r i.MX95 ENETC PF.
I don't see any functional issues with this set. I am also not sure
whether MAC address filtering is implemented in the simplest way, but I
suppose it can also be simplified over time.
Reviewed-by: Vladimir Oltean
On Mon, Apr 28, 2025 at 06:56:52PM +0800, Wei Fang wrote:
> Actually enetc_set_rss() does not need a return value, so change its
> type to void.
>
> Signed-off-by: Wei Fang
> Acked-by: Vladimir Oltean
The Acked-by: was supposed to be on patch "net: enetc: enable RSS
featur
On Wed, Apr 16, 2025 at 05:16:15AM +, Wei Fang wrote:
> > -Original Message-
> > From: Jakub Kicinski
> > Sent: 2025年4月16日 11:43
> > To: Wei Fang
> > Cc: Claudiu Manoil ; Vladimir Oltean
> > ; Clark Wang ;
> > andrew+net...@lunn.ch; da...@d
On Fri, Apr 11, 2025 at 05:57:42PM +0800, Wei Fang wrote:
> static const struct enetc_pf_ops enetc4_pf_ops = {
> .set_si_primary_mac = enetc4_pf_set_si_primary_mac,
> .get_si_primary_mac = enetc4_pf_get_si_primary_mac,
> @@ -303,12 +489,55 @@ static void enetc4_pf_free(struct enetc_pf
On Fri, Apr 18, 2025 at 01:49:25PM +, Wei Fang wrote:
> Do we need to retain cbdr_size in struct ntmp_user? Or just remove it in
> next version?
It seems redundant with cbdr->bd_num, so yes, please remove it.
On Fri, Apr 18, 2025 at 01:38:31PM +, Wei Fang wrote:
> > Can you please add one more sentence clarifying that the LS1028A
> > management protocol has been retroactively named NTMP 1.0 and its
> > implementation is in enetc_cbdr.c and enetc_tsn.c? The driver, like new
> > NETC documentation, re
for i.MX95 ENETC PF and VFs to
> support MAC address filtering.
>
> Signed-off-by: Wei Fang
> ---
Reviewed-by: Vladimir Oltean
On Fri, Apr 11, 2025 at 05:57:40PM +0800, Wei Fang wrote:
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_cbdr.c
> b/drivers/net/ethernet/freescale/enetc/enetc_cbdr.c
> index 20bfdf7fb4b4..ecb571e5ea50 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_cbdr.c
> +++ b/drivers/net/e
I see this is "Changes requested", so here are some more nitpicks from me.
On Fri, Apr 11, 2025 at 05:57:39PM +0800, Wei Fang wrote:
> Some NETC functionality is controlled using control messages sent to the
> hardware using BD ring interface with 32B descriptor similar to transmit
> BD ring used
On Tue, Mar 18, 2025 at 05:28:56AM +0200, Wei Fang wrote:
> > On Tue, Mar 11, 2025 at 01:38:21PM +0800, Wei Fang wrote:
> > > +static void enetc_show_si_mac_hash_filter(struct seq_file *s, int i)
> > > +{
> > > + struct enetc_si *si = s->private;
> > > + struct enetc_hw *hw = &si->hw;
> > > + u32 h
On Tue, Mar 18, 2025 at 06:47:11AM +0200, Wei Fang wrote:
> > These rxnfc commands seem implemented identically to the corresponding
> > subset from enetc_get_rxnfc(). Rather than duplicating those, could you
> > rather return -EOPNOTSUPP for the unsupported ones on NETC v4, and reuse
> > enetc_get
On Tue, Mar 11, 2025 at 01:38:27PM +0800, Wei Fang wrote:
> Since the VLAN hash filter of ENETC v1 and v4 is the basically same, the
> only difference is the offset of the VLAN hash filter registers. So, the
> .set_si_vlan_hash_filter() hook is added to struct enetc_pf_ops to set
> the registers of
On Tue, Mar 18, 2025 at 05:19:51AM +0200, Wei Fang wrote:
> You are right, but I'm afraid of the Coverity will report an issue, because
> the
> pf->mac_list and pf->num_mfe are protected by the mac_list_lock in other
> functions. And enetc4_pf_destroy_mac_list() will be called in other function
>
Hi Claudiu,
On Tue, Mar 18, 2025 at 10:08:24AM +0200, Claudiu Manoil wrote:
>
> > -Original Message-
> > From: Vladimir Oltean
> > Sent: Monday, March 17, 2025 4:18 PM
> [...]
> > Subject: Re: [PATCH v4 net-next 04/14] net: enetc: add MAC filter for i.MX9
On Tue, Mar 11, 2025 at 01:38:30PM +0800, Wei Fang wrote:
> Add new file ntmp.h. to ENETC driver.
>
> Signed-off-by: Wei Fang
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7078199fcebf..e259b659eadb 100644
> --- a/MAINTAINERS
> ++
On Tue, Mar 11, 2025 at 01:38:26PM +0800, Wei Fang wrote:
> For ENETC, each SI has a corresponding VLAN hash table. That is to say,
> both PF and VFs can support VLAN filter. However, currently only ENETC v1
> PF driver supports VLAN filter. In order to make i.MX95 ENETC (v4) PF and
> VF drivers al
On Tue, Mar 11, 2025 at 01:38:22PM +0800, Wei Fang wrote:
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> index d7d9a720069b..072e5b40a199 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> +++ b/drivers/net/etherne
int enetc_set_rss(struct net_device *ndev, int en)
Can you please add a preliminary patch which converts this function's
prototype to:
static void enetc_set_rss(struct net_device *ndev, bool en)
?
After you do that please feel free to add my tag and keep it in future
patch submissions:
Acked-by: Vladimir Oltean
I don't see downsides to enabling RX hashing by default.
On Tue, Mar 11, 2025 at 01:38:23PM +0800, Wei Fang wrote:
> Since the offset of the RSS key registers of i.MX95 ENETC is different
> from that of LS1028A, so add enetc_get_rss_key_base() to get the base
> offset for the different chips, so that enetc_set_rss_key() can be
> reused for this trivial.
On Tue, Mar 11, 2025 at 01:38:24PM +0800, Wei Fang wrote:
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc.h
> b/drivers/net/ethernet/freescale/enetc/enetc.h
> index a3ce324c716c..ecf79338cd79 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc.h
> +++ b/drivers/net/ethernet/freesca
On Tue, Mar 11, 2025 at 01:38:21PM +0800, Wei Fang wrote:
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c
> b/drivers/net/ethernet/freescale/enetc/enetc4_debugfs.c
> new file mode 100644
> index ..3a660c80344a
> --- /dev/null
> +++ b/drivers/net/ethernet/freescale/
On Tue, Mar 11, 2025 at 01:38:20PM +0800, Wei Fang wrote:
> The i.MX95 ENETC supports both MAC hash filter and MAC exact filter. MAC
> hash filter is implenented through a 64-bits hash table to match against
s/implenented/implemented/
s/64-bits/64-bit/
> the hashed addresses, PF and VFs each have
On Mon, Mar 17, 2025 at 11:55:26AM +0200, Wei Fang wrote:
> Actually I did this is the original version, I mean in downstream kernel 6.6
> tree. I add a "ntmp_mfe" in ntmp.h like below
>
> struct ntmp_mfe {
> u8 mac[ETH_ALEN];
> u16 si_bitmap;
> };
>
> And the conversion was done by t
title: s/filterng/filtering/
On Tue, Mar 11, 2025 at 01:38:19PM +0800, Wei Fang wrote:
> Although only ENETC PF can access the MAC address filter table, the table
> entries can specify MAC address filtering for one or more SIs based on
> SI_BITMAP, which means that the table also supports MAC addr
Hi Wei,
On Fri, Mar 14, 2025 at 03:48:21PM +0200, Wei Fang wrote:
> > I mean, I was just suggesting to group the macros with the macros, and
> > the struct fields with the struct fields. Mixing them together looks a
> > bit messy to me. Even worse in the definition of "union netc_cbd" which
> > IM
On Fri, Mar 14, 2025 at 06:51:06AM +0200, Wei Fang wrote:
> > I don't understand the need for si->ops->setup_cbdr() and
> > si->ops->teardown_cbdr()?
> > Doesn't every call site know which kind of SI it is dealing with, and thus
> > it can
> > appropriately call the direct symbol?
> > - the v1 PSI
On Fri, Mar 14, 2025 at 05:38:18AM +0200, Wei Fang wrote:
> > > + __le16 update_act;
> > > + u8 dbg_opt;
> > > + u8 tblv_qact;
> > > +#define NTMP_QUERY_ACT GENMASK(3, 0)
> > > +#define NTMP_TBL_VER GENMASK(7, 0)
> > > +#define NTMP_TBLV_QACT(v, a) (FIELD_PREP(NTMP_TBL_VER
On Tue, Mar 11, 2025 at 01:38:18PM +0800, Wei Fang wrote:
> The command BD ring is used to configure functionality where the
> underlying resources may be shared between different entities or being
> too large to configure using direct registers (such as lookup tables).
>
> Because the command BD
On Tue, Mar 11, 2025 at 01:38:17PM +0800, Wei Fang wrote:
> +int ntmp_rsst_query_or_update_entry(struct netc_cbdrs *cbdrs, u32 *table,
> + int count, bool query)
> +{
> + struct ntmp_dma_buf data = {.dev = cbdrs->dma_dev};
> + struct rsst_req_update *requ;
>
On Tue, Mar 11, 2025 at 01:38:16PM +0800, Wei Fang wrote:
> This patch set adds the following features.
> 1. Compared with ENETC v1, the formats of tables and command BD of ENETC
> v4 have changed significantly, and the two are not compatible. Therefore,
> in order to support the NETC Table Managem
On Fri, Nov 01, 2024 at 10:54:47AM +0200, Louis Peens wrote:
> Hi - sorry, I do still manage to mix up when to use signed-off-by and
> reviewed-by.
You use Signed-off-by when you submit a patch and Reviewed-by when you
review it.
s the struct dim_sample by reference to net_dim().
>
> Signed-off-by: Caleb Sander Mateos
> ---
Reviewed-by: Vladimir Oltean
On Wed, Oct 30, 2024 at 06:23:25PM -0600, Caleb Sander Mateos wrote:
> Make the start and end arguments to dim_calc_stats() const pointers
> to clarify that the function does not modify their values.
>
> Signed-off-by: Caleb Sander Mateos
> ---
Reviewed-by: Vladimir Oltean
On Tue, Oct 29, 2024 at 06:43:16PM +0200, Vladimir Oltean wrote:
> Tested on LS1046A.
..and now also tested on T2080 (PowerPC), no apparent regressions.
r API consumer
is netdev, is maintained by a different group. In this case, the buggy
qm_sg_entry_get_off() function is defined in qbman but exclusively
called in netdev.
Vladimir Oltean (3):
soc: fsl_qbman: use be16_to_cpu() in qm_sg_entry_get_off()
net: dpaa_eth: add assertions about SGT entry of
.
Signed-off-by: Vladimir Oltean
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index e280013afa63..bf5baef5c3e0 100644
--- a/drivers
is even a comment stating the same thing:
* Data in subsequent SG entries is stored from the
* beginning of the buffer, so we don't need to add the
* sg_offset.
Tested on LS1046A.
Signed-off-by: Vladimir Oltean
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c|
the buffer offset will always be zero, as will be explained in
the subsequent change.
Flagged by sparse:
warning: cast to restricted __be32
warning: cast from restricted __be16
Signed-off-by: Vladimir Oltean
---
include/soc/fsl/qman.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
to treat it as
a bug and backport the format change to all supported stable kernels,
for consistency.
Fixes: eb11ddf36eb8 ("dpaa_eth: add trace points")
Signed-off-by: Vladimir Oltean
---
Context:
https://lore.kernel.org/oe-kbuild-all/20241028-sticky-refined-lionfish-b06c0c@leitao/
d
x/fsl")
> Cc: sta...@vger.kernel.org
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202410102136.jqhzocs4-...@intel.com/
> Signed-off-by: Wei Fang
> ---
Reviewed-by: Vladimir Oltean
mir.olt...@nxp.com/
Breno Leitao (1):
soc: fsl: qbman: FSL_DPAA depends on COMPILE_TEST
Vladimir Oltean (4):
net: dpaa: avoid on-stack arrays of NR_CPUS elements
net: dpaa: eliminate NR_CPUS dependency in egress_fqs[] and conf_fqs[]
net: dpaa: stop ignoring TX queues past the number of CPUs
nts (aka a small number determined at runtime).
Link: https://lore.kernel.org/all/202406261920.l5pzm1rj-...@intel.com/
Signed-off-by: Vladimir Oltean
Reviewed-by: Breno Leitao
Acked-by: Madalin Bucur
---
v1->v2: none
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 20 ++-
eady allocated TX queues for
all possible CPUs and the maximal number of traffic classes, and we've
already iterated once through them all.
The while() condition is dead code, remove it.
Signed-off-by: Vladimir Oltean
Acked-by: Madalin Bucur
---
v1->v2: none
drivers/net/ethernet/fre
g again through FQ_TYPE_TX queues in dpaa_fq_setup() and
counting them will never yield an egress_cnt larger than the allocated
size, dpaa_max_num_txqs().
The comparison serves no purpose since it is always true; remove it.
Signed-off-by: Vladimir Oltean
Acked-by: Madalin Bucur
---
v1-&g
SoC.
The replacement is as follows:
- DPAA_TC_TXQ_NUM -> dpaa_num_txqs_per_tc()
- DPAA_ETH_TXQ_NUM -> dpaa_max_num_txqs()
Signed-off-by: Vladimir Oltean
Acked-by: Madalin Bucur
---
v1->v2: properly return -ENOMEM in probe() function
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 47 +
From: Breno Leitao
As most of the drivers that depend on ARCH_LAYERSCAPE, make FSL_DPAA
depend on COMPILE_TEST for compilation and testing.
# grep -r depends.\*ARCH_LAYERSCAPE.\*COMPILE_TEST | wc -l
29
Signed-off-by: Breno Leitao
Signed-off-by: Vladimir Oltean
Acked-by
On Sat, Jul 13, 2024 at 03:35:32PM -0700, Jakub Kicinski wrote:
> On Thu, 11 Jul 2024 02:00:22 +0300 Vladimir Oltean wrote:
> > + priv->egress_fqs = devm_kcalloc(dev, dpaa_max_num_txqs(),
> > + sizeof
On Thu, Jul 11, 2024 at 02:00:25AM +0300, Vladimir Oltean wrote:
> From: Breno Leitao
>
> As most of the drivers that depend on ARCH_LAYERSCAPE, make FSL_DPAA
> depend on COMPILE_TEST for compilation and testing.
>
> # grep -r depends.\*ARCH_LAYERSCAPE.\*COMPILE_TEST
ot;;
reg = <0x0 0x188 0x0 0x1>;
memory-region = <&qman_fqd &qman_pfdr>;
};
};
};
Fixes: 3e62273ac63a ("soc: fsl: qbman: Remove RESERVEDMEM_OF_DECLARE usage")
Cc:
Signed-off-by: Vladimir Oltean
---
dr
represents
what this function does, and for an actual upcoming bug fix, it needs to
be refactored. There is no place for the bogus code afterwards, so it
needs to go as part of that, sadly.
Cc:
Signed-off-by: Vladimir Oltean
---
drivers/soc/fsl/qbman/dpaa_sys.c | 31 -
From: Breno Leitao
As most of the drivers that depend on ARCH_LAYERSCAPE, make FSL_DPAA
depend on COMPILE_TEST for compilation and testing.
# grep -r depends.\*ARCH_LAYERSCAPE.\*COMPILE_TEST | wc -l
29
Signed-off-by: Breno Leitao
Signed-off-by: Vladimir Oltean
---
drivers
eady allocated TX queues for
all possible CPUs and the maximal number of traffic classes, and we've
already iterated once through them all.
The while() condition is dead code, remove it.
Signed-off-by: Vladimir Oltean
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 11 ---
g again through FQ_TYPE_TX queues in dpaa_fq_setup() and
counting them will never yield an egress_cnt larger than the allocated
size, dpaa_max_num_txqs().
The comparison serves no purpose since it is always true; remove it.
Signed-off-by: Vladimir Oltean
---
drivers/net/ethernet/freesca
SoC.
The replacement is as follows:
- DPAA_TC_TXQ_NUM -> dpaa_num_txqs_per_tc()
- DPAA_ETH_TXQ_NUM -> dpaa_max_num_txqs()
Signed-off-by: Vladimir Oltean
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 43 +--
.../net/ethernet/freescale/dpaa/dpaa_eth.h| 20 ++---
2 f
nts (aka a small number determined at runtime).
Link: https://lore.kernel.org/all/202406261920.l5pzm1rj-...@intel.com/
Signed-off-by: Vladimir Oltean
---
.../net/ethernet/freescale/dpaa/dpaa_eth.c| 20 ++-
.../ethernet/freescale/dpaa/dpaa_ethtool.c| 10 +-
2 files c
from Herbert to take it via netdev, despite it being on soc/qbman:
https://lore.kernel.org/all/zns%2fevvbc7pdv...@gondor.apana.org.au/
Breno Leitao (1):
soc: fsl: qbman: FSL_DPAA depends on COMPILE_TEST
Vladimir Oltean (4):
net: dpaa: avoid on-stack arrays of NR_CPUS elements
net: dpaa: el
On Tue, Jul 09, 2024 at 08:15:23AM -0700, Breno Leitao wrote:
> Hello Vladimir,
>
> On Tue, Jul 09, 2024 at 04:58:11PM +0300, Vladimir Oltean wrote:
>
> > On Mon, Jul 08, 2024 at 12:08:05PM -0700, Breno Leitao wrote:
> > > I thought about a patch like the following
ic, as opposed to hand-crafted, .config files.
A simple solution is to use dynamic allocation for num_possible_cpus()
elements (aka a small number determined at runtime).
Link: https://lore.kernel.org/all/202406261920.l5pzm1rj-...@intel.com/
Signed-off-by: Vladimir Oltean
---
.../net/eth
On Thu, Jun 27, 2024 at 11:40:24AM -0700, Breno Leitao wrote:
> Hello Vladimir,
>
> On Wed, Jun 26, 2024 at 05:06:23PM +0300, Vladimir Oltean wrote:
> > On Wed, Jun 26, 2024 at 08:09:53PM +0800, kernel test robot wrote:
>
> > > All warnings (new ones prefixed by >&
On Wed, Jun 26, 2024 at 08:09:53PM +0800, kernel test robot wrote:
> Hi Breno,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on herbert-cryptodev-2.6/master]
> [also build test WARNING on soc/for-next linus/master v6.10-rc5 next-20240625]
> [If your patc
e
> other lockers.
>
> Fixes: 96f413f47677 ("soc/fsl/qbman: fix issue in qman_delete_cgr_safe()")
> CC: sta...@vger.kernel.org
> Signed-off-by: Sean Anderson
> Reviewed-by: Camelia Groza
> Tested-by: Vladimir Oltean
> ---
> I got no response the first time
Hi Sean,
On Thu, Aug 10, 2023 at 03:58:36PM -0400, Sean Anderson wrote:
> I can look into doing this. It will be in my free time, so it will
> likely be a bit before I can update this series.
I was expecting you'd ask some clarification questions about the RCW
override procedure that I've informa
On Thu, Aug 24, 2023 at 06:09:52PM -0400, Sean Anderson wrote:
> On 8/21/23 19:59, Vladimir Oltean wrote:
> > On Mon, Aug 21, 2023 at 07:39:15PM -0400, Sean Anderson wrote:
> >> Well, I think we should take the opportunity to think about the hardware
> >> which exists
On Mon, Aug 21, 2023 at 07:39:15PM -0400, Sean Anderson wrote:
> Well, I think we should take the opportunity to think about the hardware
> which exists and how we plan to model it. IMO grouping lanes into a
> single phy simplifies both the phy driver and the mac driver.
Ok, but ungrouped for back
On Mon, Aug 21, 2023 at 05:06:46PM -0400, Sean Anderson wrote:
> On 8/21/23 15:58, Vladimir Oltean wrote:
> > On Mon, Aug 21, 2023 at 02:46:53PM -0400, Sean Anderson wrote:
> >> After further review, it seems the reason 28g can get away without this
> >> is because t
On Mon, Aug 21, 2023 at 02:46:53PM -0400, Sean Anderson wrote:
> After further review, it seems the reason 28g can get away without this
> is because there's a one-to-one mapping between protocol controllers and
> lanes. Unfortunately, that regularity is not present for 10g.
>
> --Sean
There are
On Mon, Aug 21, 2023 at 09:13:49PM +0300, Ioana Ciornei wrote:
> > - We can have one compatible for each SoC, and determine the serdes
> > based on the address. I would like to avoid this...
>
> To me this really seems like a straightforward approach.
+1
Hi Sean,
On Fri, Aug 11, 2023 at 07:36:37PM +0300, Vladimir Oltean wrote:
> Let me explain that approach, because your mention of "swapping out the
> bootloaders" makes it appear as if you are not visualising what I am
> proposing.
>
> The Lynx SerDes family has 2 PLL
On Fri, Aug 11, 2023 at 11:43:01AM -0400, Sean Anderson wrote:
> >> > > Here is an illustrative example (sorry, I don't have a board with the
> >> > > right refclk on that PLL, to verify all the way):
> >> > >
> >> > > ... snip ...
> >> >
> >> > (which of course complicates the process of buildin
Hi Sean,
On Thu, Aug 10, 2023 at 03:58:36PM -0400, Sean Anderson wrote:
> As explained previously (and noted by yourself below) 1G and 10G RCWs
> have mutally-incompatible clocking requirements. Now that you have
> documented an alternate solution, it is possible to boot up with one RCW
> and swit
Hi Sean,
On Tue, Jun 13, 2023 at 05:27:54PM +0300, Vladimir Oltean wrote:
> > > At first sight you might appear to have a point related to the fact that
> > > PLL register writes are necessary, and thus this whole shebang is
> > > necessary.
> > > But thi
Hi Sean,
On Tue, Jun 13, 2023 at 05:27:54PM +0300, Vladimir Oltean wrote:
> The way things are supposed to work (*if* this works at all) is that the
> reset state machine starts with a supported PLL / refclk configuration
> that permits a certain subset of protocols, and the SERDES prot
On Mon, Jun 12, 2023 at 04:46:16PM -0400, Sean Anderson wrote:
> On 6/12/23 12:33, Vladimir Oltean wrote:
> > On Mon, Jun 12, 2023 at 10:35:21AM -0400, Sean Anderson wrote:
> >> > And if SERDES protocol switching was not physically possible, would this
> >> > patc
On Mon, Jun 12, 2023 at 10:35:21AM -0400, Sean Anderson wrote:
> > And if SERDES protocol switching was not physically possible, would this
> > patch set still have value?
>
> Yes. To e.g. set up SGMII25 or to fix the clocking situation.
Let me analyze the reasons one by one.
The clocking situat
Hello Sean,
On Fri, Jun 09, 2023 at 03:19:22PM -0400, Sean Anderson wrote:
> On 5/22/23 11:00, Vladimir Oltean wrote:
> > On Mon, May 22, 2023 at 10:42:04AM -0400, Sean Anderson wrote:
> >> Have you had a chance to review this driver?
> >
> > Partially / too l
On Mon, May 22, 2023 at 10:42:04AM -0400, Sean Anderson wrote:
> Have you had a chance to review this driver?
Partially / too little (and no, I don't have an answer yet). I am
debugging a SERDES protocol change procedure from XFI to SGMII.
On Wed, Apr 26, 2023 at 10:50:17AM -0400, Sean Anderson wrote:
> > I need to catch up with 14 rounds of patches from you and with the
> > discussions that took place on each version, and understand how you
> > responded to feedback like "don't remove PHY interrupts without finding
> > out why they
On Tue, Apr 25, 2023 at 04:22:32PM -0400, Sean Anderson wrote:
> The features which do not work (major protocol changes) are disabled :)
>
> If it would cause this series to be immediately merged, I would remove
> KX/KR and 2.5G which are the only untested link modes.
>
> That said, PCS support i
Hello,
On Thu, 13 Apr 2023 12:05:52 -0400, Sean Anderson wrote:
> This series is ready for review by the phy maintainers. I have addressed
> all known feedback and there are no outstanding issues.
>
> Major reconfiguration of baud rate (e.g. 1G->10G) does not work.
>
> There are several stand-al
Same comment about the Fixes tag.
git tag --contains c535e923bb97
v4.9
git tag --contains 96f413f47677
v4.16
Looking at https://www.kernel.org/, I see that kernel 4.14 is still
maintained but should not have this patch backported, do you agree?
> Reported-by: Vladimir Oltean
> Link: https://l
and not in the initial commit, no?
Anyway,
Tested-by: Vladimir Oltean
the device tree should not cause any
compatibility issue, because the default CPU port was &seville_port8
before this change, and still is &seville_port8 now (the numerically
first CPU port is used by default).
Signed-off-by: Vladimir Oltean
---
arch/powerpc/boot/dts/fsl/t1040rdb.dts
It looks like U-Boot fails to start the kernel properly when the
compatible string of the board isn't fsl,T1040RDB, so stop overriding it
from the rev-a.dts.
Fixes: 5ebb74749202 ("powerpc: dts: t1040rdb: fix ports names for Seville
Ethernet switch")
Signed-off-by: Vladimir Ol
This contains a fix for the new device tree for the T1040RDB rev A
board, which never worked, and an update to enable multiple CPU port
support for all revisions of the T1040RDB.
Vladimir Oltean (2):
powerpc: dts: t1040rdb: fix compatible string for Rev A boards
powerpc: dts: t1040rdb: enable
On Mon, Dec 05, 2022 at 10:15:16PM +0300, Arınç ÜNAL wrote:
> As Jonas (on CC) pointed out, I only see this being used in the swconfig b53
> driver which uses the label to identify the cpu port.
>
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/files/drivers/net/phy/
Hi Pali,
On Fri, Dec 02, 2022 at 08:35:52PM +0100, Pali Rohár wrote:
> On Thursday 01 December 2022 17:44:00 Rob Herring wrote:
> > On Thu, Dec 01, 2022 at 06:39:02PM +0100, Pali Rohár wrote:
> > > I was told by Marek (CCed) that DSA port connected to CPU should have
> > > label "cpu" and not "cpu
On Mon, Nov 14, 2022 at 01:08:03PM -0500, Sean Anderson wrote:
> On 11/14/22 12:23, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
> >> these will probably be in device trees for a year before the kernel
> >> starts using them
On Thu, Nov 10, 2022 at 11:56:15AM -0500, Sean Anderson wrote:
> these will probably be in device trees for a year before the kernel
> starts using them. But once that is done, we are free to require them.
Sorry, you need to propose something that is not "we can break compatibility
with today's de
On Thu, Nov 10, 2022 at 05:01:34PM +0100, Andrew Lunn wrote:
> On Thu, Nov 10, 2022 at 03:29:26PM +0000, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> > > On 11/9/22 17:41, Vladimir Oltean wrote:
> > > > On Thu, Nov 03,
On Thu, Nov 10, 2022 at 10:39:30AM -0500, Sean Anderson wrote:
> On 11/10/22 10:29, Vladimir Oltean wrote:
> > On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> >> On 11/9/22 17:41, Vladimir Oltean wrote:
> >> > On Thu, Nov 03, 2022 at 05:06:3
On Thu, Nov 10, 2022 at 09:55:32AM -0500, Sean Anderson wrote:
> On 11/9/22 17:41, Vladimir Oltean wrote:
> > On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> >> Several (later) patches in this series cannot be applied until a stable
> >> release has
On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> For a long time, PCSs have been tightly coupled with their MACs. For
> this reason, the MAC creates the "phy" or mdio device, and then passes
> it to the PCS to initialize. This has a few disadvantages:
>
> - Each MAC must re-impleme
On Thu, Nov 03, 2022 at 05:06:39PM -0400, Sean Anderson wrote:
> Several (later) patches in this series cannot be applied until a stable
> release has occured containing the dts updates.
New kernels must remain compatible with old device trees.
On Tue, Jul 19, 2022 at 03:34:45PM -0400, Sean Anderson wrote:
> We could do it, but it'd be a pretty big hack. Something like the
> following. Phylink would need to be modified to grab the lock before
> every op and check if the PCS is dead or not. This is of course still
> not optimal, since ther
On Tue, Jul 19, 2022 at 11:28:42AM -0400, Sean Anderson wrote:
> Hi Vladimir,
>
> On 7/19/22 11:25 AM, Vladimir Oltean wrote:
> > Hi Sean,
> >
> > On Mon, Jul 11, 2022 at 12:05:10PM -0400, Sean Anderson wrote:
> >> For a long time, PCSs have been tightly co
turn 0 before.
>
> Signed-off-by: Uwe Kleine-König
> ---
Assuming you remove the spurious kasan change:
Reviewed-by: Vladimir Oltean
e.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=ehreask5sqxpwr9y7k9sa6cwx...@mail.gmail.com/
> [1]
> Signed-off-by: Jakob Koschel
> ---
I absolutely hate the robotic commit message, but the change looks like
it works, so:
Reviewed-by: Vladimir Oltean
> net/dsa/dsa.c | 11 +--
> 1 file ch
On Sun, Apr 10, 2022 at 10:30:31PM +0200, Jakob Koschel wrote:
> > On 10. Apr 2022, at 22:02, Vladimir Oltean wrote:
> >
> > On Sun, Apr 10, 2022 at 08:24:37PM +0200, Jakob Koschel wrote:
> >> Btw, I just realized that the if (!pos) is not necessary. Thi
more special-casing of an empty list
- simplifying the error path
- that thing with list_add_tail()
What do you think about the changes below?
>From 5b952b75e239cbe96729cf78c17e8d9725c9617c Mon Sep 17 00:00:00 2001
From: Vladimir Oltean
Date: Sun, 10 Apr 2022 22:21:41 +0300
Subject: [PATCH
On Sun, Apr 10, 2022 at 12:51:56PM +0200, Jakob Koschel wrote:
> I've just looked at this again in a bit more detail while integrating it into
> the patch series.
>
> I realized that this just shifts the 'problem' to using the 'pos' iterator
> variable after the loop.
> If the scope of the list
1 - 100 of 131 matches
Mail list logo
