| Message ID | 20180622043756.21158-1-benh@kernel.crashing.org |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | [1/2] dt-bindings: fsi: Add optional chip-id to CFAMs | expand |
On Fri, Jun 22, 2018 at 02:37:55PM +1000, Benjamin Herrenschmidt wrote: > This represents a physical chip in the system and allows > a stable numbering scheme to be passed to udev for userspace > to recognize which chip is which. I'm sure you're aware, stable numbers is generally not something the kernel guarantees... In the cases where we do have them, we've used aliases. > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > --- > Documentation/devicetree/bindings/fsi/fsi.txt | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt b/Documentation/devicetree/bindings/fsi/fsi.txt > index ab516c673a4b..afb4eccab131 100644 > --- a/Documentation/devicetree/bindings/fsi/fsi.txt > +++ b/Documentation/devicetree/bindings/fsi/fsi.txt > @@ -83,6 +83,10 @@ addresses and sizes in the slave address space: > #address-cells = <1>; > #size-cells = <1>; > > +Optionally, a slave can provide a global unique chip ID which is used to > +identify the physical location of the chip in a system specific way > + > + chip-id = <0>; > > FSI engines (devices) > --------------------- > @@ -125,6 +129,7 @@ device tree if no extra platform information is required. > reg = <0 0>; > #address-cells = <1>; > #size-cells = <1>; > + chip-id = <0>; > > /* FSI engine at 0xc00, using a single page. In this example, > * it's an I2C master controller, so subnodes describe the > -- > 2.17.1 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2018-07-03 at 13:30 -0600, Rob Herring wrote: > On Fri, Jun 22, 2018 at 02:37:55PM +1000, Benjamin Herrenschmidt wrote: > > This represents a physical chip in the system and allows > > a stable numbering scheme to be passed to udev for userspace > > to recognize which chip is which. > > I'm sure you're aware, stable numbers is generally not something the > kernel guarantees... This has nothing to do with any kernel guarantee. Not sure what you are mixing up here :-) The IDs will get exposed via sysfs in order to allow udev rules to create appropriate symlinks such as by-id or by-path as is traditional (we haven't completely decided some of the udev side details yet) > In the cases where we do have them, we've used aliases. This is necessary, though Aliases may do the job too. This is the device-tree that represents the "host" system that the BMC is managing. We need to be able to identify using a stable numbering scheme the processors on the FSI topology otherwise we would do "interesting" things such as turn the fan for CPU 1 when CPU 0 gets hot :-) (This is just a silly example, there are plenty of other reasons why we need to understand the HW topology of a given system, including debuggers using FSI as a backend etc...) Traditionally POWER has used ibm,chip-id properties for the host side, so I just did something similar here for the BMC side, but I can look into using aliases if you prefer. Note: I'm not sure what you have against DT provided names or IDs, this has been a rather standard way of doing things even before we did the FDT. For example that's what slot-names properties are for, or location codes etc... Yes we invented that alias trick later on but it's not necessarily the best approach (in fact I don't really like it to be honest). Cheers, Ben. > > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > > --- > > Documentation/devicetree/bindings/fsi/fsi.txt | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt b/Documentation/devicetree/bindings/fsi/fsi.txt > > index ab516c673a4b..afb4eccab131 100644 > > --- a/Documentation/devicetree/bindings/fsi/fsi.txt > > +++ b/Documentation/devicetree/bindings/fsi/fsi.txt > > @@ -83,6 +83,10 @@ addresses and sizes in the slave address space: > > #address-cells = <1>; > > #size-cells = <1>; > > > > +Optionally, a slave can provide a global unique chip ID which is used to > > +identify the physical location of the chip in a system specific way > > + > > + chip-id = <0>; > > > > FSI engines (devices) > > --------------------- > > @@ -125,6 +129,7 @@ device tree if no extra platform information is required. > > reg = <0 0>; > > #address-cells = <1>; > > #size-cells = <1>; > > + chip-id = <0>; > > > > /* FSI engine at 0xc00, using a single page. In this example, > > * it's an I2C master controller, so subnodes describe the > > -- > > 2.17.1 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe devicetree" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 3, 2018 at 7:07 PM Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > > On Tue, 2018-07-03 at 13:30 -0600, Rob Herring wrote: > > On Fri, Jun 22, 2018 at 02:37:55PM +1000, Benjamin Herrenschmidt wrote: > > > This represents a physical chip in the system and allows > > > a stable numbering scheme to be passed to udev for userspace > > > to recognize which chip is which. > > > > I'm sure you're aware, stable numbers is generally not something the > > kernel guarantees... > > This has nothing to do with any kernel guarantee. Not sure what you are > mixing up here :-) I was referring to /dev node names like sda/sdb/sdc or ttyS0/ttyS1. > The IDs will get exposed via sysfs in order to allow udev rules to > create appropriate symlinks such as by-id or by-path as is traditional > (we haven't completely decided some of the udev side details yet) Yeah, that's a bit different. > > In the cases where we do have them, we've used aliases. > > This is necessary, though Aliases may do the job too. This is the > device-tree that represents the "host" system that the BMC is managing. > > We need to be able to identify using a stable numbering scheme the > processors on the FSI topology otherwise we would do "interesting" > things such as turn the fan for CPU 1 when CPU 0 gets hot :-) > > (This is just a silly example, there are plenty of other reasons why we > need to understand the HW topology of a given system, including > debuggers using FSI as a backend etc...) > > Traditionally POWER has used ibm,chip-id properties for the host side, > so I just did something similar here for the BMC side, but I can look > into using aliases if you prefer. That is specifically for CPUs though, right? Is the same true here? If so, I guess this is fine. A set of indexes for any device on a bus would be more concerning. > Note: I'm not sure what you have against DT provided names or IDs, this > has been a rather standard way of doing things even before we did the > FDT. For example that's what slot-names properties are for, or location > codes etc... Yes we invented that alias trick later on but it's not > necessarily the best approach (in fact I don't really like it to be > honest). I'm no fan of aliases either, but just trying to keep some consistency in how we deal with various problems. My main concern is folks trying to create some made-up index numbering of devices. Often it's not really needed as there are other ways to address or identify devices. In many cases we end up using 'reg' if there's no other means of addressing a device. We've generally standardized around "label" for things like slots, ports, connectors, etc. that need to be physically identified. "slot-names" it seems hasn't gotten used for FDT. Since there aren't DT's published for OF based systems nor any documentation, newbies like me (that only have 8 years of DT experience) don't have any insight into how things used to be done. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2018-07-05 at 12:49 -0600, Rob Herring wrote: > On Tue, Jul 3, 2018 at 7:07 PM Benjamin Herrenschmidt > <benh@kernel.crashing.org> wrote: > > > > On Tue, 2018-07-03 at 13:30 -0600, Rob Herring wrote: > > > On Fri, Jun 22, 2018 at 02:37:55PM +1000, Benjamin Herrenschmidt wrote: > > > > This represents a physical chip in the system and allows > > > > a stable numbering scheme to be passed to udev for userspace > > > > to recognize which chip is which. > > > > > > I'm sure you're aware, stable numbers is generally not something the > > > kernel guarantees... > > > > This has nothing to do with any kernel guarantee. Not sure what you are > > mixing up here :-) > > I was referring to /dev node names like sda/sdb/sdc or ttyS0/ttyS1. Ah yes. I do have code to make those "somewhat stable" using the chip ID by default (unless overriden) as a backward compat thing for small systems but the long term goal is indeed to not rely on this. > > The IDs will get exposed via sysfs in order to allow udev rules to > > create appropriate symlinks such as by-id or by-path as is traditional > > (we haven't completely decided some of the udev side details yet) > > Yeah, that's a bit different. Yup, that's the right way actually :-) > > > In the cases where we do have them, we've used aliases. > > > > This is necessary, though Aliases may do the job too. This is the > > device-tree that represents the "host" system that the BMC is managing. > > > > We need to be able to identify using a stable numbering scheme the > > processors on the FSI topology otherwise we would do "interesting" > > things such as turn the fan for CPU 1 when CPU 0 gets hot :-) > > > > (This is just a silly example, there are plenty of other reasons why we > > need to understand the HW topology of a given system, including > > debuggers using FSI as a backend etc...) > > > > Traditionally POWER has used ibm,chip-id properties for the host side, > > so I just did something similar here for the BMC side, but I can look > > into using aliases if you prefer. > > That is specifically for CPUs though, right? No, it's for host "chips". IE, this is the device-tree of the BMC, consumed by the BMC. So we are in the context of Linux running on the BMC ARM SoC. That BMC is connected to the "Host" POWER9 chips via a service interface called FSI (think as a kind of PECI or JTAG on steroids), which it uses to crank them up or do various monitoring/management tasks. So while they are CPUs they are actually "Devices" in the context of the consumer here. Additionally, on some systems, there can be other type of chips connected to FSI, such as memory buffer chips etc... all get a "chip ID" assigned. > Is the same true here? If > so, I guess this is fine. A set of indexes for any device on a bus > would be more concerning. There can be multiple FSI links connecting to the same chips, some are accessed via cascaded FSI masters etc... so it's not about indices on the bus. It's really about identifying a physical package on the motherboard. > > Note: I'm not sure what you have against DT provided names or IDs, this > > has been a rather standard way of doing things even before we did the > > FDT. For example that's what slot-names properties are for, or location > > codes etc... Yes we invented that alias trick later on but it's not > > necessarily the best approach (in fact I don't really like it to be > > honest). > > I'm no fan of aliases either, but just trying to keep some consistency > in how we deal with various problems. My main concern is folks trying > to create some made-up index numbering of devices. Often it's not > really needed as there are other ways to address or identify devices. > In many cases we end up using 'reg' if there's no other means of > addressing a device. > > We've generally standardized around "label" for things like slots, > ports, connectors, etc. that need to be physically identified. Yes, label would be an option too, probably a better one that aliases. > "slot-names" it seems hasn't gotten used for FDT. Since there aren't > DT's published for OF based systems nor any documentation, newbies > like me (that only have 8 years of DT experience) don't have any > insight into how things used to be done. In a pretty much ad-hoc way :-) In this case, though, chip-id is a simple solution and works well (and I have the code already written and tested :-) Cheers, Ben. > Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2018-07-06 at 11:48 +1000, Benjamin Herrenschmidt wrote: > > We've generally standardized around "label" for things like slots, > > ports, connectors, etc. that need to be physically identified. > > Yes, label would be an option too, probably a better one that aliases. > > > "slot-names" it seems hasn't gotten used for FDT. Since there aren't > > DT's published for OF based systems nor any documentation, newbies > > like me (that only have 8 years of DT experience) don't have any > > insight into how things used to be done. > > In a pretty much ad-hoc way :-) In this case, though, chip-id is a > simple solution and works well (and I have the code already written and > tested :-) I want to try to get that stuff upstream. Do you still object to the chip-id's after our discussion ? The labels aren't that great really... Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 11, 2018 at 8:07 PM Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > > On Fri, 2018-07-06 at 11:48 +1000, Benjamin Herrenschmidt wrote: > > > We've generally standardized around "label" for things like slots, > > > ports, connectors, etc. that need to be physically identified. > > > > Yes, label would be an option too, probably a better one that aliases. > > > > > "slot-names" it seems hasn't gotten used for FDT. Since there aren't > > > DT's published for OF based systems nor any documentation, newbies > > > like me (that only have 8 years of DT experience) don't have any > > > insight into how things used to be done. > > > > In a pretty much ad-hoc way :-) In this case, though, chip-id is a > > simple solution and works well (and I have the code already written and > > tested :-) > > I want to try to get that stuff upstream. Do you still object to the > chip-id's after our discussion ? The labels aren't that great really... No. Acked-by: Rob Herring <robh@kernel.org> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt b/Documentation/devicetree/bindings/fsi/fsi.txt index ab516c673a4b..afb4eccab131 100644 --- a/Documentation/devicetree/bindings/fsi/fsi.txt +++ b/Documentation/devicetree/bindings/fsi/fsi.txt @@ -83,6 +83,10 @@ addresses and sizes in the slave address space: #address-cells = <1>; #size-cells = <1>; +Optionally, a slave can provide a global unique chip ID which is used to +identify the physical location of the chip in a system specific way + + chip-id = <0>; FSI engines (devices) --------------------- @@ -125,6 +129,7 @@ device tree if no extra platform information is required. reg = <0 0>; #address-cells = <1>; #size-cells = <1>; + chip-id = <0>; /* FSI engine at 0xc00, using a single page. In this example, * it's an I2C master controller, so subnodes describe the
This represents a physical chip in the system and allows a stable numbering scheme to be passed to udev for userspace to recognize which chip is which. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> --- Documentation/devicetree/bindings/fsi/fsi.txt | 5 +++++ 1 file changed, 5 insertions(+)