> As long as it doesn't behave differently from the other RTC, I'm fine
> with this. This is important because I don't want to carry any special
> infrastructure for this driver or to have to special case this driver
> later on because it is incompatible with some evolution of the
> subsystem.
> Having worked with closed-source systems, especially VxWorks, for many
> years (where the header files contain all the documentation), it just
> seems strange to embed the documentation in the .c files.
The key words here might be closed-source. With such black boxes, you
don't have access the
For example, some devices, such as the Ubiquiti EdgeRouter X, may have
> ports labeled ethX. Labeling the master GMAC with a different prefix
> than DSA ports helps with clarity.
>
> Suggested-by: René van Dorst
> Signed-off-by: Ilya Lipnitskiy
Reviewed-by: Andrew Lunn
Andrew
On Sun, Apr 18, 2021 at 09:03:52PM -0700, Ilya Lipnitskiy wrote:
> The MAC device name can now be set within DTS file instead of always
> being "ethX". This is helpful for DSA to clearly label the DSA master
> device and distinguish it from DSA slave ports.
>
> For example, some devices, such as
> Currently this code is implemented in pci_bus_find_domain_nr() function.
> IIRC domain number is 16bit integer, so plain bitmap would consume 8 kB
> of memory. I'm not sure if it is fine or some other tree-based structure
> for allocated domain numbers is needed.
Hi Pali
Have a look at
t; Fix by using readl_poll_timeout as a more standard and less error-prone
> solution.
>
> Fixes: ba37b7caf1ed ("net: ethernet: mtk_eth_soc: add support for
> initializing the PPE")
> Signed-off-by: Ilya Lipnitskiy
> Cc: Felix Fietkau
Reviewed-by: Andrew Lunn
Andrew
> @@ -1079,6 +1078,14 @@ static int korina_probe(struct platform_device *pdev)
> eth_hw_addr_random(dev);
> }
>
> + clk = devm_clk_get(>dev, NULL);
You should use a name here. It makes future expansion of the binding
easier. devm_clk_get_optional() is probably
> - memcpy(dev->dev_addr, mac_addr, ETH_ALEN);
> + if (mac_addr) {
> + ether_addr_copy(dev->dev_addr, mac_addr);
> + } else {
> + u8 ofmac[ETH_ALEN];
> +
> + if (of_get_mac_address(pdev->dev.of_node, ofmac) == 0)
> +
On Thu, Apr 15, 2021 at 01:06:43AM +0200, Thomas Bogendoerfer wrote:
> Get rid of access to struct korina_device by just passing the mac
> address via platform data and use drvdata for passing netdev to remove
> function.
>
> Signed-off-by: Thomas Bogendoerfer
> ---
> arch/mips/rb532/devices.c
On Thu, Apr 15, 2021 at 01:06:42AM +0200, Thomas Bogendoerfer wrote:
> Instead of messing with MIPS specific macros use DMA API for mapping
> descriptors and skbs.
>
> Signed-off-by: Thomas Bogendoerfer
Reviewed-by: Andrew Lunn
Andrew
On Thu, Apr 15, 2021 at 01:06:41AM +0200, Thomas Bogendoerfer wrote:
> Remove helpers, which are only used in one call site.
>
> Signed-off-by: Thomas Bogendoerfer
Reviewed-by: Andrew Lunn
Andrew
On Thu, Apr 15, 2021 at 01:06:40AM +0200, Thomas Bogendoerfer wrote:
> Descriptors are mapped uncached so there is no need to do any cache
> handling for them.
>
> Signed-off-by: Thomas Bogendoerfer
Reviewed-by: Andrew Lunn
Andrew
On Thu, Apr 15, 2021 at 01:06:39AM +0200, Thomas Bogendoerfer wrote:
> Simplify probe/remove code by using devm_ functions.
>
> Signed-off-by: Thomas Bogendoerfer
Reviewed-by: Andrew Lunn
Andrew
> +static int korina_mdio_wait(struct korina_private *lp)
> +{
> + u32 value;
> +
> + return readl_poll_timeout_atomic(>eth_regs->miimind,
> + value, value & ETH_MII_IND_BSY,
> + 1, 1000);
> +}
> +
> +static int
On Thu, Apr 15, 2021 at 04:02:34PM -0700, Ilya Lipnitskiy wrote:
> The intention is for the loop to timeout if the body does not succeed.
> The current logic calls time_is_before_jiffies(timeout) which is false
> until after the timeout, so the loop body never executes.
>
>
On Thu, Apr 15, 2021 at 12:25:37PM +0300, Radu Pirea (NXP OSS) wrote:
> Add generic PMA suspend and resume callback functions for C45 PHYs.
>
> Signed-off-by: Radu Pirea (NXP OSS)
Reviewed-by: Andrew Lunn
Andrew
> +config NXP_C45_TJA11XX_PHY
> + tristate "NXP C45 TJA11XX PHYs"
> + help
> + Enable support for NXP C45 TJA11XX PHYs.
> + Currently supports only the TJA1103 PHY.
> +#define PHY_ID_BASE_T1 0x001BB010
It would be better to use PHY_ID_TJA_1103 here.
> +
> + if (!p) {
> printk(KERN_ERR DRV_NAME ": cannot remap registers\n");
> - rc = -ENXIO;
> - goto probe_err_out;
> + return -ENOMEM;
> }
Hi Thomas
Another possible cleanup would be replacing printk(KERN_ERR with
dev_err(), or
> +static int korina_mdio_wait(struct korina_private *lp)
> +{
> + int timeout = 1000;
> +
> + while ((readl(>eth_regs->miimind) & 1) && timeout-- > 0)
> + udelay(1);
> +
> + if (timeout <= 0)
> + return -1;
> +
> + return 0;
Using
On Wed, Apr 14, 2021 at 05:26:55PM +0200, Michael Walle wrote:
> It is already possible to read the MAC address via a NVMEM provider. But
> there are boards, esp. with many ports, which only have a base MAC
> address stored. Thus we need to have a way to provide an offset per
> network device.
We
sta...@vger.kernel.org
> Signed-off-by: Michal Vokáč
Reviewed-by: Andrew Lunn
Andrew
> nxp-c45-tja11xx is acceptable from my point of view.
Great. Enough bike shedding, nxp-c45-tja11xx it is.
Andrew
> Ok, we can agree that there will not be a perfect naming. Would it be a
> possibility to rename the existing TJA11xx driver to TJA1100-1-2 or is that
> unwanted?
It is generally a bad idea. It makes back porting fixing harder if the
file changes name.
> If nxp-c45.c is to generic (I take from
On Tue, Apr 13, 2021 at 08:56:30AM +0200, Christian Herber wrote:
> Hi Andrew,
>
> On 4/12/2021 6:52 PM, Andrew Lunn wrote:
> >
> > So what you are say is, you don't care if the IP is completely
> > different, it all goes in one driver. So lets put this driver into
>
> Indeed - it should be a logical and operation - there is light present
> _and_ the PHY recognises the signal. This is what the commit achieves,
> although (iirc) doesn't cater for the case where there is no SFP cage
> attached.
Hi Russell
Is there something like this in the marvell10 driver?
On Tue, Apr 13, 2021 at 10:13:49AM +0300, Ivan Bornyakov wrote:
> On Tue, Apr 13, 2021 at 01:32:12AM +0200, Marek Behún wrote:
> > On Mon, 12 Apr 2021 15:16:59 +0300
> > Ivan Bornyakov wrote:
> >
> > > Some SFP modules uses RX_LOS for link indication. In such cases link
> > > will be always up,
> I guess this is depends whether the most usual case is to have all
> these interrupts being actively in use or not. Most interrupts only
> use a limited portion of their interrupt space at any given time.
> Allocating all interrupts and creating mappings upfront is a waste of
> memory.
>
> If
associated with that device.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
lse {}
>
> @@
> identifier a.x;
> expression e;
> @@
> - if (<+... x ...+>@e)
> - {}
> - else
> + if (!(e))
> {...}
>
> @@
> expression x, y, z;
> @@
> - x = of_get_mac_address(y, z);
> + of_get_mac_address(y, z);
> ... when != x
>
>
> All drivers, except drivers/net/ethernet/aeroflex/greth.c, were
> compile-time tested.
>
> Suggested-by: Andrew Lunn
> Signed-off-by: Michael Walle
I cannot say i looked at all the changes, but the ones i did exam
seemed O.K.
Reviewed-by: Andrew Lunn
Andrew
> > > +static void
> > > +mt7530_setup_mdio_irq(struct mt7530_priv *priv)
> > > +{
> > > + struct dsa_switch *ds = priv->ds;
> > > + int p;
> > > +
> > > + for (p = 0; p < MT7530_NUM_PHYS; p++) {
> > > + if (BIT(p) & ds->phys_mii_mask) {
> > > + unsigned int irq;
> > > +
>
On Tue, Apr 13, 2021 at 12:24:49AM +0200, Martin Blumenstingl wrote:
> Hi Andrew,
>
> On Mon, Apr 12, 2021 at 1:16 AM Andrew Lunn wrote:
> >
> > On Sun, Apr 11, 2021 at 10:55:11PM +0200, Martin Blumenstingl wrote:
> > > Add support for .get_regs_len and .get_re
On Mon, Apr 12, 2021 at 03:16:59PM +0300, Ivan Bornyakov wrote:
> Some SFP modules uses RX_LOS for link indication. In such cases link
> will be always up, even without cable connected. RX_LOS changes will
> trigger link_up()/link_down() upstream operations. Thus, check that SFP
> link is
> +static const struct nxp_c45_phy_stats nxp_c45_hw_stats[] = {
> + { "phy_symbol_error_cnt", MDIO_MMD_VEND1, SYMBOL_ERROR_COUNTER, 0,
> GENMASK(15, 0) },
> + { "phy_link_status_drop_cnt", MDIO_MMD_VEND1, LINK_DROP_COUNTER, 8,
> GENMASK(13, 8) },
> + {
ux/issues/1
> Fixes: fee2d546414d ("net: phy: marvell: mv88e6390 temperature sensor
> reading")
> Reviewed-by: Marek Behún
Reviewed-by: Andrew Lunn
Andrew
On Mon, Apr 12, 2021 at 05:49:04PM +0300, Radu Nicolae Pirea (NXP OSS) wrote:
> On Mon, 2021-04-12 at 16:23 +0200, Andrew Lunn wrote:
> > > It is purely a C45 device.
> >
> > > Even if the PHY will be based on the same IP or not, if it is a C45
> > > PHY, it
On Mon, Apr 12, 2021 at 05:52:39PM +0200, Pali Rohár wrote:
> On Monday 12 April 2021 17:32:33 Andrew Lunn wrote:
> > > Anyway, now I'm looking at phy/marvell.c driver again and it supports
> > > only 88E6341 and 88E6390 families from whole 88E63xxx range.
> > >
> Anyway, now I'm looking at phy/marvell.c driver again and it supports
> only 88E6341 and 88E6390 families from whole 88E63xxx range.
>
> So do we need to define for now table for more than
> MV88E6XXX_FAMILY_6341 and MV88E6XXX_FAMILY_6390 entries?
Probably not. I've no idea if the 6393 has an
On Mon, Apr 12, 2021 at 03:34:47PM +0200, Pali Rohár wrote:
> On Monday 12 April 2021 15:15:07 Andrew Lunn wrote:
> > > +static u16 mv88e6xxx_physid_for_family(enum mv88e6xxx_family family);
> > > +
> >
> > No forward declaration please. Move the code a
> > > +/* This table contains representative model for every family */
> > > +static const enum mv88e6xxx_model family_model_table[] = {
> > > + [MV88E6XXX_FAMILY_6095] = MV88E6095,
> > > + [MV88E6XXX_FAMILY_6097] = MV88E6097,
> > > + [MV88E6XXX_FAMILY_6185] = MV88E6185,
> > > +
> It is purely a C45 device.
> Even if the PHY will be based on the same IP or not, if it is a C45
> PHY, it will be supported by this driver. We are not talking about 2 or
> 3 PHYs. This driver will support all future C45 PHYs. That's why we
> named it "NXP C45".
So if in future you produce C45
> +static u16 mv88e6xxx_physid_for_family(enum mv88e6xxx_family family);
> +
No forward declaration please. Move the code around. It is often best
to do that in a patch which just moves code, no other changes. It
makes it easier to review.
> static int mv88e6xxx_mdio_read(struct mii_bus *bus,
On Mon, Apr 12, 2021 at 01:02:07PM +0300, Radu Nicolae Pirea (NXP OSS) wrote:
> On Fri, 2021-04-09 at 21:36 +0200, Andrew Lunn wrote:
> > On Fri, Apr 09, 2021 at 09:41:06PM +0300, Radu Pirea (NXP OSS) wrote:
> > > Add driver for tja1103 driver and for future NXP C45 PHYs.
>
> +static void mana_gd_deregiser_irq(struct gdma_queue *queue)
> +{
> + struct gdma_dev *gd = queue->gdma_dev;
> + struct gdma_irq_context *gic;
> + struct gdma_context *gc;
> + struct gdma_resource *r;
> + unsigned int msix_index;
> + unsigned long flags;
> +
> + /* At
> +static inline bool is_gdma_msg(const void *req)
> +{
> + struct gdma_req_hdr *hdr = (struct gdma_req_hdr *)req;
> +
> + if (hdr->req.hdr_type == GDMA_STANDARD_HEADER_TYPE &&
> + hdr->resp.hdr_type == GDMA_STANDARD_HEADER_TYPE &&
> + hdr->req.msg_size >= sizeof(struct
> > Currently the protocol versin is 0.1.1 You may ask why it's called
> > "drv version" rather than "protocol version" -- it's because the PF driver
> > calls it that way, so I think here the VF driver may as well use the same
> > name. BTW, the "drv ver" info is passed to the PF driver in the
On Sun, Apr 11, 2021 at 10:55:11PM +0200, Martin Blumenstingl wrote:
> Add support for .get_regs_len and .get_regs so it is easier to find out
> about the state of the ports on the GSWIP hardware. For this we
> specifically add the GSWIP_MAC_PSTATp(port) and GSWIP_MDIO_STATp(port)
> register
On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
> On Sat, 10 Apr 2021 15:34:46 +0200
> Ansuel Smith wrote:
>
> > Hi,
> > this is a respin of the Marek series in hope that this time we can
> > finally make some progress with dsa supporting multi-cpu port.
> >
> > This implementation
On Fri, Apr 09, 2021 at 09:41:06PM +0300, Radu Pirea (NXP OSS) wrote:
> Add driver for tja1103 driver and for future NXP C45 PHYs.
So apart from c45 vs c22, how does this differ to nxp-tja11xx.c?
Do we really want two different drivers for the same hardware?
Can we combine them somehow?
>
For the structs containing variables with the same sizes, or already size
aligned
> variables, we knew the __packed has no effect. And for these structs, it
> doesn't
> cause performance impact either, correct?
>
> But in the future, if different sized variables are added, the __packed may
Hi Sven
> Many thanks to Heiner Kallweit for suggesting this solution.
Adding a Suggested-by: would be good. And it might sometime help
Johnathan Corbet extract some interesting statistics from the commit
messages if everybody uses the same format.
Andrew
> Linux kernel doesn't do namespaces in the code, so every new driver needs
> to worry about global symbols clashing
This driver is called mana, yet the code uses ana. It would be good to
resolve this inconsistency as well. Ideally, you want to prefix
everything with ana_ or mana_, depending on
On Thu, Apr 08, 2021 at 11:00:08PM +0800, DENG Qingfang wrote:
> Hi René,
>
> On Thu, Apr 8, 2021 at 10:02 PM René van Dorst wrote:
> >
> > Tested on Ubiquiti ER-X-SFP (MT7621) with 1 external phy which uses
> > irq=POLL.
> >
>
> I wonder if the external PHY's IRQ can be registered in the
> > > diff --git a/drivers/net/ethernet/microsoft/Kconfig
> > b/drivers/net/ethernet/microsoft/Kconfig
> > > new file mode 100644
> > > index ..12ef6b581566
> > > --- /dev/null
> > > +++ b/drivers/net/ethernet/microsoft/Kconfig
> > > @@ -0,0 +1,30 @@
> > > +#
> > > +# Microsoft Azure
> If dropping the modifications to gswip_phylink_mac_config is my only change:
> do you want me to keep or drop your Reviewed-by in v2?
You can keep it.
Andrew
On Wed, Apr 07, 2021 at 12:50:38PM +0800, DENG Qingfang wrote:
> Enable MT7530 interrupt controller in the MT7621 SoC.
>
> Signed-off-by: DENG Qingfang
Reviewed-by: Andrew Lunn
Andrew
On Wed, Apr 07, 2021 at 12:50:37PM +0800, DENG Qingfang wrote:
> Add device tree binding to support MT7530 interrupt controller.
>
> Signed-off-by: DENG Qingfang
Reviewed-by: Andrew Lunn
Andrew
On Wed, Apr 07, 2021 at 12:50:36PM +0800, DENG Qingfang wrote:
> Add support for MT7530 interrupt controller to handle internal PHYs.
> In order to assign an IRQ number to each PHY, the registration of MDIO bus
> is also done in this driver.
>
> Signed-off-by: DENG Qingfang
> ---
> RFC v1 -> RFC
> Signed-off-by: DENG Qingfang
Reviewed-by: Andrew Lunn
Andrew
> For my own curiosity: is there a "recommended" way where to configure
> link up/down, speed, duplex and flow control? currently I have the
> logic in both, .phylink_mac_config and .phylink_mac_link_up.
You probably want to read the documentation in
include/linux/phylink.h
Andrew
On Wed, Apr 07, 2021 at 10:15:37PM +0800, Wong Vee Khee wrote:
> From: Tan Tee Min
>
> The Synopsis MAC controller supports auxiliary snapshot feature that
> allows user to store a snapshot of the system time based on an external
> event.
>
> This patch add supports to the above mentioned
> Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell
> multi-gige PHY can do rate adaption right?
The Marvell/Marvell multi-gige PHY can also do rate
adaptation. Marvell buying Aquantia made naming messy :-(
I should probably use part numbers.
> Hence, we still need to take care
> And, some variable defines can not follow the reverse christmas tree
> style due to dependency, e.g.
> static void hwc_init_event_handler(void *ctx, struct gdma_queue *q_self,
>struct gdma_event *event)
> {
> struct hw_channel_context *hwc = ctx;
>
> +static int gdma_query_max_resources(struct pci_dev *pdev)
> +{
> + struct gdma_context *gc = pci_get_drvdata(pdev);
> + struct gdma_general_req req = { 0 };
> + struct gdma_query_max_resources_resp resp = { 0 };
> + int err;
Network drivers need to use reverse christmas tree. I
On Tue, Apr 06, 2021 at 06:50:40AM +0200, Ansuel Smith wrote:
> qca8k 83xx switch have 2 cpu ports. Rework the driver to support
> multiple cpu port. All ports can access both cpu ports by default as
> they support the same features.
Do you have more information about how this actually works. How
> case PHY_INTERFACE_MODE_RGMII:
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> miicfg |= GSWIP_MII_CFG_MODE_RGMII;
> +
> + if (phylink_autoneg_inband(mode))
> +
IP automatically set
> the xMII clock")
> Cc: sta...@vger.kernel.org
> Acked-by: Hauke Mehrtens
> Signed-off-by: Martin Blumenstingl
Having the MAC polling the PHY is pretty much always a bad idea.
Reviewed-by: Andrew Lunn
Andrew
On Tue, Apr 06, 2021 at 05:49:03AM +0200, Ansuel Smith wrote:
> In preparation for the future when dsa will support multi cpu port,
> dsa_cpu_ports can be useful for switch that has multiple cpu port to
> retrieve the cpu mask for ACL and bridge table.
>
> Signed-off-by: Ansuel Smith
> ---
>
> The limitation is not on the MAC, PCS or the PHY. For Intel mgbe, the
> overclocking of 2.5 times clock rate to support 2.5G is only able to be
> configured in the BIOS during boot time. Kernel driver has no access to
> modify the clock rate for 1Gbps/2.5G mode. The way to determined the
>
On Tue, Apr 06, 2021 at 11:57:14PM +0800, DENG Qingfang wrote:
> On Tue, Apr 6, 2021 at 11:47 PM Chun-Kuang Hu wrote:
> >
> > Hi, Qingfang:
> >
> > DENG Qingfang 於 2021年4月6日 週二 下午10:19寫道：
> > > --- a/drivers/net/phy/Kconfig
> > > +++ b/drivers/net/phy/Kconfig
> > > @@ -207,6 +207,11 @@ config
On Tue, Apr 06, 2021 at 11:47:08PM +0800, Chun-Kuang Hu wrote:
> Hi, Qingfang:
>
> DENG Qingfang 於 2021年4月6日 週二 下午10:19寫道：
> >
> > Add support for MediaTek PHYs found in MT7530 and MT7531 switches.
> > The initialization procedure is from the vendor driver, but due to lack
> > of documentation,
On Tue, Apr 06, 2021 at 11:39:12PM +0800, DENG Qingfang wrote:
> On Tue, Apr 6, 2021 at 11:30 PM Andrew Lunn wrote:
> >
> > On Tue, Apr 06, 2021 at 10:18:17PM +0800, DENG Qingfang wrote:
> > > Add support for MT7530 interrupt controller to handle internal PHYs.
> >
On Tue, Apr 06, 2021 at 10:18:17PM +0800, DENG Qingfang wrote:
> Add support for MT7530 interrupt controller to handle internal PHYs.
Are the interrupts purely PHY interrupts? Or are there some switch
operation interrupts, which are currently not used?
I'm just wondering if it is correct to so
On Tue, Apr 06, 2021 at 10:18:16PM +0800, DENG Qingfang wrote:
> Add support for MediaTek PHYs found in MT7530 and MT7531 switches.
Do you know if this PHY is available standalone?
> +static int mt7531_phy_config_init(struct phy_device *phydev)
> +{
> + mtk_phy_config_init(phydev);
> +
> +
> > Speed: 2500Mb/s and Duplex: Half is very unlikely. You really only
> > ever see 10 Half and occasionally 100 Half. Anything above that will
> > be full duplex.
> >
> > It is probably best to admit the truth and use DUPLEX_UNKNOWN.
>
> Agreed. I didn't notice this "lie" until I was writing the
On Mon, Apr 05, 2021 at 04:13:40PM -0700, Grant Grundler wrote:
> This series introduces support for USB network devices that report
> speed as a part of their protocol, not emulating an MII to be accessed
> over MDIO.
>
> v2: rebased on recent upstream changes
> v3: incorporated hints on naming
On Tue, Apr 06, 2021 at 03:19:11AM +0800, kernel test robot wrote:
> Hi Michael,
>
> I love your patch! Yet something to improve:
Looks correct. You missed the #else case for #ifdef CONFIG_OF in
stmmac_platform.c
Lets see what else 0-day finds before i start reviewing.
Andrew
On Mon, Apr 05, 2021 at 08:39:54PM +0200, Corentin Labbe wrote:
> mdio0: ethernet-phy {
Not relevant to the brokennes, but this should not be called
ethernet-phy. The example given in
Documentation/devicetree/bindings/net/mdio-gpio.txt is
mdio0: mdio
> compatible =
> Now, instead of encoding this information of the bus' capabilities at both
> places, I'd propose just checking the mii_bus->capabilities field in the
> mdiobus_c45_*() functions. IMHO this would be a little cleaner, than having
> two
> places where this information is stored. What do you think
> > You have a MAC and an PCS in the stmmac IP block. That then has
> > some
> > sort of SERDES interface, running 1000BaseX, SGMII, SGMII
> > overclocked
> > at 2.5G or 25000BaseX. Connected to the SERDES you have a PHY
> > which
> > converts to copper, giving you 2500BaseT.
> >
> > You said
On Sun, Apr 04, 2021 at 09:23:55PM +0200, Danilo Krummrich wrote:
> On Fri, Apr 02, 2021 at 01:58:58PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Fri, Apr 02, 2021 at 03:10:49AM +0200, Danilo Krummrich wrote:
> > > On Thu, Apr 01, 2021 at 09:48:58AM +0100, Russell King - ARM Linux
On Mon, Apr 05, 2021 at 07:29:51PM +0800, Michael Sit Wei Hong wrote:
> This patchset enables 2.5Gbps speed mode for stmmac.
> Link speed mode is detected and configured at serdes power up sequence.
> For 2.5G, we do not use SGMII in-band AN, we check the link speed mode
> in the serdes and
On Mon, Apr 05, 2021 at 09:07:34AM +, Voon, Weifeng wrote:
> > On Fri, Apr 02, 2021 at 07:45:04AM +, Voon, Weifeng wrote:
> > > > > + /* 2.5G mode only support 2500baseT full duplex only */
> > > > > + if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
> > > > > +
> > Plus, i'm not actually sure we should be issuing warnings here. What
> > does the bridge code do in this case? Is it silent and just does it,
> > or does it issue a warning?
>
> :D
>
> What Oleksij doesn't know, I bet, is that he's using the bridge bypass
> commands:
>
> bridge fdb add dev
On Sat, Apr 03, 2021 at 01:48:46PM +0200, Oleksij Rempel wrote:
> This switch is providing forwarding matrix, with it we can configure
> individual bridges. Potentially we can configure more then one not VLAN
> based bridge on this HW.
>
> Signed-off-by: Oleksij Rempel
> ---
>
On Sat, Apr 03, 2021 at 01:48:45PM +0200, Oleksij Rempel wrote:
> This switch provides global ageing time configuration, so let DSA use
> it.
>
> Signed-off-by: Oleksij Rempel
Reviewed-by: Andrew Lunn
Andrew
> +static int ar9331_sw_port_fdb_rmw(struct ar9331_sw_priv *priv,
> + const unsigned char *mac,
> + u8 port_mask_set,
> + u8 port_mask_clr)
> +{
> + port_mask = FIELD_GET(AR9331_SW_AT_DES_PORT, f2);
> +
On Sat, Apr 03, 2021 at 01:48:43PM +0200, Oleksij Rempel wrote:
> Make sure that all external port are actually isolated from each other,
> so no packets are leaked.
>
> Signed-off-by: Oleksij Rempel
> ---
> drivers/net/dsa/qca/ar9331.c | 145 ++-
> 1 file
if (ret < 0)
> goto error;
>
> return 0;
> +
> error:
> dev_err_ratelimited(>dev, "Bus error. Failed to write
> register.\n");
> return ret;
With that:
Reviewed-by: Andrew Lunn
Andrew
> --
> 2.29.2
>
> @@ -31,6 +96,13 @@ static struct sk_buff *ar9331_tag_xmit(struct sk_buff *skb,
> __le16 *phdr;
> u16 hdr;
>
> + if (dp->stp_state == BR_STATE_BLOCKING) {
> + /* TODO: should we reflect it in the stats? */
> + netdev_warn_once(dev, "%s:%i dropping
On Fri, Apr 02, 2021 at 07:45:04AM +, Voon, Weifeng wrote:
> > > + /* 2.5G mode only support 2500baseT full duplex only */
> > > + if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
> > > + phylink_set(mac_supported, 2500baseT_Full);
> > > + phylink_set(mask,
> > Do you actually have a requirement for this?
> >
> Yes, the Marvell 88Q2112 1000Base-T1 PHY. But actually, I just recognize that
> it
> should be possible to just register it with the compatible string
> "ethernet-phy-ieee802.3-c22" instead of "ethernet-phy-ieee802.3-c45", this
> should
des to fetch the appropriate statistics which is not supported yet.
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
On Thu, Apr 01, 2021 at 02:17:50PM +0200, Mauro Carvalho Chehab wrote:
> The file name: Documentation/configuration.txt
> should be, instead: Documentation/networking/dsa/configuration.rst.
>
> Update its cross-reference accordingly.
>
> Fixes: 75b8988dfe83 ("cifsd: add server handler for
t;
> v4: added to series since cdc_ether uses same notifications
> as cdc_ncm driver.
>
> Signed-off-by: Grant Grundler
Reviewed-by: Andrew Lunn
Andrew
ions"
>
> v2: rebased on upstream
> v3: changed variable names
> v4: rewrote commit message
>
> Signed-off-by: Oliver Neukum
> Tested-by: Roland Dreier
> Signed-off-by: Grant Grundler
Reviewed-by: Andrew Lunn
Andrew
Roland Dreier
> Reviewed-by: Grant Grundler
> Tested-by: Grant Grundler
Reviewed-by: Andrew Lunn
Andrew
eworded commmit messages
>
> Signed-off-by : Oliver Neukum
> Tested-by: Roland Dreier
> Reviewed-by: Grant Grundler
> Tested-by: Grant Grundler
Reviewed-by: Andrew Lunn
Andrew
> > as per datasheet: https://www.ti.com/lit/ds/symlink/dp83867cr.pdf
>
> > 8.6.26 Control Register (CTRL)
> > do SW_RESTART to perform a reset not including the registers and is
> > acceptable to do this if a link is already present.
>
>
>
> I don't see any code here to
> @@ -670,19 +670,21 @@ struct phy_device *mdiobus_scan(struct mii_bus *bus,
> int addr)
> struct phy_device *phydev = ERR_PTR(-ENODEV);
> int err;
>
> + /* In case of NO_CAP and C22 only, we still can try to scan for C45
> + * devices, since indirect access will be used
On Tue, Mar 30, 2021 at 03:54:07PM +0200, Oleksij Rempel wrote:
> Port some parts of the stmmac selftest to the FEC. This patch was tested
> on iMX6DL.
> With this tests it is possible to detect some basic issues like:
> - MAC loopback fail: most probably wrong clock configuration.
> - PHY
1 - 100 of 5545 matches
Mail list logo
