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
On Sat, Apr 09, 2022 at 01:58:29AM +0200, Jakob Koschel wrote:
> Hello Jakub,
> > Also the list_add() could be converted to list_add_tail().
>
> Good point, I wasn't sure if that's considered as something that should be
> done as a separate change. I'm happy to include it in v2.
By now you probab
On Sat, Apr 09, 2022 at 01:44:00AM +0200, Jakob Koschel wrote:
> > Let's try to not make convoluted code worse. Do the following 2 patches
> > achieve what you are looking for? Originally I had a single patch (what
> > is now 2/2) but I figured it would be cleaner to break out the unrelated
> > cha
patches
achieve what you are looking for? Originally I had a single patch (what
is now 2/2) but I figured it would be cleaner to break out the unrelated
change into what is now 1/2.
If you want I can submit these changes separately.
-[ cut here ]
eted the end goal of your patch.
I do have a vague suspicion I understand what you're trying to achieve,
and in that case, would you mind using this patch instead of yours?
I think it still preserves the intention of the code in a clean manner.
-[ cut here ]-
iselev
> Reviewed-by: Maxim Kochetkov
> ---
Reviewed-by: Vladimir Oltean
> arch/powerpc/boot/dts/fsl/t104xrdb.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi
> b/arch/powerpc/boot/dts/fsl/t104xrdb
Kiselev
> Reviewed-by: Maxim Kochetkov
> ---
Fixes: e69eb0824d8c ("powerpc: dts: t1040rdb: add ports for Seville Ethernet
switch")
Reviewed-by: Vladimir Oltean
Hi Maxim,
On Tue, Jan 11, 2022 at 06:22:04PM +0300, Maxim Kiselev wrote:
> On board rev A, the network interface labels for the switch ports
> written on the front panel are different than on rev B and later.
>
> This patch introduces a separate device tree for rev A.
> The main device tree is su
Hi Maxim,
On Mon, Jan 10, 2022 at 07:40:38AM +, Maxim Kiselev wrote:
> Here are photos of my boards.
Your patch is OK to change t1040rdb.dts, but please preserve the existing
port mappings in a new arch/powerpc/boot/dts/fsl/t1040rdb-rev-a.dts file.
You will also need to modify the /model and
On Thu, Dec 30, 2021 at 01:43:28PM +0300, Maxim Kiselev wrote:
> Fix network interface names for the switch ports according to labels
> that are written on the front panel of the board. They start from ETH3
> and end at ETH10.
>
> Fixes: e69eb0824d8c ("powerpc: dts: t1040rdb: add ports for Seville
On Sat, Nov 27, 2021 at 04:04:48AM +0200, Vladimir Oltean wrote:
> The blamed patch attempted to do a trivial conversion of
> map_mem_in_cams() by adding an extra "bool init" argument, but by
> mistake, changed the way in which two call sites pass the other boolean
> a
.
[0.057791] smp: Bringing up secondary CPUs ...
Issue noticed on a Freescale T1040.
Fixes: 52bda69ae8b5 ("powerpc/fsl_booke: Tell map_mem_in_cams() if init is
done")
Cc: sta...@vger.kernel.org
Signed-off-by: Vladimir Oltean
---
arch/powerpc/mm/nohash/tlb.c | 4 ++--
1 file changed
On Wed, Dec 09, 2020 at 03:34:49PM -0600, Bjorn Helgaas wrote:
> On Wed, Dec 09, 2020 at 11:20:17PM +0200, Vladimir Oltean wrote:
> > On Wed, Dec 09, 2020 at 02:59:13PM -0600, Bjorn Helgaas wrote:
> > > Yep, that's the theory. Thanks for testing it!
> >
> &
On Wed, Dec 09, 2020 at 02:59:13PM -0600, Bjorn Helgaas wrote:
> Yep, that's the theory. Thanks for testing it!
Testing what? I'm not following.
):
pci_ecam_create: remapping config space from addr 0x1f000, bus_range 0x1,
bsz 0x10
Fixes: f3c07cf6924e ("PCI: Unify ECAM constants in native PCI Express drivers")
Signed-off-by: Vladimir Oltean
---
drivers/pci/ecam.c | 12 ++--
1 file changed, 10 insertions(+), 2 d
: Vladimir Oltean
Reviewed-by: Maxim Kochetkov
Reviewed-by: Andrew Lunn
---
Changes in v4:
- Retargeted to net-next.
- Fixed the port labels (ETH5 was ETH4, ETH7 was ETH6, ETH9 was ETH8,
ETH11 was ETH10).
Changes in v3:
Renamed interfaces from swpN to ETHN, as per Andrew Lunn's sugge
Add the description of the embedded L2 switch inside the SoC dtsi file
for NXP T1040.
Signed-off-by: Vladimir Oltean
Reviewed-by: Maxim Kochetkov
Reviewed-by: Andrew Lunn
---
Changes in v4:
Retargeting to net-next.
Changes in v3:
Added definition for frame extraction interrupt, even if the
flict
with other patches submitted to T1040 device tree. Maybe this could at
least get an ACK from devicetree maintainers.
Vladimir Oltean (2):
powerpc: dts: t1040: add bindings for Seville Ethernet switch
powerpc: dts: t1040rdb: add ports for Seville Ethernet switch
arch/powerpc/boot/dt
On Thu, Oct 01, 2020 at 01:10:05PM -0700, David Miller wrote:
> From: Vladimir Oltean
> Date: Thu, 1 Oct 2020 16:20:11 +0300
>
> > Seville is a DSA switch that is embedded inside the T1040 SoC, and
> > supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
schemes are
shifted by 8.
Signed-off-by: Vladimir Oltean
Reviewed-by: Maxim Kochetkov
---
Changes in v3:
Renamed interfaces from swpN to ETHN, as per Andrew Lunn's suggestion.
Changes in v2:
Use the existing way of accessing the mdio bus and not labels.
arch/powerpc/boot/dts/fsl/t1040rd
Add the description of the embedded L2 switch inside the SoC dtsi file
for NXP T1040.
Signed-off-by: Vladimir Oltean
Reviewed-by: Maxim Kochetkov
---
Changes in v3:
Added definition for frame extraction interrupt, even if the driver
doesn't use it at the moment.
Changes in v2:
Make switch
Seville is a DSA switch that is embedded inside the T1040 SoC, and
supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
This series adds this switch to the SoC's dtsi files and to the T1040RDB
board file.
Vladimir Oltean (2):
powerpc: dts: t1040: add bindings for Se
On Tue, Sep 29, 2020 at 10:10:48PM +0200, Andrew Lunn wrote:
> On Tue, Sep 29, 2020 at 07:39:54PM +0000, Vladimir Oltean wrote:
> > On Tue, Sep 29, 2020 at 09:11:53PM +0200, Andrew Lunn wrote:
> > > > +&seville_port0 {
> > > > + managed = "i
On Tue, Sep 29, 2020 at 09:11:53PM +0200, Andrew Lunn wrote:
> > +&seville_port0 {
> > + managed = "in-band-status";
> > + phy-handle = <&phy_qsgmii_0>;
> > + phy-mode = "qsgmii";
> > + /* ETH4 written on chassis */
> > + label = "swp4";
>
> If ETH4 is on the chassis why not use ETH4?
Yo
From: Vladimir Oltean
Define the network interface names for the switch ports and hook them up
to the 2 QSGMII PHYs that are onboard.
A conscious decision was taken to go along with the numbers that are
written on the front panel of the board and not with the hardware
numbers of the switch chip
Add the description of the embedded L2 switch inside the SoC dtsi file
for NXP T1040.
Signed-off-by: Vladimir Oltean
---
Changes in v2:
Make switch node disabled by default.
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 76 +
1 file changed, 76 insertions(+)
diff --git a
Seville is a DSA switch that is embedded inside the T1040 SoC, and
supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
This series adds this switch to the SoC's dtsi files and to the T1040RDB
board file.
Vladimir Oltean (2):
powerpc: dts: t1040: add bindings for Se
shifted by 4.
Signed-off-by: Vladimir Oltean
---
arch/powerpc/boot/dts/fsl/t1040rdb.dts | 111 +
1 file changed, 111 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1040rdb.dts
b/arch/powerpc/boot/dts/fsl/t1040rdb.dts
index 40d7126dbe90..28ee06a1706d 100644
--- a/arch
In preparation of referencing the MDIO nodes from board DTS files (so
that we can add PHY nodes easier), add labels to mdio0 and mdio1.
Signed-off-by: Vladimir Oltean
---
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch
We're going to add 8 more PHYs in a future patch. It is easier to follow
the hardware description if we don't need to fish for the path of the
MDIO controllers inside the SoC and just use the labels.
Signed-off-by: Vladimir Oltean
---
arch/powerpc/boot/dts/fsl/t1040rdb.dts | 12 +
o the T1040RDB
board file.
Vladimir Oltean (4):
powerpc: dts: t1040: add bindings for Seville Ethernet switch
powerpc: dts: t1040: label the 2 MDIO controllers
powerpc: dts: t1040rdb: put SGMII PHY under &mdio0 label
powerpc: dts: t1040rdb: add ports for Seville Ethernet switch
arch/powerpc
Add the description of the embedded L2 switch inside the SoC dtsi file
for NXP T1040.
Signed-off-by: Vladimir Oltean
---
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 75 +
1 file changed, 75 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
b/arch
91 matches
Mail list logo
