* [PATCH v8 2/9] dt-bindings: net: wireless: qcom,ath10k: Document NVMEM cells
From: Loic Poulain @ 2026-07-03 13:45 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan, Christian Marangi
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain, Bartosz Golaszewski, Krzysztof Kozlowski
In-Reply-To: <20260703-block-as-nvmem-v8-0-98ae32bfc49a@oss.qualcomm.com>
Document the NVMEM cells supported by the ath10k driver, the
mac-address, pre-calibration data, and calibration data.
Since such data may also originate from chipset OTP or be supplied
via other device tree structures. All of these cells are optional
and can be provided independently, in any combination.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
.../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
index c21d66c7cd558ab792524be9afec8b79272d1c87..878c5d833a9cb073520c256c1b72d0f1489e7f4a 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
@@ -92,6 +92,22 @@ properties:
ieee80211-freq-limit: true
+ nvmem-cells:
+ minItems: 1
+ maxItems: 3
+ description:
+ References to nvmem cells for MAC address and/or calibration data.
+ Supported cell names are mac-address, calibration, and pre-calibration.
+
+ nvmem-cell-names:
+ minItems: 1
+ maxItems: 3
+ items:
+ enum:
+ - mac-address
+ - calibration
+ - pre-calibration
+
qcom,calibration-data:
$ref: /schemas/types.yaml#/definitions/uint8-array
description:
--
2.34.1
^ permalink raw reply related
* [PATCH v8 1/9] dt-bindings: mmc: Document fixed-layout NVMEM provider support
From: Loic Poulain @ 2026-07-03 13:45 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan, Christian Marangi
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260703-block-as-nvmem-v8-0-98ae32bfc49a@oss.qualcomm.com>
Allow an eMMC hardware partition node to describe an NVMEM layout so the
partition can be exposed as an NVMEM provider. This lets a partition
(e.g. an eMMC boot partition) store device-specific information such as a
WiFi MAC address or a Bluetooth BD address and reference it through NVMEM
cells.
Accept "fixed-layout" as the partition node compatible, in addition to
"fixed-partitions", so the layout can be described directly on the
partition node.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
.../devicetree/bindings/mmc/mmc-card.yaml | 23 +++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
index a61d6c96df759102f9c1fbfd548b026a77921cae..0422894508478c8d0ca68292b58a5fdbee218358 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
@@ -38,7 +38,9 @@ patternProperties:
properties:
compatible:
contains:
- const: fixed-partitions
+ enum:
+ - fixed-partitions
+ - fixed-layout
required:
- compatible
@@ -86,6 +88,25 @@ examples:
read-only;
};
};
+
+ partitions-boot2 {
+ compatible = "fixed-layout";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mac-addr@4400 {
+ compatible = "mac-base";
+ reg = <0x4400 0x6>;
+ #nvmem-cell-cells = <1>;
+ };
+
+ bd-addr@5400 {
+ compatible = "mac-base";
+ reg = <0x5400 0x6>;
+ #nvmem-cell-cells = <1>;
+ };
+ };
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v8 0/9] Support for block device NVMEM providers
From: Loic Poulain @ 2026-07-03 13:45 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan, Christian Marangi
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain, Bartosz Golaszewski, Krzysztof Kozlowski,
Piotr Kwapulinski, Konrad Dybcio
On embedded devices, it is common for factory provisioning to store
device-specific information, such as Ethernet or WiFi MAC addresses,
in a dedicated area of an eMMC partition. This avoids the need for
and additional EEPROM/OTP and leverages the persistence of eMMC.
One example is the Arduino UNO-Q, where the WiFi MAC address and the
Bluetooth Device address are stored in the eMMC Boot1 partition.
Until now, accessing this information required a custom bootloader
to read the data and inject it into the Device Tree before handing
control over to the kernel. This approach is fragile and leads to
device-specific workarounds.
Rather than adding a new NVMEM provider specifically to the eMMC
subsystem, the new support operates at the block layer, allowing any
block device to behave like other non-volatile memories such as EEPROM
or OTP.
This series builds on earlier work by Daniel Golle that enables block
devices to act as NVMEM providers:
https://lore.kernel.org/all/6061aa4201030b9bb2f8d03ef32a564fdb786ed1.1709667858.git.daniel@makrotopia.org/
It also introduces an NVMEM layout description for the Arduino UNO-Q,
allowing device-specific data stored in the eMMC Boot1 partition to
be accessed in a standard way.
WiFi and Ethernet already support retrieving MAC addresses from NVMEM.
Bluetooth requires similar support, which is also addressed.
Note that this is currently limited to MMC-backed block devices, as
only the MMC core associates a firmware node with the block device
(add_disk_fwnode). This can be easily extended in the future to
support additional block drivers.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
Changes in v8:
- block: Fix bdev->bd_nvmem on registering failure (sashiko)
- net: of_net: of_get_nvmem_eui48() now also rejects all-ones cells (sashiko)
- Bluetooth: mgmt: account for HCI_QUIRK_USE_BDADDR_NVMEM in
is_configured() and get_missing_options() (sashiko)
- Reword blk-nvmem KCONFIG help text to satisfy checkpatch
- Link to v7: https://lore.kernel.org/r/20260701-block-as-nvmem-v7-0-3fe8205ef0a8@oss.qualcomm.com
Changes in v7:
- Rework bindings/dts so that the eMMC boot partition can be a nvmem fixed-layout
and not a child of fixed-partition. (Rob)
- Add Support for fixed-layout as the nvmem device node itself
- Remove "block: partitions: of: Skip child nodes without reg property"
This is no more required in this series and will be submitted separately (Rob)
- Add missing linux/cleanup.h and linux/device.h includes (Bartosz)
- simplify nvmem_register() error path using dev_err_probe() (Bartosz)
- nvmem_device forward declaration to blk_types.h (Bartosz)
- Add hci_dev_get_bd_addr_from_nvmem() kernel-doc for return value (Piotr)
- Link to v6: https://lore.kernel.org/r/20260629-block-as-nvmem-v6-0-f02513dcd46d@oss.qualcomm.com
Changes in v6:
- blk_nvmem_add() returns int, error properly propagated (Bartosz)
- Redundant if (bdev->bd_nvmem) guard removed in blk_nvmem_del() (Bartosz)
- Size guard changed from UINT_MAX → INT_MAX to avoid signed overflow in config.size (sashiko)
- BLK_OPEN_RESTRICT_WRITES removed from blk_nvmem_reg_read() (sashiko)
- Link to v5: https://lore.kernel.org/r/20260612-block-as-nvmem-v5-0-95e0b30fff90@oss.qualcomm.com
Changes in v5:
- Fixed ath10k binding issue + extended commit message (Krzysztof)
- Moved blk-nvmem handling to block core instead of a class_interface
This allows correct/robust integration with block device life cycle (Bartosz).
- block: partitions: of: Skip child nodes without reg property (sashiko)
- Link to v4: https://lore.kernel.org/r/20260609-block-as-nvmem-v4-0-45712e6b22c6@oss.qualcomm.com
Changes in v4:
- Fix squash issue (dts commit incorrectly squashed) (Konrad)
- Use devres for nvmem resources (Bartosz)
- use __free() destructor helper when possible (Bartosz)
- Fix value return checking for bdev_file_open_by_dev
- Link to v3: https://lore.kernel.org/r/20260608-block-as-nvmem-v3-0-82681f50aa35@oss.qualcomm.com
Changes in v3:
- Fixed missing 'fixed-partitions' compatible in partition (Rob)
- Fixed clashing nvmem cells, document calibration along mac (Sashiko)
- Remove workaround to handle dangling nvmem references after
unregistering, this is a generic nvmem framework issue handled
in Bartosz's series:
https://lore.kernel.org/all/20260429-nvmem-unbind-v3-0-2a694f95395b@oss.qualcomm.com/
- Validate mac (is_valid_ether_addr) before copying to output buffer
- Link to v2: https://lore.kernel.org/r/20260507-block-as-nvmem-v2-0-bf17edd5134e@oss.qualcomm.com
Changes in v2:
- Fix example nvmem-layout cells to use compatible = "mac-base"
- Squash WiFi MAC and Bluetooth BD address consumer patches into the nvmem layout patch
- Fix possible use-after-free in blk-nvmem: bnv (nvmem priv) linked to nvmem lifetime
- Simplify nvmem-cell-names from items: - const: to plain const:
- Factor out common NVMEM EUI-48 retrieval logic
- Reorder changes
- Link to v1: https://lore.kernel.org/r/20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com
---
Daniel Golle (1):
block: implement NVMEM provider
Loic Poulain (8):
dt-bindings: mmc: Document fixed-layout NVMEM provider support
dt-bindings: net: wireless: qcom,ath10k: Document NVMEM cells
dt-bindings: bluetooth: qcom: Add NVMEM BD address cell
nvmem: layouts: Support fixed-layout as the nvmem device node itself
net: of_net: Add of_get_nvmem_eui48() helper for EUI-48 lookup
Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
Bluetooth: qca: Set NVMEM BD address quirks when address is invalid
arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses
.../devicetree/bindings/mmc/mmc-card.yaml | 23 ++++-
.../net/bluetooth/qcom,bluetooth-common.yaml | 9 ++
.../bindings/net/wireless/qcom,ath10k.yaml | 16 +++
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 32 ++++++
block/Kconfig | 11 +++
block/Makefile | 1 +
block/blk-nvmem.c | 110 +++++++++++++++++++++
block/blk.h | 8 ++
block/genhd.c | 4 +
drivers/bluetooth/btqca.c | 5 +-
drivers/nvmem/layouts.c | 13 ++-
include/linux/blk_types.h | 4 +
include/linux/of_net.h | 7 ++
include/net/bluetooth/hci.h | 18 ++++
net/bluetooth/hci_sync.c | 41 +++++++-
net/bluetooth/mgmt.c | 6 +-
net/core/of_net.c | 52 +++++++---
17 files changed, 342 insertions(+), 18 deletions(-)
---
base-commit: dffcfe75c722be66aa2669fb335528edb0590671
change-id: 20260428-block-as-nvmem-4b308e8bda9a
Best regards,
--
Loic Poulain <loic.poulain@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 ethtool] man: ethtool: link 10000baseCR to SFF-8431, Appendix-E SFP+ DA
From: Maxime Chevallier @ 2026-07-03 13:41 UTC (permalink / raw)
To: Siddaraju DH, Michal Kubecek, Andrew Lunn, netdev
Cc: Shubham Das, Balaji Chintalapalle, Vijay Srinivasan,
Magnus Lindberg, Niklas Damberg, Jonas Wirandi, Siddaraju DH
In-Reply-To: <20260703102004.1111597-1-siddaraju.dh@intel.com>
Hi,
On 7/3/26 12:20, Siddaraju DH wrote:
> Annotate the 10000baseCR entry in the advertise mask table so users
> understand what physical media this mode it actually represents.
>
> 10000baseCR does not correspond to any IEEE 802.3 *base-CR PMD.
> It has no autonegotiation, no link training, and no mandatory FEC.
> The industry standard for this media type is SFF-8431 Appendix-E
> Direct Attach cable, also known as 10G_SFI_DA.
>
> Link: https://lore.kernel.org/r/SN7PR11MB69003D33489DB1D6B17EF72A9AF52@SN7PR11MB6900.namprd11.prod.outlook.com
>
> Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Looks like you're missing Andrew's review tag :(
Maxime
^ permalink raw reply
* RE: [PATCH net-next 09/17] net: dsa: mv88e6xxx: Get Product ID when enabling RMU
From: Jagielski, Jedrzej @ 2026-07-03 13:38 UTC (permalink / raw)
To: Luke Howard, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Russell King, Richard Cochran, Florian Fainelli
Cc: Cedric Jehasse, Max Holtmann, Max Hunter, Tyrrell, Kieran,
Ryan Wilkins, Mattias Forsblad, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260703-net-next-mv88e6xxx-rmu-v1-9-991a27d78bca@padl.com>
From: Luke Howard <lukeh@padl.com>
Sent: Friday, July 3, 2026 9:47 AM
>
>From: Andrew Lunn <andrew@lunn.ch>
>
>When the RMU is enabled, it is recommended to get the product ID,
>which identifies the switch. This is used as a test that communication
>with the switch actually works and the RMU can be used. If successful,
>mark the RMU usable.
>
>This completes the general infrastructure to send a request and
>process the response.
>
>Co-developed: Mattias Forsblad <mattias.forsblad@gmail.com>
>Signed-off-by: Mattias Forsblad <mattias.forsblad@gmail.com>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>Signed-off-by: Luke Howard <lukeh@padl.com>
>---
> drivers/net/dsa/mv88e6xxx/chip.h | 10 +++
> drivers/net/dsa/mv88e6xxx/rmu.c | 151 ++++++++++++++++++++++++++++++++++++++-
> drivers/net/dsa/mv88e6xxx/rmu.h | 11 +++
> 3 files changed, 170 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
>index 940ae698659fc..07300c25cbd36 100644
>--- a/drivers/net/dsa/mv88e6xxx/chip.h
>+++ b/drivers/net/dsa/mv88e6xxx/chip.h
>@@ -346,6 +346,15 @@ struct mv88e6xxx_tcam {
> struct list_head entries;
> };
>
>+enum mv88e6xxx_rmu_state {
>+ MV88E6XXX_RMU_DISABLED = 0,
>+ MV88E6XXX_RMU_ENABLED = 1,
>+ /* Reserved: a future RMU-only mode (e.g. MV88E6XXX_RMU_ONLY_ENABLED)
>+ * may be added here to indicate a switch operating purely via RMU
>+ * without an MDIO bus.
>+ */
As from what i see it's not being extended within the series, can we drop
that comment and use simple bool enabled/disabled in the place of
mv88e6xxx_rmu_state?
or am I missing something and > 2 states are needed
...
>+ return dsa_inband_request(&chip->rmu_inband, skb,
>+ (edsa ? mv88e6xxx_rmu_fill_seqno_edsa :
>+ mv88e6xxx_rmu_fill_seqno_dsa),
>+ resp, resp_len, timeout_ms);
>+}
>+
>+static int mv88e6xxx_rmu_get_id(struct mv88e6xxx_chip *chip)
>+{
>+ const __be16 req[4] = {
>+ MV88E6XXX_RMU_REQ_FORMAT_GET_ID,
>+ MV88E6XXX_RMU_REQ_PAD,
>+ MV88E6XXX_RMU_REQ_CODE_GET_ID,
>+ MV88E6XXX_RMU_REQ_DATA};
>+ struct mv88e6xxx_rmu_header resp;
>+ int resp_len;
>+ int ret = -1;
no need to init
>+
>+ resp_len = sizeof(resp);
>+ ret = mv88e6xxx_rmu_request(chip, req, sizeof(req),
^ permalink raw reply
* Re: [RFC] connectat()/bindat() or an alternative design
From: Christian Brauner @ 2026-07-03 13:35 UTC (permalink / raw)
To: John Ericson
Cc: Cong Wang, Li Chen, Andy Lutomirski, Jens Axboe, network dev,
linux-fsdevel
In-Reply-To: <e396ce86-ec84-4189-9da2-98af7cfa6c41@app.fastmail.com>
On Tue, Jun 30, 2026 at 04:22:25PM -0400, John Ericson wrote:
> I'm bumping this and adding new recipients again in light of the
> discussion happening elsewhere in
> <https://lore.kernel.org/all/a49ce818-f38d-41b0-bbf7-80b8aad998b1@app.fastmail.com/>.
> I don't want to count my chickens before they are hatched, but it is
> looking to me like a consensus in that thread is building around the
> ability to opt into intentionally empty/unusable root and working
> directories (at least with nullfs, maybe but less likely with other
> mechanisms instead).
>
> That new functionality concretizes the motivation for what I am
> proposing in this thread: in such a world, there is little to no point
> binding listening sockets in the file system, because the containing
> directory would have to be conveyed by file descriptor anyways --- might
> as well just directly convey the socket to connect to by file
> descriptor. Likewise, abstract sockets are not appealing, because the
> abstract socket namespace is either too coarse-grained (leaking info in
> the same way root/cwd would), or too cumbersome to keep it from leaking.
>
> To recap (with some slight changes, like renames), my latest proposal (a
> new version, not either of the two variations in the original email) is
> new syscalls `bind_unix_anon` and `connectat`, supporting a workflow
> like this:
Please stop sending a bunch of disparate patch series that all do
slightly related or overlapping things and point back at each other.
It's completely impossible to follow for anyone what's going on without
chasing down discussion state across multiple subsystems. The net people
have zero insight onto the fs struct discussions and it's completely
pointless to try and design all of this based on thin air. Nothing is
locked-in yet. This is not how this goes.
This frantic pushing of various features doesn't scale. It is requesting
costly review time for multiple RFC series.
^ permalink raw reply
* Re: [PATCH iwl] ice: acquire NVM lock around each flash read
From: Przemek Kitszel @ 2026-07-03 13:34 UTC (permalink / raw)
To: Robert Malz
Cc: intel-wired-lan, netdev, linux-kernel, Tony Nguyen, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexander Lobakin, Jacob Keller, Jesse Brandeburg
In-Reply-To: <20260703103245.374800-1-robert.malz@canonical.com>
On 7/3/26 12:32, Robert Malz wrote:
> FW caps the NVM read lock at a maximum of 3000ms regardless of the timeout
> requested via ice_acquire_nvm(). ice_read_flat_nvm() splits a read into
> multiple ice_aq_read_nvm() commands, one per 4KB sector, all issued under a
> single lock taken by the caller. Reading a large region can exceed 3000ms,
> so FW reclaims the lock mid-read and the remaining commands might fail.
>
> Move the lock acquire/release into ice_read_flat_nvm() so it brackets each
> individual ice_aq_read_nvm() command, ensuring the lock is never held
> across more than one FW read. ice_release_nvm() issues its own AQ command
> and would overwrite sq_last_status, so the read's AQ error is preserved
> across the release for callers such as ice_discover_flash_size() that
> inspect it.
>
> Callers that previously took the lock around ice_read_flat_nvm(),
> ice_read_sr_word() or ice_read_flash_module() now call them without it.
> The per-block locking in ice_devlink_nvm_snapshot() is now redundant
> and dropped.
>
> Fixes: e94509906d6b ("ice: create function to read a section of the NVM and Shadow RAM")
> Signed-off-by: Robert Malz <robert.malz@canonical.com>
thank you for extra effort [1]
current fix looks elegant!
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
[1] for reference, this is previous attempt for the fix:
https://lore.kernel.org/intel-wired-lan/CADcc-bysA531q2Wh=TD_oFqxivLLdnCRNY5jy7mkZuO0cwJwvg@mail.gmail.com
[...]
> /**
> - * ice_read_sr_word - Reads Shadow RAM word and acquire NVM if necessary
> + * ice_read_sr_word - Reads Shadow RAM word
> * @hw: pointer to the HW structure
> * @offset: offset of the Shadow RAM word to read (0x000000 - 0x001FFF)
> * @data: word read from the Shadow RAM
> *
> - * Reads one 16 bit word from the Shadow RAM using the ice_read_sr_word_aq.
> + * Reads one 16 bit word from the Shadow RAM using ice_read_sr_word_aq.
> + *
> + * The NVM lock is acquired and released internally by ice_read_flat_nvm()
> + * around the FW read, so this function must be called without the lock held.
> */
for future submissions would be great to "fix" kdoc warnings of touched
functions, here "Return: " section is missing.
I do not ask to fix this particular one (given there will be no ask for
v2 otherwise).
> int ice_read_sr_word(struct ice_hw *hw, u16 offset, u16 *data)
> {
^ permalink raw reply
* Re: [PATCH net-next v2 5/5] net: dsa: realtek: rtl8366rb: Switch to generic learning enablement
From: Luiz Angelo Daros de Luca @ 2026-07-03 13:31 UTC (permalink / raw)
To: Linus Walleij
Cc: Alvin Šipraga, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <20260630-rtl8366rb-improvements-v2-5-05eb9d6a37f5@kernel.org>
> Instead of just writing the learning disablement register in setup
> and a custom handling of BR_LEARNING, implement the generic RTL83xx
> .port_set_learning() callback for setting learning on a port, and
> call this in the per-port loop in .setup().
>
> Instead of the custom rtl83366rb_port_bridge_flags() function for
> setting learning mode on each port, use the RTL83xx generic
> rtl83xx_port_bridge_flags() callback.
>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
^ permalink raw reply
* RE: [PATCH net-next 07/17] net: dsa: mv88e6xxx: Add connect_tag_protocol handler
From: Jagielski, Jedrzej @ 2026-07-03 13:25 UTC (permalink / raw)
To: Luke Howard, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Russell King, Richard Cochran, Florian Fainelli
Cc: Cedric Jehasse, Max Holtmann, Max Hunter, Tyrrell, Kieran,
Ryan Wilkins, Mattias Forsblad, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260703-net-next-mv88e6xxx-rmu-v1-7-991a27d78bca@padl.com>
From: Luke Howard <lukeh@padl.com>
Sent: Friday, July 3, 2026 9:47 AM
>From: Andrew Lunn <andrew@lunn.ch>
>
>When the tagging protocol handler is attached to the DSA driver, it
>can validate it is a supported tagging protocol. It can also setup
>data shared between the tagger and the switch driver. Ensure a Mavell
s/Mavell/Marvell ?
>DSA tagger is being connected, and setup the handler from RMU in the
>shared data. At this point, the handler is just an empty stub, but
>later patches will add the needed functionality.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>---
> drivers/net/dsa/mv88e6xxx/chip.c | 18 ++++++++++++++++++
> drivers/net/dsa/mv88e6xxx/rmu.c | 6 ++++++
> drivers/net/dsa/mv88e6xxx/rmu.h | 3 +++
> 3 files changed, 27 insertions(+)
>
>diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
>index 72c93cb84b7e1..fe0d0eb8f0813 100644
>--- a/drivers/net/dsa/mv88e6xxx/chip.c
>+++ b/drivers/net/dsa/mv88e6xxx/chip.c
>@@ -7183,6 +7183,23 @@ static int mv88e6xxx_crosschip_lag_leave(struct dsa_switch *ds, int sw_index,
> return err_sync ? : err_pvt;
> }
>
>+static int mv88e6xxx_connect_tag_protocol(struct dsa_switch *ds,
>+ enum dsa_tag_protocol proto)
>+{
>+ struct dsa_tagger_data *tagger_data = ds->tagger_data;
>+
>+ switch (proto) {
>+ case DSA_TAG_PROTO_DSA:
>+ case DSA_TAG_PROTO_EDSA:
>+ tagger_data->rmu_frame2reg = mv88e6xxx_rmu_frame2reg_handler;
>+ break;
>+ default:
>+ return -EPROTONOSUPPORT;
>+ }
do we really need to use switch for 0/1 cases?
>+
>+ return 0;
>+}
>+
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net: dsa: realtek: rtl8366rb: Switch to generic port_bridge* handlers
From: Luiz Angelo Daros de Luca @ 2026-07-03 13:24 UTC (permalink / raw)
To: Linus Walleij
Cc: Alvin Šipraga, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <20260630-rtl8366rb-improvements-v2-2-05eb9d6a37f5@kernel.org>
> +static int rtl8366rb_port_set_isolation(struct realtek_priv *priv, int port,
> + u32 mask)
> +{
> + /* Bit 0 enables isolation so set this if we enable isolation
> + * any of the ports an clear it if we disable on all of them.
> + */
> + if (mask)
> + mask = RTL8366RB_PORT_ISO_PORTS(mask) | RTL8366RB_PORT_ISO_EN;
> +
> + return regmap_write(priv->map, RTL8366RB_PORT_ISO(port),
> + mask);
> +}
As sashiko pointed out, set_insolation(...,0) actually disables it
instead of completely isolating it.
I would unconditionally isolate the ports as we will never need to disable it.
Regards,
Luiz
^ permalink raw reply
* RE: [PATCH net-next 05/17] net: dsa: mv88e6xxx: Add conduit state change handler
From: Jagielski, Jedrzej @ 2026-07-03 13:17 UTC (permalink / raw)
To: Luke Howard, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Russell King, Richard Cochran, Florian Fainelli
Cc: Cedric Jehasse, Max Holtmann, Max Hunter, Tyrrell, Kieran,
Ryan Wilkins, Mattias Forsblad, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260703-net-next-mv88e6xxx-rmu-v1-5-991a27d78bca@padl.com>
From: Luke Howard <lukeh@padl.com>
Sent: Friday, July 3, 2026 9:47 AM
>From: Andrew Lunn <andrew@lunn.ch>
>
>When the conduit interface comes up, try to enable the RMU. Failing to
>enable the remote management unit is not fatal, not all chips support
>it, and some boards have chips which do support RMU, but with wrong
>port is connected to the CPU.
>
>When the conduit interface goes down, disable the RMU.
>
>Keep track of the conduit interface, so that RMU frames can be sent to
>it.
>
>Co-developed: Mattias Forsblad <mattias.forsblad@gmail.com>
>Signed-off-by: Mattias Forsblad <mattias.forsblad@gmail.com>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
...
>+++ b/drivers/net/dsa/mv88e6xxx/rmu.c
>@@ -0,0 +1,50 @@
>+// SPDX-License-Identifier: GPL-2.0-or-later
>+/*
>+ * Marvell 88E6xxx Switch Remote Management Unit Support
>+ *
>+ * Copyright (c) 2022 Mattias Forsblad <mattias.forsblad@gmail.com>
shouldn't present year be put here?
>+ *
>+ */
>+
>+#include <net/dsa.h>
>+#include "chip.h"
>+#include "global1.h"
>+#include "rmu.h"
>+
>+void mv88e6xxx_rmu_conduit_state_change(struct dsa_switch *ds,
>+ const struct net_device *conduit,
>+ bool operational)
>+{
>+ struct dsa_port *cpu_dp = conduit->dsa_ptr;
>+ struct mv88e6xxx_chip *chip = ds->priv;
>+ int port;
>+ int ret;
could be squashed
>+
>+ port = dsa_towards_port(ds, cpu_dp->ds->index, cpu_dp->index);
>+
>+ mv88e6xxx_reg_lock(chip);
>+
>+ if (operational && chip->info->ops->rmu_enable) {
>+ ret = chip->info->ops->rmu_enable(chip, port);
>+ if (ret == -EOPNOTSUPP) {
>+ dev_info(chip->dev, "RMU: not usable on this board");
do this case really needs to be treated different way if the general
case already prints error code?
>+ goto out;
>+ } else if (ret < 0) {
>+ dev_err(chip->dev, "RMU: unable to enable on port %d %pe",
>+ port, ERR_PTR(ret));
>+ goto out;
>+ }
>+
>+ WRITE_ONCE(chip->rmu_conduit, (struct net_device *)conduit);
>+
>+ dev_dbg(chip->dev, "RMU: Enabled on port %d", port);
>+ } else {
>+ if (chip->info->ops->rmu_disable)
>+ chip->info->ops->rmu_disable(chip);
>+
>+ WRITE_ONCE(chip->rmu_conduit, NULL);
>+ }
>+
>+out:
>+ mv88e6xxx_reg_unlock(chip);
>+}
>diff --git a/drivers/net/dsa/mv88e6xxx/rmu.h b/drivers/net/dsa/mv88e6xxx/rmu.h
>new file mode 100644
>index 0000000000000..71c4fc1d4113f
>--- /dev/null
>+++ b/drivers/net/dsa/mv88e6xxx/rmu.h
>@@ -0,0 +1,15 @@
>+/* SPDX-License-Identifier: GPL-2.0+ */
>+/*
>+ * Marvell 88E6xxx Switch Remote Management Unit Support
>+ *
>+ * Copyright (c) 2022 Mattias Forsblad <mattias.forsblad@gmail.com>
>+ *
>+ */
>+
>+#ifndef _MV88E6XXX_RMU_H_
>+#define _MV88E6XXX_RMU_H_
>+
>+void mv88e6xxx_rmu_conduit_state_change(struct dsa_switch *ds,
>+ const struct net_device *conduit,
>+ bool operational);
>+#endif /* _MV88E6XXX_RMU_H_ */
>
>--
>2.43.0
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] af_unix: Clean up error handling in unix_listen()
From: Christian Brauner @ 2026-07-03 13:17 UTC (permalink / raw)
To: John Ericson
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Kuniyuki Iwashima, John Ericson, Simon Horman, Christian Brauner,
David Rheinsberg, Cong Wang, Sergei Zimmerman, netdev,
linux-kernel
In-Reply-To: <20260703081416.2583118-3-John.Ericson@Obsidian.Systems>
> To avoid the sort of bug that was just fixed going forward, switch to a
> style where `err = -E...;` instead happens right before the `goto`.
> (`err = other_function(...);` is not changed.) Then there is no
> spooky-action-at-a-distance between the `err` initialization and the
> `goto`, something which is easier to slip by code review.
>
> Signed-off-by: John Ericson <mail@johnericson.me>
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
--
Christian Brauner <brauner@kernel.org>
^ permalink raw reply
* Re: [PATCH net v2 2/3] selftests/net/af_unix: test listen() rejects wrong socket states
From: Christian Brauner @ 2026-07-03 13:17 UTC (permalink / raw)
To: John Ericson
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Kuniyuki Iwashima, John Ericson, Simon Horman, Christian Brauner,
David Rheinsberg, Cong Wang, Sergei Zimmerman, netdev,
linux-kernel
In-Reply-To: <20260703081416.2583118-2-John.Ericson@Obsidian.Systems>
> Add a regression test for the `unix_listen()` state check. The key case
> is `listen()` on a bound socket that has already been connected: it is
> no longer in `TCP_CLOSE` or `TCP_LISTEN`, so it must fail with `EINVAL`.
> A `prepare_peercred()` call slipped in ahead of that check once left
> `err` at 0 and made `listen()` silently succeed there instead; this
> guards against a repeat.
>
> The neighbouring outcomes are covered too so they cannot regress the
> same way: a bound socket in `TCP_CLOSE` listens fine, re-`listen()`ing a
> socket already in `TCP_LISTEN` is allowed, and an unbound socket fails
> with `EINVAL`.
>
> Fixes: fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid")
> Signed-off-by: John Ericson <mail@johnericson.me>
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
--
Christian Brauner <brauner@kernel.org>
^ permalink raw reply
* Re: [PATCH net v2 1/3] af_unix: fix listen() succeeding on sockets in the wrong state
From: Christian Brauner @ 2026-07-03 13:17 UTC (permalink / raw)
To: John Ericson
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Kuniyuki Iwashima, John Ericson, Simon Horman, Christian Brauner,
David Rheinsberg, Cong Wang, Sergei Zimmerman, netdev,
linux-kernel
In-Reply-To: <20260703081416.2583118-1-John.Ericson@Obsidian.Systems>
> Commit fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for
> reaped sk->sk_peer_pid") inserted a `prepare_peercred()` call between
> `err = -EINVAL` and the socket-state check in `unix_listen()`. Since
> `prepare_peercred()` leaves `err` at 0 on success, `listen()` on an
> AF_UNIX socket that is not in `TCP_CLOSE` or `TCP_LISTEN` state (e.g.
> one that is already connected) now silently returns success without
> doing anything, instead of failing with `EINVAL` as it did before.
>
> Fixes: fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid")
> Signed-off-by: John Ericson <mail@johnericson.me>
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
--
Christian Brauner <brauner@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support
From: Andrew Lunn @ 2026-07-03 13:15 UTC (permalink / raw)
To: Nazle Asmade, Muhammad Nazim Amirul
Cc: dinguyen@kernel.org, maxime.chevallier@bootlin.com,
rmk+kernel@armlinux.org.uk, krzk+dt@kernel.org,
conor+dt@kernel.org, robh@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
andrew+netdev@lunn.ch, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <f31704f2-cd98-481f-8290-203e3052b738@altera.com>
> > I don't actually see a need for mac-mode. From what you are saying,
> > there is no choice. The MAC is hard wired to the converter block. So
> > you can just look at the compatible. You are going to need to use the
> > compatible anyway, to mask the phy-mode to handle the "MAC" doing the
> > RGMII delays.
> >
> > Andrew
> >
> Hi Maxime, Andrew
>
> Thanks for the reviews!
>
> Hi Andrew,
>
> The challenge with using compatible is that the TSN Config2 board has
> two ports — only gmac1 uses the GMII-to-RGMII converter, while gmac2
> connects directly to its PHY.
The two MACs are not compatible then, and each should have its own
compatible string. This is all in the SoC .dtsi file, so not really a
problem.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net: dsa: realtek: rtl8366rb: Switch to generic port_bridge* handlers
From: Luiz Angelo Daros de Luca @ 2026-07-03 13:15 UTC (permalink / raw)
To: Linus Walleij
Cc: Alvin Šipraga, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <20260630-rtl8366rb-improvements-v2-2-05eb9d6a37f5@kernel.org>
Em ter., 30 de jun. de 2026 às 08:19, Linus Walleij
<linusw@kernel.org> escreveu:
>
> The RTL8366RB is using its own sub-standard port isolation code.
>
> Implement the required isolation helpers, use these directly in
> the port setup callback, and switch over to the standard port
> isolation code.
>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v2 1/5] net: dsa: realtek: rtl83xx: Make learning optional in join/leave
From: Luiz Angelo Daros de Luca @ 2026-07-03 13:13 UTC (permalink / raw)
To: Linus Walleij
Cc: Alvin Šipraga, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <20260630-rtl8366rb-improvements-v2-1-05eb9d6a37f5@kernel.org>
> Mostly to make it possible to add rtl83xx support piece by piece,
> make the port learning callback optional in rtl83xx_port_bridge_join()
> and rtl83xx_port_bridge_leave().
>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
I know it was already merged. Anyway
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board
From: Andrew Lunn @ 2026-07-03 13:12 UTC (permalink / raw)
To: Nazle Asmade, Muhammad Nazim Amirul
Cc: dinguyen@kernel.org, maxime.chevallier@bootlin.com,
rmk+kernel@armlinux.org.uk, krzk+dt@kernel.org,
conor+dt@kernel.org, robh@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
andrew+netdev@lunn.ch, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <b8ca3bd8-af8f-43e7-904c-1ac45512296b@altera.com>
> >> The delays are provided by the FPGA GMII-to-RGMII converter soft IP,
> >> which is hardcoded in the FPGA bitstream and cannot be disabled or
> >> modified from the driver side.
> >>
> >> Using phy-mode = "rgmii" is intentional here — it prevents the PHY from
> >> adding its own internal delays on top, since the FPGA converter already
> >> provides the full required delay. This is consistent with how all other
> >> Agilex5 SoCDK board variants are described, as seen in commit
> >> c5637e5ceb4b ("arm64: dts: socfpga: agilex5: Fix phy-mode to rgmii as HW
> >> provides clock delay") already in Dinh Nguyen's tree, which applies the
> >> same rationale across all Agilex5 boards.
> >
> > I've become more insistent that designs get this correct. So i don't
> > care too much about past systems. Many vendors are having to fix up
> > their drivers and DT in order to make new boards consistent.
> >
> > You can look at your system as the FPGA being the MAC, and the PHY is
> > the PHY. The PCB is not providing the delay, the MAC is. This exactly
> > fits the description above.
> >
> > Andrew
> Hi Andrew,
>
> Thank you for the clarification. We agree with your framework in
> principle, but would like to explain why phy-mode = "rgmii" is the
> appropriate description for this specific case.
So you want to be different to every other system? Please extend the
text in that document to say that this device is special and has a
different definition of phy-mode to all other systems.
> After getting more information from hw team, for Agilex specific device,
> the RGMII timing delays on this board are provided by an FPGA delay
> chain (Input/Output Delay Chain primitives in the FPGA fabric). The
> reason for using the FPGA rather than the PHY is that the Marvell PHY on
> this board only supports 0ns or 2ns delay steps — too coarse to meet the
> RGMII timing requirements. The FPGA delay chain provides up to 63 steps
> of ~0.1ns precision, which the hardware team has tuned at design time to
> achieve correct signal timing.
As the text says, fine tuning is different. You can have fine tuning,
in both the MAC or PHY, while using either rgmii or rgmii-id.
Also, you cannot fine tune just the MAC, tuning needs to take into
account the PCB design, the length of the clock and data tracks on the
PCB. You can however take into account the difference in timing within
the FPGA.
Or does your FPGA team produce a different bitstream per board design,
after some sort of calibration in order to determine what the PCB
characteristics are?
This however opens up a new possibility. It does sound like you can
produce a new bitstream with the delays set to just the tuning delay,
not the 2ns + tuning? You need to decide if this is simpler than
changing the MAC driver to mask the phy-mode.
> Changing to phy-mode = "rgmii-id" and having
> the driver strip the delay before passing to the PHY would produce the
> same hardware behaviour (PHY adds zero delay), but would add driver
> complexity with no practical benefit, and would misrepresent the FPGA
> delay as a driver-managed MAC delay when it is actually a fixed,
> board-level hardware calibration.
Look at the wording again. It does not say it is driver managed.
# There are a small number of cases where the MAC has hard coded
# delays which cannot be disabled.
This exactly fits your situation.
> Could you advise if you still prefer the rgmii-id approach given this
> constraint?
rgmii-id is the correct value for your PCB design. Please follow what
the text says.
Andrew
^ permalink raw reply
* RE: [PATCH net-next 04/17] net: dsa: mv88e6xxx: Add RMU enable/disable for select switches.
From: Jagielski, Jedrzej @ 2026-07-03 13:07 UTC (permalink / raw)
To: Luke Howard, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Russell King, Richard Cochran, Florian Fainelli
Cc: Cedric Jehasse, Max Holtmann, Max Hunter, Tyrrell, Kieran,
Ryan Wilkins, Mattias Forsblad, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260703-net-next-mv88e6xxx-rmu-v1-4-991a27d78bca@padl.com>
From: Luke Howard <lukeh@padl.com>
Sent: Friday, July 3, 2026 9:47 AM
>From: Mattias Forsblad <mattias.forsblad@gmail.com>
>
>Add RMU enable and disable functionality for some Marvell SOHO
>switches.
>
>Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>Signed-off-by: Mattias Forsblad <mattias.forsblad@gmail.com>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>---
you tag should be the last one
>+int mv88e6085_g1_rmu_enable(struct mv88e6xxx_chip *chip, int port)
>+{
>+ int val = MV88E6352_G1_CTL2_RMU_MODE_DISABLED;
unclear for me why to init it if all allowed scenarios put some values into val?
here and for following
>+
>+ switch (port) {
>+ case 9:
>+ val = MV88E6085_G1_CTL2_RM_ENABLE;
>+ break;
>+ case 10:
>+ val = MV88E6085_G1_CTL2_RM_ENABLE | MV88E6085_G1_CTL2_P10RM;
>+ break;
>+ default:
>+ return -EOPNOTSUPP;
>+ }
>+
>+ return mv88e6xxx_g1_ctl2_mask(chip, MV88E6085_G1_CTL2_P10RM |
>+ MV88E6085_G1_CTL2_RM_ENABLE, val);
>+}
^ permalink raw reply
* RE: [PATCH net-next 03/17] net: dsa: tag_dsa: Add helper to add DSA header to RMU frame
From: Jagielski, Jedrzej @ 2026-07-03 13:06 UTC (permalink / raw)
To: Luke Howard, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Russell King, Richard Cochran, Florian Fainelli
Cc: Cedric Jehasse, Max Holtmann, Max Hunter, Tyrrell, Kieran,
Ryan Wilkins, Mattias Forsblad, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260703-net-next-mv88e6xxx-rmu-v1-3-991a27d78bca@padl.com>
From: Luke Howard <lukeh@padl.com>
Sent: Friday, July 3, 2026 9:47 AM
>From: Andrew Lunn <andrew@lunn.ch>
>
>A RMU frame sent to the switch needs a DSA header. Add a helper to the
>tag driver to add such a header to an skbuff, and provide access to
>the helper via the tagger data structure. This keeps most of the
>details of the DSA header in the tag driver.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
your tag is missing here; please check tags correctness over the whole series
^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Michael Walle @ 2026-07-03 13:05 UTC (permalink / raw)
To: Miquel Raynal, Rob Herring
Cc: Manikandan.M, krzk, pratyush, mwalle, takahiro.kuwano, richard,
vigneshr, krzk+dt, conor+dt, srini, Nicolas.Ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, linux-mtd, devicetree, linux-kernel, linux-arm-kernel,
netdev
In-Reply-To: <8733y0penb.fsf@bootlin.com>
On Fri Jul 3, 2026 at 12:10 PM CEST, Miquel Raynal wrote:
> On 02/07/2026 at 11:37:23 -05, Rob Herring <robh@kernel.org> wrote:
>
>> On Thu, Jul 02, 2026 at 06:55:15AM +0000, Manikandan.M@microchip.com wrote:
>>> Hi Krzysztof,
>>>
>>> On 7/2/26 11:46 AM, Krzysztof Kozlowski wrote:
>>> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>> >
>>> > On Tue, Jun 30, 2026 at 02:54:00PM +0530, Manikandan Muralidharan wrote:
>>> >> Add an optional "sfdp" child node (compatible "jedec,sfdp") that
>>> >> describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its
>>> >
>>> > What is SFDP?
>>> >
>>> SFDP is the Serial Flash Discoverable Parameters -- a JEDEC-standardised
>>> (JESD216) read-only parameter table present in most SPI NOR flashes, the
>>> table contents provide basic information about the flash. There are
>>> standard tables which are specified by the JEDEC standard and there are
>>> vendor tables.
>>
>> Is SFDP present or not discoverable? Or we have a table of discoverable
>> parameters that itself is not discoverable.
>
> SFDP is almost always there. I don't think there are any non SFDP chips
> manufactured today (?).
Oh i bet there are, and IIRC there were some additions lately. Not
sure if the chip was new though.
> The thing is, even if we don't need to define it
> in DT, we might need to point to it in order to extract eg. a unique ID
> or a MAC address through the NVMEM interface.
Exactly. We can detect whether is a SFDP table or not, by trying to
read its signature using the RDSFDP opcode. But as Miquel pointed
out, that's not what this is about. For the nvmem part being useful,
we have to have some node to point to. At the moment, there are
three different kind of NVMEM devices an spi nor flash can create:
- partitions
- factory OTP (i.e. OTP by the flash manufacturer)
- user OTP (i.e. what an OEM could write to)
Now there's a fourth one: SFDP. It can contain vendor specific
tables, which in the mchp case is used to store a mac address,
which is then used for a NIC.
So we somehow has to organize all of them, thus the sfdp node. A
more complete example would be:
flash@0 {
compatible = "jedec,spi-nor";
partitions {
compatible = "fixed-partitions";
partition@0 {
compatible = "nvmem-cells";
};
};
otp-1 {
compatible = "factory-otp";
};
otp-2 {
compatible = "user-otp";
};
sfdp {
compatile = "jedec,sfdp";
};
};
All being NVMEM devices and expose some kind of data used for
drivers.
HTH
-michael
> SFDP is split into several sub-tables, the first one is mandatory, but
> then there are optional tables which can be discovered dynamically.
>
> Thanks,
> Miquèl
^ permalink raw reply
* RE: [PATCH net-next 02/17] net: dsa: mv88e6xxx: Introduce Marvell dsa tagger data operation.
From: Jagielski, Jedrzej @ 2026-07-03 13:04 UTC (permalink / raw)
To: Luke Howard, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Russell King, Richard Cochran, Florian Fainelli
Cc: Cedric Jehasse, Max Holtmann, Max Hunter, Tyrrell, Kieran,
Ryan Wilkins, Mattias Forsblad, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260703-net-next-mv88e6xxx-rmu-v1-2-991a27d78bca@padl.com>
From: Luke Howard <lukeh@padl.com>
Sent: Friday, July 3, 2026 9:47 AM
>From: Mattias Forsblad <mattias.forsblad@gmail.com>
>
>Support connecting Marvell dsa tagger to the switch driver frame2reg
>function to decode received RMU frames.
>
>(Note: during teardown or failed setup, tagger_data may be NULL when
>a late FRAME2REG frame arrives.)
>
>Signed-off-by: Luke Howard <lukeh@padl.com>
>Signed-off-by: Mattias Forsblad <mattias.forsblad@gmail.com>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Hi,
i believe your sob tag should be the last one
^ permalink raw reply
* [PATCH net 9/9] netfilter: xt_connmark: reject invalid shift parameters
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Wyatt Feng <bronzed_45_vested@icloud.com>
Revision 2 of the CONNMARK target accepts user-controlled shift
parameters and applies them to 32-bit mark values in
connmark_tg_shift().
A shift_bits value of 32 or more triggers an undefined-shift bug when
the rule is evaluated. Invalid shift_dir values are also accepted and
silently fall back to the left-shift path.
Reject invalid revision-2 shift parameters in connmark_tg_check() so
malformed rules fail at installation time, before they can reach the
packet path.
Fixes: 472a73e00757 ("netfilter: xt_conntrack: Support bit-shifting for CONNMARK & MARK targets.")
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <dstsmallbird@foxmail.com>
Assisted-by: Codex:GPT-5.4
Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com>
Reviewed-by: Ren Wei <enjou1224z@gmail.com>
Reviewed-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/xt_connmark.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/xt_connmark.c b/net/netfilter/xt_connmark.c
index 4277084de2e7..2cf27f7d59b9 100644
--- a/net/netfilter/xt_connmark.c
+++ b/net/netfilter/xt_connmark.c
@@ -112,6 +112,16 @@ static int connmark_tg_check(const struct xt_tgchk_param *par)
return ret;
}
+static int connmark_tg_check_v2(const struct xt_tgchk_param *par)
+{
+ const struct xt_connmark_tginfo2 *info = par->targinfo;
+
+ if (info->shift_dir > D_SHIFT_RIGHT || info->shift_bits >= 32)
+ return -EINVAL;
+
+ return connmark_tg_check(par);
+}
+
static void connmark_tg_destroy(const struct xt_tgdtor_param *par)
{
nf_ct_netns_put(par->net, par->family);
@@ -162,7 +172,7 @@ static struct xt_target connmark_tg_reg[] __read_mostly = {
.name = "CONNMARK",
.revision = 2,
.family = NFPROTO_IPV4,
- .checkentry = connmark_tg_check,
+ .checkentry = connmark_tg_check_v2,
.target = connmark_tg_v2,
.targetsize = sizeof(struct xt_connmark_tginfo2),
.destroy = connmark_tg_destroy,
@@ -183,7 +193,7 @@ static struct xt_target connmark_tg_reg[] __read_mostly = {
.name = "CONNMARK",
.revision = 2,
.family = NFPROTO_IPV6,
- .checkentry = connmark_tg_check,
+ .checkentry = connmark_tg_check_v2,
.target = connmark_tg_v2,
.targetsize = sizeof(struct xt_connmark_tginfo2),
.destroy = connmark_tg_destroy,
--
2.54.0
^ permalink raw reply related
* [PATCH net 8/9] ipvs: reset full ip_vs_seq structs in ip_vs_conn_new
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Commit 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in
ip_vs_conn_new") changed ip_vs_conn_new() to allocate an ip_vs_conn
object with kmem_cache_alloc(). The function then initializes many
fields explicitly, but only resets in_seq.delta and out_seq.delta in the
two struct ip_vs_seq members.
That leaves init_seq and previous_delta uninitialized. This is normally
harmless while the corresponding IP_VS_CONN_F_IN_SEQ or
IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync
message, however, ip_vs_proc_conn() preserves those flags from
IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits
IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with
SEQ flags set but with the rest of in_seq/out_seq still containing stale
slab data.
When a packet for such a connection is later handled by an IPVS
application helper, vs_fix_seq() and vs_fix_ack_seq() use
previous_delta and init_seq to rewrite TCP sequence numbers. A malformed
sync message can therefore make forwarded packets carry stale slab bytes
in their TCP seq/ack numbers, and can also corrupt the forwarded TCP
flow.
Reset both struct ip_vs_seq members completely before publishing the
connection. This matches the existing "reset struct ip_vs_seq" comment
and keeps the sequence-adjustment gates inactive unless valid sequence
data is installed later.
Fixes: 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: Claude-Code:GLM-5.2
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/ipvs/ip_vs_conn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index cb36641f8d1c..6ed2622363f0 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -1420,8 +1420,8 @@ ip_vs_conn_new(const struct ip_vs_conn_param *p, int dest_af,
cp->app = NULL;
cp->app_data = NULL;
/* reset struct ip_vs_seq */
- cp->in_seq.delta = 0;
- cp->out_seq.delta = 0;
+ memset(&cp->in_seq, 0, sizeof(cp->in_seq));
+ memset(&cp->out_seq, 0, sizeof(cp->out_seq));
if (unlikely(flags & IP_VS_CONN_F_NO_CPORT)) {
int af_id = ip_vs_af_index(cp->af);
--
2.54.0
^ permalink raw reply related
* [PATCH net 7/9] ipvs: fix PMTU for GUE/GRE tunnel ICMP errors
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
When an ICMP Fragmentation Needed error is received for a tunneled IPVS
connection, ip_vs_in_icmp() recomputes the MTU that the original packet
can use by subtracting the tunnel overhead from the reported next-hop
MTU.
The current code always subtracts sizeof(struct iphdr), which is only
the IPIP overhead. For GUE and GRE tunnels, ipvs_udp_decap() and
ipvs_gre_decap() already compute the additional tunnel header length,
but that value is scoped to the decapsulation block and is lost before
the ICMP_FRAG_NEEDED handling. As a result, the ICMP error sent back to
the client advertises an MTU that is too large, so PMTUD can fail to
converge for GUE/GRE-tunneled real servers.
With a reported next-hop MTU of 1400, a GUE tunnel currently returns
1380 to the client. The correct value is 1368:
1400 - sizeof(struct iphdr) - sizeof(struct udphdr) -
sizeof(struct guehdr)
Hoist the tunnel header length into the main ip_vs_in_icmp() scope and
subtract sizeof(struct iphdr) + ulen in the Fragmentation Needed path.
The IPIP path keeps ulen as 0, so its existing 1400 - 20 = 1380 result
is unchanged.
Fixes: 508f744c0de3 ("ipvs: strip udp tunnel headers from icmp errors")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: Claude-Code:GLM-5.2
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/ipvs/ip_vs_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index d40b404c1bf6..906f2c361676 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1767,6 +1767,7 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
bool tunnel, new_cp = false;
union nf_inet_addr *raddr;
char *outer_proto = "IPIP";
+ int ulen = 0;
*related = 1;
@@ -1831,7 +1832,6 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
/* Error for our tunnel must arrive at LOCAL_IN */
(skb_rtable(skb)->rt_flags & RTCF_LOCAL)) {
__u8 iproto;
- int ulen;
/* Non-first fragment has no UDP/GRE header */
if (unlikely(cih->frag_off & htons(IP_OFFSET)))
@@ -1936,8 +1936,8 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
if (dest_dst)
mtu = dst_mtu(dest_dst->dst_cache);
}
- if (mtu > 68 + sizeof(struct iphdr))
- mtu -= sizeof(struct iphdr);
+ if (mtu > 68 + sizeof(struct iphdr) + ulen)
+ mtu -= sizeof(struct iphdr) + ulen;
info = htonl(mtu);
}
/* Strip outer IP, ICMP and IPIP/UDP/GRE, go to IP header of
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox