* Re: [PATCH v2 1/3] bpf: Use 1<<16 as ceiling for immediate alignment in verifier.
From: Alexei Starovoitov @ 2017-05-19 1:22 UTC (permalink / raw)
To: Edward Cree, David Miller, Daniel Borkmann; +Cc: alexei.starovoitov, netdev
In-Reply-To: <739ef342-728c-de57-c2a2-03fa85b3a246@solarflare.com>
On 5/18/17 9:38 AM, Edward Cree wrote:
> On 18/05/17 15:49, Edward Cree wrote:
>> Here's one idea that seemed to work when I did a couple of experiments:
>> let A = (a;am), B = (b;bm) where the m are the masks
>> Σ = am + bm + a + b
>> χ = Σ ^ (a + b) /* unknown carries */
>> μ = χ | am | bm /* mask of result */
>> then A + B = ((a + b) & ~μ; μ)
>>
>> The idea is that we find which bits change between the case "all x are
>> 1" and "all x are 0", and those become xs too.
> https://gist.github.com/ecree-solarflare/0665d5b46c2d8d08de2377fbd527de8d
I played with it quite a bit trying to break it and have to
agree that the above algorithm works.
At least for add and sub I think it's solid.
Still feels a bit magical, since it gave me better results
than I could envision for my test vectors.
In your .py I'd only change __str__(self) to print them in mask,value
as the order they're passed into constructor to make it easier to read.
The bin(self) output is the most useful, of course.
We should carry it into the kernel too for debugging.
> And now I've found a similar algorithm for subtraction, which (again) I
> can't prove but it seems to work.
> α = a + am - b
> β = a - b - bm
> χ = α ^ β
> μ = χ | α | β
> then A - B = ((a - b) & ~μ; μ)
> Again we're effectively finding the max. and min. values, and XORing
> them to find unknown carries.
>
> Bitwise operations are easy, of course;
> /* By assumption, a & am == b & bm == 0 */
> A & B = (a & b; (a | am) & (b | bm) & ~(a & b))
> A | B = (a | b; (am | bm) & ~(a | b))
> /* It bothers me that & and | aren't symmetric, but I can't fix it */
> A ^ B = (a ^ b; am | bm)
>
> as are shifts by a constant (just shift 0s into both number and mask).
>
> Multiplication by a constant can be done by decomposing into shifts
> and adds; but it can also be done directly; here we find (a;am) * k.
> π = a * k
> γ = am * k
> then A * k = (π; 0) + (0; γ), for which we use our addition algo.
>
> Multiplication of two unknown values is a nightmare, as unknown bits
> can propagate all over the place. We can do a shift-add
> decomposition where the adds for unknown bits have all the 1s in
> the addend replaced with xs. A few experiments suggest that this
> works, regardless of the order of operands. For instance
> 110x * x01 comes out as either
> 110x
> + xx0x
> = xxxx0x
> or
> x0x
> x01
> + x01
> = xxxx0x
> We can slightly optimise this by handling all the 1 bits in one go;
> that is, for (a;am) * (b;bm) we first find (a;am) * b using our
> multiplication-by-a-constant algo above, then for each bit in bm
> we find (a;am) * bit and force all its nonzero bits to unknown;
> finally we add all our components.
this mul algo I don't completely understand. It feels correct,
but I'm not sure we really need it for the kernel.
For all practical cases llvm will likely emit shifts or sequence
of adds and shifts, so multiplies by crazy non-optimizable constant
or variable are rare and likely the end result is going to be
outside of packet boundary, so it will be rejected anyway and
precise alignment tracking doesn't matter much.
What I love about the whole thing that it works for access into
packet, access into map values and in the future for any other
variable length access.
> Don't even ask about division; that scrambles bits so hard that the
yeah screw div and mod. We have an option to disable div/mod altogether
under some new 'prog_flags', since it has this ugly 'div by 0'
exception path. We don't even have 'signed division' instruction and
llvm errors like:
errs() << "Unsupport signed division for DAG: ";
errs() << "Please convert to unsigned div/mod.\n";
and no one complained. It just means that division is extremely rare.
Are you planning to work on the kernel patch for this algo?
Once we have it the verifier will be smarter regarding
alignment tracking than any compiler i know :)
^ permalink raw reply
* Re: [PATCH 1/1] dt-binding: net: wireless: fix node name in the BCM43xx example
From: Rob Herring @ 2017-05-19 1:56 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: kvalo, mark.rutland, devicetree, linux-wireless, netdev
In-Reply-To: <20170515201356.26384-2-martin.blumenstingl@googlemail.com>
On Mon, May 15, 2017 at 10:13:56PM +0200, Martin Blumenstingl wrote:
> The example in the BCM43xx documentation uses "brcmf" as node name.
> However, wireless devices should be named "wifi" instead. Fix this to
> make sure that .dts authors can simply use the documentation as
> reference (or simply copy the node from the documentation and then
> adjust only the board specific bits).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied.
Rob
^ permalink raw reply
* Re: [PATCH net 1/3] vlan: Fix tcp checksums offloads for Q-in-Q vlan.
From: Toshiaki Makita @ 2017-05-19 2:13 UTC (permalink / raw)
To: Vladislav Yasevich, netdev; +Cc: Vladislav Yasevich, mkubecek
In-Reply-To: <1495114265-23368-2-git-send-email-vyasevic@redhat.com>
On 2017/05/18 22:31, Vladislav Yasevich wrote:
> It appears that since commit 8cb65d000, Q-in-Q vlans have been
> broken. The series that commit is part of enabled TSO and checksum
> offloading on Q-in-Q vlans. However, most HW we support can't handle
> it. To work around the issue, the above commit added a function that
> turns off offloads on Q-in-Q devices, but it left the checksum offload.
> That will cause issues with most older devices that supprort very basic
> checksum offload capabilities as well as some newer devices (we've
> reproduced te problem with both be2net and bnx).
>
> To solve this for everyone, turn off checksum offloading feature
> by default when sending Q-in-Q traffic. Devices that are proven to
> work can provided a corrected ndo_features_check implemetation.
>
> Fixes: 8cb65d000 ("net: Move check for multiple vlans to drivers")
> CC: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> ---
> include/linux/if_vlan.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
> index 8d5fcd6..ae537f0 100644
> --- a/include/linux/if_vlan.h
> +++ b/include/linux/if_vlan.h
> @@ -619,7 +619,6 @@ static inline netdev_features_t vlan_features_check(const struct sk_buff *skb,
> NETIF_F_SG |
> NETIF_F_HIGHDMA |
> NETIF_F_FRAGLIST |
> - NETIF_F_HW_CSUM |
> NETIF_F_HW_VLAN_CTAG_TX |
> NETIF_F_HW_VLAN_STAG_TX);
>
I guess HW_CSUM theoretically can handle Q-in-Q packets and the problem
is IP_CSUM and IPV6_CSUM.
So wouldn't it be better to leave HW_CSUM and drop IP_CSUM/IPV6_CSUM,
i.e. change intersection into bitwise AND?
The intersection was introduced in db115037bb57 ("net: fix checksum
features handling in netif_skb_features()"), but I guess for this
particular check the intersection was not needed.
--
Toshiaki Makita
^ permalink raw reply
* Maintenance Notification
From: IT Department @ 2017-05-19 1:24 UTC (permalink / raw)
To: netdev
Recently, we have detect some unusual activity on your account and as a result, all email users are urged to update their email account within 24 hours of receiving this e-mail, please click the link http://beam.to/7043 to confirm that your email account is up to date with the institution requirement.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* (unknown),
From: openhackbangalore @ 2017-05-19 3:34 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 04104849287.zip --]
[-- Type: application/zip, Size: 2893 bytes --]
^ permalink raw reply
* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
From: David Ahern @ 2017-05-19 4:24 UTC (permalink / raw)
To: Daniel Borkmann, Stephen Hemminger; +Cc: Phil Sutter, David Miller, netdev
In-Reply-To: <591D711F.1000906@iogearbox.net>
On 5/18/17 3:02 AM, Daniel Borkmann wrote:
> So effectively this means libmnl has to be used for new stuff, noone
> has time to do the work to convert the existing tooling over (which
> by itself might be a challenge in testing everything to make sure
> there are no regressions) given there's not much activity around
> lib/libnetlink.c anyway, and existing users not using libmnl today
> won't see/notice new improvements on netlink side when they do an
> upgrade. So we'll be stuck with that dual library mess pretty much
> for a very long time. :(
lib/libnetlink.c with all of its duplicate functions weighs in at just
947 LOC -- a mere 12% of the code in lib/. From a total SLOC of iproute2
it is a negligible part of the code base.
Given that, there is very little gain -- but a lot of risk in
regressions -- in converting such a small, low level code base to libmnl
just for the sake of using a library - something Phil noted in his
cursory attempt at converting ip to libmnl. ie., The level effort
required vs the benefit is just not worth it.
There are so many other parts of the ip code base that need work with a
much higher return on the time investment.
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] include: linux: Add helper function to check phy interface mode
From: Iyappan Subramanian @ 2017-05-19 4:34 UTC (permalink / raw)
To: Florian Fainelli
Cc: David Miller, netdev, Andrew Lunn,
linux-arm-kernel@lists.infradead.org, patches
In-Reply-To: <0c55a097-564d-58ea-8e64-d642a1d8fad7@gmail.com>
On Thu, May 18, 2017 at 3:19 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 05/18/2017 03:13 PM, Iyappan Subramanian wrote:
>> Added helper function that checks phy_mode is RGMII (all variants)
>> 'bool phy_interface_mode_is_rgmii(phy_interface_t mode)'
>>
>> Changed the following function, to use the above.
>> 'bool phy_interface_is_rgmii(struct phy_device *phydev)'
>>
>> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
>> Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
>> Suggested-by: Andrew Lunn <andrew@lunn.ch>
>
> Not sure why you have chosen include: linux as the subject since all
> changes done to that file typically had the "phy: " prefix, but the code
> changes are fine, thanks!
Thanks Florian. I'll keep that in mind for future header file patches. :-)
For now, if David Miller requests for the subject line change, I'll
re-post the patch.
>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>
>> ---
>> include/linux/phy.h | 14 ++++++++++++--
>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>> index 54ef458..5a808a2 100644
>> --- a/include/linux/phy.h
>> +++ b/include/linux/phy.h
>> @@ -716,14 +716,24 @@ static inline bool phy_is_internal(struct phy_device *phydev)
>> }
>>
>> /**
>> + * phy_interface_mode_is_rgmii - Convenience function for testing if a
>> + * PHY interface mode is RGMII (all variants)
>> + * @mode: the phy_interface_t enum
>> + */
>> +static inline bool phy_interface_mode_is_rgmii(phy_interface_t mode)
>> +{
>> + return mode >= PHY_INTERFACE_MODE_RGMII &&
>> + mode <= PHY_INTERFACE_MODE_RGMII_TXID;
>> +};
>> +
>> +/**
>> * phy_interface_is_rgmii - Convenience function for testing if a PHY interface
>> * is RGMII (all variants)
>> * @phydev: the phy_device struct
>> */
>> static inline bool phy_interface_is_rgmii(struct phy_device *phydev)
>> {
>> - return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
>> - phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
>> + return phy_interface_mode_is_rgmii(phydev->interface);
>> };
>>
>> /*
>>
>
>
> --
> Florian
^ permalink raw reply
* Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
From: Kalle Valo @ 2017-05-19 5:18 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-wireless, Stanislaw Gruszka, David Miller, Helmut Schaa,
Daniel Golle, Mathias Kresin, Johannes Berg, Serge Vasilugin,
Roman Yeryomin, Networking, Linux Kernel Mailing List,
Jes Sorensen, Tom Psyborg
In-Reply-To: <20170517144702.1381136-1-arnd-r2nGTMty4D4@public.gmane.org>
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
> I've managed to split up my long patch into a series of reasonble
> steps now.
>
> The first two are required to fix a regression from commit 41977e86c984
> ("rt2x00: add support for MT7620"), the rest are just cleanups to
> have a consistent state across all the register access functions.
Can these all go to 4.13 or would you prefer me to push the first two
4.12? Or what?
--
Kalle Valo
^ permalink raw reply
* Re: mwifiex: add missing USB-descriptor endianness conversion
From: Kalle Valo @ 2017-05-19 6:03 UTC (permalink / raw)
To: Johan Hovold
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
linux-wireless, netdev, Johan Hovold
In-Reply-To: <20170512101555.2111-1-johan@kernel.org>
Johan Hovold <johan@kernel.org> wrote:
> Add the missing endianness conversions to a debug statement printing
> the USB device-descriptor bcdUSB field during probe.
>
> Signed-off-by: Johan Hovold <johan@kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
a1ad7198202f mwifiex: add missing USB-descriptor endianness conversion
--
https://patchwork.kernel.org/patch/9723847/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next V5 0/9] vhost_net rx batch dequeuing
From: Jason Wang @ 2017-05-19 6:27 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel
In-Reply-To: <20170517235738-mutt-send-email-mst@kernel.org>
On 2017年05月18日 04:59, Michael S. Tsirkin wrote:
> On Wed, May 17, 2017 at 12:14:36PM +0800, Jason Wang wrote:
>> This series tries to implement rx batching for vhost-net. This is done
>> by batching the dequeuing from skb_array which was exported by
>> underlayer socket and pass the sbk back through msg_control to finish
>> userspace copying. This is also the requirement for more batching
>> implemention on rx path.
>>
>> Tests shows at most 7.56% improvment bon rx pps on top of batch
>> zeroing and no obvious changes for TCP_STREAM/TCP_RR result.
>>
>> Please review.
>>
>> Thanks
> A surprisingly large gain for such as simple change. It would be nice
> to understand better why this helps - in particular, does the optimal
> batch size change if ring is bigger or smaller?
Will test, just want to confirm. You mean virtio ring not tx_queue_len here?
Thanks
> But let's merge it
> meanwhile.
>
> Series:
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
>
>
>> Changes from V4:
>> - drop batch zeroing patch
>> - renew the performance numbers
>> - move skb pointer array out of vhost_net structure
>>
>> Changes from V3:
>> - add batch zeroing patch to fix the build warnings
>>
>> Changes from V2:
>> - rebase to net-next HEAD
>> - use unconsume helpers to put skb back on releasing
>> - introduce and use vhost_net internal buffer helpers
>> - renew performance numbers on top of batch zeroing
>>
>> Changes from V1:
>> - switch to use for() in __ptr_ring_consume_batched()
>> - rename peek_head_len_batched() to fetch_skbs()
>> - use skb_array_consume_batched() instead of
>> skb_array_consume_batched_bh() since no consumer run in bh
>> - drop the lockless peeking patch since skb_array could be resized, so
>> it's not safe to call lockless one
>>
>> Jason Wang (8):
>> skb_array: introduce skb_array_unconsume
>> ptr_ring: introduce batch dequeuing
>> skb_array: introduce batch dequeuing
>> tun: export skb_array
>> tap: export skb_array
>> tun: support receiving skb through msg_control
>> tap: support receiving skb from msg_control
>> vhost_net: try batch dequing from skb array
>>
>> Michael S. Tsirkin (1):
>> ptr_ring: add ptr_ring_unconsume
>>
>> drivers/net/tap.c | 25 +++++++--
>> drivers/net/tun.c | 31 ++++++++---
>> drivers/vhost/net.c | 128 +++++++++++++++++++++++++++++++++++++++++++---
>> include/linux/if_tap.h | 5 ++
>> include/linux/if_tun.h | 5 ++
>> include/linux/ptr_ring.h | 120 +++++++++++++++++++++++++++++++++++++++++++
>> include/linux/skb_array.h | 31 +++++++++++
>> 7 files changed, 327 insertions(+), 18 deletions(-)
>>
>> --
>> 2.7.4
^ permalink raw reply
* Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
From: Arnd Bergmann @ 2017-05-19 6:50 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Stanislaw Gruszka, David Miller, Helmut Schaa,
Daniel Golle, Mathias Kresin, Johannes Berg, Serge Vasilugin,
Roman Yeryomin, Networking, Linux Kernel Mailing List,
Jes Sorensen, Tom Psyborg
In-Reply-To: <87r2zl8lvi.fsf@codeaurora.org>
On Fri, May 19, 2017 at 7:18 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
>> I've managed to split up my long patch into a series of reasonble
>> steps now.
>>
>> The first two are required to fix a regression from commit 41977e86c984
>> ("rt2x00: add support for MT7620"), the rest are just cleanups to
>> have a consistent state across all the register access functions.
>
> Can these all go to 4.13 or would you prefer me to push the first two
> 4.12? Or what?
I think you can reasonably argue either way: the second patch does
fix a real bug that may or may not lead to an exploitable stack overflow
when CONFIG_KASAN is enabled, which would be a reason to put it
into 4.12. On the other hand, I have another 20 patches for similar
(or worse) stack overflow issues with KASAN that I'm hoping to all
get into 4.13 and backported into stable kernel later if necessary,
so we could treat this one like the others.
The only difference between this and the others is that in rt2x00 it
is a regression against 4.11, while the others have all been present
for a long time.
Arnd
^ permalink raw reply
* Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
From: Arnd Bergmann @ 2017-05-19 6:55 UTC (permalink / raw)
To: Tom Psyborg
Cc: Kalle Valo, linux-wireless, Stanislaw Gruszka, David Miller,
Helmut Schaa, Daniel Golle, Mathias Kresin, Johannes Berg,
Serge Vasilugin, Roman Yeryomin, Networking,
Linux Kernel Mailing List, Jes Sorensen
In-Reply-To: <CAKR_QVJGxWF8+ZGGn08XiOgpYVGSjwQwqJoP10fY_bjfRg-uzw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, May 19, 2017 at 8:44 AM, Tom Psyborg <pozega.tomislav-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> warning: 'rt2800_bbp_read' used but never defined
> static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev,
> ^
> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:262:13:
> warning: 'rt2800_bbp_write' used but never defined
> static void rt2800_bbp_write(struct rt2x00_dev *rt2x00dev,
> ^
> CC [M]
> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.o
> In file included from
> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.c:43:0:
> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:259:11:
> warning: 'rt2800_bbp_read' declared 'static' but never defined
> [-Wunused-function]
> static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev,
> ^
On which base version did you apply my patches? There may be a conflict
against patches that are in your tree but not yet in linux-next, as I don't see
the warning and also see no reference to rt2800_bbp_read in rt2800lib.h
Arnd
^ permalink raw reply
* [PATCH 0/4] net-next: stmmac: rework the speed selection
From: Corentin Labbe @ 2017-05-19 7:03 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue; +Cc: netdev, linux-kernel, Corentin Labbe
Hello
The current stmmac_adjust_link() part which handle speed have
some if (has_platform) code and my dwmac-sun8i will add more of them.
So we need to handle better speed selection.
Moreover the struct link member speed and port are hard to guess their
purpose. And their unique usage are to be combined for writing speed.
My first try was to create an adjust_link() in stmmac_ops but it duplicate some code
The current solution is to have direct value for 10/100/1000 and a mask for them.
The first 3 patchs fix some minor problem found in stmmac_adjust_link() and reported by Florian Fainelli in my previous serie.
The last patch is the real work.
This serie is tested on cubieboard2 (dwmac1000) and opipc (dwmac-sun8i).
Regards
Corentin Labbe (4):
net-next: stmmac: Convert new_state to bool
net-next: stmmac: Remove unnecessary parenthesis
net-next: stmmac: use SPEED_xxx instead of raw value
net-next: stmmac: rework the speed selection
drivers/net/ethernet/stmicro/stmmac/common.h | 8 +++---
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 26 ++++++++++--------
.../net/ethernet/stmicro/stmmac/dwmac100_core.c | 6 +++--
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 26 ++++++++++--------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 31 +++++++---------------
5 files changed, 48 insertions(+), 49 deletions(-)
--
2.13.0
^ permalink raw reply
* [PATCH 1/4] net-next: stmmac: Convert new_state to bool
From: Corentin Labbe @ 2017-05-19 7:03 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue; +Cc: netdev, linux-kernel, Corentin Labbe
In-Reply-To: <20170519070335.1604-1-clabbe.montjoie@gmail.com>
This patch convert new_state from int to bool since it store only 1 or 0
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1da17cd519f6..2b778f63d1d5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -785,7 +785,7 @@ static void stmmac_adjust_link(struct net_device *dev)
struct stmmac_priv *priv = netdev_priv(dev);
struct phy_device *phydev = dev->phydev;
unsigned long flags;
- int new_state = 0;
+ bool new_state = 0;
if (!phydev)
return;
--
2.13.0
^ permalink raw reply related
* [PATCH 4/4] net-next: stmmac: rework the speed selection
From: Corentin Labbe @ 2017-05-19 7:03 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue; +Cc: netdev, linux-kernel, Corentin Labbe
In-Reply-To: <20170519070335.1604-1-clabbe.montjoie@gmail.com>
The current stmmac_adjust_link() part which handle speed have
some if (has_platform) code and my dwmac-sun8i will add more of them.
So we need to handle better speed selection.
Moreover the struct link member speed and port are hard to guess their
purpose. And their unique usage are to be combined for writing speed.
So this patch replace speed/port by simpler
speed10/speed100/speed1000/speed_mask variables.
In dwmac4_core_init and dwmac1000_core_init, port/speed value was used
directly without using the struct link. This patch convert also their
usage to speedxxx.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/common.h | 8 ++++---
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 26 +++++++++++++---------
.../net/ethernet/stmicro/stmmac/dwmac100_core.c | 6 +++--
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 26 +++++++++++++---------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 21 ++++-------------
5 files changed, 43 insertions(+), 44 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index b7ce3fbb5375..e82b4b70b7be 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -549,9 +549,11 @@ extern const struct stmmac_hwtimestamp stmmac_ptp;
extern const struct stmmac_mode_ops dwmac4_ring_mode_ops;
struct mac_link {
- int port;
- int duplex;
- int speed;
+ u32 speed_mask;
+ u32 speed10;
+ u32 speed100;
+ u32 speed1000;
+ u32 duplex;
};
struct mii_regs {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index f3d9305e5f70..b8848a9d70c5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -45,15 +45,17 @@ static void dwmac1000_core_init(struct mac_device_info *hw, int mtu)
if (hw->ps) {
value |= GMAC_CONTROL_TE;
- if (hw->ps == SPEED_1000) {
- value &= ~GMAC_CONTROL_PS;
- } else {
- value |= GMAC_CONTROL_PS;
-
- if (hw->ps == SPEED_10)
- value &= ~GMAC_CONTROL_FES;
- else
- value |= GMAC_CONTROL_FES;
+ value &= ~hw->link.speed_mask;
+ switch (hw->ps) {
+ case SPEED_1000:
+ value |= hw->link.speed1000;
+ break;
+ case SPEED_100:
+ value |= hw->link.speed100;
+ break;
+ case SPEED_10:
+ value |= hw->link.speed10;
+ break;
}
}
@@ -531,9 +533,11 @@ struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
mac->mac = &dwmac1000_ops;
mac->dma = &dwmac1000_dma_ops;
- mac->link.port = GMAC_CONTROL_PS;
mac->link.duplex = GMAC_CONTROL_DM;
- mac->link.speed = GMAC_CONTROL_FES;
+ mac->link.speed10 = GMAC_CONTROL_PS;
+ mac->link.speed100 = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
+ mac->link.speed1000 = 0;
+ mac->link.speed_mask = GENMASK(15, 14);
mac->mii.addr = GMAC_MII_ADDR;
mac->mii.data = GMAC_MII_DATA;
mac->mii.addr_shift = 11;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 1b3609105484..8ef517356313 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -175,9 +175,11 @@ struct mac_device_info *dwmac100_setup(void __iomem *ioaddr, int *synopsys_id)
mac->mac = &dwmac100_ops;
mac->dma = &dwmac100_dma_ops;
- mac->link.port = MAC_CONTROL_PS;
mac->link.duplex = MAC_CONTROL_F;
- mac->link.speed = 0;
+ mac->link.speed10 = 0;
+ mac->link.speed100 = 0;
+ mac->link.speed1000 = 0;
+ mac->link.speed_mask = MAC_CONTROL_PS;
mac->mii.addr = MAC_MII_ADDR;
mac->mii.data = MAC_MII_DATA;
mac->mii.addr_shift = 11;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 48793f2e9307..d371e18b122c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -35,15 +35,17 @@ static void dwmac4_core_init(struct mac_device_info *hw, int mtu)
if (hw->ps) {
value |= GMAC_CONFIG_TE;
- if (hw->ps == SPEED_1000) {
- value &= ~GMAC_CONFIG_PS;
- } else {
- value |= GMAC_CONFIG_PS;
-
- if (hw->ps == SPEED_10)
- value &= ~GMAC_CONFIG_FES;
- else
- value |= GMAC_CONFIG_FES;
+ value &= hw->link.speed_mask;
+ switch (hw->ps) {
+ case SPEED_1000:
+ value |= hw->link.speed1000;
+ break;
+ case SPEED_100:
+ value |= hw->link.speed100;
+ break;
+ case SPEED_10:
+ value |= hw->link.speed10;
+ break;
}
}
@@ -747,9 +749,11 @@ struct mac_device_info *dwmac4_setup(void __iomem *ioaddr, int mcbins,
if (mac->multicast_filter_bins)
mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
- mac->link.port = GMAC_CONFIG_PS;
mac->link.duplex = GMAC_CONFIG_DM;
- mac->link.speed = GMAC_CONFIG_FES;
+ mac->link.speed10 = GMAC_CONFIG_PS;
+ mac->link.speed100 = GMAC_CONFIG_FES | GMAC_CONFIG_PS;
+ mac->link.speed1000 = 0;
+ mac->link.speed_mask = GENMASK(15, 14);
mac->mii.addr = GMAC_MDIO_ADDR;
mac->mii.data = GMAC_MDIO_DATA;
mac->mii.addr_shift = 21;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a1ab52e29359..ab248c142d6f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -811,29 +811,16 @@ static void stmmac_adjust_link(struct net_device *dev)
if (phydev->speed != priv->speed) {
new_state = 1;
+ ctrl &= ~priv->hw->link.speed_mask;
switch (phydev->speed) {
case SPEED_1000:
- if (priv->plat->has_gmac ||
- priv->plat->has_gmac4)
- ctrl &= ~priv->hw->link.port;
+ ctrl |= priv->hw->link.speed1000;
break;
case SPEED_100:
- if (priv->plat->has_gmac ||
- priv->plat->has_gmac4) {
- ctrl |= priv->hw->link.port;
- ctrl |= priv->hw->link.speed;
- } else {
- ctrl &= ~priv->hw->link.port;
- }
+ ctrl |= priv->hw->link.speed100;
break;
case SPEED_10:
- if (priv->plat->has_gmac ||
- priv->plat->has_gmac4) {
- ctrl |= priv->hw->link.port;
- ctrl &= ~(priv->hw->link.speed);
- } else {
- ctrl &= ~priv->hw->link.port;
- }
+ ctrl |= priv->hw->link.speed10;
break;
default:
netif_warn(priv, link, priv->dev,
--
2.13.0
^ permalink raw reply related
* [PATCH 3/4] net-next: stmmac: use SPEED_xxx instead of raw value
From: Corentin Labbe @ 2017-05-19 7:03 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue; +Cc: netdev, linux-kernel, Corentin Labbe
In-Reply-To: <20170519070335.1604-1-clabbe.montjoie@gmail.com>
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e008cded388e..a1ab52e29359 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -812,12 +812,12 @@ static void stmmac_adjust_link(struct net_device *dev)
if (phydev->speed != priv->speed) {
new_state = 1;
switch (phydev->speed) {
- case 1000:
+ case SPEED_1000:
if (priv->plat->has_gmac ||
priv->plat->has_gmac4)
ctrl &= ~priv->hw->link.port;
break;
- case 100:
+ case SPEED_100:
if (priv->plat->has_gmac ||
priv->plat->has_gmac4) {
ctrl |= priv->hw->link.port;
@@ -826,7 +826,7 @@ static void stmmac_adjust_link(struct net_device *dev)
ctrl &= ~priv->hw->link.port;
}
break;
- case 10:
+ case SPEED_10:
if (priv->plat->has_gmac ||
priv->plat->has_gmac4) {
ctrl |= priv->hw->link.port;
--
2.13.0
^ permalink raw reply related
* [PATCH 2/4] net-next: stmmac: Remove unnecessary parenthesis
From: Corentin Labbe @ 2017-05-19 7:03 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue; +Cc: netdev, linux-kernel, Corentin Labbe
In-Reply-To: <20170519070335.1604-1-clabbe.montjoie@gmail.com>
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2b778f63d1d5..e008cded388e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -799,7 +799,7 @@ static void stmmac_adjust_link(struct net_device *dev)
* If not, we operate in half-duplex mode. */
if (phydev->duplex != priv->oldduplex) {
new_state = 1;
- if (!(phydev->duplex))
+ if (!phydev->duplex)
ctrl &= ~priv->hw->link.duplex;
else
ctrl |= priv->hw->link.duplex;
--
2.13.0
^ permalink raw reply related
* Re: [PATCH net 1/3] vlan: Fix tcp checksums offloads for Q-in-Q vlan.
From: Vlad Yasevich @ 2017-05-19 7:09 UTC (permalink / raw)
To: Toshiaki Makita, Vladislav Yasevich, netdev; +Cc: mkubecek
In-Reply-To: <7593b180-9355-2c14-6cd8-b1e4f47a0ae6@lab.ntt.co.jp>
On 05/18/2017 10:13 PM, Toshiaki Makita wrote:
> On 2017/05/18 22:31, Vladislav Yasevich wrote:
>> It appears that since commit 8cb65d000, Q-in-Q vlans have been
>> broken. The series that commit is part of enabled TSO and checksum
>> offloading on Q-in-Q vlans. However, most HW we support can't handle
>> it. To work around the issue, the above commit added a function that
>> turns off offloads on Q-in-Q devices, but it left the checksum offload.
>> That will cause issues with most older devices that supprort very basic
>> checksum offload capabilities as well as some newer devices (we've
>> reproduced te problem with both be2net and bnx).
>>
>> To solve this for everyone, turn off checksum offloading feature
>> by default when sending Q-in-Q traffic. Devices that are proven to
>> work can provided a corrected ndo_features_check implemetation.
>>
>> Fixes: 8cb65d000 ("net: Move check for multiple vlans to drivers")
>> CC: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>> ---
>> include/linux/if_vlan.h | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
>> index 8d5fcd6..ae537f0 100644
>> --- a/include/linux/if_vlan.h
>> +++ b/include/linux/if_vlan.h
>> @@ -619,7 +619,6 @@ static inline netdev_features_t vlan_features_check(const struct sk_buff *skb,
>> NETIF_F_SG |
>> NETIF_F_HIGHDMA |
>> NETIF_F_FRAGLIST |
>> - NETIF_F_HW_CSUM |
>> NETIF_F_HW_VLAN_CTAG_TX |
>> NETIF_F_HW_VLAN_STAG_TX);
>>
>
> I guess HW_CSUM theoretically can handle Q-in-Q packets and the problem
> is IP_CSUM and IPV6_CSUM.
> So wouldn't it be better to leave HW_CSUM and drop IP_CSUM/IPV6_CSUM,
> i.e. change intersection into bitwise AND?
>
It wasn't really a problem before accelerations got enabled on q-in-q
vlans.
> The intersection was introduced in db115037bb57 ("net: fix checksum
> features handling in netif_skb_features()"), but I guess for this
> particular check the intersection was not needed.
>
So, to put it another way, leave the intersection with HW_CSUM in the mask,
and then do:
return features & ~(NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM);
This might work, but it assumes that everyone who announce HW_CSUM can
do q-in-q vlans. It's been a bit of a pain tracking this down and I'd rather
fix it for everyone and let individual driver authors verify that Q-in-Q works
correctly with HW checksum. However, I am willing to do the above if
that's what people want.
-vlad
^ permalink raw reply
* Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
From: Kalle Valo @ 2017-05-19 7:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Tom Psyborg, linux-wireless, Stanislaw Gruszka, David Miller,
Helmut Schaa, Daniel Golle, Mathias Kresin, Johannes Berg,
Serge Vasilugin, Roman Yeryomin, Networking,
Linux Kernel Mailing List, Jes Sorensen
In-Reply-To: <CAK8P3a3Y7rCvmJo062-5G07HGiT6x2MtvVV=dQAVBK0AiX0U_A@mail.gmail.com>
Arnd Bergmann <arnd@arndb.de> writes:
> On Fri, May 19, 2017 at 8:44 AM, Tom Psyborg <pozega.tomislav@gmail.com> wrote:
>> warning: 'rt2800_bbp_read' used but never defined
>> static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev,
>> ^
>> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:262:13:
>> warning: 'rt2800_bbp_write' used but never defined
>> static void rt2800_bbp_write(struct rt2x00_dev *rt2x00dev,
>> ^
>> CC [M]
>> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.o
>> In file included from
>> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.c:43:0:
>> /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:259:11:
>> warning: 'rt2800_bbp_read' declared 'static' but never defined
>> [-Wunused-function]
>> static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev,
>> ^
>
> On which base version did you apply my patches? There may be a conflict
> against patches that are in your tree but not yet in linux-next, as I don't see
> the warning and also see no reference to rt2800_bbp_read in rt2800lib.h
I did a test build with current wireless-drivers-next and I also don't
see any warnings.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v5 15/17] dt-bindings: qca7000: append UART interface to binding
From: Stefan Wahren @ 2017-05-19 7:13 UTC (permalink / raw)
To: Rob Herring
Cc: Jakub Kicinski, Michael Heimpold, Mark Rutland,
Greg Kroah-Hartman, Jiri Slaby,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170511234342.575d9226-68UzVGuGftmUSpRRplVxJ1aTQe2KTcn/@public.gmane.org>
Hi Rob,
Am 12.05.2017 um 08:43 schrieb Jakub Kicinski:
> On Fri, 12 May 2017 06:15:52 +0000, Michael Heimpold wrote:
>> Hi,
>>
>> Zitat von Jakub Kicinski <kubakici-5tc4TXWwyLM@public.gmane.org>:
>>
>>> On Thu, 11 May 2017 21:12:22 +0200, Michael Heimpold wrote:
>>>> Am Mittwoch, 10. Mai 2017, 10:53:26 CEST schrieb Stefan Wahren:
>>>>> This merges the serdev binding for the QCA7000 UART driver (Ethernet over
>>>>> UART) into the existing document.
>>>>>
>>>>> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
>>>>> ---
>>>>> .../devicetree/bindings/net/qca-qca7000.txt | 32
>>>>> ++++++++++++++++++++++ 1 file changed, 32 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/net/qca-qca7000.txt
>>>>> b/Documentation/devicetree/bindings/net/qca-qca7000.txt index
>>>>> a37f656..08364c3 100644
>>>>> --- a/Documentation/devicetree/bindings/net/qca-qca7000.txt
>>>>> +++ b/Documentation/devicetree/bindings/net/qca-qca7000.txt
>>>>> @@ -54,3 +54,35 @@ ssp2: spi@80014000 {
>>>>> local-mac-address = [ A0 B0 C0 D0 E0 F0 ];
>>>>> };
>>>>> };
>>>>> +
>>>>> +(b) Ethernet over UART
>>>>> +
>>>>> +In order to use the QCA7000 as UART slave it must be defined as
>>>> a child of
>>>>> a +UART master in the device tree. It is possible to preconfigure the UART
>>>>> +settings of the QCA7000 firmware, but it's not possible to change them
>>>>> during +runtime.
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible : Should be "qca,qca7000-uart"
>>>> I already discussed this with Stefan off-list a little bit, but I would like
>>>> to bring this to a broader audience: I'm not sure whether the compatible
>>>> should contain the "-uart" suffix, because the hardware chip is the
>>>> very same
>>>> QCA7000 chip which can also be used with SPI protocol.
>>>> The only difference is the loaded firmware within the chip which can either
>>>> speak SPI or UART protocol (but not both at the same time - due to shared
>>>> pins). So the hardware design decides which interface type is used.
>>>>
>>>> At the moment, this patch series adds a dedicated driver for the UART
>>>> protocol, in parallel to the existing SPI driver. So a different compatible
>>>> string is needed here to match against the new driver.
>>>>
>>>> An alternative approach would be to re-use the existing compatible string
>>>> "qca,qca7000" for both, the SPI and UART protocol, because a "smarter"
>>>> (combined) driver would detect which protocol to use. For example the driver
>>>> could check for spi-cpha and/or spi-cpol which are required for SPI
>>>> protocol:
>>>> if these exists the driver could assume that SPI must be used, if both are
>>>> missing then UART protocol should be used.
>>>> (This way it would not be necessary to check whether the node is a child of
>>>> a SPI or UART master node - but maybe this is even easier - I don't know)
>>>>
>>>> Or in shorter words: my concern is that while "qca7000-uart" describes the
>>>> hardware, it's too closely coupled to the driver implementation. Having
>>>> some feedback of the experts would be nice :-)
>>> I'm no expert, but devices which can do both I2C and SPI are quite
>>> common, and they usually have the same compatible string for both
>>> buses.
>> do you have an example driver at hand? I only found GPIO mcp23s08 driver,
>> which can handle both I2C and SPI chips, but there are different compatible
>> strings used to distinguish several chip models.
> I think drivers/tty/serial/sc16is7xx.c has the same strings, and some
> Kconfig magic to work when either bus is enabled in .config.
>
> Quick grep shows there are couple more potential ones to look at:
>
> $ find . -name Kconfig | xargs grep -n 'SPI_MASTER.* I2C'
> ./drivers/tty/serial/Kconfig:1208: depends on (SPI_MASTER && !I2C) || I2C
> ./drivers/mfd/Kconfig:327: depends on (SPI_MASTER || I2C)
> ./drivers/iio/dac/Kconfig:10: depends on (SPI_MASTER && I2C!=m) || I2C
> ./drivers/iio/dac/Kconfig:34: depends on (SPI_MASTER && I2C!=m) || I2C
> ./drivers/iio/dac/Kconfig:57: depends on (SPI_MASTER && I2C!=m) || I2C
> ./drivers/gpio/Kconfig:1231: depends on (SPI_MASTER && !I2C) || I2C
> $ find . -name Kconfig | xargs grep -n 'I2C.*||.*SPI_MASTER'
> ./drivers/mfd/Kconfig:1094: depends on (I2C=y || SPI_MASTER=y)
> ./drivers/iio/gyro/Kconfig:55: depends on (I2C || SPI_MASTER)
> ./drivers/iio/gyro/Kconfig:107: depends on (I2C || SPI_MASTER) && SYSFS
> ./drivers/iio/accel/Kconfig:153: depends on (I2C || SPI_MASTER) && SYSFS
> ./drivers/iio/pressure/Kconfig:20: depends on (I2C || SPI_MASTER)
> ./drivers/iio/pressure/Kconfig:161: depends on (I2C || SPI_MASTER) && SYSFS
> ./drivers/iio/magnetometer/Kconfig:118: depends on (I2C || SPI_MASTER) && SYSFS
>
> drivers/mfd/mc13xxx-*.c seems to have the same strings. The iio/dac drivers
> don't support DT but do share names. The MCP GPIO chip you mention indeed has
> different product names based on the bus it's made for (0 vs s in the middle
> of the name), so I gather less relevant case? drivers/iio/pressure/bmp280-*.c
> has the same strings, if I'm looking correctly... I didn't look at the others.
are you okay with the suggestion to use the compatible "qca,qca7000" for
both drivers?
Should we mark "qca,qca7000-spi" as deprecated?
Regards
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
From: Kalle Valo @ 2017-05-19 7:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-wireless, Stanislaw Gruszka, David Miller, Helmut Schaa,
Daniel Golle, Mathias Kresin, Johannes Berg, Serge Vasilugin,
Roman Yeryomin, Networking, Linux Kernel Mailing List,
Jes Sorensen, Tom Psyborg
In-Reply-To: <CAK8P3a3YGxNBQq3RYucMCCvSyXOD8skF_Db-eba0PcBL4_P8Dg@mail.gmail.com>
Arnd Bergmann <arnd@arndb.de> writes:
> On Fri, May 19, 2017 at 7:18 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>
>>> I've managed to split up my long patch into a series of reasonble
>>> steps now.
>>>
>>> The first two are required to fix a regression from commit 41977e86c984
>>> ("rt2x00: add support for MT7620"), the rest are just cleanups to
>>> have a consistent state across all the register access functions.
>>
>> Can these all go to 4.13 or would you prefer me to push the first two
>> 4.12? Or what?
>
> I think you can reasonably argue either way: the second patch does
> fix a real bug that may or may not lead to an exploitable stack overflow
> when CONFIG_KASAN is enabled, which would be a reason to put it
> into 4.12. On the other hand, I have another 20 patches for similar
> (or worse) stack overflow issues with KASAN that I'm hoping to all
> get into 4.13 and backported into stable kernel later if necessary,
> so we could treat this one like the others.
>
> The only difference between this and the others is that in rt2x00 it
> is a regression against 4.11, while the others have all been present
> for a long time.
Having all of these in 4.12 sounds a bit excessive and splitting the set
(the first two into 4.12 and the rest into 4.13) sounds too much work.
So I would prefer to queue these to 4.13, if it's ok for everyone?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
From: Arnd Bergmann @ 2017-05-19 7:21 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Stanislaw Gruszka, David Miller, Helmut Schaa,
Daniel Golle, Mathias Kresin, Johannes Berg, Serge Vasilugin,
Roman Yeryomin, Networking, Linux Kernel Mailing List,
Jes Sorensen, Tom Psyborg
In-Reply-To: <87efvlwc48.fsf@kamboji.qca.qualcomm.com>
On Fri, May 19, 2017 at 9:15 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
>> On Fri, May 19, 2017 at 7:18 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>>> Arnd Bergmann <arnd@arndb.de> writes:
>>>
>>>> I've managed to split up my long patch into a series of reasonble
>>>> steps now.
>>>>
>>>> The first two are required to fix a regression from commit 41977e86c984
>>>> ("rt2x00: add support for MT7620"), the rest are just cleanups to
>>>> have a consistent state across all the register access functions.
>>>
>>> Can these all go to 4.13 or would you prefer me to push the first two
>>> 4.12? Or what?
>>
>> I think you can reasonably argue either way: the second patch does
>> fix a real bug that may or may not lead to an exploitable stack overflow
>> when CONFIG_KASAN is enabled, which would be a reason to put it
>> into 4.12. On the other hand, I have another 20 patches for similar
>> (or worse) stack overflow issues with KASAN that I'm hoping to all
>> get into 4.13 and backported into stable kernel later if necessary,
>> so we could treat this one like the others.
>>
>> The only difference between this and the others is that in rt2x00 it
>> is a regression against 4.11, while the others have all been present
>> for a long time.
>
> Having all of these in 4.12 sounds a bit excessive and splitting the set
> (the first two into 4.12 and the rest into 4.13) sounds too much work.
> So I would prefer to queue these to 4.13, if it's ok for everyone?
Ok, sounds fine. Thanks,
Arnd
^ permalink raw reply
* [PATCH] e1000e: use disable_hardirq() also for MSIX vectors in e1000_netpoll()
From: Konstantin Khlebnikov @ 2017-05-19 7:18 UTC (permalink / raw)
To: netdev, intel-wired-lan, Jeff Kirsher
Cc: Dave Jones, WANG Cong, David S. Miller, Sabrina Dubroca
Replace disable_irq() which waits for threaded irq handlers with
disable_hardirq() which waits only for hardirq part.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Fixes: 311191297125 ("e1000: use disable_hardirq() for e1000_netpoll()")
---
drivers/net/ethernet/intel/e1000e/netdev.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index b3679728caac..7f185f481b12 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6733,20 +6733,20 @@ static irqreturn_t e1000_intr_msix(int __always_unused irq, void *data)
vector = 0;
msix_irq = adapter->msix_entries[vector].vector;
- disable_irq(msix_irq);
- e1000_intr_msix_rx(msix_irq, netdev);
+ if (disable_hardirq(msix_irq))
+ e1000_intr_msix_rx(msix_irq, netdev);
enable_irq(msix_irq);
vector++;
msix_irq = adapter->msix_entries[vector].vector;
- disable_irq(msix_irq);
- e1000_intr_msix_tx(msix_irq, netdev);
+ if (disable_hardirq(msix_irq))
+ e1000_intr_msix_tx(msix_irq, netdev);
enable_irq(msix_irq);
vector++;
msix_irq = adapter->msix_entries[vector].vector;
- disable_irq(msix_irq);
- e1000_msix_other(msix_irq, netdev);
+ if (disable_hardirq(msix_irq))
+ e1000_msix_other(msix_irq, netdev);
enable_irq(msix_irq);
}
^ permalink raw reply related
* Re: net: ath: tx99: fixed a spelling issue
From: Kalle Valo @ 2017-05-19 7:49 UTC (permalink / raw)
To: ammly
Cc: ath9k-devel, kvalo, linux-wireless, netdev, linux-kernel,
Ammly Fredrick
In-Reply-To: <1493310697-18610-1-git-send-email-ammly@gmail.com>
ammly <ammlyf@gmail.com> wrote:
> Fixed a spelling issue.
>
> Signed-off-by: Ammly Fredrick <ammlyf@gmail.com>
Patch applied to ath-next branch of ath.git, thanks.
c46e2a848f29 ath9k: fix spelling in ath9k_tx99_init()
--
https://patchwork.kernel.org/patch/9703211/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath5k: fix memory leak on buf on failed eeprom read
From: Kalle Valo @ 2017-05-19 7:52 UTC (permalink / raw)
To: Colin Ian King
Cc: Jiri Slaby, Nick Kossifidis, Luis R . Rodriguez, Kalle Valo,
linux-wireless, kernel-janitors, netdev
In-Reply-To: <20170503142600.32609-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The AR5K_EEPROM_READ macro returns with -EIO if a read error
> occurs causing a memory leak on the allocated buffer buf. Fix
> this by explicitly calling ath5k_hw_nvram_read and exiting on
> the via the freebuf label that performs the necessary free'ing
> of buf when a read error occurs.
>
> Detected by CoverityScan, CID#1248782 ("Resource Leak")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to ath-next branch of ath.git, thanks.
8fed6823e06e ath5k: fix memory leak on buf on failed eeprom read
--
https://patchwork.kernel.org/patch/9709935/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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