| Message ID | 20210414152657.12097-2-michael@walle.cc |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | net: add support for an offset of a nvmem provided MAC address | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/dt-meta-schema | success | |
| robh/dtbs-check | fail | build log |
On Wed, Apr 14, 2021 at 05:26:55PM +0200, Michael Walle wrote: > It is already possible to read the MAC address via a NVMEM provider. But > there are boards, esp. with many ports, which only have a base MAC > address stored. Thus we need to have a way to provide an offset per > network device. We need to see what Rob thinks of this. There was recently a patchset to support swapping the byte order of the MAC address in a NVMEM. Rob said the NVMEM provider should have the property, not the MAC driver. This does seems more ethernet specific, so maybe it should be an Ethernet property? Andrew
On Wed, Apr 14, 2021 at 05:43:49PM +0200, Andrew Lunn wrote: > On Wed, Apr 14, 2021 at 05:26:55PM +0200, Michael Walle wrote: > > It is already possible to read the MAC address via a NVMEM provider. But > > there are boards, esp. with many ports, which only have a base MAC > > address stored. Thus we need to have a way to provide an offset per > > network device. > > We need to see what Rob thinks of this. There was recently a patchset > to support swapping the byte order of the MAC address in a NVMEM. Rob > said the NVMEM provider should have the property, not the MAC driver. > This does seems more ethernet specific, so maybe it should be an > Ethernet property? There was also this one[1]. I'm not totally opposed, but don't want to see a never ending addition of properties to try to describe any possible transformation. Rob [1] https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20200920095724.8251-4-ansuelsmth@gmail.com/
Am 2021-04-15 23:59, schrieb Rob Herring: > On Wed, Apr 14, 2021 at 05:43:49PM +0200, Andrew Lunn wrote: >> On Wed, Apr 14, 2021 at 05:26:55PM +0200, Michael Walle wrote: >> > It is already possible to read the MAC address via a NVMEM provider. But >> > there are boards, esp. with many ports, which only have a base MAC >> > address stored. Thus we need to have a way to provide an offset per >> > network device. >> >> We need to see what Rob thinks of this. There was recently a patchset >> to support swapping the byte order of the MAC address in a NVMEM. Rob >> said the NVMEM provider should have the property, not the MAC driver. >> This does seems more ethernet specific, so maybe it should be an >> Ethernet property? > > There was also this one[1]. I'm not totally opposed, but don't want to > see a never ending addition of properties to try to describe any > possible transformation. Agreed, that stuff like ASCII MAC address parsing should be done elsewhere. But IMHO adding an offset is a pretty common one (as also pointed out in [1]). And it also need to be a per ethernet device property. -michael [1] https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20200920095724.8251-4-ansuelsmth@gmail.com/
On 4/15/2021 2:59 PM, Rob Herring wrote: > On Wed, Apr 14, 2021 at 05:43:49PM +0200, Andrew Lunn wrote: >> On Wed, Apr 14, 2021 at 05:26:55PM +0200, Michael Walle wrote: >>> It is already possible to read the MAC address via a NVMEM provider. But >>> there are boards, esp. with many ports, which only have a base MAC >>> address stored. Thus we need to have a way to provide an offset per >>> network device. >> >> We need to see what Rob thinks of this. There was recently a patchset >> to support swapping the byte order of the MAC address in a NVMEM. Rob >> said the NVMEM provider should have the property, not the MAC driver. >> This does seems more ethernet specific, so maybe it should be an >> Ethernet property? > > There was also this one[1]. I'm not totally opposed, but don't want to > see a never ending addition of properties to try to describe any > possible transformation. If only we could load eBPF bytecode embedded into Device Tree ;)
[adding Srinivas Kandagatla and Ansuel Smith] Am 2021-04-16 00:27, schrieb Michael Walle: > Am 2021-04-15 23:59, schrieb Rob Herring: >> On Wed, Apr 14, 2021 at 05:43:49PM +0200, Andrew Lunn wrote: >>> On Wed, Apr 14, 2021 at 05:26:55PM +0200, Michael Walle wrote: >>> > It is already possible to read the MAC address via a NVMEM provider. But >>> > there are boards, esp. with many ports, which only have a base MAC >>> > address stored. Thus we need to have a way to provide an offset per >>> > network device. >>> >>> We need to see what Rob thinks of this. There was recently a patchset >>> to support swapping the byte order of the MAC address in a NVMEM. Rob >>> said the NVMEM provider should have the property, not the MAC driver. >>> This does seems more ethernet specific, so maybe it should be an >>> Ethernet property? >> >> There was also this one[1]. I'm not totally opposed, but don't want to >> see a never ending addition of properties to try to describe any >> possible transformation. > > Agreed, that stuff like ASCII MAC address parsing should be done > elsewhere. But IMHO adding an offset is a pretty common one (as also > pointed out in [1]). And it also need to be a per ethernet device > property. I'm a bit up in the air on this, as I don't know how to proceed here. To cite Rob from IRC: Not really up to me. All the people that care need to come up with something flexible enough for common/simple cases and that's not going to get extended with every new variation. What I don't want is a one-off that's then extended with another one-off. I already pointed out that this property is per consumer as opposed to something like endianess swap or parsing a given format. The latter operates on the nvmem cell. One random idea is to have a nvmem-cells-transformation (in the lack of a better name) property for consumers, where you can have some kind of simple operations like add: nvmem-cells-transformation = <NVMEM_ADD 1> But is that something we really want to have? I'm not sure. btw. given that there might be other means where a base mac address can come from in the future, it might make sense to drop the "nvmem-" prefix and just use "mac-address-offset" (or "base-mac-address-offset"?). > [1] > https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20200920095724.8251-4-ansuelsmth@gmail.com/ -michael
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index e8f04687a3e0..1a8517b0e445 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -52,6 +52,12 @@ properties: nvmem-cell-names: const: mac-address + nvmem-mac-address-offset: + maxItems: 1 + description: + Specifies an offset which will be added to the MAC address when + fetched from a nvmem cell. + phy-connection-type: description: Specifies interface type between the Ethernet device and a physical
It is already possible to read the MAC address via a NVMEM provider. But there are boards, esp. with many ports, which only have a base MAC address stored. Thus we need to have a way to provide an offset per network device. Signed-off-by: Michael Walle <michael@walle.cc> --- .../devicetree/bindings/net/ethernet-controller.yaml | 6 ++++++ 1 file changed, 6 insertions(+)