All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Luka Kovacic <luka.kovacic@sartura.hr>
Cc: "Pali Rohár" <pali@kernel.org>,
	"Robert Marko" <robert.marko@sartura.hr>,
	U-Boot-Denx <u-boot@lists.denx.de>, "Stefan Roese" <sr@denx.de>,
	"Luka Perkov" <luka.perkov@sartura.hr>
Subject: Re: [PATCH 1/2] arm: mvebu: Implement the mac command (Marvell hw_info)
Date: Mon, 11 Oct 2021 12:56:34 +0200	[thread overview]
Message-ID: <20211011125634.32dab223@dellmb> (raw)
In-Reply-To: <CADZsf3YF3N5+vzsBfYBzDCQ7Ja3JTz-WGUJ0_gikuqHcOXsXUw@mail.gmail.com>

On Mon, 11 Oct 2021 12:19:07 +0200
Luka Kovacic <luka.kovacic@sartura.hr> wrote:

> Hello Pali,
> 
> > Something like this? compatible = "marvell,hw-info"  
> 
> This compatible string looks good to me.
> We will send a new patch version, which implements the discussed DT
> functionality.
>
> > > I am sure Luka knows more about the format than me.  
> 
> The Marvell hw_info partition is very similar to the U-Boot
> environment. The only difference is in the separator between the
> "key=value" pairs, which is 0x20/space in the case of hw_info.
> This is also prevents us to hard-code the parameter addresses in the
> device tree, because they can move around.
>
> The checksum is stored before the hw_info environment - this would
> have to be investigated further to implement checksum verification.

These differences between Marvell's version and U-Boot's standard
environment version can be specified in device-tree (via compatible or
other properties) and handled by one driver.

A driver for nvmem provider of standard U-Boot env could have this
binding (with "denx,u-boot-env" as compatible, changing it to
"marvell,hw-info" would make it work with spaces instead of '=' as
separator):

  spi-flash {
    blah blah blah;

    partitions {
      compatible = "fixed-partitions";
      #address-cells = <1>;
      #size-cells = <1>;

      hw-info@18000 {
        compatible = "denx,u-boot-env";
        reg = <0x18000 0x1000>;
        label = "hw-info";

        eth0_mac_addr: ethaddr {
          compatible = "mac-address-string";
          name = "ethaddr";
        };

        eth1_mac_addr: eth1addr {
          compatible = "mac-address-string";
          name = "eth1addr";
        };
      };
    };
  };

  ethernet@30000 {
    nvmem-cells = <&eth0_mac_addr>;
    nvmem-cell-names = "mac-address";
  };


On Turris MOX, we have the MAC address of the device stored in
One-Time-Programmable memory accesible only by the secure coprocessor,
which Linux communicates with via the turris-mox-rwtm kernel driver.

Currently this driver does not register itself as a nvmem provider, and
so isn't use by the ethernet controller driver to get MAC addresses.
MAC addresses are currently read by U-Boot board code and the
controller keeps these to Linux.

But I plan to extend the turris-mox-rwtm driver to also provide MAC
addresses via nvmem API, and then specify in device-tree
  &eth1 {
    nvmem-cells = <&rwtm_eth1_mac>;
    nvmem-cell-names = "address";
  };

Maybe in the future you will also want to implement this in Linux.
It could be done simply by adding a new type of nvmem provider, with
compatible = "marvell,hw-info".

Luka, what do you think?

Marek 

  reply	other threads:[~2021-10-11 10:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-08 12:09 [PATCH 1/2] arm: mvebu: Implement the mac command (Marvell hw_info) Robert Marko
2021-10-08 12:09 ` [PATCH 2/2] arm: mvebu: add Globalscale MOCHAbin support Robert Marko
2021-10-08 12:53 ` [PATCH 1/2] arm: mvebu: Implement the mac command (Marvell hw_info) Pali Rohár
2021-10-08 13:28   ` Luka Kovacic
2021-10-08 18:06     ` Pali Rohár
2021-10-09  9:42       ` Marek Behún
2021-10-09 10:09         ` Robert Marko
2021-10-09 10:29           ` Pali Rohár
2021-10-11 10:19             ` Luka Kovacic
2021-10-11 10:56               ` Marek Behún [this message]
2021-10-11 16:16                 ` Luka Kovacic
2021-10-13 14:44                   ` Marek Behún
2021-10-13 15:35                     ` Luka Kovacic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211011125634.32dab223@dellmb \
    --to=kabel@kernel.org \
    --cc=luka.kovacic@sartura.hr \
    --cc=luka.perkov@sartura.hr \
    --cc=pali@kernel.org \
    --cc=robert.marko@sartura.hr \
    --cc=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.