> +IEC 62439-3 (HSR/PRP)
> +-
> +
> +The Parallel Redundancy Protocol (PRP) is a network redundancy protocol which
> +works by duplicating and sequence numbering packets through two independent
> L2
> +networks (which are unaware of the PRP tail tags carried in the packets), an
> +implemented as a function of the bridge driver. MRP uses management PDUs
> +(Test, Topology, LinkDown/Up, Option) sent at a multicast destination MAC
"sent to", or "sent with"
> +address range of 01:15:4e:00:00:0x and with an EtherType of 0x88e3.
address in the range.
Andrew
On Sun, Feb 21, 2021 at 11:33:51PM +0200, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Add a short summary of the methods that a driver writer must implement
> for offloading a link aggregation group, and what is still missing.
>
> Cc: Tobias Waldekranz
> Signed-off-by: Vladimir Oltean
>
lobal
> + regions as well as per-port regions are supported. Since address tables and
> + VLAN tables are only inspectable by core iproute2 tools (ip-link, bridge)
> on
> + user ports, devlink regions can be created for dumping these tables on the
> + non-user ports too.
You might al
m in the DSA core.
Hi Vladimir
"in lack of" is a bit odd wording. Maybe "due to a lack of"
Reviewed-by: Andrew Lunn
Andrew
r model to use for
> Ethernet-connected switches (since we already have 15 tagging protocols
> supported and probably more switch families from various vendors), so
> there is nothing actionable to do.
Yes, we have already taken over the universe :-)
Reviewed-by: Andrew Lunn
Andrew
onal phases anymore in most of the switchdev
> objects/attributes, and as a result, there aren't any in the DSA driver
> API either. So remove this piece.
>
> Signed-off-by: Vladimir Oltean
Reviewed-by: Andrew Lunn
Andrew
> +It is desirable that all tagging protocols are testable with the ``dsa_loop``
> +mockup driver, which can be attached to any network interface. The goal is
> that
> +any network interface should be able of transmitting the same packet in the
should be _capable_ of ??
Reviewed-by:
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 send
eed the 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
maybe you can change the
wording?
Reviewed-by: Andrew Lunn
Andrew
> Understood. Please double check ethtool callbacks work fine. People
> often forget about those when disabling clocks in .close.
The MDIO bus can also be used at any time, not just when the interface
is open. For example the MAC could be connected to an Ethernet switch,
which is managed by the MD
> > Currently, when user space queries the link's parameters, as speed and
> > duplex, each parameter is passed from the driver to ethtool.
> >
> > Instead, get the link mode bit in use, and derive each of the parameters
> > from it in ethtool.
> > + err = dev->ethtool_ops->get_link_ksettings(d
> > +/* 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 &&
> > + priv->line_interf
Hi Ivan
> +static int sfp_module_insert(void *_priv, const struct sfp_eeprom_id *id)
> +{
> + struct phy_device *phydev = _priv;
> + struct device *dev = &phydev->mdio.dev;
> + struct mv_data *priv = phydev->priv;
> + phy_interface_t sfp_interface;
Reverse Christmas tree pleas
> 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 Thu, Feb 18, 2021 at 07:31:41PM +, Grant Grundler wrote:
> Oliver, Jakub,
> Can I post v4 and deal with the issues below?
You should probably wait for two weeks. We are far enough into the
merge window that i doubt it will get picked up. So please wait,
rebase, and then post.
> Nit: The v2
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
> From 8836f1df35a884327da37885ff3ad8bfc5eb933c Mon Sep 17 00:00:00 2001
> From: Marco Wenzel
> Date: Wed, 17 Feb 2021 13:53:31 +0100
> Subject: [PATCH] net: hsr: add support for EntryForgetTime
>
> In IEC 62439-3 EntryForgetTime is defined with a value of 400 ms. When a
> node does not send any
> I'm wondering whether we need to add __acquires() and __releases()
> annotations to some of these functions so that sparse can catch
> these cases. Thoughts?
Hi Russell
The more tools we have for catching locking problems the better.
Jakubs patchwork bot should then catch them when a patch is s
On Wed, Feb 17, 2021 at 02:48:30PM +1000, Nathan Rossi wrote:
> On Wed, 17 Feb 2021 at 13:19, Andrew Lunn wrote:
> >
> > > > The patch does make sense though, Broadcom 53125 switches have a broken
> > > > turn around and are mdio_device instances, the broken beha
On Tue, Feb 16, 2021 at 04:54:53PM -0600, Robert Hancock wrote:
> Add a flag and helper function to indicate that a PHY device is part of
> an SFP module, which is set on attach. This can be used by PHY drivers
> to handle SFP-specific quirks or behavior.
>
> Signed-off-by: Robert Hancock
> ---
>
On Wed, Feb 17, 2021 at 12:55:42AM +0100, Linus Walleij wrote:
> Support also transmitting frames using the custom "8899 A"
> 4 byte tag.
>
> Qingfang came up with the solution: we need to pad the
> ethernet frame to 60 bytes using eth_skb_pad(), then the
> switch will happily accept frames with c
> > The patch does make sense though, Broadcom 53125 switches have a broken
> > turn around and are mdio_device instances, the broken behavior may not
> > show up with all MDIO controllers used to interface though. For the
>
> Yes the reason we needed this change was to enable broken turn around,
On Mon, Feb 15, 2021 at 08:33:19PM +, Stefan Chulski wrote:
> > > > > > I discussed it with Andrew earlier last year, and his response was:
> > > > > >
> > > > > > DT configuration of pause for fixed link probably is
> > > > > > sufficient. I don't remember it ever been really discussed for
>
On Mon, Feb 15, 2021 at 07:02:18AM +, Nathan Rossi wrote:
> From: Nathan Rossi
>
> The documentation for MDIO bindings describes the "broken-turn-around",
> "reset-assert-us", and "reset-deassert-us" properties such that any MDIO
> device can define them. Other MDIO devices may require these
On Mon, Feb 15, 2021 at 04:19:19PM +, Stefan Chulski wrote:
> > > > I discussed it with Andrew earlier last year, and his response was:
> > > >
> > > > DT configuration of pause for fixed link probably is sufficient. I
> > > > don't remember it ever been really discussed for DSA. It was a
> >
> If we can't switch between 1000base-X and 2500base-X, then we should
> not be calling phylink_helper_basex_speed() - and only one of those
> two capabilities should be set in the validation callback. I thought
> there were DSA switches where we could program the CMODE to switch
> between these tw
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 s
> > 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
>
ts, typically
> there is no interrupt exposed at a PHY level. So let's rename it to
> PHY_MAC_INTERRUPT. This is in line with phy_mac_interrupt(), which is
> called from the MAC interrupt handler to handle PHY events.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Andrew Lunn
Andrew
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
> Thanks, but I'm not sure I understand the difference between "rate
> adaption" and symbol repetition. The SGMII link is always 1.25Gb,
> right? If the media side is 100Mbit it will repeat the symbol 10
> times or 100 times in case of 10Mbit. What is "rate adaption" then?
Hi Michael
Some multiG
On Fri, Feb 12, 2021 at 08:18:40PM -0600, Robert Hancock wrote:
> bcm54xx_config_init was modifying the PHY LED configuration to enable link
> and activity indications. However, some SFP modules (such as Bel-Fuse
> SFP-1GBT-06) have no LEDs but use the LED outputs to control the SFP LOS
> signal, a
On Fri, Feb 12, 2021 at 06:23:56PM -0600, Robert Hancock wrote:
> Newer versions of the Xilinx AXI Ethernet core (specifically version 7.2 or
> later) allow the core to be configured with a PHY interface mode of "Both",
Hi Robert
Is it possible to read the version of the core from a register? Is
x27;t 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 Reset
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, u3
> 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 n
> > 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;
> > > +
> > > +module_param(bm_underrun_prote
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 wi
controller in BCM4908 is always connected to the internal SF2
> switch's port and uses fixed link.
>
> Signed-off-by: Rafał Miłecki
Reviewed-by: Andrew Lunn
Andrew
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 (of_property_read_boo
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
chael Walle
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 dr
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 s
> 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
On Wed, Feb 10, 2021 at 02:39:17PM -0400, Jason Gunthorpe wrote:
> On Sun, Sep 20, 2020 at 04:53:51PM +0200, Andrew Lunn wrote:
>
> > How often are new W=1 flags added? My patch exported
> > KBUILD_CFLAGS_WARN1. How about instead we export
> > KBUILD_CFLAGS_WARN1_202009
> > > +ethernet-ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + port@0 {
> > > +reg = <0>;
> > > +label = "lan1";
> > > + };
> > > + port@1 {
> > > +reg = <1>;
> > > +label
> Thanks for the other comments. I'll sort out the issues before preparing an
> update but it will take a few weeks to re-test the driver and prepare a new
> patch.
Given the complexity of these patches, you can expect to go around the
cycle a few times. So do testing, but also assume you are goin
igned-off-by: Geert Uytterhoeven
Reviewed-by: Andrew Lunn
Andrew
> +static inline u32 enet_read(struct bcm4908_enet *enet, u16 offset)
> +{
> + return readl(enet->base + offset);
> +}
No inline functions in C files please. Let the compiler decide.
> +static int bcm4908_dma_alloc_buf_descs(struct bcm4908_enet *enet,
> +st
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
> 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
chael Walle
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
> @@ -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' p
> 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
part
> 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 PHY
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 preparation
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
reason of that weird behavior 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 se
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, t
urn 0;
> + }
> +
> + priv->cm3_base = devm_ioremap_resource(&pdev->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 delet
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 +++
> drivers
> > > +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 Base
On Thu, Feb 04, 2021 at 05:06:15PM +, Vladimir Oltean wrote:
> On Thu, Feb 04, 2021 at 06:00:26PM +0100, Andrew Lunn wrote:
> > On Thu, Feb 04, 2021 at 06:33:51PM +0200, Vladimir Oltean wrote:
> > > Since teardown is supposed to undo the effects of the setup method, it
>
On Thu, Feb 04, 2021 at 06:33:51PM +0200, Vladimir Oltean wrote:
> Since teardown is supposed to undo the effects of the setup method, it
> should be called in the error path for dsa_switch_setup, not just in
> dsa_switch_teardown.
I disagree with this. If setup failed, it should of cleaned itself
> >When the platform line card driver is on the BMC, you need a proxy in
> >between. Isn't this what IPMI and Redfish is all about? The proxy
> >driver can offer the same interface as the platform line card driver.
>
> Do you have any example of kernel driver which is doing some thing like
> that?
t options")
> Signed-off-by: Russell King
Lets see if this ends up in patchwork.
Reviewed-by: Andrew Lunn
Andrew
t options")
> Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
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 definitivel
> +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);
> + linkmode_set_bit(ETHTOOL_LINK_MODE
On Mon, Feb 01, 2021 at 09:16:41AM +0100, Jiri Pirko wrote:
> Sun, Jan 31, 2021 at 06:09:24PM CET, dsah...@gmail.com wrote:
> >On 1/30/21 7:19 AM, Jiri Pirko wrote:
> >> Fri, Jan 29, 2021 at 06:31:59PM CET, and...@lunn.ch wrote:
> Platform line card driver is aware of line card I2C topology, i
> Platform line card driver is aware of line card I2C topology, its
> responsibility is to detect line card basic hardware type, create I2C
> topology (mux), connect all the necessary I2C devices, like hotswap
> devices, voltage and power regulators devices, iio/a2d devices and line
> card EEPROMs,
> 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
> Platform line card driver is aware of line card I2C topology, its
> responsibility is to detect line card basic hardware type, create I2C
> topology (mux), connect all the necessary I2C devices, like hotswap
> devices, voltage and power regulators devices, iio/a2d devices and line
> card EEPROMs,
> + /* 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 pleas
> +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 == LAN937X_SGMII
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
> ---
> include
On Thu, Jan 28, 2021 at 09:14:34AM +0100, Jiri Pirko wrote:
> Wed, Jan 27, 2021 at 03:14:34PM CET, and...@lunn.ch wrote:
> >> >There are Linux standard APIs for controlling the power to devices,
> >> >the regulator API. So i assume mlxreg-pm will make use of that. There
> >> >are also standard APIs
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 no
301 - 400 of 7453 matches
Mail list logo
