On Tue, Mar 30, 2021 at 03:54:06PM +0200, Oleksij Rempel wrote:
> PHY loopback is needed for the ethernet controller self test support.
> This PHY was tested with the FEC sefltest.
>
> Signed-off-by: Oleksij Rempel
> ---
> drivers/net/phy/at803x.c | 25 +
> 1 file
On Tue, Mar 30, 2021 at 03:54:05PM +0200, Oleksij Rempel wrote:
> PHY loopback is needed for the ethernet controller self test support.
> This PHY was tested with the FEC sefltest.
>
> Signed-off-by: Oleksij Rempel
Apart from the typo
Reviewed-by: Andrew Lunn
Andrew
On Tue, Mar 30, 2021 at 11:00:52AM -0300, Fabio Estevam wrote:
> Hi Oleksij,
>
> On Tue, Mar 9, 2021 at 8:26 AM Oleksij Rempel wrote:
> >
> > changes v2:
> > - rebase against latest kernel
> > - fix networking on RIoTBoard
> >
> > This patch series tries to remove most of the imx6 and imx7 board
> > > +static int sparx5_sd25g28_apply_params(struct sparx5_serdes_macro *macro,
> > > +struct sparx5_sd25g28_params *params)
> > > {
> > > - struct sparx5_serdes_regval item[] = {
> >
> > Could you just add const here, and then it is no longer on the
On Mon, Mar 29, 2021 at 10:14:38AM +0200, Steen Hegelund wrote:
> Use direct register operations instead of a table of register
> information to lower the stack usage.
>
> Signed-off-by: Steen Hegelund
> Reported-by: kernel test robot
> ---
> drivers/phy/microchip/sparx5_serdes.c | 1869
> The usecase is simple, unlike DSA tag, this 4byte FDSA tag doesn't
> have a ethertype,
> so HW cannot recognize this header. If such packers arise, then HW parsing
> will
> fail and RSS will not work.
>
> Hypothetically if we introduce some communication between MAC driver
> and DSA driver,
>
> What I have works. Your consumers get quirk handling, mine don't need it.
> No compromise.
Hi Don
All this discussion is now a mute point. GregKH has spoken.
But i'm sure there are some on the side lines, eating popcorn, maybe
learning from the discussion.
Would you think it is O.K. to add
Tx clocks.
>
> Tested on Ubiquiti ER-X running the GMAC0 and MT7530 in TRGMII mode.
>
> Signed-off-by: Ilya Lipnitskiy
Thanks for moving the comment.
Reviewed-by: Andrew Lunn
Andrew
> The only thing wrong I can see is that it doesn't use the kernel network
> stack. Here's where "you keep missing the point". The kernel network stack
> is not being used in these systems. Implementing EEPROM access through
> ethtool is of course possible, but it is a lot of work with no
On Fri, Mar 26, 2021 at 01:16:14PM -0700, Don Bollinger wrote:
> > > In my community, the SFP/QSFP/CMIS devices (32 to 128 of them per
> > > switch) often cost more than the switch itself. Consumers (both
> > > vendors and
> > > customers) extensively test these devices to ensure correct and
> >
> In my community, the SFP/QSFP/CMIS devices (32 to 128 of them per switch)
> often cost more than the switch itself. Consumers (both vendors and
> customers) extensively test these devices to ensure correct and reliable
> operation. Then they buy them literally by the millions. Quirks lead to
On Thu, Mar 25, 2021 at 06:32:12PM +0530, Sunil Kovvuri wrote:
> On Thu, Mar 25, 2021 at 6:20 PM Andrew Lunn wrote:
> >
> > > > So you completely skipped how this works with mv88e6xxx or
> > > > prestera. If you need this private flag for some out of mainlin
> > So you completely skipped how this works with mv88e6xxx or
> > prestera. If you need this private flag for some out of mainline
> > Marvell SDK, it is very unlikely to be accepted.
> >
> > Andrew
>
> What we are trying to do here has no dependency on DSA drivers and
> neither impacts
On Wed, Mar 24, 2021 at 12:46:41AM +0800, Wong Vee Khee wrote:
> Add support for PHY loopback for Marvell 88x2110 and Marvell 88x3310.
>
> This allow user to perform PHY loopback test using ethtool selftest.
>
> Signed-off-by: Wong Vee Khee
Reviewed-by: Andrew Lunn
Andrew
ee Khee
Reviewed-by: Andrew Lunn
Andrew
On Tue, Mar 23, 2021 at 08:00:06PM -0500, prane...@ti.com wrote:
> From: Praneeth Bajjuri
>
> Current logic is performing hard reset and causing the programmed
> registers to be wiped out.
>
> as per datasheet: https://www.ti.com/lit/ds/symlink/dp83867cr.pdf
> 8.6.26 Control Register (CTRL)
>
> > Our experience is that a number of SFPs are broken, they don't follow the
> > standard. Some you cannot perform more than 16 bytes reads without them
> > locking up. Others will perform a 16 byte read, but only give you one
> useful
> > byte of data. So you have to read enough of the EEPROM a
On Tue, Mar 23, 2021 at 06:13:28PM +, Hariprasad Kelam wrote:
>
> Hi Andrew ,
>
> Please see inline,
No need to say that. That is the correct way to right emails.
> > Hi Hariprasad
> >
> > Private flags sound very wrong here. I would expect to see some integration
> > between the
> +static void owl_emac_set_multicast(struct net_device *netdev, int count)
> +{
> + struct owl_emac_priv *priv = netdev_priv(netdev);
> + struct netdev_hw_addr *ha;
> + int index = 0;
> +
> + if (count <= 0) {
> + priv->mcaddr_list.count = 0;
> + return;
>
> The solution is to create a user space tool inside the
> drivers/net/ipa directory that will link with the kernel
> source files and will perform all the basic one-time checks
> I want to make.
Hi Alex
Have you found any other driver doing this? Where do they keep there
code?
Could this be a
On Mon, Mar 22, 2021 at 03:59:43PM +, Stefan Chulski wrote:
>
> > > 2. CM3 code has very small footprint requirement, we cannot
> > > implement the complete Serdes and PHY infrastructure that kernel
> > > provides as part of CM3 application. Therefore I would like to
> > > continue relying
On Mon, Mar 22, 2021 at 01:41:58PM +0100, Linus Walleij wrote:
> On Wed, Mar 10, 2021 at 9:38 PM Asmaa Mnebhi wrote:
>
> > > That's fine, the hardware description model (I guess in your case
> > > ACPI) should take care of that.
> > >
> > We cannot really pass it through the ACPI table because
ic for other OSs/firmware that use
> Linux device tree sources as a reference. Resolve the problem
> with backward compatibility by restoring a previous compatible
> string as secondary one.
>
> Signed-off-by: Marcin Wojtas
Reviewed-by: Andrew Lunn
Andrew
On Sun, Mar 21, 2021 at 05:39:52PM +0530, Hariprasad Kelam wrote:
> From: Felix Manlunas
>
> For PHYs that support changing modulation type (NRZ or PAM4), enable these
> commands:
>
> ethtool --set-priv-flags ethX pam4 on
> ethtool --set-priv-flags ethX pam4 off# means NRZ
On Sun, Mar 21, 2021 at 05:39:50PM +0530, Hariprasad Kelam wrote:
> This series of patches add support for parsing switch headers and
> configuration support for phy modulation type(NRZ or PAM4).
>
> PHYs that support changing modulation type ,user can configure it
> through private flags pam4.
>
On Fri, Mar 19, 2021 at 04:18:32PM -0500, Alex Elder wrote:
> On 3/19/21 1:32 PM, Andrew Lunn wrote:
> > > @@ -212,7 +213,7 @@ static inline u32 ipa_reg_bcr_val(enum ipa_version
> > > version)
> > >
> @@ -212,7 +213,7 @@ static inline u32 ipa_reg_bcr_val(enum ipa_version
> version)
> BCR_HOLB_DROP_L2_IRQ_FMASK |
> BCR_DUAL_TX_FMASK;
>
> - /* assert(version != IPA_VERSION_4_5); */
> + ipa_assert(NULL, version != IPA_VERSION_4_5);
Hi Alex
> It will be much better for everyone if you don't obfuscate existing
> kernel primitives and don't hide constant vs. dynamic expressions.
>
> So any random kernel developer will be able to change the code without
> investing too much time to understand this custom logic.
>
> And constant
> We cannot really pass it through the ACPI table because the ACPI
> table is common to all BlueField-2 boards. And each board may have
> a different GPIO pin associated with a particular function. This is
> why we use ACPI properties instead of GpioInt(). So that the
> bootloader can change the
> 2. CM3 code has very small footprint requirement, we cannot
> implement the complete Serdes and PHY infrastructure that kernel
> provides as part of CM3 application. Therefore I would like to
> continue relying on kernel configuration for that.
How can that work? How does Linux know when CM3
On Thu, Mar 18, 2021 at 01:38:50PM +0100, Bjarni Jonasson wrote:
> -static int vsc8584_config_init(struct phy_device *phydev)
> +static int vsc8584_config_host_serdes(struct phy_device *phydev)
> {
> - struct vsc8531_private *vsc8531 = phydev->priv;
> - int ret, i;
> + int ret;
>
ototype for mac(). Prototype
> was for of_get_mac_address() instead
>
> Cc: Andrew Lunn
> Cc: Heiner Kallweit
> Cc: Russell King
> Cc: Rob Herring
> Cc: Frank Rowand
> Cc: net...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Lee Jones
Thank
> I have offered, in every response, to collaborate with the simple
> integration to use optoe as the default upstream driver to access the module
> EEPROMs. optoe would be superior to the existing default routines in sfp.c
Actually, i'm not sure they would be. Since the KAPI issues are pretty
> BCM6368 (and newer) SoCs have an integrated ethernet switch controller with
> dedicated internal phys, but it also supports connecting to external phys not
> integrated in the internal switch.
> Ports 0-3 are internal, ports 4-7 are external and can be connected to
> external switches or phys
> > > + if (phy->interface != PHY_INTERFACE_MODE_RMII) {
> > > + netdev_err(netdev, "unsupported phy mode: %s\n",
> > > +phy_modes(phy->interface));
> > > + phy_disconnect(phy);
> > > + netdev->phydev = NULL;
> > > + return -EINVAL;
> > > + }
> >
On Thu, Mar 11, 2021 at 03:20:13AM +0200, Cristian Ciocaltea wrote:
> +static inline void owl_emac_reg_set(struct owl_emac_priv *priv,
> + u32 reg, u32 bits)
> +{
> + owl_emac_reg_update(priv, reg, bits, bits);
> +}
Hi Cristian
No inline functions in C files
> This interface is implemented in python scripts provided by the switch
> platform
> vendor. Those scripts encode the mapping of CPLD i2c muxes to i2c buses to
> port numbers, specific to each switch.
>
> At the bottom of that python stack, all EEPROM access goes through
> open/seek/read/close
ototype for mac(). Prototype
> was for of_get_mac_address() instead
>
> Cc: Andrew Lunn
> Cc: Heiner Kallweit
> Cc: Russell King
> Cc: Rob Herring
> Cc: Frank Rowand
> Cc: net...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
&g
On Wed, Mar 10, 2021 at 06:09:52PM -0800, Ilya Lipnitskiy wrote:
> A recent change to MIPS ralink reset logic made it so mt7530 actually
> resets the switch on platforms such as mt7621 (where bit 2 is the reset
> line for the switch). That exposed an issue where the switch would not
> function
On Wed, Mar 10, 2021 at 06:09:52PM -0800, Ilya Lipnitskiy wrote:
> A recent change to MIPS ralink reset logic made it so mt7530 actually
> resets the switch on platforms such as mt7621 (where bit 2 is the reset
> line for the switch). That exposed an issue where the switch would not
> function
On Wed, Mar 10, 2021 at 01:14:19PM -0800, Ilya Lipnitskiy wrote:
> When disabling PLL, there is no need to call core_write_mmd_indirect
> directly, use the core_write wrapper instead like the rest of the code
> in the function does. This change helps with consistency and
> readability.
>
>
On Thu, Mar 11, 2021 at 06:22:34PM +0100, Jonathan Neuschäfer wrote:
> "either" is outside the parentheses, so the matching "or" should be too.
>
> Signed-off-by: Jonathan Neuschäfer
Reviewed-by: Andrew Lunn
Andrew
On Thu, Mar 11, 2021 at 06:43:27PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
Hi Stefan
Thanks for the strings change. Looks a lot better.
Now i took a look at the bigger picture.
> According to Armada SoC architecture and design, all the PPv2 ports
> which are populated on the
gt; and VLAN filtering enable status.
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
On Wed, Mar 10, 2021 at 09:31:07PM +0100, Markus Elfring wrote:
> Hello,
>
> I would like to build the Linux version “5.11.5” for my needs.
> But I stumbled on the following information.
>
> …
> AR drivers/built-in.a
> LD [M] drivers/visorbus/visorbus.o
> GEN .version
> CHK
> Make it patch series? I can split it to 2/3 patches.
I don't think that will be needed. The helpers should be pretty
obvious.
Andrew
> static void mvpp2_ethtool_get_strings(struct net_device *netdev, u32 sset,
> u8 *data)
> {
> struct mvpp2_port *port = netdev_priv(netdev);
> int i, q;
>
> - if (sset != ETH_SS_STATS)
> - return;
> + switch (sset) {
> +
> +static int bcm6368_mdiomux_probe(struct platform_device *pdev)
> +{
> + struct bcm6368_mdiomux_desc *md;
> + struct mii_bus *bus;
> + struct resource *res;
> + int rc;
> +
> + md = devm_kzalloc(>dev, sizeof(*md), GFP_KERNEL);
> + if (!md)
> + return -ENOMEM;
On Mon, Mar 08, 2021 at 07:41:01PM +0100, Álvaro Fernández Rojas wrote:
> + clocks:
> +maxItems: 1
Hi Álvaro
The driver does not make use of this clocks property. Is it really
needed?
Andrew
> I am proposing acceptance of a commonly used implementation for accessing
> SFPs because the one used by the netdev/netlink community does not fit the
> architecture of the white box NOS/switch community.
Please could you expand on this. I've given suggests as to how the new
netlink KAPI could
> To be more specific, optoe is only replacing the functionality of
> drivers/net/phy/sfp.c, the functions of sfp_i2c_read() and sfp_i2c_write().
> These are the routines at the very bottom of the ethtool stack that actually
> execute the i2c calls to get the data. The existing routines are very
> > I assume you have seen the work NVIDIA submitted last week? This idea of
> > linear pages is really restrictive and we are moving away from it.
>
> No, I haven't seen it. I can't seem to locate anything in the past month on
> LMKL from NVIDIA. Please point me to it.
[RFC PATCH net-next
On Fri, Feb 26, 2021 at 03:44:42PM +0800, Huazhong Tan wrote:
> From: Guangbin Huang
>
> If phy uses generic driver and autoneg is on, enter command
> "ethtool -s eth0 speed 50" will not change phy speed actually, but
> command "ethtool eth0" shows speed is 50Mb/s because phydev->speed
> has
On Mon, Feb 15, 2021 at 11:38:21AM -0800, Don Bollinger wrote:
> optoe is an i2c based driver that supports read/write access to all
> the pages (tables) of MSA standard SFP and similar devices (conforming
> to the SFF-8472 spec), MSA standard QSFP and similar devices (conforming
> to the SFF-8636
hese two as __maybe_unused
> and remove the incorrect #ifdef.
>
> Fixes: 4c0d2e96ba05 ("net: phy: consider that suspend2ram may cut off PHY
> power")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Andrew Lunn
Andrew
t; in Redbox mode.
>
> Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamless
> Redundancy protocol (HSRv0)")
> Signed-off-by: Marco Wenzel
> Reviewed-by: George McCollister
> Tested-by: George McCollister
Reviewed-by: Andrew Lunn
Andrew
> > You must decide if you want to send it for net or net-next. If you want to
> > send it for net-next you must wait Linus has closed the merge window and
> > this shows open:
> > http://vger.kernel.org/~davem/net-next.html
> >
> > To send for net use the subject prefix "[PATCH net]".
> > To
he if (). The clk API is happy with a NULL pointer and
will do the right thing. Otherwise:
Reviewed-by: Andrew Lunn
Andrew
Geert Uytterhoeven
Reviewed-by: Andrew Lunn
Andrew
an change the
wording?
Reviewed-by: Andrew Lunn
Andrew
On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote:
> Hi Andrew,
>
> I ran rngtest and this is what I got:
> root@OpenWrt:/# cat /dev/hwrng | rngtest -c 1000
> rngtest 6.10
> Copyright (c) 2004 by Henrique de Moraes Holschuh
> This is free software; see the source for copying
On Sat, Feb 20, 2021 at 06:47:40PM +0100, Álvaro Fernández Rojas wrote:
> This allows devices without a high precission timer to reduce boot from >100s
> to <30s.
> diff --git a/drivers/char/hw_random/bcm2835-rng.c
> b/drivers/char/hw_random/bcm2835-rng.c
> index 1a7c43b43c6b..4b48cb7176b0 100644
> > +/* switch line-side interface between 10GBase-R and 1GBase-X
> > + * according to speed */
> > +static void mv_update_interface(struct phy_device *phydev)
> > +{
> > + struct mv_data *priv = phydev->priv;
> > +
> > + if (phydev->speed == SPEED_1 &&
> > +
Hi Ivan
> +static int sfp_module_insert(void *_priv, const struct sfp_eeprom_id *id)
> +{
> + struct phy_device *phydev = _priv;
> + struct device *dev = >mdio.dev;
> + struct mv_data *priv = phydev->priv;
> + phy_interface_t sfp_interface;
Reverse Christmas tree please.
> If in doubt, leaving the patch as is would be fine with me.
The patch is O.K. as is, no need to export something so simple for a
single users. When the next user come along, we can reconsider.
Andrew
On Wed, Feb 17, 2021 at 12:25:57PM -0800, Florian Fainelli wrote:
> We have no in-tree users, also update the sfp-phylink.rst documentation
> to indicate that phy_attach_direct() is used instead of of_phy_attach().
>
> Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Andrew
On Wed, Feb 17, 2021 at 03:30:38PM +, Rui Salvaterra wrote:
> Hardware buffer management has never worked on the Turris Omnia, as the
> required MBus window hadn't been reserved. Fix thusly.
Hi Rui
I don't know all the details for the MBus Windows...
Can this be set once in armada-385.dtsi
On Mon, Feb 15, 2021 at 05:25:10PM +0530, Kishon Vijay Abraham I wrote:
> Okay. Is it going to be some sort of manual negotiation where the
> Ethernet controller invokes set_speed with different speeds? Or the
> Ethernet controller will get the speed using some out of band mechanism
> and invokes
> > Does this even need to be configurable? What is the cost of turning it on?
> > How does having less pools affect the system? Does average latency go up?
> > When would i consider an underrun actually a good thing?
> >
> > Maybe it should just be hard coded on? Or we should try to detect when
On Sun, Feb 14, 2021 at 01:00:42PM -0800, Stephen Boyd wrote:
> Quoting Andrew Lunn (2021-02-13 08:04:34)
> > > I'm trying to see if we can make lives better for everyone by exposing
> > > the warnings by default in the drivers/clk/ directory now that there are
>
On Fri, Feb 12, 2021 at 04:12:20PM +0100, Maxime Chevallier wrote:
> +static void mvneta_setup_rx_prio_map(struct mvneta_port *pp)
> +{
> + int i;
> + u32 val = 0;
Hi Maxime
Reverse Chrismtass tree please.
Andrew
> I'm trying to see if we can make lives better for everyone by exposing
> the warnings by default in the drivers/clk/ directory now that there are
> supposedly none left. Shouldn't we tighten the screws now that we've
> cleaned them?
Do you use patchwork? netdev has a bot attached which applies
On Thu, Feb 11, 2021 at 07:07:30PM -0800, Stephen Boyd wrote:
> Quoting Lee Jones (2021-02-11 13:10:54)
> > On Thu, 11 Feb 2021, Stephen Boyd wrote:
> >
> > > Quoting Lee Jones (2021-01-26 04:45:19)
> > > > This set is part of a larger effort attempting to clean-up W=1
> > > > kernel builds,
know the hardware, but the descriptions seem to fit the code,
and i did not spot anything odd.
Reviewed-by: Andrew Lunn
Andrew
On Fri, Feb 12, 2021 at 03:06:41PM +0100, Bjarni Jonasson wrote:
> At Power-On Reset, transients may cause the LCPLL to lock onto a
> clock that is momentarily unstable. This is normally seen in QSGMII
> setups where the higher speed 6G SerDes is being used.
> This patch adds an initial LCPLL
On Fri, Feb 12, 2021 at 03:06:41PM +0100, Bjarni Jonasson wrote:
> +static u32 vsc85xx_csr_read(struct phy_device *phydev,
> + enum csr_target target, u32 reg);
> +static int vsc85xx_csr_write(struct phy_device *phydev,
> + enum csr_target target,
> So the plan to fix this warning is, when device_bind_driver() is called:
> 1. Delete all device links from the device (in this case, the PHY) to
> suppliers that haven't probed yet because there's no probe function
> that can defer at this point.
Just because it currently does not happen, does
> > Or we have also found out, that pushing back on parameters like this,
> > the developers goes back and looks at the code, and sometimes figures
> > out a way to automatically do the right thing, removing the
> > configuration knob, and just making it all simpler for the user to
> > use.
>
> I
On Thu, Feb 11, 2021 at 08:22:19AM +, Stefan Chulski wrote:
>
> >
> > --
> > From:
> > Date: Wed, 10 Feb 2021 11:48:17 +0200
> >
> > >
> > > +static int bm_underrun_protect = 1;
> > > +
> > >
On Thu, Feb 11, 2021 at 10:21:03AM +, Jon Hunter wrote:
>
> On 10/02/2021 22:56, Andrew Lunn wrote:
> > On Wed, Feb 10, 2021 at 02:13:48PM -0800, Saravana Kannan wrote:
> >> Hi,
> >>
> >> This email was triggered by this other email[1].
> >
>
> Yeah, I plan to fix this. So I have a few more questions. In the
> example I gave, what should happen if the gpios listed in the phy's DT
> node aren't ready yet?
There are four different use cases for GPIO.
1) The GPIO is used to reset all devices on the MDIO bus. When the bus
is registered
On Wed, Feb 10, 2021 at 01:55:20PM +0100, Robert Marko wrote:
> Add DT bindings for Qualcomm QCA807x PHY series.
>
> Signed-off-by: Robert Marko
> Cc: Luka Perkov
> ---
> Changes in v2:
> * Drop PSGMII/QSGMII TX driver defines
>
> include/dt-bindings/net/qcom-qca807x.h | 30
> +static int qca807x_psgmii_config(struct phy_device *phydev)
> +{
> + struct device_node *node = phydev->mdio.dev.of_node;
> + int psgmii_az, tx_amp, ret = 0;
> + u32 tx_driver_strength_dt;
> +
> + /* Workaround to enable AZ transmitting ability */
> + if
On Wed, Feb 10, 2021 at 01:55:22PM +0100, Robert Marko wrote:
Hi Robert
Could you move the GPIO driver into a patch of its own, and Cc: the
GPIO maintainer and list for that patch please.
Andrew
alle
Reviewed-by: Andrew Lunn
Andrew
On Wed, Feb 10, 2021 at 02:13:48PM -0800, Saravana Kannan wrote:
> Hi,
>
> This email was triggered by this other email[1].
And it appears the Tegra194 Jetson Xavier uses the Marvell 88E1512
PHY. So ensure the Marvell driver is available, and it should get
probed in the usual way, the fallback
On Wed, Feb 10, 2021 at 02:13:48PM -0800, Saravana Kannan wrote:
> Hi,
>
> This email was triggered by this other email[1].
>
> Why is phy_attach_direct() directly calling device_bind_driver()
> instead of using bus_probe_device()?
Hi Saravana
So this is to do with the generic PHY, which is a
> I guess it boils down to: how hard should we try to get the driver
> behave correctly if the user is changing registers.
All bets are off if root starts messing with the PHY state from
userspace. Its a foot gun, don't be surprised with what happens when
you use it.
Andrew
> > > +ethernet-ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + port@0 {
> > > +reg = <0>;
> > > +label = "lan1";
> > > + };
> > > + port@1 {
> > > +reg = <1>;
> > > +label
igned-off-by: Geert Uytterhoeven
Reviewed-by: Andrew Lunn
Andrew
On Tue, Feb 09, 2021 at 10:53:20AM +0100, Michal Simek wrote:
> +static int usb5744_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = >dev;
> + int ret;
> +
> + /* Trigger gpio reset to the hub. */
> +
On Tue, Feb 09, 2021 at 05:40:51PM +0100, Michael Walle wrote:
> Implement the operations to set desired mode and retrieve the current
> mode.
>
> This feature was tested with an IP101G.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
. Because
> of this and because the RX packet counter is more likely to overflow,
> than the error counters implement only support for the error counters.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
change the page select register before linux is started. The page select
> register is _not_ reset with a soft reset of the PHY.
>
> Add read_page()/write_page() support for the IP101G and use it
> accordingly.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
alle
Reviewed-by: Andrew Lunn
Andrew
On Tue, Feb 09, 2021 at 05:40:46PM +0100, Michael Walle wrote:
> The PHY core already resets the PHY before .config_init() if a
> .soft_reset() op is registered. Drop the open-coded ip1xx_reset().
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
On Tue, Feb 09, 2021 at 05:40:45PM +0100, Michael Walle wrote:
> Don't sometimes use the address operator and sometimes not. Drop it and
> make the code look uniform.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
d up to date, because this could
cause a regression if wrong.
Reviewed-by: Andrew Lunn
Andrew
On Tue, Feb 09, 2021 at 05:40:43PM +0100, Michael Walle wrote:
> Simpify the initializations of the structures. There is no functional
> change.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
> This will change reporting PORT_MII to either PORT_TP or PORT_FIBRE;
> except for the genphy fallback driver.
>
> Suggested-by: Andrew Lunn
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
101 - 200 of 5545 matches
Mail list logo
