[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ceaf0e29-2306-37af-f170-281d7c097fad@linaro.org>
Date: Mon, 13 Sep 2021 15:20:03 +0100
From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To: John Thomson <lists@...nthomson.fastmail.com.au>,
Vadym Kochan <vadym.kochan@...ision.eu>,
Jan Lübbe <jlu@...gutronix.de>
Cc: Rob Herring <robh+dt@...nel.org>, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, Robert Marko <robert.marko@...tura.hr>
Subject: Re: [PATCH v2 3/3] nvmem: add ONIE nvmem cells parser
On 12/09/2021 22:06, John Thomson wrote:
> Hi Vadym,
>
> On Wed, 8 Sep 2021, at 09:56, Vadym Kochan wrote:
>>
>> Hi Jan,
>>
>> Jan Lübbe <jlu@...gutronix.de> writes:
> …
>>
>>> I think it would be useful to have a way to express this setup for systems with
>>> many interfaces, but am unsure of where this should be described. Maybe a "mac-
>>> address-offset" property in the generic ethernet controller binding?
>>>
>>> Regards,
>>> Jan
>>
>> May be something like eth_address_provider should be introduced in
>> net/ethernet/ ?
>>
>> This provider can provide something like eth_provider_address_next() which
>> will consider "mac-address-num" (or other specific fields).
>>
>
> A patch series proposed the devicetree property
> mac-address-increment, but it did not get support at the time:
Please have a look at some recent nvmem patches
https://lkml.org/lkml/2021/9/8/270 that adds support for vendor specific
post-processing of nvmem-cells.
Am hoping that increment usecase (along with other variants) should also
be dealt in similar way.
--srini
> of_net: add mac-address-increment support
> https://lore.kernel.org/all/20200920095724.8251-4-ansuelsmth@gmail.com/
> dt-bindings: net: Document use of mac-address-increment
> https://lore.kernel.org/all/20200920095724.8251-5-ansuelsmth@gmail.com/
>
> Cheers,
>
Powered by blists - more mailing lists