> > >Hi Stefano,
> > >
> > >>
> > >> I was looking at other commits to see how versioning is handled in order
> > >> to make sense (e.g. using the same version of the kernel), and I saw
> > >> many commits that are removing MODULE_VERSION because they say it
> > >> doesn't make sense in in-tree mod
On Thu, Sep 19, 2024 at 10:44:11AM +, mohan.pra...@microchip.com wrote:
> Hello Andrew,
>
> Thank you for the suggestion.
>
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > > > Since you have batteries included python:
> > > >
> > > >
> > So i don't think this is a valid test. To really test autoneg off, you need
> > to
> > configure both ends of the link.
>
> I will change the implementation to configure both the ends of the link
> appropriately in the next version.
That would be good, but it does make the test and the test
> > Since you have batteries included python:
> >
> > ethtool --json enp2s0
> > [sudo] password for andrew:
> > [ {
> > "ifname": "enp2s0",
> > "supported-ports": [ "TP","MII" ],
> > "supported-link-modes": [
> > "10baseT/Half","10baseT/Full","100baseT/Half","100baseT/Full"
On Tue, Sep 17, 2024 at 08:04:07AM +0530, Mohan Prasad J wrote:
> Add selftest file to test basic features of a NIC driver.
> Tests for link modes, auto-negotiation are placed.
> Selftest makes use of ksft modules and ethtool.
> Add selftest file in the Makefile.
>
> Signed-off-by: Mohan Prasad J
> +def verify_link_up(ifname: str) -> None:
> +"""Verify whether the link is up"""
> +with open(f"/sys/class/net/{ifname}/operstate", "r") as fp:
> +link_state = fp.read().strip()
> +
> +if link_state == "down":
> +raise KsftSkipEx(f"Link state of interface {ifname} is D
On Tue, Sep 17, 2024 at 08:04:07AM +0530, Mohan Prasad J wrote:
> Add selftest file to test basic features of a NIC driver.
> Tests for link modes, auto-negotiation are placed.
> Selftest makes use of ksft modules and ethtool.
> Add selftest file in the Makefile.
Thanks for reworking this.
> +++
> I am currently working on this and would rework as soon as possible.
> The feedback that you provided is highly helpful and I will remodel the
> implementation with these points in mind.
> Hopefully you can see that in the next version.
Great.
Don't worry too much about link speeds you cannot
On Fri, Sep 06, 2024 at 06:45:53AM +, mohan.pra...@microchip.com wrote:
> Hello Andrew,
>
> Thank you for your review comments.
>
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Wed, Sep 04, 2024 at 03:45:46AM +0530, Mohan Prasad
On Wed, Sep 04, 2024 at 03:45:46AM +0530, Mohan Prasad J wrote:
> This series of patches are for testing the lan743x network driver.
> Testing comprises autonegotiation, speed, duplex and throughput checks.
> Tools such as ethtool, iperf3 are used in the testing process.
> Performance test is done
On Mon, Aug 26, 2024 at 11:06:09AM +0200, Dragos Tatulea wrote:
>
>
> On 23.08.24 18:54, Carlos Bilbao wrote:
> > Hello,
> >
> > I'm debugging my vDPA setup, and when using ioctl to retrieve the
> > configuration, I noticed that it's running in half duplex mode:
> >
> > Configuration data (24 b
On Fri, Aug 23, 2024 at 11:54:13AM -0500, Carlos Bilbao wrote:
> Hello,
>
> I'm debugging my vDPA setup, and when using ioctl to retrieve the
> configuration, I noticed that it's running in half duplex mode:
>
> Configuration data (24 bytes):
> MAC address: (Mac address)
> Status: 0x0001
>
> +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev, struct
> vdpa_device *dev,
> + const struct vdpa_dev_set_config *add_config)
> +{
> + struct virtio_net_config *config;
> + struct mlx5_core_dev *pfmdev;
> + struct mlx5_vdpa_dev *mvdev;
> + st
> +static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev, struct
> vdpa_device *dev,
> + const struct vdpa_dev_set_config *config)
> +{
> + struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
> + struct virtio_net_config *vio_config = vdpasim
> +static int vdpa_dev_net_device_attr_set(struct vdpa_device *vdev,
> + struct genl_info *info)
> +{
> + struct vdpa_dev_set_config set_config = {};
> + struct vdpa_mgmt_dev *mdev = vdev->mdev;
> + struct nlattr **nl_attrs = info->attrs;
> + cons
> +static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev,
> + struct vdpa_device *dev,
> + const struct vdpa_dev_set_config *config)
> +{
> + struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
> + struct virtio_net
On Tue, Jul 23, 2024 at 01:39:20PM +0800, Cindy Lu wrote:
> Add new UAPI to support the mac address from vdpa tool
> Function vdpa_nl_cmd_dev_attr_set_doit() will get the
> new MAC address from the vdpa tool and then set it to the device.
>
> The usage is: vdpa dev set name vdpa_name mac **:**:**:
On Tue, Jul 23, 2024 at 01:39:19PM +0800, Cindy Lu wrote:
> Add support for setting the MAC address using the VDPA tool.
> This feature will allow setting the MAC address using the VDPA tool.
> For example, in vdpa_sim_net, the implementation sets the MAC address
> to the config space. However, for
On Mon, Jul 08, 2024 at 02:55:49PM +0800, Cindy Lu wrote:
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/mlx5/net/mlx5_vn
> As long as it doesn't behave differently from the other RTC, I'm fine
> with this. This is important because I don't want to carry any special
> infrastructure for this driver or to have to special case this driver
> later on because it is incompatible with some evolution of the
> subsystem.
May
> Having worked with closed-source systems, especially VxWorks, for many
> years (where the header files contain all the documentation), it just
> seems strange to embed the documentation in the .c files.
The key words here might be closed-source. With such black boxes, you
don't have access the s
le, some devices, such as the Ubiquiti EdgeRouter X, may have
> ports labeled ethX. Labeling the master GMAC with a different prefix
> than DSA ports helps with clarity.
>
> Suggested-by: René van Dorst
> Signed-off-by: Ilya Lipnitskiy
Reviewed-by: Andrew Lunn
Andrew
On Sun, Apr 18, 2021 at 09:03:52PM -0700, Ilya Lipnitskiy wrote:
> The MAC device name can now be set within DTS file instead of always
> being "ethX". This is helpful for DSA to clearly label the DSA master
> device and distinguish it from DSA slave ports.
>
> For example, some devices, such as t
> Currently this code is implemented in pci_bus_find_domain_nr() function.
> IIRC domain number is 16bit integer, so plain bitmap would consume 8 kB
> of memory. I'm not sure if it is fine or some other tree-based structure
> for allocated domain numbers is needed.
Hi Pali
Have a look at lib/idr.
t; Fix by using readl_poll_timeout as a more standard and less error-prone
> solution.
>
> Fixes: ba37b7caf1ed ("net: ethernet: mtk_eth_soc: add support for
> initializing the PPE")
> Signed-off-by: Ilya Lipnitskiy
> Cc: Felix Fietkau
Reviewed-by: Andrew Lunn
Andrew
> @@ -1079,6 +1078,14 @@ static int korina_probe(struct platform_device *pdev)
> eth_hw_addr_random(dev);
> }
>
> + clk = devm_clk_get(&pdev->dev, NULL);
You should use a name here. It makes future expansion of the binding
easier. devm_clk_get_optional() is probab
> - memcpy(dev->dev_addr, mac_addr, ETH_ALEN);
> + if (mac_addr) {
> + ether_addr_copy(dev->dev_addr, mac_addr);
> + } else {
> + u8 ofmac[ETH_ALEN];
> +
> + if (of_get_mac_address(pdev->dev.of_node, ofmac) == 0)
> + ether_addr_cop
On Thu, Apr 15, 2021 at 01:06:43AM +0200, Thomas Bogendoerfer wrote:
> Get rid of access to struct korina_device by just passing the mac
> address via platform data and use drvdata for passing netdev to remove
> function.
>
> Signed-off-by: Thomas Bogendoerfer
> ---
> arch/mips/rb532/devices.c
On Thu, Apr 15, 2021 at 01:06:42AM +0200, Thomas Bogendoerfer wrote:
> Instead of messing with MIPS specific macros use DMA API for mapping
> descriptors and skbs.
>
> Signed-off-by: Thomas Bogendoerfer
Reviewed-by: Andrew Lunn
Andrew
On Thu, Apr 15, 2021 at 01:06:41AM +0200, Thomas Bogendoerfer wrote:
> Remove helpers, which are only used in one call site.
>
> Signed-off-by: Thomas Bogendoerfer
Reviewed-by: Andrew Lunn
Andrew
On Thu, Apr 15, 2021 at 01:06:40AM +0200, Thomas Bogendoerfer wrote:
> Descriptors are mapped uncached so there is no need to do any cache
> handling for them.
>
> Signed-off-by: Thomas Bogendoerfer
Reviewed-by: Andrew Lunn
Andrew
On Thu, Apr 15, 2021 at 01:06:39AM +0200, Thomas Bogendoerfer wrote:
> Simplify probe/remove code by using devm_ functions.
>
> Signed-off-by: Thomas Bogendoerfer
Reviewed-by: Andrew Lunn
Andrew
> +static int korina_mdio_wait(struct korina_private *lp)
> +{
> + u32 value;
> +
> + return readl_poll_timeout_atomic(&lp->eth_regs->miimind,
> + value, value & ETH_MII_IND_BSY,
> + 1, 1000);
> +}
> +
> +static int k
On Thu, Apr 15, 2021 at 04:02:34PM -0700, Ilya Lipnitskiy wrote:
> The intention is for the loop to timeout if the body does not succeed.
> The current logic calls time_is_before_jiffies(timeout) which is false
> until after the timeout, so the loop body never executes.
>
> time_is_after_jiffies(t
On Thu, Apr 15, 2021 at 12:25:37PM +0300, Radu Pirea (NXP OSS) wrote:
> Add generic PMA suspend and resume callback functions for C45 PHYs.
>
> Signed-off-by: Radu Pirea (NXP OSS)
Reviewed-by: Andrew Lunn
Andrew
> +config NXP_C45_TJA11XX_PHY
> + tristate "NXP C45 TJA11XX PHYs"
> + help
> + Enable support for NXP C45 TJA11XX PHYs.
> + Currently supports only the TJA1103 PHY.
> +#define PHY_ID_BASE_T1 0x001BB010
It would be better to use PHY_ID_TJA_1103 here.
> +
> + if (!p) {
> printk(KERN_ERR DRV_NAME ": cannot remap registers\n");
> - rc = -ENXIO;
> - goto probe_err_out;
> + return -ENOMEM;
> }
Hi Thomas
Another possible cleanup would be replacing printk(KERN_ERR with
dev_err(), or netdev_err(
> +static int korina_mdio_wait(struct korina_private *lp)
> +{
> + int timeout = 1000;
> +
> + while ((readl(&lp->eth_regs->miimind) & 1) && timeout-- > 0)
> + udelay(1);
> +
> + if (timeout <= 0)
> + return -1;
> +
> + return 0;
Using readl_poll_timeout_ato
On Wed, Apr 14, 2021 at 05:26:55PM +0200, Michael Walle wrote:
> It is already possible to read the MAC address via a NVMEM provider. But
> there are boards, esp. with many ports, which only have a base MAC
> address stored. Thus we need to have a way to provide an offset per
> network device.
We
sta...@vger.kernel.org
> Signed-off-by: Michal Vokáč
Reviewed-by: Andrew Lunn
Andrew
> nxp-c45-tja11xx is acceptable from my point of view.
Great. Enough bike shedding, nxp-c45-tja11xx it is.
Andrew
> Ok, we can agree that there will not be a perfect naming. Would it be a
> possibility to rename the existing TJA11xx driver to TJA1100-1-2 or is that
> unwanted?
It is generally a bad idea. It makes back porting fixing harder if the
file changes name.
> If nxp-c45.c is to generic (I take from y
On Tue, Apr 13, 2021 at 08:56:30AM +0200, Christian Herber wrote:
> Hi Andrew,
>
> On 4/12/2021 6:52 PM, Andrew Lunn wrote:
> >
> > So what you are say is, you don't care if the IP is completely
> > different, it all goes in one driver. So lets put this driver int
> Indeed - it should be a logical and operation - there is light present
> _and_ the PHY recognises the signal. This is what the commit achieves,
> although (iirc) doesn't cater for the case where there is no SFP cage
> attached.
Hi Russell
Is there something like this in the marvell10 driver?
A
On Tue, Apr 13, 2021 at 10:13:49AM +0300, Ivan Bornyakov wrote:
> On Tue, Apr 13, 2021 at 01:32:12AM +0200, Marek Behún wrote:
> > On Mon, 12 Apr 2021 15:16:59 +0300
> > Ivan Bornyakov wrote:
> >
> > > Some SFP modules uses RX_LOS for link indication. In such cases link
> > > will be always up, e
> I guess this is depends whether the most usual case is to have all
> these interrupts being actively in use or not. Most interrupts only
> use a limited portion of their interrupt space at any given time.
> Allocating all interrupts and creating mappings upfront is a waste of
> memory.
>
> If th
associated with that device.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
; - else {}
>
> @@
> identifier a.x;
> expression e;
> @@
> - if (<+... x ...+>@e)
> - {}
> - else
> + if (!(e))
> {...}
>
> @@
> expression x, y, z;
> @@
> - x = of_get_mac_address(y, z);
> + of_get_mac_address(y, z);
> ... when != x
>
>
> All drivers, except drivers/net/ethernet/aeroflex/greth.c, were
> compile-time tested.
>
> Suggested-by: Andrew Lunn
> Signed-off-by: Michael Walle
I cannot say i looked at all the changes, but the ones i did exam
seemed O.K.
Reviewed-by: Andrew Lunn
Andrew
> > > +static void
> > > +mt7530_setup_mdio_irq(struct mt7530_priv *priv)
> > > +{
> > > + struct dsa_switch *ds = priv->ds;
> > > + int p;
> > > +
> > > + for (p = 0; p < MT7530_NUM_PHYS; p++) {
> > > + if (BIT(p) & ds->phys_mii_mask) {
> > > + unsigned int irq;
> > > +
> >
On Tue, Apr 13, 2021 at 12:24:49AM +0200, Martin Blumenstingl wrote:
> Hi Andrew,
>
> On Mon, Apr 12, 2021 at 1:16 AM Andrew Lunn wrote:
> >
> > On Sun, Apr 11, 2021 at 10:55:11PM +0200, Martin Blumenstingl wrote:
> > > Add support for .get_regs_len and .get_re
On Mon, Apr 12, 2021 at 03:16:59PM +0300, Ivan Bornyakov wrote:
> Some SFP modules uses RX_LOS for link indication. In such cases link
> will be always up, even without cable connected. RX_LOS changes will
> trigger link_up()/link_down() upstream operations. Thus, check that SFP
> link is operation
> +static const struct nxp_c45_phy_stats nxp_c45_hw_stats[] = {
> + { "phy_symbol_error_cnt", MDIO_MMD_VEND1, SYMBOL_ERROR_COUNTER, 0,
> GENMASK(15, 0) },
> + { "phy_link_status_drop_cnt", MDIO_MMD_VEND1, LINK_DROP_COUNTER, 8,
> GENMASK(13, 8) },
> + { "phy_link_availability_drop_cnt"
caletechnologies/linux/issues/1
> Fixes: fee2d546414d ("net: phy: marvell: mv88e6390 temperature sensor
> reading")
> Reviewed-by: Marek Behún
Reviewed-by: Andrew Lunn
Andrew
On Mon, Apr 12, 2021 at 05:49:04PM +0300, Radu Nicolae Pirea (NXP OSS) wrote:
> On Mon, 2021-04-12 at 16:23 +0200, Andrew Lunn wrote:
> > > It is purely a C45 device.
> >
> > > Even if the PHY will be based on the same IP or not, if it is a C45
> > > PHY, it
On Mon, Apr 12, 2021 at 05:52:39PM +0200, Pali Rohár wrote:
> On Monday 12 April 2021 17:32:33 Andrew Lunn wrote:
> > > Anyway, now I'm looking at phy/marvell.c driver again and it supports
> > > only 88E6341 and 88E6390 families from whole 88E63xxx range.
> > >
> Anyway, now I'm looking at phy/marvell.c driver again and it supports
> only 88E6341 and 88E6390 families from whole 88E63xxx range.
>
> So do we need to define for now table for more than
> MV88E6XXX_FAMILY_6341 and MV88E6XXX_FAMILY_6390 entries?
Probably not. I've no idea if the 6393 has an I
On Mon, Apr 12, 2021 at 03:34:47PM +0200, Pali Rohár wrote:
> On Monday 12 April 2021 15:15:07 Andrew Lunn wrote:
> > > +static u16 mv88e6xxx_physid_for_family(enum mv88e6xxx_family family);
> > > +
> >
> > No forward declaration please. Move the code around. It
> > > +/* This table contains representative model for every family */
> > > +static const enum mv88e6xxx_model family_model_table[] = {
> > > + [MV88E6XXX_FAMILY_6095] = MV88E6095,
> > > + [MV88E6XXX_FAMILY_6097] = MV88E6097,
> > > + [MV88E6XXX_FAMILY_6185] = MV88E6185,
> > > + [MV88E6XXX_FAMILY_6
> It is purely a C45 device.
> Even if the PHY will be based on the same IP or not, if it is a C45
> PHY, it will be supported by this driver. We are not talking about 2 or
> 3 PHYs. This driver will support all future C45 PHYs. That's why we
> named it "NXP C45".
So if in future you produce C45
> +static u16 mv88e6xxx_physid_for_family(enum mv88e6xxx_family family);
> +
No forward declaration please. Move the code around. It is often best
to do that in a patch which just moves code, no other changes. It
makes it easier to review.
> static int mv88e6xxx_mdio_read(struct mii_bus *bus, in
On Mon, Apr 12, 2021 at 01:02:07PM +0300, Radu Nicolae Pirea (NXP OSS) wrote:
> On Fri, 2021-04-09 at 21:36 +0200, Andrew Lunn wrote:
> > On Fri, Apr 09, 2021 at 09:41:06PM +0300, Radu Pirea (NXP OSS) wrote:
> > > Add driver for tja1103 driver and for future NXP C45 PHYs.
>
> +static void mana_gd_deregiser_irq(struct gdma_queue *queue)
> +{
> + struct gdma_dev *gd = queue->gdma_dev;
> + struct gdma_irq_context *gic;
> + struct gdma_context *gc;
> + struct gdma_resource *r;
> + unsigned int msix_index;
> + unsigned long flags;
> +
> + /* At
> +static inline bool is_gdma_msg(const void *req)
> +{
> + struct gdma_req_hdr *hdr = (struct gdma_req_hdr *)req;
> +
> + if (hdr->req.hdr_type == GDMA_STANDARD_HEADER_TYPE &&
> + hdr->resp.hdr_type == GDMA_STANDARD_HEADER_TYPE &&
> + hdr->req.msg_size >= sizeof(struct gdma
> > Currently the protocol versin is 0.1.1 You may ask why it's called
> > "drv version" rather than "protocol version" -- it's because the PF driver
> > calls it that way, so I think here the VF driver may as well use the same
> > name. BTW, the "drv ver" info is passed to the PF driver in the bel
On Sun, Apr 11, 2021 at 10:55:11PM +0200, Martin Blumenstingl wrote:
> Add support for .get_regs_len and .get_regs so it is easier to find out
> about the state of the ports on the GSWIP hardware. For this we
> specifically add the GSWIP_MAC_PSTATp(port) and GSWIP_MDIO_STATp(port)
> register #defin
On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
> On Sat, 10 Apr 2021 15:34:46 +0200
> Ansuel Smith wrote:
>
> > Hi,
> > this is a respin of the Marek series in hope that this time we can
> > finally make some progress with dsa supporting multi-cpu port.
> >
> > This implementation
On Fri, Apr 09, 2021 at 09:41:06PM +0300, Radu Pirea (NXP OSS) wrote:
> Add driver for tja1103 driver and for future NXP C45 PHYs.
So apart from c45 vs c22, how does this differ to nxp-tja11xx.c?
Do we really want two different drivers for the same hardware?
Can we combine them somehow?
> +conf
For the structs containing variables with the same sizes, or already size
aligned
> variables, we knew the __packed has no effect. And for these structs, it
> doesn't
> cause performance impact either, correct?
>
> But in the future, if different sized variables are added, the __packed may
Hi Sven
> Many thanks to Heiner Kallweit for suggesting this solution.
Adding a Suggested-by: would be good. And it might sometime help
Johnathan Corbet extract some interesting statistics from the commit
messages if everybody uses the same format.
Andrew
> Linux kernel doesn't do namespaces in the code, so every new driver needs
> to worry about global symbols clashing
This driver is called mana, yet the code uses ana. It would be good to
resolve this inconsistency as well. Ideally, you want to prefix
everything with ana_ or mana_, depending on wh
On Thu, Apr 08, 2021 at 11:00:08PM +0800, DENG Qingfang wrote:
> Hi René,
>
> On Thu, Apr 8, 2021 at 10:02 PM René van Dorst wrote:
> >
> > Tested on Ubiquiti ER-X-SFP (MT7621) with 1 external phy which uses
> > irq=POLL.
> >
>
> I wonder if the external PHY's IRQ can be registered in the devic
> > > diff --git a/drivers/net/ethernet/microsoft/Kconfig
> > b/drivers/net/ethernet/microsoft/Kconfig
> > > new file mode 100644
> > > index ..12ef6b581566
> > > --- /dev/null
> > > +++ b/drivers/net/ethernet/microsoft/Kconfig
> > > @@ -0,0 +1,30 @@
> > > +#
> > > +# Microsoft Azure ne
> If dropping the modifications to gswip_phylink_mac_config is my only change:
> do you want me to keep or drop your Reviewed-by in v2?
You can keep it.
Andrew
On Wed, Apr 07, 2021 at 12:50:38PM +0800, DENG Qingfang wrote:
> Enable MT7530 interrupt controller in the MT7621 SoC.
>
> Signed-off-by: DENG Qingfang
Reviewed-by: Andrew Lunn
Andrew
On Wed, Apr 07, 2021 at 12:50:37PM +0800, DENG Qingfang wrote:
> Add device tree binding to support MT7530 interrupt controller.
>
> Signed-off-by: DENG Qingfang
Reviewed-by: Andrew Lunn
Andrew
On Wed, Apr 07, 2021 at 12:50:36PM +0800, DENG Qingfang wrote:
> Add support for MT7530 interrupt controller to handle internal PHYs.
> In order to assign an IRQ number to each PHY, the registration of MDIO bus
> is also done in this driver.
>
> Signed-off-by: DENG Qingfang
> ---
> RFC v1 -> RFC
; Signed-off-by: DENG Qingfang
Reviewed-by: Andrew Lunn
Andrew
> For my own curiosity: is there a "recommended" way where to configure
> link up/down, speed, duplex and flow control? currently I have the
> logic in both, .phylink_mac_config and .phylink_mac_link_up.
You probably want to read the documentation in
include/linux/phylink.h
Andrew
On Wed, Apr 07, 2021 at 10:15:37PM +0800, Wong Vee Khee wrote:
> From: Tan Tee Min
>
> The Synopsis MAC controller supports auxiliary snapshot feature that
> allows user to store a snapshot of the system time based on an external
> event.
>
> This patch add supports to the above mentioned featur
> Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell
> multi-gige PHY can do rate adaption right?
The Marvell/Marvell multi-gige PHY can also do rate
adaptation. Marvell buying Aquantia made naming messy :-(
I should probably use part numbers.
> Hence, we still need to take care o
> And, some variable defines can not follow the reverse christmas tree
> style due to dependency, e.g.
> static void hwc_init_event_handler(void *ctx, struct gdma_queue *q_self,
>struct gdma_event *event)
> {
> struct hw_channel_context *hwc = ctx;
>
> +static int gdma_query_max_resources(struct pci_dev *pdev)
> +{
> + struct gdma_context *gc = pci_get_drvdata(pdev);
> + struct gdma_general_req req = { 0 };
> + struct gdma_query_max_resources_resp resp = { 0 };
> + int err;
Network drivers need to use reverse christmas tree. I
On Tue, Apr 06, 2021 at 06:50:40AM +0200, Ansuel Smith wrote:
> qca8k 83xx switch have 2 cpu ports. Rework the driver to support
> multiple cpu port. All ports can access both cpu ports by default as
> they support the same features.
Do you have more information about how this actually works. How
> case PHY_INTERFACE_MODE_RGMII:
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> miicfg |= GSWIP_MII_CFG_MODE_RGMII;
> +
> + if (phylink_autoneg_inband(mode))
> +
_gswip: Let GSWIP automatically set
> the xMII clock")
> Cc: sta...@vger.kernel.org
> Acked-by: Hauke Mehrtens
> Signed-off-by: Martin Blumenstingl
Having the MAC polling the PHY is pretty much always a bad idea.
Reviewed-by: Andrew Lunn
Andrew
On Tue, Apr 06, 2021 at 05:49:03AM +0200, Ansuel Smith wrote:
> In preparation for the future when dsa will support multi cpu port,
> dsa_cpu_ports can be useful for switch that has multiple cpu port to
> retrieve the cpu mask for ACL and bridge table.
>
> Signed-off-by: Ansuel Smith
> ---
> inc
> The limitation is not on the MAC, PCS or the PHY. For Intel mgbe, the
> overclocking of 2.5 times clock rate to support 2.5G is only able to be
> configured in the BIOS during boot time. Kernel driver has no access to
> modify the clock rate for 1Gbps/2.5G mode. The way to determined the
> curr
On Tue, Apr 06, 2021 at 11:57:14PM +0800, DENG Qingfang wrote:
> On Tue, Apr 6, 2021 at 11:47 PM Chun-Kuang Hu wrote:
> >
> > Hi, Qingfang:
> >
> > DENG Qingfang 於 2021年4月6日 週二 下午10:19寫道：
> > > --- a/drivers/net/phy/Kconfig
> > > +++ b/drivers/net/phy/Kconfig
> > > @@ -207,6 +207,11 @@ config MAR
On Tue, Apr 06, 2021 at 11:47:08PM +0800, Chun-Kuang Hu wrote:
> Hi, Qingfang:
>
> DENG Qingfang 於 2021年4月6日 週二 下午10:19寫道：
> >
> > Add support for MediaTek PHYs found in MT7530 and MT7531 switches.
> > The initialization procedure is from the vendor driver, but due to lack
> > of documentation, t
On Tue, Apr 06, 2021 at 11:39:12PM +0800, DENG Qingfang wrote:
> On Tue, Apr 6, 2021 at 11:30 PM Andrew Lunn wrote:
> >
> > On Tue, Apr 06, 2021 at 10:18:17PM +0800, DENG Qingfang wrote:
> > > Add support for MT7530 interrupt controller to handle internal PHYs.
> >
On Tue, Apr 06, 2021 at 10:18:17PM +0800, DENG Qingfang wrote:
> Add support for MT7530 interrupt controller to handle internal PHYs.
Are the interrupts purely PHY interrupts? Or are there some switch
operation interrupts, which are currently not used?
I'm just wondering if it is correct to so cl
On Tue, Apr 06, 2021 at 10:18:16PM +0800, DENG Qingfang wrote:
> Add support for MediaTek PHYs found in MT7530 and MT7531 switches.
Do you know if this PHY is available standalone?
> +static int mt7531_phy_config_init(struct phy_device *phydev)
> +{
> + mtk_phy_config_init(phydev);
> +
> +
> > Speed: 2500Mb/s and Duplex: Half is very unlikely. You really only
> > ever see 10 Half and occasionally 100 Half. Anything above that will
> > be full duplex.
> >
> > It is probably best to admit the truth and use DUPLEX_UNKNOWN.
>
> Agreed. I didn't notice this "lie" until I was writing the
On Mon, Apr 05, 2021 at 04:13:40PM -0700, Grant Grundler wrote:
> This series introduces support for USB network devices that report
> speed as a part of their protocol, not emulating an MII to be accessed
> over MDIO.
>
> v2: rebased on recent upstream changes
> v3: incorporated hints on naming a
On Tue, Apr 06, 2021 at 03:19:11AM +0800, kernel test robot wrote:
> Hi Michael,
>
> I love your patch! Yet something to improve:
Looks correct. You missed the #else case for #ifdef CONFIG_OF in
stmmac_platform.c
Lets see what else 0-day finds before i start reviewing.
Andrew
On Mon, Apr 05, 2021 at 08:39:54PM +0200, Corentin Labbe wrote:
> mdio0: ethernet-phy {
Not relevant to the brokennes, but this should not be called
ethernet-phy. The example given in
Documentation/devicetree/bindings/net/mdio-gpio.txt is
mdio0: mdio
> compatible = "virtual,
> Now, instead of encoding this information of the bus' capabilities at both
> places, I'd propose just checking the mii_bus->capabilities field in the
> mdiobus_c45_*() functions. IMHO this would be a little cleaner, than having
> two
> places where this information is stored. What do you think a
> > You have a MAC and an PCS in the stmmac IP block. That then has
> > some
> > sort of SERDES interface, running 1000BaseX, SGMII, SGMII
> > overclocked
> > at 2.5G or 25000BaseX. Connected to the SERDES you have a PHY
> > which
> > converts to copper, giving you 2500BaseT.
> >
> > You said earl
On Sun, Apr 04, 2021 at 09:23:55PM +0200, Danilo Krummrich wrote:
> On Fri, Apr 02, 2021 at 01:58:58PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Fri, Apr 02, 2021 at 03:10:49AM +0200, Danilo Krummrich wrote:
> > > On Thu, Apr 01, 2021 at 09:48:58AM +0100, Russell King - ARM Linux admin
On Mon, Apr 05, 2021 at 07:29:51PM +0800, Michael Sit Wei Hong wrote:
> This patchset enables 2.5Gbps speed mode for stmmac.
> Link speed mode is detected and configured at serdes power up sequence.
> For 2.5G, we do not use SGMII in-band AN, we check the link speed mode
> in the serdes and disable
1 - 100 of 1132 matches
Mail list logo
