On Tue, Sep 08, 2020 at 09:30:50AM +0200, Andre Heider wrote:
> Now that the switch ports have a label in the .dtsi, simplify the whole
> "switch0" block for the v7 dts files.
>
> Signed-off-by: Andre Heider
Reviewed-by: Andrew Lunn
Andrew
On Mon, Sep 07, 2020 at 09:04:48PM +, Chris Packham wrote:
>
> On 8/09/20 3:45 am, Andrew Lunn wrote:
> > On Mon, Sep 07, 2020 at 02:41:48PM +1200, Chris Packham wrote:
> >> The switches with integrated CPUs have only got a single i2c controller.
> >> The incorre
> As a result of this cleanup should be binary DTB file for V7 with same
> structure as DTB file without such cleanup patch, right?
Should be. If need be, you can decompile the DTB back to a DTS and
make sure it looks correct.
Andrew
> > On Tue, Aug 25, 2020 at 07:03:09PM +0200, Łukasz Stelmach wrote:
> >> +++ b/drivers/net/ethernet/asix/ax88796c_ioctl.c
> >
> > This is an odd filename. The ioctl code is wrong anyway, but there is
> > a lot more than ioctl in here. I suggest you give it a new name.
> >
>
> Sure, any
> My dts-foo is a little rusty, but now that you labeled the ports in the
> .dtsi, can this whole "switch0" block reduced to something like:
>
> {
> label = "lan1";
> };
>
> {
> label = "wan";
> };
Probably yes.
But that is definitely too much for stable.
Andrew
On Mon, Sep 07, 2020 at 06:13:16PM +0200, Pali Rohár wrote:
> On Monday 07 September 2020 17:43:53 Andrew Lunn wrote:
> > > I would not say it is a "new feature". But rather that patch in this
> > > email fixes issue that Linux kernel did not set correct MAC addre
On Sat, Sep 05, 2020 at 11:17:55AM -0700, Jakub Kicinski wrote:
> On Thu, 3 Sep 2020 06:42:57 -0500 Dan Murphy wrote:
> > Add the ability to advertise the Fiber connection if the strap or the
> > op-mode is configured for 100Base-FX.
> >
> > Auto negotiation is not supported on this PHY when in
On Mon, Sep 07, 2020 at 02:41:49PM +1200, Chris Packham wrote:
> Add pinctrl information for the 98dx3236 (and variants). There is only
> one choice for i2c0 MPP14 and MPP15.
>
> Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
Andrew
; armada-xp-98dx3236")
> Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
Andrew
ith
> 0x1 which works.
>
> Fixes: d7ae8f8dee7f ("pinctrl: mvebu: pinctrl driver for 98DX3236 SoC")
> Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
Andrew
> I would not say it is a "new feature". But rather that patch in this
> email fixes issue that Linux kernel did not set correct MAC address for
> DSA slave ports. I think it is something which could be backported also
> to stable releases as "ignoring" vendor/factory MAC address is not
> correct
On Mon, Sep 07, 2020 at 01:27:17PM +0200, Pali Rohár wrote:
> Espressobin boards have 3 ethernet ports and some of them got assigned more
> then one MAC address. MAC addresses are stored in U-Boot environment.
>
> Since commit a2c7023f7075c ("net: dsa: read mac address from DT for slave
>
this cpufreq driver when is compiled as an external module.
>
> Signed-off-by: Pali Rohár
> Fixes: 92ce45fb875d7 ("cpufreq: Add DVFS support for Armada 37xx")
Reviewed-by: Andrew Lunn
Andrew
f-test=patterns complains:
>
> warning: no file matchesF:drivers/net/phy/pcs-lynx.c
>
> Repair the LYNX PCS MODULE section by referring to the right location.
>
> Signed-off-by: Lukas Bulwahn
Reviewed-by: Andrew Lunn
Andrew
ng like this (irrelevant parts omitted for simplicity):
Hi Florian
Thanks for the extended commit message.
Reviewed-by: Andrew Lunn
Andrew
On Sat, Sep 05, 2020 at 03:03:36PM +0200, Luka Kovacic wrote:
> +_mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + status = "okay";
> +
> + ge_phy2: ethernet-phy@2 {
> + reg = <0>;
Hi Luka
The value after the @ should be the same as the reg value.
So
On Thu, Sep 03, 2020 at 09:00:13PM -0700, Florian Fainelli wrote:
>
>
> On 9/3/2020 3:03 PM, Andrew Lunn wrote:
> > > The firmware provides the Device Tree but here is the relevant section for
> > > you pasted below. The problematic device is a particular revision of t
> > > +static int prestera_is_valid_mac_addr(struct prestera_port *port, u8
> > > *addr)
> > > +{
> > > + if (!is_valid_ether_addr(addr))
> > > + return -EADDRNOTAVAIL;
> > > +
> > > + if (memcmp(port->sw->base_mac, addr, ETH_ALEN - 1))
> >
> > Why ETH_ALEN - 1?
> >
>
> The firmware provides the Device Tree but here is the relevant section for
> you pasted below. The problematic device is a particular revision of the
> silicon (D0) which got later fixed (E0) however the Device Tree was created
> after the fixed platform, not the problematic one. Both revisions
> > > #define DP83867_CFG4_SGMII_ANEG_MASK (BIT(5) | BIT(6))
> > > #define DP83867_CFG4_SGMII_ANEG_TIMER_11MS (3 << 5)
> > > #define DP83867_CFG4_SGMII_ANEG_TIMER_800US (2 << 5)
> > > -#define DP83867_CFG4_SGMII_ANEG_TIMER_2US (1 << 5)
> > > +#define DP83867_CFG4_SGMII_ANEG_TIMER_2US
On Wed, Sep 02, 2020 at 02:03:27PM -0700, Florian Fainelli wrote:
> Registering our slave MDIO bus outside of the OF infrastructure is
> necessary in order to avoid creating double references of the same
> Device Tree nodes, however it is not sufficient to guarantee that the
> MDIO bus diversion
On Wed, Sep 02, 2020 at 02:27:04PM -0500, Dan Murphy wrote:
> Fix the registers being written to as the values were being over written
> when writing the same registers.
>
> Fixes: caabee5b53f5 ("net: phy: dp83867: support Wake on LAN")
> Signed-off-by: Dan Murphy
On Wed, Sep 02, 2020 at 07:05:25PM +0200, Pali Rohár wrote:
> On Wednesday 02 September 2020 19:00:10 Andrew Lunn wrote:
> > > > > + switch (ret) {
> > > > > + case SMCCC_RET_SUCCESS:
> > > > > + return
> > > + switch (ret) {
> > > + case SMCCC_RET_SUCCESS:
> > > + return 0;
> > > + case SMCCC_RET_NOT_SUPPORTED:
> > > + return -EOPNOTSUPP;
> > > + default:
> > > + return -EINVAL;
> > > + }
> > > }
> >
> > Hi Pali
> >
> > Maybe this should be a global helper translating
On Wed, Sep 02, 2020 at 04:43:43PM +0200, Pali Rohár wrote:
> Driver ->power_on and ->power_off callbacks leaks internal SMCC firmware
> return codes to phy caller. This patch converts SMCC error codes to
> standard linux errno codes. Include file linux/arm-smccc.h already provides
> defines for
On Tue, Sep 01, 2020 at 03:59:12PM -0700, Florian Fainelli wrote:
> Fetch the corresponding clock resource and enable/disable it during
> suspend/resume if and only if we have no ports defined for Wake-on-LAN.
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
45 switch
> as there is no clocking profile available for BCM7278.
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
;sw_switch_mdiv".
Hi Florian
Since you look clocks up by name, i don't think the order matters.
Otherwise:
Reviewed-by: Andrew Lunn
Andrew
On Fri, Aug 28, 2020 at 05:09:52PM -0600, Rob Herring wrote:
> On Fri, Aug 28, 2020 at 7:00 AM Andrew Lunn wrote:
> >
> > On Fri, Aug 28, 2020 at 04:19:39AM +0200, Andrew Lunn wrote:
> > > When building without CONFIG_OF and W=1, errors are given about unused
> > &
> > > You could make a good guess at matching to two together, but it is
> > > error prone. Phys are low level things which the user is not really
> > > involved in. They interact with interface names. ethtool, ip, etc, all
> > > use interface names. In fact, i don't know of any tool which uses
>
On Sun, Aug 30, 2020 at 12:43:51AM +0200, Pavel Machek wrote:
> Hi!
>
> > > > And no, I don't want phydev name there.
> > >
> > > Ummm. Can we get little more explanation on that? I fear that LED
> > > device renaming will be tricky and phydev would work around that
> > > nicely.
> >
> > Hi
On Fri, Aug 28, 2020 at 04:19:39AM +0200, Andrew Lunn wrote:
> When building without CONFIG_OF and W=1, errors are given about unused
> arrays of match data, because of_match_node is stubbed as a macro. The
> compile does not see it takes parameters when not astub, so it
> generates wa
these false warnings.
Signed-off-by: Andrew Lunn
---
include/linux/of.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 5cf7ae0465d1..e9838387e7d9 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -991,7 +991,12
-off-by: Landen Chao
Reviewed-by: Andrew Lunn
Andrew
On Thu, Aug 27, 2020 at 08:45:08AM -0500, Dan Murphy wrote:
> Add a dt binding for the TI dp83822 ethernet phy device.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Dan Murphy
Reviewed-by: Andrew Lunn
Andrew
ned-off-by: Dan Murphy
Reviewed-by: Andrew Lunn
Andrew
> (I can't imagine SPI being fast enough to be useful for ethernet...)
There are plenty of IoT things which only need a few kbit/s.
A VoIP phone can probably get by with 128Kbps, which a 50Mbps SPI bus
has no problem to provide, etc.
Andrew
> >> +module_param(comp, int, 0);
> >> +MODULE_PARM_DESC(comp, "0=Non-Compression Mode, 1=Compression Mode");
> >> +
> >> +module_param(ps_level, int, 0);
> >> +MODULE_PARM_DESC(ps_level,
> >> + "Power Saving Level (0:disable 1:level 1 2:level 2)");
> >> +
> >> +module_param(msg_enable, int, 0);
> There is a limitation on the DMA range. Current device can't handle
> whole ZONE_DMA range, so there is a "backup" mechanism which copies the
> entire packet if the mapping was failed or if the packet's mapped
> address is out of this range, this is done on both rx and tx directions.
If you use
On Tue, Aug 25, 2020 at 07:03:10PM +0200, Łukasz Stelmach wrote:
> Add node for ax88796c ethernet chip.
Hi Łukasz
You need to document the device tree binding.
Andrew
Hi Łukasz
It is pretty clear this is a "vendor crap driver". It needs quite a
bit more work on it.
On Tue, Aug 25, 2020 at 07:03:09PM +0200, Łukasz Stelmach wrote:
> +++ b/drivers/net/ethernet/asix/ax88796c_ioctl.c
This is an odd filename. The ioctl code is wrong anyway, but there is
a lot more
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 8dcb8a49ab67..e81198a65c26 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -1327,6 +1327,7 @@ mt7530_setup(struct dsa_switch *ds)
> if (phy_node->parent ==
y: Dinghao Liu
Reviewed-by: Andrew Lunn
Andrew
On Sun, Aug 23, 2020 at 07:31:16PM +0530, Sumera Priyadarsini wrote:
> Every iteration of for_each_child_of_node() decrements
> the reference count of the previous node, however when control
> is transferred from the middle of the loop, as in the case of
> a return or break or goto, there is no
On Thu, Aug 20, 2020 at 10:00:21AM +, Mickey Rachamim wrote:
> > ASIC device specific handling is serviced by the firmware, current
> > driver's logic does not have PP specific code and relies on the FW
> > ABI which is PP-generic, and it looks like this how it should work
> > for boards with
On Fri, Aug 21, 2020 at 09:21:46AM +0200, Matthias Schiffer wrote:
> These DT bindings are already in use by the imx7-mba7 DTS, but they were
> not supported by the PHY driver so far.
>
> Signed-off-by: Matthias Schiffer
Sorry, but NACK.
Please look at the work Marek Behún is doing
> In general, according to phy.rst, RGMII delay should be done by phy, but
> some MoCA product need RGMII delay in MAC. These two requirements
> conflict. Is there any suggestion to solve the conflict?
Implementing the delay in the PHY is just a recommendation, not a
requirement. However, as i
On Mon, Aug 17, 2020 at 09:03:54PM -0700, Florian Fainelli wrote:
> We return the VLAN table size through devlink as a simple parameter, we
> do not support altering it at runtime:
>
> devlink resource show mdio_bus/fixed-0:1f
> mdio_bus/fixed-0:1f:
> name VTU size 4096 occ 4096 unit entry
probe for ACPI devices")
> Signed-off-by: YueHaibing
Hi YueHaibing
Please take a look at:
commit 0c65b2b90d13c1deaee6449304dd367c5d4eb8ae
Author: Andrew Lunn
Date: Mon Nov 4 02:40:33 2019 +0100
net: of_get_phy_mode: Change API to solve int/unit warnings
You probably want to follow this basic idea.
Andrew
On Tue, Aug 18, 2020 at 03:14:11PM +0800, Landen Chao wrote:
> Add mt7531 dsa to mt7622-rfb1 board for 5 giga Ethernet ports support.
> mt7622 only supports 1 sgmii interface, so either gmac0 or gmac1 can be
> configured as sgmii interface. In this patch, change to connet mt7622
connect
On Tue, Aug 18, 2020 at 03:14:10PM +0800, Landen Chao wrote:
> Add new support for MT7531:
>
> MT7531 is the next generation of MT7530. It is also a 7-ports switch with
> 5 giga embedded phys, 2 cpu ports, and the same MAC logic of MT7530. Cpu
> port 6 only supports SGMII interface. Cpu port 5
On Tue, Aug 18, 2020 at 03:14:08PM +0800, Landen Chao wrote:
> Add a structure holding required operations for each device such as device
> initialization, PHY port read or write, a checker whether PHY interface is
> supported on a certain port, MAC port setup for either bus pad or a
> specific
On Tue, Aug 18, 2020 at 03:14:07PM +0800, Landen Chao wrote:
> Remove 1000baseT_Half to advertise correct hardware capability in
> phylink_validate() callback function.
Hi Landem
This seems like a fix? Please submit it against the net tree, and add
a Fixes: tag.
Thanks
Andrew
> > > Currently
> > >
> > > compatible = "marvell,prestera"
> > >
> > > is used as default, so may be
> > >
> > > you mean to support few matching including particular silicon too, like ?
> > >
> > >
> > > compatible = "marvell,prestera"
> > > compatible = "marvell,prestera-ac3x"
> net/dev/stats/tx_bytes/annotations
> DESCRIPTION net\ device\ transmited\ bytes\ count
> CUMULATIVE
> net/dev/stats/tx_bytes/fields
> interface value
> str int
> net/dev/stats/tx_bytes/values
> lo 4394430608
> eth0 33353183843
> eth1 16228847091
This is a rather small system. Have
> > And no, I don't want phydev name there.
>
> Ummm. Can we get little more explanation on that? I fear that LED
> device renaming will be tricky and phydev would work around that
> nicely.
Hi Pavel
The phydev name is not particularly nice:
!mdio-mux!mdio@1!switch@0!mdio:00
On Wed, Aug 05, 2020 at 11:47:38AM -0700, Joe Perches wrote:
> On Wed, 2020-08-05 at 19:22 +0100, Russell King - ARM Linux admin wrote:
> > On Wed, Aug 05, 2020 at 11:11:28AM -0700, Linus Torvalds wrote:
> > > On Wed, Aug 5, 2020 at 7:34 AM Russell King
> > > wrote:
> > > > Is this something
> > Well, until the user of this new API is ready, we will not accept the
> > patch.
> OK, but once we submit the change in the driver, is it good to go?
No. You really do need to explain why it is needed, and why it is
safe.
> > You also need to explain "For HW performance reasons". Why is this
On Tue, Aug 04, 2020 at 08:47:18PM +0300, Ilia Lin wrote:
> Hi Andrew and David,
Hi Ilia
Please don't top post.
>
> Thank you for your comments!
>
> The client driver is still work in progress, but it can be seen here:
>
est robot
> Fixes: 1814cff26739 ("net: phy: add a Kconfig option for mdio_devres")
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andrew Lunn
Andrew
> > @@ -736,6 +777,16 @@ struct phy_driver {
> > int (*set_loopback)(struct phy_device *dev, bool enable);
> > int (*get_sqi)(struct phy_device *dev);
> > int (*get_sqi_max)(struct phy_device *dev);
> > +
> > + /* PHY LED support */
> > + int (*led_init)(struct phy_device *dev,
> +static int of_phy_register_led(struct phy_device *phydev, struct device_node
> *np)
> +{
> + struct led_init_data init_data = {};
> + struct phy_device_led *led;
> + u32 reg;
> + int ret;
> +
> + ret = of_property_read_u32(np, "reg", );
> + if (ret < 0)
> +
extack")
> Signed-off-by: René van Dorst
> Signed-off-by: Frank Wunderlich
Reviewed-by: Andrew Lunn
Andrew
On Sun, Jul 26, 2020 at 10:37:54PM +0300, Ilia Lin wrote:
> From: Ilia Lin
>
> Add an API that returns true, if the net_dev_init was already called,
> and the driver was initialized.
>
> Some early drivers, that are initialized during the subsys_initcall
> may try accessing the net_dev or NAPI
> > > +#if 0
> > > + /* LED_COLOR_ID_MULTI is not yet merged in Linus' tree */
> > > + /* TODO: Support DUAL MODE */
> > > + if (color == LED_COLOR_ID_MULTI) {
> > > + phydev_warn(phydev, "node %pOF: This driver does not yet
> > > support multicolor LEDs\n",
> > > +
On Sat, Jul 25, 2020 at 08:02:24PM +0200, Marek Behun wrote:
> On Sat, 25 Jul 2020 19:23:18 +0200
> Andrew Lunn wrote:
>
> > On Fri, Jul 24, 2020 at 06:46:03PM +0200, Marek Behún wrote:
> > > This patch adds support for controlling the LEDs connected to several
> >
On Sat, Jul 25, 2020 at 07:39:50PM +0200, Marek Behun wrote:
> On Sat, 25 Jul 2020 17:03:42 +0200
> Andrew Lunn wrote:
>
> > Does hi-z mean off? In the implementation i did, i did not list off
> > and on as triggers. I instead used them for untriggered
> > brightness
On Fri, Jul 24, 2020 at 06:46:03PM +0200, Marek Behún wrote:
> This patch adds support for controlling the LEDs connected to several
> families of Marvell PHYs via the PHY HW LED trigger API. These families
> are: 88E1112, 88E1121R, 88E1240, 88E1340S, 88E1510 and 88E1545. More can
> be added.
>
>
On Fri, Jul 24, 2020 at 06:46:02PM +0200, Marek Behún wrote:
> Many PHYs support various HW control modes for LEDs connected directly
> to them.
>
> This code adds a new private LED trigger called phydev-hw-mode. When
> this trigger is enabled for a LED, the various HW control modes which
> the
On Sat, Jul 25, 2020 at 11:34:50AM +0200, Marek Behun wrote:
> On Sat, 25 Jul 2020 11:23:39 +0200
> Pavel Machek wrote:
>
> > Hi!
> >
> > > +static const struct marvell_led_mode_info marvell_led_mode_info[] = {
> > > + { "link", { 0x0, -1, 0x0, -1, -1, -1, }, 0 },
> >
On Fri, Jul 24, 2020 at 12:38:40PM +0200, Luka Kovacic wrote:
> An entry is added for MikroTik CRS3xx 98DX3236 based switches.
>
> Signed-off-by: Luka Kovacic
> Cc: Luka Perkov
> Cc: Jakov Petrina
Reviewed-by: Andrew Lunn
Andrew
has a
> bigger Macronix flash.
>
> This device tree includes basic Linux support.
>
> Signed-off-by: Luka Kovacic
> Cc: Luka Perkov
> Cc: Jakov Petrina
Reviewed-by: Andrew Lunn
Andrew
has a
> bigger Macronix flash.
>
> This device tree includes basic Linux support.
>
> Signed-off-by: Luka Kovacic
> Cc: Luka Perkov
> Cc: Jakov Petrina
Reviewed-by: Andrew Lunn
Andrew
has a
> bigger Macronix flash.
>
> This device tree includes basic Linux support.
>
> Signed-off-by: Luka Kovacic
> Cc: Luka Perkov
> Cc: Jakov Petrina
Reviewed-by: Andrew Lunn
Andrew
On Fri, Jul 24, 2020 at 11:21:19AM +1200, Chris Packham wrote:
> This series connects up the mv88e6xxx switches to the dsa infrastructure for
> configuring the port MTU. The first patch is also a bug fix which might be a
> candiatate for stable.
>
> I've rebased this series on top of
t; based MTU.
>
> Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
Andrew
On Fri, Jul 24, 2020 at 12:24:03PM +0200, Pavel Machek wrote:
> Hi!
>
> > > I expect some of this should be moved into the phylib core. We don't
> > > want each PHY inventing its own way to do this. The core should
> > > provide a framework and the PHY driver fills in the gaps.
> > >
> > > Take
On Thu, Jul 23, 2020 at 08:13:19PM +0200, Marek Behún wrote:
> This patch adds support for controlling the LEDs connected to several
> families of Marvell PHYs via Linux' LED API. These families are:
> 88E1112, 88E1121R, 88E1240, 88E1340S, 88E1510 and 88E1545. More can be
> added.
>
> The code
On Thu, Jul 23, 2020 at 08:50:27PM +, Chris Packham wrote:
>
> On 24/07/20 1:31 am, Andrew Lunn wrote:
> > On Thu, Jul 23, 2020 at 03:59:41PM +1200, Chris Packham wrote:
> >> Add implementations for the mv88e6xxx switches to connect with the
> >> generic
On Thu, Jul 23, 2020 at 03:59:42PM +1200, Chris Packham wrote:
> Some of the chips in the mv88e6xxx family don't support jumbo
> configuration per port. But they do have a chip-wide max frame size that
> can be used. Use this to approximate the behaviour of configuring a port
> based MTU.
>
>
On Thu, Jul 23, 2020 at 03:59:41PM +1200, Chris Packham wrote:
> Add implementations for the mv88e6xxx switches to connect with the
> generic dsa operations for configuring the port MTU.
Hi Chris
What tree is this against?
commit 2a550aec36543b20f087e4b3063882e9465f7175
Author: Andre
On Thu, Jul 23, 2020 at 03:59:40PM +1200, Chris Packham wrote:
> The MV88E6190 and MV88E6190X both support per port jumbo configuration
> just like the other GE switches. Install the appropriate ops.
>
> Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
Andrew
> Remove the erroneous function pointer assignment.
>
> Fixes: 5f430d65 ("net: dsa: mv88e6xxx: Refactor setting of jumbo frames")
> Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
Andrew
On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
> NAPI gets scheduled on the CPU core which got the
> interrupt. The linux scheduler cannot move it to a
> different core, even if the CPU on which NAPI is running
> is heavily loaded. This can lead to degraded wifi
> performance when
> @@ -755,7 +765,6 @@ static int macb_mdiobus_register(struct macb *bp)
>* decrement it before returning.
>*/
> of_node_put(child);
> -
> return of_mdiobus_register(bp->mii_bus, np);
> }
k shorthands are used for elegance and readability).
> This allowed us to drop all conversions/mappings between the driver
> and Ethtool.
>
> This involves changes in qede and qedf as well, as they used definitions
> from shared "qed_if.h".
>
> Suggested-by: Andr
On Mon, Jul 20, 2020 at 09:08:00PM +0300, Alexander Lobakin wrote:
> Add a new helper to find intersections between Ethtool link modes,
> linkmode_intersects(), similar to the other linkmode helpers.
>
> Signed-off-by: Alexander Lobakin
> Signed-off-by: Igor Russkikh
Reviewed-
On Sun, Jul 19, 2020 at 11:14:40PM +0300, Alexander Lobakin wrote:
> Currently qed driver already ran out of 32 bits to store link modes,
> and this doesn't allow to add and support more speeds.
> Convert link mode to bitmap that will always have enough space for
> any number of speeds and modes.
> If we have the core network stack reference DSA as a module then we
> force DSA to be either built-in or not, which is not very practical,
> people would still want a modular choice to be possible. The static
> inline only wraps indirect function pointer calls using definitions
> available at
> +#if IS_ENABLED(CONFIG_NET_DSA)
> +#define dsa_build_ndo_op(name, arg1_type, arg1_name, arg2_type, arg2_name) \
> +static int inline dsa_##name(struct net_device *dev, arg1_type arg1_name, \
> + arg2_type arg2_name) \
> +{
On Fri, Jul 17, 2020 at 08:05:30PM -0700, Florian Fainelli wrote:
> In preparation for adding another layer of call into a DSA stacked ops
> singleton, wrap the ndo_do_ioctl() call into dev_do_ioctl().
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
0x1
> +#define AT803X_SFC_MANUAL_MDI0x0
Interestingly, these are the same bits as for the Marvell PHY. I had a
quick look at 802.3. The functionality is standardized, but not the
registers.
Reviewed-by: Andrew Lunn
Andrew
On Fri, Jul 17, 2020 at 04:21:51PM +0100, Mark Einon wrote:
> On Fri, 2020-07-17 at 15:40 +0200, Andrew Lunn wrote:
> > On Fri, Jul 17, 2020 at 02:21:35PM +0100, Mark Einon wrote:
> > > Following the removal of an unused variable assignment (remove
> > > unused variab
On Sat, Jul 18, 2020 at 02:20:11PM +0100, Russell King - ARM Linux admin wrote:
> On Fri, Jul 17, 2020 at 10:44:19PM +0200, John Crispin wrote:
> > in regards to the sgmii clk skew. I never understood the electrics fully I
> > am afraid, but without the patch it simply does not work. my eletcric
On Fri, Jul 17, 2020 at 02:21:35PM +0100, Mark Einon wrote:
> Following the removal of an unused variable assignment (remove
> unused variable 'pm_csr') the associated register read can also go,
> as the read also occurs in the subsequent et1310_in_phy_coma()
> call.
Hi Mark
Do you have any
On Thu, Jul 16, 2020 at 03:09:25PM -0700, Jakub Kicinski wrote:
> On Mon, 13 Jul 2020 21:50:26 +0100 Matthew Hagan wrote:
> > Add names and decriptions of additional PORT0_PAD_CTRL properties.
> >
> > Signed-off-by: Matthew Hagan
> > ---
> > Documentation/devicetree/bindings/net/dsa/qca8k.txt |
On Thu, Jul 16, 2020 at 07:17:27PM +0200, Marek Behún wrote:
> Hello,
>
> this RFC series should apply on both net-next/master and Pavel's
> linux-leds/for-master tree.
>
> This adds support for LED's connected to some Marvell PHYs.
>
> LEDs are specified via device-tree. Example:
Hi Marek
> OK. So, i'll cover both errata with separate flags? Set flags in the DSA
> driver and apply workarounds in the PHY. ACK?
Yes. Assume the issues are limited to just the first PHY in this
switch. If there are discrete PHYs with the same issue, we can come up
with a different way to identify them.
On Mon, Jul 13, 2020 at 07:34:16PM +0300, Vladimir Oltean wrote:
> On Thu, Jul 09, 2020 at 11:35:23PM +0200, Michael Walle wrote:
> > The constants are taken from the USXGMII Singleport Copper Interface
> > specification. The naming are based on the SGMII ones, but with an MDIO_
> > prefix.
> >
>
est robot
> Fixes: 1814cff26739 ("net: phy: add a Kconfig option for mdio_devres")
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andrew Lunn
Andrew
701 - 800 of 5549 matches
Mail list logo
