Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1407365pxj; Fri, 4 Jun 2021 13:40:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwZUSLdS+TZJYrAH0UNdb+voTgXLbJy93oVmKVoYrvm9vZcIeiv09UprmlzZJDHuRNxCcRm X-Received: by 2002:a50:9d8d:: with SMTP id w13mr6696293ede.94.1622839207614; Fri, 04 Jun 2021 13:40:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622839207; cv=none; d=google.com; s=arc-20160816; b=WfawqsIbjakgZpdNwmyr82PHUuhNgh62xn2hpT49MrXWavBRvQQvP8RoFS6NHtOAFa zTwZvl23cnUm3mN/qa3IsQvqgZS40md+Ws5/zby9khfamQwpJVCbf1d3jdVYXgUNOY9D zW3Hfp8RTpmteLBzMmHZmPXDaSBT6QDCUnqX4ULGw0IqkT2I/cFiExgCapnM2wWqDbCs x7goSzDVWoPHkX134Uo69g56zEzrEhaqas8YqwCblViwFhZc2GyPxxs0OtYqmRYUWl/W AY35TF04frUJv8j2EAuHnshesPB57hxR07kK5SMMyyGGhpusYAgIo3VxgZHB+Y2rz9Eb LtLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ddxgeeibrSxUcXVfcvxII7HHK8VvoeqvHMOdOUWFBHk=; b=Ct7WJSNAfJ5ZkSCwF4ekqmaTADsGQbA8yyxC0Nqe432M5v5EQH72cJonaypdK4q0TM 4JaEatWwuhYHAUfoSvk8QUF6jqOQ5/qAVXuWERO5eIGUTF4Y92tglHX4I2TcpAdu0vn+ iKI/tVMjfHgz4YHTGmVUq3U/tplpS626uqMPggIhUxXAJFkFH3RVvETY64CrkQClMFhs REEqkNkyTu+s8bs9szZwLJEmrm1cOi1DOb/oJryVeNnl5/inxbqyipUtnR9zC++vKIAT o3wMjCouWrMbmuETlKNL+W2f8uLzH0qj0e0/DN1O9xxzaBekHHkUFCbNpSUvxeH3n91J Fk9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=5w2Tfyae; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u6si5393330edt.345.2021.06.04.13.39.44; Fri, 04 Jun 2021 13:40:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=5w2Tfyae; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230330AbhFDUkM (ORCPT + 99 others); Fri, 4 Jun 2021 16:40:12 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:46114 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229982AbhFDUkL (ORCPT ); Fri, 4 Jun 2021 16:40:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=ddxgeeibrSxUcXVfcvxII7HHK8VvoeqvHMOdOUWFBHk=; b=5w2TfyaeKaPAFA8l6zq7etUFUg JuCA+AK8lxijnO6MljdPCveCyNQ7lIFzu0sHLlbomqYKq8rKlb0oz7gfnkt+fo7DRDOWpTGQY72bU W0Jso7FUPxR4dkXsisxsTWtCmQ3CmZeXZsvtu4/t1bo22JQvPzkBz8nhulJoJH6K3WpY=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1lpGaB-007quD-RB; Fri, 04 Jun 2021 22:38:19 +0200 Date: Fri, 4 Jun 2021 22:38:19 +0200 From: Andrew Lunn To: Mark Brown Cc: Sander Vanheule , Greg Kroah-Hartman , "Rafael J . Wysocki" , Andy Shevchenko , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/2] Clause-22/Clause-45 MDIO regmap support Message-ID: References: <20210604172515.GG4045@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210604172515.GG4045@sirena.org.uk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 04, 2021 at 06:25:15PM +0100, Mark Brown wrote: > On Thu, Jun 03, 2021 at 08:25:08PM +0200, Sander Vanheule wrote: > > > 1. I've opted to just ignore any bits that lie beyond the allowed address > > width. Would it be cleaner to raise an error instead? > > It doesn't *really* matter, enforcement is probably a bit better as it > might catch bugs. I would agree with that. The mostly likely problem is that somebody misses the difference between C22 and C45 and instantiates the wrong sort of regmap. You can quickly detect a C22 regmap being used for C45 due to the range difference. > > 2. Packing of the clause-45 register addresses (16 bit) and adressed device > > type (5 bit) is the same as in the mdio subsystem, resulting in a 21 bit > > address. Is this an appropriate way to pack this information into one > > address for the regmap interface? > > Either that or pass the type in when instantiating the regmap (it sounds > like it should be the same for all registers on the device?). A device can implement both C22 and C45. There is also a standardized way to perform C45 access over C22, using two registers in C22 space. But this assumes the device is an Ethernet PHY, or is at least making use of the Ethernet PHY way of doing this tunnelling. But i doubt any Ethernet PHY driver will ever use regmap. Where i see regmap-mdio being used it for non-Ethernet PHY devices. That mostly means Ethernet Switches and oddball devices like this like LED controller. Broadcom also have a generic PHY driver talking over MDIO to hardware. Andrew