Skip to content
GitLab
  1. Nov 29, 2022
    • Paolo Abeni's avatar
      Merge branch 'marvell-nvmem-mac-addresses-support' · 4f5ed7fb
      Paolo Abeni authored 
      Miquel Raynal says:

====================
Marvell nvmem mac addresses support

Now that we are aligned on how to make information available from static
storage media to drivers like Ethernet controller drivers or switch
drivers by using nvmem cells and going through the whole nvmem
infrastructure, here are two driver updates to reflect these changes.

Prior to the driver updates, I propose:
* Reverting binding changes which should have never been accepted like
  that.
* A conversion of the (old) Prestera and DFX server bindings (optional,
  can be dropped if not considered necessary).
* A better description of the more recent Prestera PCI switch.

Please mind that this series cannot break anything since retrieving the
MAC address Prestera driver has never worked upstream, because the (ONIE
tlv) driver supposed to export the MAC address has not been accepted in
its original form and has been updated to the nvmem-layout
infrastructure (bindings have been merged, the code remains to be
applied).
====================

Link: https://lore.kernel.org/r/20221124111556.264647-1-miquel.raynal@bootlin.com


Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      4f5ed7fb
    • Miquel Raynal's avatar
      net: mvpp2: Consider NVMEM cells as possible MAC address source · 7a74c126
      Miquel Raynal authored 
      The ONIE standard describes the organization of tlv (type-length-value)
arrays commonly stored within NVMEM devices on common networking
hardware.

Several drivers already make use of NVMEM cells for purposes like
retrieving a default MAC address provided by the manufacturer.

What made ONIE tables unusable so far was the fact that the information
where "dynamically" located within the table depending on the
manufacturer wishes, while Linux NVMEM support only allowed statically
defined NVMEM cells. Fortunately, this limitation was eventually tackled
with the introduction of discoverable cells through the use of NVMEM
layouts, making it possible to extract and consistently use the content
of tables like ONIE's tlv arrays.

Parsing this table at runtime in order to get various information is now
possible. So, because many Marvell networking switches already follow
this standard, let's consider using NVMEM cells as a new valid source of
information when looking for a base MAC address, which is one of the
primary uses of these new fields. Indeed, manufacturers following the
ONIE standard are encouraged to provide a default MAC address there, so
let's eventually use it if no other MAC address has been found using the
existing methods.

Link: https://opencomputeproject.github.io/onie/design-spec/hw_requirements.html


Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      7a74c126
    • Miquel Raynal's avatar
      net: marvell: prestera: Avoid unnecessary DT lookups · a48acad7
      Miquel Raynal authored 
      

This driver fist makes an expensive DT lookup to retrieve its DT node
(this is a PCI driver) in order to later search for the
base-mac-provider property. This property has no reality upstream and
this code should not have been accepted like this in the first
place. Instead, there is a proper nvmem interface that should be
used. Let's avoid these extra lookups and rely on the nvmem internal
logic.

Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      a48acad7
    • Miquel Raynal's avatar
      of: net: export of_get_mac_address_nvmem() · 4c47867b
      Miquel Raynal authored 
      

Export

	of_get_mac_addr_nvmem()

and rename it to

	of_get_mac_address_nvmem()

in order to fit the convention followed by the existing exported helpers
of the same kind.

This way, OF compatible drivers using eg. fwnode_get_mac_address() can
do a direct call to it instead of calling of_get_mac_address() just for
the nvmem step, avoiding to repeat an expensive DT lookup which has
already been done once.

Eventually, fwnode_get_mac_address() should probably be updated to
perform the nvmem lookup directly, but as of today, nvmem cells seem not
to be supported by ACPI yet which would defeat this kind of extension.

Suggested-by: default avatarMarcin Wojtas <mw@semihalf.com>
Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      4c47867b
    • Miquel Raynal's avatar
      dt-bindings: net: marvell,prestera: Describe PCI devices of the prestera family · 39d10386
      Miquel Raynal authored 
      

Even though the devices have very little in common beside the name and
the main "switch" feature, Marvell Prestera switch family is also
composed of PCI-only devices which can receive additional static
properties, like nvmem cells to point at MAC addresses, for
instance. Let's describe them.

Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: default avatarRob Herring <robh@kernel.org>
Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      39d10386
    • Miquel Raynal's avatar
      dt-bindings: net: marvell,prestera: Convert to yaml · a429ab01
      Miquel Raynal authored 
      

The currently described switch family is named AlleyCat3, it is a memory
mapped switch found on Armada XP boards.

Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: default avatarRob Herring <robh@kernel.org>
Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      a429ab01
    • Miquel Raynal's avatar
      dt-bindings: net: marvell,dfx-server: Convert to yaml · 63b956f9
      Miquel Raynal authored 
      

Even though this description is not used anywhere upstream (no matching
driver), while on this file I decided I would try a conversion to yaml
in order to clarify the prestera family description.

I cannot keep the nodename dfx-server@xxxx so I switched to dfx-bus@xxxx
which matches simple-bus.yaml. Otherwise I took the example context from
the only user of this compatible: armada-xp-98dx3236.dtsi, which is a
rather old and not perfect DT.

Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      63b956f9
    • Miquel Raynal's avatar
      Revert "dt-bindings: marvell,prestera: Add description for device-tree bindings" · 98eb05dc
      Miquel Raynal authored 
      This reverts commit 40acc052

.

