* Re: [PATCH] netdevice: fix sparse warning for HARD_TX_LOCK
From: David Miller @ 2016-11-27 20:44 UTC (permalink / raw)
To: mst; +Cc: linux-kernel, netdev
In-Reply-To: <1479963754-24105-1-git-send-email-mst@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Thu, 24 Nov 2016 07:04:08 +0200
> sparse warns about context imbalance in any code
> that uses HARD_TX_LOCK/UNLOCK - this is because it's
> unable to determine that flags don't change so
> lock and unlock are paired.
>
> Seems easy enough to fix by adding __acquire/__release
> calls.
>
> With this patch af_packet.c is now sparse-clean,
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied to net-next, thanks.
^ permalink raw reply
* [PATCH 1/2] Documentation: net: dsa: marvell: Add 88E6176
From: Andreas Färber @ 2016-11-27 20:57 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Uwe Kleine-König, Michal Hrusecki, Tomas Hlavacek,
Bedřicha Košatu, Andreas Färber, Rob Herring,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
---
Documentation/devicetree/bindings/net/dsa/marvell.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt
index b3dd6b40e0de..000bc3b16edd 100644
--- a/Documentation/devicetree/bindings/net/dsa/marvell.txt
+++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt
@@ -15,6 +15,7 @@ Additional required and optional properties can be found in dsa.txt.
Required properties:
- compatible : Should be one of "marvell,mv88e6085" or
+ "marvell,mv88e6176" or
"marvell,mv88e6190"
- reg : Address on the MII bus for the switch.
--
2.6.6
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andreas Färber @ 2016-11-27 20:57 UTC (permalink / raw)
To: netdev
Cc: linux-arm-kernel, Uwe Kleine-König, Michal Hrusecki,
Tomas Hlavacek, Bedřicha Košatu, Andreas Färber,
Andrew Lunn, Vivien Didelot, Florian Fainelli, linux-kernel
In-Reply-To: <1480280279-9552-1-git-send-email-afaerber@suse.de>
This model is found on the Turris Omnia.
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
drivers/net/dsa/mv88e6xxx/chip.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 77f13ada2612..95b9efb33ec7 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4280,6 +4280,10 @@ static const struct of_device_id mv88e6xxx_of_match[] = {
.data = &mv88e6xxx_table[MV88E6085],
},
{
+ .compatible = "marvell,mv88e6176",
+ .data = &mv88e6xxx_table[MV88E6176],
+ },
+ {
.compatible = "marvell,mv88e6190",
.data = &mv88e6xxx_table[MV88E6190],
},
--
2.6.6
^ permalink raw reply related
* [PATCH] MAINTAINERS: Add device tree bindings to mv88e6xx section
From: Andreas Färber @ 2016-11-27 21:04 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Michal Hrusecki, Uwe Kleine-König,
Vivien Didelot, Tomas Hlavacek, linux-kernel, linux-arm-kernel,
Andreas Färber, Bedřicha Košatu
Also include the netdev list for convenience, as done elsewhere.
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f73e19277a70..46ccf6eadcc9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7670,6 +7670,7 @@ M: Andrew Lunn <andrew@lunn.ch>
M: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
S: Maintained
F: drivers/net/dsa/mv88e6xxx/
+F: Documentation/devicetree/bindings/net/dsa/marvell.txt
MARVELL ARMADA DRM SUPPORT
M: Russell King <rmk+kernel@armlinux.org.uk>
--
2.6.6
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2] MAINTAINERS: Add device tree bindings to mv88e6xx section
From: Andreas Färber @ 2016-11-27 21:07 UTC (permalink / raw)
To: netdev
Cc: linux-arm-kernel, Uwe Kleine-König, Michal Hrusecki,
Tomas Hlavacek, Bedřicha Košatu, Andreas Färber,
Andrew Lunn, Vivien Didelot, linux-kernel
In-Reply-To: <1480280676-10117-1-git-send-email-afaerber@suse.de>
Also include the netdev list for convenience, as done elsewhere.
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f73e19277a70..677d73cfedc7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7668,8 +7668,10 @@ S: Maintained
MARVELL 88E6XXX ETHERNET SWITCH FABRIC DRIVER
M: Andrew Lunn <andrew@lunn.ch>
M: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
+L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/dsa/mv88e6xxx/
+F: Documentation/devicetree/bindings/net/dsa/marvell.txt
MARVELL ARMADA DRM SUPPORT
M: Russell King <rmk+kernel@armlinux.org.uk>
--
2.6.6
^ permalink raw reply related
* Re: [PATCH net-next 09/11] qede: Better utilize the qede_[rt]x_queue
From: Mintz, Yuval @ 2016-11-27 21:17 UTC (permalink / raw)
To: David Miller; +Cc: lkp@intel.com, netdev@vger.kernel.org
In-Reply-To: <20161127.151631.150312523846891505.davem@davemloft.net>
> > I'd say this is a false positive, given that MTU can't be so large.
> False positive or not you must fix the warning and resubmit this
> series with that fixed.
Sure. I'll re-spin later this week [hopefully it'll get some additional
review comments by then].
^ permalink raw reply
* Re: [PATCH] mv88e6xxx: Fix mv88e6xxx_g1_irq_free() interrupt count
From: Andrew Lunn @ 2016-11-27 21:22 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, linux-arm-kernel, Uwe Kleine-König, Michal Hrusecki,
Tomas Hlavacek, Bed??icha Ko??atu, Vivien Didelot,
Florian Fainelli, linux-kernel
In-Reply-To: <1480279424-7830-1-git-send-email-afaerber@suse.de>
On Sun, Nov 27, 2016 at 09:43:44PM +0100, Andreas Färber wrote:
> mv88e6xxx_g1_irq_setup() sets up chip->g1_irq.nirqs interrupt mappings,
> so free the same amount. This will be 8 or 9 in practice, less than 16.
Hi Andreas
The patch is correct, but please read
Documentation/networking/netdev-FAQ.txt
and then resubmit the patch.
Andrew
>
> Fixes: dc30c35be720 ("net: dsa: mv88e6xxx: Implement interrupt support.")
> Cc: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
> drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 98302358ceb9..95b9efb33ec7 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -421,7 +421,7 @@ static void mv88e6xxx_g1_irq_free(struct mv88e6xxx_chip *chip)
>
> free_irq(chip->irq, chip);
>
> - for (irq = 0; irq < 16; irq++) {
> + for (irq = 0; irq < chip->g1_irq.nirqs; irq++) {
> virq = irq_find_mapping(chip->g1_irq.domain, irq);
> irq_dispose_mapping(virq);
> }
> --
> 2.6.6
>
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andrew Lunn @ 2016-11-27 21:27 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, linux-arm-kernel, Uwe Kleine-König, Michal Hrusecki,
Tomas Hlavacek, Bed??icha Ko??atu, Vivien Didelot,
Florian Fainelli, linux-kernel
In-Reply-To: <1480280279-9552-2-git-send-email-afaerber@suse.de>
On Sun, Nov 27, 2016 at 09:57:59PM +0100, Andreas Färber wrote:
> This model is found on the Turris Omnia.
This driver already supports nearly 30 different Marvell switch
models. Please document why the marvell,mv88e6176 is special and why
it needs its own compatible string when the others don't.
Andrew
^ permalink raw reply
* Re: [PATCH] mv88e6xxx: Fix mv88e6xxx_g1_irq_free() interrupt count
From: Andreas Färber @ 2016-11-27 21:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-arm-kernel, Uwe Kleine-König, Michal Hrusecki,
Tomas Hlavacek, Bed??icha Ko??atu, Vivien Didelot,
Florian Fainelli, linux-kernel
In-Reply-To: <20161127212256.GC13318@lunn.ch>
Hi Andrew,
Am 27.11.2016 um 22:22 schrieb Andrew Lunn:
> On Sun, Nov 27, 2016 at 09:43:44PM +0100, Andreas Färber wrote:
>> mv88e6xxx_g1_irq_setup() sets up chip->g1_irq.nirqs interrupt mappings,
>> so free the same amount. This will be 8 or 9 in practice, less than 16.
>
> Hi Andreas
>
> The patch is correct, but please read
> Documentation/networking/netdev-FAQ.txt
> and then resubmit the patch.
Do you mean --subject-prefix="PATCH net-next" or something else?
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2] MAINTAINERS: Add device tree bindings to mv88e6xx section
From: Andrew Lunn @ 2016-11-27 21:33 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, linux-arm-kernel, Uwe Kleine-König, Michal Hrusecki,
Tomas Hlavacek, Bed??icha Ko??atu, Vivien Didelot, linux-kernel
In-Reply-To: <1480280850-10409-1-git-send-email-afaerber@suse.de>
On Sun, Nov 27, 2016 at 10:07:30PM +0100, Andreas Färber wrote:
> Also include the netdev list for convenience, as done elsewhere.
Please indicate which maintainer you expect to accept this. And if that
is David Miller, please fix the Subject: line.
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] mv88e6xxx: Fix mv88e6xxx_g1_irq_free() interrupt count
From: Andrew Lunn @ 2016-11-27 21:39 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, linux-arm-kernel, Uwe Kleine-König, Michal Hrusecki,
Tomas Hlavacek, Bed??icha Ko??atu, Vivien Didelot,
Florian Fainelli, linux-kernel
In-Reply-To: <ff0d121a-0ecb-8af7-af11-cf94df31639c@suse.de>
On Sun, Nov 27, 2016 at 10:32:41PM +0100, Andreas Färber wrote:
> Hi Andrew,
>
> Am 27.11.2016 um 22:22 schrieb Andrew Lunn:
> > On Sun, Nov 27, 2016 at 09:43:44PM +0100, Andreas Färber wrote:
> >> mv88e6xxx_g1_irq_setup() sets up chip->g1_irq.nirqs interrupt mappings,
> >> so free the same amount. This will be 8 or 9 in practice, less than 16.
> >
> > Hi Andreas
> >
> > The patch is correct, but please read
> > Documentation/networking/netdev-FAQ.txt
> > and then resubmit the patch.
>
> Do you mean --subject-prefix="PATCH net-next"
Yep.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andreas Färber @ 2016-11-27 21:50 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Michal Hrusecki, Uwe Kleine-König,
Vivien Didelot, netdev, Tomas Hlavacek, linux-kernel,
linux-arm-kernel, Bed??icha Ko??atu
In-Reply-To: <20161127212709.GD13318@lunn.ch>
Am 27.11.2016 um 22:27 schrieb Andrew Lunn:
> On Sun, Nov 27, 2016 at 09:57:59PM +0100, Andreas Färber wrote:
>> This model is found on the Turris Omnia.
>
> This driver already supports nearly 30 different Marvell switch
> models. Please document why the marvell,mv88e6176 is special and why
> it needs its own compatible string when the others don't.
I don't understand.
The commit message above already points out for which device this is
(and you also know from the LAKML thread).
You as driver author should know that the .data pointer is vital to your
driver - you even recently accepted another model that conflicted with
my patch. So are you arguing for a ", which uses a Device Tree for
booting" half-sentence here?
The others not having an entry simply means no one needed them yet.
And any Turris Omnia side changes need to go through the mvebu tree.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andrew Lunn @ 2016-11-27 22:08 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, linux-arm-kernel, Uwe Kleine-König, Michal Hrusecki,
Tomas Hlavacek, Bed??icha Ko??atu, Vivien Didelot,
Florian Fainelli, linux-kernel
In-Reply-To: <9500470d-09c3-3ecb-994b-3d108bffc99e@suse.de>
> > This driver already supports nearly 30 different Marvell switch
> > models. Please document why the marvell,mv88e6176 is special and why
> > it needs its own compatible string when the others don't.
>
> I don't understand.
Think about what i said. Why does the 6176 need its own compatible
string, when the two 6352s and the 6165 on the zii-devel-b don't have
one? And the DIR 665 has a 6171, which does not have a compatible
string of its own. The clearfog actually has a 6176, and it seems to
work fine without a compatible string.
> You as driver author should know that the .data pointer is vital to your
> driver
Exactly, so if i ask why is it needed, maybe you should stop and think
for a while.
> you even recently accepted another model that conflicted with
> my patch.
And think about that also, and you will find the 6390 family, who's
first device is 6190, is not compatible with the 6085, and so needs a
different compatible string.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] Documentation: net: phy: Add blurb about RGMII
From: Timur Tabi @ 2016-11-27 22:24 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: davem, andrew, sf84, martin.blumenstingl, mans, alexandre.torgue,
peppe.cavallaro, jbrunet
In-Reply-To: <20161127184449.12351-4-f.fainelli@gmail.com>
Just some grammatical corrections. You might want to run a spellchecker
on all the patches.
Florian Fainelli wrote:
> + The Reduced Gigabit Medium Independent Interface (RGMII) is a 12 pins
"is a 12-pin"
> + electrical signal interface using a synchronous 125Mhz clock signal and several
> + data lines. Due to this design decision, a 1.5ns to 2ns delay must be added
> + between the clock line (RXC or TXC) and the data lines to let the PHY (clock
> + sink) have enough setup and hold times to sample the data lines correctly. The
> + PHY library offers different types of PHY_INTERFACE_MODE_RGMII* values to let
> + the PHY driver and optionaly the MAC driver implement the required delay. The
"driver, and optionally the MAC driver, implement"
> + values of phy_interface_t must be understood from the perspective of the PHY
> + device itself, leading to the following:
> +
> + * PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any
> + internal delay by itself, it assumes that either the Ethernet MAC (if capable
> + or the PCB traces) insert the correct 1.5-2ns delay
> +
> + * PHY_INTERFACE_MODE_RGMII_TXID: the PHY should be inserting an internal delay
"should insert"
> + for the transmit data lines (TXD[3:0]) processed by the PHY device
> +
> + * PHY_INTERFACE_MODE_RGMII_RXID: the PHY should be inserting an internal delay
"should insert"
> + for the receive data lines (RXD[3:0]) processed by the PHY device
> +
> + * PHY_INTERFACE_MODE_RGMII_ID: the PHY should be inserting internal delays for
"should insert"
> + both transmit AND receive data lines from/to the PHY device
> +
> + Whenever it is possible, it is preferrable to utilize the PHY side RGMII delay
> + for several reasons:
"Whenever possible, use the PHY side RGMII delay for these reasons:"
> + * PHY devices may offer sub-nanosecond granularity in how they allow a
> + receiver/transmitter side delay (e.g: 0.5, 1.0, 1.5ns) to be specified. Such
> + precision may be required to account for differences in PCB trace lengths
> +
> + * PHY devices are typically qualified for a large range of applications
> + (industrial, medical, automotive...), and they provide a constant and
> + reliable delay across temperature/pressure/voltage ranges
> +
> + * PHY device drivers in PHYLIB being reusable by nature, being able to
> + configure correctly a specified delay enables more designs with similar delay
> + requirements to be operate correctly
Ok, this one I don't know how to fix. I'm not really sure what you're
trying to say.
> +
> + For cases where the PHY is not capable of providing this delay, but the
> + Ethernet MAC driver is capable of doing it, the correct phy_interface_t value
"doing so,"
> + should be PHY_INTERFACE_MODE_RGMII, and the Ethernet MAC driver should be
> + configured correctly in order to provide the required transmit and/or receive
> + side delay from the perspective of the PHY device. Conversely, if the Ethernet
> + MAC driver looks at the phy_interface_t value, for any other mode but
> + PHY_INTERFACE_MODE_RGMII, it should make sure that the MAC-level delays are
> + disabled.
> +
> + In case neither the Ethernet MAC, nor the PHY are capable of providing the
> + required delays, as defined per the RGMII standard, several options may be
> + available:
> +
> + * Some SoCs may offer a pin pad/mux/controller capable of configuring a given
> + set of pins' drive strength, delays and voltage, and it may be a suitable
"strength, delays, and voltage; and"
> + option to insert the expected 2ns RGMII delay
> +
> + * Modifying the PCB design to include a fixed delay (e.g: using a specifically
> + designed serpentine), which may not require software configuration at all
period after "all".
> +
> +Common problems with RGMII delay mismatch
> +
> + When there is a RGMII delay mismatch between the Ethernet MAC and the PHY, this
> + will most likely result in the clock and data line sampling to capture unstable
I'm not sure what "sampling to capture unstable" is supposed to mean.
> + signals, typical symptoms include:
> +
> + * Transmission/reception partially works, and there is frequent or occasional
> + packet loss observed
> +
> + * Ethernet MAC may report some, or all packets ingressing with a FCS/CRC error,
No comma after "some".
> + or just discard them all
> +
> + * Switching to lower speeds such as 10/100Mbits/sec makes the problem go away
> + (since there is enough setup/hold time in that case)
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
^ permalink raw reply
* [PATCH net-next] net: dsa: mv88e6xxx: Fix mv88e6xxx_g1_irq_free() interrupt count
From: Andreas Färber @ 2016-11-27 22:26 UTC (permalink / raw)
To: David S . Miller
Cc: Uwe Kleine-König, Michal Hrusecki, Tomas Hlavacek,
Bedřicha Košatu, Andreas Färber, Andrew Lunn,
Vivien Didelot, Florian Fainelli, netdev, linux-kernel
mv88e6xxx_g1_irq_setup() sets up chip->g1_irq.nirqs interrupt mappings,
so free the same amount. This will be 8 or 9 in practice, less than 16.
Fixes: dc30c35be720 ("net: dsa: mv88e6xxx: Implement interrupt support.")
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b14b3d5099c8..77f13ada2612 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -421,7 +421,7 @@ static void mv88e6xxx_g1_irq_free(struct mv88e6xxx_chip *chip)
free_irq(chip->irq, chip);
- for (irq = 0; irq < 16; irq++) {
+ for (irq = 0; irq < chip->g1_irq.nirqs; irq++) {
virq = irq_find_mapping(chip->g1_irq.domain, irq);
irq_dispose_mapping(virq);
}
--
2.6.6
^ permalink raw reply related
* Re: [PATCH net-next] net: dsa: mv88e6xxx: Fix mv88e6xxx_g1_irq_free() interrupt count
From: Andrew Lunn @ 2016-11-27 22:30 UTC (permalink / raw)
To: Andreas Färber
Cc: David S . Miller, Uwe Kleine-König, Michal Hrusecki,
Tomas Hlavacek, Bed??icha Ko??atu, Vivien Didelot,
Florian Fainelli, netdev, linux-kernel
In-Reply-To: <1480285588-13501-1-git-send-email-afaerber@suse.de>
On Sun, Nov 27, 2016 at 11:26:28PM +0100, Andreas Färber wrote:
> mv88e6xxx_g1_irq_setup() sets up chip->g1_irq.nirqs interrupt mappings,
> so free the same amount. This will be 8 or 9 in practice, less than 16.
>
> Fixes: dc30c35be720 ("net: dsa: mv88e6xxx: Implement interrupt support.")
> Cc: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andreas Färber @ 2016-11-27 22:42 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-arm-kernel, Uwe Kleine-König, Michal Hrusecki,
Tomas Hlavacek, Bed??icha Ko??atu, Vivien Didelot,
Florian Fainelli, linux-kernel
In-Reply-To: <20161127220846.GH13318@lunn.ch>
Andrew,
Am 27.11.2016 um 23:08 schrieb Andrew Lunn:
>>> This driver already supports nearly 30 different Marvell switch
>>> models. Please document why the marvell,mv88e6176 is special and why
>>> it needs its own compatible string when the others don't.
>>
>> I don't understand.
>
> Think about what i said. Why does the 6176 need its own compatible
> string, when the two 6352s and the 6165 on the zii-devel-b don't have
> one? And the DIR 665 has a 6171, which does not have a compatible
> string of its own. The clearfog actually has a 6176, and it seems to
> work fine without a compatible string.
>
>> You as driver author should know that the .data pointer is vital to your
>> driver
>
> Exactly, so if i ask why is it needed, maybe you should stop and think
> for a while.
>
>> you even recently accepted another model that conflicted with
>> my patch.
>
> And think about that also, and you will find the 6390 family, who's
> first device is 6190, is not compatible with the 6085, and so needs a
> different compatible string.
Try to see it from my perspective: I see that some vf610 device I don't
have (found via `git grep marvell,mv88e6` or so) uses
"marvell,mv88e6085". I then assume it has that device on board. How
would I know it doesn't? Same for the other boards you mention.
Unfortunately some of your replies are slightly cryptic. Had you simply
replied 'please just use "marvell,mv88e6085" instead', it would've been
much more clear what you want. (Same for extending the subject instead
of just pointing to some FAQ.)
So are you okay with patch 1/2 documenting the compatible? Then we could
drop 2/2 and use "marvell,mv88e6176", "marvell,mv88e6085" instead of
just the latter. Or would you rather drop both and keep the actual chip
a comment?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] Documentation: net: phy: Add blurb about RGMII
From: Florian Fainelli @ 2016-11-27 23:02 UTC (permalink / raw)
To: Timur Tabi, netdev
Cc: davem, andrew, sf84, martin.blumenstingl, mans, alexandre.torgue,
peppe.cavallaro, jbrunet
In-Reply-To: <583B5D3B.4040108@codeaurora.org>
Le 27/11/2016 à 14:24, Timur Tabi a écrit :
>> + * PHY device drivers in PHYLIB being reusable by nature, being able to
>> + configure correctly a specified delay enables more designs with
>> similar delay
>> + requirements to be operate correctly
>
> Ok, this one I don't know how to fix. I'm not really sure what you're
> trying to say.
What I am trying to say is that once a PHY driver properly configures a
delay that you have specified, there is no reason why this is not
applicable to other platforms using this same PHY driver.
>> +
>> +Common problems with RGMII delay mismatch
>> +
>> + When there is a RGMII delay mismatch between the Ethernet MAC and
>> the PHY, this
>> + will most likely result in the clock and data line sampling to
>> capture unstable
>
> I'm not sure what "sampling to capture unstable" is supposed to mean.
When the PHY devices takes a "snapshot" of the state of the data lines,
after a clock edge, if the delay is improperly configured, these data
lines are going to still be floating, or show some kind of
capacitance/inductance effect, so the logical level which is going to be
read may be incorrect.
--
Florian
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andrew Lunn @ 2016-11-27 23:10 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, linux-arm-kernel, Uwe Kleine-König, Michal Hrusecki,
Tomas Hlavacek, Bed??icha Ko??atu, Vivien Didelot,
Florian Fainelli, linux-kernel
In-Reply-To: <e5d45b55-a4c1-3b5e-0bdc-a5e340b072d0@suse.de>
> Try to see it from my perspective: I see that some vf610 device I don't
> have (found via `git grep marvell,mv88e6` or so) uses
> "marvell,mv88e6085". I then assume it has that device on board. How
> would I know it doesn't? Same for the other boards you mention.
>
> Unfortunately some of your replies are slightly cryptic. Had you simply
> replied 'please just use "marvell,mv88e6085" instead', it would've been
> much more clear what you want. (Same for extending the subject instead
> of just pointing to some FAQ.)
By reading the FAQ you have learnt more than me saying put the correct
tree in the subject line. By asking you to explain why you need a
compatible string, i'm trying to make you think, look at the code and
understand it. In the future, you might think and understand the code
before posting a patch, and then we all save time.
> So are you okay with patch 1/2 documenting the compatible? Then we could
> drop 2/2 and use "marvell,mv88e6176", "marvell,mv88e6085" instead of
> just the latter. Or would you rather drop both and keep the actual chip
> a comment?
A comment only please.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net 1/1] driver: ipvlan: Fix one possible memleak in ipvlan_link_new
From: David Miller @ 2016-11-28 0:58 UTC (permalink / raw)
To: fgao; +Cc: maheshb, edumazet, netdev, gfree.wind
In-Reply-To: <1480001999-10500-1-git-send-email-fgao@ikuai8.com>
From: fgao@ikuai8.com
Date: Thu, 24 Nov 2016 23:39:59 +0800
> From: Gao Feng <fgao@ikuai8.com>
>
> When ipvlan_link_new fails and creates one ipvlan port, it does not
> destroy the ipvlan port created. It causes mem leak and the physical
> device contains invalid ipvlan data.
>
> Signed-off-by: Gao Feng <fgao@ikuai8.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] irda: fix overly long udelay()
From: David Miller @ 2016-11-28 1:00 UTC (permalink / raw)
To: arnd; +Cc: samuel, netdev, linux-kernel
In-Reply-To: <20161124162630.3802535-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 24 Nov 2016 17:26:22 +0100
> irda_get_mtt() returns a hardcoded '10000' in some cases,
> and with gcc-7, we get a build error because this triggers a
> compile-time check in udelay():
>
> drivers/net/irda/w83977af_ir.o: In function `w83977af_hard_xmit':
> w83977af_ir.c:(.text.w83977af_hard_xmit+0x14c): undefined reference to `__bad_udelay'
>
> Older compilers did not run into this because they either did not
> completely inline the irda_get_mtt() or did not consider the
> 10000 value a constant expression.
>
> The code has been wrong since the start of git history.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks Arnd.
^ permalink raw reply
* Re: [PATCH net v2 0/5] net: fix phydev reference leaks
From: David Miller @ 2016-11-28 1:02 UTC (permalink / raw)
To: johan
Cc: f.fainelli, madalin.bucur, timur, andrew, vivien.didelot, netdev,
linux-kernel
In-Reply-To: <1480011691-13278-1-git-send-email-johan@kernel.org>
From: Johan Hovold <johan@kernel.org>
Date: Thu, 24 Nov 2016 19:21:26 +0100
> This series fixes a number of phydev reference leaks (and one of_node
> leak) due to failure to put the reference taken by of_phy_find_device().
>
> Note that I did not try to fix drivers/net/phy/xilinx_gmii2rgmii.c which
> still leaks a reference.
>
> Against net but should apply just as fine to net-next.
...
> v2:
> - use put_device() instead of phy_dev_free() to put the references
> taken in net/dsa (patch 1/4).
> - add four new patches fixing similar leaks
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 1/1] driver: macvtap: Unregister netdev rx_handler if macvtap_newlink fails
From: David Miller @ 2016-11-28 1:04 UTC (permalink / raw)
To: fgao; +Cc: jasowang, edumazet, netdev, gfree.wind
In-Reply-To: <1480039506-29740-1-git-send-email-fgao@ikuai8.com>
From: fgao@ikuai8.com
Date: Fri, 25 Nov 2016 10:05:06 +0800
> From: Gao Feng <fgao@ikuai8.com>
>
> The macvtap_newlink registers the netdev rx_handler firstly, but it
> does not unregister the handler if macvlan_common_newlink failed.
>
> Signed-off-by: Gao Feng <fgao@ikuai8.com>
Applied.
^ permalink raw reply
* Re: pull request (net): ipsec 2016-11-25
From: David Miller @ 2016-11-28 1:22 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1480057080-20177-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri, 25 Nov 2016 07:57:57 +0100
> 1) Fix a refcount leak in vti6.
> From Nicolas Dichtel.
>
> 2) Fix a wrong if statement in xfrm_sk_policy_lookup.
> From Florian Westphal.
>
> 3) The flowcache watermarks are per cpu. Take this into
> account when comparing to the threshold where we
> refusing new allocations. From Miroslav Urbanek.
>
> Please pull or let me know if there are problems.
Pulled, thanks Steffen!
^ permalink raw reply
* Re: [PATCH 1/1] net: macb: fix the RX queue reset in macb_rx()
From: David Miller @ 2016-11-28 1:25 UTC (permalink / raw)
To: cyrille.pitchen
Cc: nicolas.ferre, netdev, soren.brinkmann, Andrei.Pistirica,
linux-arm-kernel, linux-kernel
In-Reply-To: <fd8131cbe6c0546b2b8ee35bcaac5e7eb1a1647f.1480063339.git.cyrille.pitchen@atmel.com>
From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Date: Fri, 25 Nov 2016 09:49:32 +0100
> On macb only (not gem), when a RX queue corruption was detected from
> macb_rx(), the RX queue was reset: during this process the RX ring
> buffer descriptor was initialized by macb_init_rx_ring() but we forgot
> to also set bp->rx_tail to 0.
>
> Indeed, when processing the received frames, bp->rx_tail provides the
> macb driver with the index in the RX ring buffer of the next buffer to
> process. So when the whole ring buffer is reset we must also reset
> bp->rx_tail so the driver is synchronized again with the hardware.
>
> Since macb_init_rx_ring() is called from many locations, currently from
> macb_rx() and macb_init_rings(), we'd rather add the "bp->rx_tail = 0;"
> line inside macb_init_rx_ring() than add the very same line after each
> call of this function.
>
> Without this fix, the rx queue is not reset properly to recover from
> queue corruption and connection drop may occur.
>
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> Fixes: 9ba723b081a2 ("net: macb: remove BUG_ON() and reset the queue to handle RX errors")
This doesn't apply cleanly to the 'net' tree, where
RX_RING_SIZE is used instead of bp->rx_ring_size. It seems
you generated this against net-next, however you didn't say
that either in your Subject line nor the commit message.
As a bug fix this should be targetted at 'net'.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox