* RE: [PATCH net-next] net: adjust skb->truesize in pskb_expand_head()
From: David Laight @ 2017-01-27 10:49 UTC (permalink / raw)
To: 'Eric Dumazet', David Miller; +Cc: netdev, Slava Shwartsman
In-Reply-To: <1485476480.5145.194.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet
> Sent: 27 January 2017 00:21
> Slava Shwartsman reported a warning in skb_try_coalesce(), when we
> detect skb->truesize is completely wrong.
>
> In his case, issue came from IPv6 reassembly coping with malicious
> datagrams, that forced various pskb_may_pull() to reallocate a bigger
> skb->head than the one allocated by NIC driver before entering GRO
> layer.
>
> Current code does not change skb->truesize, leaving this burden to
> callers if they care enough.
>
> Blindly changing skb->truesize in pskb_expand_head() is not
> easy, as some producers might track skb->truesize, for example
> in xmit path for back pressure feedback (sk->sk_wmem_alloc)
>
> We can detect the cases where it should be safe to change
> skb->truesize :
>
> 1) skb is not attached to a socket.
> 2) If it is attached to a socket, destructor is sock_edemux()
...
> int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
> gfp_t gfp_mask)
> {
> + int i, osize = skb_end_offset(skb);
> + int size = osize + nhead + ntail;
> long off;
> + u8 *data;
>
> BUG_ON(nhead < 0);
>
> @@ -1257,6 +1257,14 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
> skb->hdr_len = 0;
> skb->nohdr = 0;
> atomic_set(&skb_shinfo(skb)->dataref, 1);
> +
> + /* It is not generally safe to change skb->truesize.
> + * For the moment, we really care of rx path, or
> + * when skb is orphaned (not attached to a socket)
> + */
> + if (!skb->sk || skb->destructor == sock_edemux)
> + skb->truesize += size - osize;
That calculation doesn't look right to me at all.
Isn't 'truesize' supposed to reflect the amount of memory allocated to the skb.
So you need the difference between the size of the new and old memory blocks.
I'm also guessing that extra headroom can be generated by stealing unused tailroom.
David
^ permalink raw reply
* [PATCH net-next 2/2] ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W
From: Simon Horman @ 2017-01-27 11:04 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Geert Uytterhoeven,
Simon Horman
In-Reply-To: <1485515090-7570-1-git-send-email-horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
The limitation to 10/100Mbit speeds on R-Car Gen3 is valid for R-Car H3
ES1.0 only. Check for the exact SoC model to allow 1Gbps on newer
revisions of R-Car H3, and on R-Car M3-W.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
drivers/net/ethernet/renesas/ravb_main.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 9fb4c04c5885..93cdadeae354 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -31,6 +31,7 @@
#include <linux/pm_runtime.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
+#include <linux/sys_soc.h>
#include <asm/div64.h>
@@ -973,6 +974,11 @@ static void ravb_adjust_link(struct net_device *ndev)
phy_print_status(phydev);
}
+static const struct soc_device_attribute r8a7795es10[] = {
+ { .soc_id = "r8a7795", .revision = "ES1.0", },
+ { /* sentinel */ }
+};
+
/* PHY init function */
static int ravb_phy_init(struct net_device *ndev)
{
@@ -1008,10 +1014,10 @@ static int ravb_phy_init(struct net_device *ndev)
goto err_deregister_fixed_link;
}
- /* This driver only support 10/100Mbit speeds on Gen3
+ /* This driver only support 10/100Mbit speeds on R-Car H3 ES1.0
* at this time.
*/
- if (priv->chip_id == RCAR_GEN3) {
+ if (soc_device_match(r8a7795es10)) {
err = phy_set_max_speed(phydev, SPEED_100);
if (err) {
netdev_err(ndev, "failed to limit PHY to 100Mbit/s\n");
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH net-next 0/2] ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W
From: Simon Horman @ 2017-01-27 11:04 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Simon Horman
Hi,
this series adds support for gigabit communication to the Renesas EthernetAVB
controller when used in conjunction with R-Car Gen3 H3 ES1.1+ and M3-W SoCs.
Gigabit is already supported with R-Car Gen 2 SoCs.
The patch from Geert was previously posted for inclusion in v4.10 and
acked by Dave for that purpose. It was, however, not accepted by the
ARM SoC maintainers.
The path from Mizuguchi-san is to address timing problems observed with
gigabit transfers. I would like it considered although my own testing on
M3-W did not show any timing problems.
Geert Uytterhoeven (1):
ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W
Kazuya Mizuguchi (1):
ravb: Add tx and rx clock internal delays mode of APSR
drivers/net/ethernet/renesas/ravb.h | 10 ++++++++
drivers/net/ethernet/renesas/ravb_main.c | 39 ++++++++++++++++++++++++++++++--
2 files changed, 47 insertions(+), 2 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH net-next 1/2] ravb: Add tx and rx clock internal delays mode of APSR
From: Simon Horman @ 2017-01-27 11:04 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Kazuya Mizuguchi,
Simon Horman
In-Reply-To: <1485515090-7570-1-git-send-email-horms+renesas@verge.net.au>
From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
This patch enables tx and rx clock internal delay modes (TDM and RDM).
This is to address a failure in the case of 1Gbps communication using the
by salvator-x board with the KSZ9031RNX phy. This has been reported to
occur with both the r8a7795 (H3) and r8a7796 (M3-W) SoCs.
With this change APSR internal delay modes are enabled for
"rgmii-id", "rgmii-rxid" and "rgmii-txid" phy modes as follows:
phy mode | ASPR delay mode
-----------+----------------
rgmii-id | TDM and RDM
rgmii-rxid | RDM
rgmii-txid | TDM
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v1 [Simon Horman]
- Combined patches
- Reworded changelog
v0 [Kazuya Mizuguchi]
---
drivers/net/ethernet/renesas/ravb.h | 10 ++++++++++
drivers/net/ethernet/renesas/ravb_main.c | 29 +++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
index f1109661a533..d7c91d48cc48 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -76,6 +76,7 @@ enum ravb_reg {
CDAR20 = 0x0060,
CDAR21 = 0x0064,
ESR = 0x0088,
+ APSR = 0x008C, /* R-Car Gen3 only */
RCR = 0x0090,
RQC0 = 0x0094,
RQC1 = 0x0098,
@@ -248,6 +249,15 @@ enum ESR_BIT {
ESR_EIL = 0x00001000,
};
+/* APSR */
+enum APSR_BIT {
+ APSR_MEMS = 0x00000002,
+ APSR_CMSW = 0x00000010,
+ APSR_DM = 0x00006000,
+ APSR_DM_RDM = 0x00002000,
+ APSR_DM_TDM = 0x00004000,
+};
+
/* RCR */
enum RCR_BIT {
RCR_EFFS = 0x00000001,
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 89ac1e3f6175..9fb4c04c5885 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1904,6 +1904,29 @@ static void ravb_set_config_mode(struct net_device *ndev)
}
}
+static void ravb_set_delay_mode(struct net_device *ndev)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+
+ if (priv->chip_id != RCAR_GEN2) {
+ switch (priv->phy_interface) {
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ ravb_modify(ndev, APSR, APSR_DM, APSR_DM_RDM |
+ APSR_DM_TDM);
+ break;
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ ravb_modify(ndev, APSR, APSR_DM, APSR_DM_RDM);
+ break;
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ ravb_modify(ndev, APSR, APSR_DM, APSR_DM_TDM);
+ break;
+ default:
+ ravb_modify(ndev, APSR, APSR_DM, 0);
+ break;
+ }
+ }
+}
+
static int ravb_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -2016,6 +2039,9 @@ static int ravb_probe(struct platform_device *pdev)
/* Request GTI loading */
ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
+ /* Set APSR */
+ ravb_set_delay_mode(ndev);
+
/* Allocate descriptor base address table */
priv->desc_bat_size = sizeof(struct ravb_desc) * DBAT_ENTRY_NUM;
priv->desc_bat = dma_alloc_coherent(ndev->dev.parent, priv->desc_bat_size,
@@ -2152,6 +2178,9 @@ static int __maybe_unused ravb_resume(struct device *dev)
/* Request GTI loading */
ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
+ /* Set APSR */
+ ravb_set_delay_mode(ndev);
+
/* Restore descriptor base address table */
ravb_write(ndev, priv->desc_bat_dma, DBAT);
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* RE: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
From: Rafal Ozieblo @ 2017-01-27 11:06 UTC (permalink / raw)
To: Nicolas Ferre, Harini Katakam
Cc: tbultel@pixelsurmer.com, boris.brezillon@free-electrons.com,
netdev@vger.kernel.org, alexandre.belloni@free-electrons.com,
linux-kernel@vger.kernel.org, richardcochran@gmail.com,
Andrei Pistirica, michals@xilinx.com, anirudh@xilinx.com,
punnaia@xilinx.com, harini.katakam@xilinx.com,
davem@davemloft.net, linux-arm-kernel@lists.infradead.org
In-Reply-To: <779c1540-f4da-90ee-1fa1-c94339a892aa@atmel.com>
>-----Original Message-----
>From: Nicolas Ferre [mailto:nicolas.ferre@atmel.com]
>Sent: 27 stycznia 2017 11:28
>Subject: Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
>
>Le 27/01/2017 à 11:26, Rafal Ozieblo a écrit :
>>> -----Original Message-----
>>> From: Harini Katakam [mailto:harinikatakamlinux@gmail.com]
>>> Sent: 27 stycznia 2017 06:43
>>> Subject: Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
>>>
>>> Hi Rafal,
>>>
>>> On Thu, Jan 26, 2017 at 8:45 PM, Rafal Ozieblo <rafalo@cadence.com> wrote:
>>>>> -----Original Message-----
>>>>> From: Andrei Pistirica [mailto:andrei.pistirica@microchip.com]
>>>>> Sent: 19 stycznia 2017 16:56
>>>>> Subject: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
>>>>>
>>>>>
>>>>> +static inline bool gem_has_ptp(struct macb *bp)
>>>>> +{
>>>>> + return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP);
>>>>> +}
>>>> Why don't you use hardware capabilities here? Would it be better to read it from hardware instead adding it to many configuration?
>>>
>>> If you are referring to TSU bit in DCFG5, then we will be relying on
>>> Cadence IP's information irrespective of the SoC capability
>>> and whether the PTP support was adequate.
>>> I think the capability approach gives better control and
>>> it is not really much to add.
>>>
>>> Regards,
>>> Harini
>>>
>> Yes, I'm referring to TSU bit.
>> What if SoC contains multiple Cadence GEMs, some with PTP support and others without?
>
>Simply define different DT compatibility strings and we're good.
What with GEM on PCI ? There is no DT.
>> Relevant will be checking both, hardware capabilities and SoC capabilities from "caps" field.
>>
>
>
>--
>Nicolas Ferre
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [iproute PATCH] man: tc-csum.8: Fix example
From: Phil Sutter @ 2017-01-27 11:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
This fixes two issues with the provided example:
- Add missing 'dev' keyword to second command.
- Use a real IPv4 address instead of a bogus hex value since that will
be rejected by get_addr_ipv4().
Fixes: dbfb17a67f9c7 ("man: tc-csum.8: Add an example")
Reported-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
man/man8/tc-csum.8 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/man/man8/tc-csum.8 b/man/man8/tc-csum.8
index 3a64c82f09ba8..43561d9f90a8e 100644
--- a/man/man8/tc-csum.8
+++ b/man/man8/tc-csum.8
@@ -57,9 +57,9 @@ packets, both IP and UDP checksums have to be recalculated:
.RS
.EX
# tc qdisc add dev eth0 ingress handle ffff:
-# tc filter add eth0 prio 1 protocol ip parent ffff: \\
+# tc filter add dev eth0 prio 1 protocol ip parent ffff: \\
u32 match ip src 192.168.1.100/32 flowid :1 \\
- action pedit munge ip dst set 0x12345678 pipe \\
+ action pedit munge ip dst set 1.2.3.4 pipe \\
csum ip and udp
.EE
.RE
--
2.11.0
^ permalink raw reply related
* [PATCH] Net: ethernet: mediatek - Fix possible NULL derefrence.
From: Shailendra Verma @ 2017-01-27 11:19 UTC (permalink / raw)
To: Felix Fietkau, John Crispin, Matthias Brugger, netdev,
linux-arm-kernel, linux-mediatek, linux-kernel, p.shailesh,
ashish.kalra, Shailendra Verma, Shailendra Verma
In-Reply-To: <CGME20170127111947epcas2p14f5ea86f0069142be02339754fda4a55@epcas2p1.samsung.com>
of_match_device could return NULL, and so can cause a NULL
pointer dereference later.
Signed-off-by: Shailendra Verma <shailendra.v@samsung.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 4a62ffd..4495b7b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2369,6 +2369,10 @@ static int mtk_probe(struct platform_device *pdev)
int i;
match = of_match_device(of_mtk_match, &pdev->dev);
+ if (!match) {
+ dev_err(&pdev->dev, "Error: No device match found\n");
+ return -ENODEV;
+ }
soc = (struct mtk_soc_data *)match->data;
eth = devm_kzalloc(&pdev->dev, sizeof(*eth), GFP_KERNEL);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next 2/3] sfc: refactor debug-or-warnings printks
From: Edward Cree @ 2017-01-27 11:34 UTC (permalink / raw)
To: David Miller; +Cc: linux-net-drivers, netdev
In-Reply-To: <20170126.143629.337763461510725581.davem@davemloft.net>
On 26/01/17 19:36, David Miller wrote:
> From: Edward Cree <ecree@solarflare.com>
> Date: Thu, 26 Jan 2017 17:53:48 +0000
>
>> diff --git a/drivers/net/ethernet/sfc/net_driver.h b/drivers/net/ethernet/sfc/net_driver.h
>> index 5927c20..c640955 100644
>> --- a/drivers/net/ethernet/sfc/net_driver.h
>> +++ b/drivers/net/ethernet/sfc/net_driver.h
>> @@ -51,6 +51,15 @@
>> #define EFX_WARN_ON_PARANOID(x) do {} while (0)
>> #endif
>>
>> +/* if @cond then downgrade to debug, else print at @level */
>> +#define netif_cond_dbg(priv, type, netdev, cond, level, fmt, args...) \
>> + do { \
>> + if (cond) \
>> + netif_dbg(priv, type, netdev, fmt, ##args); \
>> + else \
>> + netif_ ## level(priv, type, netdev, fmt, ##args); \
>> + } while (0)
>> +
>> /**************************************************************************
>> *
>> * Efx data structures
>>
> Please do not define locally in a driver an interface that looks like a generic
> one and might be useful to code outside of your driver.
>
> Thanks.
Sure. I'll put this in netdevice.h and respin.
-Ed
^ permalink raw reply
* Re: [PATCH iproute2 1/1] tc: distinguish Add/Replace action operations.
From: Phil Sutter @ 2017-01-27 11:37 UTC (permalink / raw)
To: Roman Mashak; +Cc: stephen, netdev, Jamal Hadi Salim
In-Reply-To: <1485093333-18317-1-git-send-email-mrv@mojatatu.com>
On Sun, Jan 22, 2017 at 08:55:33AM -0500, Roman Mashak wrote:
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Phil Sutter <phil@nwl.cc>
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-27 11:49 UTC (permalink / raw)
To: Pali Rohár
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127103408.GG24223@pali>
Pali Rohár <pali.rohar@gmail.com> writes:
>> So
>> for those other platforms there will be a delay waiting for user-mode
>> helper to fail, before trying to get nvs file from /lib/firmware.
>
> Yes, there will be. But there is no easy way to fix this problem that
> kernel is trying to use default/example NVS data...
Kernel is doing correctly and requesting NVS data as expected, the
problem here is that linux-firmware claims that the example NVS data is
real calibration data (which it is not). Distros should not use that,
only developers for testing purposes. We should not courage users using
example calibration data.
The simple fix is to rename the NVS file in linux-firmware to something
like wl1251-nvs.bin.example, no need to workaround this in kernel. If
you send a patch to linux-firmware I'm happy to ack that.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 11:57 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <87bmus7mfk.fsf@kamboji.qca.qualcomm.com>
On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> >> So
> >> for those other platforms there will be a delay waiting for user-mode
> >> helper to fail, before trying to get nvs file from /lib/firmware.
> >
> > Yes, there will be. But there is no easy way to fix this problem that
> > kernel is trying to use default/example NVS data...
>
> Kernel is doing correctly and requesting NVS data as expected, the
> problem here is that linux-firmware claims that the example NVS data is
> real calibration data (which it is not). Distros should not use that,
> only developers for testing purposes. We should not courage users using
> example calibration data.
>
> The simple fix is to rename the NVS file in linux-firmware to something
> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
> you send a patch to linux-firmware I'm happy to ack that.
I agree with rename and fact that default/example data should not be
used.
But...
1) Kernel should not read device/model specific data from VFS where
are stored not-device-specific files preinstalled by linux
distributions.
And linux distributions are already putting files into VFS and kernel
cannot enforce userspace to not do that (as they are already doing it).
2) It was already tested that example NVS data can be used for N900 e.g.
for SSH connection. If real correct data are not available it is better
to use at least those example (and probably log warning message) so user
can connect via SSH and start investigating where is problem.
3) If we do rename *now* we will totally break wifi support on Nokia
N900.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pavel Machek @ 2017-01-27 12:03 UTC (permalink / raw)
To: Pali Rohár
Cc: Arend Van Spriel, Kalle Valo, Ming Lei, Luis R. Rodriguez,
Greg Kroah-Hartman, David Gnedt, Michal Kazior, Daniel Wagner,
Tony Lindgren, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127101043.GD24223@pali>
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
Hi!
> > You are probably saying that on your platform you can not remove
> > anything from /lib/firmware, right? I don't see how you come from "it is
> > part of firmware package" to "removing is not possible". Trying to
> > understand this and it makes no sense.
>
> It is already in linux distribution packages. If I remove that file from
> file system it will be placed there again by package management or it it
> will throw error message about system integrity (missing file, etc...).
>
> Also that file is already in linux-firmware git and so is propagated to
> /lib/firmware by anybody who is using linux-firmware.
>
> > >> Like we discussed earlier, the default nvs file should not be used by
> > >> normal users.
> > >
> > > But already is and we need to deal with this fact.
> >
> > Why?
>
> Because everybody has already installed it.
>
> > Are there other platforms that use the default nvs file and have a
> > working wifi.
>
> I do not know.
>
> > So your "removing is not possible" would be about
> > regression for those?
>
> Yes, that is possible.
>
> Also you can use wifi on Nokia N900 with this default file. Yes it is
> not recommended and probably has performance problems... but more people
> use it for SSH and it is working. Pavel could confirm this.
Yes, wifi somehow works on N900. .. depending on userspace and kernel
versions.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 0/2] ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W
From: Geert Uytterhoeven @ 2017-01-27 12:16 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, Sergei Shtylyov, Magnus Damm,
netdev@vger.kernel.org, Linux-Renesas
In-Reply-To: <1485515090-7570-1-git-send-email-horms+renesas@verge.net.au>
Hi Simon,
On Fri, Jan 27, 2017 at 12:04 PM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> The path from Mizuguchi-san is to address timing problems observed with
> gigabit transfers. I would like it considered although my own testing on
> M3-W did not show any timing problems.
Is there any relation with the *-skew-ps properties in the DTS in the BSP?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 net] net: free ip_vs_dest structs when refcnt=0
From: Pablo Neira Ayuso @ 2017-01-27 12:21 UTC (permalink / raw)
To: Simon Horman
Cc: Julian Anastasov, David Windsor, netdev, kernel-hardening,
netfilter-devel, lvs-devel, wensong, keescook, elena.reshetova,
ishkamiel
In-Reply-To: <20170127080738.GD21195@verge.net.au>
On Fri, Jan 27, 2017 at 09:07:38AM +0100, Simon Horman wrote:
> On Thu, Jan 26, 2017 at 10:49:10PM +0200, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Mon, 23 Jan 2017, David Windsor wrote:
> >
> > > Currently, the ip_vs_dest cache frees ip_vs_dest objects when their
> > > reference count becomes < 0. Aside from not being semantically sound,
> > > this is problematic for the new type refcount_t, which will be introduced
> > > shortly in a separate patch. refcount_t is the new kernel type for
> > > holding reference counts, and provides overflow protection and a
> > > constrained interface relative to atomic_t (the type currently being
> > > used for kernel reference counts).
> > >
> > > Per Julian Anastasov: "The problem is that dest_trash currently holds
> > > deleted dests (unlinked from RCU lists) with refcnt=0." Changing
> > > dest_trash to hold dest with refcnt=1 will allow us to free ip_vs_dest
> > > structs when their refcnt=0, in ip_vs_dest_put_and_free().
> > >
> > > Signed-off-by: David Windsor <dwindsor@gmail.com>
> >
> > Thanks! I tested the first version and this one
> > just adds the needed changes in comments, so
> >
> > Signed-off-by: Julian Anastasov <ja@ssi.bg>
> >
> > Simon and Pablo, this is more appropriate for
> > ipvs-next/nf-next. Please apply!
>
> Pablo, would you mind taking this one directly into nf-next?
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
Sure, no problem. I'll take it. Thanks!
^ permalink raw reply
* Re: [BUG/RFC] vhost: net: big endian viring access despite virtio 1
From: Halil Pasic @ 2017-01-27 12:24 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, netdev, Greg Kurz, virtualization@lists.linux-foundation.org
In-Reply-To: <20170126211511-mutt-send-email-mst@kernel.org>
On 01/26/2017 08:20 PM, Michael S. Tsirkin wrote:
> On Thu, Jan 26, 2017 at 06:39:14PM +0100, Halil Pasic wrote:
>>
>> Hi!
>>
>> Recently I have been investigating some strange migration problems on
>> s390x.
>>
>> It turned out under certain circumstances vhost_net corrupts avail.idx by
>> using wrong endianness.
[..]
>> -------------------------8<--------------
>> >From b26e2bbdc03832a0204ee2b42967a1b49a277dc8 Mon Sep 17 00:00:00 2001
>> From: Halil Pasic <pasic@linux.vnet.ibm.com>
>> Date: Thu, 26 Jan 2017 00:06:15 +0100
>> Subject: [PATCH] vhost: remove useless/dangerous reset of is_le
>>
>> The reset of is_le does no good, but it contributes its fair share to a
>> bug in vhost_net, which occurs if we have some oldubufs when stopping and
>> setting a fd = -1 as a backend. Instead of doing something convoluted in
>> vhost_net, let's just get rid of the reset.
>>
>> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
>> Fixes: commit 2751c9882b94
>> ---
>> drivers/vhost/vhost.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>> index d643260..08072a2 100644
>> --- a/drivers/vhost/vhost.c
>> +++ b/drivers/vhost/vhost.c
>> @@ -1714,10 +1714,8 @@ int vhost_vq_init_access(struct vhost_virtqueue *vq)
>> int r;
>> bool is_le = vq->is_le;
>>
>> - if (!vq->private_data) {
>> - vhost_reset_is_le(vq);
>> + if (!vq->private_data)
>> return 0;
>> - }
>>
>> vhost_init_is_le(vq);
>
>
> I think you do need to reset it, just maybe within vhost_init_is_le.
>
> if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
> vq->is_le = true;
> else
> vhost_reset_is_le(vq);
>
>
That is a very good point! I have overlooked that while the
CONFIG_VHOST_CROSS_ENDIAN_LEGACY variant
static void vhost_init_is_le(struct vhost_virtqueue *vq)
{
/* Note for legacy virtio: user_be is initialized at reset time
* according to the host endianness. If userspace does not set an
* explicit endianness, the default behavior is native endian, as
* expected by legacy virtio.
*/
vq->is_le = vhost_has_feature(vq, VIRTIO_F_VERSION_1) || !vq->user_be;
}
is fine the other variant
static void vhost_init_is_le(struct vhost_virtqueue *vq)
{
if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
vq->is_le = true;
}
is a very strange initializer (makes assumptions about the state
to be initialized).
I agree, setting native endianness there sounds very reasonable.
I have a question regarding readability. IMHO the relationship
of reset_is_le and int_is_le is a bit confusing, and I'm afraid
it could become even more confusing with using reset in one of
the init_is_le's.
How about we do the following?
static void vhost_init_is_le(struct vhost_virtqueue *vq)
{
if (vhost_has_feature(vq, VIRTIO_F_VERSION_1))
vq->is_le = true;
+ else
+ vq->is_le = virtio_legacy_is_little_endian();
}
static void vhost_reset_is_le(struct vhost_virtqueue *vq)
{
- vq->is_le = virtio_legacy_is_little_endian();
+ vhost_init_is_le(vq);
}
That way we would have correct endianness both after reset
and after init, I think :).
Thank you very much!
Halil
^ permalink raw reply
* [PATCH] stmmac: Discard masked flags in interrupt status register
From: Alexey Brodkin @ 2017-01-27 12:24 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, Alexey Brodkin, Giuseppe Cavallaro, Fabrice Gasnier,
Joachim Eastwood, Phil Reid, David Miller, Alexandre Torgue,
Vineet Gupta
DW GMAC databook says the following about bits in "Register 15 (Interrupt
Mask Register)":
--------------------------->8-------------------------
When set, this bit __disables_the_assertion_of_the_interrupt_signal__
because of the setting of XXX bit in Register 14 (Interrupt
Status Register).
--------------------------->8-------------------------
In fact even if we mask one bit in the mask register it doesn't prevent
corresponding bit to appear in the status register, it only disables
interrupt generation for corresponding event.
But currently we expect a bit different behavior: status bits to be in
sync with their masks, i.e. if mask for bit A is set in the mask
register then bit A won't appear in the interrupt status register.
This was proven to be incorrect assumption, see discussion here [1].
That misunderstanding causes unexpected behaviour of the GMAC, for
example we were happy enough to just see bogus messages about link
state changes.
So from now on we'll be only checking bits that really may trigger an
interrupt.
[1] https://lkml.org/lkml/2016/11/3/413
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Joachim Eastwood <manabian@gmail.com>
Cc: Phil Reid <preid@electromag.com.au>
Cc: David Miller <davem@davemloft.net>
Cc: Alexandre Torgue <alexandre.torgue@gmail.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index be3c91c7f211..5484fd726d5a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -305,8 +305,12 @@ static int dwmac1000_irq_status(struct mac_device_info *hw,
{
void __iomem *ioaddr = hw->pcsr;
u32 intr_status = readl(ioaddr + GMAC_INT_STATUS);
+ u32 intr_mask = readl(ioaddr + GMAC_INT_MASK);
int ret = 0;
+ /* Discard masked bits */
+ intr_status &= ~intr_mask;
+
/* Not used events (e.g. MMC interrupts) are not handled. */
if ((intr_status & GMAC_INT_STATUS_MMCTIS))
x->mmc_tx_irq_n++;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-27 12:26 UTC (permalink / raw)
To: Pali Rohár
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170127115706.GH24223@pali>
Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
>> Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>> >> So
>> >> for those other platforms there will be a delay waiting for user-mode
>> >> helper to fail, before trying to get nvs file from /lib/firmware.
>> >
>> > Yes, there will be. But there is no easy way to fix this problem that
>> > kernel is trying to use default/example NVS data...
>>
>> Kernel is doing correctly and requesting NVS data as expected, the
>> problem here is that linux-firmware claims that the example NVS data is
>> real calibration data (which it is not). Distros should not use that,
>> only developers for testing purposes. We should not courage users using
>> example calibration data.
>>
>> The simple fix is to rename the NVS file in linux-firmware to something
>> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
>> you send a patch to linux-firmware I'm happy to ack that.
>
> I agree with rename and fact that default/example data should not be
> used.
>
> But...
>
> 1) Kernel should not read device/model specific data from VFS where
> are stored not-device-specific files preinstalled by linux
> distributions.
>
> And linux distributions are already putting files into VFS and kernel
> cannot enforce userspace to not do that (as they are already doing it).
I'm having problems to understand what you are saying here.
> 2) It was already tested that example NVS data can be used for N900 e.g.
> for SSH connection. If real correct data are not available it is better
> to use at least those example (and probably log warning message) so user
> can connect via SSH and start investigating where is problem.
I disagree. Allowing default calibration data to be used can be
unnoticed by user and left her wondering why wifi works so badly.
> 3) If we do rename *now* we will totally break wifi support on Nokia
> N900.
Then the distro should fix that when updating the linux-firmware
packages. Can you provide details about the setup, what distro etc?
--
Kalle Valo
^ permalink raw reply
* [PATCH] [net] ISDN: eicon: silence misleading array-bounds warning
From: Arnd Bergmann @ 2017-01-27 12:32 UTC (permalink / raw)
To: Armin Schindler, Karsten Keil
Cc: Nicholas Mc Guire, kernel-build-reports, Arnd Bergmann, stable,
David S. Miller, netdev, linux-kernel
With some gcc versions, we get a warning about the eicon driver,
and that currently shows up as the only remaining warning in one
of the build bots:
In file included from ../drivers/isdn/hardware/eicon/message.c:30:0:
eicon/message.c: In function 'mixer_notify_update':
eicon/platform.h:333:18: warning: array subscript is above array bounds [-Warray-bounds]
The code is easily changed to open-code the unusual PUT_WORD() line
causing this to avoid the warning.
Cc: stable@vger.kernel.org
Link: http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.45/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/isdn/hardware/eicon/message.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/eicon/message.c b/drivers/isdn/hardware/eicon/message.c
index 1a1d99704fe6..296f1411fe84 100644
--- a/drivers/isdn/hardware/eicon/message.c
+++ b/drivers/isdn/hardware/eicon/message.c
@@ -11297,7 +11297,8 @@ static void mixer_notify_update(PLCI *plci, byte others)
((CAPI_MSG *) msg)->header.ncci = 0;
((CAPI_MSG *) msg)->info.facility_req.Selector = SELECTOR_LINE_INTERCONNECT;
((CAPI_MSG *) msg)->info.facility_req.structs[0] = 3;
- PUT_WORD(&(((CAPI_MSG *) msg)->info.facility_req.structs[1]), LI_REQ_SILENT_UPDATE);
+ ((CAPI_MSG *) msg)->info.facility_req.structs[1] = LI_REQ_SILENT_UPDATE & 0xff;
+ ((CAPI_MSG *) msg)->info.facility_req.structs[2] = LI_REQ_SILENT_UPDATE >> 8;
((CAPI_MSG *) msg)->info.facility_req.structs[3] = 0;
w = api_put(notify_plci->appl, (CAPI_MSG *) msg);
if (w != _QUEUE_FULL)
--
2.9.0
^ permalink raw reply related
* Re: [iproute PATCH] man: tc-csum.8: Fix example
From: Jiri Pirko @ 2017-01-27 12:26 UTC (permalink / raw)
To: Phil Sutter; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20170127111501.21439-1-phil@nwl.cc>
Fri, Jan 27, 2017 at 12:15:01PM CET, phil@nwl.cc wrote:
>This fixes two issues with the provided example:
>
>- Add missing 'dev' keyword to second command.
>- Use a real IPv4 address instead of a bogus hex value since that will
> be rejected by get_addr_ipv4().
>
>Fixes: dbfb17a67f9c7 ("man: tc-csum.8: Add an example")
>Reported-by: Davide Caratti <dcaratti@redhat.com>
>Signed-off-by: Phil Sutter <phil@nwl.cc>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net] be2net: fix initial MAC setting
From: Sriharsha Basavapatna @ 2017-01-27 12:38 UTC (permalink / raw)
To: Ivan Vecera
Cc: netdev, Sathya Perla, Ajit Khaparde, Somnath Kotur,
Sriharsha Basavapatna
In-Reply-To: <20170126102801.18914-1-cera@cera.cz>
Hi Ivan,
This patch is a bit involved. We need some time to review and test
this to make sure it works with other (non-BE3/VF - Skyhawk, Lancer)
devices. Also, IIRC we shouldn't see this issue with the latest FW.
Thanks,
-Harsha
On Thu, Jan 26, 2017 at 3:58 PM, Ivan Vecera <cera@cera.cz> wrote:
> Recent commit 34393529163a ("be2net: fix MAC addr setting on privileged
> BE3 VFs") allows privileged BE3 VFs to set its MAC address during
> initialization. Although the initial MAC for such VFs is already
> programmed by parent PF the subsequent setting performed by VF is OK,
> but in certain cases (after fresh boot) this command in VF can fail.
>
> The MAC should be initialized only when:
> 1) no MAC is programmed (always except BE3 VFs during first init)
> 2) programmed MAC is different from requested (e.g. MAC is set when
> interface is down). In this case the initial MAC programmed by PF
> needs to be deleted.
>
> The adapter->dev_mac contains MAC address currently programmed in HW so
> it should be zeroed when the MAC is deleted from HW and should not be
> filled when MAC is set when interface is down in be_mac_addr_set() as
> no programming is performed in this case.
>
> Example of failure without the fix (immediately after fresh boot):
>
> # ip link set eth0 up <- eth0 is BE3 PF
> be2net 0000:01:00.0 eth0: Link is Up
>
> # echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create 1 VF
> ...
> be2net 0000:01:04.0: Emulex OneConnect(be3): VF port 0
>
> # ip link set eth8 up <- eth8 is created privileged VF
> be2net 0000:01:04.0: opcode 59-1 failed:status 1-76
> RTNETLINK answers: Input/output error
>
> # echo 0 > /sys/class/net/eth0/device/sriov_numvfs <- Delete VF
> iommu: Removing device 0000:01:04.0 from group 33
> ...
>
> # echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create it again
> iommu: Removing device 0000:01:04.0 from group 33
> ...
>
> # ip link set eth8 up
> be2net 0000:01:04.0 eth8: Link is Up
>
> Initialization is now OK.
>
> Fixes: 34393529163a ("be2net: fix MAC addr setting on privileged BE3 VFs")
> Cc: Sathya Perla <sathya.perla@broadcom.com>
> Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
> Cc: Somnath Kotur <somnath.kotur@broadcom.com>
> Signed-off-by: Ivan Vecera <cera@cera.cz>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 31 ++++++++++++++++++++++++-----
> 1 file changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 1a7f8ad7b9c6..cf13b99b8551 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -362,8 +362,10 @@ static int be_mac_addr_set(struct net_device *netdev, void *p)
> status = -EPERM;
> goto err;
> }
> -done:
> +
> + /* Remember currently programmed MAC */
> ether_addr_copy(adapter->dev_mac, addr->sa_data);
> +done:
> ether_addr_copy(netdev->dev_addr, addr->sa_data);
> dev_info(dev, "MAC address changed to %pM\n", addr->sa_data);
> return 0;
> @@ -3618,8 +3620,10 @@ static void be_disable_if_filters(struct be_adapter *adapter)
> {
> /* Don't delete MAC on BE3 VFs without FILTMGMT privilege */
> if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
> - check_privilege(adapter, BE_PRIV_FILTMGMT))
> + check_privilege(adapter, BE_PRIV_FILTMGMT)) {
> be_dev_mac_del(adapter, adapter->pmac_id[0]);
> + eth_zero_addr(adapter->dev_mac);
> + }
>
> be_clear_uc_list(adapter);
> be_clear_mc_list(adapter);
> @@ -3773,12 +3777,25 @@ static int be_enable_if_filters(struct be_adapter *adapter)
> if (status)
> return status;
>
> - /* Don't add MAC on BE3 VFs without FILTMGMT privilege */
> - if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
> - check_privilege(adapter, BE_PRIV_FILTMGMT)) {
> + /* Normally this condition usually true as the ->dev_mac is zeroed.
> + * But on BE3 VFs the initial MAC is pre-programmed by PF and
> + * subsequent be_dev_mac_add() can fail (after fresh boot)
> + */
> + if (!ether_addr_equal(adapter->dev_mac, adapter->netdev->dev_addr)) {
> + int old_pmac_id = -1;
> +
> + /* Remember old programmed MAC if any - can happen on BE3 VF */
> + if (!is_zero_ether_addr(adapter->dev_mac))
> + old_pmac_id = adapter->pmac_id[0];
> +
> status = be_dev_mac_add(adapter, adapter->netdev->dev_addr);
> if (status)
> return status;
> +
> + /* Delete old programmed MAC if necessary */
> + if (old_pmac_id > 0 && old_pmac_id != adapter->pmac_id[0])
> + be_dev_mac_del(adapter, old_pmac_id);
> +
> ether_addr_copy(adapter->dev_mac, adapter->netdev->dev_addr);
> }
>
> @@ -4552,6 +4569,10 @@ static int be_mac_setup(struct be_adapter *adapter)
>
> memcpy(adapter->netdev->dev_addr, mac, ETH_ALEN);
> memcpy(adapter->netdev->perm_addr, mac, ETH_ALEN);
> +
> + /* Initial MAC for BE3 VFs is already programmed by PF */
> + if (BEx_chip(adapter) && be_virtfn(adapter))
> + memcpy(adapter->dev_mac, mac, ETH_ALEN);
> }
>
> return 0;
> --
> 2.10.2
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] ravb: Add tx and rx clock internal delays mode of APSR
From: Sergei Shtylyov @ 2017-01-27 12:42 UTC (permalink / raw)
To: Simon Horman, David Miller
Cc: Magnus Damm, netdev, linux-renesas-soc, Kazuya Mizuguchi
In-Reply-To: <1485515090-7570-2-git-send-email-horms+renesas@verge.net.au>
Hello!
On 01/27/2017 02:04 PM, Simon Horman wrote:
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> This patch enables tx and rx clock internal delay modes (TDM and RDM).
>
> This is to address a failure in the case of 1Gbps communication using the
> by salvator-x board with the KSZ9031RNX phy. This has been reported to
> occur with both the r8a7795 (H3) and r8a7796 (M3-W) SoCs.
>
> With this change APSR internal delay modes are enabled for
> "rgmii-id", "rgmii-rxid" and "rgmii-txid" phy modes as follows:
>
> phy mode | ASPR delay mode
> -----------+----------------
> rgmii-id | TDM and RDM
> rgmii-rxid | RDM
> rgmii-txid | TDM
>
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> ---
> v1 [Simon Horman]
> - Combined patches
> - Reworded changelog
>
> v0 [Kazuya Mizuguchi]
> ---
> drivers/net/ethernet/renesas/ravb.h | 10 ++++++++++
> drivers/net/ethernet/renesas/ravb_main.c | 29 +++++++++++++++++++++++++++++
> 2 files changed, 39 insertions(+)
>
> diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
> index f1109661a533..d7c91d48cc48 100644
> --- a/drivers/net/ethernet/renesas/ravb.h
> +++ b/drivers/net/ethernet/renesas/ravb.h
[...]
> @@ -248,6 +249,15 @@ enum ESR_BIT {
> ESR_EIL = 0x00001000,
> };
>
> +/* APSR */
> +enum APSR_BIT {
> + APSR_MEMS = 0x00000002,
Not documented in the revision 0.5 of the gen3 manual...
> + APSR_CMSW = 0x00000010,
> + APSR_DM = 0x00006000,
... and neither this field. Are these documented in the latter revs?
> + APSR_DM_RDM = 0x00002000,
> + APSR_DM_TDM = 0x00004000,
> +};
> +
> /* RCR */
> enum RCR_BIT {
> RCR_EFFS = 0x00000001,
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index 89ac1e3f6175..9fb4c04c5885 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1904,6 +1904,29 @@ static void ravb_set_config_mode(struct net_device *ndev)
> }
> }
>
> +static void ravb_set_delay_mode(struct net_device *ndev)
> +{
> + struct ravb_private *priv = netdev_priv(ndev);
> +
> + if (priv->chip_id != RCAR_GEN2) {
> + switch (priv->phy_interface) {
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + ravb_modify(ndev, APSR, APSR_DM, APSR_DM_RDM |
> + APSR_DM_TDM);
> + break;
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + ravb_modify(ndev, APSR, APSR_DM, APSR_DM_RDM);
> + break;
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + ravb_modify(ndev, APSR, APSR_DM, APSR_DM_TDM);
> + break;
> + default:
> + ravb_modify(ndev, APSR, APSR_DM, 0);
> + break;
> + }
How about doing ravb_modify() only once?
[...]
MNR, Sergei
^ permalink raw reply
* Re: [PATCH] Net: ethernet: mediatek - Fix possible NULL derefrence.
From: Corentin Labbe @ 2017-01-27 12:44 UTC (permalink / raw)
To: Shailendra Verma
Cc: Felix Fietkau, ashish.kalra-Sze3O3UU22JBDgjK7y7TUQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
p.shailesh-Sze3O3UU22JBDgjK7y7TUQ,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
Shailendra Verma,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, John Crispin
In-Reply-To: <1485515980-3814-1-git-send-email-shailendra.v-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Fri, Jan 27, 2017 at 04:49:40PM +0530, Shailendra Verma wrote:
> of_match_device could return NULL, and so can cause a NULL
> pointer dereference later.
>
> Signed-off-by: Shailendra Verma <shailendra.v-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 4a62ffd..4495b7b 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2369,6 +2369,10 @@ static int mtk_probe(struct platform_device *pdev)
> int i;
>
> match = of_match_device(of_mtk_match, &pdev->dev);
> + if (!match) {
> + dev_err(&pdev->dev, "Error: No device match found\n");
> + return -ENODEV;
> + }
> soc = (struct mtk_soc_data *)match->data;
>
> eth = devm_kzalloc(&pdev->dev, sizeof(*eth), GFP_KERNEL);
> --
Hello
You could use of_device_get_match_data() and simplifiy code
Regards
Corentin Labbe
^ permalink raw reply
* Re: [PATCH net] be2net: fix initial MAC setting
From: Ivan Vecera @ 2017-01-27 12:43 UTC (permalink / raw)
To: Sriharsha Basavapatna; +Cc: netdev, Sathya Perla, Ajit Khaparde, Somnath Kotur
In-Reply-To: <CAHHeUGXitTaXqQk8zDymcCX09vFq3CtM20FHJPL6AeVhc2iBPQ@mail.gmail.com>
2017-01-27 13:38 GMT+01:00 Sriharsha Basavapatna
<sriharsha.basavapatna@broadcom.com>:
> Hi Ivan,
>
> This patch is a bit involved. We need some time to review and test
> this to make sure it works with other (non-BE3/VF - Skyhawk, Lancer)
> devices. Also, IIRC we shouldn't see this issue with the latest FW.
>
I have done tests on BE3 PF & both privileged and non-privileged as well
as on Skyhawk PF and VF. No problems found.
Regarding firmware, I'm using version 11.1.215.0 on my devices and this version
is affected on BE3. Older versions are affected as well.
Ivan
>
> On Thu, Jan 26, 2017 at 3:58 PM, Ivan Vecera <cera@cera.cz> wrote:
>> Recent commit 34393529163a ("be2net: fix MAC addr setting on privileged
>> BE3 VFs") allows privileged BE3 VFs to set its MAC address during
>> initialization. Although the initial MAC for such VFs is already
>> programmed by parent PF the subsequent setting performed by VF is OK,
>> but in certain cases (after fresh boot) this command in VF can fail.
>>
>> The MAC should be initialized only when:
>> 1) no MAC is programmed (always except BE3 VFs during first init)
>> 2) programmed MAC is different from requested (e.g. MAC is set when
>> interface is down). In this case the initial MAC programmed by PF
>> needs to be deleted.
>>
>> The adapter->dev_mac contains MAC address currently programmed in HW so
>> it should be zeroed when the MAC is deleted from HW and should not be
>> filled when MAC is set when interface is down in be_mac_addr_set() as
>> no programming is performed in this case.
>>
>> Example of failure without the fix (immediately after fresh boot):
>>
>> # ip link set eth0 up <- eth0 is BE3 PF
>> be2net 0000:01:00.0 eth0: Link is Up
>>
>> # echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create 1 VF
>> ...
>> be2net 0000:01:04.0: Emulex OneConnect(be3): VF port 0
>>
>> # ip link set eth8 up <- eth8 is created privileged VF
>> be2net 0000:01:04.0: opcode 59-1 failed:status 1-76
>> RTNETLINK answers: Input/output error
>>
>> # echo 0 > /sys/class/net/eth0/device/sriov_numvfs <- Delete VF
>> iommu: Removing device 0000:01:04.0 from group 33
>> ...
>>
>> # echo 1 > /sys/class/net/eth0/device/sriov_numvfs <- Create it again
>> iommu: Removing device 0000:01:04.0 from group 33
>> ...
>>
>> # ip link set eth8 up
>> be2net 0000:01:04.0 eth8: Link is Up
>>
>> Initialization is now OK.
>>
>> Fixes: 34393529163a ("be2net: fix MAC addr setting on privileged BE3 VFs")
>> Cc: Sathya Perla <sathya.perla@broadcom.com>
>> Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
>> Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
>> Cc: Somnath Kotur <somnath.kotur@broadcom.com>
>> Signed-off-by: Ivan Vecera <cera@cera.cz>
>> ---
>> drivers/net/ethernet/emulex/benet/be_main.c | 31 ++++++++++++++++++++++++-----
>> 1 file changed, 26 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
>> index 1a7f8ad7b9c6..cf13b99b8551 100644
>> --- a/drivers/net/ethernet/emulex/benet/be_main.c
>> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
>> @@ -362,8 +362,10 @@ static int be_mac_addr_set(struct net_device *netdev, void *p)
>> status = -EPERM;
>> goto err;
>> }
>> -done:
>> +
>> + /* Remember currently programmed MAC */
>> ether_addr_copy(adapter->dev_mac, addr->sa_data);
>> +done:
>> ether_addr_copy(netdev->dev_addr, addr->sa_data);
>> dev_info(dev, "MAC address changed to %pM\n", addr->sa_data);
>> return 0;
>> @@ -3618,8 +3620,10 @@ static void be_disable_if_filters(struct be_adapter *adapter)
>> {
>> /* Don't delete MAC on BE3 VFs without FILTMGMT privilege */
>> if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
>> - check_privilege(adapter, BE_PRIV_FILTMGMT))
>> + check_privilege(adapter, BE_PRIV_FILTMGMT)) {
>> be_dev_mac_del(adapter, adapter->pmac_id[0]);
>> + eth_zero_addr(adapter->dev_mac);
>> + }
>>
>> be_clear_uc_list(adapter);
>> be_clear_mc_list(adapter);
>> @@ -3773,12 +3777,25 @@ static int be_enable_if_filters(struct be_adapter *adapter)
>> if (status)
>> return status;
>>
>> - /* Don't add MAC on BE3 VFs without FILTMGMT privilege */
>> - if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
>> - check_privilege(adapter, BE_PRIV_FILTMGMT)) {
>> + /* Normally this condition usually true as the ->dev_mac is zeroed.
>> + * But on BE3 VFs the initial MAC is pre-programmed by PF and
>> + * subsequent be_dev_mac_add() can fail (after fresh boot)
>> + */
>> + if (!ether_addr_equal(adapter->dev_mac, adapter->netdev->dev_addr)) {
>> + int old_pmac_id = -1;
>> +
>> + /* Remember old programmed MAC if any - can happen on BE3 VF */
>> + if (!is_zero_ether_addr(adapter->dev_mac))
>> + old_pmac_id = adapter->pmac_id[0];
>> +
>> status = be_dev_mac_add(adapter, adapter->netdev->dev_addr);
>> if (status)
>> return status;
>> +
>> + /* Delete old programmed MAC if necessary */
>> + if (old_pmac_id > 0 && old_pmac_id != adapter->pmac_id[0])
>> + be_dev_mac_del(adapter, old_pmac_id);
>> +
>> ether_addr_copy(adapter->dev_mac, adapter->netdev->dev_addr);
>> }
>>
>> @@ -4552,6 +4569,10 @@ static int be_mac_setup(struct be_adapter *adapter)
>>
>> memcpy(adapter->netdev->dev_addr, mac, ETH_ALEN);
>> memcpy(adapter->netdev->perm_addr, mac, ETH_ALEN);
>> +
>> + /* Initial MAC for BE3 VFs is already programmed by PF */
>> + if (BEx_chip(adapter) && be_virtfn(adapter))
>> + memcpy(adapter->dev_mac, mac, ETH_ALEN);
>> }
>>
>> return 0;
>> --
>> 2.10.2
>>
^ permalink raw reply
* Re: [PATCH] net: phy: broadcom: add support for BCM54210E
From: kbuild test robot @ 2017-01-27 12:50 UTC (permalink / raw)
To: Rafał Miłecki
Cc: kbuild-all, David S . Miller, Florian Fainelli, Xo Wang,
Joel Stanley, Jon Mason, Jaedon Shin, netdev,
Rafał Miłecki
In-Reply-To: <20170127104705.25162-1-zajec5@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]
Hi Rafał,
[auto build test WARNING on net-next/master]
[also build test WARNING on v4.10-rc5 next-20170125]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/net-phy-broadcom-add-support-for-BCM54210E/20170127-190002
config: x86_64-randconfig-s5-01271950 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/linux/phy.h:19:0,
from drivers/net/phy/bcm-phy-lib.h:17,
from drivers/net/phy/broadcom.c:17:
drivers/net/phy/broadcom.c: In function 'bcm54xx_config_init':
drivers/net/phy/broadcom.c:249:32: error: 'PHY_ID_BCM54210E' undeclared (first use in this function)
if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/net/phy/broadcom.c:249:2: note: in expansion of macro 'if'
if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E) {
^~
drivers/net/phy/broadcom.c:249:32: note: each undeclared identifier is reported only once for each function it appears in
if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E) {
^
include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/net/phy/broadcom.c:249:2: note: in expansion of macro 'if'
if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E) {
^~
drivers/net/phy/broadcom.c: At top level:
drivers/net/phy/broadcom.c:565:13: error: 'PHY_ID_BCM54210E' undeclared here (not in a function)
.phy_id = PHY_ID_BCM54210E,
^~~~~~~~~~~~~~~~
drivers/net/phy/broadcom.c:714:4: error: initializer element is not constant
{ PHY_ID_BCM54210E, 0xfffffff0 },
^~~~~~~~~~~~~~~~
drivers/net/phy/broadcom.c:714:4: note: (near initialization for 'broadcom_tbl[2].phy_id')
vim +/if +249 drivers/net/phy/broadcom.c
233 MII_BCM54XX_INT_SPEED |
234 MII_BCM54XX_INT_LINK);
235 err = phy_write(phydev, MII_BCM54XX_IMR, reg);
236 if (err < 0)
237 return err;
238
239 if ((BRCM_PHY_MODEL(phydev) == PHY_ID_BCM50610 ||
240 BRCM_PHY_MODEL(phydev) == PHY_ID_BCM50610M) &&
241 (phydev->dev_flags & PHY_BRCM_CLEAR_RGMII_MODE))
242 bcm_phy_write_shadow(phydev, BCM54XX_SHD_RGMII_MODE, 0);
243
244 if ((phydev->dev_flags & PHY_BRCM_RX_REFCLK_UNUSED) ||
245 (phydev->dev_flags & PHY_BRCM_DIS_TXCRXC_NOENRGY) ||
246 (phydev->dev_flags & PHY_BRCM_AUTO_PWRDWN_ENABLE))
247 bcm54xx_adjust_rxrefclk(phydev);
248
> 249 if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E) {
250 err = bcm54210e_config_init(phydev);
251 if (err)
252 return err;
253 } else if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
254 err = bcm54810_config(phydev);
255 if (err)
256 return err;
257 }
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32428 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 2/2] ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W
From: Sergei Shtylyov @ 2017-01-27 12:52 UTC (permalink / raw)
To: Simon Horman, David Miller
Cc: Magnus Damm, netdev, linux-renesas-soc, Geert Uytterhoeven
In-Reply-To: <1485515090-7570-3-git-send-email-horms+renesas@verge.net.au>
On 01/27/2017 02:04 PM, Simon Horman wrote:
> From: Geert Uytterhoeven <geert+renesas@glider.be>
>
> The limitation to 10/100Mbit speeds on R-Car Gen3 is valid for R-Car H3
> ES1.0 only. Check for the exact SoC model to allow 1Gbps on newer
> revisions of R-Car H3, and on R-Car M3-W.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ 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