> >> +static void
> >> +ax88796c_get_regs(struct net_device *ndev, struct ethtool_regs *regs,
> >> void *_p)
> >> +{
> >> + struct ax88796c_device *ax_local = to_ax88796c_device(ndev);
> >> + u16 *p = _p;
> >> + int offset, i;
> >> +
> >> + memset(p, 0, AX88796C_REGDUMP_LEN);
> >> +
> >> +
On Fri, Oct 16, 2020 at 09:35:27AM +0200, Christian Eggers wrote:
> If the supplied sk_buff is cloned (e.g. in dsa_skb_tx_timestamp()),
> __skb_put_padto() will allocate a new sk_buff with size = skb->len +
> padlen. So the condition just tested for (skb_tailroom(skb) >= padlen +
> len) is not
On Sun, Oct 11, 2020 at 03:31:52PM +0300, michael alayev wrote:
> Hello,
>
> This is my system's network topology. It relies on Xilinx's Zynq-7000 soc.
>
> zynq-7000 switch1 switch2
> (cpu) mv88e6390xmv88e6390x
> --- - -
> | | | |
> This router is currently not enabled in Openwrt
You have to be careful here. Not everything runs OpenWRT. You cannot
break backwards compatibility in mainline, simple as that. You need to
ensure that mainline does not see a change in the CPU port.
Andrew
On Wed, Oct 07, 2020 at 05:46:33PM -0400, Vivek Unune wrote:
> On Wed, Oct 07, 2020 at 11:01:34PM +0200, Andrew Lunn wrote:
> > On Wed, Oct 07, 2020 at 03:01:50PM -0400, Vivek Unune wrote:
> > > Forgo the use of mmioreg mdio mux infavor of the pinctrl
> >
> > Hi Viv
On Wed, Oct 07, 2020 at 03:01:51PM -0400, Vivek Unune wrote:
> Add port 5 and port 7 which are connected to gmac0 & 1 respectively
> DSA driver will use port 5 as cpu port and this works as well.
What port was used before this was added? The CPU port cannot be
changed because it can break user
On Wed, Oct 07, 2020 at 03:01:50PM -0400, Vivek Unune wrote:
> Forgo the use of mmioreg mdio mux infavor of the pinctrl
Hi Vivek
Could you add some more details please. I don't know this
hardware. I'm assuming there are two MDIO busses, external as talked
about in the comments, and an internal
> Signed-off-by: Christian Eggers
Reviewed-by: Andrew Lunn
Andrew
On Wed, Oct 07, 2020 at 03:13:15PM +0200, Christian Eggers wrote:
> Hi Andrew,
>
> > What chip_id values does it use? I don't see it listed in
> > ksz9477_switch_chips.
>
> here a short dump of the first chip registers:
>
> > Chip ID0 00
> > Chip ID1_2 9893 Chip ID
On Wed, Oct 07, 2020 at 11:30:49AM +0200, Christian Eggers wrote:
> Add support for the KSZ9563 3-Port Gigabit Ethernet Switch to the
> ksz9477 driver. The KSZ9563 supports both SPI (already in) and I2C. The
> ksz9563 is already in the device tree binding documentation.
Hi Christian
What chip_id
On Mon, Oct 05, 2020 at 05:19:50PM +0800, Jisheng Zhang wrote:
> Convert m88e1318_get_wol() to use the well implemented phy_read_paged()
> instead of open coding it.
>
> Signed-off-by: Jisheng Zhang
Reviewed-by: Andrew Lunn
Andrew
On Fri, Oct 02, 2020 at 04:17:34PM -0400, Jarod Wilson wrote:
> On Fri, Oct 2, 2020 at 2:09 PM Andrew Lunn wrote:
> >
> > On Fri, Oct 02, 2020 at 01:40:00PM -0400, Jarod Wilson wrote:
> > > Point users to the new interface names instead of the old ones, where
> >
> +static u32 ax88796c_get_link(struct net_device *ndev)
> +{
> + struct ax88796c_device *ax_local = to_ax88796c_device(ndev);
> +
> + mutex_lock(_local->spi_lock);
> +
> + phy_read_status(ndev->phydev);
> +
> + mutex_unlock(_local->spi_lock);
Why do you take this mutux before
On Fri, Oct 02, 2020 at 09:22:06PM +0200, Łukasz Stelmach wrote:
> This is a driver for AX88796C Ethernet Adapter connected in SPI mode as
> found on ARTIK5 evaluation board. The driver has been ported from a
> v3.10.9 vendor kernel for ARTIK5 board.
Hi Łukasz
Please include a brief list of
On Fri, Oct 02, 2020 at 01:40:00PM -0400, Jarod Wilson wrote:
> Point users to the new interface names instead of the old ones, where
> appropriate. Userspace bits referenced still include use of master/slave,
> but those can't be altered until userspace changes too, ideally after
> these changes
On Fri, Oct 02, 2020 at 12:26:49PM -0500, Dan Murphy wrote:
> Colin
>
> On 10/2/20 11:54 AM, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently the comparisons of u16 integers value and sopass_val with
> > less than zero for error checking is always false because the values
> > are
On Fri, Oct 02, 2020 at 07:49:49AM +0200, Mauro Carvalho Chehab wrote:
> The PHY kernel-doc markup has gained support for documenting
> a typedef enum.
>
> However, right now the parser was not prepared for it.
Hi Mauro
Thanks for this. I'm using Sphinx 3.2.1, since that is what my Debian
box
On Thu, Oct 01, 2020 at 04:20:12PM +0300, Vladimir Oltean wrote:
> 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
Andrew
el of the board and not with the hardware
> numbers of the switch chip ports. The 2 numbering schemes are
> shifted by 8.
>
> Signed-off-by: Vladimir Oltean
> Reviewed-by: Maxim Kochetkov
Reviewed-by: Andrew Lunn
Andrew
> > Can you run 1000Base-X over these links?
> With some reading "1000base-x" does seem the right thing to say here.
> It's even what is reflected in the CMODE field for those ports.
One more thing you might need is
managed = "in-band-status";
> > If you can, it is probably
> > worth chatting
> port@8 {
> reg = <8>;
> label = "internal8";
> phy-mode = "rgmii-id";
> fixed-link {
> speed =
On Wed, Sep 30, 2020 at 01:07:19PM -0700, Florian Fainelli wrote:
>
>
> On 9/30/2020 12:09 PM, Andrew Lunn wrote:
> > On Wed, Sep 30, 2020 at 05:47:43PM +0800, Jisheng Zhang wrote:
> > > Hi,
> > >
> > > A GE phy supports pad isolation which c
On Wed, Sep 30, 2020 at 05:47:43PM +0800, Jisheng Zhang wrote:
> Hi,
>
> A GE phy supports pad isolation which can save power in WOL mode. But once the
> isolation is enabled, the MAC can't send/receive pkts to/from the phy because
> the phy is "isolated". To make the PHY work normally, I need to
On Wed, Sep 30, 2020 at 07:07:25PM +0100, Russell King - ARM Linux admin wrote:
> On Wed, Sep 30, 2020 at 06:34:40PM +0200, Andrew Lunn wrote:
> > > @@ -2866,7 +2888,15 @@ EXPORT_SYMBOL_GPL(device_phy_find_device);
> > > */
> > > struct fwnode_handle *fwnode_get
> +/* Extract the phy ID from the compatible string of the form
> + * ethernet-phy-id..
> + */
> +int fwnode_get_phy_id(struct fwnode_handle *fwnode, u32 *phy_id)
> +{
> + unsigned int upper, lower;
> + const char *cp;
> + int ret;
> +
> + ret =
Hi Calvin
> priv->has_a011043 = device_property_read_bool(>dev,
> "fsl,erratum-a011043");
> -
> - ret = of_mdiobus_register(bus, np);
> - if (ret) {
> - dev_err(>dev, "cannot register MDIO bus\n");
> + if
On Tue, Sep 29, 2020 at 07:39:54PM +, Vladimir Oltean wrote:
> On Tue, Sep 29, 2020 at 09:11:53PM +0200, Andrew Lunn wrote:
> > > +_port0 {
> > > + managed = "in-band-status";
> > > + phy-handle = <_qsgmii_0>;
> > > + phy-mode = "
> +_port0 {
> + managed = "in-band-status";
> + phy-handle = <_qsgmii_0>;
> + phy-mode = "qsgmii";
> + /* ETH4 written on chassis */
> + label = "swp4";
If ETH4 is on the chassis why not use ETH4?
Andrew
led link attempts are required before
> falling back to 100M.
>
> Signed-off-by: Dan Murphy
Reviewed-by: Andrew Lunn
> + default:
> + phydev_err(phydev,
> +"Downshift count must be 1, 2, 4 or 8\n");
> + retur
On Mon, Sep 28, 2020 at 09:51:34AM -0500, Dan Murphy wrote:
> This adds WoL support on TI DP83869 for magic, magic secure, unicast and
> broadcast.
>
> Signed-off-by: Dan Murphy
Reviewed-by: Andrew Lunn
Andrew
ends on PCI
> select MDIO_CAVIUM
> + select MDIO_DEVRES
> help
> This driver supports the MDIO interfaces found on Cavium
> ThunderX SoCs when the MDIO bus device appears as a PCI
> --
> 2.28.0
Reviewed-by: Andrew Lunn
Andrew
luable in practice either.
>
> Just remove them.
>
> Signed-off-by: Sebastian Andrzej Siewior
> Signed-off-by: Thomas Gleixner
Reviewed-by: Andrew Lunn
Andrew
he integrated Marvell RTC controller)
> 6x SFP+ LED
> 1x HDD LED
>
> All of the hardware listed above is supported and tested in this port.
>
> Signed-off-by: Luka Kovacic
> Cc: Luka Perkov
> Cc: Robert Marko
I don't know this Marvell SoC too well, but what i see l
> I checked this again for the vendor u-boot (where Ethernet is NOT
> working) as well as the Android kernel which this board was shipped
> with (where Ethernet is working)
> - in u-boot the MAC side adds a 2ns TX delay and the PHY side adds a
> 2ns RX delay
So that suggest there is nothing on
> The reference code I linked tries to detect the RGMII interface mode.
> However, for each board we know the phy-mode as well as the RX and TX
> delay - so I'm not trying to port the RGMII interface detection part
> to the mainline driver.
>
> on X96 Air (which I'm using for testing) Amlogic
On Fri, Sep 25, 2020 at 11:47:18PM +0200, Martin Blumenstingl wrote:
> Hello,
>
> Amlogic's 12nm SoC generation requires some RGMII timing calibration
> within the Ethernet controller glue registers.
> This calibration is only needed for the RGMII modes, not for the
> (internal) RMII PHY.
> With
e future, please make the patch subject [PATCH net] to make it
clear which tree it is for.
Reviewed-by: Andrew Lunn
Andrew
On Fri, Sep 25, 2020 at 03:25:15PM +0800, Willy Liu wrote:
> There are two chip pins named TXDLY and RXDLY which actually adds the 2ns
> delays to TXC and RXC for TXD/RXD latching. These two pins can config via
> 4.7k-ohm resistor to 3.3V hw setting, but also config via software setting
>
On Fri, Sep 25, 2020 at 08:50:30AM +, David Laight wrote:
> From: Kai-Heng Feng
> > Sent: 24 September 2020 17:04
> ...
> > > I also don't fully understand the fix. You are now looping up to 6400
> > > times, each with a delay of 50uS. So that is around 12800 times more
> > > than it actually
[ 704.943155] e1000e :00:1f.6 eno1: MDI Error
> ...
> [ 705.108161] e1000e :00:1f.6 eno1: Hardware Error
>
> As Andrew Lunn pointed out, MDIO has nothing to do with phy, and indeed
> increase polling iteration can resolve the issue.
>
> The root cause is quite lik
On Thu, Sep 24, 2020 at 05:32:12PM +0200, Paul Menzel wrote:
> Dear Kai-Heng,
>
>
> Thank you for sending version 2.
>
> Am 24.09.20 um 17:09 schrieb Kai-Heng Feng:
> > We are seeing the following error after S3 resume:
>
> I’d be great if you added the system and used hardware, you are seeing
[ 704.943155] e1000e :00:1f.6 eno1: MDI Error
> ...
> [ 705.108161] e1000e :00:1f.6 eno1: Hardware Error
>
> As Andrew Lunn pointed out, MDIO has nothing to do with phy, and indeed
> increase polling iteration can resolve the issue.
>
> While at it, also move the de
> I modify the commit and resend this patch to "net tree", please reject this
> one.
Hi Xiaoliang Yang
You dropped "PATCH" from the subject. Please also include a version
number, so it is possible to identify which is the last version:
[PATCH net v2] net: dsa: felix: convert TAS link speed
> > > How much does this increase the resume time?
Define resume time? Until you get the display manager unlock screen?
Or do you need working networking?
It takes around 1.5 seconds for auto negotiation to get a link. I know
it takes me longer than that to move my fingers to the keyboard and
On Wed, Sep 23, 2020 at 04:25:28PM +0200, Stefan Riedmueller wrote:
> From: Christian Hemp
>
> Make use of device tree alias for device enumeration to keep the device
> order consistent with the naming in the datasheet.
>
> Otherwise for the i.MX 6UL/ULL the ENET1 interface is enumerated as
On Wed, Sep 23, 2020 at 10:44:10PM +0800, Kai-Heng Feng wrote:
> Hi Andrew,
>
> > On Sep 23, 2020, at 20:17, Andrew Lunn wrote:
> >
> > On Wed, Sep 23, 2020 at 03:47:51PM +0800, Kai-Heng Feng wrote:
> >> We are seeing the following error after S3 resume:
> &
ants). There is only
> >> one choice for i2c0 MPP14 and MPP15.
> >>
> >> Signed-off-by: Chris Packham
> >> Reviewed-by: Andrew Lunn
> > Reviewed-by: Linus Walleij
> >
> > Please merge this through the ARM SoC maintenance path.
>
> Ar
On Wed, Sep 23, 2020 at 03:47:51PM +0800, Kai-Heng Feng wrote:
> We are seeing the following error after S3 resume:
> [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
> [ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete
> [ 704.902817] e1000e :00:1f.6 eno1:
On Wed, Sep 23, 2020 at 02:06:25PM +0800, yue longguang wrote:
> From: ylg
>
> adjust the debug order of src and dst when tcp state changes
Hi Yue
You need to explain why you are doing something, not what you are
doing, in the commit message.
Andrew
> Subject: Re: [RFC][Patch v1 1/3] sched/isolation: API to get num of
> hosekeeping CPUs
Hosekeeping? Are these CPUs out gardening in the weeds?
Andrew
On Mon, Sep 21, 2020 at 03:10:53PM -0700, Florian Fainelli wrote:
> BCM72113 features a 28nm integrated EPHY, add an entry to the driver for
> it.
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
On Mon, Sep 21, 2020 at 09:13:54AM +0800, Jisheng Zhang wrote:
> Enable ALDPS(Advanced Link Down Power Saving) to save power when
> link down.
>
> Signed-off-by: Jisheng Zhang
Reviewed-by: Andrew Lunn
Andrew
On Mon, Sep 21, 2020 at 07:00:00AM +, 劉偉權 wrote:
> Hi Andrew,
> I removed below register layout descriptions because these
> descriptions did not match register definitions for rtl8211e
> extension page 164 reg 0x1c at all.
> 8:6 = PHY Address
> 5:4 = Auto-Negotiation
> 3 = Mode
> 2 = RXD
> 1
-s use the same controller and Clause 45 compliant
> PHY-s.
>
> Signed-off-by: Robert Marko
> Cc: Luka Perkov
Reviewed-by: Andrew Lunn
Andrew
On Sun, Sep 20, 2020 at 02:39:39AM +0200, ansuels...@gmail.com wrote:
>
>
> > -Messaggio originale-----
> > Da: Andrew Lunn
> > Inviato: domenica 20 settembre 2020 02:31
> > A: Ansuel Smith
> > Cc: Miquel Raynal ; Richard Weinberger
> > ; Vigne
> + mac-address-increment:
> +description:
> + The MAC address can optionally be increased (or decreased using
> + negative values) from the original value readed (from a nvmem cell
Read is irregular, there is no readed, just read.
> + for example). This can be used if the
> +
> +/* 0 = Clause 22, 1 = Clause 45 */
> +#define MDIO_MODE_BITBIT(8)
How about calling this MDIO_MODE_C45
> + /* Enter Clause 45 mode */
> + data = readl(priv->membase + MDIO_MODE_REG);
> +
> + data |= MDIO_MODE_BIT;
> +
> +
On Sat, Sep 19, 2020 at 07:43:28PM +0300, Oded Gabbay wrote:
> It's probably heresy, but why do I need to integrate into the RDMA subsystem ?
Hi Oded
I don't know the RDMA subsystem at all. So i will give a more generic
answer. Are you reinventing things which a subsystem core already has?
The
On Fri, Sep 18, 2020 at 02:14:53PM -0500, Dan Murphy wrote:
> Update the fiber advertisement for speed and duplex modes with the
> 100base-FX full and half linkmode entries.
>
> Signed-off-by: Dan Murphy
Reviewed-by: Andrew Lunn
Andrew
On Fri, Sep 18, 2020 at 02:14:52PM -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 fiber mode.
>
> Signed-off-by: Dan Murphy
R
0:00:00:00:00:00
> Current message level: 0x (0)
>
> Link detected: yes
>
> Signed-off-by: Dan Murphy
Reviewed-by: Andrew Lunn
Andrew
On Fri, Sep 18, 2020 at 09:02:43AM +, 劉偉權 wrote:
> Hi Andrew,
> Thanks for your information. Should I do any modifications to make this patch
> be applied?
Please do not to post. And wrap your text to about 75 characters.
Since i think you are new to posting to netdev, we tend to be
On Fri, Sep 18, 2020 at 06:55:16AM +, 劉偉權 wrote:
> Hi Serge,
> Thanks for your reply. There is a confidential issue that realtek
> doesn't offer the detail of a full register layout for configuration
> register.
...
> > * 0xa4 extension page (0x7) layout. It can be used to
On Fri, Sep 18, 2020 at 10:47:56AM +0800, Jisheng Zhang wrote:
> Enable ALDPS function to save power when link down.
Hi Jisheng
It would be nice to give a hint what ALDPS means. It is not one of the
standard acronyms i know of, so it could be Realtek specific.
>
> Signed-off-by: Jisheng Zhang
;
> Because the PHY driver can be probed with the clocks turned off we need
> to apply the dummy BMSR workaround during the driver probe function to
> ensure subsequent MDIO read or write towards the PHY will succeed.
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
On Fri, Sep 18, 2020 at 12:40:10AM +0300, Sergej Bauer wrote:
> From: sba...@blackbox.su
>
> Here is a kernel related part of my work which was helps to develop brand
> new PHY device.
>
> It is migth be helpful for developers work with PHY-less lan743x
> (7431:0011 in my case). It's
> On the other hand, the enums are part of userspace API so I better take
> a closer look to make sure we don't run into some trouble there.
Hi Michal
Yes, that is what i was thinking about. But i guess you can pass a
tagged enum to a function expecting an int and the compiler will
silently cast
bus
> controller and embedded memory.
>
> Signed-off-by: Willy Liu
Hi Willy
Before submitting any more patches, please take a look at:
https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html
Reviewed-by: Andrew Lunn
Andrew
On Wed, Sep 16, 2020 at 07:04:13PM -0700, Florian Fainelli wrote:
> The internal Gigabit PHY on Broadcom STB chips has a digital clock which
> drives its MDIO interface among other things, the driver now requests
> and manage that clock during .probe() and .remove() accordingly.
>
> Because the
On Thu, Sep 17, 2020 at 01:04:10AM +0200, Michal Kubecek wrote:
> Tunnel offload info code uses ETHTOOL_MSG_TUNNEL_INFO_GET message type (cmd
> field in genetlink header) for replies to tunnel info netlink request, i.e.
> the same value as the request have. This is a problem because we are using
>
On Wed, Sep 16, 2020 at 03:54:34PM -0500, Dan Murphy wrote:
> Andrew
>
> On 9/15/20 3:17 PM, Andrew Lunn wrote:
> > > + linkmode_set_bit(ETHTOOL_LINK_MODE_100baseFX_Full_BIT,
> > > + phydev->supported);
&g
On Tue, Sep 15, 2020 at 01:17:06PM -0500, Dan Murphy wrote:
> Add entries for the 100base-FX full and half duplex supported modes.
>
> $ ethtool eth0
> Supported ports: [ TPMII FIBRE ]
> Supported link modes: 10baseT/Half 10baseT/Full
>
> I completely understand but you didn't answer my question. How come
> there are drivers which create netdev objects, and specifically sgi-xp
> in misc (but I also saw it in usb drivers) that live outside
> drivers/net ? Why doesn't your request apply to them as well ?
> When we wrote the code,
> + linkmode_set_bit(ETHTOOL_LINK_MODE_100baseFX_Full_BIT,
> + phydev->supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_100baseFX_Half_BIT,
> + phydev->supported);
> +
> + /* Auto neg is not supported
On Tue, Sep 15, 2020 at 01:17:06PM -0500, Dan Murphy wrote:
> @@ -160,6 +160,8 @@ static const struct phy_setting settings[] = {
> PHY_SETTING(100, FULL,100baseT_Full ),
> PHY_SETTING(100, FULL,100baseT1_Full),
> PHY_SETTING(100, HALF,
> +static int gaudi_nic_get_module_eeprom(struct net_device *netdev,
> + struct ethtool_eeprom *ee, u8 *data)
> +{
> + struct gaudi_nic_device **ptr = netdev_priv(netdev);
> + struct gaudi_nic_device *gaudi_nic = *ptr;
> + struct hl_device *hdev =
> +static struct gaudi_nic_ethtool_stats gaudi_nic_mac_stats_rx[] = {
> + {"Rx MAC counters", 0},
> + {" etherStatsOctets", 0x0},
> + {" OctetsReceivedOK", 0x4},
> + {" aAlignmentErrors", 0x8},
> + {" aPAUSEMACCtrlFramesReceived", 0xC},
> + {" aFrameTooLongErrors",
On Fri, Sep 11, 2020 at 11:40:20AM +0530, Divya Koppera wrote:
> LAN8814 is a low-power, quad-port triple-speed (10BASE-T/100BASETX/1000BASE-T)
> Ethernet physical layer transceiver (PHY). It supports transmission and
> reception of data on standard CAT-5, as well as CAT-5e and CAT-6, unshielded
>
> - Do all PHYs support manual setting of the LED level, or are the PHYs
> that can only work with HW triggers?
There are PHYs with do not have simple on/off.
> - Is setting PHY registers always efficiently possible, or should SW
> triggers be avoided in certain cases? I'm thinking about setups
On Thu, Sep 10, 2020 at 11:30:33PM +0300, Oded Gabbay wrote:
> On Thu, Sep 10, 2020 at 11:25 PM Andrew Lunn wrote:
> >
> > > Can you please elaborate on how to do this with a single driver that
> > > is already in misc ?
> > > As I mentioned in the
> We already have different support for blinking in LED subsystem. Lets use
> that.
You are assuming we have full software control of the LED, we can turn
it on and off. That is not always the case. But there is sometimes a
mode which the hardware blinks the LED.
Being able to blink the LED is
> Can you please elaborate on how to do this with a single driver that
> is already in misc ?
> As I mentioned in the cover letter, we are not developing a
> stand-alone NIC. We have a deep-learning accelerator with a NIC
> interface.
This sounds like an MFD.
Andrew
> +static int gaudi_nic_get_link_ksettings(struct net_device *netdev,
> + struct ethtool_link_ksettings *cmd)
> +{
> + struct gaudi_nic_device **ptr = netdev_priv(netdev);
> + struct gaudi_nic_device *gaudi_nic = *ptr;
> + struct hl_device *hdev =
> I propose that at least these HW modes should be available (and
> documented) for ethernet PHY controlled LEDs:
> mode to determine link on:
> - `link`
> mode for activity (these should blink):
> - `activity` (both rx and tx), `rx`, `tx`
> mode for link (on) and activity (blink)
>
On Thu, Sep 10, 2020 at 08:24:34PM +0200, Pavel Machek wrote:
> On Thu 2020-09-10 15:15:41, Andrew Lunn wrote:
> > On Thu, Sep 10, 2020 at 02:23:41PM +0200, Pavel Machek wrote:
> > > On Wed 2020-09-09 18:25:51, Marek Behún wrote:
> > > > This patch adds support for
> The note in the ethtool.h says
>
> /* Last allowed bit for __ETHTOOL_LINK_MODE_LEGACY_MASK is bit
> * 31. Please do NOT define any SUPPORTED_* or ADVERTISED_*
> * macro for bits > 31. The only way to use indices > 31 is to
> * use the new
> > > static int dp83869_config_port_mirroring(struct phy_device *phydev)
> > > {
> > > struct dp83869_private *dp83869 = phydev->priv;
> > Overall this code looks quite similar to dp83867, is there no way to
> > factor this out?
>
> Factor what out? Yes the DP83867 and DP83869 are
> Moreover I propose (and am willing to do) this:
> Rewrite phy_led_trigger so that it registers one trigger, `phydev`.
> The identifier of the PHY which should be source of the trigger can be
> set via a separate sysfs file, `device_name`, like in netdev trigger.
> The linked speed on
On Thu, Sep 10, 2020 at 02:23:41PM +0200, Pavel Machek wrote:
> On Wed 2020-09-09 18:25:51, 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,
> They are in /sys/class/net/eth0/phydev/leds by default, because they
> are children of the PHY device and are of `leds` class, and the PHY
> subsystem creates a symlink `phydev` when PHY is attached to the
> interface.
> They are in /sys/class/leds/ as symlinks, because AFAIK everything in
>
On Wed, Sep 09, 2020 at 06:25:45PM +0200, Marek Behún wrote:
> Hello Andrew and Pavel,
>
> please review these patches adding support for HW controlled LEDs.
> The main difference from previous version is that the API is now generalized
> and lives in drivers/leds, so that part needs to be
On Wed, Sep 09, 2020 at 06:25:46PM +0200, Marek Behún wrote:
> Document binding for LEDs connected to and controlled by various chips
> (such as ethernet PHY chips).
>
> Signed-off-by: Marek Behún
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> ---
> .../leds/linux,hw-controlled-leds.yaml
On Wed, Sep 09, 2020 at 10:49:31AM -0700, Florian Fainelli wrote:
> We already maintain an array of VLANs used by the switch so we can
> simply iterate over it to report the occupancy via devlink.
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
> @@ -1314,6 +1314,21 @@ static struct phy_driver ksphy_driver[] = {
> .get_stats = kszphy_get_stats,
> .suspend= genphy_suspend,
> .resume = kszphy_resume,
> +}, {
> + .phy_id = PHY_ID_LAN8814,
> + .phy_id_mask= MICREL_PHY_ID_MASK,
> +
On Wed, Sep 09, 2020 at 12:36:38PM +0200, Pavel Machek wrote:
> Hi!
>
> > > Add support for the iEi WT61P803 PUZZLE LED driver.
> > > Currently only the front panel power LED is supported.
> > >
> > > This driver depends on the iEi WT61P803 PUZZLE MFD driver.
> >
> > Can we make it OF
On Tue, Sep 08, 2020 at 07:49:20PM +0200, Lukasz Stelmach wrote:
> It was <2020-09-07 pon 20:18>, when Andrew Lunn wrote:
> >> > On Tue, Aug 25, 2020 at 07:03:09PM +0200, Łukasz Stelmach wrote:
> >> >> +++ b/drivers/net/ethernet/asix/ax88796c_ioctl.c
&
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
601 - 700 of 5545 matches
Mail list logo