marvell,prestera.txt is an old file describing the old Alleycat3
standalone switches. The commit mentioned above actually hacked these
bindings to add support for a device tree property for a more modern
version of the IP connected over PCI, using only the generic compatible
in order to retrieve the device node from the prestera driver to read
one static property.

The problematic property discussed here is "base-mac-provider". The
original intent was to point to a nvmem device which could produce the
relevant nvmem-cell. This property has never been acked by DT
maintainers and fails all the layering that has been brought with the nvmem
bindings by pointing at a nvmem producer, bypassing the existing nvmem
bindings, rather than a nvmem cell directly. Furthermore, the property
cannot even be used upstream because it expected the ONIE tlv driver to
produce a specific cell, driver which used nacked bindings and thus was
never merged, replaced by a more integrated concept: the nvmem-layout.

So let's forget about this temporary addition, safely avoiding the need
for any backward compatibility handling. A new (yaml) binding file will
be brought with the prestera bindings, and there we will actually
include a description of the modern IP over PCI, including the right way
to point to a nvmem cell.

Cc: Vadym Kochan <vadym.kochan@plvision.eu>
Cc: Taras Chornyi <tchornyi@marvell.com>
Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
Acked-by: default avatarRob Herring <robh@kernel.org>
Acked-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      98eb05dc
    • Jakub Kicinski's avatar
      Daniel Borkmann says: · d6dc62fc
      Jakub Kicinski authored 
      ====================
bpf-next 2022-11-25

We've added 101 non-merge commits during the last 11 day(s) which contain
a total of 109 files changed, 8827 insertions(+), 1129 deletions(-).

The main changes are:

1) Support for user defined BPF objects: the use case is to allocate own
   objects, build own object hierarchies and use the building blocks to
   build own data structures flexibly, for example, linked lists in BPF,
   from Kumar Kartikeya Dwivedi.

2) Add bpf_rcu_read_{,un}lock() support for sleepable programs,
   from Yonghong Song.

3) Add support storing struct task_struct objects as kptrs in maps,
   from David Vernet.

4) Batch of BPF map documentation improvements, from Maryam Tahhan
   and Donald Hunter.

5) Improve BPF verifier to propagate nullness information for branches
   of register to register comparisons, from Eduard Zingerman.

6) Fix cgroup BPF iter infra to hold reference on the start cgroup,
   from Hou Tao.

7) Fix BPF verifier to not mark fentry/fexit pr...
      d6dc62fc
    • Vladimir Oltean's avatar
      Revert "net: stmmac: use sysfs_streq() instead of strncmp()" · 469d258d
      Vladimir Oltean authored 
      This reverts commit f72cd76b.
This patch is so broken, it hurts. Apparently no one reviewed it and it
passed the build testing (because the code was compiled out), but it was
obviously never compile-tested, since it produces the following build
error, due to an incomplete conversion where an extra argument was left,
although the function being called was left:

stmmac_main.c: In function ‘stmmac_cmdline_opt’:
stmmac_main.c:7586:28: error: too many arguments to function ‘sysfs_streq’
 7586 |                 } else if (sysfs_streq(opt, "pause:", 6)) {
      |                            ^~~~~~~~~~~
In file included from ../include/linux/bitmap.h:11,
                 from ../include/linux/cpumask.h:12,
                 from ../include/linux/smp.h:13,
                 from ../include/linux/lockdep.h:14,
                 from ../include/linux/mutex.h:17,
                 from ../include/linux/notifier.h:14,
                 from ../include/linux/clk.h:14,
                 from ../drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:17:
../include/linux/string.h:185:13: note: declared here
  185 | extern bool sysfs_streq(const char *s1, const char *s2);
      |             ^~~~~~~~~~~

What's even worse is that the patch is flat out wrong. The stmmac_cmdline_opt()
function does not parse sysfs input, but cmdline input such as
"stmmaceth=tc:1,pause:1". The pattern of using strsep() followed by
strncmp() for such strings is not unique to stmmac, it can also be found
mainly in drivers under drivers/video/fbdev/.

With strncmp("tc:", 3), the code matches on the "tc:1" token properly.
With sysfs_streq("tc:"), it doesn't.

Fixes: f72cd76b

 ("net: stmmac: use sysfs_streq() instead of strncmp()")
Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: default avatarMaciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/r/20221125105304.3012153-1-vladimir.oltean@nxp.com


Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      469d258d
    • Davide Tronchin's avatar
      net: usb: cdc_ether: add u-blox 0x1343 composition · 2816c986
      Davide Tronchin authored 
      

Add CDC-ECM support for LARA-L6.

LARA-L6 module can be configured (by AT interface) in three different
USB modes:
* Default mode (Vendor ID: 0x1546 Product ID: 0x1341) with 4 serial
interfaces
* RmNet mode (Vendor ID: 0x1546 Product ID: 0x1342) with 4 serial
interfaces and 1 RmNet virtual network interface
* CDC-ECM mode (Vendor ID: 0x1546 Product ID: 0x1343) with 4 serial
interface and 1 CDC-ECM virtual network interface

In CDC-ECM mode LARA-L6 exposes the following interfaces:
If 0: Diagnostic
If 1: AT parser
If 2: AT parser
If 3: AT parset/alternative functions
If 4: CDC-ECM interface

Signed-off-by: default avatarDavide Tronchin <davide.tronchin.94@gmail.com>
Link: https://lore.kernel.org/r/20221124112811.3548-1-davide.tronchin.94@gmail.com


Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2816c986
  3. Nov 28, 2022
  5. Nov 25, 2022