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] [day] [month] [year] [list]
Date:	Wed, 20 May 2015 10:18:48 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Stefan Agner <stefan@...er.ch>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Sanchayan Maity <maitysanchayan@...il.com>,
	shawn.guo@...aro.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [PATCH v2 2/2] ARM: vf610: Add SoC bus support for Vybrid

On Wednesday 20 May 2015 09:36:38 Stefan Agner wrote:
> On 2015-05-20 09:12, Arnd Bergmann wrote:
> > On Wednesday 20 May 2015 11:06:52 Sanchayan Maity wrote:
> >> Implements SoC bus support to export SoC specific information. Read
> >> the unique SoC ID from the Vybrid On Chip One Time Programmable
> >> (OCOTP) controller, SoC specific information from the Miscellaneous
> >> System Control Module (MSCM), revision from the ROM revision register
> >> and expose it via the SoC bus infrastructure.
> >>
> >> Sample Output:
> >>
> >> root@vf:/sys/devices/soc0# cat soc_id
> >> df63c12a2e2161d4
> >> root@vf:/sys/devices/soc0# cat family
> >> Freescale Vybrid VF500
> >> root@vf:/sys/devices/soc0# cat revision
> >> 00000013
> >> root@vf:/sys/devices/soc0# cat machine
> >> Freescale Vybrid
> >>
> > 
> > I would prefer to see this as a driver in drivers/soc that registers
> > to a platform device. Is there any DT node that would be a reasonable
> > device to bind to?
> 
> Hm, what is a viable device? Probably the most SoC specific device in
> the SoC? Currently, all three devices we read from do have a
> vf610-something compatible string, hence would be SoC specific (ocotp,
> ocrom and mscm-cpucfg). Probably the last is the most SoC specific...
> 
> But somehow bind to just a random device sounds wrong to me. Couldn't we
> add a more specific compatible string to the soc node and bind to that?

mscm-cpucfg by the name  sounds right to me, especially if we later
want to add some exported functions or configuration to the driver.

The other two (judging by the name without knowing anything
about them) seem like pure data areas that may also be shared with
other drivers and are better represented as syscon or eprom devices.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists