* Re: [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node
From: Kevin Easton @ 2018-05-08 8:27 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, kvm, virtualization, netdev, linux-kernel,
syzkaller-bugs
In-Reply-To: <20180507155534-mutt-send-email-mst@kernel.org>
On Mon, May 07, 2018 at 04:03:25PM +0300, Michael S. Tsirkin wrote:
> On Fri, Apr 27, 2018 at 11:45:02AM -0400, Kevin Easton wrote:
> > The struct vhost_msg within struct vhost_msg_node is copied to userspace,
> > so it should be allocated with kzalloc() to ensure all structure padding
> > is zeroed.
> >
> > Signed-off-by: Kevin Easton <kevin@guarana.org>
> > Reported-by: syzbot+87cfa083e727a224754b@syzkaller.appspotmail.com
> > ---
> > drivers/vhost/vhost.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index f3bd8e9..1b84dcff 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -2339,7 +2339,7 @@ EXPORT_SYMBOL_GPL(vhost_disable_notify);
> > /* Create a new message. */
> > struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
> > {
> > - struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
> > + struct vhost_msg_node *node = kzalloc(sizeof *node, GFP_KERNEL);
> > if (!node)
> > return NULL;
> > node->vq = vq;
>
>
> Let's just init the msg though.
>
> OK it seems this is the best we can do for now,
> we need a new feature bit to fix it for 32 bit
> userspace on 64 bit kernels.
>
> Does the following help?
Yes, the reproducer doesn't trigger the error with that patch applied.
- Kevin
^ permalink raw reply
* Re: RTL8723BE performance regression
From: Pkshih @ 2018-05-08 8:37 UTC (permalink / raw)
To: jprvita@gmail.com
Cc: linux-kernel@vger.kernel.org, Larry.Finger@lwfinger.net,
jprvita@endlessm.com, Birming Chiu, drake@endlessm.com,
Chaoming_Li, kvalo@codeaurora.org, 莊彥宣,
derosier@gmail.com, Steven Ting, netdev@vger.kernel.org,
linux@endlessm.com, Shaofu, linux-wireless@vger.kernel.org
In-Reply-To: <CA+A7VXWywjTVeb3DTjVMVTUw-vjAjD+3XTuVNk8S=8D7W=MkPQ@mail.gmail.com>
On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 1, 2018 at 10:58 PM, Pkshih <pkshih@realtek.com> wrote:
> > On Wed, 2018-05-02 at 05:44 +0000, Pkshih wrote:
> >>
> >> > -----Original Message-----
> >> > From: João Paulo Rechi Vita [mailto:jprvita@gmail.com]
> >> > Sent: Wednesday, May 02, 2018 6:41 AM
> >> > To: Larry Finger
> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; Chaoming_Li; Kalle Valo;
> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi Vita; linux@endless
> m.c
> >> om
> >> > Subject: Re: RTL8723BE performance regression
> >> >
> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >> > >>
> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <Larry.Finger@lwfinger.net>
> >> > >> wrote:
> >> > >>
> >> > >> (...)
> >> > >>
> >> > >>> As the antenna selection code changes affected your first bisection, do
> >> > >>> you
> >> > >>> have one of those HP laptops with only one antenna and the incorrect
> >> > >>> coding
> >> > >>> in the FUSE?
> >> > >>
> >> > >>
> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> > >> was needed to achieve a good performance in the past, before this
> >> > >> regression. I've also opened the laptop chassis and confirmed the
> >> > >> antenna cable is plugged to the connector labeled with "1" on the
> >> > >> card.
> >> > >>
> >> > >>> If so, please make sure that you still have the same signal
> >> > >>> strength for good and bad cases. I have tried to keep the driver and the
> >> > >>> btcoex code in sync, but there may be some combinations of antenna
> >> > >>> configuration and FUSE contents that cause the code to fail.
> >> > >>>
> >> > >>
> >> > >> What is the recommended way to monitor the signal strength?
> >> > >
> >> > >
> >> > > The btcoex code is developed for multiple platforms by a different group
> >> > > than the Linux driver. I think they made a change that caused ant_sel to
> >> > > switch from 1 to 2. At least numerous comments at
> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> >> > >
> >> > > Mhy recommended method is to verify the wifi device name with "iw dev". Then
> >> > > using that device
> >> > >
> >> > > sudo iw dev <dev_name> scan | egrep "SSID|signal"
> >> > >
> >> >
> >> > I have confirmed that the performance regression is indeed tied to
> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> >> > also switched to testing bandwidth in controlled LAN environment using
> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> >> > machine connected to the 2.4 GHz radio and the machine running the
> >> > iperf3 server connected via ethernet.
> >> >
> >>
> >> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup
> >> 8723be ant_sel definition"). You can use the above commit and do the same
> >> experiments (with ant_sel=0, 1 and 2) in your side, and then share your results.
> >> Since performance is tied to signal strength, you can only share signal strength.
> >>
> >
> > Please pay attention to cold reboot once ant_sel is changed.
> >
>
> I've tested the commit mentioned above and it fixes the problem on top
> of v4.16 (in addition to the latest wireless-drivers-next also been
> fixed as it already contains such commit). On v4.15, we also need the
> following commits before "af8a41cccf8f rtlwifi: cleanup 8723be ant_sel
> definition" to have a good performance again:
>
> 874e837d67d0 rtlwifi: fill FW version and subversion
> a44709bba70f rtlwifi: btcoex: Add power_on_setting routine
> 40d9dd4f1c5d rtlwifi: btcoex: Remove global variables from btcoex
v4.15 isn't longterm version and had been EOL.
>
> Surprisingly, it seems forcing ant_sel=1 is not needed anymore on
> these machines, as the shown by the numbers bellow (ant_sel=0 means
> that actually no parameter was passed to the module). I have powered
> off the machine and done a cold boot for every test. It seems
> something have changed in the antenna auto-selection code since v4.11,
> the latest point where I could confirm we definitely need to force
> ant_sel=1. I've been trying to understand what causes this difference,
> but haven't made progress on that so far, so any suggestions are
> appreciated (we are trying to decide if we can confidently drop the
> downstream DMI quirks for these specific machines).
>
I think your rtl8723be module programed correct efuse content, so it
works properly with ant_sel=0, and quirk isn't required for your
machine.
> w-d-n ant_sel=0: -14.00 dBm, 69.5 Mbps -> good
> w-d-n ant_sel=1: -10.00 dBm, 41.1 Mbps -> good
> w-d-n ant_sel=2: -44.00 dBm, 607 kbps -> bad
>
> v4.16 ant_sel=0: -12.00 dBm, 63.0 Mbps -> good
> v4.16 ant_sel=1: - 8.00 dBm, 69.0 Mbps -> good
> v4.16 ant_sel=2: -50.00 dBm, 224 kbps -> bad
>
> v4.15 ant_sel=0: - 8.00 dBm, 33.0 Mbps -> good
> v4.15 ant_sel=1: -10.00 dBm, 38.1 Mbps -> good
> v4.15 ant_sel=2: -48.00 dBm, 206 kbps -> bad
>
With your results, the efuse content is programmed as one or two antenna
on AUX path.
Regards,
PK
^ permalink raw reply
* pull-request: ieee802154 2018-05-08
From: Stefan Schmidt @ 2018-05-08 8:29 UTC (permalink / raw)
To: davem; +Cc: linux-wpan, alex.aring, netdev
Hello Dave.
An update from ieee802154 for your *net* tree.
Two fixes for the mcr20a driver, which was being added in the 4.17 merge window,
by Gustavo and myself.
The atusb driver got a change to GFP_KERNEL where no GFP_ATOMIC is needed by
Jia-Ju.
The last and most important fix is from Alex to get IPv6 reassembly working
again for the ieee802154 6lowpan adaptation. This got broken in 4.16 so please
queue this one also up for the 4.16 stable tree.
regards
Stefan Schmidt
The following changes since commit aa8f8778493c85fff480cdf8b349b1e1dcb5f243:
ipv6: add RTA_TABLE and RTA_PREFSRC to rtm_ipv6_policy (2018-04-23 12:01:21 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan.git ieee802154-for-davem-2018-05-08
for you to fetch changes up to f18fa5de5ba7f1d6650951502bb96a6e4715a948:
net: ieee802154: 6lowpan: fix frag reassembly (2018-04-23 20:56:24 +0200)
----------------------------------------------------------------
Alexander Aring (1):
net: ieee802154: 6lowpan: fix frag reassembly
Gustavo A. R. Silva (1):
ieee802154: mcr20a: Fix memory leak in mcr20a_probe
Jia-Ju Bai (1):
net: ieee802154: atusb: Replace GFP_ATOMIC with GFP_KERNEL in atusb_probe
Stefan Schmidt (1):
net: ieee802154: mcr20a: do not leak resources on error path
drivers/net/ieee802154/atusb.c | 2 +-
drivers/net/ieee802154/mcr20a.c | 15 ++++++++++-----
net/ieee802154/6lowpan/6lowpan_i.h | 4 ++--
net/ieee802154/6lowpan/reassembly.c | 14 +++++++-------
4 files changed, 20 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next v10 2/4] net: Introduce generic failover module
From: kbuild test robot @ 2018-05-08 9:02 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: kbuild-all, mst, stephen, davem, netdev, virtualization,
virtio-dev, jesse.brandeburg, alexander.h.duyck, kubakici,
sridhar.samudrala, jasowang, loseweigh, jiri, aaron.f.brown
In-Reply-To: <1525731046-10989-3-git-send-email-sridhar.samudrala@intel.com>
Hi Sridhar,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/Enable-virtio_net-to-act-as-a-standby-for-a-passthru-device/20180508-123531
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> net/core/net_failover.c:868:16: sparse: Using plain integer as NULL pointer
net/core/net_failover.c:115:12: sparse: context imbalance in 'net_failover_select_queue' - wrong count at exit
vim +868 net/core/net_failover.c
828
829 /**
830 * net_failover_register - Register a failover instance
831 *
832 * @dev: failover or standby netdev
833 * @ops: failover ops
834 *
835 * Paravirtual drivers supporting 3-netdev model call this routine indirectly
836 * via net_failover_create(). It passes failover netdev and ops will be NULL
837 * as the slave events are handled internally.
838 * Paravirtual drivers supporting 2-netdev model call this routine by passing
839 * standby netdev and ops that are called to handle slave register/unregister/
840 * link change events.
841 *
842 * Return: pointer to failover instance
843 */
844 struct net_failover *net_failover_register(struct net_device *dev,
845 struct net_failover_ops *ops)
846 {
847 struct net_failover *failover;
848
849 failover = kzalloc(sizeof(*failover), GFP_KERNEL);
850 if (!failover)
851 return ERR_PTR(-ENOMEM);
852
853 rcu_assign_pointer(failover->ops, ops);
854 dev_hold(dev);
855 dev->priv_flags |= IFF_FAILOVER;
856 rcu_assign_pointer(failover->failover_dev, dev);
857
858 spin_lock(&net_failover_lock);
859 list_add_tail(&failover->list, &net_failover_list);
860 spin_unlock(&net_failover_lock);
861
862 netdev_info(dev, "failover master:%s registered\n", dev->name);
863
864 net_failover_existing_slave_register(dev);
865
866 return failover;
867
> 868 return 0;
869 }
870 EXPORT_SYMBOL_GPL(net_failover_register);
871
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring
From: Tiwei Bie @ 2018-05-08 9:16 UTC (permalink / raw)
To: Jason Wang; +Cc: Michael S. Tsirkin, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <34f2c690-7cb2-f9ea-2ce9-40f4ccb594c9@redhat.com>
On Tue, May 08, 2018 at 03:16:53PM +0800, Jason Wang wrote:
> On 2018年05月08日 14:44, Tiwei Bie wrote:
> > On Tue, May 08, 2018 at 01:40:40PM +0800, Jason Wang wrote:
> > > On 2018年05月08日 11:05, Jason Wang wrote:
> > > > > Because in virtqueue_enable_cb_delayed(), we may set an
> > > > > event_off which is bigger than new and both of them have
> > > > > wrapped. And in this case, although new is smaller than
> > > > > event_off (i.e. the third param -- old), new shouldn't
> > > > > add vq->num, and actually we are expecting a very big
> > > > > idx diff.
> > > > Yes, so to calculate distance correctly between event and new, we just
> > > > need to compare the warp counter and return false if it doesn't match
> > > > without the need to try to add vq.num here.
> > > >
> > > > Thanks
> > > Sorry, looks like the following should work, we need add vq.num if
> > > used_wrap_counter does not match:
> > >
> > > static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
> > > __u16 off_wrap, __u16 new,
> > > __u16 old)
> > > {
> > > bool wrap = off_wrap >> 15;
> > > int off = off_wrap & ~(1 << 15);
> > > __u16 d1, d2;
> > >
> > > if (wrap != vq->used_wrap_counter)
> > > d1 = new + vq->num - off - 1;
> > Just to draw your attention (maybe you have already
> > noticed this).
>
> I miss this, thanks!
>
> >
> > In this case (i.e. wrap != vq->used_wrap_counter),
> > it's also possible that (off < new) is true. Because,
> >
> > when virtqueue_enable_cb_delayed_packed() is used,
> > `off` is calculated in driver in a way like this:
> >
> > off = vq->last_used_idx + bufs;
> > if (off >= vq->vring_packed.num) {
> > off -= vq->vring_packed.num;
> > wrap_counter ^= 1;
> > }
> >
> > And when `new` (in vhost) is close to vq->num. The
> > vq->last_used_idx + bufs (in driver) can be bigger
> > than vq->vring_packed.num, and:
> >
> > 1. `off` will wrap;
> > 2. wrap counters won't match;
> > 3. off < new;
> >
> > And d1 (i.e. new + vq->num - off - 1) will be a value
> > bigger than vq->num. I'm okay with this, although it's
> > a bit weird.
>
>
> So I'm considering something more compact by reusing vring_need_event() by
> pretending a larger queue size and adding vq->num back when necessary:
>
> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
> __u16 off_wrap, __u16 new,
> __u16 old)
> {
> bool wrap = vq->used_wrap_counter;
If the wrap counter is obtained from the vq,
I think `new` should also be obtained from
the vq. Or the wrap counter should be carried
in `new`.
> int off = off_wrap & ~(1 << 15);
> __u16 d1, d2;
>
> if (new < old) {
> new += vq->num;
> wrap ^= 1;
> }
>
> if (wrap != off_wrap >> 15)
> off += vq->num;
When `new` and `old` wraps, and `off` doesn't wrap,
wrap != (off_wrap >> 15) will be true. In this case,
`off` is bigger than `new`, and what we should do
is `off -= vq->num` instead of `off += vq->num`.
Best regards,
Tiwei Bie
>
> return vring_need_event(off, new, old);
> }
>
>
> >
> > Best regards,
> > Tiwei Bie
> >
> > > else
> > > d1 = new - off - 1;
> > >
> > > if (new > old)
> > > d2 = new - old;
> > > else
> > > d2 = new + vq->num - old;
> > >
> > > return d1 < d2;
> > > }
> > >
> > > Thanks
> > >
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH 1/7] can: dev: increase bus-off message severity
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Jakob Unterwurzacher, linux-kernel,
Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
bus-off is usually caused by hardware malfunction or configuration error
(baud rate mismatch) and causes a complete loss of communication.
Increase the "bus-off" message's severity from netdev_dbg() to
netdev_info() to make it visible to the user.
A can interface going into bus-off is similar in severity to ethernet's
"Link is Down" message, which is also printed at info level.
It is debatable whether the the "restarted" message should also be
changed to netdev_info() to make the interface state changes
comprehensible from the kernel log. I have chosen to keep the
"restarted" message at dbg for now as the "bus-off" message should be
enough for the user to notice and investigate the problem.
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@theobroma-systems.com>
Cc: linux-can@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index b1779566c5bb..3c71f1cb205f 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -605,7 +605,7 @@ void can_bus_off(struct net_device *dev)
{
struct can_priv *priv = netdev_priv(dev);
- netdev_dbg(dev, "bus-off\n");
+ netdev_info(dev, "bus-off\n");
netif_carrier_off(dev);
--
2.17.0
^ permalink raw reply related
* [PATCH 3/7] arm: dts: imx[35]*: declare flexcan devices to be compatible to imx25's flexcan
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Uwe Kleine-König, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Commit d50f4630c2e1 ("arm: dts: Remove p1010-flexcan compatible from imx
series dts") removed the fallback compatible "fsl,p1010-flexcan" from
the imx device trees. As the flexcan cores on i.MX25, i.MX35 and i.MX53
are identical, introduce the first as fallback for the two latter ones.
Fixes: d50f4630c2e1 ("arm: dts: Remove p1010-flexcan compatible from imx series dts")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: linux-stable <stable@vger.kernel.org> # >= v4.16
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
arch/arm/boot/dts/imx35.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index bf343195697e..54111ed218b1 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -303,7 +303,7 @@
};
can1: can@53fe4000 {
- compatible = "fsl,imx35-flexcan";
+ compatible = "fsl,imx35-flexcan", "fsl,imx25-flexcan";
reg = <0x53fe4000 0x1000>;
clocks = <&clks 33>, <&clks 33>;
clock-names = "ipg", "per";
@@ -312,7 +312,7 @@
};
can2: can@53fe8000 {
- compatible = "fsl,imx35-flexcan";
+ compatible = "fsl,imx35-flexcan", "fsl,imx25-flexcan";
reg = <0x53fe8000 0x1000>;
clocks = <&clks 34>, <&clks 34>;
clock-names = "ipg", "per";
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 7d647d043f52..3d65c0192f69 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -551,7 +551,7 @@
};
can1: can@53fc8000 {
- compatible = "fsl,imx53-flexcan";
+ compatible = "fsl,imx53-flexcan", "fsl,imx25-flexcan";
reg = <0x53fc8000 0x4000>;
interrupts = <82>;
clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>,
@@ -561,7 +561,7 @@
};
can2: can@53fcc000 {
- compatible = "fsl,imx53-flexcan";
+ compatible = "fsl,imx53-flexcan", "fsl,imx25-flexcan";
reg = <0x53fcc000 0x4000>;
interrupts = <83>;
clocks = <&clks IMX5_CLK_CAN2_IPG_GATE>,
--
2.17.0
^ permalink raw reply related
* [PATCH 4/7] can: kvaser_usb: Increase correct stats counter in kvaser_usb_rx_can_msg()
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Jimmy Assarsson, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Jimmy Assarsson <extja@kvaser.com>
Increase rx_dropped, if alloc_can_skb() fails, not tx_dropped.
Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/kvaser_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 63587b8e6825..daed57d3d209 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1179,7 +1179,7 @@ static void kvaser_usb_rx_can_msg(const struct kvaser_usb *dev,
skb = alloc_can_skb(priv->netdev, &cf);
if (!skb) {
- stats->tx_dropped++;
+ stats->rx_dropped++;
return;
}
--
2.17.0
^ permalink raw reply related
* pull-request: can 2018-05-08
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is a pull request for 7 patches for net/master.
The first patch is by Jakob Unterwurzacher and increases the severity of
bus-off messages in the generic CAN device infrastructure. The next two patches
are by Uwe Kleine-König and fix the endianess detection in the flexcan driver.
Jimmy Assarsson's patch for the kvaser driver corrects the stats counter for
dropped tx-messages. Geert Uytterhoeven provides one patch and Sergei Shtylyov
two patches for the rcan_canfd device tree binding description.
regards,
Marc
---
The following changes since commit 2c5d5b13c6eb79f5677e206b8aad59b3a2097f60:
llc: better deal with too small mtu (2018-05-08 00:11:40 -0400)
are available in the Git repository at:
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-4.17-20180508
for you to fetch changes up to 7a25ac2f71a409e77dd5c85cf3cbe1cbf2ae77f3:
DT: net: can: rcar_canfd: document R8A77980 bindings (2018-05-08 10:41:38 +0200)
----------------------------------------------------------------
linux-can-fixes-for-4.17-20180508
----------------------------------------------------------------
Geert Uytterhoeven (1):
dt-bindings: can: rcar_can: Fix R8A7796 SoC name
Jakob Unterwurzacher (1):
can: dev: increase bus-off message severity
Jimmy Assarsson (1):
can: kvaser_usb: Increase correct stats counter in kvaser_usb_rx_can_msg()
Sergei Shtylyov (2):
DT: net: can: rcar_canfd: document R8A77970 bindings
DT: net: can: rcar_canfd: document R8A77980 bindings
Uwe Kleine-König (2):
can: flexcan: fix endianess detection
arm: dts: imx[35]*: declare flexcan devices to be compatible to imx25's flexcan
.../devicetree/bindings/net/can/rcar_canfd.txt | 4 +++-
arch/arm/boot/dts/imx35.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
drivers/net/can/dev.c | 2 +-
drivers/net/can/flexcan.c | 26 ++++++++++++----------
drivers/net/can/usb/kvaser_usb.c | 2 +-
6 files changed, 23 insertions(+), 19 deletions(-)
^ permalink raw reply
* [PATCH 2/7] can: flexcan: fix endianess detection
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Uwe Kleine-König, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
In commit 88462d2a7830 ("can: flexcan: Remodel FlexCAN register r/w APIs
for big endian FlexCAN controllers.") the following logic was
implemented:
if the dt property "big-endian" is given or
the device is compatible to "fsl,p1010-flexcan":
use big-endian mode;
else
use little-endian mode;
This relies on commit d50f4630c2e1 ("arm: dts: Remove p1010-flexcan
compatible from imx series dts") which was applied a few commits later.
Without this commit (or an old device tree used for booting a new
kernel) the flexcan devices on i.MX25, i.MX28, i.MX35 and i.MX53 match
the 'the device is compatible to "fsl,p1010-flexcan"' test and so are
switched erroneously to big endian mode.
Instead of the check above put a quirk in devtype data and rely on
of_match_device yielding the most compatible match
Fixes: 88462d2a7830 ("can: flexcan: Remodel FlexCAN register r/w APIs for big endian FlexCAN controllers.")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Gavin Schenk <g.schenk@eckelmann.de>
Cc: linux-stable <stable@vger.kernel.org> # >= v4.16
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/flexcan.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 634c51e6b8ae..d53a45bf2a72 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -200,6 +200,7 @@
#define FLEXCAN_QUIRK_DISABLE_MECR BIT(4) /* Disable Memory error detection */
#define FLEXCAN_QUIRK_USE_OFF_TIMESTAMP BIT(5) /* Use timestamp based offloading */
#define FLEXCAN_QUIRK_BROKEN_PERR_STATE BIT(6) /* No interrupt for error passive */
+#define FLEXCAN_QUIRK_DEFAULT_BIG_ENDIAN BIT(7) /* default to BE register access */
/* Structure of the message buffer */
struct flexcan_mb {
@@ -287,6 +288,12 @@ struct flexcan_priv {
};
static const struct flexcan_devtype_data fsl_p1010_devtype_data = {
+ .quirks = FLEXCAN_QUIRK_BROKEN_WERR_STATE |
+ FLEXCAN_QUIRK_BROKEN_PERR_STATE |
+ FLEXCAN_QUIRK_DEFAULT_BIG_ENDIAN,
+};
+
+static const struct flexcan_devtype_data fsl_imx25_devtype_data = {
.quirks = FLEXCAN_QUIRK_BROKEN_WERR_STATE |
FLEXCAN_QUIRK_BROKEN_PERR_STATE,
};
@@ -1251,9 +1258,9 @@ static void unregister_flexcandev(struct net_device *dev)
static const struct of_device_id flexcan_of_match[] = {
{ .compatible = "fsl,imx6q-flexcan", .data = &fsl_imx6q_devtype_data, },
{ .compatible = "fsl,imx28-flexcan", .data = &fsl_imx28_devtype_data, },
- { .compatible = "fsl,imx53-flexcan", .data = &fsl_p1010_devtype_data, },
- { .compatible = "fsl,imx35-flexcan", .data = &fsl_p1010_devtype_data, },
- { .compatible = "fsl,imx25-flexcan", .data = &fsl_p1010_devtype_data, },
+ { .compatible = "fsl,imx53-flexcan", .data = &fsl_imx25_devtype_data, },
+ { .compatible = "fsl,imx35-flexcan", .data = &fsl_imx25_devtype_data, },
+ { .compatible = "fsl,imx25-flexcan", .data = &fsl_imx25_devtype_data, },
{ .compatible = "fsl,p1010-flexcan", .data = &fsl_p1010_devtype_data, },
{ .compatible = "fsl,vf610-flexcan", .data = &fsl_vf610_devtype_data, },
{ .compatible = "fsl,ls1021ar2-flexcan", .data = &fsl_ls1021a_r2_devtype_data, },
@@ -1337,18 +1344,13 @@ static int flexcan_probe(struct platform_device *pdev)
priv = netdev_priv(dev);
- if (of_property_read_bool(pdev->dev.of_node, "big-endian")) {
+ if (of_property_read_bool(pdev->dev.of_node, "big-endian") ||
+ devtype_data->quirks & FLEXCAN_QUIRK_DEFAULT_BIG_ENDIAN) {
priv->read = flexcan_read_be;
priv->write = flexcan_write_be;
} else {
- if (of_device_is_compatible(pdev->dev.of_node,
- "fsl,p1010-flexcan")) {
- priv->read = flexcan_read_be;
- priv->write = flexcan_write_be;
- } else {
- priv->read = flexcan_read_le;
- priv->write = flexcan_write_le;
- }
+ priv->read = flexcan_read_le;
+ priv->write = flexcan_write_le;
}
priv->can.clock.freq = clock_freq;
--
2.17.0
^ permalink raw reply related
* [PATCH 6/7] DT: net: can: rcar_canfd: document R8A77970 bindings
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Sergei Shtylyov, Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Document the R-Car V3M (R8A77970) SoC support in the R-Car CAN-FD bindings.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 1a4ee1d2506d..59dd13aab97f 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -6,6 +6,7 @@ Required properties:
- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
- "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller.
+ - "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
--
2.17.0
^ permalink raw reply related
* [PATCH 5/7] dt-bindings: can: rcar_can: Fix R8A7796 SoC name
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Geert Uytterhoeven, Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Geert Uytterhoeven <geert+renesas@glider.be>
R8A7796 is R-Car M3-W.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 93c3a6ae32f9..1a4ee1d2506d 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -5,7 +5,7 @@ Required properties:
- compatible: Must contain one or more of the following:
- "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
- - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3) compatible controller.
+ - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
--
2.17.0
^ permalink raw reply related
* [PATCH 7/7] DT: net: can: rcar_canfd: document R8A77980 bindings
From: Marc Kleine-Budde @ 2018-05-08 9:28 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Sergei Shtylyov, Marc Kleine-Budde
In-Reply-To: <20180508092831.28247-1-mkl@pengutronix.de>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Document the R-Car V3H (R8A77980) SoC support in the R-Car CAN-FD bindings.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
index 59dd13aab97f..ac71daa46195 100644
--- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -7,6 +7,7 @@ Required properties:
- "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
- "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller.
- "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller.
+ - "renesas,r8a77980-canfd" for R8A77980 (R-Car V3H) compatible controller.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first, followed by the
--
2.17.0
^ permalink raw reply related
* [PATCH] net/mlx4_en: Fix an error handling path in 'mlx4_en_init_netdev()'
From: Christophe JAILLET @ 2018-05-08 9:34 UTC (permalink / raw)
To: davem, tariqt
Cc: netdev, linux-rdma, linux-kernel, kernel-janitors,
Christophe JAILLET
If the 2nd memory allocation of the loop fails, we must undo the
memory allocation done so far.
Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index e0adac4a9a19..bf078244e467 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -3331,7 +3331,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
if (!priv->tx_cq[t]) {
kfree(priv->tx_ring[t]);
err = -ENOMEM;
- goto out;
+ goto err_free_tx;
}
}
priv->rx_ring_num = prof->rx_ring_num;
--
2.17.0
^ permalink raw reply related
* Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring
From: Jason Wang @ 2018-05-08 9:34 UTC (permalink / raw)
To: Tiwei Bie; +Cc: Michael S. Tsirkin, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <20180508091628.d7jzpopqopq4abhy@debian>
On 2018年05月08日 17:16, Tiwei Bie wrote:
> On Tue, May 08, 2018 at 03:16:53PM +0800, Jason Wang wrote:
>> On 2018年05月08日 14:44, Tiwei Bie wrote:
>>> On Tue, May 08, 2018 at 01:40:40PM +0800, Jason Wang wrote:
>>>> On 2018年05月08日 11:05, Jason Wang wrote:
>>>>>> Because in virtqueue_enable_cb_delayed(), we may set an
>>>>>> event_off which is bigger than new and both of them have
>>>>>> wrapped. And in this case, although new is smaller than
>>>>>> event_off (i.e. the third param -- old), new shouldn't
>>>>>> add vq->num, and actually we are expecting a very big
>>>>>> idx diff.
>>>>> Yes, so to calculate distance correctly between event and new, we just
>>>>> need to compare the warp counter and return false if it doesn't match
>>>>> without the need to try to add vq.num here.
>>>>>
>>>>> Thanks
>>>> Sorry, looks like the following should work, we need add vq.num if
>>>> used_wrap_counter does not match:
>>>>
>>>> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
>>>> __u16 off_wrap, __u16 new,
>>>> __u16 old)
>>>> {
>>>> bool wrap = off_wrap >> 15;
>>>> int off = off_wrap & ~(1 << 15);
>>>> __u16 d1, d2;
>>>>
>>>> if (wrap != vq->used_wrap_counter)
>>>> d1 = new + vq->num - off - 1;
>>> Just to draw your attention (maybe you have already
>>> noticed this).
>> I miss this, thanks!
>>
>>> In this case (i.e. wrap != vq->used_wrap_counter),
>>> it's also possible that (off < new) is true. Because,
>>>
>>> when virtqueue_enable_cb_delayed_packed() is used,
>>> `off` is calculated in driver in a way like this:
>>>
>>> off = vq->last_used_idx + bufs;
>>> if (off >= vq->vring_packed.num) {
>>> off -= vq->vring_packed.num;
>>> wrap_counter ^= 1;
>>> }
>>>
>>> And when `new` (in vhost) is close to vq->num. The
>>> vq->last_used_idx + bufs (in driver) can be bigger
>>> than vq->vring_packed.num, and:
>>>
>>> 1. `off` will wrap;
>>> 2. wrap counters won't match;
>>> 3. off < new;
>>>
>>> And d1 (i.e. new + vq->num - off - 1) will be a value
>>> bigger than vq->num. I'm okay with this, although it's
>>> a bit weird.
>>
>> So I'm considering something more compact by reusing vring_need_event() by
>> pretending a larger queue size and adding vq->num back when necessary:
>>
>> static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
>> __u16 off_wrap, __u16 new,
>> __u16 old)
>> {
>> bool wrap = vq->used_wrap_counter;
> If the wrap counter is obtained from the vq,
> I think `new` should also be obtained from
> the vq. Or the wrap counter should be carried
> in `new`.
>
>> int off = off_wrap & ~(1 << 15);
>> __u16 d1, d2;
>>
>> if (new < old) {
>> new += vq->num;
>> wrap ^= 1;
>> }
>>
>> if (wrap != off_wrap >> 15)
>> off += vq->num;
> When `new` and `old` wraps, and `off` doesn't wrap,
> wrap != (off_wrap >> 15) will be true. In this case,
> `off` is bigger than `new`, and what we should do
> is `off -= vq->num` instead of `off += vq->num`.
If I understand this correctly, if we track old correctly, it won't
happen if guest driver behave correctly. That means it should only
happen for a buggy driver (e.g trying to move off_wrap back).
Thanks
>
> Best regards,
> Tiwei Bie
>
>> return vring_need_event(off, new, old);
>> }
>>
>>
>>> Best regards,
>>> Tiwei Bie
>>>
>>>> else
>>>> d1 = new - off - 1;
>>>>
>>>> if (new > old)
>>>> d2 = new - old;
>>>> else
>>>> d2 = new + vq->num - old;
>>>>
>>>> return d1 < d2;
>>>> }
>>>>
>>>> Thanks
>>>>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC PATCH 1/3] arcnet: com20020: Add memory map of com20020
From: Andrea Greco @ 2018-05-08 9:36 UTC (permalink / raw)
To: Tobin C. Harding
Cc: m.grzeschik, Andrea Greco, Rob Herring, Mark Rutland, netdev,
devicetree, linux-kernel
In-Reply-To: <20180507025503.GF4197@eros>
On 05/07/2018 04:55 AM, Tobin C. Harding wrote:
> On Sat, May 05, 2018 at 11:34:45PM +0200, Andrea Greco wrote:
>> From: Andrea Greco <a.greco@4sigma.it>
>
> Hi Andrea,
>
> Here are some (mostly stylistic) suggestions to help you get your driver merged.
>
>> Add support for com20022I/com20020, memory mapped chip version.
>> Support bus: Intel 80xx and Motorola 68xx.
>> Bus size: Only 8 bit bus size is supported.
>> Added related device tree bindings
>>
>> Signed-off-by: Andrea Greco <a.greco@4sigma.it>
>> ---
>> .../devicetree/bindings/net/smsc-com20020.txt | 23 +++
>> drivers/net/arcnet/Kconfig | 12 +-
>> drivers/net/arcnet/Makefile | 1 +
>> drivers/net/arcnet/arcdevice.h | 27 ++-
>> drivers/net/arcnet/com20020-membus.c | 191 +++++++++++++++++++++
>> drivers/net/arcnet/com20020.c | 9 +-
>> 6 files changed, 253 insertions(+), 10 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/net/smsc-com20020.txt
>> create mode 100644 drivers/net/arcnet/com20020-membus.c
>>
>> diff --git a/Documentation/devicetree/bindings/net/smsc-com20020.txt b/Documentation/devicetree/bindings/net/smsc-com20020.txt
>> new file mode 100644
>> index 000000000000..39c5b19c55af
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/smsc-com20020.txt
>> @@ -0,0 +1,23 @@
>> +SMSC com20020, com20022I
>> +
>> +timeout: Arcnet timeout, checkout datashet
>> +clockp: Clock Prescaler, checkout datashet
>> +clockm: Clock multiplier, checkout datasheet
>> +
>> +phy-reset-gpios: Chip reset ppin
>> +phy-irq-gpios: Chip irq pin
ppin Corrected by my-self.
>> +
>> +com20020_A@0 {
>> + compatible = "smsc,com20020";
>> +
>> + timeout = <0x3>;
>> + backplane = <0x0>;
>> +
>> + clockp = <0x0>;
>> + clockm = <0x3>;
>> +
>> + phy-reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>;
>> + phy-irq-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
>> +
>> + status = "okay";
>> +};
>> diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
>> index 39bd16f3f86d..d39faf45be1e 100644
>> --- a/drivers/net/arcnet/Kconfig
>> +++ b/drivers/net/arcnet/Kconfig
>> @@ -3,7 +3,7 @@
>> #
>>
>> menuconfig ARCNET
>> - depends on NETDEVICES && (ISA || PCI || PCMCIA)
>> + depends on NETDEVICES
>> tristate "ARCnet support"
>> ---help---
>> If you have a network card of this type, say Y and check out the
>> @@ -129,5 +129,15 @@ config ARCNET_COM20020_CS
>>
>> To compile this driver as a module, choose M here: the module will be
>> called com20020_cs. If unsure, say N.
>> +config ARCNET_COM20020_MEMORY_BUS
>> + bool "Support for COM20020 on external memory"
>> + depends on ARCNET_COM20020 && !(ARCNET_COM20020_PCI || ARCNET_COM20020_ISA || ARCNET_COM20020_CS)
>> + help
>> + Say Y here if on your custom board mount com20020 or friends.
>> +
>> + Com20022I support arcnet bus 10Mbitps.
>> + This driver support only 8bit
>
> This driver only supports 8bit bus size.
>
>> , and DMA is not supported is attached on your board at external interface bus.
>
> This bit does not make sense, sorry.
Removed description,
Proposal for v2:
Say Y here if your custom board mount com20020 chipset or friends.
Supported Chipset: com20020, com20022, com20022I-3v3.
If unsure, say N.
>> + Supported bus Intel80xx / Motorola 68xx.
>> + This driver not work with other com20020 module: PCI or PCMCIA compiled as [M].
>
> I'm not sure exactly what you want to say here, perhaps:
>
> This driver does not work with other com20020 modules compiled
> as PCI or PCMCIA [M].
About this, all removed from kconfig
For PCI, PCMCIA, checkout downside
>>
>> endif # ARCNET
>> diff --git a/drivers/net/arcnet/Makefile b/drivers/net/arcnet/Makefile
>> index 53525e8ea130..19425c1e06f4 100644
>> --- a/drivers/net/arcnet/Makefile
>> +++ b/drivers/net/arcnet/Makefile
>> @@ -14,3 +14,4 @@ obj-$(CONFIG_ARCNET_COM20020) += com20020.o
>> obj-$(CONFIG_ARCNET_COM20020_ISA) += com20020-isa.o
>> obj-$(CONFIG_ARCNET_COM20020_PCI) += com20020-pci.o
>> obj-$(CONFIG_ARCNET_COM20020_CS) += com20020_cs.o
>> +obj-$(CONFIG_ARCNET_COM20020_MEMORY_BUS) += com20020-membus.o
>> diff --git a/drivers/net/arcnet/arcdevice.h b/drivers/net/arcnet/arcdevice.h
>> index d09b2b46ab63..16c608269cca 100644
>> --- a/drivers/net/arcnet/arcdevice.h
>> +++ b/drivers/net/arcnet/arcdevice.h
>> @@ -201,7 +201,7 @@ struct ArcProto {
>> void (*rx)(struct net_device *dev, int bufnum,
>> struct archdr *pkthdr, int length);
>> int (*build_header)(struct sk_buff *skb, struct net_device *dev,
>> - unsigned short ethproto, uint8_t daddr);
>> + unsigned short ethproto, uint8_t daddr);
>
> + unsigned short ethproto, uint8_t daddr);
>
> Please use Linux coding style style, parameters continuing on separate
> line are aligned with opening parenthesis.
>
>> /* these functions return '1' if the skb can now be freed */
>> int (*prepare_tx)(struct net_device *dev, struct archdr *pkt,
>> @@ -326,9 +326,9 @@ struct arcnet_local {
>> void (*recontrigger) (struct net_device * dev, int enable);
>>
>> void (*copy_to_card)(struct net_device *dev, int bufnum,
>> - int offset, void *buf, int count);
>> + int offset, void *buf, int count);
>> void (*copy_from_card)(struct net_device *dev, int bufnum,
>> - int offset, void *buf, int count);
>> + int offset, void *buf, int count);
>> } hw;
>>
>> void __iomem *mem_start; /* pointer to ioremap'ed MMIO */
>> @@ -360,7 +360,7 @@ struct net_device *alloc_arcdev(const char *name);
>> int arcnet_open(struct net_device *dev);
>> int arcnet_close(struct net_device *dev);
>> netdev_tx_t arcnet_send_packet(struct sk_buff *skb,
>> - struct net_device *dev);
>> + struct net_device *dev);
>> void arcnet_timeout(struct net_device *dev);
Not required modification then all removed.
>>
>> /* I/O equivalents */
>> @@ -371,7 +371,23 @@ void arcnet_timeout(struct net_device *dev);
>> #define BUS_ALIGN 1
>> #endif
>>
>> -/* addr and offset allow register like names to define the actual IO address.
>> +#ifdef CONFIG_ARCNET_COM20020_MEMORY_BUS
>> +#define arcnet_inb(addr, offset) \
>> + ioread8((void __iomem *)(addr) + BUS_ALIGN * (offset))
>> +
>> +#define arcnet_outb(value, addr, offset) \
>> + iowrite8(value, (void __iomem *)(addr) + BUS_ALIGN * (offset))
>> +
>> +#define arcnet_insb(addr, offset, buffer, count) \
>> + ioread8_rep((void __iomem *) \
>> + (addr) + BUS_ALIGN * (offset), buffer, count)
>> +
>> +#define arcnet_outsb(addr, offset, buffer, count) \
>> + iowrite8_rep((void __iomem *) \
>> + (addr) + BUS_ALIGN * (offset), buffer, count)
>> +#else
>> +/**
>> + * addr and offset allow register like names to define the actual IO address.
>> * A configuration option multiplies the offset for alignment.
>> */
>> #define arcnet_inb(addr, offset) \
>> @@ -388,6 +404,7 @@ void arcnet_timeout(struct net_device *dev);
>> readb((addr) + (offset))
>> #define arcnet_writeb(value, addr, offset) \
>> writeb(value, (addr) + (offset))
>> +#endif
>>
>> #endif /* __KERNEL__ */
>> #endif /* _LINUX_ARCDEVICE_H */
This is most important part where a suggestion will be very appreciated.
This part define how arcnet drivers read and write over physical.
The old driver can always use readb/writeb and friends, this driver rise
big kernel panic.
This driver make a ioreamp with: devm_ioremap.
Then, for r/w operation i use ioread8/iowrite8 and friends.
My quickly solution was make a ugly #ifdef.
With #ifndef all other driver implementation could not be used together
this driver, because break, how driver write over physical.
A proposal could be add a read/write callback to arcdevice.h struct hw.
PROS:
Every driver fill this callback, this is a solution.
CONS:
This solution require a small change for all com20020 driver
implementations. I don't dispose of all hardware for make a accurate
test. I could only test memory bus version.
Any other ideas, will be very appreciated.
>> diff --git a/drivers/net/arcnet/com20020-membus.c b/drivers/net/arcnet/com20020-membus.c
>> new file mode 100644
>> index 000000000000..6e4a2f3a84f7
>> --- /dev/null
>> +++ b/drivers/net/arcnet/com20020-membus.c
>> @@ -0,0 +1,191 @@
>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>> +/* Linux ARCnet driver for com 20020.
>> + *
>> + * This datasheet:
>> + * http://ww1.microchip.com/downloads/en/DeviceDoc/200223vrevc.pdf
>> + * http://ww1.microchip.com/downloads/en/DeviceDoc/20020.pdf
>> + *
>> + * This driver support:
>
> * This driver supports:
>
>> + * - com20020,
>> + * - com20022
>> + * - com20022I-3v3
>> + *
>> + * This driver support only, 8bit read and write.
>
> * This driver supports only 8bit read and write.
>
>> + * DMA is not supported by this driver.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/types.h>
>> +#include <linux/device.h>
>> +#include <linux/kernel.h>
>> +#include <linux/errno.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/netdevice.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_gpio.h>
>> +#include <linux/sizes.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/ioport.h>
>> +#include <linux/random.h>
>> +
>> +#include <linux/delay.h>
>> +#include "arcdevice.h"
>> +#include "com20020.h"
>
> White space line is not needed here, you might have meant to have it one
> line down?
>
Removed
>> +
>> +#define VERSION "arcnet: COM20020 MEMORY BUS support loaded.\n"
>> +
>> +static int com20020_probe(struct platform_device *pdev)
>> +{
>> + struct device_node *np;
>> + struct net_device *dev;
>> + struct arcnet_local *lp;
>> + struct resource res, *iores;
>> + int ret, phy_reset, err;
>> + u32 timeout, backplane, clockp, clockm;
>> + void __iomem *ioaddr;
>> +
>> + np = pdev->dev.of_node;
>> +
>> + iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +
>> + if (of_address_to_resource(np, 0, &res))
>> + return -EINVAL;
>> +
>> + ret = of_property_read_u32(np, "timeout", &timeout);
>> + if (ret) {
>> + dev_err(&pdev->dev, "timeout is required param");
>> + return ret;
>> + }
>> +
>> + ret = of_property_read_u32(np, "backplane", &backplane);
>> + if (ret) {
>> + dev_err(&pdev->dev, "backplane is required param");
>> + return ret;
>> + }
>> +
>> + ret = of_property_read_u32(np, "clockp", &clockp);
>> + if (ret) {
>> + dev_err(&pdev->dev, "clockp is required param");
>> + return ret;
>> + }
>> +
>> + ret = of_property_read_u32(np, "clockm", &clockm);
>> + if (ret) {
>> + dev_err(&pdev->dev, "clockm is required param");
>> + return ret;
>> + }
>> +
>> + phy_reset = of_get_named_gpio(np, "phy-reset-gpios", 0);
>> + if (phy_reset == -EPROBE_DEFER) {
>> + return phy_reset;
>> + } else if (!gpio_is_valid(phy_reset)) {
>> + dev_err(&pdev->dev, "phy-reset-gpios not valid !");
>> + return 0;
>> + }
>> +
>> + err = devm_gpio_request_one(&pdev->dev, phy_reset, GPIOF_OUT_INIT_LOW,
>> + "arcnet-phy-reset");
>> + if (err) {
>> + dev_err(&pdev->dev, "failed to get phy-reset-gpios: %d\n", err);
>> + return err;
>> + }
>> +
>> + dev = alloc_arcdev(NULL);// Let autoassign name arc%d
>
> /* C89 style comments please */
All comment bring to C89
>
>> + dev->netdev_ops = &com20020_netdev_ops;
>> + lp = netdev_priv(dev);
>> +
>> + lp->card_flags = ARC_CAN_10MBIT;/* pretend all of them can 10Mbit */
>> +
>> + // Force address to 0
>
Removed
> Unnecessary, we can see this in the code :) Please don't comment 'what'
> the code does (unless it is obfuscated or difficult to read). You may
> still like to comment 'why' the code does what it does though.
>
>> + // Will be set by user with `ip set dev arc0 address YOUR_NODE_ID`
>> + dev->dev_addr[0] = 0;
>> +
All this become
/* Will be set by userspace during if setup */
>> + // request to system this memory region
>
> Same as above
>
Removed
>> + if (!devm_request_mem_region(&pdev->dev, res.start, resource_size(&res),
>> + lp->card_name))
>> + return -EBUSY;
>> +
>> + ioaddr = devm_ioremap(&pdev->dev, iores->start, resource_size(iores));
>> + if (!ioaddr) {
>> + dev_err(&pdev->dev, "ioremap fallied\n");
>> + return -ENOMEM;
>> + }
>> +
>> + // Reset time is 5 * xTalFreq, minimal xtal is 10Mhz
>> + // (5 * 1000) / 10Mhz = 500ns
>
> perhaps a macro definition
> #define MAX_XTAL_RESET_TIME ??
Macro made, on head of file.
Rereading Datasheet maby that last delay could be removed.
Then become
gpio_set_value_cansleep(phy_reset, 0);
ndelay(RESET_DELAY);
gpio_set_value_cansleep(phy_reset, 1);
>> +
>> + gpio_set_value_cansleep(phy_reset, 0);
>> + ndelay(500);
>> + gpio_set_value_cansleep(phy_reset, 1);
>> + ndelay(500);
>> +
>> + /* Dummy access after Reset
>> + * ARCNET controller needs
>> + * this access to detect bustype
>> + */
>
> nit: Upto 72 characters wide is fine for comments
>
> /* Dummy access after Reset ARCNET controller needs
> * this access to detect bustype
> */
>
>> + arcnet_outb(0x00, ioaddr, COM20020_REG_W_COMMAND);
>> + arcnet_inb(ioaddr, COM20020_REG_R_DIAGSTAT);
>> +
Changed in:
/* ARCNET controller needs this access to detect bustype */
arcnet_outb(0x00, ioaddr, COM20020_REG_W_COMMAND);
arcnet_inb(ioaddr, COM20020_REG_R_DIAGSTAT);
>> + dev->base_addr = (unsigned long)ioaddr;
>> + get_random_bytes(dev->dev_addr, sizeof(u8));
>> +
>> + dev->irq = of_get_named_gpio(np, "phy-irq-gpios", 0);
>> + if (dev->irq == -EPROBE_DEFER) {
>> + return dev->irq;
>> + } else if (!gpio_is_valid(dev->irq)) {
>> + dev_err(&pdev->dev, "phy-irq-gpios not valid !");
>> + return 0;
>> + }
>> + dev->irq = gpio_to_irq(dev->irq);
>> +
>> + lp->backplane = backplane;
>> + lp->clockp = clockp & 7;
>> + lp->clockm = clockm & 3;
>> + lp->timeout = timeout;
>> + lp->hw.owner = THIS_MODULE;
>> +
>> + if (arcnet_inb(ioaddr, COM20020_REG_R_STATUS) == 0xFF) {
>> + ret = -EIO;
>> + goto err_release_mem;
>> + }
>> +
>> + if (com20020_check(dev)) {
>> + ret = -EIO;
>> + goto err_release_mem;
>> + }
>> +
>> + ret = com20020_found(dev, IRQF_TRIGGER_FALLING);
>> + if (ret)
>> + goto err_release_mem;
>> +
>> + dev_dbg(&pdev->dev, "probe Done\n");
>> + return 0;
>> +
>> +err_release_mem:
>> + devm_iounmap(&pdev->dev, (void __iomem *)ioaddr);
>> + devm_release_mem_region(&pdev->dev, res.start, resource_size(&res));
>> + dev_err(&pdev->dev, "probe failed!\n");
>> + return ret;
>> +}
>> +
>> +static const struct of_device_id of_com20020_match[] = {
>> + { .compatible = "smsc,com20020", },
>> + { },
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, of_com20020_match);
>> +
>> +static struct platform_driver of_com20020_driver = {
>> + .driver = {
>> + .name = "com20020-memory-bus",
>> + .of_match_table = of_com20020_match,
>> + },
>> + .probe = com20020_probe,
>> +};
>> +
>> +static int com20020_init(void)
>> +{
>> + return platform_driver_register(&of_com20020_driver);
>> +}
>> +late_initcall(com20020_init);
>> +
>> +MODULE_LICENSE("GPL");
>> diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
>> index 78043a9c5981..f09ea77dd6a8 100644
>> --- a/drivers/net/arcnet/com20020.c
>> +++ b/drivers/net/arcnet/com20020.c
>> @@ -43,7 +43,7 @@
>> #include "com20020.h"
>>
>> static const char * const clockrates[] = {
>> - "XXXXXXX", "XXXXXXXX", "XXXXXX", "2.5 Mb/s",
>> + "10 Mb/s", "XXXXXXXX", "XXXXXX", "2.5 Mb/s",
>> "1.25Mb/s", "625 Kb/s", "312.5 Kb/s", "156.25 Kb/s",
>> "Reserved", "Reserved", "Reserved"
>> };
>> @@ -391,9 +391,10 @@ static void com20020_set_mc_list(struct net_device *dev)
>> }
>> }
>>
>> -#if defined(CONFIG_ARCNET_COM20020_PCI_MODULE) || \
>> - defined(CONFIG_ARCNET_COM20020_ISA_MODULE) || \
>> - defined(CONFIG_ARCNET_COM20020_CS_MODULE)
>> +#if defined(CONFIG_ARCNET_COM20020_PCI_MODULE) || \
>> + defined(CONFIG_ARCNET_COM20020_ISA_MODULE) || \
>> + defined(CONFIG_ARCNET_COM20020_CS_MODULE) || \
>> + defined(CONFIG_ARCNET_COM20020_MEMORY_BUS)
>
> Why the whitespace change?
defined(CONFIG_ARCNET_COM20020_ISA_MODULE) || \
- defined(CONFIG_ARCNET_COM20020_CS_MODULE)
+ defined(CONFIG_ARCNET_COM20020_CS_MODULE) || \
+ defined(CONFIG_ARCNET_COM20020_MEMORY_BUS)
Removed useless withespace
>
> Hope this helps,
> Tobin.
>
Thank you for help,
Andrea
^ permalink raw reply
* RE: [PATCH v2] net: dsa: drop some VLAs in switch.c
From: David Laight @ 2018-05-08 9:39 UTC (permalink / raw)
To: 'Salvatore Mesoraca', Florian Fainelli
Cc: Andrew Lunn, linux-kernel@vger.kernel.org, Kernel Hardening,
netdev@vger.kernel.org, David S. Miller, Kees Cook,
Vivien Didelot
In-Reply-To: <CAJHCu1KsvPEs9vpp5bY04OeVfMtqZzPuO=9c8e2QP-+n+VKUjQ@mail.gmail.com>
From: Salvatore Mesoraca
> Sent: 07 May 2018 20:03
...
> This optimization will save us an allocation when number of ports is
> less than 32 or 64 (depending on arch).
> IMHO it's useful, if you consider that, right now, DSA works only with
> 12-ports switches.
Why not just error out if the number of ports is greater than the compile-time
limit?
Worry about dynamic allocation if you need a lot more than 64 ports.
David
^ permalink raw reply
* Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring
From: Tiwei Bie @ 2018-05-08 9:44 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, virtualization, linux-kernel, netdev, wexu,
jfreimann
In-Reply-To: <122277c6-d103-e1f6-d695-4d64e6934a51@redhat.com>
On Tue, May 08, 2018 at 05:34:40PM +0800, Jason Wang wrote:
> On 2018年05月08日 17:16, Tiwei Bie wrote:
> > On Tue, May 08, 2018 at 03:16:53PM +0800, Jason Wang wrote:
> > > On 2018年05月08日 14:44, Tiwei Bie wrote:
> > > > On Tue, May 08, 2018 at 01:40:40PM +0800, Jason Wang wrote:
> > > > > On 2018年05月08日 11:05, Jason Wang wrote:
> > > > > > > Because in virtqueue_enable_cb_delayed(), we may set an
> > > > > > > event_off which is bigger than new and both of them have
> > > > > > > wrapped. And in this case, although new is smaller than
> > > > > > > event_off (i.e. the third param -- old), new shouldn't
> > > > > > > add vq->num, and actually we are expecting a very big
> > > > > > > idx diff.
> > > > > > Yes, so to calculate distance correctly between event and new, we just
> > > > > > need to compare the warp counter and return false if it doesn't match
> > > > > > without the need to try to add vq.num here.
> > > > > >
> > > > > > Thanks
> > > > > Sorry, looks like the following should work, we need add vq.num if
> > > > > used_wrap_counter does not match:
> > > > >
> > > > > static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
> > > > > __u16 off_wrap, __u16 new,
> > > > > __u16 old)
> > > > > {
> > > > > bool wrap = off_wrap >> 15;
> > > > > int off = off_wrap & ~(1 << 15);
> > > > > __u16 d1, d2;
> > > > >
> > > > > if (wrap != vq->used_wrap_counter)
> > > > > d1 = new + vq->num - off - 1;
> > > > Just to draw your attention (maybe you have already
> > > > noticed this).
> > > I miss this, thanks!
> > >
> > > > In this case (i.e. wrap != vq->used_wrap_counter),
> > > > it's also possible that (off < new) is true. Because,
> > > >
> > > > when virtqueue_enable_cb_delayed_packed() is used,
> > > > `off` is calculated in driver in a way like this:
> > > >
> > > > off = vq->last_used_idx + bufs;
> > > > if (off >= vq->vring_packed.num) {
> > > > off -= vq->vring_packed.num;
> > > > wrap_counter ^= 1;
> > > > }
> > > >
> > > > And when `new` (in vhost) is close to vq->num. The
> > > > vq->last_used_idx + bufs (in driver) can be bigger
> > > > than vq->vring_packed.num, and:
> > > >
> > > > 1. `off` will wrap;
> > > > 2. wrap counters won't match;
> > > > 3. off < new;
> > > >
> > > > And d1 (i.e. new + vq->num - off - 1) will be a value
> > > > bigger than vq->num. I'm okay with this, although it's
> > > > a bit weird.
> > >
> > > So I'm considering something more compact by reusing vring_need_event() by
> > > pretending a larger queue size and adding vq->num back when necessary:
> > >
> > > static bool vhost_vring_packed_need_event(struct vhost_virtqueue *vq,
> > > __u16 off_wrap, __u16 new,
> > > __u16 old)
> > > {
> > > bool wrap = vq->used_wrap_counter;
> > If the wrap counter is obtained from the vq,
> > I think `new` should also be obtained from
> > the vq. Or the wrap counter should be carried
> > in `new`.
> >
> > > int off = off_wrap & ~(1 << 15);
> > > __u16 d1, d2;
> > >
> > > if (new < old) {
> > > new += vq->num;
> > > wrap ^= 1;
> > > }
> > >
> > > if (wrap != off_wrap >> 15)
> > > off += vq->num;
> > When `new` and `old` wraps, and `off` doesn't wrap,
> > wrap != (off_wrap >> 15) will be true. In this case,
> > `off` is bigger than `new`, and what we should do
> > is `off -= vq->num` instead of `off += vq->num`.
>
> If I understand this correctly, if we track old correctly, it won't happen
> if guest driver behave correctly. That means it should only happen for a
> buggy driver (e.g trying to move off_wrap back).
If vhost is faster than virtio driver, I guess above
case may happen. The `old` and `new` will be updated
each time we want to notify the driver. If the driver
is slower, `old` and `new` in vhost may wrap before
the `off` which is set by driver wraps.
Best regards,
Tiwei Bie
>
> Thanks
>
> >
> > Best regards,
> > Tiwei Bie
> >
> > > return vring_need_event(off, new, old);
> > > }
> > >
> > >
> > > > Best regards,
> > > > Tiwei Bie
> > > >
> > > > > else
> > > > > d1 = new - off - 1;
> > > > >
> > > > > if (new > old)
> > > > > d2 = new - old;
> > > > > else
> > > > > d2 = new + vq->num - old;
> > > > >
> > > > > return d1 < d2;
> > > > > }
> > > > >
> > > > > Thanks
> > > > >
>
^ permalink raw reply
* оферта
From: Пламен Маринова @ 2018-05-08 9:06 UTC (permalink / raw)
To: ми
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
Добро утро,
Дайте ни най-добрите цени за приложените материали. бихме искали да
знаем наличността сега.
Благодаря ти !!
Пламен Маринова
Maticskeeline Tradings
+3597469947
София, България
[-- Attachment #2: Scan_оферта_645987645doc.jar --]
[-- Type: application/jar, Size: 866397 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 2/3] arcnet: com20020: Fixup missing SLOWARB bit
From: Andrea Greco @ 2018-05-08 9:52 UTC (permalink / raw)
To: Tobin C. Harding; +Cc: m.grzeschik, Andrea Greco, netdev, linux-kernel
In-Reply-To: <20180507025556.GG4197@eros>
On 05/07/2018 04:55 AM, Tobin C. Harding wrote:
> On Sat, May 05, 2018 at 11:37:54PM +0200, Andrea Greco wrote:
>> From: Andrea Greco <a.greco@4sigma.it>
>>
>> If com20020 clock is major of 40Mhz SLOWARB bit is requested.
>>
>> Signed-off-by: Andrea Greco <a.greco@4sigma.it>
>> ---
>> drivers/net/arcnet/com20020.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/arcnet/com20020.c b/drivers/net/arcnet/com20020.c
>> index f09ea77dd6a8..abd32ed8ec9b 100644
>> --- a/drivers/net/arcnet/com20020.c
>> +++ b/drivers/net/arcnet/com20020.c
>> @@ -102,6 +102,10 @@ int com20020_check(struct net_device *dev)
>> lp->setup = lp->clockm ? 0 : (lp->clockp << 1);
>> lp->setup2 = (lp->clockm << 4) | 8;
>>
>> + // If clock is major of 40Mhz, SLOWARB bit must be set
>
> /* C89 style comments please :) */
>
Done
>
> Hope this helps,
> Tobin.
>
^ permalink raw reply
* Re: [PATCH net-next] net:sched: add gkprio scheduler
From: Nishanth Devarajan @ 2018-05-08 10:12 UTC (permalink / raw)
To: Cong Wang; +Cc: jiri, jhs, davem, netdev, doucette, michel
In-Reply-To: <CAM_iQpUpVdgQ+ED+Mbzpz6NZLQjzPR+vKcS5Zgv1F+_xysCQcg@mail.gmail.com>
On Mon, May 07, 2018 at 10:24:51PM -0700, Cong Wang wrote:
> On Mon, May 7, 2018 at 2:36 AM, Nishanth Devarajan <ndev2021@gmail.com> wrote:
> > net/sched: add gkprio scheduler
> >
> > Gkprio (Gatekeeper Priority Queue) is a queueing discipline that prioritizes
> > IPv4 and IPv6 packets accordingly to their DSCP field. Although Gkprio can be
> > employed in any QoS scenario in which a higher DSCP field means a higher
> > priority packet, Gkprio was concieved as a solution for denial-of-service
> > defenses that need to route packets with different priorities.
>
>
> Can we give it a better name? "Gatekeeper" is meaningless if we read
> it alone, it ties to your Gatekeeper project which is more than just this
> kernel module. Maybe "DS Priority Queue"?
>
Yes, we should be able to come up with a better name, we'll work on it.
> Overall it looks good to me, just one thing below:
>
> > +struct Qdisc_ops gkprio_qdisc_ops __read_mostly = {
> > + .id = "gkprio",
> > + .priv_size = sizeof(struct gkprio_sched_data),
> > + .enqueue = gkprio_enqueue,
> > + .dequeue = gkprio_dequeue,
> > + .peek = qdisc_peek_dequeued,
> > + .init = gkprio_init,
> > + .reset = gkprio_reset,
> > + .change = gkprio_change,
> > + .dump = gkprio_dump,
> > + .destroy = gkprio_destroy,
> > + .owner = THIS_MODULE,
> > +};
>
> You probably want to add Qdisc_class_ops here so that you can
> dump the stats of each internal queue.
Alright, will make some changes and send in a v2.
Thanks,
Nishanth
^ permalink raw reply
* Re: [PATCH v2] net: dsa: drop some VLAs in switch.c
From: Salvatore Mesoraca @ 2018-05-08 10:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, linux-kernel, Kernel Hardening, netdev,
David S. Miller, Kees Cook, Vivien Didelot, David Laight
In-Reply-To: <20180507192641.GD31021@lunn.ch>
2018-05-07 21:26 GMT+02:00 Andrew Lunn <andrew@lunn.ch>:
>> >> +++ b/include/net/dsa.h
>> >> @@ -256,6 +256,9 @@ struct dsa_switch {
>> >> /* Number of switch port queues */
>> >> unsigned int num_tx_queues;
>> >>
>> >> + unsigned long *bitmap;
>> >> + unsigned long _bitmap;
>> >> +
>> >> /* Dynamically allocated ports, keep last */
>> >> size_t num_ports;
>> >> struct dsa_port ports[];
>> >> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
>> >> index adf50fb..cebf35f0 100644
>> >> --- a/net/dsa/dsa2.c
>> >> +++ b/net/dsa/dsa2.c
>> >> @@ -748,6 +748,20 @@ struct dsa_switch *dsa_switch_alloc(struct device *dev, size_t n)
>> >> if (!ds)
>> >> return NULL;
>> >>
>> >> + /* We avoid allocating memory outside dsa_switch
>> >> + * if it is not needed.
>> >> + */
>> >> + if (n <= sizeof(ds->_bitmap) * 8) {
>> >> + ds->bitmap = &ds->_bitmap;
>> >
>> > Should not this be / BITS_PER_BYTE? If the sizeof(unsigned long) is <=
>> > 8, then you don't need to allocate it, otherwise, you have to.
>
>> This optimization will save us an allocation when number of ports is
>> less than 32 or 64 (depending on arch).
>> IMHO it's useful, if you consider that, right now, DSA works only with
>> 12-ports switches.
>
> Do you have a feeling for the savings? I don't see it being very
> large, and given the extra code, it might actually be negative.
I think that a "compare" and a "jump" costs nothing compared to
devm_kmalloc, its eventual free, and, *maybe*, the cache miss you
get every time you access the bitmask.
This is not necessarily relevant if this code it's invoked rarely,
but, IMHO, it seems strange to always go for dynamic allocation for
something that will be, almost always, as big as a pointer.
Salvatore
^ permalink raw reply
* Re: [PATCH v2] net: dsa: drop some VLAs in switch.c
From: Salvatore Mesoraca @ 2018-05-08 10:32 UTC (permalink / raw)
To: David Laight
Cc: Florian Fainelli, Andrew Lunn, linux-kernel@vger.kernel.org,
Kernel Hardening, netdev@vger.kernel.org, David S. Miller,
Kees Cook, Vivien Didelot
In-Reply-To: <f733e4630e424e0aaf402d5d840cb6e2@AcuMS.aculab.com>
2018-05-08 11:39 GMT+02:00 David Laight <David.Laight@aculab.com>:
> From: Salvatore Mesoraca
>> Sent: 07 May 2018 20:03
> ...
>> This optimization will save us an allocation when number of ports is
>> less than 32 or 64 (depending on arch).
>> IMHO it's useful, if you consider that, right now, DSA works only with
>> 12-ports switches.
>
> Why not just error out if the number of ports is greater than the compile-time
> limit?
>
> Worry about dynamic allocation if you need a lot more than 64 ports.
v1 has been NAK-ed by maintainers because they don't want limits on how
many ports a switch can have.
Salvatore
^ permalink raw reply
* Re: [RFC/PATCH] Add a socketoption IPV6_MULTICAST_ALL analogue to the IPV4 version
From: 吉藤英明 @ 2018-05-08 11:48 UTC (permalink / raw)
To: Andre Naujoks; +Cc: David S. Miller, netdev, yoshfuji
In-Reply-To: <3600af24-8938-a55f-f67f-2306c4c3ac2b@gmail.com>
Hi,
2018-05-08 15:41 GMT+09:00 Andre Naujoks <nautsch2@gmail.com>:
> On 08.05.2018 08:31, 吉藤英明 wrote:
>> Hi,
>>
>> 2018-05-08 15:03 GMT+09:00 Andre Naujoks <nautsch2@gmail.com>:
>>> On 11.04.2018 13:02, Andre Naujoks wrote:
>>>> Hi.
>>>
>>> Hi again.
>>>
>>> Since it has been a month now, I'd like to send a little "ping" on this subject.
>>>
>>> Is anything wrong with this? Or was it just bad timing?
>>
>> I'm just curious... What kind of behaviour do you expect?
>>
>> Unless you explicitly join the group, you cannot get traffic for the group
>> because of multicast filtering at device level (multicast fitlering) or at the
>> switch level (MLD).
>>
>> If an application is interested in (several) multicast groups, it should
>> explicitly join the group. So I cannot find valid (or meaningful) use-case.
>
> I expect only to receive the multicast traffic of groups I explicitly joined on that
> socket. This is was the IPv4 version of this socket option already does. The problem
> only exists if multiple groups are joined and the socket therefore has to be bound
> to the "any"-address. Then we get traffic from all multicast groups joined by any(!)
> process on the system (plus anything else on that IP-port).
Okay I agree that we should be able NOT to get such traffic.
Acked-By: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
--yoshfuji
>
> Regards
> Andre
>
>>
>> --yoshfuji
>>
>>>
>>> Regards
>>> Andre
>>>
>>>>
>>>> I was running into a problem, when trying to join multiple multicast groups
>>>> on a single socket and thus binding to the any-address on said socket. I
>>>> received traffic from multicast groups, I did not join on that socket and
>>>> was at first surprised by that. After reading some old e-mails/threads,
>>>> which came to the conclusion "It is, as it is."
>>>> (e.g https://marc.info/?l=linux-kernel&m=115815686626791&w=2), I discovered
>>>> the IPv4 socketoption IP_MULTICAST_ALL, which, when disabled, does exactly
>>>> what I would expect from a socket by default.
>>>>
>>>> I propose a socket option for IPv6, which does the same and has the same
>>>> default as the IPv4 version. My first thought was, to just apply
>>>> IP_MULTICAST_ALL to a ipv6 socket, but that would change the behavior of
>>>> current applications and would probably be a big no-no.
>>>>
>>>> Regards
>>>> Andre
>>>>
>>>>
>>>> From 473653086c05a3de839c3504885053f6254c7bc5 Mon Sep 17 00:00:00 2001
>>>> From: Andre Naujoks <nautsch2@gmail.com>
>>>> Date: Wed, 11 Apr 2018 12:38:28 +0200
>>>> Subject: [PATCH] Add a socketoption IPV6_MULTICAST_ALL analogue to the IPV4
>>>> version
>>>>
>>>> The socket option will be enabled by default to ensure current behaviour
>>>> is not changed. This is the same for the IPv4 version.
>>>>
>>>> A socket bound to in6addr_any and a specific port will receive all traffic
>>>> on that port. Analogue to IP_MULTICAST_ALL, disable this behaviour, if
>>>> one or more multicast groups were joined (using said socket) and only
>>>> pass on multicast traffic from groups, which were explicitly joined via
>>>> this socket.
>>>>
>>>> Without this option disabled a socket (system even) joined to multiple
>>>> multicast groups is very hard to get right. Filtering by destination
>>>> address has to take place in user space to avoid receiving multicast
>>>> traffic from other multicast groups, which might have traffic on the same
>>>> port.
>>>>
>>>> The extension of the IP_MULTICAST_ALL socketoption to just apply to ipv6,
>>>> too, is not done to avoid changing the behaviour of current applications.
>>>>
>>>> Signed-off-by: Andre Naujoks <nautsch2@gmail.com>
>>>> ---
>>>> include/linux/ipv6.h | 3 ++-
>>>> include/uapi/linux/in6.h | 1 +
>>>> net/ipv6/af_inet6.c | 1 +
>>>> net/ipv6/ipv6_sockglue.c | 11 +++++++++++
>>>> net/ipv6/mcast.c | 2 +-
>>>> 5 files changed, 16 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
>>>> index 8415bf1a9776..495e834c1367 100644
>>>> --- a/include/linux/ipv6.h
>>>> +++ b/include/linux/ipv6.h
>>>> @@ -274,7 +274,8 @@ struct ipv6_pinfo {
>>>> */
>>>> dontfrag:1,
>>>> autoflowlabel:1,
>>>> - autoflowlabel_set:1;
>>>> + autoflowlabel_set:1,
>>>> + mc_all:1;
>>>> __u8 min_hopcount;
>>>> __u8 tclass;
>>>> __be32 rcv_flowinfo;
>>>> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
>>>> index ed291e55f024..71d82fe15b03 100644
>>>> --- a/include/uapi/linux/in6.h
>>>> +++ b/include/uapi/linux/in6.h
>>>> @@ -177,6 +177,7 @@ struct in6_flowlabel_req {
>>>> #define IPV6_V6ONLY 26
>>>> #define IPV6_JOIN_ANYCAST 27
>>>> #define IPV6_LEAVE_ANYCAST 28
>>>> +#define IPV6_MULTICAST_ALL 29
>>>>
>>>> /* IPV6_MTU_DISCOVER values */
>>>> #define IPV6_PMTUDISC_DONT 0
>>>> diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
>>>> index 8da0b513f188..7844cd9d2f10 100644
>>>> --- a/net/ipv6/af_inet6.c
>>>> +++ b/net/ipv6/af_inet6.c
>>>> @@ -209,6 +209,7 @@ static int inet6_create(struct net *net, struct socket *sock, int protocol,
>>>> np->hop_limit = -1;
>>>> np->mcast_hops = IPV6_DEFAULT_MCASTHOPS;
>>>> np->mc_loop = 1;
>>>> + np->mc_all = 1;
>>>> np->pmtudisc = IPV6_PMTUDISC_WANT;
>>>> np->repflow = net->ipv6.sysctl.flowlabel_reflect;
>>>> sk->sk_ipv6only = net->ipv6.sysctl.bindv6only;
>>>> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
>>>> index 4d780c7f0130..b2bc1942a2ee 100644
>>>> --- a/net/ipv6/ipv6_sockglue.c
>>>> +++ b/net/ipv6/ipv6_sockglue.c
>>>> @@ -664,6 +664,13 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
>>>> retv = ipv6_sock_ac_drop(sk, mreq.ipv6mr_ifindex, &mreq.ipv6mr_acaddr);
>>>> break;
>>>> }
>>>> + case IPV6_MULTICAST_ALL:
>>>> + if (optlen < sizeof(int))
>>>> + goto e_inval;
>>>> + np->mc_all = valbool;
>>>> + retv = 0;
>>>> + break;
>>>> +
>>>> case MCAST_JOIN_GROUP:
>>>> case MCAST_LEAVE_GROUP:
>>>> {
>>>> @@ -1255,6 +1262,10 @@ static int do_ipv6_getsockopt(struct sock *sk, int level, int optname,
>>>> val = np->mcast_oif;
>>>> break;
>>>>
>>>> + case IPV6_MULTICAST_ALL:
>>>> + val = np->mc_all;
>>>> + break;
>>>> +
>>>> case IPV6_UNICAST_IF:
>>>> val = (__force int)htonl((__u32) np->ucast_oif);
>>>> break;
>>>> diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
>>>> index 793159d77d8a..623ad00eb3c2 100644
>>>> --- a/net/ipv6/mcast.c
>>>> +++ b/net/ipv6/mcast.c
>>>> @@ -622,7 +622,7 @@ bool inet6_mc_check(struct sock *sk, const struct in6_addr *mc_addr,
>>>> }
>>>> if (!mc) {
>>>> rcu_read_unlock();
>>>> - return true;
>>>> + return np->mc_all;
>>>> }
>>>> read_lock(&mc->sflock);
>>>> psl = mc->sflist;
>>>>
>>>
>
^ permalink raw reply
* Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors
From: Russell King - ARM Linux @ 2018-05-08 11:52 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180504135643.23466-3-antoine.tenart@bootlin.com>
On Fri, May 04, 2018 at 03:56:32PM +0200, Antoine Tenart wrote:
> SFP connectors can be solder on a board without having any of their pins
> (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed,
> and the overall link status reporting is left to other layers.
>
> In order to achieve this, a new SFP_DEV status is added, named UNKNOWN.
> This mode is set when it is not possible for the SFP code to get the
> link status and as a result the link status is reported to be always UP
> from the SFP point of view.
This looks weird to me. SFP_DEV_* states track the netdevice up/down
state and have little to do with whether LOS or MODDEF0 are implemented.
I think it would be better to have a new SFP_MOD_* and to force
sm_mod_state to that in this circumstance.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ 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