* 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
* 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 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: [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
* [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
* [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 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 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 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
* 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 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
* [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 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
* 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
* 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
* 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: 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
* 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
* [PATCH net-next] drivers: net: davinci_mdio: prevent sprious timeout
From: Sekhar Nori @ 2018-05-08 8:26 UTC (permalink / raw)
To: Grygorii Strashko; +Cc: David S . Miller, linux-omap, netdev
A well timed kernel preemption in the time_after() loop
in wait_for_idle() can result in a spurious timeout
error to be returned.
Fix it by checking for status of hardware before returning
timeout error.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
The issue has not been personally observed by me, but has
been reported by users. Sending for next-next given the
non-critical nature. There is seems to be no easy way to
reproduce this.
drivers/net/ethernet/ti/davinci_mdio.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 3c33f4504d8e..4fbd04fd38cf 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -231,10 +231,16 @@ static inline int wait_for_idle(struct davinci_mdio_data *data)
while (time_after(timeout, jiffies)) {
if (__raw_readl(®s->control) & CONTROL_IDLE)
- return 0;
+ goto out;
}
- dev_err(data->dev, "timed out waiting for idle\n");
- return -ETIMEDOUT;
+
+ if (!(__raw_readl(®s->control) & CONTROL_IDLE)) {
+ dev_err(data->dev, "timed out waiting for idle\n");
+ return -ETIMEDOUT;
+ }
+
+out:
+ return 0;
}
static int davinci_mdio_read(struct mii_bus *bus, int phy_id, int phy_reg)
--
2.16.2
^ permalink raw reply related
* Re: linux-next: manual merge of the bpf-next tree with the s390 tree
From: Daniel Borkmann @ 2018-05-08 8:19 UTC (permalink / raw)
To: Stephen Rothwell, Alexei Starovoitov, Networking,
Martin Schwidefsky, Heiko Carstens
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20180508102638.1e19b7f2@canb.auug.org.au>
On 05/08/2018 02:26 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
> arch/s390/net/bpf_jit.S
>
> between commit:
>
> de5cb6eb514e ("s390: use expoline thunks in the BPF JIT")
>
> from the s390 tree and commit:
>
> e1cf4befa297 ("bpf, s390x: remove ld_abs/ld_ind")
>
> from the bpf-next tree.
>
> I fixed it up (I just removed the file as the latter does) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
Yep, sounds good, thanks!
^ permalink raw reply
* [PATCH] net: wireless: ath: ath9k: Fix a possible data race in ath_chanctx_set_next
From: Jia-Ju Bai @ 2018-05-08 8:06 UTC (permalink / raw)
To: ath9k-devel, kvalo; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
The write operation to "sc->next_chan" is protected by
the lock on line 1287, but the read operation to
this data on line 1262 is not protected by the lock.
Thus, there may exist a data race for "sc->next_chan".
To fix this data race, the read operation to "sc->next_chan"
should be also protected by the lock.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/wireless/ath/ath9k/channel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/channel.c b/drivers/net/wireless/ath/ath9k/channel.c
index 1b05b5d7a038..ed3cd5523481 100644
--- a/drivers/net/wireless/ath/ath9k/channel.c
+++ b/drivers/net/wireless/ath/ath9k/channel.c
@@ -1257,12 +1257,12 @@ void ath_chanctx_set_next(struct ath_softc *sc, bool force)
"Stopping current chanctx: %d\n",
sc->cur_chan->chandef.center_freq1);
sc->cur_chan->stopped = true;
- spin_unlock_bh(&sc->chan_lock);
if (sc->next_chan == &sc->offchannel.chan) {
getrawmonotonic(&ts);
measure_time = true;
}
+ spin_unlock_bh(&sc->chan_lock);
ath9k_chanctx_stop_queues(sc, sc->cur_chan);
queues_stopped = true;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net] stmmac: fix reception of 802.1ad Ethernet tagged frames
From: Toshiaki Makita @ 2018-05-08 7:34 UTC (permalink / raw)
To: Elad Nachman; +Cc: davem, netdev
In-Reply-To: <f82648ab-0cfb-0bc2-e0f4-759e32ee445a@gmail.com>
On 2018/05/08 16:11, Elad Nachman wrote:
> Currently running:
> ip link add link eth0 eth0.100 type vlan proto 802.1ad id 100
>
> On eth0=stmmac succeeds, but the end result is that the vlan device gets proto 802.1q instead of proto 802.1ad and drops the received packet. Without the patch packets gets dropped for a seemingly "correct" 802.1ad ip link configuration.
>
> If NETIF_F_HW_VLAN_STAG_RX is a requirement for the driver for supporting 802.1ad protocols then the Linux kernel should return error when user-space requests to create a vlan device with proto 802.1ad for physical devices which lacks NETIF_F_HW_VLAN_STAG_RX, which is not currently the case.
No. You can create 802.1ad devices without HW_VLAN_STAG_RX, but you
should not strip 802.1ad tag in driver without HW_VLAN_STAG_RX.
__netif_receive_skb_core should handle them if the device does not have
HW_VLAN_STAG_RX.
> skb_vlan_untag() does nothing if __vlan_hwaccel_put_tag() was already called before (in the driver). The only possible alternative is to completely remove stmmac_rx_vlan() from the stmmac code and let skb_vlan_untag() handles things in a generic way.
You cannot remove an already added feature in the driver.
Alternatively you can skip stripping vlan if vlan_proto is not 8021Q.
Something like this.
if ((dev->features & NETIF_F_HW_VLAN_CTAG_RX) ==
NETIF_F_HW_VLAN_CTAG_RX &&
!__vlan_get_tag(skb, &vlanid)) {
veth = (struct vlan_ethhdr *)skb->data;
vlan_proto = veth->h_vlan_proto;
if (vlan_proto == htons(ETH_P_8021Q)) {
/* pop the vlan tag */
memmove(skb->data + VLAN_HLEN, veth, ETH_ALEN * 2);
skb_pull(skb, VLAN_HLEN);
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlanid);
}
}
}
--
Toshiaki Makita
^ permalink raw reply
* INFO: rcu detected stall in sctp_generate_heartbeat_event
From: syzbot @ 2018-05-08 7:35 UTC (permalink / raw)
To: davem, linux-kernel, linux-sctp, marcelo.leitner, netdev, nhorman,
syzkaller-bugs, vyasevich
Hello,
syzbot found the following crash on:
HEAD commit: 90278871d4b0 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=119a7237800000
kernel config: https://syzkaller.appspot.com/x/.config?x=aea320d3af5ef99d
dashboard link: https://syzkaller.appspot.com/bug?extid=e4a5bbd54260c93014f9
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e4a5bbd54260c93014f9@syzkaller.appspotmail.com
device bridge0 left promiscuous mode
IPVS: set_ctl: invalid protocol: 56 0.0.0.0:20003 fo
IPVS: set_ctl: invalid protocol: 175 224.0.0.2:20003 dh
INFO: rcu_sched self-detected stall on CPU
0-...!: (119824 ticks this GP) idle=4b6/1/4611686018427387908
softirq=23864/23864 fqs=5
(t=125000 jiffies g=13072 c=13071 q=480954)
NMI backtrace for cpu 0
CPU: 0 PID: 4547 Comm: udevd Not tainted 4.17.0-rc3+ #34
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
print_cpu_stall kernel/rcu/tree.c:1525 [inline]
check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
__rcu_pending kernel/rcu/tree.c:3356 [inline]
rcu_pending kernel/rcu/tree.c:3401 [inline]
rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
update_process_times+0x2d/0x70 kernel/time/timer.c:1636
tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164
tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274
__run_hrtimer kernel/time/hrtimer.c:1398 [inline]
__hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460
hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
RIP: 0010:rep_nop arch/x86/include/asm/processor.h:667 [inline]
RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:672 [inline]
RIP: 0010:virt_spin_lock arch/x86/include/asm/qspinlock.h:69 [inline]
RIP: 0010:native_queued_spin_lock_slowpath+0x204/0xde0
kernel/locking/qspinlock.c:305
RSP: 0018:ffff8801dae07390 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000000 RBX: ffffed003b5c0e8b RCX: 0000000000000004
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff8801a9e9d088
RBP: ffff8801dae07700 R08: ffffed00353d3a12 R09: ffffed00353d3a11
R10: ffffed00353d3a11 R11: ffff8801a9e9d08b R12: ffff8801a9e9d088
R13: ffff8801dae076d8 R14: 0000000000000001 R15: dffffc0000000000
pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:674 [inline]
queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:30 [inline]
queued_spin_lock include/asm-generic/qspinlock.h:90 [inline]
do_raw_spin_lock+0x1a7/0x200 kernel/locking/spinlock_debug.c:113
__raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline]
_raw_spin_lock+0x32/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:310 [inline]
sctp_generate_heartbeat_event+0xa4/0x450 net/sctp/sm_sideeffect.c:386
call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x79e/0xc50 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x1d1/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:525 [inline]
smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
</IRQ>
RIP: 0010:rcu_is_watching+0x41/0x140 kernel/rcu/tree.c:1071
RSP: 0018:ffff8801ad457848 EFLAGS: 00000296 ORIG_RAX: ffffffffffffff13
RAX: ffffed0035a8af0a RBX: 1ffff10035a8af0a RCX: ffff8801ad4578f0
RDX: 0000000000000000 RSI: ffff8801ad457f58 RDI: ffffffff897bf004
RBP: ffff8801ad4578d8 R08: ffff8801ad457978 R09: ffff8801ad53e040
R10: ffffed0035a8af32 R11: ffff8801ad457997 R12: ffff8801ad457988
R13: 0000000000000000 R14: ffff8801ad4578b0 R15: dffffc0000000000
syz-executor3 (7657) used greatest stack depth: 15968 bytes left
kernel_text_address+0x61/0xf0 kernel/extable.c:140
__kernel_text_address+0xd/0x40 kernel/extable.c:107
unwind_get_return_address+0x61/0xa0 arch/x86/kernel/unwind_frame.c:18
__save_stack_trace+0x7e/0xd0 arch/x86/kernel/stacktrace.c:45
save_stack_trace+0x1a/0x20 arch/x86/kernel/stacktrace.c:60
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
getname_flags+0xd0/0x5a0 fs/namei.c:140
getname+0x19/0x20 fs/namei.c:211
do_sys_open+0x39a/0x740 fs/open.c:1087
__do_sys_open fs/open.c:1111 [inline]
__se_sys_open fs/open.c:1106 [inline]
__x64_sys_open+0x7e/0xc0 fs/open.c:1106
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f7621c19120
RSP: 002b:00007fff6a9646f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7621c19120
RDX: 0000000000000124 RSI: 0000000000080000 RDI: 00007fff6a9647a0
RBP: 0000000000ddd744 R08: 0000000000ddd744 R09: 00007f7621c6ec20
R10: 7269762f73656369 R11: 0000000000000246 R12: 0000000000dc3810
R13: 0000000000dc3900 R14: 0000000000dc3250 R15: 0000000000dc8e10
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state
IPVS: ftp: loaded support on port[0] = 21
team0 (unregistering): Port device team_slave_1 removed
team0 (unregistering): Port device team_slave_0 removed
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
team0 (unregistering): Port device team_slave_1 removed
team0 (unregistering): Port device team_slave_0 removed
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
team0 (unregistering): Port device team_slave_1 removed
team0 (unregistering): Port device team_slave_0 removed
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
team0 (unregistering): Port device team_slave_1 removed
team0 (unregistering): Port device team_slave_0 removed
bond0 (unregistering): Releasing backup interface bond_slave_1
bond0 (unregistering): Releasing backup interface bond_slave_0
bond0 (unregistering): Released all slaves
bridge0: port 1(bridge_slave_0) entered blocking state
bridge0: port 1(bridge_slave_0) entered disabled state
device bridge_slave_0 entered promiscuous mode
bridge0: port 2(bridge_slave_1) entered blocking state
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_1 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): veth0_to_bridge: link is not ready
IPv6: ADDRCONF(NETDEV_UP): veth1_to_bridge: link is not ready
bond0: Enslaving bond_slave_0 as an active interface with an up link
bond0: Enslaving bond_slave_1 as an active interface with an up link
IPv6: ADDRCONF(NETDEV_UP): veth1_to_bond: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_bond: link becomes ready
IPv6: ADDRCONF(NETDEV_UP): team_slave_0: link is not ready
team0: Port device team_slave_0 added
IPv6: ADDRCONF(NETDEV_UP): team_slave_1: link is not ready
team0: Port device team_slave_1 added
IPv6: ADDRCONF(NETDEV_CHANGE): team_slave_0: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): team_slave_1: link becomes ready
IPv6: ADDRCONF(NETDEV_UP): bridge_slave_0: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): bridge_slave_0: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0_to_bridge: link becomes ready
IPv6: ADDRCONF(NETDEV_UP): bridge_slave_1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): bridge_slave_1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_bridge: link becomes ready
bridge0: port 2(bridge_slave_1) entered blocking state
bridge0: port 2(bridge_slave_1) entered forwarding state
bridge0: port 1(bridge_slave_0) entered blocking state
bridge0: port 1(bridge_slave_0) entered forwarding state
IPv6: ADDRCONF(NETDEV_UP): bridge0: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): bridge0: link becomes ready
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH] net: aquantia: Fix an error handling path in 'aq_pci_probe()'
From: Igor Russkikh @ 2018-05-08 7:19 UTC (permalink / raw)
To: Christophe JAILLET, davem, pavel.belous, weiyongjun1,
dan.carpenter
Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <20180508063947.11317-1-christophe.jaillet@wanadoo.fr>
Hi Christophe,
On 08.05.2018 09:39, Christophe JAILLET wrote:
> The position of 2 labels should be swapped in order to release resources
> in the correct order and avoid leaks.
>
> kfree(self->aq_hw);
> err_ioremap:
> free_netdev(ndev);
> -err_pci_func:
> - pci_release_regions(pdev);
> err_ndev:
> + pci_release_regions(pdev);
> +err_pci_func:
> pci_disable_device(pdev);
> return err;
> }
>
This was just submitted yesterday and is already accepted in netdev by David:
http://patchwork.ozlabs.org/patch/909746/
Thanks!
BR, Igor
^ permalink raw reply
* [PATCH net-next 4/4] bnxt_en: Always forward VF MAC address to the PF.
From: Michael Chan @ 2018-05-08 7:18 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1525763921-20698-1-git-send-email-michael.chan@broadcom.com>
The current code already forwards the VF MAC address to the PF, except
in one case. If the VF driver gets a valid MAC address from the firmware
during probe time, it will not forward the MAC address to the PF,
incorrectly assuming that the PF already knows the MAC address. This
causes "ip link show" to show zero VF MAC addresses for this case.
This assumption is not correct. Newer firmware remembers the VF MAC
address last used by the VF and provides it to the VF driver during
probe. So we need to always forward the VF MAC address to the PF.
The forwarded MAC address may now be the PF assigned MAC address and so we
need to make sure we approve it for this case.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index cd3ab78..dfa0839 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -8678,8 +8678,8 @@ static int bnxt_init_mac_addr(struct bnxt *bp)
memcpy(bp->dev->dev_addr, vf->mac_addr, ETH_ALEN);
} else {
eth_hw_addr_random(bp->dev);
- rc = bnxt_approve_mac(bp, bp->dev->dev_addr);
}
+ rc = bnxt_approve_mac(bp, bp->dev->dev_addr);
#endif
}
return rc;
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
index cc21d87..a649108 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -923,7 +923,8 @@ static int bnxt_vf_configure_mac(struct bnxt *bp, struct bnxt_vf_info *vf)
if (req->enables & cpu_to_le32(FUNC_VF_CFG_REQ_ENABLES_DFLT_MAC_ADDR)) {
if (is_valid_ether_addr(req->dflt_mac_addr) &&
((vf->flags & BNXT_VF_TRUST) ||
- (!is_valid_ether_addr(vf->mac_addr)))) {
+ !is_valid_ether_addr(vf->mac_addr) ||
+ ether_addr_equal(req->dflt_mac_addr, vf->mac_addr))) {
ether_addr_copy(vf->vf_mac_addr, req->dflt_mac_addr);
return bnxt_hwrm_exec_fwd_resp(bp, vf, msg_size);
}
--
1.8.3.1
^ permalink raw reply related
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