netdev - Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <542AC5B2.9040406@pengutronix.de>
Date:	Tue, 30 Sep 2014 17:01:06 +0200
From:	Marc Kleine-Budde <mkl@...gutronix.de>
To:	Wolfram Sang <wsa@...-dreams.de>
CC:	Roger Quadros <rogerq@...com>, wg@...ndegger.com, tony@...mide.com,
	tglx@...utronix.de, mugunthanvnm@...com, george.cherian@...com,
	balbi@...com, nsekhar@...com, nm@...com,
	sergei.shtylyov@...entembedded.com, linux-omap@...r.kernel.org,
	linux-can@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism

On 09/30/2014 04:49 PM, Wolfram Sang wrote:
> On Tue, Sep 30, 2014 at 04:22:08PM +0200, Marc Kleine-Budde wrote:
>> On 09/30/2014 04:19 PM, Wolfram Sang wrote:
>>>
>>>> As just TI is using this out of band RAMINIT mechanism, should it be "ti,syscon" or just "syscon"?
>>>
>>> Yes, only TI uses this out-of-band RAMINIT (currently, at least). So, we
>>> need an (optional) way to describe that. However, accessing syscon
>>> registers in general is not TI specific and a generic way to do this
>>> should be used. Which looks to me like the "syscon" property to allow
>>> access to the register. Still, we should ask DT maintainers about it,
>>> maybe they prefer a more precise property like "syscon-raminit" to allow
>>> for further syscon extensions later or something...
>>
>> What do you think about putting the bit information in the
>> syscon-raminit phandle as additional arguments?
> 
> Then we'd have <n> syscon phandles for <n> instances?
> 
> Also, judging from Markus patch [1] there is already some
> infrastructure, namely syscon_regmap_lookup_by_phandle(). From a
> glimpse, it doesn't look viable to add such a support to it.

Yes, but syscon_regmap_lookup_by_phandle() doesn't need any support for
additional parameters. Have a look at:

drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c

First get the regmap, then the 1st argument is the offset in the regmap,
the 2nd and 3rd could be the bits.

> So, I'd rather drop additional arguments.
> 
> Why would you like to have it encoded in DT?

Where put the information then? Into the driver, but where do you get
the reference which instance of the DCAN you are, so that you can look
up the correct bits?

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)