On Mon, 2018-08-06 at 08:48 -0600, Rob Herring wrote:
> On Sun, Aug 5, 2018 at 4:03 PM Robert P. J. Day wrote:
> >
> >
> >
> Yes, to answer your question in the subject...
>
> >
> > in section 2.2.2 of devicetree spec v0.2, there is a moderately
> > lengthy list of recommended (but not mandatory) node names, but i
> > notice the use of a few other node names that might warrant inclusion
> > in that list. first, there is a *single* use of the node name
> > "nor-flash" here:
> >
> > arm64/boot/dts/hisilicon/hip05-d02.dts: nor-flash@0,0 {
> >
> > but a single usage doesn't really warrant official approval.
> Why not?
>
> >
> > next, there is usage of both "spiflash" and "spi-flash", but
> > "spi-flash" is clearly the dominant form (searching under arch/):
> >
> > $ grep -r spi-flash@ * | wc -l
> > 38
> > $ grep -r spiflash@ * | wc -l
> > 1
> >
> > so is "spi-flash" a recommended node name to be added to that list?
> > (neither of them is in the list at present.)
> Or they should all be changed to nor-flash. I'm not sure that encoding
> the interface type into the node name is good practice. Do we need
> i2c-flash, parallel-bus-flash, etc.?
>
It's not about encoding the inteface name, SpiFlash is the registered
trademark for that type of device, so spi-flash is a good compromise
that makes it immediately apparently what type of device it is without
violating anybody's trademark.
Of course, the compatible string tells you what type of device it is,
and the node's location in the tree tells you the interface. So the
name doesn't need to tell you anything at all, and to me that argues
for using something that's descriptive of the way the device is used in
the system, and that strongly argues against any arbitrary naming
standard at all except for general guidelines such as "dashes not
underbars".
-- Ian
> >
> > a few other node names i noticed in my travels, none of which are in
> > that list:
> >
> > video@...
> What about video? Probably should be something else.
>
> >
> > qos@...
> > vram@...
> > gadget@...
> Sounds like a Linuxism.
>
> >
> > video-scaler@...
> >
> > also, while the approved list contains "usb-phy", there is a fair
> > bit of just "ubsphy" -- is that equally acceptable?
> I assume you meant usbphy, but no. We should fix dts files that deviate.
>
> >
> > the list also contains "usb-hub", of which there is all of one
> > example:
> >
> > arm/boot/dts/exynos5410-odroidxu.dts: usb3503: usb-hub@8 {
> There aren't many because not that many boards have a USB hub soldered
> on the board and need them described in DT.
>
> What about the cases of hubs that didn't use usb-hub?
>
> >
> > finally, i notice a few instances of the node name "mtd_dataflash"
> > under arm/boot/dts (using an underscore instead of the ubiquitous
> > hyphen):
> >
> > at91rm9200ek.dts: mtd_dataflash@0 {
> > at91sam9260ek.dts: mtd_dataflash@0 {
> > at91sam9261ek.dts: mtd_dataflash@0 {
> > at91sam9263ek.dts: mtd_dataflash@0 {
> > at91sam9g20ek_common.dtsi: mtd_dataflash@0 {
> > at91sam9m10g45ek.dts: mtd_dataflash@0 {
> > at91sam9rlek.dts: mtd_dataflash@0 {
> > usb_a9263.dts: mtd_dataflash@0 {
> These should be changed, not added to the spec.
>
> Node names are horribly inconsistent as they don't matter to the OS
> generally and we haven't enforced any names or documentation of names.
> The first step is to just have a list of names to point to. I don't
> plan to require documenting node names until we have machine parseable
> documentation[1].
>
> Rob
>
> [1] https://github.com/robherring/yaml-bindings
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree-spec" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
