* [PATCH v3 net-next] dt-bindings: can: rcar_can: document r8a77965 support
From: Eugeniu Rosca @ 2018-08-20 14:49 UTC (permalink / raw)
To: Simon Horman, Kieran Bingham, Sergei Shtylyov,
Wolfgang Grandegger, Marc Kleine-Budde, David S . Miller,
Rob Herring, Mark Rutland, linux-can, netdev, devicetree,
Magnus Damm, linux-renesas-soc
Cc: Eugeniu Rosca, Eugeniu Rosca
From: Eugeniu Rosca <rosca.eugeniu@gmail.com>
Document the support for rcar_can on R8A77965 SoC devices.
Add R8A77965 to the list of SoCs which require the "assigned-clocks" and
"assigned-clock-rates" properties (thanks, Sergei).
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
---
Changes in v3:
- [Simon Horman] Added more recipients.
- [Simon Horman] Dropped redundant "can" word in summary line.
- [Simon Horman] Added Reviewed-by.
- [Kieran Bingham] Added Reviewed-by.
Changes in v2:
- [Kieran Bingham] Simplified commit description. Rewrapped text.
- [Sergei Shtylyov] Replaced footnotes with inline text.
- Pushed all dt-bindings patches to the beginning of the series.
---
Documentation/devicetree/bindings/net/can/rcar_can.txt | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
index 94a7f33ac5e9..60daa878c9a2 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
@@ -13,6 +13,7 @@ Required properties:
"renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
"renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
"renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
+ "renesas,can-r8a77965" if CAN controller is a part of R8A77965 SoC.
"renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
"renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
compatible device.
@@ -28,11 +29,10 @@ Required properties:
- pinctrl-0: pin control group to be used for this controller.
- pinctrl-names: must be "default".
-Required properties for "renesas,can-r8a7795" and "renesas,can-r8a7796"
-compatible:
-In R8A7795 and R8A7796 SoCs, "clkp2" can be CANFD clock. This is a div6 clock
-and can be used by both CAN and CAN FD controller at the same time. It needs to
-be scaled to maximum frequency if any of these controllers use it. This is done
+Required properties for R8A7795, R8A7796 and R8A77965:
+For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock and can
+be used by both CAN and CAN FD controller at the same time. It needs to be
+scaled to maximum frequency if any of these controllers use it. This is done
using the below properties:
- assigned-clocks: phandle of clkp2(CANFD) clock.
--
2.18.0
^ permalink raw reply related
* [PATCH] net: macb: do not disable MDIO bus at open/close time
From: Anssi Hannula @ 2018-08-20 14:55 UTC (permalink / raw)
To: netdev, Nicolas Ferre, Claudiu Beznea; +Cc: David S. Miller, Andrew Lunn
In-Reply-To: <3e55fc51-503c-d174-841c-a1a5a0f5ae69@microchip.com>
macb_reset_hw() is called from macb_close() and indirectly from
macb_open(). macb_reset_hw() zeroes the NCR register, including the MPE
(Management Port Enable) bit.
This will prevent accessing any other PHYs for other Ethernet MACs on
the MDIO bus, which remains registered at macb_reset_hw() time, until
macb_init_hw() is called from macb_open() which sets the MPE bit again.
I.e. currently the MDIO bus has a short disruption at open time and is
disabled at close time until the interface is opened again.
Fix that by only touching the RE and TE bits when enabling and disabling
RX/TX.
Fixes: 6c36a7074436 ("macb: Use generic PHY layer")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
---
Claudiu Beznea wrote:
> On 10.08.2018 09:22, Anssi Hannula wrote:
>>
>> macb_reset_hw() is called in init path too,
>
> I only see it in macb_close() and macb_open() called from macb_init_hw().
Yeah, macb_init_hw() is what I meant :)
drivers/net/ethernet/cadence/macb_main.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index dc09f9a8a49b..6501e9b3785a 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2028,14 +2028,17 @@ static void macb_reset_hw(struct macb *bp)
{
struct macb_queue *queue;
unsigned int q;
+ u32 ctrl = macb_readl(bp, NCR);
/* Disable RX and TX (XXX: Should we halt the transmission
* more gracefully?)
*/
- macb_writel(bp, NCR, 0);
+ ctrl &= ~(MACB_BIT(RE) | MACB_BIT(TE));
/* Clear the stats registers (XXX: Update stats first?) */
- macb_writel(bp, NCR, MACB_BIT(CLRSTAT));
+ ctrl |= MACB_BIT(CLRSTAT);
+
+ macb_writel(bp, NCR, ctrl);
/* Clear all status flags */
macb_writel(bp, TSR, -1);
@@ -2170,6 +2173,7 @@ static void macb_init_hw(struct macb *bp)
unsigned int q;
u32 config;
+ u32 ctrl;
macb_reset_hw(bp);
macb_set_hwaddr(bp);
@@ -2223,7 +2227,9 @@ static void macb_init_hw(struct macb *bp)
}
/* Enable TX and RX */
- macb_writel(bp, NCR, MACB_BIT(RE) | MACB_BIT(TE) | MACB_BIT(MPE));
+ ctrl = macb_readl(bp, NCR);
+ ctrl |= MACB_BIT(RE) | MACB_BIT(TE);
+ macb_writel(bp, NCR, ctrl);
}
/* The hash address register is 64 bits long and takes up two
--
2.17.1
^ permalink raw reply related
* Re: [PATCH V2 net-next 2/6] sctp: Handle sctp packets with CHECKSUM_PARTIAL
From: Marcelo Ricardo Leitner @ 2018-08-20 14:54 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, linux-sctp, virtualization, virtio-dev, mst, jasowang,
nhorman, Vladislav Yasevich
In-Reply-To: <20180502143824.GF5105@localhost.localdomain>
On Wed, May 02, 2018 at 11:38:24AM -0300, Marcelo Ricardo Leitner wrote:
> On Tue, May 01, 2018 at 10:07:35PM -0400, Vladislav Yasevich wrote:
> > With SCTP checksum offload available in virtio, it is now
> > possible for virtio to receive a sctp packet with CHECKSUM_PARTIAL
> > set (guest-to-guest traffic). SCTP doesn't really have a
> > partial checksum like TCP does, because CRC32c can't do partial
> > additive checksumming. It's all or nothing. So an SCTP packet
> > with CHECKSUM_PARTIAL will have checksum set to 0. Let SCTP
> > treat this as a valid checksum if CHECKSUM_PARTIAL is set.
> >
> > Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > ---
> > net/sctp/input.c | 11 ++++++++++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/sctp/input.c b/net/sctp/input.c
> > index ba8a6e6..055b8ffa 100644
> > --- a/net/sctp/input.c
> > +++ b/net/sctp/input.c
> > @@ -80,8 +80,17 @@ static inline int sctp_rcv_checksum(struct net *net, struct sk_buff *skb)
> > {
> > struct sctphdr *sh = sctp_hdr(skb);
> > __le32 cmp = sh->checksum;
> > - __le32 val = sctp_compute_cksum(skb, 0);
> > + __le32 val = 0;
> >
> > + /* In sctp PARTIAL checksum is always 0. This is a case of
> > + * a packet received from guest that supports checksum offload.
> > + * Assume it's correct as there is really no way to verify,
> > + * and we want to avaoid computing it unnecesarily.
> nit, typos --^ --^
Hi Vlad. Seems this patchset got stuck because of these.
The only other subthread that is left is actually about SCTP GSO,
which is not directly related to this.
Marcelo
^ permalink raw reply
* Re: [bpf-next RFC 1/3] flow_dissector: implements flow dissector BPF hook
From: Daniel Borkmann @ 2018-08-20 14:20 UTC (permalink / raw)
To: Willem de Bruijn, liu.song.a23
Cc: Petar Penkov, Petar Penkov, Network Development, David Miller,
Alexei Starovoitov, simon.horman, Willem de Bruijn
In-Reply-To: <CAF=yD-KciJUH6Mi_oE2rqfOPWTLvEAdinos64fL=0+dEA=_gFQ@mail.gmail.com>
On 08/20/2018 04:13 PM, Willem de Bruijn wrote:
> On Mon, Aug 20, 2018 at 1:47 AM Song Liu <liu.song.a23@gmail.com> wrote:
>> On Thu, Aug 16, 2018 at 4:14 PM, Petar Penkov <ppenkov@google.com> wrote:
>>> On Thu, Aug 16, 2018 at 3:40 PM, Song Liu <liu.song.a23@gmail.com> wrote:
>>>> On Thu, Aug 16, 2018 at 9:44 AM, Petar Penkov <peterpenkov96@gmail.com> wrote:
>>>>> From: Petar Penkov <ppenkov@google.com>
>>>>>
>>>>> Adds a hook for programs of type BPF_PROG_TYPE_FLOW_DISSECTOR and
>>>>> attach type BPF_FLOW_DISSECTOR that is executed in the flow dissector
>>>>> path. The BPF program is kept as a global variable so it is
>>>>> accessible to all flow dissectors.
>>>>>
>>>>> Signed-off-by: Petar Penkov <ppenkov@google.com>
>>>>> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
>>>>> @@ -658,6 +698,42 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>>>>> FLOW_DISSECTOR_KEY_BASIC,
>>>>> target_container);
>>>>>
>>>>> + rcu_read_lock();
>>>>> + attached = rcu_dereference(flow_dissector_prog);
>>>>> + if (attached) {
>>>>> + /* Note that even though the const qualifier is discarded
>>>>> + * throughout the execution of the BPF program, all changes(the
>>>>> + * control block) are reverted after the BPF program returns.
>>>>> + * Therefore, __skb_flow_dissect does not alter the skb.
>>>>> + */
>>>>> + struct bpf_flow_dissect_cb *cb;
>>>>> + u8 cb_saved[BPF_SKB_CB_LEN];
>>>>> + u32 result;
>>>>> +
>>>>> + cb = (struct bpf_flow_dissect_cb *)(bpf_skb_cb((struct sk_buff *)skb));
>>>>> +
>>>>> + /* Save Control Block */
>>>>> + memcpy(cb_saved, cb, sizeof(cb_saved));
>>>>> + memset(cb, 0, sizeof(cb_saved));
>>>>> +
>>>>> + /* Pass parameters to the BPF program */
>>>>> + cb->nhoff = nhoff;
>>>>> + cb->target_container = target_container;
>>>>> + cb->flow_dissector = flow_dissector;
>>>>> +
>>>>> + bpf_compute_data_pointers((struct sk_buff *)skb);
>>>>> + result = BPF_PROG_RUN(attached, skb);
>>>>> +
>>>>> + /* Restore state */
>>>>> + memcpy(cb, cb_saved, sizeof(cb_saved));
>>>>> +
>>>>> + key_control->thoff = min_t(u16, key_control->thoff,
>>>>> + skb ? skb->len : hlen);
>>>>> + rcu_read_unlock();
>>>>> + return result == BPF_OK;
>>>>> + }
>>>>
>>>> If the BPF program cannot handle certain protocol, shall we fall back
>>>> to the built-in logic? Otherwise, all BPF programs need to have some
>>>> code for all protocols.
>>>>
>>>> Song
>>>
>>> I believe that if we fall back to the built-in logic we lose all security
>>> guarantees from BPF and this is why the code does not support
>>> fall back.
>>>
>>> Petar
>>
>> I am not really sure we are on the same page. I am proposing 3
>> different return values from BPF_PROG_RUN(), and they should be
>> handled as
>>
>> 1. result == BPF_OK => return true;
>> 2. result == BPF_DROP => return false;
>> 3. result == something else => fall back.
>>
>> Does this proposal make any sense?
>>
>> Thanks,
>> Song
>
> It certainly makes sense. We debated it initially, as well.
>
> In the short term, it allows for simpler BPF programs, as they can
> off-load some protocols to the C implementation.
>
> But the RFC patchset already implements most protocols in BPF.
> I had not expected that when we started out.
>
> Eventually, I think it is preferable to just deprecate the C
> implementation. Which is not possible if we make this opt-out
> a part of the BPF flow dissector interface.
+1
> There is also the lesser issue that a buggy BPF program might
> accidentally pass the third value and unknowing open itself up
> to the large attack surface. Without this option, the security
> audit is much simpler.
Fully agree, I'm all for dropping such option.
Thanks,
Daniel
^ permalink raw reply
* Re: [bpf-next RFC 1/3] flow_dissector: implements flow dissector BPF hook
From: Willem de Bruijn @ 2018-08-20 14:13 UTC (permalink / raw)
To: liu.song.a23
Cc: Petar Penkov, Petar Penkov, Network Development, David Miller,
Alexei Starovoitov, Daniel Borkmann, simon.horman,
Willem de Bruijn
In-Reply-To: <CAPhsuW6w7OX4vjXhA=rH51rBZd-gjtvckUseZP77P5fez5As2A@mail.gmail.com>
On Mon, Aug 20, 2018 at 1:47 AM Song Liu <liu.song.a23@gmail.com> wrote:
>
> On Thu, Aug 16, 2018 at 4:14 PM, Petar Penkov <ppenkov@google.com> wrote:
> > On Thu, Aug 16, 2018 at 3:40 PM, Song Liu <liu.song.a23@gmail.com> wrote:
> >>
> >> On Thu, Aug 16, 2018 at 9:44 AM, Petar Penkov <peterpenkov96@gmail.com> wrote:
> >> > From: Petar Penkov <ppenkov@google.com>
> >> >
> >> > Adds a hook for programs of type BPF_PROG_TYPE_FLOW_DISSECTOR and
> >> > attach type BPF_FLOW_DISSECTOR that is executed in the flow dissector
> >> > path. The BPF program is kept as a global variable so it is
> >> > accessible to all flow dissectors.
> >> >
> >> > Signed-off-by: Petar Penkov <ppenkov@google.com>
> >> > Signed-off-by: Willem de Bruijn <willemb@google.com>
> >> > @@ -658,6 +698,42 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> >> > FLOW_DISSECTOR_KEY_BASIC,
> >> > target_container);
> >> >
> >> > + rcu_read_lock();
> >> > + attached = rcu_dereference(flow_dissector_prog);
> >> > + if (attached) {
> >> > + /* Note that even though the const qualifier is discarded
> >> > + * throughout the execution of the BPF program, all changes(the
> >> > + * control block) are reverted after the BPF program returns.
> >> > + * Therefore, __skb_flow_dissect does not alter the skb.
> >> > + */
> >> > + struct bpf_flow_dissect_cb *cb;
> >> > + u8 cb_saved[BPF_SKB_CB_LEN];
> >> > + u32 result;
> >> > +
> >> > + cb = (struct bpf_flow_dissect_cb *)(bpf_skb_cb((struct sk_buff *)skb));
> >> > +
> >> > + /* Save Control Block */
> >> > + memcpy(cb_saved, cb, sizeof(cb_saved));
> >> > + memset(cb, 0, sizeof(cb_saved));
> >> > +
> >> > + /* Pass parameters to the BPF program */
> >> > + cb->nhoff = nhoff;
> >> > + cb->target_container = target_container;
> >> > + cb->flow_dissector = flow_dissector;
> >> > +
> >> > + bpf_compute_data_pointers((struct sk_buff *)skb);
> >> > + result = BPF_PROG_RUN(attached, skb);
> >> > +
> >> > + /* Restore state */
> >> > + memcpy(cb, cb_saved, sizeof(cb_saved));
> >> > +
> >> > + key_control->thoff = min_t(u16, key_control->thoff,
> >> > + skb ? skb->len : hlen);
> >> > + rcu_read_unlock();
> >> > + return result == BPF_OK;
> >> > + }
> >>
> >> If the BPF program cannot handle certain protocol, shall we fall back
> >> to the built-in logic? Otherwise, all BPF programs need to have some
> >> code for all protocols.
> >>
> >> Song
> >
> > I believe that if we fall back to the built-in logic we lose all security
> > guarantees from BPF and this is why the code does not support
> > fall back.
> >
> > Petar
>
> I am not really sure we are on the same page. I am proposing 3
> different return values from BPF_PROG_RUN(), and they should be
> handled as
>
> 1. result == BPF_OK => return true;
> 2. result == BPF_DROP => return false;
> 3. result == something else => fall back.
>
> Does this proposal make any sense?
>
> Thanks,
> Song
It certainly makes sense. We debated it initially, as well.
In the short term, it allows for simpler BPF programs, as they can
off-load some protocols to the C implementation.
But the RFC patchset already implements most protocols in BPF.
I had not expected that when we started out.
Eventually, I think it is preferable to just deprecate the C
implementation. Which is not possible if we make this opt-out
a part of the BPF flow dissector interface.
There is also the lesser issue that a buggy BPF program might
accidentally pass the third value and unknowing open itself up
to the large attack surface. Without this option, the security
audit is much simpler.
^ permalink raw reply
* Re: [PATCH 0/2] net/sched: Add hardware specific counters to TC actions
From: Eelco Chaudron @ 2018-08-20 14:03 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David Miller, netdev, jhs, xiyou.wangcong, jiri, simon.horman,
Marcelo Ricardo Leitner
In-Reply-To: <20180817042722.0e534ce0@cakuba>
On 17 Aug 2018, at 13:27, Jakub Kicinski wrote:
> On Thu, 16 Aug 2018 14:02:44 +0200, Eelco Chaudron wrote:
>> On 11 Aug 2018, at 21:06, David Miller wrote:
>>
>>> From: Jakub Kicinski <jakub.kicinski@netronome.com>
>>> Date: Thu, 9 Aug 2018 20:26:08 -0700
>>>
>>>> It is not immediately clear why this is needed. The memory and
>>>> updating two sets of counters won't come for free, so perhaps a
>>>> stronger justification than troubleshooting is due? :S
>>>>
>>>> Netdev has counters for fallback vs forwarded traffic, so you'd
>>>> know
>>>> that traffic hits the SW datapath, plus the rules which are in_hw
>>>> will
>>>> most likely not match as of today for flower (assuming
>>>> correctness).
>>
>> I strongly believe that these counters are a requirement for a mixed
>> software/hardware (flow) based forwarding environment. The global
>> counters will not help much here as you might have chosen to have
>> certain traffic forwarded by software.
>>
>> These counters are probably the only option you have to figure out
>> why
>> forwarding is not as fast as expected, and you want to blame the TC
>> offload NIC.
>
> The suggested debugging flow would be:
> (1) check the global counter for fallback are incrementing;
> (2) find a flow with high stats but no in_hw flag set.
>
> The in_hw indication should be sufficient in most cases (unless there
> are shared blocks between netdevs of different ASICs...).
I guess the aim is to find miss behaving hardware, i.e. having the in_hw
flag set, but flows still coming to the kernel.
>>>> I'm slightly concerned about potential performance impact, would
>>>> you
>>>> be able to share some numbers for non-trivial number of flows (100k
>>>> active?)?
>>>
>>> Agreed, features used for diagnostics cannot have a harmful penalty
>>> for fast path performance.
>>
>> Fast path performance is not affected as these counters are not
>> incremented there. They are only incremented by the nic driver when
>> they
>> gather their statistics from hardware.
>
> Not by much, you are adding state to performance-critical structures,
> though, for what is effectively debugging purposes.
>
> I was mostly talking about the HW offload stat updates (sorry for not
> being clear).
>
> We can have some hundreds of thousands active offloaded flows, each of
> them can have multiple actions, and stats have to be updated multiple
> times per second and dumped probably around once a second, too. On a
> busy system the stats will get evicted from cache between each round.
>
> But I'm speculating let's see if I can get some numbers on it (if you
> could get some too, that would be great!).
I’ll try to measure some of this later this week/early next week.
>> However, the flow creation is effected, as this is where the extra
>> memory gets allocated. I had done some 40K flow tests before and did
>> not
>> see any noticeable change in flow insertion performance. As requested
>> by
>> Jakub I did it again for 100K (and threw a Netronome blade in the mix
>> ;). I used Marcelo’s test tool,
>> https://github.com/marceloleitner/perf-flower.git.
>>
>> Here are the numbers (time in seconds) for 10 runs in sorted order:
>>
>> +-------------+----------------+
>> | Base_kernel | Change_applied |
>> +-------------+----------------+
>> | 5.684019 | 5.656388 |
>> | 5.699658 | 5.674974 |
>> | 5.725220 | 5.722107 |
>> | 5.739285 | 5.839855 |
>> | 5.748088 | 5.865238 |
>> | 5.766231 | 5.873913 |
>> | 5.842264 | 5.909259 |
>> | 5.902202 | 5.912685 |
>> | 5.905391 | 5.947138 |
>> | 6.032997 | 5.997779 |
>> +-------------+----------------+
>>
>> I guess the deviation is in the userspace part, which is where in
>> real
>> life flows get added anyway.
>>
>> Let me know if more is unclear.
^ permalink raw reply
* Re: [PATCH 3/4] net: macb: Support specifying PHYs in a mdio container dts node
From: Andrew Lunn @ 2018-08-20 13:56 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: David S. Miller, Nicolas Ferre, kernel, netdev, mdf, Brad Mouring,
Florian Fainelli
In-Reply-To: <2c7d7e81-322d-c995-7de6-64a25906d280@pengutronix.de>
> I've done so in part 4/4.
Yes, i noticed that later. Ideally, it would be here, since this is
the patch which actually changes the binding.
Andrew
^ permalink raw reply
* Re: [PATCH 2/4] of: phy: Warn about unexpected fixed-links in of_mdiobus_register
From: Ahmad Fatoum @ 2018-08-20 13:51 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Nicolas Ferre, kernel, netdev, mdf, Brad Mouring,
Florian Fainelli
In-Reply-To: <20180820133734.GB6583@lunn.ch>
On 08/20/2018 03:37 PM, Andrew Lunn wrote:
> We should be more specific than "device tree". It is actually the "mdio bus subtree".
I wasn't sure if there are more drivers that call of_mdiobus_register for the MAC node.
I'll update the message.
> Is this patch on its own sufficient to fix your regression? Ideally we
> want one small patch which we can add to stable to fix the regression,
> and then all the new functionality goes into net-next.
This patch (or at least the fixed version in v3) only replaces the MDIO bus scan for
fixed-links with a warning. Patch 1/4 (the one Cc:ing stable) suffices to fix the regression.
^ permalink raw reply
* Re: [PATCH 3/4] net: macb: Support specifying PHYs in a mdio container dts node
From: Ahmad Fatoum @ 2018-08-20 13:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Nicolas Ferre, kernel, netdev, mdf, Brad Mouring,
Florian Fainelli
In-Reply-To: <20180820134234.GC6583@lunn.ch>
On 08/20/2018 03:42 PM, Andrew Lunn wrote:
> On Mon, Aug 20, 2018 at 02:12:37PM +0200, Ahmad Fatoum wrote:
> This is correct. But i would prefer the more readable
>
> struct device_node *node = of_get_child_by_name(np, "mdio");
>
> if (!node)
> /* Allow for the deprecated PHYs in the MAC node. */
> node = np;
>
>> if (pdata)
>> bp->mii_bus->phy_mask = pdata->phy_mask;
>> -
>> - err = of_mdiobus_register(bp->mii_bus, np);
>> + err = of_mdiobus_register(bp->mii_bus, node);
>> }
Ok.
> Also, the device tree binding documentation needs updating.
I've done so in part 4/4.
^ permalink raw reply
* Re: [PATCH 3/4] net: macb: Support specifying PHYs in a mdio container dts node
From: Andrew Lunn @ 2018-08-20 13:42 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: David S. Miller, Nicolas Ferre, kernel, netdev, mdf, Brad Mouring,
Florian Fainelli
In-Reply-To: <20180820121238.7779-3-a.fatoum@pengutronix.de>
On Mon, Aug 20, 2018 at 02:12:37PM +0200, Ahmad Fatoum wrote:
> To align macb DT entries with those of other MACs.
> For backwards compatibility, the old way remains supported.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index ef6ce8691443..2ebc5698db9d 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -596,10 +596,10 @@ static int macb_mii_init(struct macb *bp)
>
> err = mdiobus_register(bp->mii_bus);
> } else {
> + struct device_node *node = of_get_child_by_name(np, "mdio") ?: np;
This is correct. But i would prefer the more readable
struct device_node *node = of_get_child_by_name(np, "mdio");
if (!node)
/* Allow for the deprecated PHYs in the MAC node. */
node = np;
> if (pdata)
> bp->mii_bus->phy_mask = pdata->phy_mask;
> -
> - err = of_mdiobus_register(bp->mii_bus, np);
> + err = of_mdiobus_register(bp->mii_bus, node);
> }
Also, the device tree binding documentation needs updating.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH 2/4] of: phy: Warn about unexpected fixed-links in of_mdiobus_register
From: Andrew Lunn @ 2018-08-20 13:37 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: David S. Miller, Nicolas Ferre, kernel, netdev, mdf, Brad Mouring,
Florian Fainelli
In-Reply-To: <20180820121238.7779-2-a.fatoum@pengutronix.de>
On Mon, Aug 20, 2018 at 02:12:36PM +0200, Ahmad Fatoum wrote:
> fixed-links are currently not handled by of_mdiobus_register,
> skip them with a warning instead of trying pointlessly to find their PHY
> address:
>
> libphy: MACB_mii_bus: probed
> mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address
> mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0
> [snip]
> mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31
> macb f0028000.ethernet: broken fixed-link specification
>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> drivers/of/of_mdio.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index e92391d6d1bd..9a7ccd299daf 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -229,6 +229,13 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
>
> /* Loop over the child nodes and register a phy_device for each phy */
> for_each_available_child_of_node(np, child) {
> + if (of_phy_is_fixed_link(np)) {
> + /* fixed-links are handled in the MAC drivers */
> + dev_warn(&mdio->dev, FW_BUG
> + "Skipping unexpected fixed-link in device tree");
Hi Ahmad
We should be more specific than "device tree". It is actually the "mdio bus subtree".
Is this patch on its own sufficient to fix your regression? Ideally we
want one small patch which we can add to stable to fix the regression,
and then all the new functionality goes into net-next.
Andrew
^ permalink raw reply
* Re: [RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.
From: Andrew Lunn @ 2018-08-20 13:28 UTC (permalink / raw)
To: Craig McGeachie; +Cc: David S. Miller, netdev, Craig McGeachie
In-Reply-To: <43f861ad-1e40-7e6e-b90c-ce410c60df94@gmail.com>
> Turns out the problem is WinPCAP running on the host system (Windows
> 10).
Hi Craig
It would be good to report this to the WinPCAP people. I hate it when
debug tools actually introduce bugs.
Andrew
^ permalink raw reply
* Re: [PATCH 1/4] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Ahmad Fatoum @ 2018-08-20 15:56 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Nicolas Ferre, kernel, netdev, mdf, Brad Mouring,
Florian Fainelli, stable
In-Reply-To: <20180820135536.GD6583@lunn.ch>
On 08/20/2018 03:55 PM, Andrew Lunn wrote:
> Why is of_phy_register_fixed_link(np) failing?
Apparently, the fixed-link's gpio's FLAG_REQUESTED bit remained set
causing gpiod_request_commit to return -EBUSY in (v4.18.0):
[<c0667750>] (gpiod_request_commit) from [<c066890c>] (gpiod_request+0x64/0x88)
[<c066890c>] (gpiod_request) from [<c066a338>] (gpiod_get_from_of_node+0x48/0x13c)
[<c066a338>] (gpiod_get_from_of_node) from [<c094b92c>] (mdiobus_register_device+0x70/0x124)
[<c094b92c>] (mdiobus_register_device) from [<c0949d2c>] (phy_device_register+0xc/0xa0)
[<c0949d2c>] (phy_device_register) from [<c094e824>] (fixed_phy_register+0xe8/0x1f8)
[<c094e824>] (fixed_phy_register) from [<c0b84260>] (of_phy_register_fixed_link+0x150/0x1e4)
[<c0b84260>] (of_phy_register_fixed_link) from [<c0964908>] (macb_probe+0x548/0xa7c)
[<c0964908>] (macb_probe) from [<c086ebec>] (platform_drv_probe+0x48/0x98)
But that's a separate issue, I'll remove this line from the commit message...
^ permalink raw reply
* Re: [PATCH 2/4] of: phy: Warn about unexpected fixed-links in of_mdiobus_register
From: Ahmad Fatoum @ 2018-08-20 12:31 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Nicolas Ferre
Cc: netdev, Florian Fainelli, mdf, kernel, Brad Mouring
In-Reply-To: <20180820121238.7779-2-a.fatoum@pengutronix.de>
On 08/20/2018 02:12 PM, Ahmad Fatoum wrote:
> /* Loop over the child nodes and register a phy_device for each phy */
> for_each_available_child_of_node(np, child) {
> + if (of_phy_is_fixed_link(np)) {
> + /* fixed-links are handled in the MAC drivers */
> + dev_warn(&mdio->dev, FW_BUG
> + "Skipping unexpected fixed-link in device tree");
> + continue;
> + }
> +
This would emit the warning even for normal PHYs,
because of_phy_is_fixed_link looks up a child...
I will correct this in v3 along with any other potential suggestions.
^ permalink raw reply
* [PATCH 2/4] of: phy: Warn about unexpected fixed-links in of_mdiobus_register
From: Ahmad Fatoum @ 2018-08-20 12:12 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Nicolas Ferre
Cc: kernel, netdev, mdf, Brad Mouring, Florian Fainelli
In-Reply-To: <20180820121238.7779-1-a.fatoum@pengutronix.de>
fixed-links are currently not handled by of_mdiobus_register,
skip them with a warning instead of trying pointlessly to find their PHY
address:
libphy: MACB_mii_bus: probed
mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address
mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0
[snip]
mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31
macb f0028000.ethernet: broken fixed-link specification
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
drivers/of/of_mdio.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index e92391d6d1bd..9a7ccd299daf 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -229,6 +229,13 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
/* Loop over the child nodes and register a phy_device for each phy */
for_each_available_child_of_node(np, child) {
+ if (of_phy_is_fixed_link(np)) {
+ /* fixed-links are handled in the MAC drivers */
+ dev_warn(&mdio->dev, FW_BUG
+ "Skipping unexpected fixed-link in device tree");
+ continue;
+ }
+
addr = of_mdio_parse_addr(&mdio->dev, child);
if (addr < 0) {
scanphys = true;
--
2.18.0
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: macb: wrap macb PHYs in a mdio container
From: Ahmad Fatoum @ 2018-08-20 12:12 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Nicolas Ferre
Cc: kernel, netdev, mdf, Brad Mouring, Florian Fainelli
In-Reply-To: <20180820121238.7779-1-a.fatoum@pengutronix.de>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
.../devicetree/bindings/net/macb.txt | 13 +++--
arch/arm/boot/dts/at91-sam9_l9260.dts | 6 ++-
arch/arm/boot/dts/at91-sama5d27_som1.dtsi | 14 ++---
arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 10 ++--
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 10 ++--
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 12 +++--
arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts | 6 ++-
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 10 ++--
arch/arm/boot/dts/at91-sama5d4ek.dts | 10 ++--
arch/arm/boot/dts/at91-vinco.dts | 24 +++++----
arch/arm/boot/dts/at91rm9200ek.dts | 8 +--
arch/arm/boot/dts/sama5d2.dtsi | 5 ++
arch/arm/boot/dts/sama5d3_emac.dtsi | 5 ++
arch/arm/boot/dts/sama5d3_gmac.dtsi | 5 ++
arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 52 ++++++++++---------
arch/arm/boot/dts/sama5d3xmb_gmac.dtsi | 52 ++++++++++---------
arch/arm/boot/dts/sama5d4.dtsi | 10 ++++
17 files changed, 155 insertions(+), 97 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 457d5ae16f23..f39732372538 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -25,7 +25,8 @@ Required properties:
Optional elements: 'tsu_clk'
- clocks: Phandles to input clocks.
-Optional properties for PHY child node:
+PHY child nodes should be grouped in a mdio container,
+they have following optional properties:
- reset-gpios : Should specify the gpio for phy reset
- magic-packet : If present, indicates that the hardware supports waking
up via magic packet.
@@ -41,8 +42,12 @@ Examples:
local-mac-address = [3a 0e 03 04 05 06];
clock-names = "pclk", "hclk", "tx_clk";
clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
- ethernet-phy@1 {
- reg = <0x1>;
- reset-gpios = <&pioE 6 1>;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethernet-phy@1 {
+ reg = <0x1>;
+ reset-gpios = <&pioE 6 1>;
+ };
};
};
diff --git a/arch/arm/boot/dts/at91-sam9_l9260.dts b/arch/arm/boot/dts/at91-sam9_l9260.dts
index 70cb36f7a9d7..9d1fbd3afaea 100644
--- a/arch/arm/boot/dts/at91-sam9_l9260.dts
+++ b/arch/arm/boot/dts/at91-sam9_l9260.dts
@@ -67,8 +67,10 @@
#size-cells = <0>;
status = "okay";
- ethernet-phy@1 {
- reg = <0x1>;
+ mdio {
+ ethernet-phy@1 {
+ reg = <0x1>;
+ };
};
};
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1.dtsi b/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
index cf0087b4c9e1..f729f128e68e 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
+++ b/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
@@ -67,12 +67,14 @@
pinctrl-0 = <&pinctrl_macb0_default>;
phy-mode = "rmii";
- ethernet-phy@0 {
- reg = <0x0>;
- interrupt-parent = <&pioA>;
- interrupts = <PIN_PD31 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_macb0_phy_irq>;
+ mdio {
+ ethernet-phy@0 {
+ reg = <0x0>;
+ interrupt-parent = <&pioA>;
+ interrupts = <PIN_PD31 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_macb0_phy_irq>;
+ };
};
};
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
index b10dccd0958f..1ba4bad8189b 100644
--- a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -142,10 +142,12 @@
phy-mode = "rmii";
status = "okay";
- ethernet-phy@1 {
- reg = <0x1>;
- interrupt-parent = <&pioA>;
- interrupts = <56 IRQ_TYPE_LEVEL_LOW>;
+ mdio {
+ ethernet-phy@1 {
+ reg = <0x1>;
+ interrupt-parent = <&pioA>;
+ interrupts = <56 IRQ_TYPE_LEVEL_LOW>;
+ };
};
};
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index fcc85d70f36e..83b435744ffd 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -126,10 +126,12 @@
phy-mode = "rmii";
status = "okay";
- ethernet-phy@1 {
- reg = <0x1>;
- interrupt-parent = <&pioA>;
- interrupts = <PIN_PC9 IRQ_TYPE_LEVEL_LOW>;
+ mdio {
+ ethernet-phy@1 {
+ reg = <0x1>;
+ interrupt-parent = <&pioA>;
+ interrupts = <PIN_PC9 IRQ_TYPE_LEVEL_LOW>;
+ };
};
};
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index 02c1d2958d78..a84fec83f0a5 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -134,8 +134,10 @@
#size-cells = <0>;
status = "okay";
- ethernet-phy@7 {
- reg = <0x7>;
+ mdio {
+ ethernet-phy@7 {
+ reg = <0x7>;
+ };
};
};
@@ -201,8 +203,10 @@
#size-cells = <0>;
status = "okay";
- ethernet-phy@1 {
- reg = <0x1>;
+ mdio {
+ ethernet-phy@1 {
+ reg = <0x1>;
+ };
};
};
diff --git a/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts b/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
index fe05aaa7ac87..a361423a3969 100644
--- a/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
@@ -63,8 +63,10 @@
phy-mode = "rmii";
status = "okay";
- phy0: ethernet-phy@0 {
- reg = <0>;
+ mdio {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
};
};
diff --git a/arch/arm/boot/dts/at91-sama5d4_xplained.dts b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
index 4b7c762d5f22..8b22ff53b40a 100644
--- a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -95,10 +95,12 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_macb0_rmii &pinctrl_macb0_phy_irq>;
- phy0: ethernet-phy@1 {
- interrupt-parent = <&pioE>;
- interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
- reg = <1>;
+ mdio {
+ phy0: ethernet-phy@1 {
+ interrupt-parent = <&pioE>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ reg = <1>;
+ };
};
};
diff --git a/arch/arm/boot/dts/at91-sama5d4ek.dts b/arch/arm/boot/dts/at91-sama5d4ek.dts
index 0702a2f2b336..35ccba00b8cb 100644
--- a/arch/arm/boot/dts/at91-sama5d4ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d4ek.dts
@@ -144,10 +144,12 @@
phy-mode = "rmii";
status = "okay";
- ethernet-phy@1 {
- reg = <0x1>;
- interrupt-parent = <&pioE>;
- interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ mdio {
+ ethernet-phy@1 {
+ reg = <0x1>;
+ interrupt-parent = <&pioE>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ };
};
};
diff --git a/arch/arm/boot/dts/at91-vinco.dts b/arch/arm/boot/dts/at91-vinco.dts
index 1be9889a2b3a..b690031ada28 100644
--- a/arch/arm/boot/dts/at91-vinco.dts
+++ b/arch/arm/boot/dts/at91-vinco.dts
@@ -116,11 +116,13 @@
phy-mode = "rmii";
status = "okay";
- ethernet-phy@1 {
- reg = <0x1>;
- reset-gpios = <&pioE 8 GPIO_ACTIVE_LOW>;
- interrupt-parent = <&pioB>;
- interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
+ mdio {
+ ethernet-phy@1 {
+ reg = <0x1>;
+ reset-gpios = <&pioE 8 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&pioB>;
+ interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
+ };
};
};
@@ -170,11 +172,13 @@
#size-cells = <0>;
status = "okay";
- ethernet-phy@1 {
- reg = <0x1>;
- interrupt-parent = <&pioB>;
- interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
- reset-gpios = <&pioE 6 GPIO_ACTIVE_LOW>;
+ mdio {
+ ethernet-phy@1 {
+ reg = <0x1>;
+ interrupt-parent = <&pioB>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&pioE 6 GPIO_ACTIVE_LOW>;
+ };
};
};
diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
index 81aaf8151c76..1b1cc47b2376 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -54,9 +54,11 @@
phy-mode = "rmii";
status = "okay";
- phy0: ethernet-phy {
- interrupt-parent = <&pioC>;
- interrupts = <4 IRQ_TYPE_EDGE_BOTH>;
+ mdio {
+ phy0: ethernet-phy {
+ interrupt-parent = <&pioC>;
+ interrupts = <4 IRQ_TYPE_EDGE_BOTH>;
+ };
};
};
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 61f68e5c48e9..424aabd0db68 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -1091,6 +1091,11 @@
clocks = <&macb0_clk>, <&macb0_clk>;
clock-names = "hclk", "pclk";
status = "disabled";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
tcb0: timer@f800c000 {
diff --git a/arch/arm/boot/dts/sama5d3_emac.dtsi b/arch/arm/boot/dts/sama5d3_emac.dtsi
index 7cb235ef0fb6..d0187d4da1da 100644
--- a/arch/arm/boot/dts/sama5d3_emac.dtsi
+++ b/arch/arm/boot/dts/sama5d3_emac.dtsi
@@ -49,6 +49,11 @@
clocks = <&macb1_clk>, <&macb1_clk>;
clock-names = "hclk", "pclk";
status = "disabled";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
};
};
diff --git a/arch/arm/boot/dts/sama5d3_gmac.dtsi b/arch/arm/boot/dts/sama5d3_gmac.dtsi
index 23f225fbb756..826d5891a2da 100644
--- a/arch/arm/boot/dts/sama5d3_gmac.dtsi
+++ b/arch/arm/boot/dts/sama5d3_gmac.dtsi
@@ -82,6 +82,11 @@
clocks = <&macb0_clk>, <&macb0_clk>;
clock-names = "hclk", "pclk";
status = "disabled";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
};
};
diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
index a02f59021364..948df9aa40ac 100644
--- a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
+++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
@@ -86,32 +86,34 @@
#address-cells = <1>;
#size-cells = <0>;
- ethernet-phy@1 {
- reg = <0x1>;
- interrupt-parent = <&pioB>;
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- txen-skew-ps = <800>;
- txc-skew-ps = <3000>;
- rxdv-skew-ps = <400>;
- rxc-skew-ps = <3000>;
- rxd0-skew-ps = <400>;
- rxd1-skew-ps = <400>;
- rxd2-skew-ps = <400>;
- rxd3-skew-ps = <400>;
- };
+ mdio {
+ ethernet-phy@1 {
+ reg = <0x1>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
- ethernet-phy@7 {
- reg = <0x7>;
- interrupt-parent = <&pioB>;
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- txen-skew-ps = <800>;
- txc-skew-ps = <3000>;
- rxdv-skew-ps = <400>;
- rxc-skew-ps = <3000>;
- rxd0-skew-ps = <400>;
- rxd1-skew-ps = <400>;
- rxd2-skew-ps = <400>;
- rxd3-skew-ps = <400>;
+ ethernet-phy@7 {
+ reg = <0x7>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
};
};
diff --git a/arch/arm/boot/dts/sama5d3xmb_gmac.dtsi b/arch/arm/boot/dts/sama5d3xmb_gmac.dtsi
index 65aea7a75b1d..af097ff8bee4 100644
--- a/arch/arm/boot/dts/sama5d3xmb_gmac.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb_gmac.dtsi
@@ -15,32 +15,34 @@
#address-cells = <1>;
#size-cells = <0>;
- ethernet-phy@1 {
- reg = <0x1>;
- interrupt-parent = <&pioB>;
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- txen-skew-ps = <800>;
- txc-skew-ps = <3000>;
- rxdv-skew-ps = <400>;
- rxc-skew-ps = <3000>;
- rxd0-skew-ps = <400>;
- rxd1-skew-ps = <400>;
- rxd2-skew-ps = <400>;
- rxd3-skew-ps = <400>;
- };
+ mdio {
+ ethernet-phy@1 {
+ reg = <0x1>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
- ethernet-phy@7 {
- reg = <0x7>;
- interrupt-parent = <&pioB>;
- interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
- txen-skew-ps = <800>;
- txc-skew-ps = <3000>;
- rxdv-skew-ps = <400>;
- rxc-skew-ps = <3000>;
- rxd0-skew-ps = <400>;
- rxd1-skew-ps = <400>;
- rxd2-skew-ps = <400>;
- rxd3-skew-ps = <400>;
+ ethernet-phy@7 {
+ reg = <0x7>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
};
};
};
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 0cf9beddd556..d623a8dc0116 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -980,6 +980,11 @@
clocks = <&macb0_clk>, <&macb0_clk>;
clock-names = "hclk", "pclk";
status = "disabled";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
i2c2: i2c@f8024000 {
@@ -1220,6 +1225,11 @@
clocks = <&macb1_clk>, <&macb1_clk>;
clock-names = "hclk", "pclk";
status = "disabled";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
trng@fc030000 {
--
2.18.0
^ permalink raw reply related
* [PATCH 3/4] net: macb: Support specifying PHYs in a mdio container dts node
From: Ahmad Fatoum @ 2018-08-20 12:12 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Nicolas Ferre
Cc: kernel, netdev, mdf, Brad Mouring, Florian Fainelli
In-Reply-To: <20180820121238.7779-1-a.fatoum@pengutronix.de>
To align macb DT entries with those of other MACs.
For backwards compatibility, the old way remains supported.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
drivers/net/ethernet/cadence/macb_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index ef6ce8691443..2ebc5698db9d 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -596,10 +596,10 @@ static int macb_mii_init(struct macb *bp)
err = mdiobus_register(bp->mii_bus);
} else {
+ struct device_node *node = of_get_child_by_name(np, "mdio") ?: np;
if (pdata)
bp->mii_bus->phy_mask = pdata->phy_mask;
-
- err = of_mdiobus_register(bp->mii_bus, np);
+ err = of_mdiobus_register(bp->mii_bus, node);
}
if (err)
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 1/4] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Andrew Lunn @ 2018-08-20 13:55 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: David S. Miller, Nicolas Ferre, kernel, netdev, mdf, Brad Mouring,
Florian Fainelli, stable
In-Reply-To: <20180820121238.7779-1-a.fatoum@pengutronix.de>
On Mon, Aug 20, 2018 at 02:12:35PM +0200, Ahmad Fatoum wrote:
> The referenced commit broke initializing macb on the EVB-KSZ9477 eval board.
> There, of_mdiobus_register was called even for the fixed-link representing
> the SPI-connected switch PHY, with the result that the driver attempts to
> enumerate PHYs on a non-existent MDIO bus:
>
> libphy: MACB_mii_bus: probed
So there are two different things here:
> mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address
> mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0
> [snip]
> mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31
These are the result of the fixed-link being considered a PHY in
of_mdiobus_register(). Patch 2 fixes that, turns it into a single
warning.
> macb f0028000.ethernet: broken fixed-link specification
Why is of_phy_register_fixed_link(np) failing?
>
> Cc: <stable@vger.kernel.org>
> Fixes: 739de9a1563a ("net: macb: Reorganize macb_mii bringup")
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 27 +++++++++++++++---------
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> Fixes since v1:
> Added one more error path for failing to register fixed-link
> Fixed a whitespace issue
>
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index dc09f9a8a49b..ef6ce8691443 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -482,11 +482,6 @@ static int macb_mii_probe(struct net_device *dev)
>
> if (np) {
> if (of_phy_is_fixed_link(np)) {
> - if (of_phy_register_fixed_link(np) < 0) {
> - dev_err(&bp->pdev->dev,
> - "broken fixed-link specification\n");
> - return -ENODEV;
> - }
As a separate patch, please can you use the error code which
of_phy_register_fixed_link() returns, not -ENODEV. It is possible it
is returning EPROBE_DEFER.
Andrew
^ permalink raw reply
* Re: unregister_netdevice: waiting for DEV to become free (2)
From: Julian Anastasov @ 2018-08-20 12:55 UTC (permalink / raw)
To: syzbot; +Cc: ddstreet, dvyukov, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <0000000000007d22100573d66078@google.com>
Hello,
On Sun, 19 Aug 2018, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit: d7857ae43dcc Add linux-next specific files for 20180817
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13c72fce400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=4b10cd1ea76bb092
> dashboard link: https://syzkaller.appspot.com/bug?extid=30209ea299c09d8785c9
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=15df679a400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15242741400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+30209ea299c09d8785c9@syzkaller.appspotmail.com
>
> IPVS: stopping master sync thread 4657 ...
> IPVS: stopping master sync thread 4663 ...
> IPVS: sync thread started: state = MASTER, mcast_ifn = syz_tun, syncid = 0, id
> IPVS: = 0
> IPVS: sync thread started: state = MASTER, mcast_ifn = syz_tun, syncid = 0, id
> IPVS: = 0
> IPVS: stopping master sync thread 4664 ...
> unregister_netdevice: waiting for lo to become free. Usage count = 1
Well, only IPVS and tun in the game? But IPVS does not
take any dev references for sync threads. Can it be a problem
in tun? For example, a side effects from dst_cache_reset?
May be dst_release is called too late? Here is what should happen
on unregistration:
- NETDEV_UNREGISTER event: rt_flush_dev changes dst->dev with lo
but dst is not released
- ndo_uninit/ip_tunnel_uninit: dst_cache_reset is called which
does nothing!?! May be dst_release call is needed here.
- no more references are expected here ...
- netdev_run_todo -> netdev_wait_allrefs: loop here due to refcnt!=0
- dev->priv_destructor (ip_tunnel_dev_free) calls dst_cache_destroy
where dst_release is used but it is not reached because we loop in
netdev_wait_allrefs above
- dst_cache_destroy: really call dst_release
In fact, after calling rt_flush_dev and replacing the
dst->dev we should reach dev->priv_destructor (ip_tunnel_dev_free)
for tun device where dst_release for lo should be called. But may be
something prevents it, exit batching?
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Ahmad Fatoum @ 2018-08-20 12:37 UTC (permalink / raw)
To: Lad, Prabhakar, Andrew Lunn
Cc: Uwe Kleine-König, David S. Miller, Nicolas Ferre, netdev,
mdf, stable, Sascha Hauer, brad.mouring, Florian Fainelli
In-Reply-To: <CA+V-a8tjrJGNh6gLALtzR8WB36xFMoA+prsst-mp7jhtoxHhWg@mail.gmail.com>
On 08/15/2018 03:59 PM, Lad, Prabhakar wrote:
> This didn’t happen in v4.9.x something in core has changed ?
In my case, it was the macb driver that changed. I found the offending commit
with git-bisect, you might want to give it a try.
^ permalink raw reply
* Re: [PATCH] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Ahmad Fatoum @ 2018-08-20 12:17 UTC (permalink / raw)
To: Andrew Lunn
Cc: Uwe Kleine-König, David S. Miller, Nicolas Ferre, netdev,
mdf, stable, kernel, Brad Mouring, Florian Fainelli
In-Reply-To: <20180816142443.GA5282@lunn.ch>
On 08/16/2018 04:24 PM, Andrew Lunn wrote:
> 1) A regression. We should find a fix for that. Maybe we should
> special case a child node called 'fixed-link' in
> of_mdiobus_register(). I would suggest adding a single warning if
> such node is found.
I just sent out a v2, which warns if fixed-link is encountered
in of_mdiobus_register(). The actual fixed-link handling remains in the
macb driver, because I think it's would be out of scope for a regression
fix to change where fixed-links are handled for all using drivers...
> 2) Missing functionality. Add support for an mdio container node.
>
> node = of_get_child_by_name(np, "mdio");
> if (node)
> err = of_mdiobus_register(bp->mii_bus, node);
> else
> err = of_mdiobus_register(bp->mii_bus, np);
Done.
> 3) Modify the existing dts files to make use of this container.
> Because of backwards compatibility, we cannot force the use of it,
> but we can encourage it.
Done as well.
Cheers
Ahmad
^ permalink raw reply
* [PATCH 1/4] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Ahmad Fatoum @ 2018-08-20 12:12 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Nicolas Ferre
Cc: kernel, netdev, mdf, Brad Mouring, Florian Fainelli, stable
The referenced commit broke initializing macb on the EVB-KSZ9477 eval board.
There, of_mdiobus_register was called even for the fixed-link representing
the SPI-connected switch PHY, with the result that the driver attempts to
enumerate PHYs on a non-existent MDIO bus:
libphy: MACB_mii_bus: probed
mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address
mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0
[snip]
mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31
macb f0028000.ethernet: broken fixed-link specification
Cc: <stable@vger.kernel.org>
Fixes: 739de9a1563a ("net: macb: Reorganize macb_mii bringup")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
drivers/net/ethernet/cadence/macb_main.c | 27 +++++++++++++++---------
1 file changed, 17 insertions(+), 10 deletions(-)
Fixes since v1:
Added one more error path for failing to register fixed-link
Fixed a whitespace issue
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index dc09f9a8a49b..ef6ce8691443 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -482,11 +482,6 @@ static int macb_mii_probe(struct net_device *dev)
if (np) {
if (of_phy_is_fixed_link(np)) {
- if (of_phy_register_fixed_link(np) < 0) {
- dev_err(&bp->pdev->dev,
- "broken fixed-link specification\n");
- return -ENODEV;
- }
bp->phy_node = of_node_get(np);
} else {
bp->phy_node = of_parse_phandle(np, "phy-handle", 0);
@@ -569,7 +564,7 @@ static int macb_mii_init(struct macb *bp)
{
struct macb_platform_data *pdata;
struct device_node *np;
- int err;
+ int err = -ENXIO;
/* Enable management port */
macb_writel(bp, NCR, MACB_BIT(MPE));
@@ -592,12 +587,23 @@ static int macb_mii_init(struct macb *bp)
dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
np = bp->pdev->dev.of_node;
- if (pdata)
- bp->mii_bus->phy_mask = pdata->phy_mask;
+ if (np && of_phy_is_fixed_link(np)) {
+ if (of_phy_register_fixed_link(np) < 0) {
+ dev_err(&bp->pdev->dev,
+ "broken fixed-link specification\n");
+ goto err_out_free_mdiobus;
+ }
+
+ err = mdiobus_register(bp->mii_bus);
+ } else {
+ if (pdata)
+ bp->mii_bus->phy_mask = pdata->phy_mask;
+
+ err = of_mdiobus_register(bp->mii_bus, np);
+ }
- err = of_mdiobus_register(bp->mii_bus, np);
if (err)
- goto err_out_free_mdiobus;
+ goto err_out_free_fixed_link;
err = macb_mii_probe(bp->dev);
if (err)
@@ -607,6 +613,7 @@ static int macb_mii_init(struct macb *bp)
err_out_unregister_bus:
mdiobus_unregister(bp->mii_bus);
+err_out_free_fixed_link:
if (np && of_phy_is_fixed_link(np))
of_phy_deregister_fixed_link(np);
err_out_free_mdiobus:
--
2.18.0
^ permalink raw reply related
* Re: [RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.
From: Craig McGeachie @ 2018-08-20 8:48 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David S. Miller, netdev, Craig McGeachie
In-Reply-To: <20180819144107.GA23981@lunn.ch>
On 20/08/18 02:41, Andrew Lunn wrote:
>> I run inside Virtualbox with the Realtek PCIe GBE Family Controller.
>>
>> Assuming I'm reading /sys/class/net/enp0s3/driver correctly, it's using the
>> e1000 driver.
>
> Hi Craig
Andrew,
My apologies. I've wasted your time. PEBKAC.
> Ah. And how do you connect to the network? Please run some tcpdumps
> and collect packets at various points. Make sure your network setup is
> not duplicating packets, in particular, any bridges you might have in
> order to connect the segments together.
Just for the record, in case anyone else experiences this later. It's
Fedora Core 29 with kernel 4.17.12-200.fc28.x86_64 running inside
Virtualbox 4.2.16. The host NIC is Realtek PCIe GBE. The virtual NIC is
Intel 82540EM. The Linux kernel driver for the virtual NIC is e1000. The
virtual NIC is connected to the physical NIC in bridged mode.
>> However, it might not be the ethernet driver's fault. I've been a bit loose
>> with terminology. Appletalk AARP probe packets aren't ethernet broadcasts as
>> such; they're multicast packets, via the psnap driver, to hardware address
>> 09:00:07:ff:ff:ff.
>
> Basically, the same question applies for Multicast as for Broadcast.
> I'm pretty sure the interface should not receiver the packet it
> transmitted itself. But if something on the network has duplicated the
> packet, it will receiver the duplicate. So before we add a filter,
> lets understand where the packets are coming from.
Turns out the problem is WinPCAP running on the host system (Windows
10). I can reliably cause the problem by starting up anything using
WinPCAP on the host system. I can make the AARP packet echo go away by
shutting down everything that uses WinPCAP.
I don't have a real Apple IIgs (much as I might like one) so I've been
using GSport 0.31, which uses WinPCAP to generate Ethertalk packets over
the same physical NIC that the Linux virtual machine is bridged to.
I've also been using Wireshark on both the host system and guest system
to diagnose my problem. Ironically, using Wireshark on the host system
is one way to cause the packet echo. Wireshark on the guest system works
just fine.
Maybe running WinPCAP and the bridged virtual NIC on different physical
NICS would fix the problem. I wouldn't know. My solution is run GSport
on a different computer. Using Win10pcap 10.2.5002 instead of WinPCAP
4.1.3 is not a fix. It has the same problem.
I have trouble believing this affects only Appletalk packets, but it's
probably unfounded speculation to consider anything else.
Anyway, thank you very much for your time Andrew.
Cheers,
Craig.
^ permalink raw reply
* Re: [PATCH bpf] xsk: fix return value of xdp_umem_assign_dev()
From: Björn Töpel @ 2018-08-20 8:31 UTC (permalink / raw)
To: bhole_prashant_q7
Cc: ast, Daniel Borkmann, Björn Töpel, Karlsson, Magnus,
David Miller, Netdev
In-Reply-To: <20180820005425.2604-1-bhole_prashant_q7@lab.ntt.co.jp>
Den mån 20 aug. 2018 kl 02:58 skrev Prashant Bhole
<bhole_prashant_q7@lab.ntt.co.jp>:
>
> s/ENOTSUPP/EOPNOTSUPP/ in function umem_assign_dev().
> This function's return value is directly returned by xsk_bind().
> EOPNOTSUPP is bind()'s possible return value.
>
> Fixes: f734607e819b ("xsk: refactor xdp_umem_assign_dev()")
> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
> ---
> net/xdp/xdp_umem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> index 911ca6d3cb5a..bfe2dbea480b 100644
> --- a/net/xdp/xdp_umem.c
> +++ b/net/xdp/xdp_umem.c
> @@ -74,14 +74,14 @@ int xdp_umem_assign_dev(struct xdp_umem *umem, struct net_device *dev,
> return 0;
>
> if (!dev->netdev_ops->ndo_bpf || !dev->netdev_ops->ndo_xsk_async_xmit)
> - return force_zc ? -ENOTSUPP : 0; /* fail or fallback */
> + return force_zc ? -EOPNOTSUPP : 0; /* fail or fallback */
>
> bpf.command = XDP_QUERY_XSK_UMEM;
>
> rtnl_lock();
> err = xdp_umem_query(dev, queue_id);
> if (err) {
> - err = err < 0 ? -ENOTSUPP : -EBUSY;
> + err = err < 0 ? -EOPNOTSUPP : -EBUSY;
> goto err_rtnl_unlock;
> }
>
> --
> 2.17.1
>
>
Acked-by: Björn Töpel <bjorn.topel@intel.com>
^ permalink raw reply
* Re: [PATCH] wireless: Use dma_zalloc_coherent instead of dma_alloc_coherent + memset
From: zhong jiang @ 2018-08-20 10:53 UTC (permalink / raw)
To: Kalle Valo; +Cc: davem, linux-kernel, netdev
In-Reply-To: <87lg93ttkv.fsf@kamboji.qca.qualcomm.com>
On 2018/8/19 2:31, Kalle Valo wrote:
> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> zhong jiang <zhongjiang@huawei.com> writes:
>>
>>> dma_zalloc_coherent has implemented the dma_alloc_coherent() + memset (),
>>> We prefer to dma_zalloc_coherent instead of open-codeing.
>>>
>>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>>> ---
>>> drivers/net/wireless/ath/wcn36xx/dxe.c | 6 ++----
>>> 1 file changed, 2 insertions(+), 4 deletions(-)
>> The correct prefix is "wcn36xx: ", not "wireless:". I can fix it this
>> time.
>>
>> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong
> Actually please resend this patch and CC linux-wireless so that
> patchwork sees this.
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#who_to_address
>
Thanks. I will resend it in v2.
Best wishes,
zhong jiang
^ 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