> @@ -1552,6 +1552,7 @@ static int marvell_read_status_page(struct phy_device
> *phydev, int page)
> phydev->asym_pause = 0;
> phydev->speed = SPEED_UNKNOWN;
> phydev->duplex = DUPLEX_UNKNOWN;
> + phydev->port = fiber ? PORT_FIBRE : PORT_TP;
>
> if (phydev->autoneg
> Right at the beginning - we implemented PP function into the Kernel
> driver like the SDMA operation (This is the RX/TX DMA engine).
> We do plan to port more and more PP functions as Kernel drivers
> along the way.
It will be interesting to see how well you manage to handle the 'split
brain'
> Regarding splitting the series up. I don't see a problem in just
> sending the cover-letter patch and actual GPIO-related patches to
> the GPIO-maintainers with no need to have them added to Cc in the rest
> of the series.
The Linux community has to handle a large number of patches. I don't
> At the same time some FW is necessary. Certain chip functions, are
> best driven by a micro-controller running a tight control loop.
For a smart NIC, i could agree. But a switch? The data path is in
hardware. The driver is all about configuring this hardware, and then
it is idle. Polls the
moving the #define, it
will fail at compile time, making it obvious the support has been
removed?
Otherwise:
Reviewed-by: Andrew Lunn
Andrew
On Tue, Feb 09, 2021 at 02:00:18AM +0100, Michael Walle wrote:
> genphy_read_status() is already the default for the .read_status() op.
> Drop the unnecessary references.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
> > I took a quick look at it, and what I found left me very puzzled. I hope
> > you do not mind me asking a generic question about the policy around
> > switchdev drivers. If someone published a driver using something similar
> > to the following configuration flow:
> >
> > iproute2 daemon(SDK)
On Mon, Feb 08, 2021 at 05:08:04PM +0300, Serge Semin wrote:
Hi Serge
I suggest you split this patchset up. This uses the generic GPIO
framework, which is great. But that also means you should be Cc: the
GPIO subsystem maintainers and list. But you don't want to spam them
with all the
On Mon, Feb 08, 2021 at 05:03:30PM +0300, Serge Semin wrote:
> There has been no user of the denoted array of the device private data
> since commit e7f4dc3536a4 ("mdio: Move allocation of interrupts into
> core"). Discard it then.
>
> Signed-off-by: Serge Semin
vior I'd be glad to test it out on my device.
It is a reasonable explanation, and a read should not do any harm.
Reviewed-by: Andrew Lunn
Andrew
On Mon, Feb 08, 2021 at 05:03:22PM +0300, Serge Semin wrote:
> It has been noticed that RTL8211E PHY stops detecting and reporting events
> when EEE is successfully advertised and RXC stopping in LPI is enabled.
> The freeze happens right after 3.0.10 bit (PC1R "Clock Stop Enable"
> register) is
On Mon, Feb 08, 2021 at 12:31:34AM -0600, Samuel Holland wrote:
> On 2/8/21 12:28 AM, Samuel Holland wrote:
> > In commit e5c02cf54154 ("i2c: mv64xxx: Add runtime PM support"), error
> > pointers to optional clocks were replaced by NULL to simplify the resume
> > callback implementation. However,
+ priv->cm3_base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(priv->cm3_base))
> + return PTR_ERR(priv->cm3_base);
> +
> + return 0;
> +}
This looks much better. Thanks
Reviewed-by: Andrew Lunn
Andrew
On Sun, Feb 07, 2021 at 08:38:43PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> Patch adds CM3 address space PPv2.3 description.
>
> Signed-off-by: Stefan Chulski
> ---
> Documentation/devicetree/bindings/net/marvell-pp2.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2
On Sun, Feb 07, 2021 at 10:19:12AM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> This patch adds CM3 memory map and CM3 read/write callbacks.
> No functionality changes.
>
> Signed-off-by: Stefan Chulski
> ---
> drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 7 +++
>
On Fri, Feb 05, 2021 at 02:42:23PM +0100, Takashi Iwai wrote:
> On Fri, 05 Feb 2021 14:13:02 +0100,
> Andrew Lunn wrote:
> >
> > Hi Takashi
> >
> > > Indeed, looks so. In most cases, this doesn't matter since both point
> > > to the same device
> > > +bool lan937x_is_internal_tx_phy_port(struct ksz_device *dev, int
> > > port)
> > > +{
> > > + /* Check if the port is internal tx phy port */
> >
> > What is an internal TX phy port? Is it actually a conventional t2
> > Fast
> > Ethernet port, as opposed to a t1 port?
> This is 100
Hi Takashi
> Indeed, looks so. In most cases, this doesn't matter since both point
> to the same device object. In some cases like xhci-plat HCD, they
> differ. And sysdev might be a better choice from the consistency
> POV.
>
> But this brought an interesting question, too. eg. USB
On Fri, Feb 05, 2021 at 01:36:43PM +0100, Hans Verkuil wrote:
> Hi Takashi,
>
> Thank you for this patch, but it clashes with another patch trying to do the
> same thing
> that has already been merged in our tree:
>
>
On Thu, Feb 04, 2021 at 02:29:11PM -0700, Jonathan Corbet wrote:
> Lubomir Rintel writes:
>
> > Just remove these; there's good chance there wasn't anything useful
> > there anyway.
> >
> > Signed-off-by: Lubomir Rintel
> >
> > ---
> > Changes since v1:
> > - Adjust for removal of "[PATCH 1/5]
> > > + sdhci_pins: sdhi-pins {
> >
> > sdhi-pins ?
> >
> [KP] You mean to replace the underline with dash?
I think he would like a c added in the correct place.
Andrew
> > Reviewed-by: Andrew Lunn
> >
> > Andrew
>
> Just wondering, now, a v2 patch isn't needed? Or should I amend the commit
> text?
Hi Mike
Take a look in patchwork.kernel.org. It has been flaky the last few
days. If the patch is not there, you definitively nee
> +static int mv_config_init(struct phy_device *phydev)
> +{
> + linkmode_zero(phydev->supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, phydev->supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, phydev->supported);
> +
> diff --git a/drivers/net/ethernet/microchip/lan743x_main.c
> b/drivers/net/ethernet/microchip/lan743x_main.c
> index f1f6eba4ace4..f485320e5784 100644
> --- a/drivers/net/ethernet/microchip/lan743x_main.c
> +++ b/drivers/net/ethernet/microchip/lan743x_main.c
> @@ -1957,11 +1957,11 @@ static int
On Thu, Jan 28, 2021 at 09:45:41AM +0100, Mike Looijmans wrote:
> Hi Andrew,
>
> Response below...
Hi Mike
Everybody here knows that top posting is evil, we don't do it. We
expect the replay to be inline.
> > Hi Mike
> >
> > Did you look at the per PHY reset? mdiobus_register_gpiod() gets the
> + /* For T1 PHY */
> + if (lan937x_is_internal_t1_phy_port(dev, port)) {
> + phylink_set(mask, 100baseT_Full);
> + phylink_set_port_modes(mask);
Since this is a T1 PHY, you should be using 100baseT1_Full.
This might be the first user of this for phylink, so
> +bool lan937x_is_internal_phy_port(struct ksz_device *dev, int port)
> +{
> + /* Check if the port is RGMII */
> + if (port == LAN937X_RGMII_1_PORT || port == LAN937X_RGMII_2_PORT)
> + return false;
> +
> + /* Check if the port is SGMII */
> + if (port ==
On Thu, Jan 28, 2021 at 12:11:06PM +0530, Prasanna Vengateshan wrote:
> The Microchip LAN937X switches have a tagging protocol which is
> very similar to KSZ tagging. So that the implementation is added to
> tag_ksz.c and reused common APIs
>
> Signed-off-by: Prasanna Vengateshan
> ---
>
On Wed, Jan 27, 2021 at 06:08:16PM -0800, Ronak Doshi wrote:
> buf_info structures in RX & TX queues are private driver data that
> do not need to be visible to the device. Although there is physical
> address and length in the queue descriptor that points to these
> structures, their layout is
On Tue, Jan 26, 2021 at 08:33:37AM +0100, Mike Looijmans wrote:
> The mdio_bus reset code first de-asserted the reset by allocating with
> GPIOD_OUT_LOW, then asserted and de-asserted again. In other words, if
> the reset signal defaulted to asserted, there'd be a short "spike"
> before the reset.
On Thu, Jan 28, 2021 at 12:25:55AM +, Russell King - ARM Linux admin wrote:
> On Thu, Jan 28, 2021 at 01:00:57AM +0100, Andrew Lunn wrote:
> > On Tue, Jan 26, 2021 at 01:49:38PM +, Russell King - ARM Linux admin
> > wrote:
> > > On Tue, Jan 26, 2021 at 02:14:40PM
On Tue, Jan 26, 2021 at 01:49:38PM +, Russell King - ARM Linux admin wrote:
> On Tue, Jan 26, 2021 at 02:14:40PM +0100, Andrew Lunn wrote:
> > On Tue, Jan 26, 2021 at 08:33:37AM +0100, Mike Looijmans wrote:
> > > The mdio_bus reset code first de-asserted the r
> +static void otx2_get_link_mode_info(u64 index, int mode,
> + struct ethtool_link_ksettings
> + *link_ksettings)
> +{
> + u64 ethtool_link_mode = 0;
> + int bit_position = 0;
> + u64 link_modes = 0;
> +
> + /* CGX
On Wed, Jan 27, 2021 at 01:15:49PM +0530, Hariprasad Kelam wrote:
> From: Christina Jacob
>
> CGX LMAC, the physical interface support link configuration parameters
> like speed, auto negotiation, duplex etc. Firmware saves these into
> memory region shared between firmware and this driver.
>
On Tue, Jan 26, 2021 at 08:33:37AM +0100, Mike Looijmans wrote:
> The mdio_bus reset code first de-asserted the reset by allocating with
> GPIOD_OUT_LOW, then asserted and de-asserted again. In other words, if
> the reset signal defaulted to asserted, there'd be a short "spike"
> before the reset.
> Ok! If this is the only remaining issue, I will update commit messages
> and send a new patch series. I was just waiting for a response if
> somebody else has other comments or if somebody write that is fine with
> it.
Hi Pali
As a general rule of thumb, with netdev, wait 3 days and then send
On Mon, Jan 25, 2021 at 12:43:22PM +0800, DENG Qingfang wrote:
> MT7530's LED controller can drive up to 15 LED/GPIOs.
>
> Add support for GPIO control and allow users to use its GPIOs by
> setting gpio-controller property in device tree.
>
> Signed-off-by: DENG Qingfang
R
75b5 ("net: ks8851: Implement Parallel bus operations")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Andrew Lunn
Andrew
On Mon, Jan 25, 2021 at 12:43:21PM +0800, DENG Qingfang wrote:
> Add device tree binding to support MT7530 GPIO controller.
>
> Signed-off-by: DENG Qingfang
Reviewed-by: Andrew Lunn
Andrew
On Sun, Jan 24, 2021 at 02:43:30PM +, Stefan Chulski wrote:
> >
> > --
> > On Sun, Jan 24, 2021 at 01:43:57PM +0200, stef...@marvell.com wrote:
> > > +/* Set Flow Control timer x140 faster than pause quanta to ensure
> > >
On Sun, Jan 24, 2021 at 01:55:42PM +, Stefan Chulski wrote:
> > > Signed-off-by: Stefan Chulski
> > > ---
> > > drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 24 --
> > --
> > > drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +-
> > > 2 files changed, 25
On Sun, Jan 24, 2021 at 12:44:43PM +, Russell King - ARM Linux admin wrote:
> On Sun, Jan 24, 2021 at 01:43:52PM +0200, stef...@marvell.com wrote:
> > + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > + if (!priv->sram_pool) {
> > + if
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index a07cf60..c969a2d 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -25,6 +25,7 @@
> #include
>
> it migth be helpful for developers work on userspace networking tools with
> PHY-less lan743x
(the interface even could not be brought up)
> of course, there nothing much to do without TP port but the difference is
> representative.
>
> sbauer@metamini ~$ sudo ethtool eth7
> Settings for eth7:
> > > @@ -1000,8 +1005,10 @@ static void lan743x_phy_close(struct
> > > lan743x_adapter *adapter)>
> > > struct net_device *netdev = adapter->netdev;
> > >
> > > phy_stop(netdev->phydev);
> > >
> > > - phy_disconnect(netdev->phydev);
> > > - netdev->phydev = NULL;
> > > + if
On Sat, Jan 23, 2021 at 12:42:41AM +0300, Sergej Bauer wrote:
> From: sba...@blackbox.su
>
> v1->v2:
> switch to using of fixed_phy as was suggested by Andrew and Florian
> also features-related parts are removed
This is not using fixed_phy, at least not in the normal way.
Take a
On Thu, Jan 21, 2021 at 08:34:18PM +0100, Pali Rohár wrote:
> Signed-off-by: Pali Rohár
Reviewed-by: Andrew Lunn
Andrew
On Thu, Jan 21, 2021 at 08:34:17PM +0100, Pali Rohár wrote:
> Signed-off-by: Pali Rohár
Fixes: dc7a12bdfccd ("docs: arm: convert docs to ReST and rename to *.rst")
Reviewed-by: Andrew Lunn
Andrew
00
> Hz
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
> >> @@ -1218,6 +1218,12 @@ T: git
> >> git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor
> >> F:Documentation/admin-guide/LSM/apparmor.rst
> >> F:security/apparmor/
> >> +APPLE ADVANCED INTERRUPT CONTROLLER DRIVER
> >> +M:Stan Skowronek
> >
> > Signing
> + introduced ethtool tunable to control SPI compression
> >>
>
> [...]
>
> >>
> >> The other ax88796 driver is for NE2000 compatible AX88796L chip. These
> >> chips are not compatible. Hence, two separate drivers are required.
> &
On Tue, Jan 19, 2021 at 09:32:40AM +0100, Horatiu Vultur wrote:
> The 01/18/2021 21:27, Vladimir Oltean wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Mon, Jan 18, 2021 at 09:20:36PM +0100, Horatiu Vultur wrote:
> > > The
> to avoid self-shadowing and potentially improve bug-catching.
> No functional changes implied.
>
> Signed-off-by: Alexander Lobakin
Reviewed-by: Andrew Lunn
Andrew
essed while the
> device is suspended, causing undefined behavior, which may crash the
> system.
>
> Fix this by wrapping the PHY bitbang accessors in the sh_eth driver by
> wrappers that take care of Runtime PM, to resume the device when needed.
>
> Reported-by: Wolfram Sang
> Suggested-by: Andrew Lunn
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Andrew Lunn
Andrew
On Thu, Jan 14, 2021 at 04:13:23PM +, Stefan Chulski wrote:
> > > From: Stefan Chulski
> > >
> > > This patch doesn't change any functionality, but just extend MIB
> > > counter register and ethtool-statistic names with "err".
> > >
> > > The counter MVPP2_MIB_FRAGMENTS_RCVD in fact is Error
On Thu, Jan 14, 2021 at 12:07:38PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> This patch doesn't change any functionality, but just extend
> MIB counter register and ethtool-statistic names with "err".
>
> The counter MVPP2_MIB_FRAGMENTS_RCVD in fact is Error counter.
> Extend
> +static int sparx5_switch_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct mchp_reset_context *ctx =
> + container_of(rcdev, struct mchp_reset_context, reset_ctrl);
> + u32 val;
> +
> + /* Make sure the core
> Not sure what you mean, the patch is above the comment (line 265 vs
> 345). The patch is on top of 5.10, is that the issue?
All networking patches for the next merge window should be against
net-next. Please see:
https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html
which talks
On Mon, Jan 11, 2021 at 04:36:53PM -0800, Jakub Kicinski wrote:
> On Sun, 10 Jan 2021 21:23:02 +0200 stef...@marvell.com wrote:
> > From: Stefan Chulski
> >
> > Packet Processor hardware not connected to MAC flow control unit and
> > cannot support TX flow control.
> > This patch disable flow
On Mon, Jan 11, 2021 at 02:06:56PM +0100, Bjarni Jonasson wrote:
> Sparx-5 supports this mode and it is missing in the PHY core.
>
> Signed-off-by: Bjarni Jonasson
Reviewed-by: Andrew Lunn
Andrew
ignores it.
>
> Fixes: bedd8d78aba3 ("net: phy: smsc: LAN8710/20: add phy refclk in support")
> Suggested-by: Jakub Kicinski
> Signed-off-by: Marco Felsch
Reviewed-by: Andrew Lunn
Andrew
On Sun, Jan 10, 2021 at 06:27:12PM +0100, Arnd Bergmann wrote:
> On Sun, Jan 10, 2021 at 5:48 PM Andrew Lunn wrote:
> >
> > > For this platform, I'm most interested in whether there are still users
> > > that rely on board files instead of DT. AFAIU we could jus
On Sun, Jan 10, 2021 at 07:11:53PM +, Stefan Chulski wrote:
> >
> > On Sun, Jan 10, 2021 at 06:55:11PM +, Stefan Chulski wrote:
> > > > > not connected to the GOP flow control generation mechanism.
> > > > > To solve this issue Armada has firmware running on CM3 CPU
> > > > > dedectated
On Sun, Jan 10, 2021 at 06:55:11PM +, Stefan Chulski wrote:
> > > not connected to the GOP flow control generation mechanism.
> > > To solve this issue Armada has firmware running on CM3 CPU dedectated
> > > for Flow Control support. Firmware monitors Packet Processor resources
> > > and
On Sun, Jan 10, 2021 at 05:57:14PM +, Stefan Chulski wrote:
> > > + } else {
> > > + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > > + if (!priv->sram_pool) {
> > > + dev_warn(>dev, "DT is too old, TX FC
> > disabled\n");
> >
> > I don't see anything
> > Should there be -EPROBE_DEFER handling in here somewhere? The SRAM is a
> > device, so it might not of been probed yet?
>
> No, firmware probed during bootloader boot and we can use SRAM. SRAM
> memory can be safely used.
A previous patch added:
+ CP11X_LABEL(cm3_sram):
On Sun, Jan 10, 2021 at 05:30:22PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> This patch add ring size validation before enabling FC.
> 1. Flow control cannot be enabled if ring size is below start
> threshold.
> 2. Flow control disabled if ring size set below start
>
> @@ -5373,6 +5402,30 @@ static int mvpp2_ethtool_set_pause_param(struct
> net_device *dev,
>struct ethtool_pauseparam *pause)
> {
> struct mvpp2_port *port = netdev_priv(dev);
> + int i;
> +
> + if (pause->tx_pause &&
On Sun, Jan 10, 2021 at 05:30:10PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> BM pool size increased to support Firmware Flow Control.
> Minimum depletion thresholds to support FC is 1024 buffers.
> BM pool size increased to 2048 to have some 1024 buffers
> space between
> +static int mvpp2_get_sram(struct platform_device *pdev,
> + struct mvpp2 *priv)
> +{
> + struct device_node *dn = pdev->dev.of_node;
> + struct resource *res;
> +
> + if (has_acpi_companion(>dev)) {
> + res = platform_get_resource(pdev,
> For this platform, I'm most interested in whether there are still users
> that rely on board files instead of DT. AFAIU we could just fold
> the DT variant into arch-mvebu like kirkwood was, right?
Hi Arnd
I'm actually booting my device using a board file. But Debian
flash-kernel is pretty
> Then there are ARM platforms that are old but have still seen some work
> in the past years. If I hear nothing, these will all stay, but if maintainers
> may want to drop them anyway, I can help with that:
Hi Arnd
I notice orion5x is not on this list. Is that because of Debian still
building
On Sat, Jan 09, 2021 at 03:46:01PM +, Russell King - ARM Linux admin wrote:
> On Thu, Jan 07, 2021 at 05:54:28PM +0100, Andrew Lunn wrote:
> > On Wed, Jan 06, 2021 at 04:37:48PM +0100, Pali Rohár wrote:
> > > From: Russell King
> > >
> > > Some GPON SFP mo
On Fri, Jan 08, 2021 at 10:51:55AM +0800, DENG Qingfang wrote:
> This was for OpenWrt's swconfig driver, which never made it upstream,
> and was also superseded by MT7530 DSA driver.
What about
Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt ?
Should that also be removed?
ing, in case the PHY has been configured on probe with
> slew rate or DLL settings these needs to be restored thus call
> driver's config_init() on resume.
>
> Signed-off-by: Claudiu Beznea
Reviewed-by: Andrew Lunn
Andrew
> + if (sfp->i2c_block_size < 2) {
> + dev_info(sfp->dev, "skipping hwmon device registration "
> +"due to broken EEPROM\n");
> + dev_info(sfp->dev, "diagnostic EEPROM area cannot be read "
> +"atomically
so assume that LOS signal is not
> implemented.
>
> This patch fixes link carrier for GPON SFP module Ubiquiti U-Fiber Instant.
>
> Signed-off-by: Russell King
> Signed-off-by: Pali Rohár
Reviewed-by: Andrew Lunn
Andrew
32 33 20 20 60 80 02 41 140123 `??A
>
> Signed-off-by: Pali Rohár
Reviewed-by: Andrew Lunn
Andrew
On Thu, Jan 07, 2021 at 10:26:12AM +0100, Greg KH wrote:
> On Thu, Jan 07, 2021 at 02:07:08PM +0800, Xu Yilun wrote:
> > This driver supports the ethernet retimers (C827) for the Intel PAC
> > (Programmable Acceleration Card) N3000, which is a FPGA based Smart NIC.
> >
> > C827 is an Intel(R)
> +static void ar9331_get_stats64(struct dsa_switch *ds, int port,
> +struct rtnl_link_stats64 *s)
> +{
> + struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
> + struct ar9331_sw_port *p = >port[port];
> +
> + spin_lock(>stats_lock);
> +
> + /* hwmon interface needs to access 16bit registers in atomic way to
> + * guarantee coherency of the diagnostic monitoring data. If it is not
> + * possible to guarantee coherency because EEPROM is broken in such way
> + * that does not support atomic 16bit read operation
On Wed, Jan 06, 2021 at 09:09:44AM -0800, Florian Fainelli wrote:
> BCM72116 features a 28nm integrated EPHY, add an entry to match this PHY
> OUI.
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
> Hi Andrew
>
> I found here:
> https://patchwork.kernel.org/project/netdevbpf/patch/20201218105538.30563-2-rasmus.villem...@prevas.dk/
>
> Seem to be underway but stable isn't included, I think it should be.
Stable should happen, since this was posted with [net,v2,3/3]. David
or Jakub handles
On Tue, Jan 05, 2021 at 02:17:42PM +, Joakim Tjernlund wrote:
> On Thu, 2020-12-10 at 02:25 +0100, Andrew Lunn wrote:
> > On Sat, Dec 05, 2020 at 08:17:24PM +0100, Rasmus Villemoes wrote:
> > > All the buffers and registers are already set up appropriately for an
> > &
eescale/fs_enet/mii-fec.o
> ERROR: modpost: missing MODULE_LICENSE() in
> drivers/net/ethernet/freescale/fs_enet/mii-bitbang.o
>
> Add the missing MODULE_LICENSEs to fix the build. Both files include a
> copyright header indicating they are GPL v2.
>
> Signed-off-by: Michael Ellerman
Reviewed-by: Andrew Lunn
Andrew
> I added a statically-linked ethtool binary to my initramfs, and can
> confirm that retrieving the PHY statistics does not access the PHY
> registers when the device is suspended:
>
> # ethtool --phy-statistics eth0
> no stats available
> # ifconfig eth0 up
> # ethtool
On Tue, Jan 05, 2021 at 01:22:29PM +1100, Michael Ellerman wrote:
> Since commit 1d6cd3929360 ("modpost: turn missing MODULE_LICENSE()
> into error") the ppc32_allmodconfig build fails with:
>
> ERROR: modpost: missing MODULE_LICENSE() in
> drivers/net/ethernet/freescale/fs_enet/mii-fec.o
>
> The basic rules here should be, if the MDIO bus is registered, it is
> usable. There are things like PHY statistics, HWMON temperature
> sensors, etc, DSA switches, all which have a life cycle separate to
> the interface being up.
[Goes and looks at the code]
Yes, this is runtime PM which is
> Ok, so this does not have anything to do with interrupts explicitly but
> rather with the fact that any PHY access will cause a crash when the
> sh_eth device is powered down.
>
> If the device is powered-down before the actual .ndo_open() how is the
> probe actually setting up the device? Or
not be called for IPs having this
> capability
>
> This strongly implies that present of the flag was intended to skip
> the function not absence of the flag. Update the if statement to
> this effect, which repairs the existing users.
>
> Fixes: daafa1d33cc9 ("net: macb: add capa
> Fixes: 539e44d26855 ("dp83640: Include hash in timestamp/packet matching")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Andrew Lunn
Andrew
> > > + qcom,tx-driver-strength:
> > > +description: PSGMII/QSGMII TX driver strength control.
> > > +$ref: /schemas/types.yaml#/definitions/uint32
> > > +enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
> >
> > Please use the actual values here, and have the driver convert to the
>
On Sun, Jan 03, 2021 at 02:25:43AM +0100, Martin Blumenstingl wrote:
> Enable GSWIP_MII_CFG_EN also for internal PHYs to make traffic flow.
> Without this the PHY link is detected properly and ethtool statistics
> for TX are increasing but there's no RX traffic coming in.
>
> Fixes:
> > Looking at sfp_module_info(), adding a check for i2c_block_size < 2
> > when determining what length to return. ethtool should do the right
> > thing, know that the second page has not been returned to user space.
>
> But if we limit length of eeprom then userspace would not be able to
>
On Thu, Dec 31, 2020 at 01:14:10PM +0100, Pali Rohár wrote:
> On Wednesday 30 December 2020 19:09:58 Russell King - ARM Linux admin wrote:
> > On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> > > On Wednesday 30 December 2020 18:13:15 Andrew Lunn wrot
On Thu, Dec 31, 2020 at 01:14:10PM +0100, Pali Rohár wrote:
> On Wednesday 30 December 2020 19:09:58 Russell King - ARM Linux admin wrote:
> > On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> > > On Wednesday 30 December 2020 18:13:15 Andrew Lunn wrot
> Which shows why it's pointless producing an EEPROM validation tool that
> runs under Linux (as has been your suggestion). They won't use it,
> since their testing only goes as far as "does it work in our product?"
Yes, i would need SNIA to push for conformance testing, hold
plug-testing events,
> Ok!
>
> So should we completely skip hwmon_device_register_with_info() call
> if (i2c_block_size < 2) ?
Yep. That would be a nice simple test.
But does ethtool -m still export the second page? That is also
unreliable.
Andrew
On Wed, Dec 30, 2020 at 05:06:23PM +, Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 05:57:58PM +0100, Pali Rohár wrote:
> > On Wednesday 30 December 2020 16:13:10 Russell King - ARM Linux admin wrote:
> > > On Wed, Dec 30, 2020 at 04:47:54PM +0100, Pali Rohár wrote:
> > > >
On Wed, Dec 30, 2020 at 05:05:46PM +, Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 05:56:34PM +0100, Pali Rohár wrote:
> > This change is really required for those Realtek chips. I thought that
> > it is obvious that from *both* addresses 0x50 and 0x51 can be read only
> >
201 - 300 of 5545 matches
Mail list logo
