Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1351367 > unrolled thread

Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-03-07 09:20 +0100
    Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Andrey Smirnov <andrew.smirnov@gmail.com> - 2016-03-08 05:10 +0100
      Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-03-08 23:30 +0100
        Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Andrey Smirnov <andrew.smirnov@gmail.com> - 2016-03-08 23:50 +0100
          Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Trent Piepho <tpiepho@kymetacorp.com> - 2016-03-09 00:40 +0100
            Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-03-09 11:20 +0100
              Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Trent Piepho <tpiepho@kymetacorp.com> - 2016-03-09 21:00 +0100
          Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-03-09 11:00 +0100
            Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Andrey Smirnov <andrew.smirnov@gmail.com> - 2016-03-09 18:10 +0100
        Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Sascha Hauer <s.hauer@pengutronix.de> - 2016-03-09 09:10 +0100

#1351367 — Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Wed, Mar 02, 2016 at 09:21:01AM -0800, Andrey Smirnov wrote:
> On Wed, Mar 2, 2016 at 5:58 AM, Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
> >
> >
> > On 01/03/16 16:59, Andrey Smirnov wrote:
> >>
> >> Add 'nvmem-blob' driver, which allows to access device tree embedded
> >> data via NVMEM subsystem API.
> >
> >
> > Patch itself looks simple. Before we review it further could you provide
> > more details on the exact usecase or some background of this.
> 
> The discussion on this topic originated on mailing list of Barebox
> project(which borrows very heavily from Linux designs). Barebox
> operates on two device tree blobs, one is used for its internal
> initialization, whereas second one is passed to Linux kernel when
> booting it. The problem I was trying to solve was to make possible to
> specify in the first DT blob what data would be used for MAC address
> fixup of the second DT blob(the one passed to Linux).
> 
> My first approach was to implement a very limited DT code, however in
> discussing it the consensus was that porting 'nvmem' subsystem from
> the kernel and using for the same purpose would be a better approach.
> First pass adoption of that subsystem revealed that there were two
> use-cases that current design didn't allow us to handle:
> 
> - Depending on the version i.MX SoC MAC address data stored in ROM
> would have different layout so as a possible solution to that I
> implemented "composite" driver(patch #3)
> 
> - On i.MX28, part of the MAC address is hard-coded in
> arch/arm/mach-mxs/mach-mxs.c and only a portion of it is read from
> ROM, this patch in combination with the aforementioned one should
> allow us to encode all needed info in DT.
> 
> Ideally, since all of the above is as applicable to Linux as it is to
> Barebox it would be good for BB not to invent its own custom 'nvmem'
> flavor, so hence me trying to start a conversation about adding this
> upstream.

If the only use-case is to store the MAC address, why not using the
local-mac-address property directly?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [next] | [standalone]

#1352608

>> >
>> > Patch itself looks simple. Before we review it further could you provide
>> > more details on the exact usecase or some background of this.
>>
>> The discussion on this topic originated on mailing list of Barebox
>> project(which borrows very heavily from Linux designs). Barebox
>> operates on two device tree blobs, one is used for its internal
>> initialization, whereas second one is passed to Linux kernel when
>> booting it. The problem I was trying to solve was to make possible to
>> specify in the first DT blob what data would be used for MAC address
>> fixup of the second DT blob(the one passed to Linux).
>>
>> My first approach was to implement a very limited DT code, however in
>> discussing it the consensus was that porting 'nvmem' subsystem from
>> the kernel and using for the same purpose would be a better approach.
>> First pass adoption of that subsystem revealed that there were two
>> use-cases that current design didn't allow us to handle:
>>
>> - Depending on the version i.MX SoC MAC address data stored in ROM
>> would have different layout so as a possible solution to that I
>> implemented "composite" driver(patch #3)
>>
>> - On i.MX28, part of the MAC address is hard-coded in
>> arch/arm/mach-mxs/mach-mxs.c and only a portion of it is read from
>> ROM, this patch in combination with the aforementioned one should
>> allow us to encode all needed info in DT.
>>
>> Ideally, since all of the above is as applicable to Linux as it is to
>> Barebox it would be good for BB not to invent its own custom 'nvmem'
>> flavor, so hence me trying to start a conversation about adding this
>> upstream.
>
> If the only use-case is to store the MAC address, why not using the
> local-mac-address property directly?

I don't think I understand what you mean, could you give me an example
of how I'd use local-mac-address property for that use case? AFAIK,
local-mac-address is just an array of bytes embedded into device tree,
how would it get populated with data from OTP memory of SoC?

[toc] | [prev] | [next] | [standalone]

#1353444

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Mon, Mar 07, 2016 at 08:07:41PM -0800, Andrey Smirnov wrote:
> >> >
> >> > Patch itself looks simple. Before we review it further could you provide
> >> > more details on the exact usecase or some background of this.
> >>
> >> The discussion on this topic originated on mailing list of Barebox
> >> project(which borrows very heavily from Linux designs). Barebox
> >> operates on two device tree blobs, one is used for its internal
> >> initialization, whereas second one is passed to Linux kernel when
> >> booting it. The problem I was trying to solve was to make possible to
> >> specify in the first DT blob what data would be used for MAC address
> >> fixup of the second DT blob(the one passed to Linux).
> >>
> >> My first approach was to implement a very limited DT code, however in
> >> discussing it the consensus was that porting 'nvmem' subsystem from
> >> the kernel and using for the same purpose would be a better approach.
> >> First pass adoption of that subsystem revealed that there were two
> >> use-cases that current design didn't allow us to handle:
> >>
> >> - Depending on the version i.MX SoC MAC address data stored in ROM
> >> would have different layout so as a possible solution to that I
> >> implemented "composite" driver(patch #3)
> >>
> >> - On i.MX28, part of the MAC address is hard-coded in
> >> arch/arm/mach-mxs/mach-mxs.c and only a portion of it is read from
> >> ROM, this patch in combination with the aforementioned one should
> >> allow us to encode all needed info in DT.
> >>
> >> Ideally, since all of the above is as applicable to Linux as it is to
> >> Barebox it would be good for BB not to invent its own custom 'nvmem'
> >> flavor, so hence me trying to start a conversation about adding this
> >> upstream.
> >
> > If the only use-case is to store the MAC address, why not using the
> > local-mac-address property directly?
> 
> I don't think I understand what you mean, could you give me an example
> of how I'd use local-mac-address property for that use case? AFAIK,
> local-mac-address is just an array of bytes embedded into device tree,

Well, yeah, but the nvmem-blob is also just an array of bytes embedded
into the DT, right?

> how would it get populated with data from OTP memory of SoC?

In the bootloader, or Linux, read the OTP, patch the DT to add that
node, done.

It's already what U-Boot does here for example (the source of ethaddr
being dependent of the platform):
http://git.denx.de/?p=u-boot.git;a=blob;f=common/fdt_support.c#l468

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1353460

>>
>> I don't think I understand what you mean, could you give me an example
>> of how I'd use local-mac-address property for that use case? AFAIK,
>> local-mac-address is just an array of bytes embedded into device tree,
>
> Well, yeah, but the nvmem-blob is also just an array of bytes embedded
> into the DT, right?

One is accessible via "nvmem" API and the other one isn't.

>
>> how would it get populated with data from OTP memory of SoC?
>
> In the bootloader, or Linux, read the OTP, patch the DT to add that
> node, done.

No, it's not really "done", because if you read my previous messages,
"read the OTP, patch the DT" is exactly the problem I am trying to
solve. The overall goal is to be able to read a certain "nvmem" cell
and patch DT with that data as MAC address, however in it's current
incarnation "nvmem" doesn't have provisions to make cells that are
just combination of other cells (patch #3) and to embed certain data
in DT and then access it as "nvmem" cell (patch #2)

[toc] | [prev] | [next] | [standalone]

#1353483

On Tue, 2016-03-08 at 14:46 -0800, Andrey Smirnov wrote:
> >> I don't think I understand what you mean, could you give me an example
> >> of how I'd use local-mac-address property for that use case? AFAIK,
> >> local-mac-address is just an array of bytes embedded into device tree,
> >
> > Well, yeah, but the nvmem-blob is also just an array of bytes embedded
> > into the DT, right?
> 
> One is accessible via "nvmem" API and the other one isn't.
> 
> >
> >> how would it get populated with data from OTP memory of SoC?
> >
> > In the bootloader, or Linux, read the OTP, patch the DT to add that
> > node, done.
> 
> No, it's not really "done", because if you read my previous messages,
> "read the OTP, patch the DT" is exactly the problem I am trying to
> solve. The overall goal is to be able to read a certain "nvmem" cell
> and patch DT with that data as MAC address, however in it's current
> incarnation "nvmem" doesn't have provisions to make cells that are
> just combination of other cells (patch #3) and to embed certain data

So I did something that solved this a few years ago for another board
and embedded the data into the local-mac-address property.

I think maybe the problem isn't here isn't clear.  For some boards
(mxs), only part of a MAC address is stored in nvmem while the rest of
the address is fixed data.  Currently embedded in the kernel source,
though embedded in the device tree would clearly be better.  While
splitting the MAC into two locations like this is not, at least in my
opinion, the best design, it's burned into the one time programmable
memory so there's not much that can be done.

The kernel looks for 'mac-address' and then 'local-mac-address', with
the former having precedence.

So what I did was embed the fixed portion in 'local-mac-address', have
the bootloader extract the variable part from nvmem, and then combine
the two and place it into 'mac-address' for the kernel to use.

My DT binding that described the placement of data from nvmem into the
MAC used a permutation list instead of a series of ranges.  So a list
like [0 0 0 1 2 3] could be used to specify the first three bytes of the
mac address do not come from nvmem.  This also allows changing byte
order concisely.  But doesn't scale well to larger regions.

[toc] | [prev] | [next] | [standalone]

#1353942

[Multipart message — attachments visible in raw view] — view raw

On Tue, Mar 08, 2016 at 11:24:33PM +0000, Trent Piepho wrote:
> On Tue, 2016-03-08 at 14:46 -0800, Andrey Smirnov wrote:
> > >> I don't think I understand what you mean, could you give me an example
> > >> of how I'd use local-mac-address property for that use case? AFAIK,
> > >> local-mac-address is just an array of bytes embedded into device tree,
> > >
> > > Well, yeah, but the nvmem-blob is also just an array of bytes embedded
> > > into the DT, right?
> > 
> > One is accessible via "nvmem" API and the other one isn't.
> > 
> > >
> > >> how would it get populated with data from OTP memory of SoC?
> > >
> > > In the bootloader, or Linux, read the OTP, patch the DT to add that
> > > node, done.
> > 
> > No, it's not really "done", because if you read my previous messages,
> > "read the OTP, patch the DT" is exactly the problem I am trying to
> > solve. The overall goal is to be able to read a certain "nvmem" cell
> > and patch DT with that data as MAC address, however in it's current
> > incarnation "nvmem" doesn't have provisions to make cells that are
> > just combination of other cells (patch #3) and to embed certain data
> 
> So I did something that solved this a few years ago for another board
> and embedded the data into the local-mac-address property.
> 
> I think maybe the problem isn't here isn't clear.  For some boards
> (mxs), only part of a MAC address is stored in nvmem while the rest of
> the address is fixed data.  Currently embedded in the kernel source,
> though embedded in the device tree would clearly be better.  While
> splitting the MAC into two locations like this is not, at least in my
> opinion, the best design, it's burned into the one time programmable
> memory so there's not much that can be done.
> 
> The kernel looks for 'mac-address' and then 'local-mac-address', with
> the former having precedence.
> 
> So what I did was embed the fixed portion in 'local-mac-address', have
> the bootloader extract the variable part from nvmem, and then combine
> the two and place it into 'mac-address' for the kernel to use.

I guess another solution would be to deal with that at the driver
level. Read the 3 last bytes from the OTP, add the MAC prefix and give
that to the net framework without looking it up in the DT. The MAC
prefix could even be changed then through a kernel parameter, which is
not possible currently.

> My DT binding that described the placement of data from nvmem into the
> MAC used a permutation list instead of a series of ranges.  So a list
> like [0 0 0 1 2 3] could be used to specify the first three bytes of the
> mac address do not come from nvmem.  This also allows changing byte
> order concisely.  But doesn't scale well to larger regions.

Is your code / binding doc somewhere for reference ?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1354401

On Wed, 2016-03-09 at 11:13 +0100, Maxime Ripard wrote:
> On Tue, Mar 08, 2016 at 11:24:33PM +0000, Trent Piepho wrote:
> > I think maybe the problem isn't here isn't clear.  For some boards
> > (mxs), only part of a MAC address is stored in nvmem while the rest of
> > the address is fixed data.  Currently embedded in the kernel source,
> > though embedded in the device tree would clearly be better.  While
> > splitting the MAC into two locations like this is not, at least in my
> > opinion, the best design, it's burned into the one time programmable
> > memory so there's not much that can be done.
> > 
> > The kernel looks for 'mac-address' and then 'local-mac-address', with
> > the former having precedence.
> > 
> > So what I did was embed the fixed portion in 'local-mac-address', have
> > the bootloader extract the variable part from nvmem, and then combine
> > the two and place it into 'mac-address' for the kernel to use.
> 
> I guess another solution would be to deal with that at the driver
> level. Read the 3 last bytes from the OTP, add the MAC prefix and give
> that to the net framework without looking it up in the DT. The MAC
> prefix could even be changed then through a kernel parameter, which is
> not possible currently.

How the data is stored in nvmem is specific to each board.  Some boards
use OTP, some use an external EEPROM.  The EEPROM could be on any of
multiple SPI or I2C buses and at different possible addresses.  The data
in OPT might be little-endian or big-endian or "written by someone who
doesn't understand byte order"-endian.

So the ethernet driver would need to deal with many different possible
board configurations.  And each ethernet driver would need to do that
all over again.

So the idea is to create a way that a single "DT binding for a MAC from
nvmem" driver could do the job for all boards and all ethernet drivers.
While there are many possibilities, a DT binding that covers all of them
doesn't need to be that complex.

> > My DT binding that described the placement of data from nvmem into the
> > MAC used a permutation list instead of a series of ranges.  So a list
> > like [0 0 0 1 2 3] could be used to specify the first three bytes of the
> > mac address do not come from nvmem.  This also allows changing byte
> > order concisely.  But doesn't scale well to larger regions.
> 
> Is your code / binding doc somewhere for reference ?

No, it was for a product that never upstreamed those changes :(.  It was
somewhat like the bindings that already exist in c6x/dscr.txt, for
ti,dscr-mac-fuse-regs.  I didn't support EEPROMs for that board, but
once extended to support that it would like something like:

&ethernet-device {
    mac-address   = [ab cd ef 00 00 00]; //already defined binding
    mac-nvmem     = <&otp 0x80 4>;  // these two are new bindings
    mac-nvmem-map = [0 0 0 1 2 3];
};

mac-nvmem = tuple of phandle, offset, length.  phandle is to a nvmem
device (OTP, eeprom, etc.).

mac-nvmem-map = list of bytes the length of a MAC address.  Each byte
indicates what byte from mac-nvmem (starting at 1, not 0) should go into
the corresponding position in the MAC.  0 means no byte from mac-nvmem
should be used for that position.

Thus [0 0 0 1 2 3] means the first three bytes of the mac do not come
from OTP and default to the existing value of mac-address.  The fourth
byte of the MAC should be the 1st byte from mac-nvmem, the fifth byte
shoud be the 2nd byte, and so on.

I believe this concisely handles all the possible cases of byte order,
EEPROMs, bytes in DT combined with bytes in OTP, etc. that I know of as
being used.

It doesn't attempt to be as powerful as Andrey's bindings.  E.g., it
doesn't scale to data much longer than a MAC address as the permutation
map list would become cumbersomely long.  It also doesn't support
combining data from more than two sources.

[toc] | [prev] | [next] | [standalone]

#1353933

[Multipart message — attachments visible in raw view] — view raw

On Tue, Mar 08, 2016 at 02:46:52PM -0800, Andrey Smirnov wrote:
> >>
> >> I don't think I understand what you mean, could you give me an example
> >> of how I'd use local-mac-address property for that use case? AFAIK,
> >> local-mac-address is just an array of bytes embedded into device tree,
> >
> > Well, yeah, but the nvmem-blob is also just an array of bytes embedded
> > into the DT, right?
> 
> One is accessible via "nvmem" API and the other one isn't.

But there's no point in accessing it with nvmem in the first
place. You want to provide some information to the ethernet driver to
give it his mac address, that's what you want to do. And we already
have a property that does just that, and is supported by all the
ethernet drivers. Why would you want to add a special case to
something that is doing exactly the same thing?

> >> how would it get populated with data from OTP memory of SoC?
> >
> > In the bootloader, or Linux, read the OTP, patch the DT to add that
> > node, done.
> 
> No, it's not really "done", because if you read my previous messages,
> "read the OTP, patch the DT" is exactly the problem I am trying to
> solve. The overall goal is to be able to read a certain "nvmem" cell
> and patch DT with that data as MAC address,

But *why* do you need to store that using nvmem in the first place?
You really have two solutions here: make your ethernet driver read the
EEPROM using nvmem directly or do it in the bootloader and set
local-mac-address (note that you can do both).

> however in it's current incarnation "nvmem" doesn't have provisions
> to make cells that are just combination of other cells (patch #3)

This use case is valid.

> and to embed certain data in DT and then access it as "nvmem" cell
> (patch #2)

And this one is redundant.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1354284

On Wed, Mar 9, 2016 at 1:58 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Tue, Mar 08, 2016 at 02:46:52PM -0800, Andrey Smirnov wrote:
>> >>
>> >> I don't think I understand what you mean, could you give me an example
>> >> of how I'd use local-mac-address property for that use case? AFAIK,
>> >> local-mac-address is just an array of bytes embedded into device tree,
>> >
>> > Well, yeah, but the nvmem-blob is also just an array of bytes embedded
>> > into the DT, right?
>>
>> One is accessible via "nvmem" API and the other one isn't.
>
> But there's no point in accessing it with nvmem in the first
> place. You want to provide some information to the ethernet driver to
> give it his mac address, that's what you want to do.

No, that's not what I want to do. I want to be able to deal with data
layout and composition of a "nvmem" cell at the data producer site and
not add custom hacks to the consumer code.

> And we already have a property that does just that, and is supported by all the
> ethernet drivers. Why would you want to add a special case to
> something that is doing exactly the same thing?

That's not what I am trying to add. The intent of "nvmem-blob" is to
be use as a part of a "nvmem-composite" cell in order to be able to
inject constants. It has nothing to do with storing complete
MAC-addresses, the fact that it can be used as a complete replacement
of "local-mac-address" is just a side-effect.

Sidenote: now that we are on the subject of using this code as
equivalent of "local-mac-address", I'd argue that if it were possible
to ignore backwards compatibility, removing "local-mac-address" from
all the drivers and .dts's and replacing it with something to the
effect of "nvmem-blob" would be a better solution since you'd be able
to handle the cases of MAC address being a part of DT and being stored
in NVM using exactly the same code-path.

>
>> >> how would it get populated with data from OTP memory of SoC?
>> >
>> > In the bootloader, or Linux, read the OTP, patch the DT to add that
>> > node, done.
>>
>> No, it's not really "done", because if you read my previous messages,
>> "read the OTP, patch the DT" is exactly the problem I am trying to
>> solve. The overall goal is to be able to read a certain "nvmem" cell
>> and patch DT with that data as MAC address,
>
> But *why* do you need to store that using nvmem in the first place?

Because I want to combine that data with other nvmem blobs using
"nvmem-composite"

> You really have two solutions here: make your ethernet driver read the
> EEPROM using nvmem directly or do it in the bootloader and set
> local-mac-address (note that you can do both).

Which would lead to per-board/per-SoC custom code. I've had that kind
of solution before I started this discussion. I am hoping that we all
can come up with more elegant solution and that's why I started this
thread.

>
>> however in it's current incarnation "nvmem" doesn't have provisions
>> to make cells that are just combination of other cells (patch #3)
>
> This use case is valid.
>
>> and to embed certain data in DT and then access it as "nvmem" cell
>> (patch #2)
>
> And this one is redundant.

How is it redundant? What kernel code allows one to create a constant
"nvmem" cell?

And why do you think #3 valid? Your solution for #2, namely:

> make your ethernet driver read the
> EEPROM using nvmem directly or do it in the bootloader and set
> local-mac-address (note that you can do both)

applies in the case of #3 as well. I can read and shuffle the data in
either consumer side (in this particular case the Ethernet driver) or
in the bootloader.

[toc] | [prev] | [next] | [standalone]

#1353887

On Tue, Mar 08, 2016 at 11:28:21PM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Mar 07, 2016 at 08:07:41PM -0800, Andrey Smirnov wrote:
> > >> >
> > >> > Patch itself looks simple. Before we review it further could you provide
> > >> > more details on the exact usecase or some background of this.
> > >>
> > >> The discussion on this topic originated on mailing list of Barebox
> > >> project(which borrows very heavily from Linux designs). Barebox
> > >> operates on two device tree blobs, one is used for its internal
> > >> initialization, whereas second one is passed to Linux kernel when
> > >> booting it. The problem I was trying to solve was to make possible to
> > >> specify in the first DT blob what data would be used for MAC address
> > >> fixup of the second DT blob(the one passed to Linux).
> > >>
> > >> My first approach was to implement a very limited DT code, however in
> > >> discussing it the consensus was that porting 'nvmem' subsystem from
> > >> the kernel and using for the same purpose would be a better approach.
> > >> First pass adoption of that subsystem revealed that there were two
> > >> use-cases that current design didn't allow us to handle:
> > >>
> > >> - Depending on the version i.MX SoC MAC address data stored in ROM
> > >> would have different layout so as a possible solution to that I
> > >> implemented "composite" driver(patch #3)
> > >>
> > >> - On i.MX28, part of the MAC address is hard-coded in
> > >> arch/arm/mach-mxs/mach-mxs.c and only a portion of it is read from
> > >> ROM, this patch in combination with the aforementioned one should
> > >> allow us to encode all needed info in DT.
> > >>
> > >> Ideally, since all of the above is as applicable to Linux as it is to
> > >> Barebox it would be good for BB not to invent its own custom 'nvmem'
> > >> flavor, so hence me trying to start a conversation about adding this
> > >> upstream.
> > >
> > > If the only use-case is to store the MAC address, why not using the
> > > local-mac-address property directly?
> > 
> > I don't think I understand what you mean, could you give me an example
> > of how I'd use local-mac-address property for that use case? AFAIK,
> > local-mac-address is just an array of bytes embedded into device tree,
> 
> Well, yeah, but the nvmem-blob is also just an array of bytes embedded
> into the DT, right?
> 
> > how would it get populated with data from OTP memory of SoC?
> 
> In the bootloader, or Linux, read the OTP, patch the DT to add that
> node, done.

This series is a try to put the information how the MAC address can be
found (might be board specific) into the DT to not have board specific
hacks in the kernel/bootloader.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web