Re: [PATCH v2] staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()
On Fri, Feb 15, 2019 at 03:02:25PM +0800, Chao Yu wrote:
> On 2019/2/1 20:16, Gao Xiang wrote:
> > + /*
> > +* on-disk error, let's only BUG_ON in the debugging mode.
> > +* otherwise, it will return 1 to just skip the invalid name
> > +* and go on (in consideration of the lookup performance).
> > +*/
> > + DBG_BUGON(qd->name > qd->end);
>
> qd->name == qd->end is not allowed as well?
>
> So will it be better to return directly here?
>
> if (unlikely(qd->name >= qd->end)) {
> DBG_BUGON(1);
> return 1;
> }
Please don't add likely/unlikely() annotations unless you have
benchmarked it and it makes a difference.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android: use multiple futex wait queues
> > + list_for_each_entry(it, >futex_wait_queue_list, list) {
> > + if (wait_queue->offset == arg->offset) {
> ^^
> You meant "it->offset".
Right, this is not good. Fixed in v2.
Thanks for the feedback!
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] binder: fix handling of misaligned binder object
On Thu, Feb 14, 2019 at 03:22:57PM -0800, Todd Kjos wrote: > Fixes crash found by syzbot: > kernel BUG at drivers/android/binder_alloc.c:LINE! (2) > > Reported-by: syzbot+55de1eb4975dec156...@syzkaller.appspotmail.com As the bot asked, this should be: Reported-and-tested-by: syzbot+55de1eb4975dec156...@syzkaller.appspotmail.com I'll go fix that up... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging/android: use multiple futex wait queues
Use multiple per-offset wait queues instead of one big wait queue per
region.
Signed-off-by: Hugo Lefeuvre
---
Changes in v2:
- dereference the it pointer instead of wait_queue (which is not set
yet) in handle_vsoc_cond_wait()
---
drivers/staging/android/TODO | 4 ---
drivers/staging/android/vsoc.c | 56 ++
2 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index fbf015cc6d62..cd2af06341dc 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -12,10 +12,6 @@ ion/
- Better test framework (integration with VGEM was suggested)
vsoc.c, uapi/vsoc_shm.h
- - The current driver uses the same wait queue for all of the futexes in a
- region. This will cause false wakeups in regions with a large number of
- waiting threads. We should eventually use multiple queues and select the
- queue based on the region.
- Add debugfs support for examining the permissions of regions.
- Remove VSOC_WAIT_FOR_INCOMING_INTERRUPT ioctl. This functionality has been
superseded by the futex and is there for legacy reasons.
diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
index f2bb18158e5b..97303d9173aa 100644
--- a/drivers/staging/android/vsoc.c
+++ b/drivers/staging/android/vsoc.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "uapi/vsoc_shm.h"
#define VSOC_DEV_NAME "vsoc"
@@ -62,11 +63,18 @@ static const int MAX_REGISTER_BAR_LEN = 0x100;
*/
static const int SHARED_MEMORY_BAR = 2;
+struct vsoc_futex_wait_queue_t {
+ struct list_head list;
+ u32 offset;
+ wait_queue_head_t queue;
+};
+
struct vsoc_region_data {
char name[VSOC_DEVICE_NAME_SZ + 1];
wait_queue_head_t interrupt_wait_queue;
- /* TODO(b/73664181): Use multiple futex wait queues */
- wait_queue_head_t futex_wait_queue;
+ /* Per-offset futex wait queue. */
+ struct list_head futex_wait_queue_list;
+ spinlock_t futex_wait_queue_lock;
/* Flag indicating that an interrupt has been signalled by the host. */
atomic_t *incoming_signalled;
/* Flag indicating the guest has signalled the host. */
@@ -402,6 +410,7 @@ static int handle_vsoc_cond_wait(struct file *filp, struct
vsoc_cond_wait *arg)
struct vsoc_region_data *data = vsoc_dev.regions_data + region_number;
int ret = 0;
struct vsoc_device_region *region_p = vsoc_region_from_filep(filp);
+ struct vsoc_futex_wait_queue_t *it, *wait_queue = NULL;
atomic_t *address = NULL;
ktime_t wake_time;
@@ -415,10 +424,27 @@ static int handle_vsoc_cond_wait(struct file *filp,
struct vsoc_cond_wait *arg)
address = shm_off_to_virtual_addr(region_p->region_begin_offset +
arg->offset);
+ /* Find wait queue corresponding to offset or create it */
+ spin_lock(>futex_wait_queue_lock);
+ list_for_each_entry(it, >futex_wait_queue_list, list) {
+ if (it->offset == arg->offset) {
+ wait_queue = it;
+ break;
+ }
+ }
+
+ if (!wait_queue) {
+ wait_queue = kmalloc(sizeof(*wait_queue), GFP_KERNEL);
+ wait_queue->offset = arg->offset;
+ init_waitqueue_head(_queue->queue);
+ list_add(_queue->list, >futex_wait_queue_list);
+ }
+ spin_unlock(>futex_wait_queue_lock);
+
/* Ensure that the type of wait is valid */
switch (arg->wait_type) {
case VSOC_WAIT_IF_EQUAL:
- ret = wait_event_freezable(data->futex_wait_queue,
+ ret = wait_event_freezable(wait_queue->queue,
arg->wakes++ &&
atomic_read(address) != arg->value);
break;
@@ -426,7 +452,7 @@ static int handle_vsoc_cond_wait(struct file *filp, struct
vsoc_cond_wait *arg)
if (arg->wake_time_nsec >= NSEC_PER_SEC)
return -EINVAL;
wake_time = ktime_set(arg->wake_time_sec, arg->wake_time_nsec);
- ret = wait_event_freezable_hrtimeout(data->futex_wait_queue,
+ ret = wait_event_freezable_hrtimeout(wait_queue->queue,
arg->wakes++ &&
atomic_read(address) !=
arg->value,
wake_time);
@@ -463,6 +489,7 @@ static int do_vsoc_cond_wake(struct file *filp, uint32_t
offset)
struct vsoc_device_region *region_p = vsoc_region_from_filep(filp);
u32 region_number = iminor(file_inode(filp));
struct vsoc_region_data *data = vsoc_dev.regions_data + region_number;
+ struct vsoc_futex_wait_queue_t *wait_queue;
/* Ensure that the offset is
Re: [PATCH v2 2/2] staging: erofs: complete POSIX ACL support
On Fri, Feb 15, 2019 at 10:10:34AM +0800, Chao Yu wrote: > Hi Dan, > > Any suggestion? > I won't NAK whatever you decide. But my opinion is that you should just use normal kernel memory allocators even though it means you have to use two different fault injection frameworks. Over time it would be good to improve and expand the standard kernel error injection frameworks to cover more types. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android: use multiple futex wait queues
On Thu, Feb 14, 2019 at 06:34:59PM +0100, Hugo Lefeuvre wrote:
> @@ -402,6 +410,7 @@ static int handle_vsoc_cond_wait(struct file *filp,
> struct vsoc_cond_wait *arg)
> struct vsoc_region_data *data = vsoc_dev.regions_data + region_number;
> int ret = 0;
> struct vsoc_device_region *region_p = vsoc_region_from_filep(filp);
> + struct vsoc_futex_wait_queue_t *it, *wait_queue = NULL;
^
> atomic_t *address = NULL;
> ktime_t wake_time;
>
> @@ -415,10 +424,27 @@ static int handle_vsoc_cond_wait(struct file *filp,
> struct vsoc_cond_wait *arg)
> address = shm_off_to_virtual_addr(region_p->region_begin_offset +
> arg->offset);
>
> + /* Find wait queue corresponding to offset or create it */
> + spin_lock(>futex_wait_queue_lock);
> + list_for_each_entry(it, >futex_wait_queue_list, list) {
> + if (wait_queue->offset == arg->offset) {
^^
You meant "it->offset".
> + wait_queue = it;
> + break;
> + }
> + }
> +
> + if (!wait_queue) {
> + wait_queue = kmalloc(sizeof(*wait_queue), GFP_KERNEL);
> + wait_queue->offset = arg->offset;
> + init_waitqueue_head(_queue->queue);
> + list_add(_queue->list, >futex_wait_queue_list);
> + }
> + spin_unlock(>futex_wait_queue_lock);
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()
On 2019/2/1 20:16, Gao Xiang wrote:
> As Al pointed out, "
> ... and while we are at it, what happens to
> unsigned int nameoff = le16_to_cpu(de[mid].nameoff);
> unsigned int matched = min(startprfx, endprfx);
>
> struct qstr dname = QSTR_INIT(data + nameoff,
> unlikely(mid >= ndirents - 1) ?
> maxsize - nameoff :
> le16_to_cpu(de[mid + 1].nameoff) - nameoff);
>
> /* string comparison without already matched prefix */
> int ret = dirnamecmp(name, , );
> if le16_to_cpu(de[...].nameoff) is not monotonically increasing? I.e.
> what's to prevent e.g. (unsigned)-1 ending up in dname.len?
>
> Corrupted fs image shouldn't oops the kernel.. "
>
> Revisit the related lookup flow to address the issue.
>
> Fixes: d72d1ce60174 ("staging: erofs: add namei functions")
> Cc: # 4.19+
> Suggested-by: Al Viro
> Signed-off-by: Gao Xiang
> ---
> [ It should be better get reviewed first and for linux-next... ]
>
> change log v2:
> - fix the missing "kunmap_atomic" pointed out by Dan;
> - minor cleanup;
>
> drivers/staging/erofs/namei.c | 187
> ++
> 1 file changed, 99 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/staging/erofs/namei.c b/drivers/staging/erofs/namei.c
> index 5596c52e246d..321c881d720f 100644
> --- a/drivers/staging/erofs/namei.c
> +++ b/drivers/staging/erofs/namei.c
> @@ -15,74 +15,77 @@
>
> #include
>
> -/* based on the value of qn->len is accurate */
> -static inline int dirnamecmp(struct qstr *qn,
> - struct qstr *qd, unsigned int *matched)
> +struct erofs_qstr {
> + const unsigned char *name;
> + const unsigned char *end;
> +};
> +
> +/* based on the end of qn is accurate and it must have the trailing '\0' */
> +static inline int dirnamecmp(const struct erofs_qstr *qn,
> + const struct erofs_qstr *qd,
> + unsigned int *matched)
> {
> - unsigned int i = *matched, len = min(qn->len, qd->len);
> -loop:
> - if (unlikely(i >= len)) {
> - *matched = i;
> - if (qn->len < qd->len) {
> - /*
> - * actually (qn->len == qd->len)
> - * when qd->name[i] == '\0'
> - */
> - return qd->name[i] == '\0' ? 0 : -1;
> + unsigned int i = *matched;
> +
> + /*
> + * on-disk error, let's only BUG_ON in the debugging mode.
> + * otherwise, it will return 1 to just skip the invalid name
> + * and go on (in consideration of the lookup performance).
> + */
> + DBG_BUGON(qd->name > qd->end);
qd->name == qd->end is not allowed as well?
So will it be better to return directly here?
if (unlikely(qd->name >= qd->end)) {
DBG_BUGON(1);
return 1;
}
> +
> + /* qd could not have trailing '\0' */
> + /* However it is absolutely safe if < qd->end */
> + while (qd->name + i < qd->end && qd->name[i] != '\0') {
> + if (qn->name[i] != qd->name[i]) {
> + *matched = i;
> + return qn->name[i] > qd->name[i] ? 1 : -1;
> }
> - return (qn->len > qd->len);
> + ++i;
> }
> -
> - if (qn->name[i] != qd->name[i]) {
> - *matched = i;
> - return qn->name[i] > qd->name[i] ? 1 : -1;
> - }
> -
> - ++i;
> - goto loop;
> + *matched = i;
> + /* See comments in __d_alloc on the terminating NUL character */
> + return qn->name[i] == '\0' ? 0 : 1;
> }
>
> -static struct erofs_dirent *find_target_dirent(
> - struct qstr *name,
> - u8 *data, int maxsize)
> +#define nameoff_from_disk(off, sz) (le16_to_cpu(off) & ((sz) - 1))
> +
> +static struct erofs_dirent *find_target_dirent(struct erofs_qstr *name,
> +u8 *data,
> +unsigned int dirblksize,
> +const int ndirents)
> {
> - unsigned int ndirents, head, back;
> + int head, back;
> unsigned int startprfx, endprfx;
> struct erofs_dirent *const de = (struct erofs_dirent *)data;
>
> - /* make sure that maxsize is valid */
> - BUG_ON(maxsize < sizeof(struct erofs_dirent));
> -
> - ndirents = le16_to_cpu(de->nameoff) / sizeof(*de);
> -
> - /* corrupted dir (may be unnecessary...) */
> - BUG_ON(!ndirents);
> -
> - head = 0;
> + /* since the 1st dirent has been evaluated previously */
> + head = 1;
> back = ndirents - 1;
> startprfx = endprfx = 0;
>
> while (head <= back) {
> - unsigned int mid = head + (back - head) / 2;
> - unsigned int nameoff = le16_to_cpu(de[mid].nameoff);
> + const int mid = head + (back - head) / 2;
> + const int nameoff = nameoff_from_disk(de[mid].nameoff,
> +
Re: [PATCH 2/2] staging: android: ashmem: Don't allow range_alloc() to fail.
On Thu, Feb 14, 2019 at 11:22:51AM -0500, Joel Fernandes wrote:
> On Sat, Feb 09, 2019 at 11:24:03AM +0900, Tetsuo Handa wrote:
> > @@ -722,10 +719,17 @@ static int ashmem_pin_unpin(struct ashmem_area *asma,
> > unsigned long cmd,
> > struct ashmem_pin pin;
> > size_t pgstart, pgend;
> > int ret = -EINVAL;
> > + struct ashmem_range *range = NULL;
> >
> > if (copy_from_user(, p, sizeof(pin)))
> > return -EFAULT;
> >
> > + if (cmd == ASHMEM_PIN || cmd == ASHMEM_UNPIN) {
> > + range = kmem_cache_zalloc(ashmem_range_cachep, GFP_KERNEL);
> > + if (!range)
> > + return -ENOMEM;
>
> According to the too-small-to-fail rule, why are you checking for errors
> here?
>
As a static analysis person, Smatch knows about the GFP_NOFAIL flag.
The small size rule would probably be easy enough to implement for 80%
of the cases but I have avoided doing that and still patch up the code
when I find missing NULL checks.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging: mt7621-pci-phy: use 'module_init' instead of 'arch_initcall'
Init driver as 'arch_initcall()' does not work. It causes phy_create()
to be called before the phy module is initialized, so 'phy_class' is NULL,
the new phy isn't placed in the right class, and it cannot be found.
Change to 'module_init()' which works properly in this case.
Fixes: 00981d31d6df: staging: mt7621-pci-phy: add new driver for phy part of
mt7621-pci
Reported-by: NeilBrown
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
index 3d16716cfebc..d3ca2f019112 100644
--- a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
+++ b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
@@ -380,7 +380,7 @@ static int __init mt7621_pci_phy_drv_init(void)
return platform_driver_register(_pci_phy_driver);
}
-arch_initcall(mt7621_pci_phy_drv_init);
+module_init(mt7621_pci_phy_drv_init);
MODULE_AUTHOR("Sergio Paracuellos ");
MODULE_DESCRIPTION("MediaTek MT7621 PCIe PHY driver");
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: mt7621-dts: fix pci phy register addresses
Both pci-phy0 and pci-phy1 are using bad addresses to search
for its registers. Use proper register values.
Fixes: 06184ba5a33a: staging: mt7621-dts: add pci-phy related bindings to
board's device tree
Reported-by: NeilBrown
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/mt7621.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 3645360e7841..6aff3680ce4b 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -452,9 +452,9 @@
};
};
- pcie0_phy: pcie-phy@1a149000 {
+ pcie0_phy: pcie-phy@1e149000 {
compatible = "mediatek,mt7621-pci-phy";
- reg = <0x1a149000 0x0700>;
+ reg = <0x1e149000 0x0700>;
#address-cells = <1>;
#size-cells = <0>;
@@ -469,9 +469,9 @@
};
};
- pcie1_phy: pcie-phy@1a14a000 {
+ pcie1_phy: pcie-phy@1e14a000 {
compatible = "mediatek,mt7621-pci-phy";
- reg = <0x1a14a000 0x0700>;
+ reg = <0x1e14a000 0x0700>;
#address-cells = <1>;
#size-cells = <0>;
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/2] staging: mt7621-pci-phy: minor fixes after testing
This two patches fix issues encountered after testing mt7621-pci-phy driver into real hardware. Two changes here: * Fix bad addresses in pcie phy registers. * Use module_init instead of arch_initcall to init the driver. Hope this helps. Best regards, Sergio Paracuellos Sergio Paracuellos (2): staging: mt7621-dts: fix pci phy register addresses staging: mt7621-pci-phy: use 'module_init' instead of 'arch_initcall' drivers/staging/mt7621-dts/mt7621.dtsi | 8 drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) -- 2.19.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/4] staging: mt7621-pci-phy: add new driver for phy part of mt7621-pci
On Fri, Feb 15, 2019 at 6:44 AM NeilBrown wrote: > > On Fri, Jan 04 2019, Sergio Paracuellos wrote: > > > Phy part of the pci for this SoC can be handled using a generic phy > > driver. This commit extracts phy part of the mt7621-pci into a new > > 'mt7621-pci-phy' driver. > > > > Signed-off-by: Sergio Paracuellos > > --- > > drivers/staging/Kconfig | 2 + > > drivers/staging/Makefile | 1 + > > drivers/staging/mt7621-pci-phy/Kconfig| 7 + > > drivers/staging/mt7621-pci-phy/Makefile | 1 + > > drivers/staging/mt7621-pci-phy/TODO | 4 + > > .../staging/mt7621-pci-phy/pci-mt7621-phy.c | 387 ++ > > 6 files changed, 402 insertions(+) > > create mode 100644 drivers/staging/mt7621-pci-phy/Kconfig > > create mode 100644 drivers/staging/mt7621-pci-phy/Makefile > > create mode 100644 drivers/staging/mt7621-pci-phy/TODO > > create mode 100644 drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c > > > > diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig > > index e4f608815c05..4a3d6e00f7cb 100644 > > --- a/drivers/staging/Kconfig > > +++ b/drivers/staging/Kconfig > > @@ -104,6 +104,8 @@ source "drivers/staging/pi433/Kconfig" > > > > source "drivers/staging/mt7621-pci/Kconfig" > > > > +source "drivers/staging/mt7621-pci-phy/Kconfig" > > + > > source "drivers/staging/mt7621-pinctrl/Kconfig" > > > > source "drivers/staging/mt7621-spi/Kconfig" > > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile > > index 5868631e8f1b..413890dd5a14 100644 > > --- a/drivers/staging/Makefile > > +++ b/drivers/staging/Makefile > > @@ -42,6 +42,7 @@ obj-$(CONFIG_BCM2835_VCHIQ) += vc04_services/ > > obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/ > > obj-$(CONFIG_PI433) += pi433/ > > obj-$(CONFIG_SOC_MT7621) += mt7621-pci/ > > +obj-$(CONFIG_SOC_MT7621) += mt7621-pci-phy/ > > obj-$(CONFIG_SOC_MT7621) += mt7621-pinctrl/ > > obj-$(CONFIG_SOC_MT7621) += mt7621-spi/ > > obj-$(CONFIG_SOC_MT7621) += mt7621-dma/ > > diff --git a/drivers/staging/mt7621-pci-phy/Kconfig > > b/drivers/staging/mt7621-pci-phy/Kconfig > > new file mode 100644 > > index ..b9f6ab784ee8 > > --- /dev/null > > +++ b/drivers/staging/mt7621-pci-phy/Kconfig > > @@ -0,0 +1,7 @@ > > +config PCI_MT7621_PHY > > + tristate "MediaTek MT7621 PCI PHY Driver" > > + depends on RALINK && OF > > + select GENERIC_PHY > > + help > > + Say 'Y' here to add support for MediaTek MT7621 PCI PHY driver, > > + > > diff --git a/drivers/staging/mt7621-pci-phy/Makefile > > b/drivers/staging/mt7621-pci-phy/Makefile > > new file mode 100644 > > index ..2b82ccfc28c6 > > --- /dev/null > > +++ b/drivers/staging/mt7621-pci-phy/Makefile > > @@ -0,0 +1 @@ > > +obj-$(CONFIG_SOC_MT7621) += pci-mt7621-phy.o > > diff --git a/drivers/staging/mt7621-pci-phy/TODO > > b/drivers/staging/mt7621-pci-phy/TODO > > new file mode 100644 > > index ..a255e8f753eb > > --- /dev/null > > +++ b/drivers/staging/mt7621-pci-phy/TODO > > @@ -0,0 +1,4 @@ > > + > > +- general code review and cleanup > > + > > +Cc: NeilBrown and Sergio Paracuellos > > > > diff --git a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c > > b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c > > new file mode 100644 > > index ..3d16716cfebc > > --- /dev/null > > +++ b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c > > @@ -0,0 +1,387 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * Mediatek MT7621 PCI PHY Driver > > + * Author: Sergio Paracuellos > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define RALINK_CLKCFG1 0x30 > > +#define CHIP_REV_MT7621_E2 0x0101 > > + > > +#define PCIE_PORT_CLK_EN(x) BIT(24 + (x)) > > + > > +#define RG_PE1_PIPE_REG 0x02c > > +#define RG_PE1_PIPE_RST BIT(12) > > +#define RG_PE1_PIPE_CMD_FRC BIT(4) > > + > > +#define RG_P0_TO_P1_WIDTH0x100 > > +#define RG_PE1_H_LCDDS_REG 0x49c > > +#define RG_PE1_H_LCDDS_PCW GENMASK(30, 0) > > +#define RG_PE1_H_LCDDS_PCW_VAL(x)((0x7fff & (x)) << 0) > > + > > +#define RG_PE1_FRC_H_XTAL_REG0x400 > > +#define RG_PE1_FRC_H_XTAL_TYPE BIT(8) > > +#define RG_PE1_H_XTAL_TYPE GENMASK(10, 9) > > +#define RG_PE1_H_XTAL_TYPE_VAL(x) ((0x3 & (x)) << 9) > > + > > +#define RG_PE1_FRC_PHY_REG 0x000 > > +#define RG_PE1_FRC_PHY_EN BIT(4) > > +#define RG_PE1_PHY_EN BIT(5) > > + > > +#define RG_PE1_H_PLL_REG 0x490 > > +#define RG_PE1_H_PLL_BC GENMASK(23, 22) > > +#define RG_PE1_H_PLL_BC_VAL(x) ((0x3 & (x)) << 22) > > +#define RG_PE1_H_PLL_BP GENMASK(21, 18) > > +#define
Re: [PATCH v3 3/4] staging: mt7621-dts: add pci-phy related bindings to board's device tree
Hi Neil,
On Fri, Feb 15, 2019 at 6:42 AM NeilBrown wrote:
>
> On Fri, Jan 04 2019, Sergio Paracuellos wrote:
>
> > New driver for pci phy has been added, as well as. pci driver has been
> > changed to use kernel's generic PHY API. Add related PCI PHY bindings
> > accordly.
> >
> > Signed-off-by: Sergio Paracuellos
> > ---
> > drivers/staging/mt7621-dts/mt7621.dtsi | 31 ++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
> > b/drivers/staging/mt7621-dts/mt7621.dtsi
> > index 71f069d59ad8..0cbc298ed457 100644
> > --- a/drivers/staging/mt7621-dts/mt7621.dtsi
> > +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
> > @@ -424,6 +424,8 @@
> > reset-names = "pcie0", "pcie1", "pcie2";
> > clocks = < 24 25 26>;
> > clock-names = "pcie0", "pcie1", "pcie2";
> > + phys = <_port>, <_port>, <_port>;
> > + phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
> >
> > pcie@0,0 {
> > reg = <0x 0 0 0 0>;
> > @@ -449,4 +451,33 @@
> > bus-range = <0x00 0xff>;
> > };
> > };
> > +
> > + pcie0_phy: pcie-phy@1a149000 {
>
> Sorry for the late testing...
> This should be "1e149000", 'e', not 'a'.
>
> Same for pcie1_phy.
You are totally right. My bad here. I will fix this and send changes
as a fix patch.
>
> Thanks,
> NeilBrown
Thanks for testing and let me know.
Best regards,
Sergio Paracuellos
>
>
> > + compatible = "mediatek,mt7621-pci-phy";
> > + reg = <0x1a149000 0x0700>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + pcie0_port: pcie-phy@0 {
> > + reg = <0>;
> > + #phy-cells = <0>;
> > + };
> > +
> > + pcie1_port: pcie-phy@1 {
> > + reg = <1>;
> > + #phy-cells = <0>;
> > + };
> > + };
> > +
> > + pcie1_phy: pcie-phy@1a14a000 {
> > + compatible = "mediatek,mt7621-pci-phy";
> > + reg = <0x1a14a000 0x0700>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + pcie2_port: pcie-phy@0 {
> > + reg = <0>;
> > + #phy-cells = <0>;
> > + };
> > + };
> > };
> > --
> > 2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/4] staging: mt7621-pci-phy: add new driver for phy part of mt7621-pci
On Fri, Jan 04 2019, Sergio Paracuellos wrote: > Phy part of the pci for this SoC can be handled using a generic phy > driver. This commit extracts phy part of the mt7621-pci into a new > 'mt7621-pci-phy' driver. > > Signed-off-by: Sergio Paracuellos > --- > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/mt7621-pci-phy/Kconfig| 7 + > drivers/staging/mt7621-pci-phy/Makefile | 1 + > drivers/staging/mt7621-pci-phy/TODO | 4 + > .../staging/mt7621-pci-phy/pci-mt7621-phy.c | 387 ++ > 6 files changed, 402 insertions(+) > create mode 100644 drivers/staging/mt7621-pci-phy/Kconfig > create mode 100644 drivers/staging/mt7621-pci-phy/Makefile > create mode 100644 drivers/staging/mt7621-pci-phy/TODO > create mode 100644 drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c > > diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig > index e4f608815c05..4a3d6e00f7cb 100644 > --- a/drivers/staging/Kconfig > +++ b/drivers/staging/Kconfig > @@ -104,6 +104,8 @@ source "drivers/staging/pi433/Kconfig" > > source "drivers/staging/mt7621-pci/Kconfig" > > +source "drivers/staging/mt7621-pci-phy/Kconfig" > + > source "drivers/staging/mt7621-pinctrl/Kconfig" > > source "drivers/staging/mt7621-spi/Kconfig" > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile > index 5868631e8f1b..413890dd5a14 100644 > --- a/drivers/staging/Makefile > +++ b/drivers/staging/Makefile > @@ -42,6 +42,7 @@ obj-$(CONFIG_BCM2835_VCHIQ) += vc04_services/ > obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/ > obj-$(CONFIG_PI433) += pi433/ > obj-$(CONFIG_SOC_MT7621) += mt7621-pci/ > +obj-$(CONFIG_SOC_MT7621) += mt7621-pci-phy/ > obj-$(CONFIG_SOC_MT7621) += mt7621-pinctrl/ > obj-$(CONFIG_SOC_MT7621) += mt7621-spi/ > obj-$(CONFIG_SOC_MT7621) += mt7621-dma/ > diff --git a/drivers/staging/mt7621-pci-phy/Kconfig > b/drivers/staging/mt7621-pci-phy/Kconfig > new file mode 100644 > index ..b9f6ab784ee8 > --- /dev/null > +++ b/drivers/staging/mt7621-pci-phy/Kconfig > @@ -0,0 +1,7 @@ > +config PCI_MT7621_PHY > + tristate "MediaTek MT7621 PCI PHY Driver" > + depends on RALINK && OF > + select GENERIC_PHY > + help > + Say 'Y' here to add support for MediaTek MT7621 PCI PHY driver, > + > diff --git a/drivers/staging/mt7621-pci-phy/Makefile > b/drivers/staging/mt7621-pci-phy/Makefile > new file mode 100644 > index ..2b82ccfc28c6 > --- /dev/null > +++ b/drivers/staging/mt7621-pci-phy/Makefile > @@ -0,0 +1 @@ > +obj-$(CONFIG_SOC_MT7621) += pci-mt7621-phy.o > diff --git a/drivers/staging/mt7621-pci-phy/TODO > b/drivers/staging/mt7621-pci-phy/TODO > new file mode 100644 > index ..a255e8f753eb > --- /dev/null > +++ b/drivers/staging/mt7621-pci-phy/TODO > @@ -0,0 +1,4 @@ > + > +- general code review and cleanup > + > +Cc: NeilBrown and Sergio Paracuellos > > diff --git a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c > b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c > new file mode 100644 > index ..3d16716cfebc > --- /dev/null > +++ b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c > @@ -0,0 +1,387 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Mediatek MT7621 PCI PHY Driver > + * Author: Sergio Paracuellos > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define RALINK_CLKCFG1 0x30 > +#define CHIP_REV_MT7621_E2 0x0101 > + > +#define PCIE_PORT_CLK_EN(x) BIT(24 + (x)) > + > +#define RG_PE1_PIPE_REG 0x02c > +#define RG_PE1_PIPE_RST BIT(12) > +#define RG_PE1_PIPE_CMD_FRC BIT(4) > + > +#define RG_P0_TO_P1_WIDTH0x100 > +#define RG_PE1_H_LCDDS_REG 0x49c > +#define RG_PE1_H_LCDDS_PCW GENMASK(30, 0) > +#define RG_PE1_H_LCDDS_PCW_VAL(x)((0x7fff & (x)) << 0) > + > +#define RG_PE1_FRC_H_XTAL_REG0x400 > +#define RG_PE1_FRC_H_XTAL_TYPE BIT(8) > +#define RG_PE1_H_XTAL_TYPE GENMASK(10, 9) > +#define RG_PE1_H_XTAL_TYPE_VAL(x) ((0x3 & (x)) << 9) > + > +#define RG_PE1_FRC_PHY_REG 0x000 > +#define RG_PE1_FRC_PHY_EN BIT(4) > +#define RG_PE1_PHY_EN BIT(5) > + > +#define RG_PE1_H_PLL_REG 0x490 > +#define RG_PE1_H_PLL_BC GENMASK(23, 22) > +#define RG_PE1_H_PLL_BC_VAL(x) ((0x3 & (x)) << 22) > +#define RG_PE1_H_PLL_BP GENMASK(21, 18) > +#define RG_PE1_H_PLL_BP_VAL(x) ((0xf & (x)) << 18) > +#define RG_PE1_H_PLL_IR GENMASK(15, 12) > +#define RG_PE1_H_PLL_IR_VAL(x) ((0xf & (x)) << 12) > +#define RG_PE1_H_PLL_IC GENMASK(11, 8) > +#define RG_PE1_H_PLL_IC_VAL(x) ((0xf & (x))
Re: [PATCH v3 3/4] staging: mt7621-dts: add pci-phy related bindings to board's device tree
On Fri, Jan 04 2019, Sergio Paracuellos wrote:
> New driver for pci phy has been added, as well as. pci driver has been
> changed to use kernel's generic PHY API. Add related PCI PHY bindings
> accordly.
>
> Signed-off-by: Sergio Paracuellos
> ---
> drivers/staging/mt7621-dts/mt7621.dtsi | 31 ++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
> b/drivers/staging/mt7621-dts/mt7621.dtsi
> index 71f069d59ad8..0cbc298ed457 100644
> --- a/drivers/staging/mt7621-dts/mt7621.dtsi
> +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
> @@ -424,6 +424,8 @@
> reset-names = "pcie0", "pcie1", "pcie2";
> clocks = < 24 25 26>;
> clock-names = "pcie0", "pcie1", "pcie2";
> + phys = <_port>, <_port>, <_port>;
> + phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
>
> pcie@0,0 {
> reg = <0x 0 0 0 0>;
> @@ -449,4 +451,33 @@
> bus-range = <0x00 0xff>;
> };
> };
> +
> + pcie0_phy: pcie-phy@1a149000 {
Sorry for the late testing...
This should be "1e149000", 'e', not 'a'.
Same for pcie1_phy.
Thanks,
NeilBrown
> + compatible = "mediatek,mt7621-pci-phy";
> + reg = <0x1a149000 0x0700>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pcie0_port: pcie-phy@0 {
> + reg = <0>;
> + #phy-cells = <0>;
> + };
> +
> + pcie1_port: pcie-phy@1 {
> + reg = <1>;
> + #phy-cells = <0>;
> + };
> + };
> +
> + pcie1_phy: pcie-phy@1a14a000 {
> + compatible = "mediatek,mt7621-pci-phy";
> + reg = <0x1a14a000 0x0700>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pcie2_port: pcie-phy@0 {
> + reg = <0>;
> + #phy-cells = <0>;
> + };
> + };
> };
> --
> 2.19.1
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: kernel BUG at drivers/android/binder_alloc.c:LINE! (2)
syzbot has found a reproducer for the following crash on: HEAD commit:b3418f8bddf4 Add linux-next specific files for 20190214 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=12ccad60c0 kernel config: https://syzkaller.appspot.com/x/.config?x=8a3a37525a677c71 dashboard link: https://syzkaller.appspot.com/bug?extid=55de1eb4975dec156d8f compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16f6304740 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12a2ed58c0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+55de1eb4975dec156...@syzkaller.appspotmail.com [ cut here ] kernel BUG at drivers/android/binder_alloc.c:1141! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 0 PID: 7540 Comm: syz-executor013 Not tainted 5.0.0-rc6-next-20190214 #35 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:binder_alloc_do_buffer_copy+0xd6/0x510 drivers/android/binder_alloc.c:1141 Code: 02 00 0f 85 20 04 00 00 4d 8b 64 24 58 49 29 dc e8 9f e1 26 fc 4c 89 e6 4c 89 ef e8 b4 e2 26 fc 4d 39 e5 76 07 e8 8a e1 26 fc <0f> 0b e8 83 e1 26 fc 4c 8b 75 d0 4d 29 ec 4c 89 e6 4c 89 f7 e8 91 RSP: 0018:88804a6cf558 EFLAGS: 00010293 RAX: 888033dc61c0 RBX: 20001000 RCX: 8549806c RDX: RSI: 85498076 RDI: 0006 RBP: 88804a6cf5d8 R08: 888033dc61c0 R09: 0028 R10: ed10094d9f01 R11: 88804a6cf80f R12: 0008 R13: 0028 R14: 888069c1c210 R15: FS: 017d9940() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 7b49a000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: binder_alloc_copy_from_buffer+0x37/0x42 drivers/android/binder_alloc.c:1187 binder_get_object+0xa2/0x1e0 drivers/android/binder.c:2062 binder_transaction+0x2b4a/0x6690 drivers/android/binder.c:3231 binder_thread_write+0x64a/0x2820 drivers/android/binder.c:3792 binder_ioctl_write_read drivers/android/binder.c:4825 [inline] binder_ioctl+0x1033/0x183b drivers/android/binder.c:5002 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x444579 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fff3621c708 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7fff3621c710 RCX: 00444579 RDX: 2440 RSI: c0306201 RDI: 0003 RBP: R08: R09: 00401000 R10: R11: 0246 R12: 00402280 R13: 00402310 R14: R15: Modules linked in: ---[ end trace e53003f51f970669 ]--- RIP: 0010:binder_alloc_do_buffer_copy+0xd6/0x510 drivers/android/binder_alloc.c:1141 Code: 02 00 0f 85 20 04 00 00 4d 8b 64 24 58 49 29 dc e8 9f e1 26 fc 4c 89 e6 4c 89 ef e8 b4 e2 26 fc 4d 39 e5 76 07 e8 8a e1 26 fc <0f> 0b e8 83 e1 26 fc 4c 8b 75 d0 4d 29 ec 4c 89 e6 4c 89 f7 e8 91 RSP: 0018:88804a6cf558 EFLAGS: 00010293 RAX: 888033dc61c0 RBX: 20001000 RCX: 8549806c RDX: RSI: 85498076 RDI: 0006 RBP: 88804a6cf5d8 R08: 888033dc61c0 R09: 0028 R10: ed10094d9f01 R11: 88804a6cf80f R12: 0008 R13: 0028 R14: 888069c1c210 R15: FS: 017d9940() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 7b49a000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show functions
On Thu, Feb 14, 2019 at 08:54:31PM -0500, Sasha Levin wrote: > On Sat, Feb 02, 2019 at 03:07:35PM -0500, Kimberly Brown wrote: > > On Fri, Feb 01, 2019 at 06:24:24PM +, Dexuan Cui wrote: > > > > From: Kimberly Brown > > > > Sent: Thursday, January 31, 2019 9:47 AM > > > > ... > > > > 2) Prevent a deadlock that can occur between the proposed mutex_lock() > > > > call in the vmbus_chan_attr_show() function and the sysfs/kernfs > > > > functions. > > > Hi Kim, > > > Can you please share more details about the deadlock? > > > It's unclear to me how the deadlock happens. > > > > > > > Hi Dexuan, > > > > I encountered the deadlock by: > > 1) Adding a call to msleep() before acquiring the mutex in > > vmbus_chan_attr_show() > > 2) Opening a hv_netvsc subchannel's sysfs file > > 3) Removing hv_netvsc while the sysfs file is opening > > Dexuan, any objections to pulling this fix in? > Hi Sasha, This fix can cause a deadlock. I'm working on a different fix for the original race condition problem. Thanks, Kim > -- > Thanks, > Sasha ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.14 30/40] hv_netvsc: Fix ethtool change hash key error
From: Haiyang Zhang
[ Upstream commit b4a10c750424e01b5e37372fef0a574ebf7b56c3 ]
Hyper-V hosts require us to disable RSS before changing RSS key,
otherwise the changing request will fail. This patch fixes the
coding error.
Fixes: ff4a44199012 ("netvsc: allow get/set of RSS indirection table")
Reported-by: Wei Hu
Signed-off-by: Haiyang Zhang
Reviewed-by: Michael Kelley
[sl: fix up subject line]
Signed-off-by: Sasha Levin
---
drivers/net/hyperv/rndis_filter.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 17025d46bdac..fc1d5e14d83e 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -711,8 +711,8 @@ rndis_filter_set_offload_params(struct net_device *ndev,
return ret;
}
-int rndis_filter_set_rss_param(struct rndis_device *rdev,
- const u8 *rss_key)
+static int rndis_set_rss_param_msg(struct rndis_device *rdev,
+ const u8 *rss_key, u16 flag)
{
struct net_device *ndev = rdev->ndev;
struct rndis_request *request;
@@ -741,7 +741,7 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
rssp->hdr.type = NDIS_OBJECT_TYPE_RSS_PARAMETERS;
rssp->hdr.rev = NDIS_RECEIVE_SCALE_PARAMETERS_REVISION_2;
rssp->hdr.size = sizeof(struct ndis_recv_scale_param);
- rssp->flag = 0;
+ rssp->flag = flag;
rssp->hashinfo = NDIS_HASH_FUNC_TOEPLITZ | NDIS_HASH_IPV4 |
NDIS_HASH_TCP_IPV4 | NDIS_HASH_IPV6 |
NDIS_HASH_TCP_IPV6;
@@ -766,9 +766,12 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
wait_for_completion(>wait_event);
set_complete = >response_msg.msg.set_complete;
- if (set_complete->status == RNDIS_STATUS_SUCCESS)
- memcpy(rdev->rss_key, rss_key, NETVSC_HASH_KEYLEN);
- else {
+ if (set_complete->status == RNDIS_STATUS_SUCCESS) {
+ if (!(flag & NDIS_RSS_PARAM_FLAG_DISABLE_RSS) &&
+ !(flag & NDIS_RSS_PARAM_FLAG_HASH_KEY_UNCHANGED))
+ memcpy(rdev->rss_key, rss_key, NETVSC_HASH_KEYLEN);
+
+ } else {
netdev_err(ndev, "Fail to set RSS parameters:0x%x\n",
set_complete->status);
ret = -EINVAL;
@@ -779,6 +782,16 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
return ret;
}
+int rndis_filter_set_rss_param(struct rndis_device *rdev,
+ const u8 *rss_key)
+{
+ /* Disable RSS before change */
+ rndis_set_rss_param_msg(rdev, rss_key,
+ NDIS_RSS_PARAM_FLAG_DISABLE_RSS);
+
+ return rndis_set_rss_param_msg(rdev, rss_key, 0);
+}
+
static int rndis_filter_query_device_link_status(struct rndis_device *dev,
struct netvsc_device
*net_device)
{
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.19 28/65] staging: rtl8723bs: Fix build error with Clang when inlining is disabled
From: Nathan Chancellor
[ Upstream commit 97715058b70da1262fd07798c8b2e3e894f759dd ]
When CONFIG_NO_AUTO_INLINE was present in linux-next (which added
'-fno-inline-functions' to KBUILD_CFLAGS), an allyesconfig build with
Clang failed at the modpost stage:
ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
These functions were marked as extern inline, meaning that if inlining
doesn't happen, the function will be undefined, as it is above.
This happens to work with GCC because the '-fno-inline-functions' option
respects the __inline attribute so all instances of these functions are
inlined as expected and the definition doesn't actually matter. However,
with Clang and '-fno-inline-functions', a function has to be marked with
the __always_inline attribute to be considered for inlining, which none
of these functions are. Clang tries to find the symbol definition
elsewhere as it was told and fails, which trickles down to modpost.
To make sure that this code compiles regardless of compiler and make the
intention of the code clearer, use 'static' to ensure these functions
are always defined, regardless of inlining. Additionally, silence a
checkpatch warning by switching from '__inline' to 'inline'.
Signed-off-by: Nathan Chancellor
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/rtl8723bs/include/ieee80211.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/include/ieee80211.h
b/drivers/staging/rtl8723bs/include/ieee80211.h
index bcc8dfa8e672..9efb4dcb9d3a 100644
--- a/drivers/staging/rtl8723bs/include/ieee80211.h
+++ b/drivers/staging/rtl8723bs/include/ieee80211.h
@@ -850,18 +850,18 @@ enum ieee80211_state {
#define IP_FMT "%pI4"
#define IP_ARG(x) (x)
-extern __inline int is_multicast_mac_addr(const u8 *addr)
+static inline int is_multicast_mac_addr(const u8 *addr)
{
return ((addr[0] != 0xff) && (0x01 & addr[0]));
}
-extern __inline int is_broadcast_mac_addr(const u8 *addr)
+static inline int is_broadcast_mac_addr(const u8 *addr)
{
return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) &&
\
(addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff));
}
-extern __inline int is_zero_mac_addr(const u8 *addr)
+static inline int is_zero_mac_addr(const u8 *addr)
{
return ((addr[0] == 0x00) && (addr[1] == 0x00) && (addr[2] == 0x00) &&
\
(addr[3] == 0x00) && (addr[4] == 0x00) && (addr[5] == 0x00));
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: erofs: fix memleak of inode's shared xattr array
On 2019/2/14 15:10, Gao Xiang wrote:
>
>
> On 2019/2/14 14:46, Sheng Yong wrote:
>> If it fails to read a shared xattr page, the inode's shared xattr array
>> is not freed. The next time the inode's xattr is accessed, the previously
>> allocated array is leaked.
Nice catch!
>>
>> Signed-off-by: Sheng Yong
>
> LGTM,
>
> Fixes: b17500a0fdba ("staging: erofs: introduce xattr & acl support")
> Cc: # 4.19+
> Reviewed-by: Gao Xiang
Reviewed-by: Chao Yu
Thanks,
>
> [and there is also another race condition in it, but different root cause.
> let me fix it later independently...]
>
> Thanks,
> Gao Xiang
>
> .
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.14 25/40] staging: android: ion: Support cpu access during dma_buf_detach
From: Liam Mark
[ Upstream commit 31eb79db420a3f94c4c45a8c0a05cd30e333f981 ]
Often userspace doesn't know when the kernel will be calling dma_buf_detach
on the buffer.
If userpace starts its CPU access at the same time as the sg list is being
freed it could end up accessing the sg list after it has been freed.
Thread AThread B
- DMA_BUF_IOCTL_SYNC IOCT
- ion_dma_buf_begin_cpu_access
- list_for_each_entry
- ion_dma_buf_detatch
- free_duped_table
- dma_sync_sg_for_cpu
Fix this by getting the ion_buffer lock before freeing the sg table memory.
Fixes: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing and
mapping")
Signed-off-by: Liam Mark
Acked-by: Laura Abbott
Acked-by: Andrew F. Davis
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/android/ion/ion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 24cb666c9224..dd96ca61a515 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -257,10 +257,10 @@ static void ion_dma_buf_detatch(struct dma_buf *dmabuf,
struct ion_dma_buf_attachment *a = attachment->priv;
struct ion_buffer *buffer = dmabuf->priv;
- free_duped_table(a->table);
mutex_lock(>lock);
list_del(>list);
mutex_unlock(>lock);
+ free_duped_table(a->table);
kfree(a);
}
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/2] staging: erofs: complete POSIX ACL support
Hi Dan, Any suggestion? On 2019/2/3 10:52, Chao Yu wrote: > Sorry for the delay due to business travel. > > On 2019/1/29 2:30, Dan Carpenter wrote: >> On Tue, Jan 29, 2019 at 12:41:55AM +0800, Chao Yu wrote: >>> Hi Dan and Xiang, >>> >>> On 2019-1-28 21:48, Gao Xiang wrote: Hi Dan, On 2019/1/28 21:33, Dan Carpenter wrote: > Hopefully, regular kmalloc() is enough. > > Do really need the erofs_kmalloc() function? Regular kmalloc() has > fault injection already. Have you tried to use it? >>> >>> Yes, I think we'd better to use erofs_kmalloc(). :) >>> >>> Actually, fault injection in erofs_kmalloc only affect erofs module, we can >>> expect that the range of fault can be limited in erofs code, rather than >>> whole >>> kernel, so the test point can be aimed at more accurately. >>> >> >> Are you serious? The standard fault injection doesn't do that??? > > Oh, I just realized the common fault injection can inject into specified > module with function granularity, sorry. > >> >> Please fix it instead of creating a duplicate better implementation >> which only your filesystem can use. I would have thought that obviously > > I agreed that it will be good to make common fault injection better, > covering more cases, so that it can benefit all modules which need fault > injection functionality. But rather than injecting kmalloc, there will be > other injection demands from erofs/f2fs, like injecting in the middle of > their specified function, how could we do that? Could you give us advice? > > Thanks, > >> any fault injection framework could at least be configured to test >> specific code... >> >> regards, >> dan carpenter >> >> >> . >> > > > . > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.14 17/40] staging: rtl8723bs: Fix build error with Clang when inlining is disabled
From: Nathan Chancellor
[ Upstream commit 97715058b70da1262fd07798c8b2e3e894f759dd ]
When CONFIG_NO_AUTO_INLINE was present in linux-next (which added
'-fno-inline-functions' to KBUILD_CFLAGS), an allyesconfig build with
Clang failed at the modpost stage:
ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
These functions were marked as extern inline, meaning that if inlining
doesn't happen, the function will be undefined, as it is above.
This happens to work with GCC because the '-fno-inline-functions' option
respects the __inline attribute so all instances of these functions are
inlined as expected and the definition doesn't actually matter. However,
with Clang and '-fno-inline-functions', a function has to be marked with
the __always_inline attribute to be considered for inlining, which none
of these functions are. Clang tries to find the symbol definition
elsewhere as it was told and fails, which trickles down to modpost.
To make sure that this code compiles regardless of compiler and make the
intention of the code clearer, use 'static' to ensure these functions
are always defined, regardless of inlining. Additionally, silence a
checkpatch warning by switching from '__inline' to 'inline'.
Signed-off-by: Nathan Chancellor
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/rtl8723bs/include/ieee80211.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/include/ieee80211.h
b/drivers/staging/rtl8723bs/include/ieee80211.h
index 73ce63770c3c..fa9c80fc7773 100644
--- a/drivers/staging/rtl8723bs/include/ieee80211.h
+++ b/drivers/staging/rtl8723bs/include/ieee80211.h
@@ -1008,18 +1008,18 @@ enum ieee80211_state {
#define IP_FMT "%pI4"
#define IP_ARG(x) (x)
-extern __inline int is_multicast_mac_addr(const u8 *addr)
+static inline int is_multicast_mac_addr(const u8 *addr)
{
return ((addr[0] != 0xff) && (0x01 & addr[0]));
}
-extern __inline int is_broadcast_mac_addr(const u8 *addr)
+static inline int is_broadcast_mac_addr(const u8 *addr)
{
return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) &&
\
(addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff));
}
-extern __inline int is_zero_mac_addr(const u8 *addr)
+static inline int is_zero_mac_addr(const u8 *addr)
{
return ((addr[0] == 0x00) && (addr[1] == 0x00) && (addr[2] == 0x00) &&
\
(addr[3] == 0x00) && (addr[4] == 0x00) && (addr[5] == 0x00));
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.19 47/65] hv_netvsc: Fix ethtool change hash key error
From: Haiyang Zhang
[ Upstream commit b4a10c750424e01b5e37372fef0a574ebf7b56c3 ]
Hyper-V hosts require us to disable RSS before changing RSS key,
otherwise the changing request will fail. This patch fixes the
coding error.
Fixes: ff4a44199012 ("netvsc: allow get/set of RSS indirection table")
Reported-by: Wei Hu
Signed-off-by: Haiyang Zhang
Reviewed-by: Michael Kelley
[sl: fix up subject line]
Signed-off-by: Sasha Levin
---
drivers/net/hyperv/rndis_filter.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 2a5209f23f29..0b05f7ebeb01 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -715,8 +715,8 @@ rndis_filter_set_offload_params(struct net_device *ndev,
return ret;
}
-int rndis_filter_set_rss_param(struct rndis_device *rdev,
- const u8 *rss_key)
+static int rndis_set_rss_param_msg(struct rndis_device *rdev,
+ const u8 *rss_key, u16 flag)
{
struct net_device *ndev = rdev->ndev;
struct rndis_request *request;
@@ -745,7 +745,7 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
rssp->hdr.type = NDIS_OBJECT_TYPE_RSS_PARAMETERS;
rssp->hdr.rev = NDIS_RECEIVE_SCALE_PARAMETERS_REVISION_2;
rssp->hdr.size = sizeof(struct ndis_recv_scale_param);
- rssp->flag = 0;
+ rssp->flag = flag;
rssp->hashinfo = NDIS_HASH_FUNC_TOEPLITZ | NDIS_HASH_IPV4 |
NDIS_HASH_TCP_IPV4 | NDIS_HASH_IPV6 |
NDIS_HASH_TCP_IPV6;
@@ -770,9 +770,12 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
wait_for_completion(>wait_event);
set_complete = >response_msg.msg.set_complete;
- if (set_complete->status == RNDIS_STATUS_SUCCESS)
- memcpy(rdev->rss_key, rss_key, NETVSC_HASH_KEYLEN);
- else {
+ if (set_complete->status == RNDIS_STATUS_SUCCESS) {
+ if (!(flag & NDIS_RSS_PARAM_FLAG_DISABLE_RSS) &&
+ !(flag & NDIS_RSS_PARAM_FLAG_HASH_KEY_UNCHANGED))
+ memcpy(rdev->rss_key, rss_key, NETVSC_HASH_KEYLEN);
+
+ } else {
netdev_err(ndev, "Fail to set RSS parameters:0x%x\n",
set_complete->status);
ret = -EINVAL;
@@ -783,6 +786,16 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
return ret;
}
+int rndis_filter_set_rss_param(struct rndis_device *rdev,
+ const u8 *rss_key)
+{
+ /* Disable RSS before change */
+ rndis_set_rss_param_msg(rdev, rss_key,
+ NDIS_RSS_PARAM_FLAG_DISABLE_RSS);
+
+ return rndis_set_rss_param_msg(rdev, rss_key, 0);
+}
+
static int rndis_filter_query_device_link_status(struct rndis_device *dev,
struct netvsc_device
*net_device)
{
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.19 49/65] hv_netvsc: Fix hash key value reset after other ops
From: Haiyang Zhang
[ Upstream commit 17d91256898402daf4425cc541ac9cbf64574d9a ]
Changing mtu, channels, or buffer sizes ops call to netvsc_attach(),
rndis_set_subchannel(), which always reset the hash key to default
value. That will override hash key changed previously. This patch
fixes the problem by save the hash key, then restore it when we re-
add the netvsc device.
Fixes: ff4a44199012 ("netvsc: allow get/set of RSS indirection table")
Signed-off-by: Haiyang Zhang
Reviewed-by: Michael Kelley
[sl: fix up subject line]
Signed-off-by: Sasha Levin
---
drivers/net/hyperv/hyperv_net.h | 10 +++---
drivers/net/hyperv/netvsc.c | 2 +-
drivers/net/hyperv/netvsc_drv.c | 5 -
drivers/net/hyperv/rndis_filter.c | 9 +++--
4 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index a32ded5b4f41..42d284669b03 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -144,6 +144,8 @@ struct hv_netvsc_packet {
u32 total_data_buflen;
};
+#define NETVSC_HASH_KEYLEN 40
+
struct netvsc_device_info {
unsigned char mac_adr[ETH_ALEN];
u32 num_chn;
@@ -151,6 +153,8 @@ struct netvsc_device_info {
u32 recv_sections;
u32 send_section_size;
u32 recv_section_size;
+
+ u8 rss_key[NETVSC_HASH_KEYLEN];
};
enum rndis_device_state {
@@ -160,8 +164,6 @@ enum rndis_device_state {
RNDIS_DEV_DATAINITIALIZED,
};
-#define NETVSC_HASH_KEYLEN 40
-
struct rndis_device {
struct net_device *ndev;
@@ -210,7 +212,9 @@ int netvsc_recv_callback(struct net_device *net,
void netvsc_channel_cb(void *context);
int netvsc_poll(struct napi_struct *napi, int budget);
-int rndis_set_subchannel(struct net_device *ndev, struct netvsc_device *nvdev);
+int rndis_set_subchannel(struct net_device *ndev,
+struct netvsc_device *nvdev,
+struct netvsc_device_info *dev_info);
int rndis_filter_open(struct netvsc_device *nvdev);
int rndis_filter_close(struct netvsc_device *nvdev);
struct netvsc_device *rndis_filter_device_add(struct hv_device *dev,
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index fe01e141c8f8..1a942feab954 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -84,7 +84,7 @@ static void netvsc_subchan_work(struct work_struct *w)
rdev = nvdev->extension;
if (rdev) {
- ret = rndis_set_subchannel(rdev->ndev, nvdev);
+ ret = rndis_set_subchannel(rdev->ndev, nvdev, NULL);
if (ret == 0) {
netif_device_attach(rdev->ndev);
} else {
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index bece935567c1..c9e2a986ccb7 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -875,6 +875,9 @@ static struct netvsc_device_info *netvsc_devinfo_get
dev_info->send_section_size = nvdev->send_section_size;
dev_info->recv_sections = nvdev->recv_section_cnt;
dev_info->recv_section_size = nvdev->recv_section_size;
+
+ memcpy(dev_info->rss_key, nvdev->extension->rss_key,
+ NETVSC_HASH_KEYLEN);
} else {
dev_info->num_chn = VRSS_CHANNEL_DEFAULT;
dev_info->send_sections = NETVSC_DEFAULT_TX;
@@ -937,7 +940,7 @@ static int netvsc_attach(struct net_device *ndev,
return PTR_ERR(nvdev);
if (nvdev->num_chn > 1) {
- ret = rndis_set_subchannel(ndev, nvdev);
+ ret = rndis_set_subchannel(ndev, nvdev, dev_info);
/* if unavailable, just proceed with one queue */
if (ret) {
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 0b05f7ebeb01..53c6039bffb6 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1075,7 +1075,9 @@ static void netvsc_sc_open(struct vmbus_channel *new_sc)
* This breaks overlap of processing the host message for the
* new primary channel with the initialization of sub-channels.
*/
-int rndis_set_subchannel(struct net_device *ndev, struct netvsc_device *nvdev)
+int rndis_set_subchannel(struct net_device *ndev,
+struct netvsc_device *nvdev,
+struct netvsc_device_info *dev_info)
{
struct nvsp_message *init_packet = >channel_init_pkt;
struct net_device_context *ndev_ctx = netdev_priv(ndev);
@@ -1116,7 +1118,10 @@ int rndis_set_subchannel(struct net_device *ndev, struct
netvsc_device *nvdev)
atomic_read(>open_chn) == nvdev->num_chn);
/* ignore failues from setting rss parameters, still have channels */
- rndis_filter_set_rss_param(rdev, netvsc_hash_key);
+ if (dev_info)
+
[PATCH AUTOSEL 4.19 48/65] hv_netvsc: Refactor assignments of struct netvsc_device_info
From: Haiyang Zhang
[ Upstream commit 7c9f335a3ff20557a92584199f3d35c7e992bbe5 ]
These assignments occur in multiple places. The patch refactor them
to a function for simplicity. It also puts the struct to heap area
for future expension.
Signed-off-by: Haiyang Zhang
Reviewed-by: Michael Kelley
[sl: fix up subject line]
Signed-off-by: Sasha Levin
---
drivers/net/hyperv/netvsc_drv.c | 134
1 file changed, 85 insertions(+), 49 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 1c37a821895b..bece935567c1 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -856,6 +856,36 @@ static void netvsc_get_channels(struct net_device *net,
}
}
+/* Alloc struct netvsc_device_info, and initialize it from either existing
+ * struct netvsc_device, or from default values.
+ */
+static struct netvsc_device_info *netvsc_devinfo_get
+ (struct netvsc_device *nvdev)
+{
+ struct netvsc_device_info *dev_info;
+
+ dev_info = kzalloc(sizeof(*dev_info), GFP_ATOMIC);
+
+ if (!dev_info)
+ return NULL;
+
+ if (nvdev) {
+ dev_info->num_chn = nvdev->num_chn;
+ dev_info->send_sections = nvdev->send_section_cnt;
+ dev_info->send_section_size = nvdev->send_section_size;
+ dev_info->recv_sections = nvdev->recv_section_cnt;
+ dev_info->recv_section_size = nvdev->recv_section_size;
+ } else {
+ dev_info->num_chn = VRSS_CHANNEL_DEFAULT;
+ dev_info->send_sections = NETVSC_DEFAULT_TX;
+ dev_info->send_section_size = NETVSC_SEND_SECTION_SIZE;
+ dev_info->recv_sections = NETVSC_DEFAULT_RX;
+ dev_info->recv_section_size = NETVSC_RECV_SECTION_SIZE;
+ }
+
+ return dev_info;
+}
+
static int netvsc_detach(struct net_device *ndev,
struct netvsc_device *nvdev)
{
@@ -941,7 +971,7 @@ static int netvsc_set_channels(struct net_device *net,
struct net_device_context *net_device_ctx = netdev_priv(net);
struct netvsc_device *nvdev = rtnl_dereference(net_device_ctx->nvdev);
unsigned int orig, count = channels->combined_count;
- struct netvsc_device_info device_info;
+ struct netvsc_device_info *device_info;
int ret;
/* We do not support separate count for rx, tx, or other */
@@ -960,24 +990,26 @@ static int netvsc_set_channels(struct net_device *net,
orig = nvdev->num_chn;
- memset(_info, 0, sizeof(device_info));
- device_info.num_chn = count;
- device_info.send_sections = nvdev->send_section_cnt;
- device_info.send_section_size = nvdev->send_section_size;
- device_info.recv_sections = nvdev->recv_section_cnt;
- device_info.recv_section_size = nvdev->recv_section_size;
+ device_info = netvsc_devinfo_get(nvdev);
+
+ if (!device_info)
+ return -ENOMEM;
+
+ device_info->num_chn = count;
ret = netvsc_detach(net, nvdev);
if (ret)
- return ret;
+ goto out;
- ret = netvsc_attach(net, _info);
+ ret = netvsc_attach(net, device_info);
if (ret) {
- device_info.num_chn = orig;
- if (netvsc_attach(net, _info))
+ device_info->num_chn = orig;
+ if (netvsc_attach(net, device_info))
netdev_err(net, "restoring channel setting failed\n");
}
+out:
+ kfree(device_info);
return ret;
}
@@ -1044,48 +1076,45 @@ static int netvsc_change_mtu(struct net_device *ndev,
int mtu)
struct net_device *vf_netdev = rtnl_dereference(ndevctx->vf_netdev);
struct netvsc_device *nvdev = rtnl_dereference(ndevctx->nvdev);
int orig_mtu = ndev->mtu;
- struct netvsc_device_info device_info;
+ struct netvsc_device_info *device_info;
int ret = 0;
if (!nvdev || nvdev->destroy)
return -ENODEV;
+ device_info = netvsc_devinfo_get(nvdev);
+
+ if (!device_info)
+ return -ENOMEM;
+
/* Change MTU of underlying VF netdev first. */
if (vf_netdev) {
ret = dev_set_mtu(vf_netdev, mtu);
if (ret)
- return ret;
+ goto out;
}
- memset(_info, 0, sizeof(device_info));
- device_info.num_chn = nvdev->num_chn;
- device_info.send_sections = nvdev->send_section_cnt;
- device_info.send_section_size = nvdev->send_section_size;
- device_info.recv_sections = nvdev->recv_section_cnt;
- device_info.recv_section_size = nvdev->recv_section_size;
-
ret = netvsc_detach(ndev, nvdev);
if (ret)
goto rollback_vf;
ndev->mtu = mtu;
- ret = netvsc_attach(ndev, _info);
- if (ret)
-
[PATCH AUTOSEL 4.19 39/65] staging: android: ion: Support cpu access during dma_buf_detach
From: Liam Mark
[ Upstream commit 31eb79db420a3f94c4c45a8c0a05cd30e333f981 ]
Often userspace doesn't know when the kernel will be calling dma_buf_detach
on the buffer.
If userpace starts its CPU access at the same time as the sg list is being
freed it could end up accessing the sg list after it has been freed.
Thread AThread B
- DMA_BUF_IOCTL_SYNC IOCT
- ion_dma_buf_begin_cpu_access
- list_for_each_entry
- ion_dma_buf_detatch
- free_duped_table
- dma_sync_sg_for_cpu
Fix this by getting the ion_buffer lock before freeing the sg table memory.
Fixes: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing and
mapping")
Signed-off-by: Liam Mark
Acked-by: Laura Abbott
Acked-by: Andrew F. Davis
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/android/ion/ion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 99073325b0c0..45c7f829e387 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -237,10 +237,10 @@ static void ion_dma_buf_detatch(struct dma_buf *dmabuf,
struct ion_dma_buf_attachment *a = attachment->priv;
struct ion_buffer *buffer = dmabuf->priv;
- free_duped_table(a->table);
mutex_lock(>lock);
list_del(>list);
mutex_unlock(>lock);
+ free_duped_table(a->table);
kfree(a);
}
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.20 56/77] hv_netvsc: Refactor assignments of struct netvsc_device_info
From: Haiyang Zhang
[ Upstream commit 7c9f335a3ff20557a92584199f3d35c7e992bbe5 ]
These assignments occur in multiple places. The patch refactor them
to a function for simplicity. It also puts the struct to heap area
for future expension.
Signed-off-by: Haiyang Zhang
Reviewed-by: Michael Kelley
[sl: fix up subject line]
Signed-off-by: Sasha Levin
---
drivers/net/hyperv/netvsc_drv.c | 134
1 file changed, 85 insertions(+), 49 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index cf36e7ff3191..4055e12fce9a 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -857,6 +857,36 @@ static void netvsc_get_channels(struct net_device *net,
}
}
+/* Alloc struct netvsc_device_info, and initialize it from either existing
+ * struct netvsc_device, or from default values.
+ */
+static struct netvsc_device_info *netvsc_devinfo_get
+ (struct netvsc_device *nvdev)
+{
+ struct netvsc_device_info *dev_info;
+
+ dev_info = kzalloc(sizeof(*dev_info), GFP_ATOMIC);
+
+ if (!dev_info)
+ return NULL;
+
+ if (nvdev) {
+ dev_info->num_chn = nvdev->num_chn;
+ dev_info->send_sections = nvdev->send_section_cnt;
+ dev_info->send_section_size = nvdev->send_section_size;
+ dev_info->recv_sections = nvdev->recv_section_cnt;
+ dev_info->recv_section_size = nvdev->recv_section_size;
+ } else {
+ dev_info->num_chn = VRSS_CHANNEL_DEFAULT;
+ dev_info->send_sections = NETVSC_DEFAULT_TX;
+ dev_info->send_section_size = NETVSC_SEND_SECTION_SIZE;
+ dev_info->recv_sections = NETVSC_DEFAULT_RX;
+ dev_info->recv_section_size = NETVSC_RECV_SECTION_SIZE;
+ }
+
+ return dev_info;
+}
+
static int netvsc_detach(struct net_device *ndev,
struct netvsc_device *nvdev)
{
@@ -942,7 +972,7 @@ static int netvsc_set_channels(struct net_device *net,
struct net_device_context *net_device_ctx = netdev_priv(net);
struct netvsc_device *nvdev = rtnl_dereference(net_device_ctx->nvdev);
unsigned int orig, count = channels->combined_count;
- struct netvsc_device_info device_info;
+ struct netvsc_device_info *device_info;
int ret;
/* We do not support separate count for rx, tx, or other */
@@ -961,24 +991,26 @@ static int netvsc_set_channels(struct net_device *net,
orig = nvdev->num_chn;
- memset(_info, 0, sizeof(device_info));
- device_info.num_chn = count;
- device_info.send_sections = nvdev->send_section_cnt;
- device_info.send_section_size = nvdev->send_section_size;
- device_info.recv_sections = nvdev->recv_section_cnt;
- device_info.recv_section_size = nvdev->recv_section_size;
+ device_info = netvsc_devinfo_get(nvdev);
+
+ if (!device_info)
+ return -ENOMEM;
+
+ device_info->num_chn = count;
ret = netvsc_detach(net, nvdev);
if (ret)
- return ret;
+ goto out;
- ret = netvsc_attach(net, _info);
+ ret = netvsc_attach(net, device_info);
if (ret) {
- device_info.num_chn = orig;
- if (netvsc_attach(net, _info))
+ device_info->num_chn = orig;
+ if (netvsc_attach(net, device_info))
netdev_err(net, "restoring channel setting failed\n");
}
+out:
+ kfree(device_info);
return ret;
}
@@ -1047,48 +1079,45 @@ static int netvsc_change_mtu(struct net_device *ndev,
int mtu)
struct net_device *vf_netdev = rtnl_dereference(ndevctx->vf_netdev);
struct netvsc_device *nvdev = rtnl_dereference(ndevctx->nvdev);
int orig_mtu = ndev->mtu;
- struct netvsc_device_info device_info;
+ struct netvsc_device_info *device_info;
int ret = 0;
if (!nvdev || nvdev->destroy)
return -ENODEV;
+ device_info = netvsc_devinfo_get(nvdev);
+
+ if (!device_info)
+ return -ENOMEM;
+
/* Change MTU of underlying VF netdev first. */
if (vf_netdev) {
ret = dev_set_mtu(vf_netdev, mtu);
if (ret)
- return ret;
+ goto out;
}
- memset(_info, 0, sizeof(device_info));
- device_info.num_chn = nvdev->num_chn;
- device_info.send_sections = nvdev->send_section_cnt;
- device_info.send_section_size = nvdev->send_section_size;
- device_info.recv_sections = nvdev->recv_section_cnt;
- device_info.recv_section_size = nvdev->recv_section_size;
-
ret = netvsc_detach(ndev, nvdev);
if (ret)
goto rollback_vf;
ndev->mtu = mtu;
- ret = netvsc_attach(ndev, _info);
- if (ret)
-
[PATCH AUTOSEL 4.20 55/77] hv_netvsc: Fix ethtool change hash key error
From: Haiyang Zhang
[ Upstream commit b4a10c750424e01b5e37372fef0a574ebf7b56c3 ]
Hyper-V hosts require us to disable RSS before changing RSS key,
otherwise the changing request will fail. This patch fixes the
coding error.
Fixes: ff4a44199012 ("netvsc: allow get/set of RSS indirection table")
Reported-by: Wei Hu
Signed-off-by: Haiyang Zhang
Reviewed-by: Michael Kelley
[sl: fix up subject line]
Signed-off-by: Sasha Levin
---
drivers/net/hyperv/rndis_filter.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 8b537a049c1e..a4661d396e3c 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -774,8 +774,8 @@ rndis_filter_set_offload_params(struct net_device *ndev,
return ret;
}
-int rndis_filter_set_rss_param(struct rndis_device *rdev,
- const u8 *rss_key)
+static int rndis_set_rss_param_msg(struct rndis_device *rdev,
+ const u8 *rss_key, u16 flag)
{
struct net_device *ndev = rdev->ndev;
struct rndis_request *request;
@@ -804,7 +804,7 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
rssp->hdr.type = NDIS_OBJECT_TYPE_RSS_PARAMETERS;
rssp->hdr.rev = NDIS_RECEIVE_SCALE_PARAMETERS_REVISION_2;
rssp->hdr.size = sizeof(struct ndis_recv_scale_param);
- rssp->flag = 0;
+ rssp->flag = flag;
rssp->hashinfo = NDIS_HASH_FUNC_TOEPLITZ | NDIS_HASH_IPV4 |
NDIS_HASH_TCP_IPV4 | NDIS_HASH_IPV6 |
NDIS_HASH_TCP_IPV6;
@@ -829,9 +829,12 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
wait_for_completion(>wait_event);
set_complete = >response_msg.msg.set_complete;
- if (set_complete->status == RNDIS_STATUS_SUCCESS)
- memcpy(rdev->rss_key, rss_key, NETVSC_HASH_KEYLEN);
- else {
+ if (set_complete->status == RNDIS_STATUS_SUCCESS) {
+ if (!(flag & NDIS_RSS_PARAM_FLAG_DISABLE_RSS) &&
+ !(flag & NDIS_RSS_PARAM_FLAG_HASH_KEY_UNCHANGED))
+ memcpy(rdev->rss_key, rss_key, NETVSC_HASH_KEYLEN);
+
+ } else {
netdev_err(ndev, "Fail to set RSS parameters:0x%x\n",
set_complete->status);
ret = -EINVAL;
@@ -842,6 +845,16 @@ int rndis_filter_set_rss_param(struct rndis_device *rdev,
return ret;
}
+int rndis_filter_set_rss_param(struct rndis_device *rdev,
+ const u8 *rss_key)
+{
+ /* Disable RSS before change */
+ rndis_set_rss_param_msg(rdev, rss_key,
+ NDIS_RSS_PARAM_FLAG_DISABLE_RSS);
+
+ return rndis_set_rss_param_msg(rdev, rss_key, 0);
+}
+
static int rndis_filter_query_device_link_status(struct rndis_device *dev,
struct netvsc_device
*net_device)
{
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.20 47/77] staging: android: ion: Support cpu access during dma_buf_detach
From: Liam Mark
[ Upstream commit 31eb79db420a3f94c4c45a8c0a05cd30e333f981 ]
Often userspace doesn't know when the kernel will be calling dma_buf_detach
on the buffer.
If userpace starts its CPU access at the same time as the sg list is being
freed it could end up accessing the sg list after it has been freed.
Thread AThread B
- DMA_BUF_IOCTL_SYNC IOCT
- ion_dma_buf_begin_cpu_access
- list_for_each_entry
- ion_dma_buf_detatch
- free_duped_table
- dma_sync_sg_for_cpu
Fix this by getting the ion_buffer lock before freeing the sg table memory.
Fixes: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing and
mapping")
Signed-off-by: Liam Mark
Acked-by: Laura Abbott
Acked-by: Andrew F. Davis
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/android/ion/ion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 99073325b0c0..45c7f829e387 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -237,10 +237,10 @@ static void ion_dma_buf_detatch(struct dma_buf *dmabuf,
struct ion_dma_buf_attachment *a = attachment->priv;
struct ion_buffer *buffer = dmabuf->priv;
- free_duped_table(a->table);
mutex_lock(>lock);
list_del(>list);
mutex_unlock(>lock);
+ free_duped_table(a->table);
kfree(a);
}
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.20 57/77] hv_netvsc: Fix hash key value reset after other ops
From: Haiyang Zhang
[ Upstream commit 17d91256898402daf4425cc541ac9cbf64574d9a ]
Changing mtu, channels, or buffer sizes ops call to netvsc_attach(),
rndis_set_subchannel(), which always reset the hash key to default
value. That will override hash key changed previously. This patch
fixes the problem by save the hash key, then restore it when we re-
add the netvsc device.
Fixes: ff4a44199012 ("netvsc: allow get/set of RSS indirection table")
Signed-off-by: Haiyang Zhang
Reviewed-by: Michael Kelley
[sl: fix up subject line]
Signed-off-by: Sasha Levin
---
drivers/net/hyperv/hyperv_net.h | 10 +++---
drivers/net/hyperv/netvsc.c | 2 +-
drivers/net/hyperv/netvsc_drv.c | 5 -
drivers/net/hyperv/rndis_filter.c | 9 +++--
4 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index ef6f766f6389..e598a684700b 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -144,6 +144,8 @@ struct hv_netvsc_packet {
u32 total_data_buflen;
};
+#define NETVSC_HASH_KEYLEN 40
+
struct netvsc_device_info {
unsigned char mac_adr[ETH_ALEN];
u32 num_chn;
@@ -151,6 +153,8 @@ struct netvsc_device_info {
u32 recv_sections;
u32 send_section_size;
u32 recv_section_size;
+
+ u8 rss_key[NETVSC_HASH_KEYLEN];
};
enum rndis_device_state {
@@ -160,8 +164,6 @@ enum rndis_device_state {
RNDIS_DEV_DATAINITIALIZED,
};
-#define NETVSC_HASH_KEYLEN 40
-
struct rndis_device {
struct net_device *ndev;
@@ -209,7 +211,9 @@ int netvsc_recv_callback(struct net_device *net,
void netvsc_channel_cb(void *context);
int netvsc_poll(struct napi_struct *napi, int budget);
-int rndis_set_subchannel(struct net_device *ndev, struct netvsc_device *nvdev);
+int rndis_set_subchannel(struct net_device *ndev,
+struct netvsc_device *nvdev,
+struct netvsc_device_info *dev_info);
int rndis_filter_open(struct netvsc_device *nvdev);
int rndis_filter_close(struct netvsc_device *nvdev);
struct netvsc_device *rndis_filter_device_add(struct hv_device *dev,
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 922054c1d544..1910810e55bd 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -84,7 +84,7 @@ static void netvsc_subchan_work(struct work_struct *w)
rdev = nvdev->extension;
if (rdev) {
- ret = rndis_set_subchannel(rdev->ndev, nvdev);
+ ret = rndis_set_subchannel(rdev->ndev, nvdev, NULL);
if (ret == 0) {
netif_device_attach(rdev->ndev);
} else {
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 4055e12fce9a..80d9297ad9d9 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -876,6 +876,9 @@ static struct netvsc_device_info *netvsc_devinfo_get
dev_info->send_section_size = nvdev->send_section_size;
dev_info->recv_sections = nvdev->recv_section_cnt;
dev_info->recv_section_size = nvdev->recv_section_size;
+
+ memcpy(dev_info->rss_key, nvdev->extension->rss_key,
+ NETVSC_HASH_KEYLEN);
} else {
dev_info->num_chn = VRSS_CHANNEL_DEFAULT;
dev_info->send_sections = NETVSC_DEFAULT_TX;
@@ -938,7 +941,7 @@ static int netvsc_attach(struct net_device *ndev,
return PTR_ERR(nvdev);
if (nvdev->num_chn > 1) {
- ret = rndis_set_subchannel(ndev, nvdev);
+ ret = rndis_set_subchannel(ndev, nvdev, dev_info);
/* if unavailable, just proceed with one queue */
if (ret) {
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index a4661d396e3c..db81378e6624 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1134,7 +1134,9 @@ static void netvsc_sc_open(struct vmbus_channel *new_sc)
* This breaks overlap of processing the host message for the
* new primary channel with the initialization of sub-channels.
*/
-int rndis_set_subchannel(struct net_device *ndev, struct netvsc_device *nvdev)
+int rndis_set_subchannel(struct net_device *ndev,
+struct netvsc_device *nvdev,
+struct netvsc_device_info *dev_info)
{
struct nvsp_message *init_packet = >channel_init_pkt;
struct net_device_context *ndev_ctx = netdev_priv(ndev);
@@ -1175,7 +1177,10 @@ int rndis_set_subchannel(struct net_device *ndev, struct
netvsc_device *nvdev)
atomic_read(>open_chn) == nvdev->num_chn);
/* ignore failues from setting rss parameters, still have channels */
- rndis_filter_set_rss_param(rdev, netvsc_hash_key);
+ if (dev_info)
+
[PATCH AUTOSEL 4.20 35/77] staging: rtl8723bs: Fix build error with Clang when inlining is disabled
From: Nathan Chancellor
[ Upstream commit 97715058b70da1262fd07798c8b2e3e894f759dd ]
When CONFIG_NO_AUTO_INLINE was present in linux-next (which added
'-fno-inline-functions' to KBUILD_CFLAGS), an allyesconfig build with
Clang failed at the modpost stage:
ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
These functions were marked as extern inline, meaning that if inlining
doesn't happen, the function will be undefined, as it is above.
This happens to work with GCC because the '-fno-inline-functions' option
respects the __inline attribute so all instances of these functions are
inlined as expected and the definition doesn't actually matter. However,
with Clang and '-fno-inline-functions', a function has to be marked with
the __always_inline attribute to be considered for inlining, which none
of these functions are. Clang tries to find the symbol definition
elsewhere as it was told and fails, which trickles down to modpost.
To make sure that this code compiles regardless of compiler and make the
intention of the code clearer, use 'static' to ensure these functions
are always defined, regardless of inlining. Additionally, silence a
checkpatch warning by switching from '__inline' to 'inline'.
Signed-off-by: Nathan Chancellor
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/rtl8723bs/include/ieee80211.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/include/ieee80211.h
b/drivers/staging/rtl8723bs/include/ieee80211.h
index bcc8dfa8e672..9efb4dcb9d3a 100644
--- a/drivers/staging/rtl8723bs/include/ieee80211.h
+++ b/drivers/staging/rtl8723bs/include/ieee80211.h
@@ -850,18 +850,18 @@ enum ieee80211_state {
#define IP_FMT "%pI4"
#define IP_ARG(x) (x)
-extern __inline int is_multicast_mac_addr(const u8 *addr)
+static inline int is_multicast_mac_addr(const u8 *addr)
{
return ((addr[0] != 0xff) && (0x01 & addr[0]));
}
-extern __inline int is_broadcast_mac_addr(const u8 *addr)
+static inline int is_broadcast_mac_addr(const u8 *addr)
{
return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) &&
\
(addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff));
}
-extern __inline int is_zero_mac_addr(const u8 *addr)
+static inline int is_zero_mac_addr(const u8 *addr)
{
return ((addr[0] == 0x00) && (addr[1] == 0x00) && (addr[2] == 0x00) &&
\
(addr[3] == 0x00) && (addr[4] == 0x00) && (addr[5] == 0x00));
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/2] PCI: hv: Refactor hv_irq_unmask() to use hv_vpset and cpumask_to_vpset()
On Wed, Feb 13, 2019 at 03:15:49PM +, Lorenzo Pieralisi wrote: On Mon, Jan 28, 2019 at 11:15:37PM -0800, Maya Nakamura wrote: This patchset removes a duplicate definition of VP set (hv_vp_set) and uses the common definition (hv_vpset) that is used in other places. It changes the order of the members in struct hv_pcibus_device due to flexible array in hv_vpset. It also removes the duplicate implementation of cpumask_to_vpset(), uses the shared implementation, and exports hv_max_vp_index, which is required by cpumask_to_vpset(). Maya Nakamura (2): PCI: hv: Replace hv_vp_set with hv_vpset PCI: hv: Refactor hv_irq_unmask() to use cpumask_to_vpset() arch/x86/hyperv/hv_init.c | 1 + drivers/pci/controller/pci-hyperv.c | 59 + 2 files changed, 28 insertions(+), 32 deletions(-) I need a maintainer ACK to merge this series. Acked-by: Sasha Levin -- Thanks, Sasha ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] Drivers: hv: vmbus: Expose counters for interrupts and full conditions
On Mon, Feb 04, 2019 at 04:25:34PM +, Michael Kelley wrote: From: Kimberly Brown Sent: Sunday, February 3, 2019 11:13 PM Counter values for per-channel interrupts and ring buffer full conditions are useful for investigating performance. Expose counters in sysfs for 2 types of guest to host interrupts: 1) Interrupts caused by the channel's outbound ring buffer transitioning from empty to not empty 2) Interrupts caused by the channel's inbound ring buffer transitioning from full to not full while a packet is waiting for enough buffer space to become available Expose 2 counters in sysfs for the number of times that write operations encountered a full outbound ring buffer: 1) The total number of write operations that encountered a full condition 2) The number of write operations that were the first to encounter a full condition Increment the outbound full condition counters in the hv_ringbuffer_write() function because, for most drivers, a full outbound ring buffer is detected in that function. Also increment the outbound full condition counters in the set_channel_pending_send_size() function. In the hv_sock driver, a full outbound ring buffer is detected and set_channel_pending_send_size() is called before hv_ringbuffer_write() is called. I tested this patch by confirming that the sysfs files were created and observing the counter values. The values seemed to increase by a reasonable amount when the Hyper-v related drivers were in use. Signed-off-by: Kimberly Brown --- Reviewed-by: Michael Kelley Queued for hyperv-next, thanks Kimberly! -- Thanks, Sasha ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show functions
On Sat, Feb 02, 2019 at 03:07:35PM -0500, Kimberly Brown wrote: On Fri, Feb 01, 2019 at 06:24:24PM +, Dexuan Cui wrote: > From: Kimberly Brown > Sent: Thursday, January 31, 2019 9:47 AM > ... > 2) Prevent a deadlock that can occur between the proposed mutex_lock() > call in the vmbus_chan_attr_show() function and the sysfs/kernfs functions. Hi Kim, Can you please share more details about the deadlock? It's unclear to me how the deadlock happens. Hi Dexuan, I encountered the deadlock by: 1) Adding a call to msleep() before acquiring the mutex in vmbus_chan_attr_show() 2) Opening a hv_netvsc subchannel's sysfs file 3) Removing hv_netvsc while the sysfs file is opening Dexuan, any objections to pulling this fix in? -- Thanks, Sasha ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: android: ashmem: Don't allow range_alloc() to fail.
Joel Fernandes wrote:
> I am sorry, what has changed in the updated patch? Please send clear diff
> notes in your patches or at least mention exactly what changed since previous
> patch revision. It is very difficult to review if you don't even mention what
> changed since previous revision. Please resend the patches again.
>
> Also I am OK with assuming small alloc success, so we are on the same page
> about that.
>
> One more comment below..
>
> Thanks!
>
> > @@ -722,10 +719,17 @@ static int ashmem_pin_unpin(struct ashmem_area *asma,
> > unsigned long cmd,
> > struct ashmem_pin pin;
> > size_t pgstart, pgend;
> > int ret = -EINVAL;
> > + struct ashmem_range *range = NULL;
> >
> > if (copy_from_user(, p, sizeof(pin)))
> > return -EFAULT;
> >
> > + if (cmd == ASHMEM_PIN || cmd == ASHMEM_UNPIN) {
> > + range = kmem_cache_zalloc(ashmem_range_cachep, GFP_KERNEL);
> > + if (!range)
> > + return -ENOMEM;
>
> According to the too-small-to-fail rule, why are you checking for errors
> here?
The "too small to fail" memory-allocation rule is not __GFP_NOFAIL; it is
almost __GFP_NOFAIL.
Small __GFP_NOFAIL allocation might fail if current thread was killed by the
OOM killer or
memory allocation fault injection forced it to fail. And syzbot is finding many
bugs (using
memory allocation fault injection) where the caller is not checking for
allocation failures.
The old patch tried to allow syzbot to test this module by using __GFP_NOFAIL
(i.e. minimal
change), and the new patch is trying to allow syzbot to test this module by
moving
small __GFP_KERNEL allocation out of ashmem_mutex (i.e. cleaner change).
>
> > + }
> > +
> > mutex_lock(_mutex);
> > wait_event(ashmem_shrink_wait, !atomic_read(_shrink_inflight));
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] binder: fix handling of misaligned binder object
Fixes crash found by syzbot: kernel BUG at drivers/android/binder_alloc.c:LINE! (2) Reported-by: syzbot+55de1eb4975dec156...@syzkaller.appspotmail.com Signed-off-by: Todd Kjos --- Applies to linux-next drivers/android/binder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index 2dba539eb792c..8685882da64cd 100644 --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -2057,7 +2057,7 @@ static size_t binder_get_object(struct binder_proc *proc, size_t object_size = 0; read_size = min_t(size_t, sizeof(*object), buffer->data_size - offset); - if (read_size < sizeof(*hdr)) + if (read_size < sizeof(*hdr) || !IS_ALIGNED(offset, sizeof(u32))) return 0; binder_alloc_copy_from_buffer(>alloc, object, buffer, offset, read_size); -- 2.21.0.rc0.258.g878e2cd30e-goog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: kernel BUG at drivers/android/binder_alloc.c:LINE! (2)
Hello, syzbot has tested the proposed patch and the reproducer did not trigger crash: Reported-and-tested-by: syzbot+55de1eb4975dec156...@syzkaller.appspotmail.com Tested on: commit: b3418f8bddf4 Add linux-next specific files for 20190214 git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master kernel config: https://syzkaller.appspot.com/x/.config?x=8a3a37525a677c71 compiler: gcc (GCC) 9.0.0 20181231 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=139c8f50c0 Note: testing is done by a robot and is best-effort only. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: kernel BUG at drivers/android/binder_alloc.c:LINE! (2)
On Thu, Feb 14, 2019 at 3:35 AM syzbot wrote: > > syzbot has found a reproducer for the following crash on: > > HEAD commit:b3418f8bddf4 Add linux-next specific files for 20190214 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=161d2048c0 > kernel config: https://syzkaller.appspot.com/x/.config?x=8a3a37525a677c71 > dashboard link: https://syzkaller.appspot.com/bug?extid=55de1eb4975dec156d8f > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11cd2f1f40 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+55de1eb4975dec156...@syzkaller.appspotmail.com > Testing a fix: #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git linux-next patch Description: Binary data ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: kernel BUG at drivers/android/binder_alloc.c:LINE! (2)
Hello, syzbot tried to test the proposed patch but build/boot failed: failed to checkout kernel repo https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/linux-next: failed to run ["git" "fetch" "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git; "linux-next"]: exit status 128 fatal: Couldn't find remote ref linux-next Tested on: commit: [unknown] git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git linux-next compiler: gcc (GCC) 9.0.0 20181231 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=17832048c0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/7] binder: create userspace-to-binder-buffer copy function
On Thu, Feb 14, 2019 at 01:55:19PM -0800, 'Todd Kjos' via kernel-team wrote: > On Thu, Feb 14, 2019 at 1:25 PM Joel Fernandes wrote: > > > > On Thu, Feb 14, 2019 at 03:53:54PM -0500, Joel Fernandes wrote: > > > On Thu, Feb 14, 2019 at 3:42 PM Todd Kjos wrote: > > > > > > > > On Thu, Feb 14, 2019 at 11:45 AM Joel Fernandes > > > > wrote: > > > [snip] > > > > > > + * check_buffer() - verify that buffer/offset is safe to access > > > > > > + * @alloc: binder_alloc for this proc > > > > > > + * @buffer: binder buffer to be accessed > > > > > > + * @offset: offset into @buffer data > > > > > > + * @bytes: bytes to access from offset > > > > > > + * > > > > > > + * Check that the @offset/@bytes are within the size of the given > > > > > > + * @buffer and that the buffer is currently active and not > > > > > > freeable. > > > > > > + * Offsets must also be multiples of sizeof(u32). The kernel is > > > > > > > > > > In all callers of binder_alloc_copy_user_to_buffer, the alignment of > > > > > offsets > > > > > is set to sizeof(void *). Then shouldn't this function check for > > > > > sizeof(void *) > > > > > alignment instead of u32? > > > > > > > > But there are other callers of check_buffer() later in the series that > > > > don't require pointer-size alignment. u32 alignment is consistent with > > > > the alignment requirements of the binder driver before this change. > > > > The copy functions don't actually need to insist on alignment, but > > > > these binder buffer objects have always used u32 alignment which has > > > > been checked in the driver. If user code misaligned it, then errors > > > > are returned. The alignment checks are really to be consistent with > > > > previous binder driver behavior. > > > > > > Got it, thanks. > > > > One more thing I wanted to ask is, kmap() will now cause global lock > > contention because of using spin_lock due to kmap_high(). > > > > Previously the binder driver was made to not use global lock (as you had > > done). Now these paths will start global locking on 32-bit architectures. > > Would that degrade performance? > > There was a lot of concern about 32-bit performance both for > lock-contention and the cost of map/unmap operations. Of course, > 32-bit systems are also where the primary win is -- namely avoiding > vmalloc space depletion. So there was a several months-long evaluation > period on 32-bit devices by a silicon vendor who did a lot of testing > across a broad set of benchmarks / workloads to verify the performance > costs are acceptable. We also ran tests to try to exhaust the kmap > space with multiple large buffers. > > The testing did find that there is some performance degradation for > large buffer transfers, but there are no cases where this > significantly impacted a meaningful user workload. > > > > > Are we not using kmap_atomic() in this patch because of any concern that the > > kmap fixmap space is limited and may run out? > > We're not using the atomic version here since we can't guarantee that > the loop will be atomic since we are calling copy_from_user(). Later > in the series, other cases do use kmap_atomic(). Got it, thanks for all the clarifications, - Joel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android: use multiple futex wait queues
> > Use multiple per-offset wait queues instead of one big wait queue per > > region. > > > > Signed-off-by: Hugo Lefeuvre > > Have you tested this? > > Noticed any performance speedups or slow downs? Not yet. I have started to set up a cuttlefish test environment but it might take some time until I am able to fully test these changes myself (having some trouble to find documentation)... I will post the results here when ready. thanks! regards, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/7] binder: create userspace-to-binder-buffer copy function
On Thu, Feb 14, 2019 at 03:53:54PM -0500, Joel Fernandes wrote: > On Thu, Feb 14, 2019 at 3:42 PM Todd Kjos wrote: > > > > On Thu, Feb 14, 2019 at 11:45 AM Joel Fernandes wrote: > [snip] > > > > + * check_buffer() - verify that buffer/offset is safe to access > > > > + * @alloc: binder_alloc for this proc > > > > + * @buffer: binder buffer to be accessed > > > > + * @offset: offset into @buffer data > > > > + * @bytes: bytes to access from offset > > > > + * > > > > + * Check that the @offset/@bytes are within the size of the given > > > > + * @buffer and that the buffer is currently active and not freeable. > > > > + * Offsets must also be multiples of sizeof(u32). The kernel is > > > > > > In all callers of binder_alloc_copy_user_to_buffer, the alignment of > > > offsets > > > is set to sizeof(void *). Then shouldn't this function check for > > > sizeof(void *) > > > alignment instead of u32? > > > > But there are other callers of check_buffer() later in the series that > > don't require pointer-size alignment. u32 alignment is consistent with > > the alignment requirements of the binder driver before this change. > > The copy functions don't actually need to insist on alignment, but > > these binder buffer objects have always used u32 alignment which has > > been checked in the driver. If user code misaligned it, then errors > > are returned. The alignment checks are really to be consistent with > > previous binder driver behavior. > > Got it, thanks. One more thing I wanted to ask is, kmap() will now cause global lock contention because of using spin_lock due to kmap_high(). Previously the binder driver was made to not use global lock (as you had done). Now these paths will start global locking on 32-bit architectures. Would that degrade performance? Are we not using kmap_atomic() in this patch because of any concern that the kmap fixmap space is limited and may run out? thanks, - Joel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/7] binder: create userspace-to-binder-buffer copy function
On Thu, Feb 14, 2019 at 3:42 PM Todd Kjos wrote: > > On Thu, Feb 14, 2019 at 11:45 AM Joel Fernandes wrote: [snip] > > > + * check_buffer() - verify that buffer/offset is safe to access > > > + * @alloc: binder_alloc for this proc > > > + * @buffer: binder buffer to be accessed > > > + * @offset: offset into @buffer data > > > + * @bytes: bytes to access from offset > > > + * > > > + * Check that the @offset/@bytes are within the size of the given > > > + * @buffer and that the buffer is currently active and not freeable. > > > + * Offsets must also be multiples of sizeof(u32). The kernel is > > > > In all callers of binder_alloc_copy_user_to_buffer, the alignment of offsets > > is set to sizeof(void *). Then shouldn't this function check for > > sizeof(void *) > > alignment instead of u32? > > But there are other callers of check_buffer() later in the series that > don't require pointer-size alignment. u32 alignment is consistent with > the alignment requirements of the binder driver before this change. > The copy functions don't actually need to insist on alignment, but > these binder buffer objects have always used u32 alignment which has > been checked in the driver. If user code misaligned it, then errors > are returned. The alignment checks are really to be consistent with > previous binder driver behavior. Got it, thanks. - Joel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 4/4] staging: iio: ad7780: moving ad7780 out of staging
On 02/09, Jonathan Cameron wrote: On Tue, 5 Feb 2019 15:14:03 -0200 Renato Lui Geh wrote: Move ad7780 ADC driver out of staging and into the mainline. The ad7780 is a sigma-delta analog to digital converter. This driver provides reading voltage values and status bits from both the ad778x and ad717x series. Its interface also allows writing on the FILTER and GAIN GPIO pins on the ad778x. Signed-off-by: Renato Lui Geh Signed-off-by: Giuliano Belinassi Co-developed-by: Giuliano Belinassi This needs a device tree binding doc which should be reviewed before we move the driver out of staging. Make sure to cc the dt-binding maintainers and list. Doesn't really matter if that patch is before or after this one in the series but needs to be in the same series. Ok! I see that some Analog dt-bindings are prefixed by adi and some are not. Should I follow any naming standard? There are a few more minor tidy ups that would be nice to have inline given you are doing a v4. Stuff like this could have been cleaned up after moving out of staging (nothing wrong with improving non staging drivers after all) but always better to do it whilst we remember! --- Changes in v3: - Changes unrelated to moving the driver to main tree were resent as individual patches drivers/iio/adc/Kconfig | 13 ++ drivers/iio/adc/Makefile | 1 + drivers/iio/adc/ad7780.c | 359 +++ drivers/staging/iio/adc/Kconfig | 13 -- drivers/staging/iio/adc/Makefile | 1 - drivers/staging/iio/adc/ad7780.c | 359 --- 6 files changed, 373 insertions(+), 373 deletions(-) create mode 100644 drivers/iio/adc/ad7780.c delete mode 100644 drivers/staging/iio/adc/ad7780.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index f3cc7a31bce5..2cdee166d0e9 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -108,6 +108,19 @@ config AD7766 To compile this driver as a module, choose M here: the module will be called ad7766. +config AD7780 + tristate "Analog Devices AD7780 and similar ADCs driver" + depends on SPI + depends on GPIOLIB || COMPILE_TEST + select AD_SIGMA_DELTA + help + Say yes here to build support for Analog Devices AD7170, AD7171, + AD7780 and AD7781 SPI analog to digital converters (ADC). + If unsure, say N (but it's safe to say "Y"). I wouldn't bother with this statement, doesn't add any real info! + + To compile this driver as a module, choose M here: the + module will be called ad7780. + config AD7791 tristate "Analog Devices AD7791 ADC driver" depends on SPI diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index ea5031348052..b48852157115 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o obj-$(CONFIG_AD7606) += ad7606.o obj-$(CONFIG_AD7766) += ad7766.o +obj-$(CONFIG_AD7780) += ad7780.o obj-$(CONFIG_AD7791) += ad7791.o obj-$(CONFIG_AD7793) += ad7793.o obj-$(CONFIG_AD7887) += ad7887.o diff --git a/drivers/iio/adc/ad7780.c b/drivers/iio/adc/ad7780.c new file mode 100644 index ..163e3c983598 --- /dev/null +++ b/drivers/iio/adc/ad7780.c @@ -0,0 +1,359 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * AD7170/AD7171 and AD7780/AD7781 SPI ADC driver + * + * Copyright 2011 Analog Devices Inc. I think you have done more than enough to this driver to add an additional copyright line if you want to! Oh wow, that'd be awesome! Thanks! Should I just add my full name there? + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#define AD7780_RDY BIT(7) +#define AD7780_FILTER BIT(6) +#define AD7780_ERR BIT(5) +#define AD7780_ID1 BIT(4) +#define AD7780_ID0 BIT(3) +#define AD7780_GAINBIT(2) +#define AD7780_PAT1BIT(1) +#define AD7780_PAT0BIT(0) These two bits of pattern don't really add anything. I'd drop them in favour of something like #define AD7780_PATTERN_GOOD 1 #define AD7780_PATTERN_MASK GENMASK(1, 0) Same for ID for that matter. These aren't one bit fields, so we shouldn't ever present them as such (though the datasheet confusingly sort of does so!) + +#define AD7780_PATTERN (AD7780_PAT0) +#define AD7780_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1) + +#define AD7170_PAT2BIT(2) + +#define AD7170_PATTERN (AD7780_PAT0 | AD7170_PAT2) +#define AD7170_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2) I'd use a value for the pattern directly and GENMASK for the mask. + +#define AD7780_GAIN_GPIO 0 +#define AD7780_FILTER_GPIO 1 + +#define AD7780_GAIN_MIDPOINT 64 +#define
Re: [PATCH v3 1/4] staging: iio: ad7780: add gain & filter gpio support
Hi Jonathan,
Thanks for the review. Comments inline.
Renato
On 02/09, Jonathan Cameron wrote:
On Tue, 5 Feb 2019 15:13:00 -0200
Renato Lui Geh wrote:
Previously, the AD7780 driver only supported gpio for the 'powerdown'
pin. This commit adds suppport for the 'gain' and 'filter' pin.
Signed-off-by: Renato Lui Geh
Signed-off-by: Giuliano Belinassi
Co-developed-by: Giuliano Belinassi
Comments inline.
---
Changes in v3:
- Renamed ad7780_chip_info's filter to odr
- Renamed ad778x_filter to ad778x_odr_avail
- Changed vref variable from unsigned int to unsigned long long to
avoid overflow
- Removed unnecessary AD_SD_CHANNEL macro
drivers/staging/iio/adc/ad7780.c | 95 ++--
1 file changed, 89 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c
index c4a85789c2db..6e4357800d31 100644
--- a/drivers/staging/iio/adc/ad7780.c
+++ b/drivers/staging/iio/adc/ad7780.c
@@ -39,6 +39,15 @@
#define AD7170_PATTERN (AD7780_PAT0 | AD7170_PAT2)
#define AD7170_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2)
+#define AD7780_GAIN_GPIO 0
+#define AD7780_FILTER_GPIO 1
What are these for?
Sorry about that. That's leftover from a previous attempt.
+
+#define AD7780_GAIN_MIDPOINT 64
+#define AD7780_FILTER_MIDPOINT 13350
+
+static const unsigned int ad778x_gain[2] = { 1, 128 };
+static const unsigned int ad778x_odr_avail[2] = { 1, 16700 };
+
struct ad7780_chip_info {
struct iio_chan_specchannel;
unsigned intpattern_mask;
@@ -50,7 +59,11 @@ struct ad7780_state {
const struct ad7780_chip_info *chip_info;
struct regulator*reg;
struct gpio_desc*powerdown_gpio;
- unsigned intgain;
+ struct gpio_desc*gain_gpio;
+ struct gpio_desc*filter_gpio;
+ unsigned intgain;
+ unsigned intodr;
+ unsigned intint_vref_mv;
struct ad_sigma_delta sd;
};
@@ -104,17 +117,65 @@ static int ad7780_read_raw(struct iio_dev *indio_dev,
voltage_uv = regulator_get_voltage(st->reg);
if (voltage_uv < 0)
return voltage_uv;
- *val = (voltage_uv / 1000) * st->gain;
+ voltage_uv /= 1000;
+ *val = voltage_uv * st->gain;
*val2 = chan->scan_type.realbits - 1;
+ st->int_vref_mv = voltage_uv;
return IIO_VAL_FRACTIONAL_LOG2;
case IIO_CHAN_INFO_OFFSET:
*val = -(1 << (chan->scan_type.realbits - 1));
return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ *val = st->odr;
+ return IIO_VAL_INT;
}
return -EINVAL;
}
+static int ad7780_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val,
+ int val2,
+ long m)
+{
+ struct ad7780_state *st = iio_priv(indio_dev);
+ const struct ad7780_chip_info *chip_info = st->chip_info;
+ unsigned long long vref;
+ unsigned int full_scale, gain;
+
+ if (!chip_info->is_ad778x)
+ return 0;
+
+ switch (m) {
+ case IIO_CHAN_INFO_SCALE:
+ if (val != 0)
+ return -EINVAL;
+
+ vref = st->int_vref_mv * 100LL;
+ full_scale = 1 << (chip_info->channel.scan_type.realbits - 1);
+ gain = DIV_ROUND_CLOSEST(vref, full_scale);
+ gain = DIV_ROUND_CLOSEST(gain, val2);
+ st->gain = gain;
+ if (gain < AD7780_GAIN_MIDPOINT)
+ gain = 0;
+ else
+ gain = 1;
+ gpiod_set_value(st->gain_gpio, gain);
+ break;
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ if (1000*val + val2/1000 < AD7780_FILTER_MIDPOINT)
+ val = 0;
+ else
+ val = 1;
+ st->odr = ad778x_odr_avail[val];
+ gpiod_set_value(st->filter_gpio, val);
+ break;
+ }
+
+ return 0;
+}
+
static int ad7780_postprocess_sample(struct ad_sigma_delta *sigma_delta,
unsigned int raw_sample)
{
@@ -126,10 +187,8 @@ static int ad7780_postprocess_sample(struct ad_sigma_delta
*sigma_delta,
return -EIO;
if (chip_info->is_ad778x) {
- if (raw_sample & AD7780_GAIN)
- st->gain = 1;
- else
- st->gain = 128;
+ st->gain = ad778x_gain[raw_sample & AD7780_GAIN];
+ st->odr = ad778x_odr_avail[raw_sample & AD7780_FILTER];
}
return 0;
@@
Re: [PATCH 2/2] Drivers: hv: vmbus: Display nothing in sysfs if monitor_allocated not set
On Thu, 14 Feb 2019 01:11:03 -0500
Kimberly Brown wrote:
> On Mon, Feb 11, 2019 at 10:02:47AM -0800, Stephen Hemminger wrote:
> > On Mon, 11 Feb 2019 02:01:18 -0500
> > Kimberly Brown wrote:
> >
> > > On Fri, Feb 08, 2019 at 02:32:09PM -0800, Stephen Hemminger wrote:
> > > > On Fri, 8 Feb 2019 05:01:12 -0500
> > > > Kimberly Brown wrote:
> > > >
> > > > You are right, the current behavior is broken.
> > > > It would be good to add a description of under what conditions
> > > > monitor is not used. Is this some part of a project emulating
> > > > Hyper-V?
> > > >
> > >
> > > I'm not sure which conditions determine whether the monitor mechanism is
> > > used. I've searched the Hypervisor TLFS, and I couldn't find any
> > > information. If you have any suggestions for where I can find this
> > > information, please let me know.
> >
> > The monitor page stuff pre-dates my involvement with Hyper-V. KY might know.
> > But based on comments it looks like it was added to avoid hypercalls
> > for each message. It probably showed up in Windows Server 2012 timeframe.
> >
> > To test you might want to dig up Windows Server 2008.
> >
>
> It looks like the monitor mechanism has always been used. It's present in the
> earliest commit that I can find: 3e7ee4902fe6 ("add the Hyper-V virtual bus")
> from 2009.
>
> I propose that the following sentences be added to the sysfs documentation for
> the affected attributes:
>
> "The monitor page mechanism is used for performance critical channels
> (storage,
> network, etc.). Channels that do not use the monitor page mechanism will
> return
> EINVAL."
>
> I think that this provides sufficient information for a user to understand why
> opening an affected file can return EINVAL. What do you think?
Thanks for following up. I agree with you EINVAL works as a solution.
My understanding is that their are two ways a channel can work. The first one is
for the guest to send a hyper call to the host to indicate when data is
available.
The other is for the guest to indicate by setting a bit in shared memory with
host.
The shared memory approach reduces host/guest overhead and allows for more
opportunities
for batching in the ring. The host checks the shared memory on a polling
interval
defined in the latency field.
The hypercall method does not use the monitor page. It has lower latency (no
polling).
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android: use multiple futex wait queues
On Thu, Feb 14, 2019 at 06:34:59PM +0100, Hugo Lefeuvre wrote: > Use multiple per-offset wait queues instead of one big wait queue per > region. > > Signed-off-by: Hugo Lefeuvre Have you tested this? Noticed any performance speedups or slow downs? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: android: ion: Allocate from heap ID directly without mask
On Mon, Jan 28, 2019 at 1:44 PM Andrew F. Davis wrote:
>
> Previously the heap to allocate from was selected by a mask of allowed
> heap types. This may have been done as a primitive form of constraint
> solving, the first heap type that matched any set bit of the heap mask
> was allocated from, unless that heap was excluded by having its heap
> ID bit not set in the separate passed in heap ID mask.
>
> The heap type does not really represent constraints that should be
> matched against to begin with. So the patch [0] removed the the heap type
> mask matching but unfortunately left the heap ID mask check (possibly by
> mistake or to preserve API). Therefor we now only have a mask of heap
> IDs, but heap IDs are unique identifiers and have nothing to do with the
> underlying heap, so mask matching is not useful here. This also limits us
> to 32 heaps total in a system.
>
> With the heap query API users can find the right heap based on type or
> name themselves then just supply the ID for that heap. Remove heap ID
> mask and allow users to specify heap ID directly by its number.
Sorry for the very late reply. I just dug this out of my spam box.
While this seems like a reasonable cleanup (ABI pain aside), I'm
curious as to other then the 32-heap limitation, what other benefits
this brings?
My hesitancy is that we still have fixed number to heap mapping.
Curious how this fits in (or if it would still be necessary) if we
finally moved to previously discussed per-heap device-nodes idea,
which is interesting to me as it avoids a fixed enumeration of heaps
in the kernel (and also allows for per heap permissions).
> I know this is an ABI break, but we are in staging so lets get this over
> with now rather than limit ourselves later.
>
> [0] commit 2bb9f5034ec7 ("gpu: ion: Remove heapmask from client")
>
> Signed-off-by: Andrew F. Davis
> ---
>
> This also means we don't need to store the available heaps in a plist,
> we only operation we care about is lookup, so a better data structure
> should be chosen at some point, regular list or xarray maybe?
>
> This is base on -next as to be on top of the other taken Ion patches.
>
> Changes from v1:
> - Fix spelling in commit message
> - Cleanup logic per Brian's suggestion
>
Some thoughts, as this ABI break has the potential to be pretty painful.
1) Unfortunately, this ABI is exposed *through* libion via
ion_alloc/ion_alloc_fd out to gralloc implementations. Which means it
will have a wider impact to vendor userland code.
2) For patches that cause ABI breaks, it might be good to make it
clear in the commit what the userland impact looks like in userspace,
possibly with an example, so the poor folks who bisect down the change
as breaking their system in a year or so have a clear example as to
what they need to change in their code.
3) Also, its not clear how a given userland should distinguish between
the different ABIs. We already have logic in libion to distinguish
between pre-4.12 legacy and post-4.12 implementations (using implicit
ion_free() behavior). I don't see any such check we can make with this
code. Adding another ABI version may require we provide an actual
interface version ioctl.
thanks
-john
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging/android: use multiple futex wait queues
Use multiple per-offset wait queues instead of one big wait queue per
region.
Signed-off-by: Hugo Lefeuvre
---
This patch is based on the simplify handle_vsoc_cond_wait patchset,
currently under review: https://lkml.org/lkml/2019/2/7/870
---
drivers/staging/android/TODO | 4 ---
drivers/staging/android/vsoc.c | 56 ++
2 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index fbf015cc6d62..cd2af06341dc 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -12,10 +12,6 @@ ion/
- Better test framework (integration with VGEM was suggested)
vsoc.c, uapi/vsoc_shm.h
- - The current driver uses the same wait queue for all of the futexes in a
- region. This will cause false wakeups in regions with a large number of
- waiting threads. We should eventually use multiple queues and select the
- queue based on the region.
- Add debugfs support for examining the permissions of regions.
- Remove VSOC_WAIT_FOR_INCOMING_INTERRUPT ioctl. This functionality has been
superseded by the futex and is there for legacy reasons.
diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
index f2bb18158e5b..55b0ee03e7b8 100644
--- a/drivers/staging/android/vsoc.c
+++ b/drivers/staging/android/vsoc.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "uapi/vsoc_shm.h"
#define VSOC_DEV_NAME "vsoc"
@@ -62,11 +63,18 @@ static const int MAX_REGISTER_BAR_LEN = 0x100;
*/
static const int SHARED_MEMORY_BAR = 2;
+struct vsoc_futex_wait_queue_t {
+ struct list_head list;
+ u32 offset;
+ wait_queue_head_t queue;
+};
+
struct vsoc_region_data {
char name[VSOC_DEVICE_NAME_SZ + 1];
wait_queue_head_t interrupt_wait_queue;
- /* TODO(b/73664181): Use multiple futex wait queues */
- wait_queue_head_t futex_wait_queue;
+ /* Per-offset futex wait queue. */
+ struct list_head futex_wait_queue_list;
+ spinlock_t futex_wait_queue_lock;
/* Flag indicating that an interrupt has been signalled by the host. */
atomic_t *incoming_signalled;
/* Flag indicating the guest has signalled the host. */
@@ -402,6 +410,7 @@ static int handle_vsoc_cond_wait(struct file *filp, struct
vsoc_cond_wait *arg)
struct vsoc_region_data *data = vsoc_dev.regions_data + region_number;
int ret = 0;
struct vsoc_device_region *region_p = vsoc_region_from_filep(filp);
+ struct vsoc_futex_wait_queue_t *it, *wait_queue = NULL;
atomic_t *address = NULL;
ktime_t wake_time;
@@ -415,10 +424,27 @@ static int handle_vsoc_cond_wait(struct file *filp,
struct vsoc_cond_wait *arg)
address = shm_off_to_virtual_addr(region_p->region_begin_offset +
arg->offset);
+ /* Find wait queue corresponding to offset or create it */
+ spin_lock(>futex_wait_queue_lock);
+ list_for_each_entry(it, >futex_wait_queue_list, list) {
+ if (wait_queue->offset == arg->offset) {
+ wait_queue = it;
+ break;
+ }
+ }
+
+ if (!wait_queue) {
+ wait_queue = kmalloc(sizeof(*wait_queue), GFP_KERNEL);
+ wait_queue->offset = arg->offset;
+ init_waitqueue_head(_queue->queue);
+ list_add(_queue->list, >futex_wait_queue_list);
+ }
+ spin_unlock(>futex_wait_queue_lock);
+
/* Ensure that the type of wait is valid */
switch (arg->wait_type) {
case VSOC_WAIT_IF_EQUAL:
- ret = wait_event_freezable(data->futex_wait_queue,
+ ret = wait_event_freezable(wait_queue->queue,
arg->wakes++ &&
atomic_read(address) != arg->value);
break;
@@ -426,7 +452,7 @@ static int handle_vsoc_cond_wait(struct file *filp, struct
vsoc_cond_wait *arg)
if (arg->wake_time_nsec >= NSEC_PER_SEC)
return -EINVAL;
wake_time = ktime_set(arg->wake_time_sec, arg->wake_time_nsec);
- ret = wait_event_freezable_hrtimeout(data->futex_wait_queue,
+ ret = wait_event_freezable_hrtimeout(wait_queue->queue,
arg->wakes++ &&
atomic_read(address) !=
arg->value,
wake_time);
@@ -463,6 +489,7 @@ static int do_vsoc_cond_wake(struct file *filp, uint32_t
offset)
struct vsoc_device_region *region_p = vsoc_region_from_filep(filp);
u32 region_number = iminor(file_inode(filp));
struct vsoc_region_data *data = vsoc_dev.regions_data + region_number;
+ struct vsoc_futex_wait_queue_t *wait_queue;
/* Ensure that the
[PATCH v2 2/2] staging: iio: frequency: ad9834: Move phase and scale to standard iio attribute
The custom phase and scale attributes were moved to standard iio types.
Signed-off-by: Beniamin Bia
---
Changes in v2:
-the personal email address was replaced by the work email
-separate define for every phase channel
-enum used for write_phase functions
-phase variables were replaced by an array
drivers/staging/iio/frequency/ad9834.c | 53 --
1 file changed, 32 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/iio/frequency/ad9834.c
b/drivers/staging/iio/frequency/ad9834.c
index 561617046c20..4366b6121154 100644
--- a/drivers/staging/iio/frequency/ad9834.c
+++ b/drivers/staging/iio/frequency/ad9834.c
@@ -82,6 +82,7 @@ struct ad9834_state {
struct mutexlock; /* protect sensor state */
unsigned long frequency[2];
+ unsigned long phase[2];
/*
* DMA (thus cache coherency maintenance) requires the
@@ -113,6 +114,8 @@ enum ad9834_supported_device_ids {
.output = 1,\
.channel = (chan), \
.info_mask_separate = BIT(IIO_CHAN_INFO_FREQUENCY) \
+ | BIT(IIO_CHAN_INFO_PHASE),\
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
}
static const struct iio_chan_spec ad9833_channels[] = {
@@ -172,13 +175,26 @@ static int ad9834_write_frequency(struct ad9834_state *st,
}
static int ad9834_write_phase(struct ad9834_state *st,
- unsigned long addr, unsigned long phase)
+ enum ad9834_ch_addr addr,
+ unsigned long phase)
{
+ int ret;
+
if (phase > BIT(AD9834_PHASE_BITS))
return -EINVAL;
- st->data = cpu_to_be16(addr | phase);
- return spi_sync(st->spi, >msg);
+ if (addr == AD9834_CHANNEL_ADDRESS0)
+ st->data = cpu_to_be16(AD9834_REG_PHASE0 | phase);
+ else
+ st->data = cpu_to_be16(AD9834_REG_PHASE1 | phase);
+
+ ret = spi_sync(st->spi, >msg);
+ if (ret)
+ return ret;
+
+ st->phase[(int)addr] = phase;
+
+ return 0;
}
static int ad9834_read_raw(struct iio_dev *indio_dev,
@@ -191,6 +207,13 @@ static int ad9834_read_raw(struct iio_dev *indio_dev,
case IIO_CHAN_INFO_FREQUENCY:
*val = st->frequency[chan->channel];
return IIO_VAL_INT;
+ case IIO_CHAN_INFO_PHASE:
+ *val = st->phase[chan->channel];
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ /*1 hz */
+ *val = 1;
+ return IIO_VAL_INT;
}
return -EINVAL;
@@ -207,6 +230,10 @@ static int ad9834_write_raw(struct iio_dev *indio_dev,
return ad9834_write_frequency(st,
(enum
ad9834_ch_addr)chan->channel,
val);
+ case IIO_CHAN_INFO_PHASE:
+ return ad9834_write_phase(st,
+ (enum ad9834_ch_addr)chan->channel,
+ val);
default:
return -EINVAL;
}
@@ -231,10 +258,6 @@ static ssize_t ad9834_write(struct device *dev,
mutex_lock(>lock);
switch ((u32)this_attr->address) {
- case AD9834_REG_PHASE0:
- case AD9834_REG_PHASE1:
- ret = ad9834_write_phase(st, this_attr->address, val);
- break;
case AD9834_OPBITEN:
if (st->control & AD9834_MODE) {
ret = -EINVAL; /* AD9843 reserved mode */
@@ -394,12 +417,8 @@ static
IIO_DEVICE_ATTR(out_altvoltage0_out1_wavetype_available, 0444,
*/
static IIO_DEV_ATTR_FREQSYMBOL(0, 0200, NULL, ad9834_write, AD9834_FSEL);
-static IIO_CONST_ATTR_FREQ_SCALE(0, "1"); /* 1Hz */
-static IIO_DEV_ATTR_PHASE(0, 0, 0200, NULL, ad9834_write, AD9834_REG_PHASE0);
-static IIO_DEV_ATTR_PHASE(0, 1, 0200, NULL, ad9834_write, AD9834_REG_PHASE1);
static IIO_DEV_ATTR_PHASESYMBOL(0, 0200, NULL, ad9834_write, AD9834_PSEL);
-static IIO_CONST_ATTR_PHASE_SCALE(0, "0.0015339808"); /* 2PI/2^12 rad*/
static IIO_DEV_ATTR_PINCONTROL_EN(0, 0200, NULL,
ad9834_write, AD9834_PIN_SW);
@@ -410,10 +429,6 @@ static IIO_DEV_ATTR_OUT_WAVETYPE(0, 0,
ad9834_store_wavetype, 0);
static IIO_DEV_ATTR_OUT_WAVETYPE(0, 1, ad9834_store_wavetype, 1);
static struct attribute *ad9834_attributes[] = {
- _const_attr_out_altvoltage0_frequency_scale.dev_attr.attr,
- _dev_attr_out_altvoltage0_phase0.dev_attr.attr,
- _dev_attr_out_altvoltage0_phase1.dev_attr.attr,
- _const_attr_out_altvoltage0_phase_scale.dev_attr.attr,
_dev_attr_out_altvoltage0_pincontrol_en.dev_attr.attr,
[PATCH v2 1/2] staging: iio: frequency: ad9834: Move frequency to standard iio types
Frequency attribute is added with a standard type from iio framework
instead of custom attribute. This is a small step towards removing any
unnecessary custom attribute. Ad9834 will diverge from ad9833 in the
future, that is why we have two identical arrays for ad9834 and 9833.
Signed-off-by: Beniamin Bia
---
Changes in v2:
-the personal email address was replaced by the work email
-separate define for frequency channel
-address field from channel specification was removed
-frequency variables were replaced by an array
-specified in comment why we have differente chan_spec for ad9834 and
ad9833
-enum used for write_frequency function
drivers/staging/iio/frequency/ad9834.c | 110 -
1 file changed, 91 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/iio/frequency/ad9834.c
b/drivers/staging/iio/frequency/ad9834.c
index f036f75d1f22..561617046c20 100644
--- a/drivers/staging/iio/frequency/ad9834.c
+++ b/drivers/staging/iio/frequency/ad9834.c
@@ -81,6 +81,8 @@ struct ad9834_state {
struct spi_message freq_msg;
struct mutexlock; /* protect sensor state */
+ unsigned long frequency[2];
+
/*
* DMA (thus cache coherency maintenance) requires the
* transfer buffers to live in their own cache lines.
@@ -89,6 +91,11 @@ struct ad9834_state {
__be16 freq_data[2];
};
+enum ad9834_ch_addr {
+ AD9834_CHANNEL_ADDRESS0,
+ AD9834_CHANNEL_ADDRESS1,
+};
+
/**
* ad9834_supported_device_ids:
*/
@@ -100,6 +107,24 @@ enum ad9834_supported_device_ids {
ID_AD9838,
};
+#define AD9833_CHANNEL(chan) { \
+ .type = IIO_ALTVOLTAGE, \
+ .indexed = 1, \
+ .output = 1,\
+ .channel = (chan), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_FREQUENCY) \
+}
+
+static const struct iio_chan_spec ad9833_channels[] = {
+ AD9833_CHANNEL(0),
+ AD9833_CHANNEL(1),
+};
+
+static const struct iio_chan_spec ad9834_channels[] = {
+ AD9833_CHANNEL(0),
+ AD9833_CHANNEL(1),
+};
+
static unsigned int ad9834_calc_freqreg(unsigned long mclk, unsigned long fout)
{
unsigned long long freqreg = (u64)fout * (u64)BIT(AD9834_FREQ_BITS);
@@ -109,10 +134,12 @@ static unsigned int ad9834_calc_freqreg(unsigned long
mclk, unsigned long fout)
}
static int ad9834_write_frequency(struct ad9834_state *st,
- unsigned long addr, unsigned long fout)
+ enum ad9834_ch_addr addr,
+ unsigned long fout)
{
unsigned long clk_freq;
unsigned long regval;
+ int ret;
clk_freq = clk_get_rate(st->mclk);
@@ -121,13 +148,27 @@ static int ad9834_write_frequency(struct ad9834_state *st,
regval = ad9834_calc_freqreg(clk_freq, fout);
- st->freq_data[0] = cpu_to_be16(addr | (regval &
- RES_MASK(AD9834_FREQ_BITS / 2)));
- st->freq_data[1] = cpu_to_be16(addr | ((regval >>
- (AD9834_FREQ_BITS / 2)) &
- RES_MASK(AD9834_FREQ_BITS / 2)));
+ if (addr == AD9834_CHANNEL_ADDRESS0) {
+ st->freq_data[0] = cpu_to_be16(AD9834_REG_FREQ0 | (regval &
+ RES_MASK(AD9834_FREQ_BITS / 2)));
+ st->freq_data[1] = cpu_to_be16(AD9834_REG_FREQ0 | ((regval >>
+ (AD9834_FREQ_BITS / 2)) &
+ RES_MASK(AD9834_FREQ_BITS / 2)));
+ } else {
+ st->freq_data[0] = cpu_to_be16(AD9834_REG_FREQ1 | (regval &
+ RES_MASK(AD9834_FREQ_BITS / 2)));
+ st->freq_data[1] = cpu_to_be16(AD9834_REG_FREQ1 | ((regval >>
+ (AD9834_FREQ_BITS / 2)) &
+ RES_MASK(AD9834_FREQ_BITS / 2)));
+ }
+
+ ret = spi_sync(st->spi, >freq_msg);
+ if (ret)
+ return ret;
+
+ st->frequency[(int)addr] = fout;
- return spi_sync(st->spi, >freq_msg);
+ return 0;
}
static int ad9834_write_phase(struct ad9834_state *st,
@@ -140,6 +181,39 @@ static int ad9834_write_phase(struct ad9834_state *st,
return spi_sync(st->spi, >msg);
}
+static int ad9834_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct ad9834_state *st = iio_priv(indio_dev);
+
+ switch
Re: [PATCH V2 00/10] X86/KVM/Hyper-V: Add HV ept tlb range list flush support in KVM
On 02/02/19 02:38, lantianyu1...@gmail.com wrote: > From: Lan Tianyu > > This patchset is to introduce hv ept tlb range list flush function > support in the KVM MMU component. Flushing ept tlbs of several address > range can be done via single hypercall and new list flush function is > used in the kvm_mmu_commit_zap_page() and FNAME(sync_page). This patchset > also adds more hv ept tlb range flush support in more KVM MMU function. > > Change since v1: >1) Make flush list as a hlist instead of list in order to >keep struct kvm_mmu_page size. >2) Add last_level flag in the struct kvm_mmu_page instead >of spte pointer >3) Move tlb flush from kvm_mmu_notifier_clear_flush_young() to > kvm_age_hva() >4) Use range flush in the kvm_vm_ioctl_get/clear_dirty_log() Looks good except for the confusion on sp->last_level (which was mostly mine---sorry about that). I think it can still make 5.1. However, note that I've never received "KVM/MMU: Use tlb range flush in the kvm_age_hva()". Paolo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: android: ashmem: Don't allow range_alloc() to fail.
On Sat, Feb 09, 2019 at 11:24:03AM +0900, Tetsuo Handa wrote: > On 2019/02/08 23:45, Joel Fernandes wrote: > > On Wed, Feb 06, 2019 at 08:45:32AM +0900, Tetsuo Handa wrote: > >> Joel Fernandes wrote: > >>> On Tue, Feb 05, 2019 at 07:28:41PM +0900, Tetsuo Handa wrote: > ashmem_pin() is calling range_shrink() without checking whether > range_alloc() succeeded. Since memory allocation fault injection might > force range_alloc() to fail while range_alloc() is called for only once > for one ioctl() request, make range_alloc() not to fail. > >>> > >>> Why does this not need to fail? I am worried your change will introduce > >>> unwanted endless looping in the kernel instead of gracefully failing a > >>> pin/unpin request. > >> > >> This patch won't introduce endless looping in the kernel, due to a rule > >> called > >> > >> The "too small to fail" memory-allocation rule > >> https://lwn.net/Articles/627419/ > >> > >> . In short, memory allocation by range_alloc() might fail only if current > >> thread > >> was killed by the OOM killer or memory allocation fault injection mechanism > >> forced it to fail. And this patch helps doing fuzzing test with minimal > >> changes. > >> > >>> > >>> Unless there is a good reason, I suggest to drop this patch from the > >>> series; > >>> but let us discuss more if you want. > >> > >> We can allocate memory for range_alloc() before holding ashmem_mutex at > >> ashmem_pin_unpin() if you don't want to use __GFP_NOFAIL. It is better to > >> avoid memory allocation with ashmem_mutex because ashmem_mutex is held by > >> shrinker function. But given that this module is going to be replaced > >> shortly, > >> does it worth moving the memory allocation to the caller? > > > > Even if memory allocation does not fail right now, I still want to return > > the > > error code correctly via ashmem_pin_unpin() so that if in the future there > > are changes to the allocator algorithm, then a silent success isn't reported > > when a failure should be reported.. > > > > It doesn't make sense to return success when an allocation failed.. even if > > you are asking this code to rely on the allocator's "too small to fail" > > behavior.. can we guarantee this allocator behavior will always exist? > > Probably not. > > > > Does always exist. Small GFP_KERNEL allocation without __GFP_NORETRY or > __GFP_RETRY_MAYFAIL won't fail unless current thread was killed by the OOM > killer or memory allocation fault injection mechanism forced it to fail. > Failing such allocation instead of invoking the OOM killer is effectively > equivalent to sending SIGKILL to current thread. If current thread got > SIGKILL, current thread can't receive the error code of ioctl() from > ashmem_pin_unpin() because userspace code is no longer executed. > > MM people want to make !GFP_KERNEL memory allocations fail rather than > retry forever. But failing small GFP_KERNEL memory allocations is such > a horrible idea. Anyway, here is an updated patch... I am sorry, what has changed in the updated patch? Please send clear diff notes in your patches or at least mention exactly what changed since previous patch revision. It is very difficult to review if you don't even mention what changed since previous revision. Please resend the patches again. Also I am OK with assuming small alloc success, so we are on the same page about that. One more comment below.. Thanks! > From f2c8a098ebf69122fc440d9e9ca3c9cd786cce8a Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa > Date: Sat, 9 Feb 2019 11:07:07 +0900 > Subject: [PATCH] staging: android: ashmem: Avoid range_alloc() allocation with > ashmem_mutex held. > > ashmem_pin() is calling range_shrink() without checking whether > range_alloc() succeeded. Also, doing memory allocation with ashmem_mutex > held should be avoided because ashmem_shrink_scan() tries to hold it. > > Therefore, move memory allocation for range_alloc() to ashmem_pin_unpin() > and make range_alloc() not to fail. > > Signed-off-by: Tetsuo Handa > --- > drivers/staging/android/ashmem.c | 42 > +++- > 1 file changed, 24 insertions(+), 18 deletions(-) > > diff --git a/drivers/staging/android/ashmem.c > b/drivers/staging/android/ashmem.c > index ade8438..910826d 100644 > --- a/drivers/staging/android/ashmem.c > +++ b/drivers/staging/android/ashmem.c > @@ -171,19 +171,15 @@ static inline void lru_del(struct ashmem_range *range) > * @end:The ending page (inclusive) > * > * This function is protected by ashmem_mutex. > - * > - * Return: 0 if successful, or -ENOMEM if there is an error > */ > -static int range_alloc(struct ashmem_area *asma, > -struct ashmem_range *prev_range, unsigned int purged, > -size_t start, size_t end) > +static void range_alloc(struct ashmem_area *asma, > + struct ashmem_range *prev_range, unsigned int purged, > + size_t start,
Re: [PATCH net-next 3/9] mlxsw: spectrum: Check bridge flags during prepare phase
On Wed, Feb 13, 2019 at 02:06:32PM -0800, Florian Fainelli wrote:
> In preparation for getting rid of switchdev_port_attr_get(), have mlxsw
> check for the bridge flags being set through switchdev_port_attr_set()
> when the SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attribute identifier is
> used.
>
> Signed-off-by: Florian Fainelli
> ---
> .../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> index 1f492b7dbea8..7616eab50035 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> @@ -598,13 +598,17 @@ mlxsw_sp_bridge_port_learning_set(struct mlxsw_sp_port
> *mlxsw_sp_port,
> static int mlxsw_sp_port_attr_br_flags_set(struct mlxsw_sp_port
> *mlxsw_sp_port,
> struct switchdev_trans *trans,
> struct net_device *orig_dev,
> -unsigned long brport_flags)
> +unsigned long brport_flags,
> +bool pre_set)
> {
> struct mlxsw_sp_bridge_port *bridge_port;
> int err;
>
> - if (switchdev_trans_ph_prepare(trans))
> + if (switchdev_trans_ph_prepare(trans) && pre_set) {
> + if (brport_flags & ~(BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD))
> + return -EOPNOTSUPP;
> return 0;
> + }
When we get SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS we only want to
perform a check. With this code in case it's not prepare phase, then we
continue to set the flags. Better do:
if (pre_set) {
if (switchdev_trans_ph_commit(trans))
return 0;
// perform check here
}
>
> bridge_port = mlxsw_sp_bridge_port_find(mlxsw_sp_port->mlxsw_sp->bridge,
> orig_dev);
> @@ -833,6 +837,7 @@ static int mlxsw_sp_port_attr_set(struct net_device *dev,
> struct switchdev_trans *trans)
> {
> struct mlxsw_sp_port *mlxsw_sp_port = netdev_priv(dev);
> + bool pre_set = false;
> int err;
>
> switch (attr->id) {
> @@ -841,10 +846,13 @@ static int mlxsw_sp_port_attr_set(struct net_device
> *dev,
> attr->orig_dev,
> attr->u.stp_state);
> break;
> + case SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS:
> + pre_set = true; /* fall through */
> case SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS:
> err = mlxsw_sp_port_attr_br_flags_set(mlxsw_sp_port, trans,
> attr->orig_dev,
> - attr->u.brport_flags);
> + attr->u.brport_flags,
> + pre_set);
> break;
> case SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME:
> err = mlxsw_sp_port_attr_br_ageing_set(mlxsw_sp_port, trans,
> --
> 2.17.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 7/9] net: bridge: Stop calling switchdev_port_attr_get()
On Thu, Feb 14, 2019 at 01:20:02PM +0200, Ido Schimmel wrote:
> On Wed, Feb 13, 2019 at 02:06:36PM -0800, Florian Fainelli wrote:
> > Now that all switchdev drivers have been converted to checking the
> > bridge port flags during the prepare phase of the
> > switchdev_port_attr_set() when the process
> > SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS, we can avoid calling
> > switchdev_port_attr_get() with
> > SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT.
> >
> > Signed-off-by: Florian Fainelli
> > ---
> > net/bridge/br_switchdev.c | 16 +++-
> > 1 file changed, 7 insertions(+), 9 deletions(-)
> >
> > diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
> > index db9e8ab96d48..8f88f8a1a7fa 100644
> > --- a/net/bridge/br_switchdev.c
> > +++ b/net/bridge/br_switchdev.c
> > @@ -64,29 +64,27 @@ int br_switchdev_set_port_flag(struct net_bridge_port
> > *p,
> > {
> > struct switchdev_attr attr = {
> > .orig_dev = p->dev,
> > - .id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
> > + .id = SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS,
> > + .u.brport_flags = flags,
> > };
> > int err;
> >
> > if (mask & ~BR_PORT_FLAGS_HW_OFFLOAD)
> > return 0;
> >
> > - err = switchdev_port_attr_get(p->dev, );
> > - if (err == -EOPNOTSUPP)
> > - return 0;
> > - if (err)
> > + err = switchdev_port_attr_set(p->dev, );
> > + if (err && err != -EOPNOTSUPP)
> > return err;
> >
> > - /* Check if specific bridge flag attribute offload is supported */
> > - if (!(attr.u.brport_flags_support & mask)) {
> > + if (err == -EOPNOTSUPP) {
> > br_warn(p->br, "bridge flag offload is not supported %u(%s)\n",
> > (unsigned int)p->port_no, p->dev->name);
> > - return -EOPNOTSUPP;
> > + return err;
> > }
>
> I see that you return -EOPNOTSUPP from drivers in case of unsupported
> flags. I believe this is problematic (I'll test soon). The same return
> code is used by:
>
> 1. Switch drivers to indicate unsupported flags
> 2. switchdev code to indicate unsupported netdev (no switchdev ops)
>
> I guess that with this patch any attempt to set bridge port flags on
> veth/dummy device will result in an error.
Yea, that's the case. You can test with
tools/testing/selftests/net/forwarding/bridge_vlan_aware.sh and other
bridge-related tests we have there.
Another problem is that during PORT_PRE_BRIDGE_FLAGS you pass 'flags'
and not 'mask'. This breaks mlxsw (and probably others as well) given
BR_BCAST_FLOOD is set by default.
>
> >
> > attr.id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS;
> > attr.flags = SWITCHDEV_F_DEFER;
> > - attr.u.brport_flags = flags;
> > +
> > err = switchdev_port_attr_set(p->dev, );
> > if (err) {
> > br_warn(p->br, "error setting offload flag on port %u(%s)\n",
> > --
> > 2.17.1
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 9/9] net: Get rid of switchdev_port_attr_get()
On Wed, Feb 13, 2019 at 02:06:38PM -0800, Florian Fainelli wrote: > With the bridge no longer calling switchdev_port_attr_get() to obtain > the supported bridge port flags from a driver but instead trying to set > the bridge port flags directly and relying on driver to reject > unsupported configurations, we can effectively get rid of > switchdev_port_attr_get() entirely since this was the only place where > it was called. > > Signed-off-by: Florian Fainelli > --- > Documentation/networking/switchdev.txt | 5 ++--- > drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 7 --- > drivers/net/ethernet/rocker/rocker_main.c| 7 --- > drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 7 --- > include/net/switchdev.h | 8 > net/dsa/slave.c | 7 --- > 6 files changed, 2 insertions(+), 39 deletions(-) > > diff --git a/Documentation/networking/switchdev.txt > b/Documentation/networking/switchdev.txt > index ea90243340a9..327afe754230 100644 > --- a/Documentation/networking/switchdev.txt > +++ b/Documentation/networking/switchdev.txt > @@ -233,9 +233,8 @@ the bridge's FDB. It's possible, but not optimal, to > enable learning on the > device port and on the bridge port, and disable learning_sync. > > To support learning and learning_sync port attributes, the driver implements > -switchdev op switchdev_port_attr_get/set for > -SWITCHDEV_ATTR_PORT_ID_BRIDGE_FLAGS. The driver should initialize the > attributes > -to the hardware defaults. > +switchdev op switchdev_port_attr_set for SWITCHDEV_ATTR_PORT_ID_BRIDGE_FLAGS. > +The driver should initialize the attributes to the hardware defaults. Last sentence is not relevant anymore. learning_sync can also be dropped ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 8/9] net: Remove SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT
On Wed, Feb 13, 2019 at 02:06:37PM -0800, Florian Fainelli wrote: > Now that we have converted the bridge code and the drivers to check for > bridge port(s) flags at the time we try to set them, there is no need > for a get() -> set() sequence anymore and > SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT therefore becomes unused. > > Signed-off-by: Florian Fainelli Reviewed-by: Ido Schimmel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: kernel BUG at drivers/android/binder_alloc.c:LINE! (2)
syzbot has found a reproducer for the following crash on: HEAD commit:b3418f8bddf4 Add linux-next specific files for 20190214 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=161d2048c0 kernel config: https://syzkaller.appspot.com/x/.config?x=8a3a37525a677c71 dashboard link: https://syzkaller.appspot.com/bug?extid=55de1eb4975dec156d8f compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11cd2f1f40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+55de1eb4975dec156...@syzkaller.appspotmail.com binder: 7792:7794 transaction failed 29189/-22, size 24-8 line 2994 [ cut here ] kernel BUG at drivers/android/binder_alloc.c:1141! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 1 PID: 7794 Comm: syz-executor.5 Not tainted 5.0.0-rc6-next-20190214 #35 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:binder_alloc_do_buffer_copy+0xd6/0x510 drivers/android/binder_alloc.c:1141 Code: 02 00 0f 85 20 04 00 00 4d 8b 64 24 58 49 29 dc e8 9f e1 26 fc 4c 89 e6 4c 89 ef e8 b4 e2 26 fc 4d 39 e5 76 07 e8 8a e1 26 fc <0f> 0b e8 83 e1 26 fc 4c 8b 75 d0 4d 29 ec 4c 89 e6 4c 89 f7 e8 91 RSP: 0018:888051747558 EFLAGS: 00010293 RAX: 8880a55d8040 RBX: 20001000 RCX: 8549806c RDX: RSI: 85498076 RDI: 0006 RBP: 8880517475d8 R08: 8880a55d8040 R09: 0028 R10: ed100a2e8f01 R11: 88805174780f R12: 0020 R13: 0028 R14: 888096952b50 R15: FS: 7f526c1e3700() GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f526c1a0db8 CR3: 32547000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: binder_alloc_copy_from_buffer+0x37/0x42 drivers/android/binder_alloc.c:1187 binder_get_object+0xa2/0x1e0 drivers/android/binder.c:2062 binder_transaction+0x2b4a/0x6690 drivers/android/binder.c:3231 binder_thread_write+0x64a/0x2820 drivers/android/binder.c:3792 binder_ioctl_write_read drivers/android/binder.c:4825 [inline] binder_ioctl+0x1033/0x183b drivers/android/binder.c:5002 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457e29 Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f526c1e2c78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 0003 RCX: 00457e29 RDX: 2000 RSI: c0306201 RDI: 0006 RBP: 0073bf00 R08: R09: R10: R11: 0246 R12: 7f526c1e36d4 R13: 004bf15b R14: 004d0a60 R15: Modules linked in: ---[ end trace f34ec74539dae8b5 ]--- RIP: 0010:binder_alloc_do_buffer_copy+0xd6/0x510 drivers/android/binder_alloc.c:1141 Code: 02 00 0f 85 20 04 00 00 4d 8b 64 24 58 49 29 dc e8 9f e1 26 fc 4c 89 e6 4c 89 ef e8 b4 e2 26 fc 4d 39 e5 76 07 e8 8a e1 26 fc <0f> 0b e8 83 e1 26 fc 4c 8b 75 d0 4d 29 ec 4c 89 e6 4c 89 f7 e8 91 RSP: 0018:888051747558 EFLAGS: 00010293 RAX: 8880a55d8040 RBX: 20001000 RCX: 8549806c RDX: RSI: 85498076 RDI: 0006 RBP: 8880517475d8 R08: 8880a55d8040 R09: 0028 R10: ed100a2e8f01 R11: 88805174780f R12: 0020 R13: 0028 R14: 888096952b50 R15: FS: 7f526c1e3700() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ff600400 CR3: 32547000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
kernel BUG at drivers/android/binder_alloc.c:LINE! (2)
Hello, syzbot found the following crash on: HEAD commit:b3418f8bddf4 Add linux-next specific files for 20190214 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=15d98978c0 kernel config: https://syzkaller.appspot.com/x/.config?x=8a3a37525a677c71 dashboard link: https://syzkaller.appspot.com/bug?extid=55de1eb4975dec156d8f compiler: gcc (GCC) 9.0.0 20181231 (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+55de1eb4975dec156...@syzkaller.appspotmail.com binder: 9248:9252 ioctl 80081272 2140 returned -22 [ cut here ] kernel BUG at drivers/android/binder_alloc.c:1141! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 1 PID: 9252 Comm: syz-executor.2 Not tainted 5.0.0-rc6-next-20190214 #35 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:binder_alloc_do_buffer_copy+0xd6/0x510 drivers/android/binder_alloc.c:1141 Code: 02 00 0f 85 20 04 00 00 4d 8b 64 24 58 49 29 dc e8 9f e1 26 fc 4c 89 e6 4c 89 ef e8 b4 e2 26 fc 4d 39 e5 76 07 e8 8a e1 26 fc <0f> 0b e8 83 e1 26 fc 4c 8b 75 d0 4d 29 ec 4c 89 e6 4c 89 f7 e8 91 RSP: 0018:88803fc37558 EFLAGS: 00010212 RAX: 0004 RBX: 20001000 RCX: c9000a245000 RDX: 0386 RSI: 85498076 RDI: 0006 RBP: 88803fc375d8 R08: 88805d20e640 R09: 0028 R10: ed1007f86f01 R11: 88803fc3780f R12: 0020 R13: 0028 R14: 8880772a18d0 R15: FS: 7f8b32812700() GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 004d6c10 CR3: 788df000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: binder_alloc_copy_from_buffer+0x37/0x42 drivers/android/binder_alloc.c:1187 binder_get_object+0xa2/0x1e0 drivers/android/binder.c:2062 binder_transaction+0x2b4a/0x6690 drivers/android/binder.c:3231 binder_thread_write+0x64a/0x2820 drivers/android/binder.c:3792 binder_ioctl_write_read drivers/android/binder.c:4825 [inline] binder_ioctl+0x1033/0x183b drivers/android/binder.c:5002 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457e29 Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f8b32811c78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 0003 RCX: 00457e29 RDX: 2000 RSI: c0306201 RDI: 0003 RBP: 0073bf00 R08: R09: R10: R11: 0246 R12: 7f8b328126d4 R13: 004bf15b R14: 004d0a60 R15: Modules linked in: ---[ end trace ccb30c2e039fdec2 ]--- RIP: 0010:binder_alloc_do_buffer_copy+0xd6/0x510 drivers/android/binder_alloc.c:1141 Code: 02 00 0f 85 20 04 00 00 4d 8b 64 24 58 49 29 dc e8 9f e1 26 fc 4c 89 e6 4c 89 ef e8 b4 e2 26 fc 4d 39 e5 76 07 e8 8a e1 26 fc <0f> 0b e8 83 e1 26 fc 4c 8b 75 d0 4d 29 ec 4c 89 e6 4c 89 f7 e8 91 RSP: 0018:88803fc37558 EFLAGS: 00010212 RAX: 0004 RBX: 20001000 RCX: c9000a245000 RDX: 0386 RSI: 85498076 RDI: 0006 RBP: 88803fc375d8 R08: 88805d20e640 R09: 0028 R10: ed1007f86f01 R11: 88803fc3780f R12: 0020 R13: 0028 R14: 8880772a18d0 R15: FS: 7f8b32812700() GS:8880ae90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fff6ec60cec CR3: 788df000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- 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 syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 7/9] net: bridge: Stop calling switchdev_port_attr_get()
On Wed, Feb 13, 2019 at 02:06:36PM -0800, Florian Fainelli wrote:
> Now that all switchdev drivers have been converted to checking the
> bridge port flags during the prepare phase of the
> switchdev_port_attr_set() when the process
> SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS, we can avoid calling
> switchdev_port_attr_get() with
> SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT.
>
> Signed-off-by: Florian Fainelli
> ---
> net/bridge/br_switchdev.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
> index db9e8ab96d48..8f88f8a1a7fa 100644
> --- a/net/bridge/br_switchdev.c
> +++ b/net/bridge/br_switchdev.c
> @@ -64,29 +64,27 @@ int br_switchdev_set_port_flag(struct net_bridge_port *p,
> {
> struct switchdev_attr attr = {
> .orig_dev = p->dev,
> - .id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
> + .id = SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS,
> + .u.brport_flags = flags,
> };
> int err;
>
> if (mask & ~BR_PORT_FLAGS_HW_OFFLOAD)
> return 0;
>
> - err = switchdev_port_attr_get(p->dev, );
> - if (err == -EOPNOTSUPP)
> - return 0;
> - if (err)
> + err = switchdev_port_attr_set(p->dev, );
> + if (err && err != -EOPNOTSUPP)
> return err;
>
> - /* Check if specific bridge flag attribute offload is supported */
> - if (!(attr.u.brport_flags_support & mask)) {
> + if (err == -EOPNOTSUPP) {
> br_warn(p->br, "bridge flag offload is not supported %u(%s)\n",
> (unsigned int)p->port_no, p->dev->name);
> - return -EOPNOTSUPP;
> + return err;
> }
I see that you return -EOPNOTSUPP from drivers in case of unsupported
flags. I believe this is problematic (I'll test soon). The same return
code is used by:
1. Switch drivers to indicate unsupported flags
2. switchdev code to indicate unsupported netdev (no switchdev ops)
I guess that with this patch any attempt to set bridge port flags on
veth/dummy device will result in an error.
>
> attr.id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS;
> attr.flags = SWITCHDEV_F_DEFER;
> - attr.u.brport_flags = flags;
> +
> err = switchdev_port_attr_set(p->dev, );
> if (err) {
> br_warn(p->br, "error setting offload flag on port %u(%s)\n",
> --
> 2.17.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 1/9] Documentation: networking: switchdev: Update port parent ID section
On Wed, Feb 13, 2019 at 02:06:30PM -0800, Florian Fainelli wrote:
> Update the section about switchdev drivers having to implement a
> switchdev_port_attr_get() function to return
> SWITCHDEV_ATTR_ID_PORT_PARENT_ID since that is no longer valid after
> commit bccb30254a4a ("net: Get rid of
> SWITCHDEV_ATTR_ID_PORT_PARENT_ID").
>
> Fixes: bccb30254a4a ("net: Get rid of SWITCHDEV_ATTR_ID_PORT_PARENT_ID")
> Acked-by: Jiri Pirko
> Signed-off-by: Florian Fainelli
Reviewed-by: Ido Schimmel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging:iio:ad7152: Rename misspelled RESEVERD -> RESERVED
On Mi, 2019-02-13 at 22:25 -0200, Rodrigo Ribeiro wrote: > [External] > > > Em ter, 29 de jan de 2019 às 07:10, Alexandru Ardelean l.com> escreveu: > > > > On Sat, Jan 26, 2019 at 8:13 PM Jonathan Cameron > wrote: > > > > > > On Fri, 25 Jan 2019 22:14:32 -0200 > > > Rodrigo Ribeiro wrote: > > > > > > > Em sex, 25 de jan de 2019 às 21:46, Rodrigo Ribeiro > > > > escreveu: > > > > > > > > > > Em sex, 25 de jan de 2019 às 06:20, Alexandru Ardelean > > > > > escreveu: > > > > > > > > > > > > On Thu, Jan 24, 2019 at 9:35 PM Rodrigo Ribeiro ail.com> wrote: > > > > > > > > > > > > > > Remove the checkpatch.pl check: > > > > > > > > > > > > > > CHECK: 'RESEVERD' may be misspelled - perhaps 'RESERVED'? > > > > > > > > > > > > Hey, > > > > > > > > > > Hi, > > > > > > > > > > Thanks for answering. > > > > > > > > > > > A bit curios about this one. > > > > > > Are you using this chip/driver ? > > > > > > > > > > No, I am just a student at USP (University of São Paulo) starting > in Linux > > > > > Kernel and a new member of the USP Linux Kernel group that has > contributed > > > > > for a few months. > > > > > > > > > > > Thing is: the part is nearing EOL, and it could be an idea to > be > > > > > > marked for removal (since it's still in staging). > > > > > > But if there are users for this driver, it could be left around > for a while. > > > > > > > > > > This is my first patch in Linux Kernel, but if the driver will be > removed, I > > > > > can send a patch for another driver. Is there any driver that I > can > > > > > fix a style warning? > > > > > > > > Maybe, one checkstyle patch is enough, right? Which drivers can I > truly > > > > contribute to? > > > > > > How about the ad7150? That one is still listed as production. > > > What do you think Alex, you probably have better visibility on the > > > status of these parts and their drivers than I do! > > > > > > (note I haven't even opened that one for a few years so no idea > > > what state the driver is in!) > > > > > > > ad7150 is a good alternative. > > At a first glance over the driver it looks like it could do with some > > polish/conversions to newer IIO constructs (like IIO triggers, maybe > > some newer event handling mechanisms?). > > I'll sync with Stefan [Popa] to see about this stuff at a later point > in time. > > > > I'd also add here the adxl345 driver. > > This is mostly informational for anyone who'd find this interesting. > > There are 2 drivers for this chip, one in IIO > > [drivers/iio/accel/adxl345] and another one in > > "drivers/misc/adxl34x.c" as part of the input sub-system. > > What would be interesting here is to finalize the IIO driver [ I think > > some features are lacking behind the input driver], and make the input > > driver a consumer of the IIO driver. > > > > From my side, both these variants are fine to take on. > > The ad7150 is a good idea as a starter project, and the adxl one is > > more of a long-term medium-level project. > > > > Thanks > > Alex > > > > Hi Alex, thanks for suggestions. > > I read the IIO trigger documentation > (https://www.kernel.org/doc/html/v4.12/driver-api/iio/triggers.html) and > ask one question: What is the difference between events and triggers? > They are sounds me same things. > > I am trying to understand how to implement a IIO trigger by reading > the IIO Simple Dummy code but this driver does not implements IIO > triggers > but only IIO events. Is there a didactic example like IIO Simple Dummy > that implements IIO triggers? > > Thanks > Rodrigo > Hi Rodrigo, From what I know, IIO Events are not used for passing readings from devices to userspace, but rather out of bounds information such as crossing of voltage thresholds, proximity detection, motion detection, etc. Triggers are typically used to determine when valid data can be read from a device which is then stored in the buffer. After a quick look over the AD7150, I think that using IIO events, might be the correct approach, since it is a proximity sensing device. -Stefan > > > Jonathan > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > Em sex, 25 de jan de 2019 às 06:20, Alexandru Ardelean > > > > > escreveu: > > > > > > > > > > > > On Thu, Jan 24, 2019 at 9:35 PM Rodrigo Ribeiro ail.com> wrote: > > > > > > > > > > > > > > Remove the checkpatch.pl check: > > > > > > > > > > > > > > CHECK: 'RESEVERD' may be misspelled - perhaps 'RESERVED'? > > > > > > > > > > > > Hey, > > > > > > > > > > > > A bit curios about this one. > > > > > > Are you using this chip/driver ? > > > > > > > > > > > > Thing is: the part is nearing EOL, and it could be an idea to > be > > > > > > marked for removal (since it's still in staging). > > > > > > But if there are users for this driver, it could be left around > for a while. > > > > > > > > > > > > Thanks > > > > > > Alex > > > > > > > > > > > > > > > > > > > > Signed-off-by: Rodrigo Ribeiro > > > > > > > Signed-off-by: Rafael Tsuha > > > > > > > --- > > > > > > > This
[PATCH v3 2/2] media: cedrus: Add HEVC/H.265 decoding support
This introduces support for HEVC/H.265 to the Cedrus VPU driver, with
both uni-directional and bi-directional prediction modes supported.
Field-coded (interlaced) pictures, custom quantization matrices and
10-bit output are not supported at this point.
Signed-off-by: Paul Kocialkowski
---
drivers/staging/media/sunxi/cedrus/Makefile | 2 +-
drivers/staging/media/sunxi/cedrus/cedrus.c | 27 +-
drivers/staging/media/sunxi/cedrus/cedrus.h | 18 +
.../staging/media/sunxi/cedrus/cedrus_dec.c | 9 +
.../staging/media/sunxi/cedrus/cedrus_h265.c | 531 ++
.../staging/media/sunxi/cedrus/cedrus_hw.c| 4 +
.../staging/media/sunxi/cedrus/cedrus_regs.h | 290 ++
.../staging/media/sunxi/cedrus/cedrus_video.c | 10 +
8 files changed, 887 insertions(+), 4 deletions(-)
create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_h265.c
diff --git a/drivers/staging/media/sunxi/cedrus/Makefile
b/drivers/staging/media/sunxi/cedrus/Makefile
index aaf141fc58b6..186cb6d01b67 100644
--- a/drivers/staging/media/sunxi/cedrus/Makefile
+++ b/drivers/staging/media/sunxi/cedrus/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi-cedrus.o
sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o cedrus_dec.o \
-cedrus_mpeg2.o cedrus_h264.o
+cedrus_mpeg2.o cedrus_h264.o cedrus_h265.o
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index b275607b8111..a713630ce7ba 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -68,6 +68,23 @@ static const struct cedrus_control cedrus_controls[] = {
.id = V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX,
.elem_size = sizeof(struct v4l2_ctrl_h264_scaling_matrix),
.codec = CEDRUS_CODEC_H264,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_HEVC_SPS,
+ .elem_size = sizeof(struct v4l2_ctrl_hevc_sps),
+ .codec = CEDRUS_CODEC_H265,
+ .required = true,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_HEVC_PPS,
+ .elem_size = sizeof(struct v4l2_ctrl_hevc_pps),
+ .codec = CEDRUS_CODEC_H265,
+ .required = true,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS,
+ .elem_size = sizeof(struct v4l2_ctrl_hevc_slice_params),
+ .codec = CEDRUS_CODEC_H265,
.required = true,
},
};
@@ -309,6 +326,7 @@ static int cedrus_probe(struct platform_device *pdev)
dev->dec_ops[CEDRUS_CODEC_MPEG2] = _dec_ops_mpeg2;
dev->dec_ops[CEDRUS_CODEC_H264] = _dec_ops_h264;
+ dev->dec_ops[CEDRUS_CODEC_H265] = _dec_ops_h265;
mutex_init(>dev_mutex);
@@ -416,15 +434,18 @@ static const struct cedrus_variant
sun8i_a33_cedrus_variant = {
};
static const struct cedrus_variant sun8i_h3_cedrus_variant = {
- .capabilities = CEDRUS_CAPABILITY_UNTILED,
+ .capabilities = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_H265_DEC,
};
static const struct cedrus_variant sun50i_a64_cedrus_variant = {
- .capabilities = CEDRUS_CAPABILITY_UNTILED,
+ .capabilities = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_H265_DEC,
};
static const struct cedrus_variant sun50i_h5_cedrus_variant = {
- .capabilities = CEDRUS_CAPABILITY_UNTILED,
+ .capabilities = CEDRUS_CAPABILITY_UNTILED |
+ CEDRUS_CAPABILITY_H265_DEC,
};
static const struct of_device_id cedrus_dt_match[] = {
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 8c64f9a27e9d..b5d083812bea 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -27,10 +27,12 @@
#define CEDRUS_NAME"cedrus"
#define CEDRUS_CAPABILITY_UNTILED BIT(0)
+#define CEDRUS_CAPABILITY_H265_DEC BIT(1)
enum cedrus_codec {
CEDRUS_CODEC_MPEG2,
CEDRUS_CODEC_H264,
+ CEDRUS_CODEC_H265,
CEDRUS_CODEC_LAST,
};
@@ -66,6 +68,12 @@ struct cedrus_mpeg2_run {
const struct v4l2_ctrl_mpeg2_quantization *quantization;
};
+struct cedrus_h265_run {
+ const struct v4l2_ctrl_hevc_sps *sps;
+ const struct v4l2_ctrl_hevc_pps *pps;
+ const struct v4l2_ctrl_hevc_slice_params*slice_params;
+};
+
struct cedrus_run {
struct vb2_v4l2_buffer *src;
struct vb2_v4l2_buffer *dst;
@@ -73,6 +81,7 @@ struct cedrus_run {
union {
struct cedrus_h264_run h264;
struct cedrus_mpeg2_run mpeg2;
+ struct cedrus_h265_run h265;
[PATCH v3 0/2] HEVC/H.265 stateless support for V4L2 and Cedrus
This introduces the required bits for supporting HEVC/H.265 both in the V4L2 framework and the Cedrus VPU driver that concerns Allwinner devices. A specific pixel format is introduced for the HEVC slice format and controls are provided to pass the bitstream metadata to the decoder. Some bitstream extensions are intentionally not supported at this point. Since this is the first proposal for stateless HEVC/H.265 support in V4L2, reviews and comments about the controls definitions are particularly welcome. On the Cedrus side, the H.265 implementation covers frame pictures with both uni-directional and bi-direction prediction modes (P/B slices). Field pictures (interleaved), scaling lists and 10-bit output are not supported at this point. This series is based upon the following series: * media: cedrus: Add H264 decoding support Changes since v2: * Moved headers to non-public API; * Added H265 capability for A64 and H5; * Moved docs to ext-ctrls-codec.rst; * Mentionned sections of the spec in the docs; * Added padding to control structures for 32-bit alignment; * Made write function use void/size in bytes; * Reduced the number of arguments to helpers when possible; * Removed PHYS_OFFSET since we already set PFN_OFFSET; * Added comments where suggested; * Moved to timestamp for references instead of index; * Fixed some style issues reported by checkpatch. Changes since v1: * Added a H.265 capability to whitelist relevant platforms; * Switched over to tags instead of buffer indices in the DPB * Declared variable in their reduced scope as suggested; * Added the H.265/HEVC spec to the biblio; * Used in-doc references to the spec and the required APIs; * Removed debugging leftovers. Cheers! Paul Kocialkowski (2): media: v4l: Add definitions for the HEVC slice format and controls media: cedrus: Add HEVC/H.265 decoding support Documentation/media/uapi/v4l/biblio.rst | 9 + .../media/uapi/v4l/ext-ctrls-codec.rst| 418 ++ .../media/uapi/v4l/pixfmt-compressed.rst | 15 + .../media/uapi/v4l/vidioc-queryctrl.rst | 18 + .../media/videodev2.h.rst.exceptions | 3 + drivers/media/v4l2-core/v4l2-ctrls.c | 26 + drivers/media/v4l2-core/v4l2-ioctl.c | 1 + drivers/staging/media/sunxi/cedrus/Makefile | 2 +- drivers/staging/media/sunxi/cedrus/cedrus.c | 27 +- drivers/staging/media/sunxi/cedrus/cedrus.h | 18 + .../staging/media/sunxi/cedrus/cedrus_dec.c | 9 + .../staging/media/sunxi/cedrus/cedrus_h265.c | 531 ++ .../staging/media/sunxi/cedrus/cedrus_hw.c| 4 + .../staging/media/sunxi/cedrus/cedrus_regs.h | 290 ++ .../staging/media/sunxi/cedrus/cedrus_video.c | 10 + include/media/hevc-ctrls.h| 181 ++ include/media/v4l2-ctrls.h| 7 + include/uapi/linux/videodev2.h| 1 + 18 files changed, 1566 insertions(+), 4 deletions(-) create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_h265.c create mode 100644 include/media/hevc-ctrls.h -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/2] media: v4l: Add definitions for the HEVC slice format and controls
This introduces the required definitions for HEVC decoding support with stateless VPUs. The controls associated to the HEVC slice format provide the required meta-data for decoding slices extracted from the bitstream. This interface comes with the following limitations: * No custom quantization matrices (scaling lists); * Support for a single temporal layer only; * No slice entry point offsets support; * No conformance window support; * No VUI parameters support; * No support for SPS extensions: range, multilayer, 3d, scc, 4 bits; * No support for PPS extensions: range, multilayer, 3d, scc, 4 bits. Signed-off-by: Paul Kocialkowski --- Documentation/media/uapi/v4l/biblio.rst | 9 + .../media/uapi/v4l/ext-ctrls-codec.rst| 418 ++ .../media/uapi/v4l/pixfmt-compressed.rst | 15 + .../media/uapi/v4l/vidioc-queryctrl.rst | 18 + .../media/videodev2.h.rst.exceptions | 3 + drivers/media/v4l2-core/v4l2-ctrls.c | 26 ++ drivers/media/v4l2-core/v4l2-ioctl.c | 1 + include/media/hevc-ctrls.h| 181 include/media/v4l2-ctrls.h| 7 + include/uapi/linux/videodev2.h| 1 + 10 files changed, 679 insertions(+) create mode 100644 include/media/hevc-ctrls.h diff --git a/Documentation/media/uapi/v4l/biblio.rst b/Documentation/media/uapi/v4l/biblio.rst index 3fc3f7ff338a..b4b3fcec55dd 100644 --- a/Documentation/media/uapi/v4l/biblio.rst +++ b/Documentation/media/uapi/v4l/biblio.rst @@ -131,6 +131,15 @@ ITU H.264 :author:International Telecommunication Union (http://www.itu.ch) +.. _hevc: + +ITU H.265/HEVC +== + +:title: ITU-T Rec. H.265 | ISO/IEC 23008-2 "High Efficiency Video Coding" + +:author:International Telecommunication Union (http://www.itu.ch), International Organisation for Standardisation (http://www.iso.ch) + .. _jfif: JFIF diff --git a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst index d152474c18bc..3714dfd1449b 100644 --- a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst +++ b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst @@ -2067,6 +2067,424 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - - 0x0002 - +.. _v4l2-mpeg-hevc: + +``V4L2_CID_MPEG_VIDEO_HEVC_SPS (struct)`` +Specifies the Sequence Parameter Set fields (as extracted from the +bitstream) for the associated HEVC slice data. +These bitstream parameters are defined according to :ref:`hevc`. +They are described in section 7.4.3.2 "Sequence parameter set RBSP +semantics" of the specification. + +.. c:type:: v4l2_ctrl_hevc_sps + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_hevc_sps +:header-rows: 0 +:stub-columns: 0 +:widths: 1 1 2 + +* - __u8 + - ``chroma_format_idc`` + - +* - __u8 + - ``separate_colour_plane_flag`` + - +* - __u16 + - ``pic_width_in_luma_samples`` + - +* - __u16 + - ``pic_height_in_luma_samples`` + - +* - __u8 + - ``bit_depth_luma_minus8`` + - +* - __u8 + - ``bit_depth_chroma_minus8`` + - +* - __u8 + - ``log2_max_pic_order_cnt_lsb_minus4`` + - +* - __u8 + - ``sps_max_dec_pic_buffering_minus1`` + - +* - __u8 + - ``sps_max_num_reorder_pics`` + - +* - __u8 + - ``sps_max_latency_increase_plus1`` + - +* - __u8 + - ``log2_min_luma_coding_block_size_minus3`` + - +* - __u8 + - ``log2_diff_max_min_luma_coding_block_size`` + - +* - __u8 + - ``log2_min_luma_transform_block_size_minus2`` + - +* - __u8 + - ``log2_diff_max_min_luma_transform_block_size`` + - +* - __u8 + - ``max_transform_hierarchy_depth_inter`` + - +* - __u8 + - ``max_transform_hierarchy_depth_intra`` + - +* - __u8 + - ``scaling_list_enabled_flag`` + - +* - __u8 + - ``amp_enabled_flag`` + - +* - __u8 + - ``sample_adaptive_offset_enabled_flag`` + - +* - __u8 + - ``pcm_enabled_flag`` + - +* - __u8 + - ``pcm_sample_bit_depth_luma_minus1`` + - +* - __u8 + - ``pcm_sample_bit_depth_chroma_minus1`` + - +* - __u8 + - ``log2_min_pcm_luma_coding_block_size_minus3`` + - +* - __u8 + - ``log2_diff_max_min_pcm_luma_coding_block_size`` + - +* - __u8 + - ``pcm_loop_filter_disabled_flag`` + - +* - __u8 + - ``num_short_term_ref_pic_sets`` + - +* - __u8 + - ``long_term_ref_pics_present_flag`` + - +* - __u8 + - ``num_long_term_ref_pics_sps`` + - +* - __u8 + - ``sps_temporal_mvp_enabled_flag`` + - +* - __u8 + - ``strong_intra_smoothing_enabled_flag`` + - + +``V4L2_CID_MPEG_VIDEO_HEVC_PPS (struct)`` +Specifies the Picture Parameter Set fields (as extracted from the +
Re: [PATCH 1/1] staging: android: ion: Add the GPL exception for syscalls
On Wed, Feb 13, 2019 at 04:01:46PM -0800, Hyun Kwon wrote: > Add "WITH Linux-syscall-note" to the license to not put GPL > restrictions on user space programs using this header. > > Signed-off-by: Hyun Kwon > --- > drivers/staging/android/uapi/ion.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/android/uapi/ion.h > b/drivers/staging/android/uapi/ion.h > index 5d70098..46c93fc 100644 > --- a/drivers/staging/android/uapi/ion.h > +++ b/drivers/staging/android/uapi/ion.h > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > /* > * drivers/staging/android/uapi/ion.h > * > -- > 2.7.4 > Yes, that is the correct thing to do, let me go queue this up. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
