Re: [PATCH v3 8/8] mfd: cros_ec: add a dev_release empty method.
On Wed, Nov 28, 2018 at 05:17:22PM -0800, Guenter Roeck wrote:
> Hi Greg,
>
> On Tue, Nov 27, 2018 at 9:52 AM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Nov 27, 2018 at 09:29:38AM -0800, Guenter Roeck wrote:
> > > Hi Enric,
> > >
> > > On Tue, Nov 27, 2018 at 4:19 AM Enric Balletbo i Serra
> > > wrote:
> > > >
> > > > Devices are required to provide a release method. This patch fixes the
> > > > following WARN():
> > > >
> > > > [ 47.218707] [ cut here ]
> > > > [ 47.223901] Device 'cros_ec' does not have a release() function, it
> > > > is broken and must be fixed.
> > > > [ 47.234430] WARNING: CPU: 0 PID: 3585 at drivers/base/core.c:895
> > > > device_release+0x80/0x90
> > > > [ 47.243560] Modules linked in: btusb btrtl btintel btbcm bluetooth
> > > > ecdh_generic [...]
> > > > [ 47.323851] CPU: 0 PID: 3585 Comm: rmmod Not tainted 4.20.0-rc2+ #29
> > > > [ 47.330947] Hardware name: Google Kevin (DT)
> > > > [ 47.335714] pstate: 4005 (nZcv daif -PAN -UAO)
> > > > [ 47.341063] pc : device_release+0x80/0x90
> > > > [ 47.345537] lr : device_release+0x80/0x90
> > > > [ 47.350001] sp : 0b17bc70
> > > > [ 47.353698] x29: 0b17bc70 x28: 8000e48e9a80
> > > > [ 47.359629] x27: x26:
> > > > [ 47.365561] x25: 5600 x24: 0015
> > > > [ 47.371492] x23: 8000f0248060 x22: 00b700a0
> > > > [ 47.377414] x21: 8000edf56100 x20: 8000edd13028
> > > > [ 47.383346] x19: 8000edd13018 x18: 0095
> > > > [ 47.389278] x17: x16:
> > > > [ 47.395209] x15: 0400 x14: 0400
> > > > [ 47.401131] x13: 01a7 x12:
> > > > [ 47.407053] x11: 0001 x10: 0960
> > > > [ 47.412976] x9 : 0b17b9b0 x8 : 8000e48ea440
> > > > [ 47.418898] x7 : 8000ee9090c0 x6 : 8000f7d0b0b8
> > > > [ 47.424830] x5 : 8000f7d0b0b8 x4 :
> > > > [ 47.430752] x3 : 8000f7d11e68 x2 : 8000e48e9a80
> > > > [ 47.436674] x1 : 37d859939c964800 x0 :
> > > > [ 47.442597] Call trace:
> > > > [ 47.445324] device_release+0x80/0x90
> > > > [ 47.449414] kobject_put+0x74/0xe8
> > > > [ 47.453210] device_unregister+0x20/0x30
> > > > [ 47.457592] ec_device_remove+0x34/0x48 [cros_ec_dev]
> > > > [ 47.463233] platform_drv_remove+0x28/0x48
> > > > [ 47.467805] device_release_driver_internal+0x1a8/0x240
> > > > [ 47.473630] driver_detach+0x40/0x80
> > > > [ 47.477609] bus_remove_driver+0x54/0xa8
> > > > [ 47.481986] driver_unregister+0x2c/0x58
> > > > [ 47.486355] platform_driver_unregister+0x10/0x18
> > > > [ 47.491599] cros_ec_dev_exit+0x1c/0x258 [cros_ec_dev]
> > > > [ 47.497338] __arm64_sys_delete_module+0x16c/0x1f8
> > > > [ 47.502689] el0_svc_common+0x84/0xd8
> > > > [ 47.506776] el0_svc_handler+0x2c/0x80
> > > > [ 47.510960] el0_svc+0x8/0xc
> > > > [ 47.514171] ---[ end trace 9087279fc8c03450 ]---
> > > >
> > > > Signed-off-by: Enric Balletbo i Serra
> > > > ---
> > > >
> > > > Changes in v3: None
> > > > Changes in v2:
> > > > - Fix WARN when unloading. This is new in these series.
> > > >
> > > > drivers/mfd/cros_ec_dev.c | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> > > > index 1ba98a32715e..cdb941c6db98 100644
> > > > --- a/drivers/mfd/cros_ec_dev.c
> > > > +++ b/drivers/mfd/cros_ec_dev.c
> > > > @@ -35,9 +35,14 @@
> > > > #define CROS_MAX_DEV 128
> > > > static int ec_major;
> > > >
> > > > +static void cros_ec_dev_release(struct device *dev)
> > > > +{
> > > > +}
> >
> > Yeah, as part of the in-kernel documentation, I now get to make fun of
> > you in public!
> >
> > You did read the documentation, right?
> >
>
> To be fair, the problem is difficult to understand. Maybe it is easy
> for you, but that is not true for everyone, including me. Remember the
> block discussion we just had ? As for the in-kernel documentation,
> maybe there is a comprehensive explanation someone, one that clueless
> people like me can understand, but all I found was
>
> "If a bus driver unregisters a device, it should not immediately free
> it. It should instead wait for the driver model core to call the
> device's release method, then free the bus-specific object.
> (There may be other code that is currently referencing the device
> structure, and it would be rude to free the device while that is
> happening)"
>
> Does that apply to mfd devices ? What other code may that be that
> accesses the structure ? What else does it mean, or in other words,
> what other cleanup code besides releasing the data structure needs to
> reside in the release function ?
To quote Documentation/kobject.txt:
One important point cannot be overstated: every kobject must
have a release()
Re: [PATCH v3 8/8] mfd: cros_ec: add a dev_release empty method.
On Wed, Nov 28, 2018 at 05:17:22PM -0800, Guenter Roeck wrote:
> Hi Greg,
>
> On Tue, Nov 27, 2018 at 9:52 AM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Nov 27, 2018 at 09:29:38AM -0800, Guenter Roeck wrote:
> > > Hi Enric,
> > >
> > > On Tue, Nov 27, 2018 at 4:19 AM Enric Balletbo i Serra
> > > wrote:
> > > >
> > > > Devices are required to provide a release method. This patch fixes the
> > > > following WARN():
> > > >
> > > > [ 47.218707] [ cut here ]
> > > > [ 47.223901] Device 'cros_ec' does not have a release() function, it
> > > > is broken and must be fixed.
> > > > [ 47.234430] WARNING: CPU: 0 PID: 3585 at drivers/base/core.c:895
> > > > device_release+0x80/0x90
> > > > [ 47.243560] Modules linked in: btusb btrtl btintel btbcm bluetooth
> > > > ecdh_generic [...]
> > > > [ 47.323851] CPU: 0 PID: 3585 Comm: rmmod Not tainted 4.20.0-rc2+ #29
> > > > [ 47.330947] Hardware name: Google Kevin (DT)
> > > > [ 47.335714] pstate: 4005 (nZcv daif -PAN -UAO)
> > > > [ 47.341063] pc : device_release+0x80/0x90
> > > > [ 47.345537] lr : device_release+0x80/0x90
> > > > [ 47.350001] sp : 0b17bc70
> > > > [ 47.353698] x29: 0b17bc70 x28: 8000e48e9a80
> > > > [ 47.359629] x27: x26:
> > > > [ 47.365561] x25: 5600 x24: 0015
> > > > [ 47.371492] x23: 8000f0248060 x22: 00b700a0
> > > > [ 47.377414] x21: 8000edf56100 x20: 8000edd13028
> > > > [ 47.383346] x19: 8000edd13018 x18: 0095
> > > > [ 47.389278] x17: x16:
> > > > [ 47.395209] x15: 0400 x14: 0400
> > > > [ 47.401131] x13: 01a7 x12:
> > > > [ 47.407053] x11: 0001 x10: 0960
> > > > [ 47.412976] x9 : 0b17b9b0 x8 : 8000e48ea440
> > > > [ 47.418898] x7 : 8000ee9090c0 x6 : 8000f7d0b0b8
> > > > [ 47.424830] x5 : 8000f7d0b0b8 x4 :
> > > > [ 47.430752] x3 : 8000f7d11e68 x2 : 8000e48e9a80
> > > > [ 47.436674] x1 : 37d859939c964800 x0 :
> > > > [ 47.442597] Call trace:
> > > > [ 47.445324] device_release+0x80/0x90
> > > > [ 47.449414] kobject_put+0x74/0xe8
> > > > [ 47.453210] device_unregister+0x20/0x30
> > > > [ 47.457592] ec_device_remove+0x34/0x48 [cros_ec_dev]
> > > > [ 47.463233] platform_drv_remove+0x28/0x48
> > > > [ 47.467805] device_release_driver_internal+0x1a8/0x240
> > > > [ 47.473630] driver_detach+0x40/0x80
> > > > [ 47.477609] bus_remove_driver+0x54/0xa8
> > > > [ 47.481986] driver_unregister+0x2c/0x58
> > > > [ 47.486355] platform_driver_unregister+0x10/0x18
> > > > [ 47.491599] cros_ec_dev_exit+0x1c/0x258 [cros_ec_dev]
> > > > [ 47.497338] __arm64_sys_delete_module+0x16c/0x1f8
> > > > [ 47.502689] el0_svc_common+0x84/0xd8
> > > > [ 47.506776] el0_svc_handler+0x2c/0x80
> > > > [ 47.510960] el0_svc+0x8/0xc
> > > > [ 47.514171] ---[ end trace 9087279fc8c03450 ]---
> > > >
> > > > Signed-off-by: Enric Balletbo i Serra
> > > > ---
> > > >
> > > > Changes in v3: None
> > > > Changes in v2:
> > > > - Fix WARN when unloading. This is new in these series.
> > > >
> > > > drivers/mfd/cros_ec_dev.c | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> > > > index 1ba98a32715e..cdb941c6db98 100644
> > > > --- a/drivers/mfd/cros_ec_dev.c
> > > > +++ b/drivers/mfd/cros_ec_dev.c
> > > > @@ -35,9 +35,14 @@
> > > > #define CROS_MAX_DEV 128
> > > > static int ec_major;
> > > >
> > > > +static void cros_ec_dev_release(struct device *dev)
> > > > +{
> > > > +}
> >
> > Yeah, as part of the in-kernel documentation, I now get to make fun of
> > you in public!
> >
> > You did read the documentation, right?
> >
>
> To be fair, the problem is difficult to understand. Maybe it is easy
> for you, but that is not true for everyone, including me. Remember the
> block discussion we just had ? As for the in-kernel documentation,
> maybe there is a comprehensive explanation someone, one that clueless
> people like me can understand, but all I found was
>
> "If a bus driver unregisters a device, it should not immediately free
> it. It should instead wait for the driver model core to call the
> device's release method, then free the bus-specific object.
> (There may be other code that is currently referencing the device
> structure, and it would be rude to free the device while that is
> happening)"
>
> Does that apply to mfd devices ? What other code may that be that
> accesses the structure ? What else does it mean, or in other words,
> what other cleanup code besides releasing the data structure needs to
> reside in the release function ?
To quote Documentation/kobject.txt:
One important point cannot be overstated: every kobject must
have a release()
Re: [PATCH v2 1/4] x86/hyper-v: move synic/stimer control structures definitions to hyperv-tlfs.h
On Wed, Nov 28, 2018 at 02:07:42PM +0100, Thomas Gleixner wrote: > On Wed, 28 Nov 2018, Vitaly Kuznetsov wrote: > > > Nadav Amit writes: > > > > > > > > On a different note: how come all of the hyper-v structs are not marked > > > with the “packed" attribute? > > > > "packed" should not be needed with proper padding; I vaguely remember > > someone (from x86@?) arguing _against_ "packed". > > Packed needs to be used, when describing fixed format data structures in > hardware or other ABIs, so the compiler cannot put alignment holes into > them. > > Using packed for generic data structures might result in suboptimal layouts > and prevents layout randomization. Sorry for my illiteracy, I didn't watch this field closely so I had to google about layout randomization. Is my understanding correct that one can't rely any more on the compiler to naturally align the struct members with minimal padding? My life will never be the same... Roman.
Re: [PATCH v2 1/4] x86/hyper-v: move synic/stimer control structures definitions to hyperv-tlfs.h
On Wed, Nov 28, 2018 at 02:07:42PM +0100, Thomas Gleixner wrote: > On Wed, 28 Nov 2018, Vitaly Kuznetsov wrote: > > > Nadav Amit writes: > > > > > > > > On a different note: how come all of the hyper-v structs are not marked > > > with the “packed" attribute? > > > > "packed" should not be needed with proper padding; I vaguely remember > > someone (from x86@?) arguing _against_ "packed". > > Packed needs to be used, when describing fixed format data structures in > hardware or other ABIs, so the compiler cannot put alignment holes into > them. > > Using packed for generic data structures might result in suboptimal layouts > and prevents layout randomization. Sorry for my illiteracy, I didn't watch this field closely so I had to google about layout randomization. Is my understanding correct that one can't rely any more on the compiler to naturally align the struct members with minimal padding? My life will never be the same... Roman.
[PATCH 1/2] mm: Move lru_to_page to mm.h
There are multiple places in the kernel which opencode this helper, this patch moves it to the more generic mm.h header in preparation for using it. No functional changes. Signed-off-by: Nikolay Borisov --- include/linux/mm.h| 2 ++ include/linux/mm_inline.h | 3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 5411de93a363..47b4aa5bba93 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -146,6 +146,8 @@ extern int overcommit_kbytes_handler(struct ctl_table *, int, void __user *, /* test whether an address (unsigned long or pointer) is aligned to PAGE_SIZE */ #define PAGE_ALIGNED(addr) IS_ALIGNED((unsigned long)(addr), PAGE_SIZE) +#define lru_to_page(head) (list_entry((head)->prev, struct page, lru)) + /* * Linux kernel virtual memory manager primitives. * The idea being to have a "virtual" mm in the same way diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h index 10191c28fc04..04ec454d44ce 100644 --- a/include/linux/mm_inline.h +++ b/include/linux/mm_inline.h @@ -124,7 +124,4 @@ static __always_inline enum lru_list page_lru(struct page *page) } return lru; } - -#define lru_to_page(head) (list_entry((head)->prev, struct page, lru)) - #endif -- 2.17.1
[PATCH 1/2] mm: Move lru_to_page to mm.h
There are multiple places in the kernel which opencode this helper, this patch moves it to the more generic mm.h header in preparation for using it. No functional changes. Signed-off-by: Nikolay Borisov --- include/linux/mm.h| 2 ++ include/linux/mm_inline.h | 3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index 5411de93a363..47b4aa5bba93 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -146,6 +146,8 @@ extern int overcommit_kbytes_handler(struct ctl_table *, int, void __user *, /* test whether an address (unsigned long or pointer) is aligned to PAGE_SIZE */ #define PAGE_ALIGNED(addr) IS_ALIGNED((unsigned long)(addr), PAGE_SIZE) +#define lru_to_page(head) (list_entry((head)->prev, struct page, lru)) + /* * Linux kernel virtual memory manager primitives. * The idea being to have a "virtual" mm in the same way diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h index 10191c28fc04..04ec454d44ce 100644 --- a/include/linux/mm_inline.h +++ b/include/linux/mm_inline.h @@ -124,7 +124,4 @@ static __always_inline enum lru_list page_lru(struct page *page) } return lru; } - -#define lru_to_page(head) (list_entry((head)->prev, struct page, lru)) - #endif -- 2.17.1
Re: [PATCH] Input: mouse: elan_i2c_core: Added support for ELAN0621 touchpad.
On Wed, Nov 28, 2018 at 04:20:01PM -0500, a...@adamwong.me wrote: > From: TheWongGuy This name, does not match: > Signed-off-by: Adam Wong That name :( Please fix. thanks, greg k-h
Re: [PATCH v4] usb/mtu3: power down device ip at setup
Thanks! On Thu, Nov 29, 2018 at 2:26 PM Chunfeng Yun wrote: > > hi Hsin-Yi, > > On Thu, 2018-11-29 at 11:16 +0800, Hsin-Yi, Wang wrote: > > Originally, when dr_mode is USB_DR_MODE_HOST, it didn't power down device > > ip, > > so host ip sleep will fail at ssusb_host_disable. > > > > Power down device ip at ssusb_host_setup. > > > > Signed-off-by: Hsin-Yi, Wang > > --- > > ChangeLog: > > V3->V4: > > *update comment > > --- > > drivers/usb/mtu3/mtu3_plat.c | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c > > index 46551f6d16fd..e086630e41a9 100644 > > --- a/drivers/usb/mtu3/mtu3_plat.c > > +++ b/drivers/usb/mtu3/mtu3_plat.c > > @@ -200,6 +200,14 @@ static void ssusb_ip_sw_reset(struct ssusb_mtk *ssusb) > > mtu3_setbits(ssusb->ippc_base, U3D_SSUSB_IP_PW_CTRL0, > > SSUSB_IP_SW_RST); > > udelay(1); > > mtu3_clrbits(ssusb->ippc_base, U3D_SSUSB_IP_PW_CTRL0, > > SSUSB_IP_SW_RST); > > + > > + /* > > + * device ip may be powered on in firmware/BROM stage before entering > > + * kernel stage; > > + * power down device ip, otherwise ip-sleep will fail when working as > > + * host only mode > > + */ > > + mtu3_setbits(ssusb->ippc_base, U3D_SSUSB_IP_PW_CTRL2, > > SSUSB_IP_DEV_PDN); > > } > > > > /* ignore the error if the clock does not exist */ > > Acked-by: Chunfeng Yun > > Thanks a lot > > >
Re: [PATCH] Input: mouse: elan_i2c_core: Added support for ELAN0621 touchpad.
On Wed, Nov 28, 2018 at 04:20:01PM -0500, a...@adamwong.me wrote: > From: TheWongGuy This name, does not match: > Signed-off-by: Adam Wong That name :( Please fix. thanks, greg k-h
Re: [PATCH v4] usb/mtu3: power down device ip at setup
Thanks! On Thu, Nov 29, 2018 at 2:26 PM Chunfeng Yun wrote: > > hi Hsin-Yi, > > On Thu, 2018-11-29 at 11:16 +0800, Hsin-Yi, Wang wrote: > > Originally, when dr_mode is USB_DR_MODE_HOST, it didn't power down device > > ip, > > so host ip sleep will fail at ssusb_host_disable. > > > > Power down device ip at ssusb_host_setup. > > > > Signed-off-by: Hsin-Yi, Wang > > --- > > ChangeLog: > > V3->V4: > > *update comment > > --- > > drivers/usb/mtu3/mtu3_plat.c | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c > > index 46551f6d16fd..e086630e41a9 100644 > > --- a/drivers/usb/mtu3/mtu3_plat.c > > +++ b/drivers/usb/mtu3/mtu3_plat.c > > @@ -200,6 +200,14 @@ static void ssusb_ip_sw_reset(struct ssusb_mtk *ssusb) > > mtu3_setbits(ssusb->ippc_base, U3D_SSUSB_IP_PW_CTRL0, > > SSUSB_IP_SW_RST); > > udelay(1); > > mtu3_clrbits(ssusb->ippc_base, U3D_SSUSB_IP_PW_CTRL0, > > SSUSB_IP_SW_RST); > > + > > + /* > > + * device ip may be powered on in firmware/BROM stage before entering > > + * kernel stage; > > + * power down device ip, otherwise ip-sleep will fail when working as > > + * host only mode > > + */ > > + mtu3_setbits(ssusb->ippc_base, U3D_SSUSB_IP_PW_CTRL2, > > SSUSB_IP_DEV_PDN); > > } > > > > /* ignore the error if the clock does not exist */ > > Acked-by: Chunfeng Yun > > Thanks a lot > > >
Re: [PATCH v4 4/6] coresight: Use PMU driver configuration for sink selection
On Wed, Nov 28, 2018 at 03:01:16PM -0700, Mathieu Poirier wrote: > This patch uses the PMU driver configuration held in event::hw::drv_config > to select a sink for each event that is created (the old sysFS way of > working is kept around for backward compatibility). It is "sysfs", no InterCaps please, I've never called it that in the past. And just use sysfs, if that does not work properly, then fix that, don't create yet-another-way-to-configure-this-thing to just confuse people. thanks, greg k-h
Re: [PATCH v4 4/6] coresight: Use PMU driver configuration for sink selection
On Wed, Nov 28, 2018 at 03:01:16PM -0700, Mathieu Poirier wrote: > This patch uses the PMU driver configuration held in event::hw::drv_config > to select a sink for each event that is created (the old sysFS way of > working is kept around for backward compatibility). It is "sysfs", no InterCaps please, I've never called it that in the past. And just use sysfs, if that does not work properly, then fix that, don't create yet-another-way-to-configure-this-thing to just confuse people. thanks, greg k-h
[tip:x86/cache] x86/resctrl: Remove unnecessary check for cbm_validate()
Commit-ID: cb74635faa17cfa2991ddbe027596270af525c6d
Gitweb: https://git.kernel.org/tip/cb74635faa17cfa2991ddbe027596270af525c6d
Author: Babu Moger
AuthorDate: Wed, 28 Nov 2018 22:42:47 +
Committer: Borislav Petkov
CommitDate: Thu, 29 Nov 2018 08:36:12 +0100
x86/resctrl: Remove unnecessary check for cbm_validate()
The Smatch static checker reports the following error after commit:
a36c5ff560fb ("x86/resctrl: Bring cbm_validate() into the resource
structure"):
arch/x86/kernel/cpu/resctrl/ctrlmondata.c:227 parse_cbm()
error: uninitialized symbol 'cbm_val'.
arch/x86/kernel/cpu/resctrl/ctrlmondata.c:236 parse_cbm()
error: uninitialized symbol 'cbm_val'.
This could happen if ->cbm_validate() is NULL which could leave cbm_val
uninitialized.
However, there is no case where ->cbm_validate() can be NULL as it is
initialized based on a vendor check. So it is either an Intel or an AMD
version it points to. And in both the cases it is initialized properly.
Thus, remove the first check.
Verified the fix running Smatch.
[ bp: massage commit message. ]
Fixes: a36c5ff560fb ("x86/resctrl: Bring cbm_validate() into the resource
structure")
Reported-by: Dan Carpenter
Signed-off-by: Babu Moger
Signed-off-by: Borislav Petkov
Cc: Fenghua Yu
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Reinette Chatre
Cc: Thomas Gleixner
Cc: x86-ml
Link: https://lkml.kernel.org/r/20181128224234.22998-1-babu.mo...@amd.com
---
arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
index 03ee13235a45..ba11f54f5ab8 100644
--- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
+++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
@@ -219,7 +219,7 @@ int parse_cbm(struct rdt_parse_data *data, struct
rdt_resource *r,
return -EINVAL;
}
- if (r->cbm_validate && !r->cbm_validate(data->buf, _val, r))
+ if (!r->cbm_validate(data->buf, _val, r))
return -EINVAL;
if ((rdtgrp->mode == RDT_MODE_EXCLUSIVE ||
[tip:x86/cache] x86/resctrl: Remove unnecessary check for cbm_validate()
Commit-ID: cb74635faa17cfa2991ddbe027596270af525c6d
Gitweb: https://git.kernel.org/tip/cb74635faa17cfa2991ddbe027596270af525c6d
Author: Babu Moger
AuthorDate: Wed, 28 Nov 2018 22:42:47 +
Committer: Borislav Petkov
CommitDate: Thu, 29 Nov 2018 08:36:12 +0100
x86/resctrl: Remove unnecessary check for cbm_validate()
The Smatch static checker reports the following error after commit:
a36c5ff560fb ("x86/resctrl: Bring cbm_validate() into the resource
structure"):
arch/x86/kernel/cpu/resctrl/ctrlmondata.c:227 parse_cbm()
error: uninitialized symbol 'cbm_val'.
arch/x86/kernel/cpu/resctrl/ctrlmondata.c:236 parse_cbm()
error: uninitialized symbol 'cbm_val'.
This could happen if ->cbm_validate() is NULL which could leave cbm_val
uninitialized.
However, there is no case where ->cbm_validate() can be NULL as it is
initialized based on a vendor check. So it is either an Intel or an AMD
version it points to. And in both the cases it is initialized properly.
Thus, remove the first check.
Verified the fix running Smatch.
[ bp: massage commit message. ]
Fixes: a36c5ff560fb ("x86/resctrl: Bring cbm_validate() into the resource
structure")
Reported-by: Dan Carpenter
Signed-off-by: Babu Moger
Signed-off-by: Borislav Petkov
Cc: Fenghua Yu
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Reinette Chatre
Cc: Thomas Gleixner
Cc: x86-ml
Link: https://lkml.kernel.org/r/20181128224234.22998-1-babu.mo...@amd.com
---
arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
index 03ee13235a45..ba11f54f5ab8 100644
--- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
+++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
@@ -219,7 +219,7 @@ int parse_cbm(struct rdt_parse_data *data, struct
rdt_resource *r,
return -EINVAL;
}
- if (r->cbm_validate && !r->cbm_validate(data->buf, _val, r))
+ if (!r->cbm_validate(data->buf, _val, r))
return -EINVAL;
if ((rdtgrp->mode == RDT_MODE_EXCLUSIVE ||
[PATCH v4 3/4] perf report: Display average IPC and IPC coverage per symbol
Support displaying the average IPC and IPC coverage per symbol
in perf report TUI and stdio modes.
For example,
$ perf record -b ...
$ perf report -s symbol
Overhead Symbol IPC [IPC Coverage]
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
Jiri Olsa provides the patch to support the
stdio mode. I merge Jiri's code in this patch.
$ perf report -s symbol --stdio
# Overhead Symbol IPC [IPC Coverage]
# ...
#
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
0.02% [k] run_timer_softirq 1.60 [ 57.2%]
The columns "IPC" and "[IPC Coverage]" are automatically enabled
when the sort-key "symbol" is specified. If the perf.data doesn't
contain timed LBR information, columns are filled with "-".
For example,
# Overhead Symbol IPC [IPC Coverage]
# ...
#
46.57% [.] main - -
17.60% [.] rand - -
15.84% [.] __random_r - -
11.90% [.] __random - -
6.50% [.] compute_flag - -
1.59% [.] rand@plt - -
0.00% [.] _dl_relocate_object - -
0.00% [k] tlb_flush_mmu- -
0.00% [k] perf_event_mmap - -
0.00% [k] native_sched_clock - -
0.00% [k] intel_pmu_handle_irq_v4 - -
0.00% [k] native_write_msr - -
v3:
---
Removed the sortkey 'ipc' from command-line. The columns "IPC"
and "[IPC Coverage]" are automatically enabled when "symbol"
is specified.
v2:
---
Merge in Jiri's patch to support stdio mode
Signed-off-by: Jin Yao
---
tools/perf/builtin-report.c | 26 ---
tools/perf/util/hist.h | 1 +
tools/perf/util/sort.c | 61 +
tools/perf/util/sort.h | 2 ++
4 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 257c9c1..4958095 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -85,6 +85,7 @@ struct report {
int socket_filter;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
struct branch_type_stat brtype_stat;
+ boolsymbol_ipc;
};
static int report__config(const char *var, const char *value, void *cb)
@@ -129,7 +130,7 @@ static int hist_iter__report_callback(struct
hist_entry_iter *iter,
struct mem_info *mi;
struct branch_info *bi;
- if (!ui__has_annotation())
+ if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
hist__account_cycles(sample->branch_stack, al, sample,
@@ -174,7 +175,7 @@ static int hist_iter__branch_callback(struct
hist_entry_iter *iter,
struct perf_evsel *evsel = iter->evsel;
int err;
- if (!ui__has_annotation())
+ if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
hist__account_cycles(sample->branch_stack, al, sample,
@@ -1133,6 +1134,7 @@ int cmd_report(int argc, const char **argv)
.mode = PERF_DATA_MODE_READ,
};
int ret = hists__init();
+ char sort_tmp[128];
if (ret < 0)
return ret;
@@ -1284,6 +1286,24 @@ int cmd_report(int argc, const char **argv)
else
use_browser = 0;
+ if (sort_order && strstr(sort_order, "ipc")) {
+ parse_options_usage(report_usage, options, "s", 1);
+ goto error;
+ }
+
+ if (sort_order && strstr(sort_order, "symbol")) {
+ if (sort__mode == SORT_MODE__BRANCH) {
+ snprintf(sort_tmp, sizeof(sort_tmp), "%s,%s",
+sort_order, "ipc_lbr");
+ report.symbol_ipc = true;
+ } else {
+ snprintf(sort_tmp, sizeof(sort_tmp), "%s,%s",
+sort_order, "ipc_null");
+ }
+
+ sort_order = sort_tmp;
+ }
+
if (setup_sorting(session->evlist) < 0) {
if (sort_order)
parse_options_usage(report_usage,
[PATCH v4 2/4] perf annotate: Create a annotate2 flag in struct symbol
We often use the symbol__annotate2() to annotate a specified symbol.
While annotating may take some time, so in order to avoid annotating
the same symbol repeatedly, the patch creates a new flag to indicate
the symbol has been annotated.
Signed-off-by: Jin Yao
---
tools/perf/util/annotate.c | 1 +
tools/perf/util/symbol.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 4b2b1b0..f69d8e1 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -2798,6 +2798,7 @@ int symbol__annotate2(struct symbol *sym, struct map
*map, struct perf_evsel *ev
notes->nr_events = nr_pcnt;
annotation__update_column_widths(notes);
+ sym->annotate2 = true;
return 0;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index d026d21..14d9d43 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -63,6 +63,7 @@ struct symbol {
u8 ignore:1;
u8 inlined:1;
u8 arch_sym;
+ boolannotate2;
charname[0];
};
--
2.7.4
[PATCH v4 0/4] perf report/annotate: Support average IPC and IPC coverage for function
Add supporting of displaying the average IPC and IPC coverage
percentage per function.
For example,
$ perf record -b ...
$ perf report -s symbol or
perf report -s symbol --stdio
Overhead Symbol IPC [IPC Coverage]
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
...
$ perf annotate --stdio2
Percent IPC Cycle (Average IPC: 2.30, IPC Coverage: 54.8%)
Disassembly of section .text:
0003aac0 :
8.32 3.28 sub$0x18,%rsp
3.28 mov$0x1,%esi
3.28 xor%eax,%eax
3.28 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
11.57 3.28 1 ↓ je 20
lock cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne29
↓ jmp43
11.57 1.1020: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
...
v4:
---
Add a new patch "perf report: Documentation average IPC and IPC coverage"
to explain the new columns "IPC" and "IPC Coverage".
Other patches are not changed.
v3:
---
Remove the sortkey "ipc" from command-line. The columns "IPC"
and "[IPC Coverage]" are automatically enabled when "symbol"
is specified.
Patch "perf report: Display average IPC and IPC coverage per symbol"
is impacted.
v2:
---
1. Merge in Jiri's patch to support stdio mode
2. Add a new patch "perf annotate: Create a annotate2 flag
in struct symbol" which records if the symbol has been
annotated yet.
3. Minor update such as adding { } for multiline code in 'if'
condition.
Jin Yao (4):
perf annotate: Compute average IPC and IPC coverage per symbol
perf annotate: Create a annotate2 flag in struct symbol
perf report: Display average IPC and IPC coverage per symbol
perf report: Documentation average IPC and IPC coverage
tools/perf/Documentation/perf-report.txt | 8 +
tools/perf/builtin-report.c | 26 --
tools/perf/util/annotate.c | 42 --
tools/perf/util/annotate.h | 5 +++
tools/perf/util/hist.h | 1 +
tools/perf/util/sort.c | 61
tools/perf/util/sort.h | 2 ++
tools/perf/util/symbol.h | 1 +
8 files changed, 140 insertions(+), 6 deletions(-)
--
2.7.4
[PATCH v4 3/4] perf report: Display average IPC and IPC coverage per symbol
Support displaying the average IPC and IPC coverage per symbol
in perf report TUI and stdio modes.
For example,
$ perf record -b ...
$ perf report -s symbol
Overhead Symbol IPC [IPC Coverage]
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
Jiri Olsa provides the patch to support the
stdio mode. I merge Jiri's code in this patch.
$ perf report -s symbol --stdio
# Overhead Symbol IPC [IPC Coverage]
# ...
#
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
0.02% [k] run_timer_softirq 1.60 [ 57.2%]
The columns "IPC" and "[IPC Coverage]" are automatically enabled
when the sort-key "symbol" is specified. If the perf.data doesn't
contain timed LBR information, columns are filled with "-".
For example,
# Overhead Symbol IPC [IPC Coverage]
# ...
#
46.57% [.] main - -
17.60% [.] rand - -
15.84% [.] __random_r - -
11.90% [.] __random - -
6.50% [.] compute_flag - -
1.59% [.] rand@plt - -
0.00% [.] _dl_relocate_object - -
0.00% [k] tlb_flush_mmu- -
0.00% [k] perf_event_mmap - -
0.00% [k] native_sched_clock - -
0.00% [k] intel_pmu_handle_irq_v4 - -
0.00% [k] native_write_msr - -
v3:
---
Removed the sortkey 'ipc' from command-line. The columns "IPC"
and "[IPC Coverage]" are automatically enabled when "symbol"
is specified.
v2:
---
Merge in Jiri's patch to support stdio mode
Signed-off-by: Jin Yao
---
tools/perf/builtin-report.c | 26 ---
tools/perf/util/hist.h | 1 +
tools/perf/util/sort.c | 61 +
tools/perf/util/sort.h | 2 ++
4 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 257c9c1..4958095 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -85,6 +85,7 @@ struct report {
int socket_filter;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
struct branch_type_stat brtype_stat;
+ boolsymbol_ipc;
};
static int report__config(const char *var, const char *value, void *cb)
@@ -129,7 +130,7 @@ static int hist_iter__report_callback(struct
hist_entry_iter *iter,
struct mem_info *mi;
struct branch_info *bi;
- if (!ui__has_annotation())
+ if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
hist__account_cycles(sample->branch_stack, al, sample,
@@ -174,7 +175,7 @@ static int hist_iter__branch_callback(struct
hist_entry_iter *iter,
struct perf_evsel *evsel = iter->evsel;
int err;
- if (!ui__has_annotation())
+ if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
hist__account_cycles(sample->branch_stack, al, sample,
@@ -1133,6 +1134,7 @@ int cmd_report(int argc, const char **argv)
.mode = PERF_DATA_MODE_READ,
};
int ret = hists__init();
+ char sort_tmp[128];
if (ret < 0)
return ret;
@@ -1284,6 +1286,24 @@ int cmd_report(int argc, const char **argv)
else
use_browser = 0;
+ if (sort_order && strstr(sort_order, "ipc")) {
+ parse_options_usage(report_usage, options, "s", 1);
+ goto error;
+ }
+
+ if (sort_order && strstr(sort_order, "symbol")) {
+ if (sort__mode == SORT_MODE__BRANCH) {
+ snprintf(sort_tmp, sizeof(sort_tmp), "%s,%s",
+sort_order, "ipc_lbr");
+ report.symbol_ipc = true;
+ } else {
+ snprintf(sort_tmp, sizeof(sort_tmp), "%s,%s",
+sort_order, "ipc_null");
+ }
+
+ sort_order = sort_tmp;
+ }
+
if (setup_sorting(session->evlist) < 0) {
if (sort_order)
parse_options_usage(report_usage,
[PATCH v4 2/4] perf annotate: Create a annotate2 flag in struct symbol
We often use the symbol__annotate2() to annotate a specified symbol.
While annotating may take some time, so in order to avoid annotating
the same symbol repeatedly, the patch creates a new flag to indicate
the symbol has been annotated.
Signed-off-by: Jin Yao
---
tools/perf/util/annotate.c | 1 +
tools/perf/util/symbol.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 4b2b1b0..f69d8e1 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -2798,6 +2798,7 @@ int symbol__annotate2(struct symbol *sym, struct map
*map, struct perf_evsel *ev
notes->nr_events = nr_pcnt;
annotation__update_column_widths(notes);
+ sym->annotate2 = true;
return 0;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index d026d21..14d9d43 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -63,6 +63,7 @@ struct symbol {
u8 ignore:1;
u8 inlined:1;
u8 arch_sym;
+ boolannotate2;
charname[0];
};
--
2.7.4
[PATCH v4 0/4] perf report/annotate: Support average IPC and IPC coverage for function
Add supporting of displaying the average IPC and IPC coverage
percentage per function.
For example,
$ perf record -b ...
$ perf report -s symbol or
perf report -s symbol --stdio
Overhead Symbol IPC [IPC Coverage]
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
...
$ perf annotate --stdio2
Percent IPC Cycle (Average IPC: 2.30, IPC Coverage: 54.8%)
Disassembly of section .text:
0003aac0 :
8.32 3.28 sub$0x18,%rsp
3.28 mov$0x1,%esi
3.28 xor%eax,%eax
3.28 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
11.57 3.28 1 ↓ je 20
lock cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne29
↓ jmp43
11.57 1.1020: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
...
v4:
---
Add a new patch "perf report: Documentation average IPC and IPC coverage"
to explain the new columns "IPC" and "IPC Coverage".
Other patches are not changed.
v3:
---
Remove the sortkey "ipc" from command-line. The columns "IPC"
and "[IPC Coverage]" are automatically enabled when "symbol"
is specified.
Patch "perf report: Display average IPC and IPC coverage per symbol"
is impacted.
v2:
---
1. Merge in Jiri's patch to support stdio mode
2. Add a new patch "perf annotate: Create a annotate2 flag
in struct symbol" which records if the symbol has been
annotated yet.
3. Minor update such as adding { } for multiline code in 'if'
condition.
Jin Yao (4):
perf annotate: Compute average IPC and IPC coverage per symbol
perf annotate: Create a annotate2 flag in struct symbol
perf report: Display average IPC and IPC coverage per symbol
perf report: Documentation average IPC and IPC coverage
tools/perf/Documentation/perf-report.txt | 8 +
tools/perf/builtin-report.c | 26 --
tools/perf/util/annotate.c | 42 --
tools/perf/util/annotate.h | 5 +++
tools/perf/util/hist.h | 1 +
tools/perf/util/sort.c | 61
tools/perf/util/sort.h | 2 ++
tools/perf/util/symbol.h | 1 +
8 files changed, 140 insertions(+), 6 deletions(-)
--
2.7.4
[PATCH v4 1/4] perf annotate: Compute average IPC and IPC coverage per symbol
Add support to perf report annotate view or perf annotate --stdio2 to
aggregate the IPC derived from timed LBRs per symbol. We compute the
average IPC and the IPC coverage percentage.
For example,
$ perf annotate --stdio2
Percent IPC Cycle (Average IPC: 2.30, IPC Coverage: 54.8%)
Disassembly of section .text:
0003aac0 :
8.32 3.28 sub$0x18,%rsp
3.28 mov$0x1,%esi
3.28 xor%eax,%eax
3.28 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
11.57 3.28 1 ↓ je 20
lock cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne29
↓ jmp43
11.57 1.1020: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
0.00 1.10 1 ↓ je 43
29: lea__abort_msg@@GLIBC_PRIVATE+0x8a0,%rdi
sub$0x80,%rsp
→ callq __lll_lock_wait_private
add$0x80,%rsp
0.00 3.0043: lea__ctype_b@GLIBC_2.2.5+0x38,%rdi
3.00 lea0xc(%rsp),%rsi
8.49 3.00 1 → callq __random_r
7.91 1.94 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
0.00 1.94 1 ↓ je 68
lock decl __abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne70
↓ jmp8a
0.00 2.0068: decl __abort_msg@@GLIBC_PRIVATE+0x8a0
21.56 2.00 1 ↓ je 8a
70: lea__abort_msg@@GLIBC_PRIVATE+0x8a0,%rdi
sub$0x80,%rsp
→ callq __lll_unlock_wake_private
add$0x80,%rsp
21.56 2.908a: movslq 0xc(%rsp),%rax
2.90 add$0x18,%rsp
9.03 2.90 1 ← retq
It shows for this symbol the average IPC is 2.30 and the IPC coverage
is 54.8%.
Signed-off-by: Jin Yao
---
tools/perf/util/annotate.c | 41 ++---
tools/perf/util/annotate.h | 5 +
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 6936daf..4b2b1b0 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1000,6 +1000,7 @@ static unsigned annotation__count_insn(struct annotation
*notes, u64 start, u64
static void annotation__count_and_fill(struct annotation *notes, u64 start,
u64 end, struct cyc_hist *ch)
{
unsigned n_insn;
+ unsigned int cover_insn = 0;
u64 offset;
n_insn = annotation__count_insn(notes, start, end);
@@ -1013,21 +1014,34 @@ static void annotation__count_and_fill(struct
annotation *notes, u64 start, u64
for (offset = start; offset <= end; offset++) {
struct annotation_line *al = notes->offsets[offset];
- if (al)
+ if (al && al->ipc == 0.0) {
al->ipc = ipc;
+ cover_insn++;
+ }
+ }
+
+ if (cover_insn) {
+ notes->hit_cycles += ch->cycles;
+ notes->hit_insn += n_insn * ch->num;
+ notes->cover_insn += cover_insn;
}
}
}
void annotation__compute_ipc(struct annotation *notes, size_t size)
{
- u64 offset;
+ s64 offset;
if (!notes->src || !notes->src->cycles_hist)
return;
+ notes->total_insn = annotation__count_insn(notes, 0, size - 1);
+ notes->hit_cycles = 0;
+ notes->hit_insn = 0;
+ notes->cover_insn = 0;
+
pthread_mutex_lock(>lock);
- for (offset = 0; offset < size; ++offset) {
+ for (offset = size - 1; offset >= 0; --offset) {
struct cyc_hist *ch;
ch = >src->cycles_hist[offset];
@@ -2563,6 +2577,22 @@ static void disasm_line__write(struct disasm_line *dl,
struct annotation *notes,
disasm_line__scnprintf(dl, bf, size, !notes->options->use_offset);
}
+static void ipc_coverage_string(char *bf, int size, struct annotation *notes)
+{
+ double ipc = 0.0, coverage = 0.0;
+
+ if (notes->hit_cycles)
+ ipc = notes->hit_insn / ((double)notes->hit_cycles);
+
+ if (notes->total_insn) {
+ coverage = notes->cover_insn * 100.0 /
+ ((double)notes->total_insn);
+ }
+
+ scnprintf(bf, size, "(Average IPC: %.2f, IPC Coverage: %.1f%%)",
+ ipc, coverage);
+}
+
static void __annotation_line__write(struct annotation_line *al, struct
annotation *notes,
bool first_line, bool current_entry, bool
change_color, int width,
void *obj,
Re: [PATCH] crypto: do not free algorithm before using
On Thu, Nov 29, 2018 at 02:57:11PM +0800, Herbert Xu wrote: > On Thu, Nov 22, 2018 at 06:00:16PM +0800, Pan Bian wrote: > > In multiple functions, the algorithm fields are read after its reference > > is dropped through crypto_mod_put. In this case, the algorithm memory > > may be freed, resulting in use-after-free bugs. This patch delays the > > put operation until the algorithm is never used. > > > > Signed-off-by: Pan Bian > > Patch applied. Thanks! > > BTW, this problem exists in almost every other skcipher template, > e.g., in ctr. Are you working on a fix for them too? Probably not. Could you please provide patches to fix them? Thanks, Pan > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 2/6] perf/core: Use ioctl to communicate driver configuration to kernel
On Wed, Nov 28, 2018 at 03:01:14PM -0700, Mathieu Poirier wrote: > This patch adds the mechanic needed for user space to send PMU specific > configuration to the kernel driver using an ioctl() command. That way > events can keep track of options that don't fit in the perf_event_attr > structure like the selection of a CoreSight sink to use for the session. This is what configfs is for, please use that instead of a generic "send a string to the kernel for it to parse" type of thing. No other driver does this (or if they do, they should not), so this driver should not do it as well, sorry. greg k-h
[PATCH v4 4/4] perf report: Documentation average IPC and IPC coverage
Add explanations for new columns "IPC" and "IPC coverage" in perf documentation. Signed-off-by: Jin Yao --- tools/perf/Documentation/perf-report.txt | 8 1 file changed, 8 insertions(+) diff --git a/tools/perf/Documentation/perf-report.txt b/tools/perf/Documentation/perf-report.txt index 474a494..e5a32f3 100644 --- a/tools/perf/Documentation/perf-report.txt +++ b/tools/perf/Documentation/perf-report.txt @@ -126,6 +126,14 @@ OPTIONS And default sort keys are changed to comm, dso_from, symbol_from, dso_to and symbol_to, see '--branch-stack'. + When the sort key symbol is specified, columns "IPC" and "IPC Coverage" + are enabled automatically. Column "IPC" reports the average IPC per function + and column "IPC coverage" reports the percentage of instructions with + sampled IPC in this function. IPC means Instruction Per Cycle. If it's low, + it indicates there may be performance bottleneck when the function is + executed, such as, memory access bottleneck. If a function has high overhead + and low IPC, it's worth further analysis for performance optimization. + If the --mem-mode option is used, the following sort keys are also available (incompatible with --branch-stack): symbol_daddr, dso_daddr, locked, tlb, mem, snoop, dcacheline. -- 2.7.4
[PATCH v4 1/4] perf annotate: Compute average IPC and IPC coverage per symbol
Add support to perf report annotate view or perf annotate --stdio2 to
aggregate the IPC derived from timed LBRs per symbol. We compute the
average IPC and the IPC coverage percentage.
For example,
$ perf annotate --stdio2
Percent IPC Cycle (Average IPC: 2.30, IPC Coverage: 54.8%)
Disassembly of section .text:
0003aac0 :
8.32 3.28 sub$0x18,%rsp
3.28 mov$0x1,%esi
3.28 xor%eax,%eax
3.28 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
11.57 3.28 1 ↓ je 20
lock cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne29
↓ jmp43
11.57 1.1020: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
0.00 1.10 1 ↓ je 43
29: lea__abort_msg@@GLIBC_PRIVATE+0x8a0,%rdi
sub$0x80,%rsp
→ callq __lll_lock_wait_private
add$0x80,%rsp
0.00 3.0043: lea__ctype_b@GLIBC_2.2.5+0x38,%rdi
3.00 lea0xc(%rsp),%rsi
8.49 3.00 1 → callq __random_r
7.91 1.94 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
0.00 1.94 1 ↓ je 68
lock decl __abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne70
↓ jmp8a
0.00 2.0068: decl __abort_msg@@GLIBC_PRIVATE+0x8a0
21.56 2.00 1 ↓ je 8a
70: lea__abort_msg@@GLIBC_PRIVATE+0x8a0,%rdi
sub$0x80,%rsp
→ callq __lll_unlock_wake_private
add$0x80,%rsp
21.56 2.908a: movslq 0xc(%rsp),%rax
2.90 add$0x18,%rsp
9.03 2.90 1 ← retq
It shows for this symbol the average IPC is 2.30 and the IPC coverage
is 54.8%.
Signed-off-by: Jin Yao
---
tools/perf/util/annotate.c | 41 ++---
tools/perf/util/annotate.h | 5 +
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 6936daf..4b2b1b0 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1000,6 +1000,7 @@ static unsigned annotation__count_insn(struct annotation
*notes, u64 start, u64
static void annotation__count_and_fill(struct annotation *notes, u64 start,
u64 end, struct cyc_hist *ch)
{
unsigned n_insn;
+ unsigned int cover_insn = 0;
u64 offset;
n_insn = annotation__count_insn(notes, start, end);
@@ -1013,21 +1014,34 @@ static void annotation__count_and_fill(struct
annotation *notes, u64 start, u64
for (offset = start; offset <= end; offset++) {
struct annotation_line *al = notes->offsets[offset];
- if (al)
+ if (al && al->ipc == 0.0) {
al->ipc = ipc;
+ cover_insn++;
+ }
+ }
+
+ if (cover_insn) {
+ notes->hit_cycles += ch->cycles;
+ notes->hit_insn += n_insn * ch->num;
+ notes->cover_insn += cover_insn;
}
}
}
void annotation__compute_ipc(struct annotation *notes, size_t size)
{
- u64 offset;
+ s64 offset;
if (!notes->src || !notes->src->cycles_hist)
return;
+ notes->total_insn = annotation__count_insn(notes, 0, size - 1);
+ notes->hit_cycles = 0;
+ notes->hit_insn = 0;
+ notes->cover_insn = 0;
+
pthread_mutex_lock(>lock);
- for (offset = 0; offset < size; ++offset) {
+ for (offset = size - 1; offset >= 0; --offset) {
struct cyc_hist *ch;
ch = >src->cycles_hist[offset];
@@ -2563,6 +2577,22 @@ static void disasm_line__write(struct disasm_line *dl,
struct annotation *notes,
disasm_line__scnprintf(dl, bf, size, !notes->options->use_offset);
}
+static void ipc_coverage_string(char *bf, int size, struct annotation *notes)
+{
+ double ipc = 0.0, coverage = 0.0;
+
+ if (notes->hit_cycles)
+ ipc = notes->hit_insn / ((double)notes->hit_cycles);
+
+ if (notes->total_insn) {
+ coverage = notes->cover_insn * 100.0 /
+ ((double)notes->total_insn);
+ }
+
+ scnprintf(bf, size, "(Average IPC: %.2f, IPC Coverage: %.1f%%)",
+ ipc, coverage);
+}
+
static void __annotation_line__write(struct annotation_line *al, struct
annotation *notes,
bool first_line, bool current_entry, bool
change_color, int width,
void *obj,
Re: [PATCH] crypto: do not free algorithm before using
On Thu, Nov 29, 2018 at 02:57:11PM +0800, Herbert Xu wrote: > On Thu, Nov 22, 2018 at 06:00:16PM +0800, Pan Bian wrote: > > In multiple functions, the algorithm fields are read after its reference > > is dropped through crypto_mod_put. In this case, the algorithm memory > > may be freed, resulting in use-after-free bugs. This patch delays the > > put operation until the algorithm is never used. > > > > Signed-off-by: Pan Bian > > Patch applied. Thanks! > > BTW, this problem exists in almost every other skcipher template, > e.g., in ctr. Are you working on a fix for them too? Probably not. Could you please provide patches to fix them? Thanks, Pan > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v4 2/6] perf/core: Use ioctl to communicate driver configuration to kernel
On Wed, Nov 28, 2018 at 03:01:14PM -0700, Mathieu Poirier wrote: > This patch adds the mechanic needed for user space to send PMU specific > configuration to the kernel driver using an ioctl() command. That way > events can keep track of options that don't fit in the perf_event_attr > structure like the selection of a CoreSight sink to use for the session. This is what configfs is for, please use that instead of a generic "send a string to the kernel for it to parse" type of thing. No other driver does this (or if they do, they should not), so this driver should not do it as well, sorry. greg k-h
[PATCH v4 4/4] perf report: Documentation average IPC and IPC coverage
Add explanations for new columns "IPC" and "IPC coverage" in perf documentation. Signed-off-by: Jin Yao --- tools/perf/Documentation/perf-report.txt | 8 1 file changed, 8 insertions(+) diff --git a/tools/perf/Documentation/perf-report.txt b/tools/perf/Documentation/perf-report.txt index 474a494..e5a32f3 100644 --- a/tools/perf/Documentation/perf-report.txt +++ b/tools/perf/Documentation/perf-report.txt @@ -126,6 +126,14 @@ OPTIONS And default sort keys are changed to comm, dso_from, symbol_from, dso_to and symbol_to, see '--branch-stack'. + When the sort key symbol is specified, columns "IPC" and "IPC Coverage" + are enabled automatically. Column "IPC" reports the average IPC per function + and column "IPC coverage" reports the percentage of instructions with + sampled IPC in this function. IPC means Instruction Per Cycle. If it's low, + it indicates there may be performance bottleneck when the function is + executed, such as, memory access bottleneck. If a function has high overhead + and low IPC, it's worth further analysis for performance optimization. + If the --mem-mode option is used, the following sort keys are also available (incompatible with --branch-stack): symbol_daddr, dso_daddr, locked, tlb, mem, snoop, dcacheline. -- 2.7.4
Re: [PATCH v4 1/6] perf: Introduce ioctl to communicate driver configuration to kernel
On Wed, Nov 28, 2018 at 03:01:13PM -0700, Mathieu Poirier wrote:
> Adding a new IOCTL command to communicate PMU specific configuration to
> PMU kernel drivers. This can be anything a PMU might need for
> configuration that doesn't fit in the perf_event_attr structure, such
> as the CoreSight sink to use for a session.
>
> Signed-off-by: Mathieu Poirier
> ---
> include/uapi/linux/perf_event.h | 1 +
> tools/include/uapi/linux/perf_event.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 9de8780ac8d9..bb558caeb33b 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -462,6 +462,7 @@ struct perf_event_query_bpf {
> #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> #define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct
> perf_event_query_bpf *)
> #define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct
> perf_event_attr *)
> +#define PERF_EVENT_IOC_SET_DRV_CONFIG_IOW('$', 12, char *)
A generic "char *" that the kernel is then going to parse? Can you make
any more flexible of a new syscall to the kernel that allows anyone to
do anything with this? :)
Please make this a lot more specific, this is way to generic, sorry.
greg k-h
Re: [PATCH v4 1/6] perf: Introduce ioctl to communicate driver configuration to kernel
On Wed, Nov 28, 2018 at 03:01:13PM -0700, Mathieu Poirier wrote:
> Adding a new IOCTL command to communicate PMU specific configuration to
> PMU kernel drivers. This can be anything a PMU might need for
> configuration that doesn't fit in the perf_event_attr structure, such
> as the CoreSight sink to use for a session.
>
> Signed-off-by: Mathieu Poirier
> ---
> include/uapi/linux/perf_event.h | 1 +
> tools/include/uapi/linux/perf_event.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 9de8780ac8d9..bb558caeb33b 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -462,6 +462,7 @@ struct perf_event_query_bpf {
> #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> #define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct
> perf_event_query_bpf *)
> #define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct
> perf_event_attr *)
> +#define PERF_EVENT_IOC_SET_DRV_CONFIG_IOW('$', 12, char *)
A generic "char *" that the kernel is then going to parse? Can you make
any more flexible of a new syscall to the kernel that allows anyone to
do anything with this? :)
Please make this a lot more specific, this is way to generic, sorry.
greg k-h
RE: [PATCH v13 0/5] Add i.MX8MQ clock driver
> -Original Message-
> From: Stephen Boyd [mailto:sb...@kernel.org]
[...]
> >
> > Changes since v12:
> > * replaced the division in clk_pll_recalc_rate in clk-frac
> >with do_div as suggested by Stephen
> >
> > Abel Vesa (2):
> > clk: imx: Add imx composite clock
> > clk: imx: Add clock driver for i.MX8MQ CCM
> >
> > Lucas Stach (3):
> > dt-bindings: add binding for i.MX8MQ CCM
> > clk: imx: add fractional PLL output clock
> > clk: imx: Add SCCG PLL type
> >
>
> I had to apply this set of fixes to silence sparse and smatch warnings about
> things that are not right. Please take a look over things and see if it's
> sane.
>
The change looks good to me and tested ok.
I did not see this patch series in your tree.
Do you want us to apply your changes and re-send for easy pick up?
Regards
Dong Aisheng
> diff --git a/drivers/clk/imx/clk-composite-8m.c
> b/drivers/clk/imx/clk-composite-8m.c
> index bcd31d889584..6d9d3714b4df 100644
> --- a/drivers/clk/imx/clk-composite-8m.c
> +++ b/drivers/clk/imx/clk-composite-8m.c
> @@ -127,8 +127,8 @@ struct clk *imx8m_clk_composite_flags(const char
> *name,
> int num_parents, void __iomem *reg,
> unsigned long flags)
> {
> - struct clk_hw *hw = NULL, *mux_hw = NULL;
> - struct clk_hw *div_hw = NULL, *gate_hw = NULL;
> + struct clk_hw *hw = ERR_PTR(-ENOMEM), *mux_hw;
> + struct clk_hw *div_hw, *gate_hw;
> struct clk_divider *div = NULL;
> struct clk_gate *gate = NULL;
> struct clk_mux *mux = NULL;
> diff --git a/drivers/clk/imx/clk-frac-pll.c b/drivers/clk/imx/clk-frac-pll.c
> index
> a3732be5ad7f..98726206f3c4 100644
> --- a/drivers/clk/imx/clk-frac-pll.c
> +++ b/drivers/clk/imx/clk-frac-pll.c
> @@ -14,6 +14,8 @@
> #include
> #include
>
> +#include "clk.h"
> +
> #define PLL_CFG0 0x0
> #define PLL_CFG1 0x4
>
> @@ -214,7 +216,7 @@ struct clk *imx_clk_frac_pll(const char *name, const
> char *parent_name,
> ret = clk_hw_register(NULL, hw);
> if (ret) {
> kfree(pll);
> - return ERR_CAST(hw);
> + return ERR_PTR(ret);
> }
>
> return hw->clk;
> diff --git a/drivers/clk/imx/clk-sccg-pll.c b/drivers/clk/imx/clk-sccg-pll.c
> index
> 4666b96bdb3f..ee7752bace89 100644
> --- a/drivers/clk/imx/clk-sccg-pll.c
> +++ b/drivers/clk/imx/clk-sccg-pll.c
> @@ -249,7 +249,7 @@ struct clk *imx_clk_sccg_pll(const char *name,
> ret = clk_hw_register(NULL, hw);
> if (ret) {
> kfree(pll);
> - return ERR_CAST(hw);
> + return ERR_PTR(ret);
> }
>
> return hw->clk;
RE: [PATCH v13 0/5] Add i.MX8MQ clock driver
> -Original Message-
> From: Stephen Boyd [mailto:sb...@kernel.org]
[...]
> >
> > Changes since v12:
> > * replaced the division in clk_pll_recalc_rate in clk-frac
> >with do_div as suggested by Stephen
> >
> > Abel Vesa (2):
> > clk: imx: Add imx composite clock
> > clk: imx: Add clock driver for i.MX8MQ CCM
> >
> > Lucas Stach (3):
> > dt-bindings: add binding for i.MX8MQ CCM
> > clk: imx: add fractional PLL output clock
> > clk: imx: Add SCCG PLL type
> >
>
> I had to apply this set of fixes to silence sparse and smatch warnings about
> things that are not right. Please take a look over things and see if it's
> sane.
>
The change looks good to me and tested ok.
I did not see this patch series in your tree.
Do you want us to apply your changes and re-send for easy pick up?
Regards
Dong Aisheng
> diff --git a/drivers/clk/imx/clk-composite-8m.c
> b/drivers/clk/imx/clk-composite-8m.c
> index bcd31d889584..6d9d3714b4df 100644
> --- a/drivers/clk/imx/clk-composite-8m.c
> +++ b/drivers/clk/imx/clk-composite-8m.c
> @@ -127,8 +127,8 @@ struct clk *imx8m_clk_composite_flags(const char
> *name,
> int num_parents, void __iomem *reg,
> unsigned long flags)
> {
> - struct clk_hw *hw = NULL, *mux_hw = NULL;
> - struct clk_hw *div_hw = NULL, *gate_hw = NULL;
> + struct clk_hw *hw = ERR_PTR(-ENOMEM), *mux_hw;
> + struct clk_hw *div_hw, *gate_hw;
> struct clk_divider *div = NULL;
> struct clk_gate *gate = NULL;
> struct clk_mux *mux = NULL;
> diff --git a/drivers/clk/imx/clk-frac-pll.c b/drivers/clk/imx/clk-frac-pll.c
> index
> a3732be5ad7f..98726206f3c4 100644
> --- a/drivers/clk/imx/clk-frac-pll.c
> +++ b/drivers/clk/imx/clk-frac-pll.c
> @@ -14,6 +14,8 @@
> #include
> #include
>
> +#include "clk.h"
> +
> #define PLL_CFG0 0x0
> #define PLL_CFG1 0x4
>
> @@ -214,7 +216,7 @@ struct clk *imx_clk_frac_pll(const char *name, const
> char *parent_name,
> ret = clk_hw_register(NULL, hw);
> if (ret) {
> kfree(pll);
> - return ERR_CAST(hw);
> + return ERR_PTR(ret);
> }
>
> return hw->clk;
> diff --git a/drivers/clk/imx/clk-sccg-pll.c b/drivers/clk/imx/clk-sccg-pll.c
> index
> 4666b96bdb3f..ee7752bace89 100644
> --- a/drivers/clk/imx/clk-sccg-pll.c
> +++ b/drivers/clk/imx/clk-sccg-pll.c
> @@ -249,7 +249,7 @@ struct clk *imx_clk_sccg_pll(const char *name,
> ret = clk_hw_register(NULL, hw);
> if (ret) {
> kfree(pll);
> - return ERR_CAST(hw);
> + return ERR_PTR(ret);
> }
>
> return hw->clk;
Re: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
On Thu, Nov 29, 2018 at 04:36:43AM +, Dexuan Cui wrote:
>
> vmbus_process_offer() mustn't call channel->sc_creation_callback()
> directly for sub-channels, because sc_creation_callback() ->
> vmbus_open() may never get the host's response to the
> OPEN_CHANNEL message (the host may rescind a channel at any time,
> e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
> may not wake up the vmbus_open() as it's blocked due to a non-zero
> vmbus_connection.offer_in_progress, and finally we have a deadlock.
>
> The above is also true for primary channels, if the related device
> drivers use sync probing mode by default.
>
> And, usually the handling of primary channels and sub-channels can
> depend on each other, so we should offload them to different
> workqueues to avoid possible deadlock, e.g. in sync-probing mode,
> NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
> rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
> and waits for all the sub-channels to appear, but the latter
> can't get the rtnl_lock and this blocks the handling of sub-channels.
>
> The patch can fix the multiple-NIC deadlock described above for
> v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
> of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
> but don't enable async-probing for Hyper-V drivers (yet).
>
> The patch can also fix the hang issue in sub-channel's handling described
> above for all versions of kernels, including v4.19 and v4.20-rc4.
>
> So, actually the patch should be applied to all the existing kernels,
> not only the kernels that have 8195b1396ec8.
>
> Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
> Cc: sta...@vger.kernel.org
> Cc: Stephen Hemminger
> Cc: K. Y. Srinivasan
> Cc: Haiyang Zhang
> Signed-off-by: Dexuan Cui
> Signed-off-by: K. Y. Srinivasan
> ---
>
> There is no change in this repost. I just rebased this patch to today's
> char-misc's char-misc-next branch. Previously KY posted the patch with his
> Signed-off-by (which is kept in this repost), but there was a conflict issue.
>
> Note: the patch can't be cleanly applied to char-misc's char-misc-linus
> branch --
> to do that, we need to cherry-pick the supporting patch first:
> 4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API
> vmbus_get_outgoing_channel()")
That is not going to work for the obvious reason that this dependant
patch is not going to be merged into 4.20-final.
So, what do you expect us to do here? The only way this can be accepted
is to have it go into my -next branch, which means it will show up in
4.21-rc1, is that ok?
But then, if that happens, it will fail to apply to any stable tree for
4.20 and older, like you are asking it to be done for.
So what do you expect me to do here with this?
totally confused,
greg k-h
Re: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
On Thu, Nov 29, 2018 at 04:36:43AM +, Dexuan Cui wrote:
>
> vmbus_process_offer() mustn't call channel->sc_creation_callback()
> directly for sub-channels, because sc_creation_callback() ->
> vmbus_open() may never get the host's response to the
> OPEN_CHANNEL message (the host may rescind a channel at any time,
> e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
> may not wake up the vmbus_open() as it's blocked due to a non-zero
> vmbus_connection.offer_in_progress, and finally we have a deadlock.
>
> The above is also true for primary channels, if the related device
> drivers use sync probing mode by default.
>
> And, usually the handling of primary channels and sub-channels can
> depend on each other, so we should offload them to different
> workqueues to avoid possible deadlock, e.g. in sync-probing mode,
> NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
> rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
> and waits for all the sub-channels to appear, but the latter
> can't get the rtnl_lock and this blocks the handling of sub-channels.
>
> The patch can fix the multiple-NIC deadlock described above for
> v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
> of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
> but don't enable async-probing for Hyper-V drivers (yet).
>
> The patch can also fix the hang issue in sub-channel's handling described
> above for all versions of kernels, including v4.19 and v4.20-rc4.
>
> So, actually the patch should be applied to all the existing kernels,
> not only the kernels that have 8195b1396ec8.
>
> Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
> Cc: sta...@vger.kernel.org
> Cc: Stephen Hemminger
> Cc: K. Y. Srinivasan
> Cc: Haiyang Zhang
> Signed-off-by: Dexuan Cui
> Signed-off-by: K. Y. Srinivasan
> ---
>
> There is no change in this repost. I just rebased this patch to today's
> char-misc's char-misc-next branch. Previously KY posted the patch with his
> Signed-off-by (which is kept in this repost), but there was a conflict issue.
>
> Note: the patch can't be cleanly applied to char-misc's char-misc-linus
> branch --
> to do that, we need to cherry-pick the supporting patch first:
> 4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API
> vmbus_get_outgoing_channel()")
That is not going to work for the obvious reason that this dependant
patch is not going to be merged into 4.20-final.
So, what do you expect us to do here? The only way this can be accepted
is to have it go into my -next branch, which means it will show up in
4.21-rc1, is that ok?
But then, if that happens, it will fail to apply to any stable tree for
4.20 and older, like you are asking it to be done for.
So what do you expect me to do here with this?
totally confused,
greg k-h
Re: [PATCH] iio: adc: Replace license text w/ SPDX identifier
On Wed, 28 Nov 2018 at 18:53, Matheus Tavares wrote: > > From: Lucas Santos > > This patch removes all license boilerplate texts from the .c and .h > files at drivers/iio/adc/ and, instead, adds the proper SPDX license > identifiers. > > Signed-off-by: Lucas Santos > Signed-off-by: Matheus Tavares > --- > drivers/iio/adc/ad7266.c | 3 +-- > drivers/iio/adc/ad7291.c | 3 +-- > drivers/iio/adc/ad7298.c | 3 +-- > drivers/iio/adc/ad7766.c | 3 +-- > drivers/iio/adc/ad7791.c | 3 +-- > drivers/iio/adc/ad7793.c | 3 +-- > drivers/iio/adc/ad7887.c | 3 +-- > drivers/iio/adc/ad7923.c | 3 +-- > drivers/iio/adc/ad799x.c | 5 + > drivers/iio/adc/ad_sigma_delta.c | 3 +-- > drivers/iio/adc/aspeed_adc.c | 6 +- > drivers/iio/adc/at91-sama5d2_adc.c | 10 +- > drivers/iio/adc/at91_adc.c | 3 +-- > drivers/iio/adc/axp20x_adc.c | 5 + > drivers/iio/adc/axp288_adc.c | 13 + > drivers/iio/adc/bcm_iproc_adc.c | 13 + > drivers/iio/adc/berlin2-adc.c| 5 + > drivers/iio/adc/cc10001_adc.c| 6 +- > drivers/iio/adc/cpcap-adc.c | 10 +- > drivers/iio/adc/da9150-gpadc.c | 6 +- > drivers/iio/adc/dln2-adc.c | 5 + > drivers/iio/adc/ep93xx_adc.c | 5 + > drivers/iio/adc/exynos_adc.c | 11 +-- > drivers/iio/adc/fsl-imx25-gcq.c | 5 + > drivers/iio/adc/hi8435.c | 6 +- > drivers/iio/adc/hx711.c | 6 +- > drivers/iio/adc/imx7d_adc.c | 6 +- > drivers/iio/adc/ina2xx-adc.c | 7 +-- > drivers/iio/adc/lp8788_adc.c | 5 + > drivers/iio/adc/lpc18xx_adc.c| 5 + > drivers/iio/adc/lpc32xx_adc.c| 15 +-- > drivers/iio/adc/ltc2471.c| 3 +-- > drivers/iio/adc/ltc2485.c| 5 + > drivers/iio/adc/ltc2497.c| 3 +-- > drivers/iio/adc/max1027.c| 5 + > drivers/iio/adc/max1118.c| 5 + > drivers/iio/adc/max1363.c| 5 + > drivers/iio/adc/mcp320x.c| 5 + > drivers/iio/adc/mcp3422.c| 6 +- > drivers/iio/adc/men_z188_adc.c | 5 + > drivers/iio/adc/meson_saradc.c | 5 + > drivers/iio/adc/mt6577_auxadc.c | 10 +- > drivers/iio/adc/mxs-lradc-adc.c | 11 +-- > drivers/iio/adc/nau7802.c| 3 +-- > drivers/iio/adc/palmas_gpadc.c | 5 + > drivers/iio/adc/qcom-pm8xxx-xoadc.c | 1 + > drivers/iio/adc/qcom-spmi-iadc.c | 10 +- > drivers/iio/adc/qcom-spmi-vadc.c | 10 +- > drivers/iio/adc/rockchip_saradc.c| 11 +-- > drivers/iio/adc/spear_adc.c | 3 +-- > drivers/iio/adc/stx104.c | 10 +- > drivers/iio/adc/sun4i-gpadc-iio.c| 5 + > drivers/iio/adc/ti-adc081c.c | 5 + > drivers/iio/adc/ti-adc0832.c | 5 + > drivers/iio/adc/ti-adc084s021.c | 5 + > drivers/iio/adc/ti-adc108s102.c | 10 +- > drivers/iio/adc/ti-adc12138.c| 5 + > drivers/iio/adc/ti-ads1015.c | 5 + > drivers/iio/adc/ti-ads8688.c | 5 + > drivers/iio/adc/ti-tlc4541.c | 5 + > drivers/iio/adc/ti_am335x_adc.c | 10 +- > drivers/iio/adc/twl4030-madc.c | 16 +--- > drivers/iio/adc/twl6030-gpadc.c | 16 +--- > drivers/iio/adc/vf610_adc.c | 15 +-- > drivers/iio/adc/viperboard_adc.c | 7 +-- > drivers/iio/adc/xilinx-xadc-core.c | 3 +-- > drivers/iio/adc/xilinx-xadc-events.c | 3 +-- > drivers/iio/adc/xilinx-xadc.h| 3 +-- > 68 files changed, 68 insertions(+), 361 deletions(-) > (...) > diff --git a/drivers/iio/adc/ep93xx_adc.c b/drivers/iio/adc/ep93xx_adc.c > index 5036c392cb20..8f614c84b643 100644 > --- a/drivers/iio/adc/ep93xx_adc.c > +++ b/drivers/iio/adc/ep93xx_adc.c > @@ -1,12 +1,9 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Driver for ADC module on the Cirrus Logic EP93xx series of SoCs > * > * Copyright (C) 2015 Alexander Sverdlin > * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > - * > * The driver uses polling to get the conversion status. According to EP93xx > * datasheets, reading ADCResult register starts the conversion, but user is > also > * responsible for ensuring that delay between adjacent conversion triggers > is > diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c > index f10443f92e4c..9f9c186e2135 100644 > --- a/drivers/iio/adc/exynos_adc.c > +++ b/drivers/iio/adc/exynos_adc.c > @@ -1,3 +1,4 @@ > +//
Re: [PATCH] iio: adc: Replace license text w/ SPDX identifier
On Wed, 28 Nov 2018 at 18:53, Matheus Tavares wrote: > > From: Lucas Santos > > This patch removes all license boilerplate texts from the .c and .h > files at drivers/iio/adc/ and, instead, adds the proper SPDX license > identifiers. > > Signed-off-by: Lucas Santos > Signed-off-by: Matheus Tavares > --- > drivers/iio/adc/ad7266.c | 3 +-- > drivers/iio/adc/ad7291.c | 3 +-- > drivers/iio/adc/ad7298.c | 3 +-- > drivers/iio/adc/ad7766.c | 3 +-- > drivers/iio/adc/ad7791.c | 3 +-- > drivers/iio/adc/ad7793.c | 3 +-- > drivers/iio/adc/ad7887.c | 3 +-- > drivers/iio/adc/ad7923.c | 3 +-- > drivers/iio/adc/ad799x.c | 5 + > drivers/iio/adc/ad_sigma_delta.c | 3 +-- > drivers/iio/adc/aspeed_adc.c | 6 +- > drivers/iio/adc/at91-sama5d2_adc.c | 10 +- > drivers/iio/adc/at91_adc.c | 3 +-- > drivers/iio/adc/axp20x_adc.c | 5 + > drivers/iio/adc/axp288_adc.c | 13 + > drivers/iio/adc/bcm_iproc_adc.c | 13 + > drivers/iio/adc/berlin2-adc.c| 5 + > drivers/iio/adc/cc10001_adc.c| 6 +- > drivers/iio/adc/cpcap-adc.c | 10 +- > drivers/iio/adc/da9150-gpadc.c | 6 +- > drivers/iio/adc/dln2-adc.c | 5 + > drivers/iio/adc/ep93xx_adc.c | 5 + > drivers/iio/adc/exynos_adc.c | 11 +-- > drivers/iio/adc/fsl-imx25-gcq.c | 5 + > drivers/iio/adc/hi8435.c | 6 +- > drivers/iio/adc/hx711.c | 6 +- > drivers/iio/adc/imx7d_adc.c | 6 +- > drivers/iio/adc/ina2xx-adc.c | 7 +-- > drivers/iio/adc/lp8788_adc.c | 5 + > drivers/iio/adc/lpc18xx_adc.c| 5 + > drivers/iio/adc/lpc32xx_adc.c| 15 +-- > drivers/iio/adc/ltc2471.c| 3 +-- > drivers/iio/adc/ltc2485.c| 5 + > drivers/iio/adc/ltc2497.c| 3 +-- > drivers/iio/adc/max1027.c| 5 + > drivers/iio/adc/max1118.c| 5 + > drivers/iio/adc/max1363.c| 5 + > drivers/iio/adc/mcp320x.c| 5 + > drivers/iio/adc/mcp3422.c| 6 +- > drivers/iio/adc/men_z188_adc.c | 5 + > drivers/iio/adc/meson_saradc.c | 5 + > drivers/iio/adc/mt6577_auxadc.c | 10 +- > drivers/iio/adc/mxs-lradc-adc.c | 11 +-- > drivers/iio/adc/nau7802.c| 3 +-- > drivers/iio/adc/palmas_gpadc.c | 5 + > drivers/iio/adc/qcom-pm8xxx-xoadc.c | 1 + > drivers/iio/adc/qcom-spmi-iadc.c | 10 +- > drivers/iio/adc/qcom-spmi-vadc.c | 10 +- > drivers/iio/adc/rockchip_saradc.c| 11 +-- > drivers/iio/adc/spear_adc.c | 3 +-- > drivers/iio/adc/stx104.c | 10 +- > drivers/iio/adc/sun4i-gpadc-iio.c| 5 + > drivers/iio/adc/ti-adc081c.c | 5 + > drivers/iio/adc/ti-adc0832.c | 5 + > drivers/iio/adc/ti-adc084s021.c | 5 + > drivers/iio/adc/ti-adc108s102.c | 10 +- > drivers/iio/adc/ti-adc12138.c| 5 + > drivers/iio/adc/ti-ads1015.c | 5 + > drivers/iio/adc/ti-ads8688.c | 5 + > drivers/iio/adc/ti-tlc4541.c | 5 + > drivers/iio/adc/ti_am335x_adc.c | 10 +- > drivers/iio/adc/twl4030-madc.c | 16 +--- > drivers/iio/adc/twl6030-gpadc.c | 16 +--- > drivers/iio/adc/vf610_adc.c | 15 +-- > drivers/iio/adc/viperboard_adc.c | 7 +-- > drivers/iio/adc/xilinx-xadc-core.c | 3 +-- > drivers/iio/adc/xilinx-xadc-events.c | 3 +-- > drivers/iio/adc/xilinx-xadc.h| 3 +-- > 68 files changed, 68 insertions(+), 361 deletions(-) > (...) > diff --git a/drivers/iio/adc/ep93xx_adc.c b/drivers/iio/adc/ep93xx_adc.c > index 5036c392cb20..8f614c84b643 100644 > --- a/drivers/iio/adc/ep93xx_adc.c > +++ b/drivers/iio/adc/ep93xx_adc.c > @@ -1,12 +1,9 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Driver for ADC module on the Cirrus Logic EP93xx series of SoCs > * > * Copyright (C) 2015 Alexander Sverdlin > * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > - * > * The driver uses polling to get the conversion status. According to EP93xx > * datasheets, reading ADCResult register starts the conversion, but user is > also > * responsible for ensuring that delay between adjacent conversion triggers > is > diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c > index f10443f92e4c..9f9c186e2135 100644 > --- a/drivers/iio/adc/exynos_adc.c > +++ b/drivers/iio/adc/exynos_adc.c > @@ -1,3 +1,4 @@ > +//
Re: [PATCH] RISC-V: Make BSS section as the last section in vmlinux.lds.S
On Mon, Nov 26, 2018 at 2:12 PM Anup Patel wrote: > > The objcopy only emits loadable sections when creating flat kernel > Image. To have minimal possible size of flat kernel Image, we should > have all non-loadable sections after loadable sections. > > Currently, execption table section (loadable section) is after BSS > section (non-loadable section) in the RISC-V vmlinux.lds.S. This > is not optimal for having minimal flat kernel Image size hence this > patch makes BSS section as the last section in RISC-V vmlinux.lds.S. > > In addition, we make BSS section aligned to 16byte instead of PAGE > aligned which further reduces flat kernel Image size by few KBs. > > The flat kernel Image size of Linux-4.20-rc4 using GCC 8.2.0 is > 8819980 bytes with current RISC-V vmlinux.lds.S and it reduces to > 7991740 bytes with this patch applied using GCC 8.2.0. In summary, > this patch reduces Linux-4.20-rc4 flat kernel Image size by 809 KB. > > Signed-off-by: Anup Patel > --- > arch/riscv/kernel/vmlinux.lds.S | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng Tested-by: Bin Meng
Re: [PATCH] RISC-V: Make BSS section as the last section in vmlinux.lds.S
On Mon, Nov 26, 2018 at 2:12 PM Anup Patel wrote: > > The objcopy only emits loadable sections when creating flat kernel > Image. To have minimal possible size of flat kernel Image, we should > have all non-loadable sections after loadable sections. > > Currently, execption table section (loadable section) is after BSS > section (non-loadable section) in the RISC-V vmlinux.lds.S. This > is not optimal for having minimal flat kernel Image size hence this > patch makes BSS section as the last section in RISC-V vmlinux.lds.S. > > In addition, we make BSS section aligned to 16byte instead of PAGE > aligned which further reduces flat kernel Image size by few KBs. > > The flat kernel Image size of Linux-4.20-rc4 using GCC 8.2.0 is > 8819980 bytes with current RISC-V vmlinux.lds.S and it reduces to > 7991740 bytes with this patch applied using GCC 8.2.0. In summary, > this patch reduces Linux-4.20-rc4 flat kernel Image size by 809 KB. > > Signed-off-by: Anup Patel > --- > arch/riscv/kernel/vmlinux.lds.S | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng Tested-by: Bin Meng
Re: [PATCH v2 1/3] mmc: sdhci: add support for using external DMA devices
On 29/11/18 8:22 AM, Chunyan Zhang wrote:
> On Tue, 20 Nov 2018 at 21:41, Adrian Hunter wrote:
>>
>> On 12/11/18 9:26 AM, Chunyan Zhang wrote:
>>> Some standard SD host controllers can support both external dma
>>> controllers as well as ADMA/SDMA in which the SD host controller
>>> acts as DMA master. TI's omap controller is the case as an example.
>>>
>>> Currently the generic SDHCI code supports ADMA/SDMA integrated in
>>> the host controller but does not have any support for external DMA
>>> controllers implemented using dmaengine, meaning that custom code is
>>> needed for any systems that use an external DMA controller with SDHCI.
>>
>> I still think you probably need to reset the DMA if there are transfer
>> errors - perhaps you could comment on that. Also there are some comments
>> below.
>
> With regard to "transfer error", do you mean if
> sdhci_external_dma_setup() failed?
No, I mean any error interrupt that can leave the DMA uncompleted. For
SDHCI, resetting the data circuit cleans that up, but presumably something
is needed for external DMA?
>
> Thanks,
> Chunyan
>
>
>>
>>>
>>> Signed-off-by: Chunyan Zhang
>>> ---
>>> drivers/mmc/host/Kconfig | 13
>>> drivers/mmc/host/sdhci.c | 181
>>> ++-
>>> drivers/mmc/host/sdhci.h | 8 +++
>>> 3 files changed, 201 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>>> index 1b58739..7bf3eff 100644
>>> --- a/drivers/mmc/host/Kconfig
>>> +++ b/drivers/mmc/host/Kconfig
>>> @@ -977,3 +977,16 @@ config MMC_SDHCI_OMAP
>>> If you have a controller with this interface, say Y or M here.
>>>
>>> If unsure, say N.
>>> +
>>> +config MMC_SDHCI_EXTERNAL_DMA
>>> +bool "Support external DMA in standard SD host controller"
>>
>> It would be simpler if the drivers that needed it just selected it e.g.
>>
>> config MMC_SDHCI_OMAP
>> tristate "TI SDHCI Controller Support"
>> depends on MMC_SDHCI_PLTFM && OF
>> select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
>>
>>> + depends on MMC_SDHCI
>>> + depends on DMA_ENGINE
>>> + help
>>> + This is an option for using external DMA device via dmaengine
>>> + framework.
>>> +
>>> + If you have a controller which support using external DMA device
>>> + for data transfer, can say Y.
>>> +
>>> + If unsure, say N.
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index 99bdae5..853cc98 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -14,6 +14,7 @@
>>> */
>>>
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -1309,6 +1310,158 @@ static void sdhci_del_timer(struct sdhci_host
>>> *host, struct mmc_request *mrq)
>>> del_timer(>timer);
>>> }
>>>
>>> +#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
>>> +static int sdhci_external_dma_init(struct sdhci_host *host)
>>> +{
>>> + int ret = 0;
>>> + struct mmc_host *mmc = host->mmc;
>>> +
>>> + host->tx_chan = dma_request_chan(mmc->parent, "tx");
>>> + if (IS_ERR(host->tx_chan)) {
>>> + ret = PTR_ERR(host->tx_chan);
>>> + if (ret != -EPROBE_DEFER)
>>> + pr_warn("Failed to request TX DMA channel.\n");
>>> + host->tx_chan = NULL;
>>> + return ret;
>>> + }
>>> +
>>> + host->rx_chan = dma_request_chan(mmc->parent, "rx");
>>> + if (IS_ERR(host->rx_chan)) {
>>> + if (host->tx_chan) {
>>> + dma_release_channel(host->tx_chan);
>>> + host->tx_chan = NULL;
>>> + }
>>> +
>>> + ret = PTR_ERR(host->rx_chan);
>>> + if (ret != -EPROBE_DEFER)
>>> + pr_warn("Failed to request RX DMA channel.\n");
>>> + host->rx_chan = NULL;
>>> + }
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static inline struct dma_chan *
>>> +sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data *data)
>>> +{
>>> + return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
>>> +}
>>> +
>>> +static int sdhci_external_dma_setup(struct sdhci_host *host,
>>> + struct mmc_command *cmd)
>>> +{
>>> + int ret = 0, i;
>>> + struct dma_async_tx_descriptor *desc;
>>> + struct mmc_data *data = cmd->data;
>>
>> cmd->data might be NULL? Have you tested this?
>>
>>> + struct dma_chan *chan;
>>> + struct dma_slave_config cfg;
>>> + dma_cookie_t cookie;
>>> +
>>> + if (!host->mapbase)
>>> + return -EINVAL;
>>> +
>>> + cfg.src_addr = host->mapbase + SDHCI_BUFFER;
>>> + cfg.dst_addr = host->mapbase + SDHCI_BUFFER;
>>> + cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>>> + cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>>> + cfg.src_maxburst = data->blksz / 4;
>>> + cfg.dst_maxburst = data->blksz / 4;
>>> +
>>> + /*
Re: [PATCH v2 1/3] mmc: sdhci: add support for using external DMA devices
On 29/11/18 8:22 AM, Chunyan Zhang wrote:
> On Tue, 20 Nov 2018 at 21:41, Adrian Hunter wrote:
>>
>> On 12/11/18 9:26 AM, Chunyan Zhang wrote:
>>> Some standard SD host controllers can support both external dma
>>> controllers as well as ADMA/SDMA in which the SD host controller
>>> acts as DMA master. TI's omap controller is the case as an example.
>>>
>>> Currently the generic SDHCI code supports ADMA/SDMA integrated in
>>> the host controller but does not have any support for external DMA
>>> controllers implemented using dmaengine, meaning that custom code is
>>> needed for any systems that use an external DMA controller with SDHCI.
>>
>> I still think you probably need to reset the DMA if there are transfer
>> errors - perhaps you could comment on that. Also there are some comments
>> below.
>
> With regard to "transfer error", do you mean if
> sdhci_external_dma_setup() failed?
No, I mean any error interrupt that can leave the DMA uncompleted. For
SDHCI, resetting the data circuit cleans that up, but presumably something
is needed for external DMA?
>
> Thanks,
> Chunyan
>
>
>>
>>>
>>> Signed-off-by: Chunyan Zhang
>>> ---
>>> drivers/mmc/host/Kconfig | 13
>>> drivers/mmc/host/sdhci.c | 181
>>> ++-
>>> drivers/mmc/host/sdhci.h | 8 +++
>>> 3 files changed, 201 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
>>> index 1b58739..7bf3eff 100644
>>> --- a/drivers/mmc/host/Kconfig
>>> +++ b/drivers/mmc/host/Kconfig
>>> @@ -977,3 +977,16 @@ config MMC_SDHCI_OMAP
>>> If you have a controller with this interface, say Y or M here.
>>>
>>> If unsure, say N.
>>> +
>>> +config MMC_SDHCI_EXTERNAL_DMA
>>> +bool "Support external DMA in standard SD host controller"
>>
>> It would be simpler if the drivers that needed it just selected it e.g.
>>
>> config MMC_SDHCI_OMAP
>> tristate "TI SDHCI Controller Support"
>> depends on MMC_SDHCI_PLTFM && OF
>> select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
>>
>>> + depends on MMC_SDHCI
>>> + depends on DMA_ENGINE
>>> + help
>>> + This is an option for using external DMA device via dmaengine
>>> + framework.
>>> +
>>> + If you have a controller which support using external DMA device
>>> + for data transfer, can say Y.
>>> +
>>> + If unsure, say N.
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index 99bdae5..853cc98 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -14,6 +14,7 @@
>>> */
>>>
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -1309,6 +1310,158 @@ static void sdhci_del_timer(struct sdhci_host
>>> *host, struct mmc_request *mrq)
>>> del_timer(>timer);
>>> }
>>>
>>> +#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
>>> +static int sdhci_external_dma_init(struct sdhci_host *host)
>>> +{
>>> + int ret = 0;
>>> + struct mmc_host *mmc = host->mmc;
>>> +
>>> + host->tx_chan = dma_request_chan(mmc->parent, "tx");
>>> + if (IS_ERR(host->tx_chan)) {
>>> + ret = PTR_ERR(host->tx_chan);
>>> + if (ret != -EPROBE_DEFER)
>>> + pr_warn("Failed to request TX DMA channel.\n");
>>> + host->tx_chan = NULL;
>>> + return ret;
>>> + }
>>> +
>>> + host->rx_chan = dma_request_chan(mmc->parent, "rx");
>>> + if (IS_ERR(host->rx_chan)) {
>>> + if (host->tx_chan) {
>>> + dma_release_channel(host->tx_chan);
>>> + host->tx_chan = NULL;
>>> + }
>>> +
>>> + ret = PTR_ERR(host->rx_chan);
>>> + if (ret != -EPROBE_DEFER)
>>> + pr_warn("Failed to request RX DMA channel.\n");
>>> + host->rx_chan = NULL;
>>> + }
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static inline struct dma_chan *
>>> +sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data *data)
>>> +{
>>> + return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
>>> +}
>>> +
>>> +static int sdhci_external_dma_setup(struct sdhci_host *host,
>>> + struct mmc_command *cmd)
>>> +{
>>> + int ret = 0, i;
>>> + struct dma_async_tx_descriptor *desc;
>>> + struct mmc_data *data = cmd->data;
>>
>> cmd->data might be NULL? Have you tested this?
>>
>>> + struct dma_chan *chan;
>>> + struct dma_slave_config cfg;
>>> + dma_cookie_t cookie;
>>> +
>>> + if (!host->mapbase)
>>> + return -EINVAL;
>>> +
>>> + cfg.src_addr = host->mapbase + SDHCI_BUFFER;
>>> + cfg.dst_addr = host->mapbase + SDHCI_BUFFER;
>>> + cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>>> + cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>>> + cfg.src_maxburst = data->blksz / 4;
>>> + cfg.dst_maxburst = data->blksz / 4;
>>> +
>>> + /*
[PATCH] ASoC: adau1761: Ensure DSP_RUN and DSP_ENABLE are disabled
From: Niklas Carlsson
DSP_RUN and DSP_ENABLE needs to be disabled during FW load. This is not
a problem after power-cycling but for soft reboots.
Signed-off-by: Niklas Carlsson
---
sound/soc/codecs/adau1761.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/adau1761.c b/sound/soc/codecs/adau1761.c
index bef3e9e74c26..3075c13bcbbc 100644
--- a/sound/soc/codecs/adau1761.c
+++ b/sound/soc/codecs/adau1761.c
@@ -460,8 +460,35 @@ static int adau1761_set_bias_level(struct
snd_soc_component *component,
regmap_update_bits(adau->regmap, ADAU17X1_CLOCK_CONTROL,
ADAU17X1_CLOCK_CONTROL_SYSCLK_EN,
ADAU17X1_CLOCK_CONTROL_SYSCLK_EN);
- if (snd_soc_component_get_bias_level(component) ==
SND_SOC_BIAS_OFF)
+ if (snd_soc_component_get_bias_level(component) ==
+ SND_SOC_BIAS_OFF) {
+ /*
+* When going OFF -> STANDBY, the device can be in two
+* states:
+* 1) Power-cycled and reset
+* 2) Soft reboot
+* In the case of soft reboot, we need to sync the HW
+* registers even if our regmap reports default values.
+* Marking the cache as dirty ensures that both cases
+* are handled.
+*/
+ regcache_mark_dirty(adau->regmap);
regcache_sync(adau->regmap);
+ /*
+* In order for FW to load correctly, the device needs
+* DSP_RUN and DSP_ENABLE to be 0. This might not be the
+* case for soft reboots. Ensure that DSP_RUN and
+* DSP_ENABLE is 0 by bypassing the cache and write
+* directly to HW when going OFF -> STANDBY.
+*/
+ if (adau17x1_has_dsp(adau)) {
+ regcache_cache_bypass(adau->regmap, true);
+ regmap_write(adau->regmap, ADAU17X1_DSP_RUN, 0);
+ regmap_write(adau->regmap,
+ ADAU17X1_DSP_ENABLE, 0);
+ regcache_cache_bypass(adau->regmap, false);
+ }
+ }
break;
case SND_SOC_BIAS_OFF:
regmap_update_bits(adau->regmap, ADAU17X1_CLOCK_CONTROL,
--
2.11.0
[PATCH] ASoC: adau1761: Ensure DSP_RUN and DSP_ENABLE are disabled
From: Niklas Carlsson
DSP_RUN and DSP_ENABLE needs to be disabled during FW load. This is not
a problem after power-cycling but for soft reboots.
Signed-off-by: Niklas Carlsson
---
sound/soc/codecs/adau1761.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/adau1761.c b/sound/soc/codecs/adau1761.c
index bef3e9e74c26..3075c13bcbbc 100644
--- a/sound/soc/codecs/adau1761.c
+++ b/sound/soc/codecs/adau1761.c
@@ -460,8 +460,35 @@ static int adau1761_set_bias_level(struct
snd_soc_component *component,
regmap_update_bits(adau->regmap, ADAU17X1_CLOCK_CONTROL,
ADAU17X1_CLOCK_CONTROL_SYSCLK_EN,
ADAU17X1_CLOCK_CONTROL_SYSCLK_EN);
- if (snd_soc_component_get_bias_level(component) ==
SND_SOC_BIAS_OFF)
+ if (snd_soc_component_get_bias_level(component) ==
+ SND_SOC_BIAS_OFF) {
+ /*
+* When going OFF -> STANDBY, the device can be in two
+* states:
+* 1) Power-cycled and reset
+* 2) Soft reboot
+* In the case of soft reboot, we need to sync the HW
+* registers even if our regmap reports default values.
+* Marking the cache as dirty ensures that both cases
+* are handled.
+*/
+ regcache_mark_dirty(adau->regmap);
regcache_sync(adau->regmap);
+ /*
+* In order for FW to load correctly, the device needs
+* DSP_RUN and DSP_ENABLE to be 0. This might not be the
+* case for soft reboots. Ensure that DSP_RUN and
+* DSP_ENABLE is 0 by bypassing the cache and write
+* directly to HW when going OFF -> STANDBY.
+*/
+ if (adau17x1_has_dsp(adau)) {
+ regcache_cache_bypass(adau->regmap, true);
+ regmap_write(adau->regmap, ADAU17X1_DSP_RUN, 0);
+ regmap_write(adau->regmap,
+ ADAU17X1_DSP_ENABLE, 0);
+ regcache_cache_bypass(adau->regmap, false);
+ }
+ }
break;
case SND_SOC_BIAS_OFF:
regmap_update_bits(adau->regmap, ADAU17X1_CLOCK_CONTROL,
--
2.11.0
Re: [PATCH] ALSA: pcm: Fix starvation on down_write_nonblock()
On Thu, 29 Nov 2018 00:48:20 +0100,
Chanho Min wrote:
>
> > > > On Mon, 26 Nov 2018 06:36:37 +0100,
> > > > Chanho Min wrote:
> > > > >
> > > > > Commit 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-atomic
> > > > > PCM
> > > > > stream") fixes deadlock for non-atomic PCM stream. But, This patch
> > > > causes antother stuck.
> > > > > If writer is RT thread and reader is a normal thread, the reader
> > > > > thread will be difficult to get scheduled. It may not give chance
> > > > > to release readlocks and writer gets stuck for a long time if they
> > > > > are
> > > > pinned to single cpu.
> > > > >
> > > > > The deadlock described in the previous commit is because the linux
> > > > > rwsem queues like a FIFO. So, we might need non-FIFO writelock,
> > > > > not non-
> > > > block one.
> > > > >
> > > > > My suggestion is that the writer gives reader a chance to be
> > > > > scheduled by using the minimum msleep() instaed of spinning
> > > > > without blocking by writer. Also, The *_nonblock may be changed to
> > > > > *_nonfifo appropriately
> > > > to this concept.
> > > > > In terms of performance, when trylock is failed, this minimum
> > > > > periodic msleep will have the same performance as the tick-based
> > > > schedule()/wake_up_q().
> > > > >
> > > > > Suggested-by: Wonmin Jung
> > > > > Signed-off-by: Chanho Min
> > > >
> > > > Hrm, converting unconditionally with msleep() looks too drastic.
> > >
> > > Yes, it looks drastic. But, IMHO, I can't say busy-spin is not non-
> > drastic.
> > > To fix the root cause, We may need another rwsem that does not work as
> > > a FIFO.
> >
> > Right, but applying msleep(1) unconditionally is really bad.
> >
> > > > I guess you've hit this while not explicitly using the linked PCM
> > > > streams, i.e. in the call of snd_pcm_unlink() at close, right?
> > > >
> > > > Then this can be worked around by checking the link before calling it.
> > > > Could you check the patch below?
> > >
> > > More testing is needed, but it seems to be fixed by your patch.
> > > We may not use the linked PCM.
> >
> > Then I'm sure that my patch papers over.
> Thanks, Plz let me know when the patch is merged.
I'm going to merge the patch below now.
It slips from the pull request to Linus in today, but will be the next
one for 4.20-rc6.
> > > But, If the linked PCM is enabled, Can snd_pcm_unlink() be called?
> > > This also seems to be a workaround.
> >
> > Yes, for the linked streams, something else is needed *in addition*.
> >
> > The original fix with busy loop also assumed that this code path (via
> > snd_pcm_link() and snd_pcm_unlink()) is the rare occasion, and it didn't
> > consider that it were called for regular use cases. So the fix to make
> > things just works for regular use cases without any artifact must be
> > implemented in the first place. The fix for the linked streams comes at
> > next. It might be like your msleep() change as a workaround, but in
> > anyway it's far less urgency.
>
> msleep is worst, but If it is harmless, can I apply my patch to the private
> tree
> temporarily until your next fix comes?
> We may use the linked streams in the near future. It makes our product
> unstable.
> It's urgency for us. How is your opinion?
I'll add your fix on top of mine for now. The msleep() is applied
only for linked streams, so it's not that bad any longer.
thanks,
Takashi
-- 8< --
From: Takashi Iwai
Subject: [PATCH] ALSA: pcm: Call snd_pcm_unlink() conditionally at closing
Currently the PCM core calls snd_pcm_unlink() always unconditionally
at closing a stream. However, since snd_pcm_unlink() invokes the
global rwsem down, the lock can be easily contended. More badly, when
a thread runs in a high priority RT-FIFO, it may stall at spinning.
Basically the call of snd_pcm_unlink() is required only for the linked
streams that are already rare occasion. For normal use cases, this
code path is fairly superfluous.
As an optimization (and also as a workaround for the RT problem
above in normal situations without linked streams), this patch adds a
check before calling snd_pcm_unlink() and calls it only when needed.
Reported-by: Chanho Min
Cc:
Signed-off-by: Takashi Iwai
---
sound/core/pcm_native.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 66c90f486af9..6afcc393113a 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2369,7 +2369,8 @@ int snd_pcm_hw_constraints_complete(struct
snd_pcm_substream *substream)
static void pcm_release_private(struct snd_pcm_substream *substream)
{
- snd_pcm_unlink(substream);
+ if (snd_pcm_stream_linked(substream))
+ snd_pcm_unlink(substream);
}
void snd_pcm_release_substream(struct snd_pcm_substream *substream)
--
2.19.1
Re: [PATCH] ALSA: pcm: Fix starvation on down_write_nonblock()
On Thu, 29 Nov 2018 00:48:20 +0100,
Chanho Min wrote:
>
> > > > On Mon, 26 Nov 2018 06:36:37 +0100,
> > > > Chanho Min wrote:
> > > > >
> > > > > Commit 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-atomic
> > > > > PCM
> > > > > stream") fixes deadlock for non-atomic PCM stream. But, This patch
> > > > causes antother stuck.
> > > > > If writer is RT thread and reader is a normal thread, the reader
> > > > > thread will be difficult to get scheduled. It may not give chance
> > > > > to release readlocks and writer gets stuck for a long time if they
> > > > > are
> > > > pinned to single cpu.
> > > > >
> > > > > The deadlock described in the previous commit is because the linux
> > > > > rwsem queues like a FIFO. So, we might need non-FIFO writelock,
> > > > > not non-
> > > > block one.
> > > > >
> > > > > My suggestion is that the writer gives reader a chance to be
> > > > > scheduled by using the minimum msleep() instaed of spinning
> > > > > without blocking by writer. Also, The *_nonblock may be changed to
> > > > > *_nonfifo appropriately
> > > > to this concept.
> > > > > In terms of performance, when trylock is failed, this minimum
> > > > > periodic msleep will have the same performance as the tick-based
> > > > schedule()/wake_up_q().
> > > > >
> > > > > Suggested-by: Wonmin Jung
> > > > > Signed-off-by: Chanho Min
> > > >
> > > > Hrm, converting unconditionally with msleep() looks too drastic.
> > >
> > > Yes, it looks drastic. But, IMHO, I can't say busy-spin is not non-
> > drastic.
> > > To fix the root cause, We may need another rwsem that does not work as
> > > a FIFO.
> >
> > Right, but applying msleep(1) unconditionally is really bad.
> >
> > > > I guess you've hit this while not explicitly using the linked PCM
> > > > streams, i.e. in the call of snd_pcm_unlink() at close, right?
> > > >
> > > > Then this can be worked around by checking the link before calling it.
> > > > Could you check the patch below?
> > >
> > > More testing is needed, but it seems to be fixed by your patch.
> > > We may not use the linked PCM.
> >
> > Then I'm sure that my patch papers over.
> Thanks, Plz let me know when the patch is merged.
I'm going to merge the patch below now.
It slips from the pull request to Linus in today, but will be the next
one for 4.20-rc6.
> > > But, If the linked PCM is enabled, Can snd_pcm_unlink() be called?
> > > This also seems to be a workaround.
> >
> > Yes, for the linked streams, something else is needed *in addition*.
> >
> > The original fix with busy loop also assumed that this code path (via
> > snd_pcm_link() and snd_pcm_unlink()) is the rare occasion, and it didn't
> > consider that it were called for regular use cases. So the fix to make
> > things just works for regular use cases without any artifact must be
> > implemented in the first place. The fix for the linked streams comes at
> > next. It might be like your msleep() change as a workaround, but in
> > anyway it's far less urgency.
>
> msleep is worst, but If it is harmless, can I apply my patch to the private
> tree
> temporarily until your next fix comes?
> We may use the linked streams in the near future. It makes our product
> unstable.
> It's urgency for us. How is your opinion?
I'll add your fix on top of mine for now. The msleep() is applied
only for linked streams, so it's not that bad any longer.
thanks,
Takashi
-- 8< --
From: Takashi Iwai
Subject: [PATCH] ALSA: pcm: Call snd_pcm_unlink() conditionally at closing
Currently the PCM core calls snd_pcm_unlink() always unconditionally
at closing a stream. However, since snd_pcm_unlink() invokes the
global rwsem down, the lock can be easily contended. More badly, when
a thread runs in a high priority RT-FIFO, it may stall at spinning.
Basically the call of snd_pcm_unlink() is required only for the linked
streams that are already rare occasion. For normal use cases, this
code path is fairly superfluous.
As an optimization (and also as a workaround for the RT problem
above in normal situations without linked streams), this patch adds a
check before calling snd_pcm_unlink() and calls it only when needed.
Reported-by: Chanho Min
Cc:
Signed-off-by: Takashi Iwai
---
sound/core/pcm_native.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 66c90f486af9..6afcc393113a 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2369,7 +2369,8 @@ int snd_pcm_hw_constraints_complete(struct
snd_pcm_substream *substream)
static void pcm_release_private(struct snd_pcm_substream *substream)
{
- snd_pcm_unlink(substream);
+ if (snd_pcm_stream_linked(substream))
+ snd_pcm_unlink(substream);
}
void snd_pcm_release_substream(struct snd_pcm_substream *substream)
--
2.19.1
Re: [RFC PATCH v3 3/4] irqchip: gic-v3: Add quirk for msm8996 secured registers
Bjorn, On Wed, 28 Nov 2018 23:33:27 +, Bjorn Andersson wrote: > > On Mon 12 Nov 02:33 PST 2018, Srinivas Kandagatla wrote: > > > Access to GICR_WAKER is restricted on msm8996 SoC in Hypervisor. > > Its been more than 2+ years of wait for this to be fixed, which has > > no hopes to be fixed. This change was introduced for the "lead device" > > on msm8996 platform. It looks like all publicly available msm8996 and > > other qcom SoCs have this implementation. > > > > So add a quirk to not access this register on msm8996. > > > > With this quirk MSM8996 can at least boot out of mainline, > > which can help community to work with boards based on MSM8996 and other > > SoCs with have this restrictions. This Quirk is based on device tree > > compatible string. > > > > Without this patch Qualcomm DB820c board reboots when GICR_WAKER > > is accessed. > > > > Hi Srinivas, > > Given that the change request introducing this restriction looks quite > generic and that we've heard reports of other shipping platforms having > the same restriction, could we make this slightly more generic? s/restriction/gross bug/ > I.e. dropping the MSM8996 from the flag name and perhaps use a bool > property in devicetree to toggle the flag, instead of adding compatibles > as we figure out which Qualcomm platforms has this restriction. If we are to introduce a property, then it ought to be an erratum number (similar to what we do for the arch timer). Srinivas wasn't able to obtain one despite the defect having been known for years, so I guess this is out. Thanks, M. -- Jazz is not dead, it just smell funny.
Re: [RFC PATCH v3 3/4] irqchip: gic-v3: Add quirk for msm8996 secured registers
Bjorn, On Wed, 28 Nov 2018 23:33:27 +, Bjorn Andersson wrote: > > On Mon 12 Nov 02:33 PST 2018, Srinivas Kandagatla wrote: > > > Access to GICR_WAKER is restricted on msm8996 SoC in Hypervisor. > > Its been more than 2+ years of wait for this to be fixed, which has > > no hopes to be fixed. This change was introduced for the "lead device" > > on msm8996 platform. It looks like all publicly available msm8996 and > > other qcom SoCs have this implementation. > > > > So add a quirk to not access this register on msm8996. > > > > With this quirk MSM8996 can at least boot out of mainline, > > which can help community to work with boards based on MSM8996 and other > > SoCs with have this restrictions. This Quirk is based on device tree > > compatible string. > > > > Without this patch Qualcomm DB820c board reboots when GICR_WAKER > > is accessed. > > > > Hi Srinivas, > > Given that the change request introducing this restriction looks quite > generic and that we've heard reports of other shipping platforms having > the same restriction, could we make this slightly more generic? s/restriction/gross bug/ > I.e. dropping the MSM8996 from the flag name and perhaps use a bool > property in devicetree to toggle the flag, instead of adding compatibles > as we figure out which Qualcomm platforms has this restriction. If we are to introduce a property, then it ought to be an erratum number (similar to what we do for the arch timer). Srinivas wasn't able to obtain one despite the defect having been known for years, so I guess this is out. Thanks, M. -- Jazz is not dead, it just smell funny.
Re: [PATCH V5 1/2] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE
On 28/11/18 18:54, Daniel Lezcano wrote:
> On 28/11/2018 12:44, Juri Lelli wrote:
> > Hi Daniel,
> >
> > On 27/11/18 14:24, Daniel Lezcano wrote:
> >> The mutex protects a per_cpu variable access. The potential race can
> >> happen only when the cpufreq governor module is loaded and at the same
> >> time the cpu capacity is changed in the sysfs.
> >>
> >> There is no real interest of using a mutex to protect a variable
> >> assignation when there is no situation where a task can take the lock
> >> and block.
> >>
> >> Replace the mutex by READ_ONCE / WRITE_ONCE.
> >>
> >> Signed-off-by: Daniel Lezcano
> >> Cc: Sudeep Holla
> >> Reviewed-by: Viresh Kumar
> >> ---
> >> drivers/base/arch_topology.c | 7 +--
> >> include/linux/arch_topology.h | 2 +-
> >> 2 files changed, 2 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> >> index edfcf8d..fd5325b 100644
> >> --- a/drivers/base/arch_topology.c
> >> +++ b/drivers/base/arch_topology.c
> >> @@ -31,12 +31,11 @@ void arch_set_freq_scale(struct cpumask *cpus,
> >> unsigned long cur_freq,
> >>per_cpu(freq_scale, i) = scale;
> >> }
> >>
> >> -static DEFINE_MUTEX(cpu_scale_mutex);
> >> DEFINE_PER_CPU(unsigned long, cpu_scale) = SCHED_CAPACITY_SCALE;
> >>
> >> void topology_set_cpu_scale(unsigned int cpu, unsigned long capacity)
> >> {
> >> - per_cpu(cpu_scale, cpu) = capacity;
> >> + WRITE_ONCE(per_cpu(cpu_scale, cpu), capacity);
> >> }
> >>
> >> static ssize_t cpu_capacity_show(struct device *dev,
> >> @@ -71,10 +70,8 @@ static ssize_t cpu_capacity_store(struct device *dev,
> >>if (new_capacity > SCHED_CAPACITY_SCALE)
> >>return -EINVAL;
> >>
> >> - mutex_lock(_scale_mutex);
> >>for_each_cpu(i, _topology[this_cpu].core_sibling)
> >>topology_set_cpu_scale(i, new_capacity);
> >> - mutex_unlock(_scale_mutex);
> >
> > IIRC this was meant to ensure atomic updates of all siblings with the new
> > capacity value. I actually now wonder if readers should not grab the
> > mutex as well (cpu_capacity_show()). Can't we get into a situation where
> > a reader might see siblings with intermediate values (while the loop
> > above is performing an update)?
>
> With or without this patch, it is the case:
>
> task1 task2
> | |
> read("/sys/.../cpu1/cpu_capacity) |
> | write("/sys/.../cpu1/cpu_capacity")
> read("/sys/.../cpu2/cpu_capacity) |
>
>
> There is no guarantee userspace can have a consistent view of the
> capacity. As soon as it reads a capacity, it can be changed in its back.
True, but w/o the mutex task1 could read different cpu_capacity values
for a cluster (it actually can also with current implementation, we
should grab the mutex in the read path as well if we want to avoid
this). Just pointing this out, not sure it is a problem, though, as even
the notion of strictly equal capacities clusters is going to disappear
AFAIK.
Re: [PATCH V5 1/2] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE
On 28/11/18 18:54, Daniel Lezcano wrote:
> On 28/11/2018 12:44, Juri Lelli wrote:
> > Hi Daniel,
> >
> > On 27/11/18 14:24, Daniel Lezcano wrote:
> >> The mutex protects a per_cpu variable access. The potential race can
> >> happen only when the cpufreq governor module is loaded and at the same
> >> time the cpu capacity is changed in the sysfs.
> >>
> >> There is no real interest of using a mutex to protect a variable
> >> assignation when there is no situation where a task can take the lock
> >> and block.
> >>
> >> Replace the mutex by READ_ONCE / WRITE_ONCE.
> >>
> >> Signed-off-by: Daniel Lezcano
> >> Cc: Sudeep Holla
> >> Reviewed-by: Viresh Kumar
> >> ---
> >> drivers/base/arch_topology.c | 7 +--
> >> include/linux/arch_topology.h | 2 +-
> >> 2 files changed, 2 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> >> index edfcf8d..fd5325b 100644
> >> --- a/drivers/base/arch_topology.c
> >> +++ b/drivers/base/arch_topology.c
> >> @@ -31,12 +31,11 @@ void arch_set_freq_scale(struct cpumask *cpus,
> >> unsigned long cur_freq,
> >>per_cpu(freq_scale, i) = scale;
> >> }
> >>
> >> -static DEFINE_MUTEX(cpu_scale_mutex);
> >> DEFINE_PER_CPU(unsigned long, cpu_scale) = SCHED_CAPACITY_SCALE;
> >>
> >> void topology_set_cpu_scale(unsigned int cpu, unsigned long capacity)
> >> {
> >> - per_cpu(cpu_scale, cpu) = capacity;
> >> + WRITE_ONCE(per_cpu(cpu_scale, cpu), capacity);
> >> }
> >>
> >> static ssize_t cpu_capacity_show(struct device *dev,
> >> @@ -71,10 +70,8 @@ static ssize_t cpu_capacity_store(struct device *dev,
> >>if (new_capacity > SCHED_CAPACITY_SCALE)
> >>return -EINVAL;
> >>
> >> - mutex_lock(_scale_mutex);
> >>for_each_cpu(i, _topology[this_cpu].core_sibling)
> >>topology_set_cpu_scale(i, new_capacity);
> >> - mutex_unlock(_scale_mutex);
> >
> > IIRC this was meant to ensure atomic updates of all siblings with the new
> > capacity value. I actually now wonder if readers should not grab the
> > mutex as well (cpu_capacity_show()). Can't we get into a situation where
> > a reader might see siblings with intermediate values (while the loop
> > above is performing an update)?
>
> With or without this patch, it is the case:
>
> task1 task2
> | |
> read("/sys/.../cpu1/cpu_capacity) |
> | write("/sys/.../cpu1/cpu_capacity")
> read("/sys/.../cpu2/cpu_capacity) |
>
>
> There is no guarantee userspace can have a consistent view of the
> capacity. As soon as it reads a capacity, it can be changed in its back.
True, but w/o the mutex task1 could read different cpu_capacity values
for a cluster (it actually can also with current implementation, we
should grab the mutex in the read path as well if we want to avoid
this). Just pointing this out, not sure it is a problem, though, as even
the notion of strictly equal capacities clusters is going to disappear
AFAIK.
Re: [PATCH v3 1/3] thermal: tegra: remove unnecessary warnings
On 28/11/2018 6:12 PM, Thierry Reding wrote: > On Wed, Nov 28, 2018 at 01:44:35PM +0800, Wei Ni wrote: >> Convert warnings to info as not all platforms may >> have all the thresholds and sensors enabled. >> >> Signed-off-by: Wei Ni >> --- >> drivers/thermal/tegra/soctherm.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) > > If these are all optional anyway, why even keep the informational > messages? While those may not show up as warnings in the log, they will > still be unconditional noise in the kernel log. Do we really want that, > or should we just trust that the DT is correct and shut up if optional > thresholds and sensors are not present? > > Thierry I think we can trust the DT files, but these trip points are important, it's better to notify user about these information. And user also can change log level to control these messages. Thanks. Wei. >
Re: [PATCH v3 1/3] thermal: tegra: remove unnecessary warnings
On 28/11/2018 6:12 PM, Thierry Reding wrote: > On Wed, Nov 28, 2018 at 01:44:35PM +0800, Wei Ni wrote: >> Convert warnings to info as not all platforms may >> have all the thresholds and sensors enabled. >> >> Signed-off-by: Wei Ni >> --- >> drivers/thermal/tegra/soctherm.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) > > If these are all optional anyway, why even keep the informational > messages? While those may not show up as warnings in the log, they will > still be unconditional noise in the kernel log. Do we really want that, > or should we just trust that the DT is correct and shut up if optional > thresholds and sensors are not present? > > Thierry I think we can trust the DT files, but these trip points are important, it's better to notify user about these information. And user also can change log level to control these messages. Thanks. Wei. >
Re: [PATCH 0/3] Stingray usb phy driver support
Hi Vijay, Could you please help to review and provide your comments to this patch series when you have time? Thank you, Regards, Srinath. On Tue, Nov 13, 2018 at 9:43 AM Srinath Mannam wrote: > > These patches add stingray usb phy driver and its > corresponding DT nodes with documentation. > > All patches are based on Linux-4.19. > > Srinath Mannam (3): > dt-bindings: phy: Add binding document for stingray usb phy > phy: sr-usb: Add stingray usb phy driver > arm64: dts: Add USB DT nodes for Stingray SoC > > .../bindings/phy/brcm,stingray-usb-phy.txt | 62 > .../boot/dts/broadcom/stingray/stingray-usb.dtsi | 95 ++ > .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 + > drivers/phy/broadcom/Kconfig | 11 + > drivers/phy/broadcom/Makefile | 1 + > drivers/phy/broadcom/phy-bcm-sr-usb.c | 367 > + > 6 files changed, 537 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt > create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi > create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c > > -- > 2.7.4 >
Re: [PATCH 0/3] Stingray usb phy driver support
Hi Vijay, Could you please help to review and provide your comments to this patch series when you have time? Thank you, Regards, Srinath. On Tue, Nov 13, 2018 at 9:43 AM Srinath Mannam wrote: > > These patches add stingray usb phy driver and its > corresponding DT nodes with documentation. > > All patches are based on Linux-4.19. > > Srinath Mannam (3): > dt-bindings: phy: Add binding document for stingray usb phy > phy: sr-usb: Add stingray usb phy driver > arm64: dts: Add USB DT nodes for Stingray SoC > > .../bindings/phy/brcm,stingray-usb-phy.txt | 62 > .../boot/dts/broadcom/stingray/stingray-usb.dtsi | 95 ++ > .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 + > drivers/phy/broadcom/Kconfig | 11 + > drivers/phy/broadcom/Makefile | 1 + > drivers/phy/broadcom/phy-bcm-sr-usb.c | 367 > + > 6 files changed, 537 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt > create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi > create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c > > -- > 2.7.4 >
[RESEND PATCH 3/4] mtd: spi-nor: mtk-quadspi: add SNOR_HWCAPS_READ for capcity setting
From: Guochun Mao
SNOR_HWCAPS_READ is a basic read mode for both flash and controller,
it should be supported, so add the capcity for mtk-quadspi.
Signed-off-by: Guochun Mao
Tested-by: Ryder Lee
---
drivers/mtd/spi-nor/mtk-quadspi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index 2278677..c198fd2 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -433,7 +433,8 @@ static int mtk_nor_init(struct mtk_nor *mtk_nor,
struct device_node *flash_node)
{
const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ_FAST |
+ .mask = SNOR_HWCAPS_READ |
+ SNOR_HWCAPS_READ_FAST |
SNOR_HWCAPS_READ_1_1_2 |
SNOR_HWCAPS_PP,
};
--
1.9.1
[RESEND PATCH 2/4] mtd: spi-nor: mtk-quadspi: use ofpart for parsing partitions
From: Guochun Mao
Replace mtd_device_register with mtd_device_parse_register for
parsing partitions and add ofpart support.
Signed-off-by: Guochun Mao
Tested-by: Ryder Lee
---
drivers/mtd/spi-nor/mtk-quadspi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index 5442993..2278677 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -118,6 +118,8 @@ struct mtk_nor {
struct clk *nor_clk;
};
+static const char * const probes[] = { "ofpart", NULL };
+
static void mtk_nor_set_read_mode(struct mtk_nor *mtk_nor)
{
struct spi_nor *nor = _nor->nor;
@@ -457,7 +459,7 @@ static int mtk_nor_init(struct mtk_nor *mtk_nor,
if (ret)
return ret;
- return mtd_device_register(>mtd, NULL, 0);
+ return mtd_device_parse_register(>mtd, probes, NULL, NULL, 0);
}
static int mtk_nor_drv_probe(struct platform_device *pdev)
--
1.9.1
[RESEND PATCH 3/4] mtd: spi-nor: mtk-quadspi: add SNOR_HWCAPS_READ for capcity setting
From: Guochun Mao
SNOR_HWCAPS_READ is a basic read mode for both flash and controller,
it should be supported, so add the capcity for mtk-quadspi.
Signed-off-by: Guochun Mao
Tested-by: Ryder Lee
---
drivers/mtd/spi-nor/mtk-quadspi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index 2278677..c198fd2 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -433,7 +433,8 @@ static int mtk_nor_init(struct mtk_nor *mtk_nor,
struct device_node *flash_node)
{
const struct spi_nor_hwcaps hwcaps = {
- .mask = SNOR_HWCAPS_READ_FAST |
+ .mask = SNOR_HWCAPS_READ |
+ SNOR_HWCAPS_READ_FAST |
SNOR_HWCAPS_READ_1_1_2 |
SNOR_HWCAPS_PP,
};
--
1.9.1
[RESEND PATCH 2/4] mtd: spi-nor: mtk-quadspi: use ofpart for parsing partitions
From: Guochun Mao
Replace mtd_device_register with mtd_device_parse_register for
parsing partitions and add ofpart support.
Signed-off-by: Guochun Mao
Tested-by: Ryder Lee
---
drivers/mtd/spi-nor/mtk-quadspi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index 5442993..2278677 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -118,6 +118,8 @@ struct mtk_nor {
struct clk *nor_clk;
};
+static const char * const probes[] = { "ofpart", NULL };
+
static void mtk_nor_set_read_mode(struct mtk_nor *mtk_nor)
{
struct spi_nor *nor = _nor->nor;
@@ -457,7 +459,7 @@ static int mtk_nor_init(struct mtk_nor *mtk_nor,
if (ret)
return ret;
- return mtd_device_register(>mtd, NULL, 0);
+ return mtd_device_parse_register(>mtd, probes, NULL, NULL, 0);
}
static int mtk_nor_drv_probe(struct platform_device *pdev)
--
1.9.1
[RESEND PATCH 4/4] mtd: spi-nor: mtk-quadspi: rename config to a common one
The quadspi is a generic communication interface which could be shared with other MediaTek SoCs. Hence rename it to a common one. Signed-off-by: Ryder Lee --- drivers/mtd/spi-nor/Kconfig | 16 drivers/mtd/spi-nor/Makefile | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index 6cc9c92..2062611 100644 --- a/drivers/mtd/spi-nor/Kconfig +++ b/drivers/mtd/spi-nor/Kconfig @@ -7,14 +7,6 @@ menuconfig MTD_SPI_NOR if MTD_SPI_NOR -config MTD_MT81xx_NOR - tristate "Mediatek MT81xx SPI NOR flash controller" - depends on HAS_IOMEM - help - This enables access to SPI NOR flash, using MT81xx SPI NOR flash - controller. This controller does not support generic SPI BUS, it only - supports SPI NOR Flash. - config MTD_SPI_NOR_USE_4K_SECTORS bool "Use small 4096 B erase sectors" default y @@ -86,6 +78,14 @@ config SPI_NXP_SPIFI Flash. Enable this option if you have a device with a SPIFI controller and want to access the Flash as a mtd device. +config SPI_MTK_QUADSPI + tristate "MediaTek Quad SPI controller" + depends on HAS_IOMEM + help + This enables support for the Quad SPI controller in master mode. + This controller does not support generic SPI. It only supports + SPI NOR. + config SPI_INTEL_SPI tristate diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile index f4c61d2..7f4b6f6 100644 --- a/drivers/mtd/spi-nor/Makefile +++ b/drivers/mtd/spi-nor/Makefile @@ -5,7 +5,7 @@ obj-$(CONFIG_SPI_ATMEL_QUADSPI) += atmel-quadspi.o obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o -obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o +obj-$(CONFIG_SPI_MTK_QUADSPI)+= mtk-quadspi.o obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o obj-$(CONFIG_SPI_INTEL_SPI)+= intel-spi.o obj-$(CONFIG_SPI_INTEL_SPI_PCI)+= intel-spi-pci.o -- 1.9.1
[RESEND PATCH 4/4] mtd: spi-nor: mtk-quadspi: rename config to a common one
The quadspi is a generic communication interface which could be shared with other MediaTek SoCs. Hence rename it to a common one. Signed-off-by: Ryder Lee --- drivers/mtd/spi-nor/Kconfig | 16 drivers/mtd/spi-nor/Makefile | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig index 6cc9c92..2062611 100644 --- a/drivers/mtd/spi-nor/Kconfig +++ b/drivers/mtd/spi-nor/Kconfig @@ -7,14 +7,6 @@ menuconfig MTD_SPI_NOR if MTD_SPI_NOR -config MTD_MT81xx_NOR - tristate "Mediatek MT81xx SPI NOR flash controller" - depends on HAS_IOMEM - help - This enables access to SPI NOR flash, using MT81xx SPI NOR flash - controller. This controller does not support generic SPI BUS, it only - supports SPI NOR Flash. - config MTD_SPI_NOR_USE_4K_SECTORS bool "Use small 4096 B erase sectors" default y @@ -86,6 +78,14 @@ config SPI_NXP_SPIFI Flash. Enable this option if you have a device with a SPIFI controller and want to access the Flash as a mtd device. +config SPI_MTK_QUADSPI + tristate "MediaTek Quad SPI controller" + depends on HAS_IOMEM + help + This enables support for the Quad SPI controller in master mode. + This controller does not support generic SPI. It only supports + SPI NOR. + config SPI_INTEL_SPI tristate diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile index f4c61d2..7f4b6f6 100644 --- a/drivers/mtd/spi-nor/Makefile +++ b/drivers/mtd/spi-nor/Makefile @@ -5,7 +5,7 @@ obj-$(CONFIG_SPI_ATMEL_QUADSPI) += atmel-quadspi.o obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o -obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o +obj-$(CONFIG_SPI_MTK_QUADSPI)+= mtk-quadspi.o obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o obj-$(CONFIG_SPI_INTEL_SPI)+= intel-spi.o obj-$(CONFIG_SPI_INTEL_SPI_PCI)+= intel-spi-pci.o -- 1.9.1
[RESEND PATCH 1/4] dt-bindings: mtd: mtk-quadspi: update bindings for MT7629 SoC
This updates bindings for the MT7629 SPI-NOR controller. Signed-off-by: Ryder Lee --- Documentation/devicetree/bindings/mtd/mtk-quadspi.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt index 56d3668..a12e3b5 100644 --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt @@ -1,4 +1,4 @@ -* Serial NOR flash controller for MTK MT81xx (and similar) +* Serial NOR flash controller for MediaTek SoCs Required properties: - compatible:For mt8173, compatible should be "mediatek,mt8173-nor", @@ -10,6 +10,7 @@ Required properties: "mediatek,mt2712-nor", "mediatek,mt8173-nor" "mediatek,mt7622-nor", "mediatek,mt8173-nor" "mediatek,mt7623-nor", "mediatek,mt8173-nor" + "mediatek,mt7629-nor", "mediatek,mt8173-nor" "mediatek,mt8173-nor" - reg: physical base address and length of the controller's register - clocks:the phandle of the clocks needed by the nor controller -- 1.9.1
[RESEND PATCH 1/4] dt-bindings: mtd: mtk-quadspi: update bindings for MT7629 SoC
This updates bindings for the MT7629 SPI-NOR controller. Signed-off-by: Ryder Lee --- Documentation/devicetree/bindings/mtd/mtk-quadspi.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt index 56d3668..a12e3b5 100644 --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt @@ -1,4 +1,4 @@ -* Serial NOR flash controller for MTK MT81xx (and similar) +* Serial NOR flash controller for MediaTek SoCs Required properties: - compatible:For mt8173, compatible should be "mediatek,mt8173-nor", @@ -10,6 +10,7 @@ Required properties: "mediatek,mt2712-nor", "mediatek,mt8173-nor" "mediatek,mt7622-nor", "mediatek,mt8173-nor" "mediatek,mt7623-nor", "mediatek,mt8173-nor" + "mediatek,mt7629-nor", "mediatek,mt8173-nor" "mediatek,mt8173-nor" - reg: physical base address and length of the controller's register - clocks:the phandle of the clocks needed by the nor controller -- 1.9.1
Re: [PATCH v3 0/3] perf report/annotate: Support average IPC and IPC coverage for function
On 11/28/2018 6:18 PM, Jiri Olsa wrote:
On Wed, Nov 28, 2018 at 11:17:57AM +0100, Jiri Olsa wrote:
On Wed, Nov 28, 2018 at 11:14:55PM +0800, Jin Yao wrote:
Add supporting of displaying the average IPC and IPC coverage
percentage per function.
For example,
$ perf record -b ...
$ perf report -s symbol or
perf report -s symbol --stdio
Overhead Symbol IPC [IPC Coverage]
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
...
$ perf annotate --stdio2
Percent IPC Cycle (Average IPC: 2.30, IPC Coverage: 54.8%)
Disassembly of section .text:
0003aac0 :
8.32 3.28 sub$0x18,%rsp
3.28 mov$0x1,%esi
3.28 xor%eax,%eax
3.28 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
11.57 3.28 1 ↓ je 20
lock cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne29
↓ jmp43
11.57 1.1020: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
...
v3:
---
Remove the sortkey "ipc" from command-line. The columns "IPC"
and "[IPC Coverage]" are automatically enabled when "symbol"
is specified.
Patch "perf report: Display average IPC and IPC coverage per symbol"
is impacted.
v2:
---
1. Merge in Jiri's patch to support stdio mode
2. Add a new patch "perf annotate: Create a annotate2 flag
in struct symbol" which records if the symbol has been
annotated yet.
3. Minor update such as adding { } for multiline code in 'if'
condition.
Jin Yao (3):
perf annotate: Compute average IPC and IPC coverage per symbol
perf annotate: Create a annotate2 flag in struct symbol
perf report: Display average IPC and IPC coverage per symbol
hi,
I took he liberty and moved the annotation retrieval into
resort phase under progress bar scope. It's currently on top
of my perf/fixes branch, could you please check it?
git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
commits:
7f3ffdb9783f perf tools: Move symbol annotation to resort
e87f7d3c4f10 perf tools: Add perf_evsel__output_resort_cb function
40012b422108 perf tools: Add argument to hists__resort_cb_t callback
jirka
Hi Jiri,
Thanks for your patches. I have tested with your repo. Now I can see 2
progress bars. One is displayed at the events processing phase, the
other is displayed at resorting phase.
I have only one concern that is, in my test, much of time is consumed by
the event processing phase, for example, 90% of time. Only 10% of time
is consumed at resorting phase.
So do we really need the second progress bar?
Thanks
Jin Yao
Re: [PATCH] staging: wilc1000: correct inconsistent indenting
On Wed, 2018-11-28 at 19:17 +0100, Michael Straube wrote:
> Correct inconsistent indenting reported by smatch.
[]
> diff --git a/drivers/staging/wilc1000/wilc_spi.c
> b/drivers/staging/wilc1000/wilc_spi.c
[]
> @@ -963,7 +963,7 @@ static int wilc_spi_read_int(struct wilc *wilc, u32
> *int_status)
> dev_err(>dev,
> "Unexpected interrupt(2):j=%d,tmp=%x,mask=%x\n",
> j, tmp, unknown_mask);
> - happened = 1;
> + happened = 1;s a
> }
>
> j++;
Perhaps a little refactoring instead
---
drivers/staging/wilc1000/wilc_spi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_spi.c
b/drivers/staging/wilc1000/wilc_spi.c
index 35ff432587fe..a38ddb1f0a1f 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -927,7 +927,8 @@ static int wilc_spi_read_int(struct wilc *wilc, u32
*int_status)
int ret;
u32 tmp;
u32 byte_cnt;
- int happened, j;
+ bool unexpected_irq;
+ int j;
u32 unknown_mask;
u32 irq_flags;
int k = IRG_FLAGS_OFFSET + 5;
@@ -947,8 +948,6 @@ static int wilc_spi_read_int(struct wilc *wilc, u32
*int_status)
j = 0;
do {
- happened = 0;
-
wilc_spi_read_reg(wilc, 0x1a90, _flags);
tmp |= ((irq_flags >> 27) << IRG_FLAGS_OFFSET);
@@ -959,15 +958,14 @@ static int wilc_spi_read_int(struct wilc *wilc, u32
*int_status)
unknown_mask = ~((1ul << spi_priv->nint) - 1);
- if ((tmp >> IRG_FLAGS_OFFSET) & unknown_mask) {
+ unexpected_irq = (tmp >> IRG_FLAGS_OFFSET) & unknown_mask;
+ if (unexpected_irq)
dev_err(>dev,
"Unexpected interrupt(2):j=%d,tmp=%x,mask=%x\n",
j, tmp, unknown_mask);
- happened = 1;
- }
j++;
- } while (happened);
+ } while (unexpected_irq);
*int_status = tmp;
Re: [PATCH] staging: wilc1000: correct inconsistent indenting
On Wed, 2018-11-28 at 19:17 +0100, Michael Straube wrote:
> Correct inconsistent indenting reported by smatch.
[]
> diff --git a/drivers/staging/wilc1000/wilc_spi.c
> b/drivers/staging/wilc1000/wilc_spi.c
[]
> @@ -963,7 +963,7 @@ static int wilc_spi_read_int(struct wilc *wilc, u32
> *int_status)
> dev_err(>dev,
> "Unexpected interrupt(2):j=%d,tmp=%x,mask=%x\n",
> j, tmp, unknown_mask);
> - happened = 1;
> + happened = 1;s a
> }
>
> j++;
Perhaps a little refactoring instead
---
drivers/staging/wilc1000/wilc_spi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_spi.c
b/drivers/staging/wilc1000/wilc_spi.c
index 35ff432587fe..a38ddb1f0a1f 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -927,7 +927,8 @@ static int wilc_spi_read_int(struct wilc *wilc, u32
*int_status)
int ret;
u32 tmp;
u32 byte_cnt;
- int happened, j;
+ bool unexpected_irq;
+ int j;
u32 unknown_mask;
u32 irq_flags;
int k = IRG_FLAGS_OFFSET + 5;
@@ -947,8 +948,6 @@ static int wilc_spi_read_int(struct wilc *wilc, u32
*int_status)
j = 0;
do {
- happened = 0;
-
wilc_spi_read_reg(wilc, 0x1a90, _flags);
tmp |= ((irq_flags >> 27) << IRG_FLAGS_OFFSET);
@@ -959,15 +958,14 @@ static int wilc_spi_read_int(struct wilc *wilc, u32
*int_status)
unknown_mask = ~((1ul << spi_priv->nint) - 1);
- if ((tmp >> IRG_FLAGS_OFFSET) & unknown_mask) {
+ unexpected_irq = (tmp >> IRG_FLAGS_OFFSET) & unknown_mask;
+ if (unexpected_irq)
dev_err(>dev,
"Unexpected interrupt(2):j=%d,tmp=%x,mask=%x\n",
j, tmp, unknown_mask);
- happened = 1;
- }
j++;
- } while (happened);
+ } while (unexpected_irq);
*int_status = tmp;
Re: [PATCH v3 0/3] perf report/annotate: Support average IPC and IPC coverage for function
On 11/28/2018 6:18 PM, Jiri Olsa wrote:
On Wed, Nov 28, 2018 at 11:17:57AM +0100, Jiri Olsa wrote:
On Wed, Nov 28, 2018 at 11:14:55PM +0800, Jin Yao wrote:
Add supporting of displaying the average IPC and IPC coverage
percentage per function.
For example,
$ perf record -b ...
$ perf report -s symbol or
perf report -s symbol --stdio
Overhead Symbol IPC [IPC Coverage]
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
...
$ perf annotate --stdio2
Percent IPC Cycle (Average IPC: 2.30, IPC Coverage: 54.8%)
Disassembly of section .text:
0003aac0 :
8.32 3.28 sub$0x18,%rsp
3.28 mov$0x1,%esi
3.28 xor%eax,%eax
3.28 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
11.57 3.28 1 ↓ je 20
lock cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne29
↓ jmp43
11.57 1.1020: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
...
v3:
---
Remove the sortkey "ipc" from command-line. The columns "IPC"
and "[IPC Coverage]" are automatically enabled when "symbol"
is specified.
Patch "perf report: Display average IPC and IPC coverage per symbol"
is impacted.
v2:
---
1. Merge in Jiri's patch to support stdio mode
2. Add a new patch "perf annotate: Create a annotate2 flag
in struct symbol" which records if the symbol has been
annotated yet.
3. Minor update such as adding { } for multiline code in 'if'
condition.
Jin Yao (3):
perf annotate: Compute average IPC and IPC coverage per symbol
perf annotate: Create a annotate2 flag in struct symbol
perf report: Display average IPC and IPC coverage per symbol
hi,
I took he liberty and moved the annotation retrieval into
resort phase under progress bar scope. It's currently on top
of my perf/fixes branch, could you please check it?
git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
commits:
7f3ffdb9783f perf tools: Move symbol annotation to resort
e87f7d3c4f10 perf tools: Add perf_evsel__output_resort_cb function
40012b422108 perf tools: Add argument to hists__resort_cb_t callback
jirka
Hi Jiri,
Thanks for your patches. I have tested with your repo. Now I can see 2
progress bars. One is displayed at the events processing phase, the
other is displayed at resorting phase.
I have only one concern that is, in my test, much of time is consumed by
the event processing phase, for example, 90% of time. Only 10% of time
is consumed at resorting phase.
So do we really need the second progress bar?
Thanks
Jin Yao
Re: [PATCH v2 1/3] mmc: sdhci: add support for using external DMA devices
On Tue, 20 Nov 2018 at 21:41, Adrian Hunter wrote:
>
> On 12/11/18 9:26 AM, Chunyan Zhang wrote:
> > Some standard SD host controllers can support both external dma
> > controllers as well as ADMA/SDMA in which the SD host controller
> > acts as DMA master. TI's omap controller is the case as an example.
> >
> > Currently the generic SDHCI code supports ADMA/SDMA integrated in
> > the host controller but does not have any support for external DMA
> > controllers implemented using dmaengine, meaning that custom code is
> > needed for any systems that use an external DMA controller with SDHCI.
>
> I still think you probably need to reset the DMA if there are transfer
> errors - perhaps you could comment on that. Also there are some comments
> below.
With regard to "transfer error", do you mean if
sdhci_external_dma_setup() failed?
Thanks,
Chunyan
>
> >
> > Signed-off-by: Chunyan Zhang
> > ---
> > drivers/mmc/host/Kconfig | 13
> > drivers/mmc/host/sdhci.c | 181
> > ++-
> > drivers/mmc/host/sdhci.h | 8 +++
> > 3 files changed, 201 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 1b58739..7bf3eff 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -977,3 +977,16 @@ config MMC_SDHCI_OMAP
> > If you have a controller with this interface, say Y or M here.
> >
> > If unsure, say N.
> > +
> > +config MMC_SDHCI_EXTERNAL_DMA
> > +bool "Support external DMA in standard SD host controller"
>
> It would be simpler if the drivers that needed it just selected it e.g.
>
> config MMC_SDHCI_OMAP
> tristate "TI SDHCI Controller Support"
> depends on MMC_SDHCI_PLTFM && OF
> select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
>
> > + depends on MMC_SDHCI
> > + depends on DMA_ENGINE
> > + help
> > + This is an option for using external DMA device via dmaengine
> > + framework.
> > +
> > + If you have a controller which support using external DMA device
> > + for data transfer, can say Y.
> > +
> > + If unsure, say N.
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > index 99bdae5..853cc98 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -14,6 +14,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1309,6 +1310,158 @@ static void sdhci_del_timer(struct sdhci_host
> > *host, struct mmc_request *mrq)
> > del_timer(>timer);
> > }
> >
> > +#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
> > +static int sdhci_external_dma_init(struct sdhci_host *host)
> > +{
> > + int ret = 0;
> > + struct mmc_host *mmc = host->mmc;
> > +
> > + host->tx_chan = dma_request_chan(mmc->parent, "tx");
> > + if (IS_ERR(host->tx_chan)) {
> > + ret = PTR_ERR(host->tx_chan);
> > + if (ret != -EPROBE_DEFER)
> > + pr_warn("Failed to request TX DMA channel.\n");
> > + host->tx_chan = NULL;
> > + return ret;
> > + }
> > +
> > + host->rx_chan = dma_request_chan(mmc->parent, "rx");
> > + if (IS_ERR(host->rx_chan)) {
> > + if (host->tx_chan) {
> > + dma_release_channel(host->tx_chan);
> > + host->tx_chan = NULL;
> > + }
> > +
> > + ret = PTR_ERR(host->rx_chan);
> > + if (ret != -EPROBE_DEFER)
> > + pr_warn("Failed to request RX DMA channel.\n");
> > + host->rx_chan = NULL;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static inline struct dma_chan *
> > +sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data *data)
> > +{
> > + return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
> > +}
> > +
> > +static int sdhci_external_dma_setup(struct sdhci_host *host,
> > + struct mmc_command *cmd)
> > +{
> > + int ret = 0, i;
> > + struct dma_async_tx_descriptor *desc;
> > + struct mmc_data *data = cmd->data;
>
> cmd->data might be NULL? Have you tested this?
>
> > + struct dma_chan *chan;
> > + struct dma_slave_config cfg;
> > + dma_cookie_t cookie;
> > +
> > + if (!host->mapbase)
> > + return -EINVAL;
> > +
> > + cfg.src_addr = host->mapbase + SDHCI_BUFFER;
> > + cfg.dst_addr = host->mapbase + SDHCI_BUFFER;
> > + cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> > + cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> > + cfg.src_maxburst = data->blksz / 4;
> > + cfg.dst_maxburst = data->blksz / 4;
> > +
> > + /* Sanity check: all the SG entries must be aligned by block size. */
> > + for (i = 0; i < data->sg_len; i++) {
> > + if ((data->sg + i)->length % data->blksz)
> > + return -EINVAL;
> > + }
> > +
> > + chan =
Re: [PATCH v2 1/3] mmc: sdhci: add support for using external DMA devices
On Tue, 20 Nov 2018 at 21:41, Adrian Hunter wrote:
>
> On 12/11/18 9:26 AM, Chunyan Zhang wrote:
> > Some standard SD host controllers can support both external dma
> > controllers as well as ADMA/SDMA in which the SD host controller
> > acts as DMA master. TI's omap controller is the case as an example.
> >
> > Currently the generic SDHCI code supports ADMA/SDMA integrated in
> > the host controller but does not have any support for external DMA
> > controllers implemented using dmaengine, meaning that custom code is
> > needed for any systems that use an external DMA controller with SDHCI.
>
> I still think you probably need to reset the DMA if there are transfer
> errors - perhaps you could comment on that. Also there are some comments
> below.
With regard to "transfer error", do you mean if
sdhci_external_dma_setup() failed?
Thanks,
Chunyan
>
> >
> > Signed-off-by: Chunyan Zhang
> > ---
> > drivers/mmc/host/Kconfig | 13
> > drivers/mmc/host/sdhci.c | 181
> > ++-
> > drivers/mmc/host/sdhci.h | 8 +++
> > 3 files changed, 201 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index 1b58739..7bf3eff 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -977,3 +977,16 @@ config MMC_SDHCI_OMAP
> > If you have a controller with this interface, say Y or M here.
> >
> > If unsure, say N.
> > +
> > +config MMC_SDHCI_EXTERNAL_DMA
> > +bool "Support external DMA in standard SD host controller"
>
> It would be simpler if the drivers that needed it just selected it e.g.
>
> config MMC_SDHCI_OMAP
> tristate "TI SDHCI Controller Support"
> depends on MMC_SDHCI_PLTFM && OF
> select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
>
> > + depends on MMC_SDHCI
> > + depends on DMA_ENGINE
> > + help
> > + This is an option for using external DMA device via dmaengine
> > + framework.
> > +
> > + If you have a controller which support using external DMA device
> > + for data transfer, can say Y.
> > +
> > + If unsure, say N.
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > index 99bdae5..853cc98 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -14,6 +14,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1309,6 +1310,158 @@ static void sdhci_del_timer(struct sdhci_host
> > *host, struct mmc_request *mrq)
> > del_timer(>timer);
> > }
> >
> > +#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
> > +static int sdhci_external_dma_init(struct sdhci_host *host)
> > +{
> > + int ret = 0;
> > + struct mmc_host *mmc = host->mmc;
> > +
> > + host->tx_chan = dma_request_chan(mmc->parent, "tx");
> > + if (IS_ERR(host->tx_chan)) {
> > + ret = PTR_ERR(host->tx_chan);
> > + if (ret != -EPROBE_DEFER)
> > + pr_warn("Failed to request TX DMA channel.\n");
> > + host->tx_chan = NULL;
> > + return ret;
> > + }
> > +
> > + host->rx_chan = dma_request_chan(mmc->parent, "rx");
> > + if (IS_ERR(host->rx_chan)) {
> > + if (host->tx_chan) {
> > + dma_release_channel(host->tx_chan);
> > + host->tx_chan = NULL;
> > + }
> > +
> > + ret = PTR_ERR(host->rx_chan);
> > + if (ret != -EPROBE_DEFER)
> > + pr_warn("Failed to request RX DMA channel.\n");
> > + host->rx_chan = NULL;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static inline struct dma_chan *
> > +sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data *data)
> > +{
> > + return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
> > +}
> > +
> > +static int sdhci_external_dma_setup(struct sdhci_host *host,
> > + struct mmc_command *cmd)
> > +{
> > + int ret = 0, i;
> > + struct dma_async_tx_descriptor *desc;
> > + struct mmc_data *data = cmd->data;
>
> cmd->data might be NULL? Have you tested this?
>
> > + struct dma_chan *chan;
> > + struct dma_slave_config cfg;
> > + dma_cookie_t cookie;
> > +
> > + if (!host->mapbase)
> > + return -EINVAL;
> > +
> > + cfg.src_addr = host->mapbase + SDHCI_BUFFER;
> > + cfg.dst_addr = host->mapbase + SDHCI_BUFFER;
> > + cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> > + cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> > + cfg.src_maxburst = data->blksz / 4;
> > + cfg.dst_maxburst = data->blksz / 4;
> > +
> > + /* Sanity check: all the SG entries must be aligned by block size. */
> > + for (i = 0; i < data->sg_len; i++) {
> > + if ((data->sg + i)->length % data->blksz)
> > + return -EINVAL;
> > + }
> > +
> > + chan =
Re: [PATCH v2 0/3] Add support for using external dma in SDHCI
Hi Faiz, Many thanks for testing this. On Thu, 29 Nov 2018 at 00:59, Rizvi, Mohammad Faiz Abbas wrote: > > + Mark Brown > > Chunyan, > > On 11/21/2018 5:17 PM, Faiz Abbas wrote: > > Hi Chunyan, > > > > On 12/11/18 12:56 PM, Chunyan Zhang wrote: > >> Currently the generic SDHCI code in the Linux kernel supports the SD > >> standard DMA integrated into the host controller but does not have any > >> support for external DMA controllers implemented using dmaengine meaning > >> that custom code is needed for any systems that use a generic DMA > >> controller with SDHCI which in practice means any SDHCI controller that > >> doesn't have an integrated DMA controller so we should have this as a > >> generic feature. > >> > >> There are already a number of controller specific drivers that have > >> dmaengine > >> code, and some could use sdhci.c actually, but needed to implement > >> mmc_ops->request() > >> in their specific driver for sending command with external dma using > >> dmaengine > >> framework, with this patchset, them will take advantage of the generic > >> support. > >> TI's omap controller is the case as an example. > >> > >> Any comments are very appreciated. > >> > > > > This is great. It helps us move am335x and am43xx platforms to > > sdhci-omap. What platforms have you tested this on? > > > > Gentle ping on this. I tried testing these with an am335x-evm board. In > their current condition, the card fails to enumerate altogether. The > changes suggested by Adrian should fix this. Let me know when you post a v3. I addressed Adrian's comments, and posted a new patch under 1/3 of the last patch series, if this patch can be verified workable, I will send another new patchset also add your tested-by. Thanks, Chunyan > > Thanks, > Faiz
Re: [PATCH v2 0/3] Add support for using external dma in SDHCI
Hi Faiz, Many thanks for testing this. On Thu, 29 Nov 2018 at 00:59, Rizvi, Mohammad Faiz Abbas wrote: > > + Mark Brown > > Chunyan, > > On 11/21/2018 5:17 PM, Faiz Abbas wrote: > > Hi Chunyan, > > > > On 12/11/18 12:56 PM, Chunyan Zhang wrote: > >> Currently the generic SDHCI code in the Linux kernel supports the SD > >> standard DMA integrated into the host controller but does not have any > >> support for external DMA controllers implemented using dmaengine meaning > >> that custom code is needed for any systems that use a generic DMA > >> controller with SDHCI which in practice means any SDHCI controller that > >> doesn't have an integrated DMA controller so we should have this as a > >> generic feature. > >> > >> There are already a number of controller specific drivers that have > >> dmaengine > >> code, and some could use sdhci.c actually, but needed to implement > >> mmc_ops->request() > >> in their specific driver for sending command with external dma using > >> dmaengine > >> framework, with this patchset, them will take advantage of the generic > >> support. > >> TI's omap controller is the case as an example. > >> > >> Any comments are very appreciated. > >> > > > > This is great. It helps us move am335x and am43xx platforms to > > sdhci-omap. What platforms have you tested this on? > > > > Gentle ping on this. I tried testing these with an am335x-evm board. In > their current condition, the card fails to enumerate altogether. The > changes suggested by Adrian should fix this. Let me know when you post a v3. I addressed Adrian's comments, and posted a new patch under 1/3 of the last patch series, if this patch can be verified workable, I will send another new patchset also add your tested-by. Thanks, Chunyan > > Thanks, > Faiz
[PATCH V3 1/3] mmc: sdhci: add support for using external DMA devices
Some standard SD host controllers can support both external dma
controllers as well as ADMA/SDMA in which the SD host controller
acts as DMA master. TI's omap controller is the case as an example.
Currently the generic SDHCI code supports ADMA/SDMA integrated in
the host controller but does not have any support for external DMA
controllers implemented using dmaengine, meaning that custom code is
needed for any systems that use an external DMA controller with SDHCI.
Signed-off-by: Chunyan Zhang
---
drivers/mmc/host/Kconfig | 14
drivers/mmc/host/sdhci.c | 185 ++-
drivers/mmc/host/sdhci.h | 8 ++
3 files changed, 206 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1b58739..4183f43 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -969,6 +969,7 @@ config MMC_SDHCI_XENON
config MMC_SDHCI_OMAP
tristate "TI SDHCI Controller Support"
depends on MMC_SDHCI_PLTFM && OF
+ select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
help
This selects the Secure Digital Host Controller Interface (SDHCI)
support present in TI's DRA7 SOCs. The controller supports
@@ -977,3 +978,16 @@ config MMC_SDHCI_OMAP
If you have a controller with this interface, say Y or M here.
If unsure, say N.
+
+config MMC_SDHCI_EXTERNAL_DMA
+bool "Support external DMA in standard SD host controller"
+ depends on MMC_SDHCI
+ depends on DMA_ENGINE
+ help
+ This is an option for using external DMA device via dmaengine
+ framework.
+
+ If you have a controller which support using external DMA device
+ for data transfer, can say Y.
+
+ If unsure, say N.
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 99bdae5..ad7cc80 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -14,6 +14,7 @@
*/
#include
+#include
#include
#include
#include
@@ -1309,6 +1310,162 @@ static void sdhci_del_timer(struct sdhci_host *host,
struct mmc_request *mrq)
del_timer(>timer);
}
+#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
+static int sdhci_external_dma_init(struct sdhci_host *host)
+{
+ int ret = 0;
+ struct mmc_host *mmc = host->mmc;
+
+ host->tx_chan = dma_request_chan(mmc->parent, "tx");
+ if (IS_ERR(host->tx_chan)) {
+ ret = PTR_ERR(host->tx_chan);
+ if (ret != -EPROBE_DEFER)
+ pr_warn("Failed to request TX DMA channel.\n");
+ host->tx_chan = NULL;
+ return ret;
+ }
+
+ host->rx_chan = dma_request_chan(mmc->parent, "rx");
+ if (IS_ERR(host->rx_chan)) {
+ if (host->tx_chan) {
+ dma_release_channel(host->tx_chan);
+ host->tx_chan = NULL;
+ }
+
+ ret = PTR_ERR(host->rx_chan);
+ if (ret != -EPROBE_DEFER)
+ pr_warn("Failed to request RX DMA channel.\n");
+ host->rx_chan = NULL;
+ }
+
+ return ret;
+}
+
+static inline struct dma_chan *
+sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data *data)
+{
+ return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
+}
+
+static int sdhci_external_dma_setup(struct sdhci_host *host,
+ struct mmc_command *cmd)
+{
+ int ret, i;
+ struct dma_async_tx_descriptor *desc;
+ struct mmc_data *data = cmd->data;
+ struct dma_chan *chan;
+ struct dma_slave_config cfg;
+ dma_cookie_t cookie;
+
+ if (!host->mapbase)
+ return -EINVAL;
+
+ if (!data)
+ return 0;
+
+ cfg.src_addr = host->mapbase + SDHCI_BUFFER;
+ cfg.dst_addr = host->mapbase + SDHCI_BUFFER;
+ cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ cfg.src_maxburst = data->blksz / 4;
+ cfg.dst_maxburst = data->blksz / 4;
+
+ /* Sanity check: all the SG entries must be aligned by block size. */
+ for (i = 0; i < data->sg_len; i++) {
+ if ((data->sg + i)->length % data->blksz)
+ return -EINVAL;
+ }
+
+ chan = sdhci_external_dma_channel(host, data);
+
+ ret = dmaengine_slave_config(chan, );
+ if (ret)
+ return ret;
+
+ desc = dmaengine_prep_slave_sg(chan, data->sg, data->sg_len,
+ mmc_get_dma_dir(data),
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (!desc)
+ return -EINVAL;
+
+ desc->callback = NULL;
+ desc->callback_param = NULL;
+
+ cookie = dmaengine_submit(desc);
+ if (cookie < 0)
+ ret = cookie;
+
+ return ret;
+}
+
+static void
[PATCH V3 1/3] mmc: sdhci: add support for using external DMA devices
Some standard SD host controllers can support both external dma
controllers as well as ADMA/SDMA in which the SD host controller
acts as DMA master. TI's omap controller is the case as an example.
Currently the generic SDHCI code supports ADMA/SDMA integrated in
the host controller but does not have any support for external DMA
controllers implemented using dmaengine, meaning that custom code is
needed for any systems that use an external DMA controller with SDHCI.
Signed-off-by: Chunyan Zhang
---
drivers/mmc/host/Kconfig | 14
drivers/mmc/host/sdhci.c | 185 ++-
drivers/mmc/host/sdhci.h | 8 ++
3 files changed, 206 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1b58739..4183f43 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -969,6 +969,7 @@ config MMC_SDHCI_XENON
config MMC_SDHCI_OMAP
tristate "TI SDHCI Controller Support"
depends on MMC_SDHCI_PLTFM && OF
+ select MMC_SDHCI_EXTERNAL_DMA if DMA_ENGINE
help
This selects the Secure Digital Host Controller Interface (SDHCI)
support present in TI's DRA7 SOCs. The controller supports
@@ -977,3 +978,16 @@ config MMC_SDHCI_OMAP
If you have a controller with this interface, say Y or M here.
If unsure, say N.
+
+config MMC_SDHCI_EXTERNAL_DMA
+bool "Support external DMA in standard SD host controller"
+ depends on MMC_SDHCI
+ depends on DMA_ENGINE
+ help
+ This is an option for using external DMA device via dmaengine
+ framework.
+
+ If you have a controller which support using external DMA device
+ for data transfer, can say Y.
+
+ If unsure, say N.
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 99bdae5..ad7cc80 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -14,6 +14,7 @@
*/
#include
+#include
#include
#include
#include
@@ -1309,6 +1310,162 @@ static void sdhci_del_timer(struct sdhci_host *host,
struct mmc_request *mrq)
del_timer(>timer);
}
+#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
+static int sdhci_external_dma_init(struct sdhci_host *host)
+{
+ int ret = 0;
+ struct mmc_host *mmc = host->mmc;
+
+ host->tx_chan = dma_request_chan(mmc->parent, "tx");
+ if (IS_ERR(host->tx_chan)) {
+ ret = PTR_ERR(host->tx_chan);
+ if (ret != -EPROBE_DEFER)
+ pr_warn("Failed to request TX DMA channel.\n");
+ host->tx_chan = NULL;
+ return ret;
+ }
+
+ host->rx_chan = dma_request_chan(mmc->parent, "rx");
+ if (IS_ERR(host->rx_chan)) {
+ if (host->tx_chan) {
+ dma_release_channel(host->tx_chan);
+ host->tx_chan = NULL;
+ }
+
+ ret = PTR_ERR(host->rx_chan);
+ if (ret != -EPROBE_DEFER)
+ pr_warn("Failed to request RX DMA channel.\n");
+ host->rx_chan = NULL;
+ }
+
+ return ret;
+}
+
+static inline struct dma_chan *
+sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data *data)
+{
+ return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
+}
+
+static int sdhci_external_dma_setup(struct sdhci_host *host,
+ struct mmc_command *cmd)
+{
+ int ret, i;
+ struct dma_async_tx_descriptor *desc;
+ struct mmc_data *data = cmd->data;
+ struct dma_chan *chan;
+ struct dma_slave_config cfg;
+ dma_cookie_t cookie;
+
+ if (!host->mapbase)
+ return -EINVAL;
+
+ if (!data)
+ return 0;
+
+ cfg.src_addr = host->mapbase + SDHCI_BUFFER;
+ cfg.dst_addr = host->mapbase + SDHCI_BUFFER;
+ cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ cfg.src_maxburst = data->blksz / 4;
+ cfg.dst_maxburst = data->blksz / 4;
+
+ /* Sanity check: all the SG entries must be aligned by block size. */
+ for (i = 0; i < data->sg_len; i++) {
+ if ((data->sg + i)->length % data->blksz)
+ return -EINVAL;
+ }
+
+ chan = sdhci_external_dma_channel(host, data);
+
+ ret = dmaengine_slave_config(chan, );
+ if (ret)
+ return ret;
+
+ desc = dmaengine_prep_slave_sg(chan, data->sg, data->sg_len,
+ mmc_get_dma_dir(data),
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (!desc)
+ return -EINVAL;
+
+ desc->callback = NULL;
+ desc->callback_param = NULL;
+
+ cookie = dmaengine_submit(desc);
+ if (cookie < 0)
+ ret = cookie;
+
+ return ret;
+}
+
+static void
Re: [RFC PATCH 0/5] x86: dynamic indirect call promotion
On Wed, Nov 28, 2018 at 7:24 PM Andy Lutomirski wrote: > > > On Nov 28, 2018, at 6:06 PM, Nadav Amit wrote: > > >> On Nov 28, 2018, at 5:40 PM, Andy Lutomirski wrote: > >> > >>> On Wed, Nov 28, 2018 at 4:38 PM Josh Poimboeuf > >>> wrote: > >>> On Wed, Nov 28, 2018 at 07:34:52PM +, Nadav Amit wrote: > > On Nov 28, 2018, at 8:08 AM, Josh Poimboeuf wrote: > > > >> On Wed, Oct 17, 2018 at 05:54:15PM -0700, Nadav Amit wrote: > >> This RFC introduces indirect call promotion in runtime, which for the > >> matter of simplification (and branding) will be called here > >> "relpolines" > >> (relative call + trampoline). Relpolines are mainly intended as a way > >> of reducing retpoline overheads due to Spectre v2. > >> > >> Unlike indirect call promotion through profile guided optimization, the > >> proposed approach does not require a profiling stage, works well with > >> modules whose address is unknown and can adapt to changing workloads. > >> > >> The main idea is simple: for every indirect call, we inject a piece of > >> code with fast- and slow-path calls. The fast path is used if the > >> target > >> matches the expected (hot) target. The slow-path uses a retpoline. > >> During training, the slow-path is set to call a function that saves the > >> call source and target in a hash-table and keep count for call > >> frequency. The most common target is then patched into the hot path. > >> > >> The patching is done on-the-fly by patching the conditional branch > >> (opcode and offset) that is used to compare the target to the hot > >> target. This allows to direct all cores to the fast-path, while > >> patching > >> the slow-path and vice-versa. Patching follows 2 more rules: (1) Only > >> patch a single byte when the code might be executed by any core. (2) > >> When patching more than one byte, ensure that all cores do not run the > >> to-be-patched-code by preventing this code from being preempted, and > >> using synchronize_sched() after patching the branch that jumps over > >> this > >> code. > >> > >> Changing all the indirect calls to use relpolines is done using > >> assembly > >> macro magic. There are alternative solutions, but this one is > >> relatively simple and transparent. There is also logic to retrain the > >> software predictor, but the policy it uses may need to be refined. > >> > >> Eventually the results are not bad (2 VCPU VM, throughput reported): > >> > >> baserelpoline > >> - > >> nginx 22898 25178 (+10%) > >> redis-ycsb 24523 25486 (+4%) > >> dbench 21442103 (+2%) > >> > >> When retpolines are disabled, and if retraining is off, performance > >> benefits are up to 2% (nginx), but are much less impressive. > > > > Hi Nadav, > > > > Peter pointed me to these patches during a discussion about retpoline > > profiling. Personally, I think this is brilliant. This could help > > networking and filesystem intensive workloads a lot. > > Thanks! I was a bit held-back by the relatively limited number of > responses. > >>> > >>> It is a rather, erm, ambitious idea, maybe they were speechless :-) > >>> > I finished another version two weeks ago, and every day I think: "should > it > be RFCv2 or v1”, ending up not sending it… > > There is one issue that I realized while working on the new version: I’m > not > sure it is well-defined what an outline retpoline is allowed to do. The > indirect branch promotion code can change rflags, which might cause > correction issues. In practice, using gcc, it is not a problem. > >>> > >>> Callees can clobber flags, so it seems fine to me. > >> > >> Just to check I understand your approach right: you made a macro > >> called "call", and you're therefore causing all instances of "call" to > >> become magic? This is... terrifying. It's even plausibly worse than > >> "#define if" :) The scariest bit is that it will impact inline asm as > >> well. Maybe a gcc plugin would be less alarming? > > > > It is likely to look less alarming. When I looked at the inline retpoline > > implementation of gcc, it didn’t look much better than what I did - it > > basically just emits assembly instructions. > > To be clear, that wasn’t a NAK. It was merely a “this is alarming.” Although... how do you avoid matching on things that really don't want this treatment? paravirt ops come to mind.
[PATCH AUTOSEL 4.4 05/13] bnx2x: Assign unique DMAE channel number for FW DMAE transactions.
From: Sudarsana Reddy Kalluru [ Upstream commit 77e461d14ed141253573eeeb4d34eccc51e38328 ] Driver assigns DMAE channel 0 for FW as part of START_RAMROD command. FW uses this channel for DMAE operations (e.g., TIME_SYNC implementation). Driver also uses the same channel 0 for DMAE operations for some of the PFs (e.g., PF0 on Port0). This could lead to concurrent access to the DMAE channel by FW and driver which is not legal. Hence need to assign unique DMAE id for FW. Currently following DMAE channels are used by the clients, MFW - OCBB/OCSD functionality uses DMAE channel 14/15 Driver 0-3 and 8-11 (for PF dmae operations) 4 and 12 (for stats requests) Assigning unique dmae_id '13' to the FW. Changes from previous version: -- v2: Incorporated the review comments. Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/ethernet/broadcom/bnx2x/bnx2x.h| 7 +++ drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 1 + 2 files changed, 8 insertions(+) diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h index 1ea068815419..2491cdc2535c 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h @@ -2291,6 +2291,13 @@ void bnx2x_igu_clear_sb_gen(struct bnx2x *bp, u8 func, u8 idu_sb_id, #define PMF_DMAE_C(bp) (BP_PORT(bp) * MAX_DMAE_C_PER_PORT + \ E1HVN_MAX) +/* Following is the DMAE channel number allocation for the clients. + * MFW: OCBB/OCSD implementations use DMAE channels 14/15 respectively. + * Driver: 0-3 and 8-11 (for PF dmae operations) + * 4 and 12 (for stats requests) + */ +#define BNX2X_FW_DMAE_C 13 /* Channel for FW DMAE operations */ + /* PCIE link and speed */ #define PCICFG_LINK_WIDTH 0x1f0 #define PCICFG_LINK_WIDTH_SHIFT20 diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c index ff702a707a91..343e3366d751 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c @@ -5931,6 +5931,7 @@ static inline int bnx2x_func_send_start(struct bnx2x *bp, rdata->sd_vlan_tag = cpu_to_le16(start_params->sd_vlan_tag); rdata->path_id = BP_PATH(bp); rdata->network_cos_mode = start_params->network_cos_mode; + rdata->dmae_cmd_id = BNX2X_FW_DMAE_C; rdata->vxlan_dst_port = cpu_to_le16(start_params->vxlan_dst_port); rdata->geneve_dst_port = cpu_to_le16(start_params->geneve_dst_port); -- 2.17.1
Re: [RFC PATCH 0/5] x86: dynamic indirect call promotion
On Wed, Nov 28, 2018 at 7:24 PM Andy Lutomirski wrote: > > > On Nov 28, 2018, at 6:06 PM, Nadav Amit wrote: > > >> On Nov 28, 2018, at 5:40 PM, Andy Lutomirski wrote: > >> > >>> On Wed, Nov 28, 2018 at 4:38 PM Josh Poimboeuf > >>> wrote: > >>> On Wed, Nov 28, 2018 at 07:34:52PM +, Nadav Amit wrote: > > On Nov 28, 2018, at 8:08 AM, Josh Poimboeuf wrote: > > > >> On Wed, Oct 17, 2018 at 05:54:15PM -0700, Nadav Amit wrote: > >> This RFC introduces indirect call promotion in runtime, which for the > >> matter of simplification (and branding) will be called here > >> "relpolines" > >> (relative call + trampoline). Relpolines are mainly intended as a way > >> of reducing retpoline overheads due to Spectre v2. > >> > >> Unlike indirect call promotion through profile guided optimization, the > >> proposed approach does not require a profiling stage, works well with > >> modules whose address is unknown and can adapt to changing workloads. > >> > >> The main idea is simple: for every indirect call, we inject a piece of > >> code with fast- and slow-path calls. The fast path is used if the > >> target > >> matches the expected (hot) target. The slow-path uses a retpoline. > >> During training, the slow-path is set to call a function that saves the > >> call source and target in a hash-table and keep count for call > >> frequency. The most common target is then patched into the hot path. > >> > >> The patching is done on-the-fly by patching the conditional branch > >> (opcode and offset) that is used to compare the target to the hot > >> target. This allows to direct all cores to the fast-path, while > >> patching > >> the slow-path and vice-versa. Patching follows 2 more rules: (1) Only > >> patch a single byte when the code might be executed by any core. (2) > >> When patching more than one byte, ensure that all cores do not run the > >> to-be-patched-code by preventing this code from being preempted, and > >> using synchronize_sched() after patching the branch that jumps over > >> this > >> code. > >> > >> Changing all the indirect calls to use relpolines is done using > >> assembly > >> macro magic. There are alternative solutions, but this one is > >> relatively simple and transparent. There is also logic to retrain the > >> software predictor, but the policy it uses may need to be refined. > >> > >> Eventually the results are not bad (2 VCPU VM, throughput reported): > >> > >> baserelpoline > >> - > >> nginx 22898 25178 (+10%) > >> redis-ycsb 24523 25486 (+4%) > >> dbench 21442103 (+2%) > >> > >> When retpolines are disabled, and if retraining is off, performance > >> benefits are up to 2% (nginx), but are much less impressive. > > > > Hi Nadav, > > > > Peter pointed me to these patches during a discussion about retpoline > > profiling. Personally, I think this is brilliant. This could help > > networking and filesystem intensive workloads a lot. > > Thanks! I was a bit held-back by the relatively limited number of > responses. > >>> > >>> It is a rather, erm, ambitious idea, maybe they were speechless :-) > >>> > I finished another version two weeks ago, and every day I think: "should > it > be RFCv2 or v1”, ending up not sending it… > > There is one issue that I realized while working on the new version: I’m > not > sure it is well-defined what an outline retpoline is allowed to do. The > indirect branch promotion code can change rflags, which might cause > correction issues. In practice, using gcc, it is not a problem. > >>> > >>> Callees can clobber flags, so it seems fine to me. > >> > >> Just to check I understand your approach right: you made a macro > >> called "call", and you're therefore causing all instances of "call" to > >> become magic? This is... terrifying. It's even plausibly worse than > >> "#define if" :) The scariest bit is that it will impact inline asm as > >> well. Maybe a gcc plugin would be less alarming? > > > > It is likely to look less alarming. When I looked at the inline retpoline > > implementation of gcc, it didn’t look much better than what I did - it > > basically just emits assembly instructions. > > To be clear, that wasn’t a NAK. It was merely a “this is alarming.” Although... how do you avoid matching on things that really don't want this treatment? paravirt ops come to mind.
[PATCH AUTOSEL 4.4 05/13] bnx2x: Assign unique DMAE channel number for FW DMAE transactions.
From: Sudarsana Reddy Kalluru [ Upstream commit 77e461d14ed141253573eeeb4d34eccc51e38328 ] Driver assigns DMAE channel 0 for FW as part of START_RAMROD command. FW uses this channel for DMAE operations (e.g., TIME_SYNC implementation). Driver also uses the same channel 0 for DMAE operations for some of the PFs (e.g., PF0 on Port0). This could lead to concurrent access to the DMAE channel by FW and driver which is not legal. Hence need to assign unique DMAE id for FW. Currently following DMAE channels are used by the clients, MFW - OCBB/OCSD functionality uses DMAE channel 14/15 Driver 0-3 and 8-11 (for PF dmae operations) 4 and 12 (for stats requests) Assigning unique dmae_id '13' to the FW. Changes from previous version: -- v2: Incorporated the review comments. Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/ethernet/broadcom/bnx2x/bnx2x.h| 7 +++ drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 1 + 2 files changed, 8 insertions(+) diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h index 1ea068815419..2491cdc2535c 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h @@ -2291,6 +2291,13 @@ void bnx2x_igu_clear_sb_gen(struct bnx2x *bp, u8 func, u8 idu_sb_id, #define PMF_DMAE_C(bp) (BP_PORT(bp) * MAX_DMAE_C_PER_PORT + \ E1HVN_MAX) +/* Following is the DMAE channel number allocation for the clients. + * MFW: OCBB/OCSD implementations use DMAE channels 14/15 respectively. + * Driver: 0-3 and 8-11 (for PF dmae operations) + * 4 and 12 (for stats requests) + */ +#define BNX2X_FW_DMAE_C 13 /* Channel for FW DMAE operations */ + /* PCIE link and speed */ #define PCICFG_LINK_WIDTH 0x1f0 #define PCICFG_LINK_WIDTH_SHIFT20 diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c index ff702a707a91..343e3366d751 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c @@ -5931,6 +5931,7 @@ static inline int bnx2x_func_send_start(struct bnx2x *bp, rdata->sd_vlan_tag = cpu_to_le16(start_params->sd_vlan_tag); rdata->path_id = BP_PATH(bp); rdata->network_cos_mode = start_params->network_cos_mode; + rdata->dmae_cmd_id = BNX2X_FW_DMAE_C; rdata->vxlan_dst_port = cpu_to_le16(start_params->vxlan_dst_port); rdata->geneve_dst_port = cpu_to_le16(start_params->geneve_dst_port); -- 2.17.1
[PATCH AUTOSEL 3.18 5/6] net: faraday: ftmac100: remove netif_running(netdev) check before disabling interrupts
From: Vincent Chen
[ Upstream commit 426a593e641ebf0d9288f0a2fcab644a86820220 ]
In the original ftmac100_interrupt(), the interrupts are only disabled when
the condition "netif_running(netdev)" is true. However, this condition
causes kerenl hang in the following case. When the user requests to
disable the network device, kernel will clear the bit __LINK_STATE_START
from the dev->state and then call the driver's ndo_stop function. Network
device interrupts are not blocked during this process. If an interrupt
occurs between clearing __LINK_STATE_START and stopping network device,
kernel cannot disable the interrupts due to the condition
"netif_running(netdev)" in the ISR. Hence, kernel will hang due to the
continuous interruption of the network device.
In order to solve the above problem, the interrupts of the network device
should always be disabled in the ISR without being restricted by the
condition "netif_running(netdev)".
[V2]
Remove unnecessary curly braces.
Signed-off-by: Vincent Chen
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/faraday/ftmac100.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/faraday/ftmac100.c
b/drivers/net/ethernet/faraday/ftmac100.c
index 4ff1adc6bfca..9a0703f2da9a 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -865,11 +865,10 @@ static irqreturn_t ftmac100_interrupt(int irq, void
*dev_id)
struct net_device *netdev = dev_id;
struct ftmac100 *priv = netdev_priv(netdev);
- if (likely(netif_running(netdev))) {
- /* Disable interrupts for polling */
- ftmac100_disable_all_int(priv);
+ /* Disable interrupts for polling */
+ ftmac100_disable_all_int(priv);
+ if (likely(netif_running(netdev)))
napi_schedule(>napi);
- }
return IRQ_HANDLED;
}
--
2.17.1
[PATCH AUTOSEL 3.18 6/6] net: amd: add missing of_node_put()
From: Yangtao Li
[ Upstream commit c44c749d3b6fdfca39002e7e48e03fe9f9fe37a3 ]
of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
This place doesn't do that, so fix it.
Signed-off-by: Yangtao Li
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/amd/sunlance.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/sunlance.c
b/drivers/net/ethernet/amd/sunlance.c
index 5e4273b7aa27..2bac37b9b4d3 100644
--- a/drivers/net/ethernet/amd/sunlance.c
+++ b/drivers/net/ethernet/amd/sunlance.c
@@ -1419,7 +1419,7 @@ static int sparc_lance_probe_one(struct platform_device
*op,
prop = of_get_property(nd, "tpe-link-test?", NULL);
if (!prop)
- goto no_link_test;
+ goto node_put;
if (strcmp(prop, "true")) {
printk(KERN_NOTICE "SunLance: warning:
overriding option "
@@ -1428,6 +1428,8 @@ static int sparc_lance_probe_one(struct platform_device
*op,
"to e...@skynet.be\n");
auxio_set_lte(AUXIO_LTE_ON);
}
+node_put:
+ of_node_put(nd);
no_link_test:
lp->auto_select = 1;
lp->tpe = 0;
--
2.17.1
[PATCH AUTOSEL 3.18 5/6] net: faraday: ftmac100: remove netif_running(netdev) check before disabling interrupts
From: Vincent Chen
[ Upstream commit 426a593e641ebf0d9288f0a2fcab644a86820220 ]
In the original ftmac100_interrupt(), the interrupts are only disabled when
the condition "netif_running(netdev)" is true. However, this condition
causes kerenl hang in the following case. When the user requests to
disable the network device, kernel will clear the bit __LINK_STATE_START
from the dev->state and then call the driver's ndo_stop function. Network
device interrupts are not blocked during this process. If an interrupt
occurs between clearing __LINK_STATE_START and stopping network device,
kernel cannot disable the interrupts due to the condition
"netif_running(netdev)" in the ISR. Hence, kernel will hang due to the
continuous interruption of the network device.
In order to solve the above problem, the interrupts of the network device
should always be disabled in the ISR without being restricted by the
condition "netif_running(netdev)".
[V2]
Remove unnecessary curly braces.
Signed-off-by: Vincent Chen
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/faraday/ftmac100.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/faraday/ftmac100.c
b/drivers/net/ethernet/faraday/ftmac100.c
index 4ff1adc6bfca..9a0703f2da9a 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -865,11 +865,10 @@ static irqreturn_t ftmac100_interrupt(int irq, void
*dev_id)
struct net_device *netdev = dev_id;
struct ftmac100 *priv = netdev_priv(netdev);
- if (likely(netif_running(netdev))) {
- /* Disable interrupts for polling */
- ftmac100_disable_all_int(priv);
+ /* Disable interrupts for polling */
+ ftmac100_disable_all_int(priv);
+ if (likely(netif_running(netdev)))
napi_schedule(>napi);
- }
return IRQ_HANDLED;
}
--
2.17.1
[PATCH AUTOSEL 3.18 6/6] net: amd: add missing of_node_put()
From: Yangtao Li
[ Upstream commit c44c749d3b6fdfca39002e7e48e03fe9f9fe37a3 ]
of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
This place doesn't do that, so fix it.
Signed-off-by: Yangtao Li
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/amd/sunlance.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/sunlance.c
b/drivers/net/ethernet/amd/sunlance.c
index 5e4273b7aa27..2bac37b9b4d3 100644
--- a/drivers/net/ethernet/amd/sunlance.c
+++ b/drivers/net/ethernet/amd/sunlance.c
@@ -1419,7 +1419,7 @@ static int sparc_lance_probe_one(struct platform_device
*op,
prop = of_get_property(nd, "tpe-link-test?", NULL);
if (!prop)
- goto no_link_test;
+ goto node_put;
if (strcmp(prop, "true")) {
printk(KERN_NOTICE "SunLance: warning:
overriding option "
@@ -1428,6 +1428,8 @@ static int sparc_lance_probe_one(struct platform_device
*op,
"to e...@skynet.be\n");
auxio_set_lte(AUXIO_LTE_ON);
}
+node_put:
+ of_node_put(nd);
no_link_test:
lp->auto_select = 1;
lp->tpe = 0;
--
2.17.1
Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
> On Nov 27, 2018, at 12:43 AM, Peter Zijlstra wrote:
>
>> On Mon, Nov 26, 2018 at 03:26:28PM -0600, Josh Poimboeuf wrote:
>>
>> Yeah, that's probably better. I assume you also mean that we would have
>> all text_poke_bp() users create a handler callback? That way the
>> interface is clear and consistent for everybody. Like:
>
> Can do, it does indeed make the interface less like a hack. It is not
> like there are too many users.
>
>> diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
>> index aac0c1f7e354..d4b0abe4912d 100644
>> --- a/arch/x86/kernel/jump_label.c
>> +++ b/arch/x86/kernel/jump_label.c
>> @@ -37,6 +37,11 @@ static void bug_at(unsigned char *ip, int line)
>>BUG();
>> }
>>
>> +static inline void jump_label_bp_handler(struct pt_regs *regs, void *data)
>> +{
>> +regs->ip += JUMP_LABEL_NOP_SIZE - 1;
>> +}
>> +
>> static void __ref __jump_label_transform(struct jump_entry *entry,
>> enum jump_label_type type,
>> void *(*poker)(void *, const void *, size_t),
>> @@ -91,7 +96,7 @@ static void __ref __jump_label_transform(struct jump_entry
>> *entry,
>>}
>>
>>text_poke_bp((void *)jump_entry_code(entry), code, JUMP_LABEL_NOP_SIZE,
>> - (void *)jump_entry_code(entry) + JUMP_LABEL_NOP_SIZE);
>> + jump_label_bp_handler, NULL);
>> }
>>
>> void arch_jump_label_transform(struct jump_entry *entry,
>
> Per that example..
>
>> diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
>> index d3869295b88d..e05ebc6d4db5 100644
>> --- a/arch/x86/kernel/static_call.c
>> +++ b/arch/x86/kernel/static_call.c
>> @@ -7,24 +7,30 @@
>>
>> #define CALL_INSN_SIZE 5
>>
>> +struct static_call_bp_data {
>> +unsigned long func, ret;
>> +};
>> +
>> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
>> +{
>> +struct static_call_bp_data *data = _data;
>> +
>> +/*
>> + * For inline static calls, push the return address on the stack so the
>> + * "called" function will return to the location immediately after the
>> + * call site.
>> + *
>> + * NOTE: This code will need to be revisited when kernel CET gets
>> + * implemented.
>> + */
>> +if (data->ret) {
>> +regs->sp -= sizeof(long);
>> +*(unsigned long *)regs->sp = data->ret;
>> +}
You can’t do this. Depending on the alignment of the old RSP, which
is not guaranteed, this overwrites regs->cs. IRET goes boom.
Maybe it could be fixed by pointing regs->ip at a real trampoline?
This code is subtle and executed rarely, which is a bag combination.
It would be great if we had a test case.
I think it would be great if the implementation could be, literally:
regs->ip -= 1;
return;
IOW, just retry and wait until we get the new patched instruction.
The problem is that, if we're in a context where IRQs are off, then
we're preventing on_each_cpu() from completing and, even if we somehow
just let the code know that we already serialized ourselves, we're
still potentially holding a spinlock that another CPU is waiting for
with IRQs off. Ugh. Anyone have a clever idea to fix that?
Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
> On Nov 27, 2018, at 12:43 AM, Peter Zijlstra wrote:
>
>> On Mon, Nov 26, 2018 at 03:26:28PM -0600, Josh Poimboeuf wrote:
>>
>> Yeah, that's probably better. I assume you also mean that we would have
>> all text_poke_bp() users create a handler callback? That way the
>> interface is clear and consistent for everybody. Like:
>
> Can do, it does indeed make the interface less like a hack. It is not
> like there are too many users.
>
>> diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
>> index aac0c1f7e354..d4b0abe4912d 100644
>> --- a/arch/x86/kernel/jump_label.c
>> +++ b/arch/x86/kernel/jump_label.c
>> @@ -37,6 +37,11 @@ static void bug_at(unsigned char *ip, int line)
>>BUG();
>> }
>>
>> +static inline void jump_label_bp_handler(struct pt_regs *regs, void *data)
>> +{
>> +regs->ip += JUMP_LABEL_NOP_SIZE - 1;
>> +}
>> +
>> static void __ref __jump_label_transform(struct jump_entry *entry,
>> enum jump_label_type type,
>> void *(*poker)(void *, const void *, size_t),
>> @@ -91,7 +96,7 @@ static void __ref __jump_label_transform(struct jump_entry
>> *entry,
>>}
>>
>>text_poke_bp((void *)jump_entry_code(entry), code, JUMP_LABEL_NOP_SIZE,
>> - (void *)jump_entry_code(entry) + JUMP_LABEL_NOP_SIZE);
>> + jump_label_bp_handler, NULL);
>> }
>>
>> void arch_jump_label_transform(struct jump_entry *entry,
>
> Per that example..
>
>> diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
>> index d3869295b88d..e05ebc6d4db5 100644
>> --- a/arch/x86/kernel/static_call.c
>> +++ b/arch/x86/kernel/static_call.c
>> @@ -7,24 +7,30 @@
>>
>> #define CALL_INSN_SIZE 5
>>
>> +struct static_call_bp_data {
>> +unsigned long func, ret;
>> +};
>> +
>> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
>> +{
>> +struct static_call_bp_data *data = _data;
>> +
>> +/*
>> + * For inline static calls, push the return address on the stack so the
>> + * "called" function will return to the location immediately after the
>> + * call site.
>> + *
>> + * NOTE: This code will need to be revisited when kernel CET gets
>> + * implemented.
>> + */
>> +if (data->ret) {
>> +regs->sp -= sizeof(long);
>> +*(unsigned long *)regs->sp = data->ret;
>> +}
You can’t do this. Depending on the alignment of the old RSP, which
is not guaranteed, this overwrites regs->cs. IRET goes boom.
Maybe it could be fixed by pointing regs->ip at a real trampoline?
This code is subtle and executed rarely, which is a bag combination.
It would be great if we had a test case.
I think it would be great if the implementation could be, literally:
regs->ip -= 1;
return;
IOW, just retry and wait until we get the new patched instruction.
The problem is that, if we're in a context where IRQs are off, then
we're preventing on_each_cpu() from completing and, even if we somehow
just let the code know that we already serialized ourselves, we're
still potentially holding a spinlock that another CPU is waiting for
with IRQs off. Ugh. Anyone have a clever idea to fix that?
[PATCH AUTOSEL 4.9 09/18] qed: Fix PTT leak in qed_drain()
From: Denis Bolotin [ Upstream commit 9aaa4e8ba12972d674caeefbc5f88d83235dd697 ] Release PTT before entering error flow. Signed-off-by: Denis Bolotin Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c index 1ed13a165e58..a769196628d9 100644 --- a/drivers/net/ethernet/qlogic/qed/qed_main.c +++ b/drivers/net/ethernet/qlogic/qed/qed_main.c @@ -1395,9 +1395,9 @@ static int qed_drain(struct qed_dev *cdev) return -EBUSY; } rc = qed_mcp_drain(hwfn, ptt); + qed_ptt_release(hwfn, ptt); if (rc) return rc; - qed_ptt_release(hwfn, ptt); } return 0; -- 2.17.1
[PATCH AUTOSEL 4.9 13/18] net/mlx4: Fix UBSAN warning of signed integer overflow
From: Aya Levin
[ Upstream commit a463146e67c848cbab5ce706d6528281b7cded08 ]
UBSAN: Undefined behavior in
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:626:29
signed integer overflow: 1802201963 + 1802201963 cannot be represented
in type 'int'
The union of res_reserved and res_port_rsvd[MLX4_MAX_PORTS] monitors
granting of reserved resources. The grant operation is calculated and
protected, thus both members of the union cannot be negative. Changed
type of res_reserved and of res_port_rsvd[MLX4_MAX_PORTS] from signed
int to unsigned int, allowing large value.
Fixes: 5a0d0a6161ae ("mlx4: Structures and init/teardown for VF resource
quotas")
Signed-off-by: Aya Levin
Signed-off-by: Tariq Toukan
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
index 086920b615af..df5d86fa0a92 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
@@ -542,8 +542,8 @@ struct slave_list {
struct resource_allocator {
spinlock_t alloc_lock; /* protect quotas */
union {
- int res_reserved;
- int res_port_rsvd[MLX4_MAX_PORTS];
+ unsigned int res_reserved;
+ unsigned int res_port_rsvd[MLX4_MAX_PORTS];
};
union {
int res_free;
--
2.17.1
[PATCH AUTOSEL 4.9 07/18] batman-adv: Expand merged fragment buffer for full packet
From: Sven Eckelmann
[ Upstream commit d7d8bbb40a5b1f682ee6589e212934f4c6b8ad60 ]
The complete size ("total_size") of the fragmented packet is stored in the
fragment header and in the size of the fragment chain. When the fragments
are ready for merge, the skbuff's tail of the first fragment is expanded to
have enough room after the data pointer for at least total_size. This means
that it gets expanded by total_size - first_skb->len.
But this is ignoring the fact that after expanding the buffer, the fragment
header is pulled by from this buffer. Assuming that the tailroom of the
buffer was already 0, the buffer after the data pointer of the skbuff is
now only total_size - len(fragment_header) large. When the merge function
is then processing the remaining fragments, the code to copy the data over
to the merged skbuff will cause an skb_over_panic when it tries to actually
put enough data to fill the total_size bytes of the packet.
The size of the skb_pull must therefore also be taken into account when the
buffer's tailroom is expanded.
Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge")
Reported-by: Martin Weinelt
Co-authored-by: Linus Lüssing
Signed-off-by: Sven Eckelmann
Signed-off-by: Simon Wunderlich
Signed-off-by: Sasha Levin
---
net/batman-adv/fragmentation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/fragmentation.c b/net/batman-adv/fragmentation.c
index 57215e3fd1a0..a06b6041f3e0 100644
--- a/net/batman-adv/fragmentation.c
+++ b/net/batman-adv/fragmentation.c
@@ -264,7 +264,7 @@ batadv_frag_merge_packets(struct hlist_head *chain)
kfree(entry);
packet = (struct batadv_frag_packet *)skb_out->data;
- size = ntohs(packet->total_size);
+ size = ntohs(packet->total_size) + hdr_size;
/* Make room for the rest of the fragments. */
if (pskb_expand_head(skb_out, 0, size - skb_out->len, GFP_ATOMIC) < 0) {
--
2.17.1
[PATCH AUTOSEL 4.9 09/18] qed: Fix PTT leak in qed_drain()
From: Denis Bolotin [ Upstream commit 9aaa4e8ba12972d674caeefbc5f88d83235dd697 ] Release PTT before entering error flow. Signed-off-by: Denis Bolotin Signed-off-by: Michal Kalderon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c index 1ed13a165e58..a769196628d9 100644 --- a/drivers/net/ethernet/qlogic/qed/qed_main.c +++ b/drivers/net/ethernet/qlogic/qed/qed_main.c @@ -1395,9 +1395,9 @@ static int qed_drain(struct qed_dev *cdev) return -EBUSY; } rc = qed_mcp_drain(hwfn, ptt); + qed_ptt_release(hwfn, ptt); if (rc) return rc; - qed_ptt_release(hwfn, ptt); } return 0; -- 2.17.1
[PATCH AUTOSEL 4.9 13/18] net/mlx4: Fix UBSAN warning of signed integer overflow
From: Aya Levin
[ Upstream commit a463146e67c848cbab5ce706d6528281b7cded08 ]
UBSAN: Undefined behavior in
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:626:29
signed integer overflow: 1802201963 + 1802201963 cannot be represented
in type 'int'
The union of res_reserved and res_port_rsvd[MLX4_MAX_PORTS] monitors
granting of reserved resources. The grant operation is calculated and
protected, thus both members of the union cannot be negative. Changed
type of res_reserved and of res_port_rsvd[MLX4_MAX_PORTS] from signed
int to unsigned int, allowing large value.
Fixes: 5a0d0a6161ae ("mlx4: Structures and init/teardown for VF resource
quotas")
Signed-off-by: Aya Levin
Signed-off-by: Tariq Toukan
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/mellanox/mlx4/mlx4.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
index 086920b615af..df5d86fa0a92 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
@@ -542,8 +542,8 @@ struct slave_list {
struct resource_allocator {
spinlock_t alloc_lock; /* protect quotas */
union {
- int res_reserved;
- int res_port_rsvd[MLX4_MAX_PORTS];
+ unsigned int res_reserved;
+ unsigned int res_port_rsvd[MLX4_MAX_PORTS];
};
union {
int res_free;
--
2.17.1
[PATCH AUTOSEL 4.9 07/18] batman-adv: Expand merged fragment buffer for full packet
From: Sven Eckelmann
[ Upstream commit d7d8bbb40a5b1f682ee6589e212934f4c6b8ad60 ]
The complete size ("total_size") of the fragmented packet is stored in the
fragment header and in the size of the fragment chain. When the fragments
are ready for merge, the skbuff's tail of the first fragment is expanded to
have enough room after the data pointer for at least total_size. This means
that it gets expanded by total_size - first_skb->len.
But this is ignoring the fact that after expanding the buffer, the fragment
header is pulled by from this buffer. Assuming that the tailroom of the
buffer was already 0, the buffer after the data pointer of the skbuff is
now only total_size - len(fragment_header) large. When the merge function
is then processing the remaining fragments, the code to copy the data over
to the merged skbuff will cause an skb_over_panic when it tries to actually
put enough data to fill the total_size bytes of the packet.
The size of the skb_pull must therefore also be taken into account when the
buffer's tailroom is expanded.
Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge")
Reported-by: Martin Weinelt
Co-authored-by: Linus Lüssing
Signed-off-by: Sven Eckelmann
Signed-off-by: Simon Wunderlich
Signed-off-by: Sasha Levin
---
net/batman-adv/fragmentation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/fragmentation.c b/net/batman-adv/fragmentation.c
index 57215e3fd1a0..a06b6041f3e0 100644
--- a/net/batman-adv/fragmentation.c
+++ b/net/batman-adv/fragmentation.c
@@ -264,7 +264,7 @@ batadv_frag_merge_packets(struct hlist_head *chain)
kfree(entry);
packet = (struct batadv_frag_packet *)skb_out->data;
- size = ntohs(packet->total_size);
+ size = ntohs(packet->total_size) + hdr_size;
/* Make room for the rest of the fragments. */
if (pskb_expand_head(skb_out, 0, size - skb_out->len, GFP_ATOMIC) < 0) {
--
2.17.1
[PATCH AUTOSEL 4.9 06/18] HID: input: Ignore battery reported by Symbol DS4308
From: Benson Leung
[ Upstream commit 0fd791841a6d67af1155a9c3de54dea51220721e ]
The Motorola/Zebra Symbol DS4308-HD is a handheld USB barcode scanner
which does not have a battery, but reports one anyway that always has
capacity 2.
Let's apply the IGNORE quirk to prevent it from being treated like a
power supply so that userspaces don't get confused that this
accessory is almost out of power and warn the user that they need to charge
their wired barcode scanner.
Reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=804720
Signed-off-by: Benson Leung
Reviewed-by: Benjamin Tissoires
Signed-off-by: Benjamin Tissoires
Signed-off-by: Sasha Levin
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-input.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 8913f357e78f..6f4c84d824e6 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -965,6 +965,7 @@
#define USB_VENDOR_ID_SYMBOL 0x05e0
#define USB_DEVICE_ID_SYMBOL_SCANNER_1 0x0800
#define USB_DEVICE_ID_SYMBOL_SCANNER_2 0x1300
+#define USB_DEVICE_ID_SYMBOL_SCANNER_3 0x1200
#define USB_VENDOR_ID_SYNAPTICS0x06cb
#define USB_DEVICE_ID_SYNAPTICS_TP 0x0001
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 5ff6dd8147b6..fc7ada26457e 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -324,6 +324,9 @@ static const struct hid_device_id hid_battery_quirks[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM,
USB_DEVICE_ID_ELECOM_BM084),
HID_BATTERY_QUIRK_IGNORE },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SYMBOL,
+ USB_DEVICE_ID_SYMBOL_SCANNER_3),
+ HID_BATTERY_QUIRK_IGNORE },
{}
};
--
2.17.1
[PATCH AUTOSEL 4.9 14/18] mtd: rawnand: qcom: Namespace prefix some commands
From: Olof Johansson
[ Upstream commit 33bf5519ae5dd356b182a94e3622f42860274a38 ]
PAGE_READ is used by RISC-V arch code included through mm headers,
and it makes sense to bring in a prefix on these in the driver.
drivers/mtd/nand/raw/qcom_nandc.c:153: warning: "PAGE_READ" redefined
#define PAGE_READ 0x2
In file included from include/linux/memremap.h:7,
from include/linux/mm.h:27,
from include/linux/scatterlist.h:8,
from include/linux/dma-mapping.h:11,
from drivers/mtd/nand/raw/qcom_nandc.c:17:
arch/riscv/include/asm/pgtable.h:48: note: this is the location of the previous
definition
Caught by riscv allmodconfig.
Signed-off-by: Olof Johansson
Reviewed-by: Miquel Raynal
Signed-off-by: Boris Brezillon
Signed-off-by: Sasha Levin
---
drivers/mtd/nand/qcom_nandc.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index dc4943134649..9f6c9a34b9eb 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -142,15 +142,15 @@
#defineNAND_VERSION_MINOR_SHIFT16
/* NAND OP_CMDs */
-#definePAGE_READ 0x2
-#definePAGE_READ_WITH_ECC 0x3
-#definePAGE_READ_WITH_ECC_SPARE0x4
-#definePROGRAM_PAGE0x6
-#definePAGE_PROGRAM_WITH_ECC 0x7
-#definePROGRAM_PAGE_SPARE 0x9
-#defineBLOCK_ERASE 0xa
-#defineFETCH_ID0xb
-#defineRESET_DEVICE0xd
+#defineOP_PAGE_READ0x2
+#defineOP_PAGE_READ_WITH_ECC 0x3
+#defineOP_PAGE_READ_WITH_ECC_SPARE 0x4
+#defineOP_PROGRAM_PAGE 0x6
+#defineOP_PAGE_PROGRAM_WITH_ECC0x7
+#defineOP_PROGRAM_PAGE_SPARE 0x9
+#defineOP_BLOCK_ERASE 0xa
+#defineOP_FETCH_ID 0xb
+#defineOP_RESET_DEVICE 0xd
/* Default Value for NAND_DEV_CMD_VLD */
#define NAND_DEV_CMD_VLD_VAL (READ_START_VLD | WRITE_START_VLD | \
@@ -425,11 +425,11 @@ static void update_rw_regs(struct qcom_nand_host *host,
int num_cw, bool read)
if (read) {
if (host->use_ecc)
- cmd = PAGE_READ_WITH_ECC | PAGE_ACC | LAST_PAGE;
+ cmd = OP_PAGE_READ_WITH_ECC | PAGE_ACC | LAST_PAGE;
else
- cmd = PAGE_READ | PAGE_ACC | LAST_PAGE;
+ cmd = OP_PAGE_READ | PAGE_ACC | LAST_PAGE;
} else {
- cmd = PROGRAM_PAGE | PAGE_ACC | LAST_PAGE;
+ cmd = OP_PROGRAM_PAGE | PAGE_ACC | LAST_PAGE;
}
if (host->use_ecc) {
@@ -662,7 +662,7 @@ static int nandc_param(struct qcom_nand_host *host)
* in use. we configure the controller to perform a raw read of 512
* bytes to read onfi params
*/
- nandc_set_reg(nandc, NAND_FLASH_CMD, PAGE_READ | PAGE_ACC | LAST_PAGE);
+ nandc_set_reg(nandc, NAND_FLASH_CMD, OP_PAGE_READ | PAGE_ACC |
LAST_PAGE);
nandc_set_reg(nandc, NAND_ADDR0, 0);
nandc_set_reg(nandc, NAND_ADDR1, 0);
nandc_set_reg(nandc, NAND_DEV0_CFG0, 0 << CW_PER_PAGE
@@ -715,7 +715,7 @@ static int erase_block(struct qcom_nand_host *host, int
page_addr)
struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
nandc_set_reg(nandc, NAND_FLASH_CMD,
- BLOCK_ERASE | PAGE_ACC | LAST_PAGE);
+ OP_BLOCK_ERASE | PAGE_ACC | LAST_PAGE);
nandc_set_reg(nandc, NAND_ADDR0, page_addr);
nandc_set_reg(nandc, NAND_ADDR1, 0);
nandc_set_reg(nandc, NAND_DEV0_CFG0,
@@ -746,7 +746,7 @@ static int read_id(struct qcom_nand_host *host, int column)
if (column == -1)
return 0;
- nandc_set_reg(nandc, NAND_FLASH_CMD, FETCH_ID);
+ nandc_set_reg(nandc, NAND_FLASH_CMD, OP_FETCH_ID);
nandc_set_reg(nandc, NAND_ADDR0, column);
nandc_set_reg(nandc, NAND_ADDR1, 0);
nandc_set_reg(nandc, NAND_FLASH_CHIP_SELECT, DM_EN);
@@ -766,7 +766,7 @@ static int reset(struct qcom_nand_host *host)
struct nand_chip *chip = >chip;
struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
- nandc_set_reg(nandc, NAND_FLASH_CMD, RESET_DEVICE);
+ nandc_set_reg(nandc, NAND_FLASH_CMD, OP_RESET_DEVICE);
nandc_set_reg(nandc, NAND_EXEC_CMD, 1);
write_reg_dma(nandc, NAND_FLASH_CMD, 1);
--
2.17.1
[PATCH AUTOSEL 4.9 06/18] HID: input: Ignore battery reported by Symbol DS4308
From: Benson Leung
[ Upstream commit 0fd791841a6d67af1155a9c3de54dea51220721e ]
The Motorola/Zebra Symbol DS4308-HD is a handheld USB barcode scanner
which does not have a battery, but reports one anyway that always has
capacity 2.
Let's apply the IGNORE quirk to prevent it from being treated like a
power supply so that userspaces don't get confused that this
accessory is almost out of power and warn the user that they need to charge
their wired barcode scanner.
Reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=804720
Signed-off-by: Benson Leung
Reviewed-by: Benjamin Tissoires
Signed-off-by: Benjamin Tissoires
Signed-off-by: Sasha Levin
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-input.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 8913f357e78f..6f4c84d824e6 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -965,6 +965,7 @@
#define USB_VENDOR_ID_SYMBOL 0x05e0
#define USB_DEVICE_ID_SYMBOL_SCANNER_1 0x0800
#define USB_DEVICE_ID_SYMBOL_SCANNER_2 0x1300
+#define USB_DEVICE_ID_SYMBOL_SCANNER_3 0x1200
#define USB_VENDOR_ID_SYNAPTICS0x06cb
#define USB_DEVICE_ID_SYNAPTICS_TP 0x0001
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 5ff6dd8147b6..fc7ada26457e 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -324,6 +324,9 @@ static const struct hid_device_id hid_battery_quirks[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM,
USB_DEVICE_ID_ELECOM_BM084),
HID_BATTERY_QUIRK_IGNORE },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SYMBOL,
+ USB_DEVICE_ID_SYMBOL_SCANNER_3),
+ HID_BATTERY_QUIRK_IGNORE },
{}
};
--
2.17.1
[PATCH AUTOSEL 4.9 14/18] mtd: rawnand: qcom: Namespace prefix some commands
From: Olof Johansson
[ Upstream commit 33bf5519ae5dd356b182a94e3622f42860274a38 ]
PAGE_READ is used by RISC-V arch code included through mm headers,
and it makes sense to bring in a prefix on these in the driver.
drivers/mtd/nand/raw/qcom_nandc.c:153: warning: "PAGE_READ" redefined
#define PAGE_READ 0x2
In file included from include/linux/memremap.h:7,
from include/linux/mm.h:27,
from include/linux/scatterlist.h:8,
from include/linux/dma-mapping.h:11,
from drivers/mtd/nand/raw/qcom_nandc.c:17:
arch/riscv/include/asm/pgtable.h:48: note: this is the location of the previous
definition
Caught by riscv allmodconfig.
Signed-off-by: Olof Johansson
Reviewed-by: Miquel Raynal
Signed-off-by: Boris Brezillon
Signed-off-by: Sasha Levin
---
drivers/mtd/nand/qcom_nandc.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index dc4943134649..9f6c9a34b9eb 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -142,15 +142,15 @@
#defineNAND_VERSION_MINOR_SHIFT16
/* NAND OP_CMDs */
-#definePAGE_READ 0x2
-#definePAGE_READ_WITH_ECC 0x3
-#definePAGE_READ_WITH_ECC_SPARE0x4
-#definePROGRAM_PAGE0x6
-#definePAGE_PROGRAM_WITH_ECC 0x7
-#definePROGRAM_PAGE_SPARE 0x9
-#defineBLOCK_ERASE 0xa
-#defineFETCH_ID0xb
-#defineRESET_DEVICE0xd
+#defineOP_PAGE_READ0x2
+#defineOP_PAGE_READ_WITH_ECC 0x3
+#defineOP_PAGE_READ_WITH_ECC_SPARE 0x4
+#defineOP_PROGRAM_PAGE 0x6
+#defineOP_PAGE_PROGRAM_WITH_ECC0x7
+#defineOP_PROGRAM_PAGE_SPARE 0x9
+#defineOP_BLOCK_ERASE 0xa
+#defineOP_FETCH_ID 0xb
+#defineOP_RESET_DEVICE 0xd
/* Default Value for NAND_DEV_CMD_VLD */
#define NAND_DEV_CMD_VLD_VAL (READ_START_VLD | WRITE_START_VLD | \
@@ -425,11 +425,11 @@ static void update_rw_regs(struct qcom_nand_host *host,
int num_cw, bool read)
if (read) {
if (host->use_ecc)
- cmd = PAGE_READ_WITH_ECC | PAGE_ACC | LAST_PAGE;
+ cmd = OP_PAGE_READ_WITH_ECC | PAGE_ACC | LAST_PAGE;
else
- cmd = PAGE_READ | PAGE_ACC | LAST_PAGE;
+ cmd = OP_PAGE_READ | PAGE_ACC | LAST_PAGE;
} else {
- cmd = PROGRAM_PAGE | PAGE_ACC | LAST_PAGE;
+ cmd = OP_PROGRAM_PAGE | PAGE_ACC | LAST_PAGE;
}
if (host->use_ecc) {
@@ -662,7 +662,7 @@ static int nandc_param(struct qcom_nand_host *host)
* in use. we configure the controller to perform a raw read of 512
* bytes to read onfi params
*/
- nandc_set_reg(nandc, NAND_FLASH_CMD, PAGE_READ | PAGE_ACC | LAST_PAGE);
+ nandc_set_reg(nandc, NAND_FLASH_CMD, OP_PAGE_READ | PAGE_ACC |
LAST_PAGE);
nandc_set_reg(nandc, NAND_ADDR0, 0);
nandc_set_reg(nandc, NAND_ADDR1, 0);
nandc_set_reg(nandc, NAND_DEV0_CFG0, 0 << CW_PER_PAGE
@@ -715,7 +715,7 @@ static int erase_block(struct qcom_nand_host *host, int
page_addr)
struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
nandc_set_reg(nandc, NAND_FLASH_CMD,
- BLOCK_ERASE | PAGE_ACC | LAST_PAGE);
+ OP_BLOCK_ERASE | PAGE_ACC | LAST_PAGE);
nandc_set_reg(nandc, NAND_ADDR0, page_addr);
nandc_set_reg(nandc, NAND_ADDR1, 0);
nandc_set_reg(nandc, NAND_DEV0_CFG0,
@@ -746,7 +746,7 @@ static int read_id(struct qcom_nand_host *host, int column)
if (column == -1)
return 0;
- nandc_set_reg(nandc, NAND_FLASH_CMD, FETCH_ID);
+ nandc_set_reg(nandc, NAND_FLASH_CMD, OP_FETCH_ID);
nandc_set_reg(nandc, NAND_ADDR0, column);
nandc_set_reg(nandc, NAND_ADDR1, 0);
nandc_set_reg(nandc, NAND_FLASH_CHIP_SELECT, DM_EN);
@@ -766,7 +766,7 @@ static int reset(struct qcom_nand_host *host)
struct nand_chip *chip = >chip;
struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
- nandc_set_reg(nandc, NAND_FLASH_CMD, RESET_DEVICE);
+ nandc_set_reg(nandc, NAND_FLASH_CMD, OP_RESET_DEVICE);
nandc_set_reg(nandc, NAND_EXEC_CMD, 1);
write_reg_dma(nandc, NAND_FLASH_CMD, 1);
--
2.17.1
[PATCH AUTOSEL 4.14 28/35] flexfiles: use per-mirror specified stateid for IO
From: Tigran Mkrtchyan
[ Upstream commit bb21ce0ad227b69ec0f83279297ee44232105d96 ]
rfc8435 says:
For tight coupling, ffds_stateid provides the stateid to be used by
the client to access the file.
However current implementation replaces per-mirror provided stateid with
by open or lock stateid.
Ensure that per-mirror stateid is used by ff_layout_write_prepare_v4 and
nfs4_ff_layout_prepare_ds.
Signed-off-by: Tigran Mkrtchyan
Signed-off-by: Rick Macklem
Signed-off-by: Trond Myklebust
Signed-off-by: Sasha Levin
---
fs/nfs/flexfilelayout/flexfilelayout.c| 21 +
fs/nfs/flexfilelayout/flexfilelayout.h| 4
fs/nfs/flexfilelayout/flexfilelayoutdev.c | 19 +++
3 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/fs/nfs/flexfilelayout/flexfilelayout.c
b/fs/nfs/flexfilelayout/flexfilelayout.c
index b0fa83a60754..13612a848378 100644
--- a/fs/nfs/flexfilelayout/flexfilelayout.c
+++ b/fs/nfs/flexfilelayout/flexfilelayout.c
@@ -1365,12 +1365,7 @@ static void ff_layout_read_prepare_v4(struct rpc_task
*task, void *data)
task))
return;
- if (ff_layout_read_prepare_common(task, hdr))
- return;
-
- if (nfs4_set_rw_stateid(>args.stateid, hdr->args.context,
- hdr->args.lock_context, FMODE_READ) == -EIO)
- rpc_exit(task, -EIO); /* lost lock, terminate I/O */
+ ff_layout_read_prepare_common(task, hdr);
}
static void ff_layout_read_call_done(struct rpc_task *task, void *data)
@@ -1539,12 +1534,7 @@ static void ff_layout_write_prepare_v4(struct rpc_task
*task, void *data)
task))
return;
- if (ff_layout_write_prepare_common(task, hdr))
- return;
-
- if (nfs4_set_rw_stateid(>args.stateid, hdr->args.context,
- hdr->args.lock_context, FMODE_WRITE) == -EIO)
- rpc_exit(task, -EIO); /* lost lock, terminate I/O */
+ ff_layout_write_prepare_common(task, hdr);
}
static void ff_layout_write_call_done(struct rpc_task *task, void *data)
@@ -1734,6 +1724,10 @@ ff_layout_read_pagelist(struct nfs_pgio_header *hdr)
fh = nfs4_ff_layout_select_ds_fh(lseg, idx);
if (fh)
hdr->args.fh = fh;
+
+ if (!nfs4_ff_layout_select_ds_stateid(lseg, idx, >args.stateid))
+ goto out_failed;
+
/*
* Note that if we ever decide to split across DSes,
* then we may need to handle dense-like offsets.
@@ -1796,6 +1790,9 @@ ff_layout_write_pagelist(struct nfs_pgio_header *hdr, int
sync)
if (fh)
hdr->args.fh = fh;
+ if (!nfs4_ff_layout_select_ds_stateid(lseg, idx, >args.stateid))
+ goto out_failed;
+
/*
* Note that if we ever decide to split across DSes,
* then we may need to handle dense-like offsets.
diff --git a/fs/nfs/flexfilelayout/flexfilelayout.h
b/fs/nfs/flexfilelayout/flexfilelayout.h
index 679cb087ef3f..d6515f1584f3 100644
--- a/fs/nfs/flexfilelayout/flexfilelayout.h
+++ b/fs/nfs/flexfilelayout/flexfilelayout.h
@@ -214,6 +214,10 @@ unsigned int ff_layout_fetch_ds_ioerr(struct
pnfs_layout_hdr *lo,
unsigned int maxnum);
struct nfs_fh *
nfs4_ff_layout_select_ds_fh(struct pnfs_layout_segment *lseg, u32 mirror_idx);
+int
+nfs4_ff_layout_select_ds_stateid(struct pnfs_layout_segment *lseg,
+ u32 mirror_idx,
+ nfs4_stateid *stateid);
struct nfs4_pnfs_ds *
nfs4_ff_layout_prepare_ds(struct pnfs_layout_segment *lseg, u32 ds_idx,
diff --git a/fs/nfs/flexfilelayout/flexfilelayoutdev.c
b/fs/nfs/flexfilelayout/flexfilelayoutdev.c
index d62279d3fc5d..9f69e83810ca 100644
--- a/fs/nfs/flexfilelayout/flexfilelayoutdev.c
+++ b/fs/nfs/flexfilelayout/flexfilelayoutdev.c
@@ -369,6 +369,25 @@ nfs4_ff_layout_select_ds_fh(struct pnfs_layout_segment
*lseg, u32 mirror_idx)
return fh;
}
+int
+nfs4_ff_layout_select_ds_stateid(struct pnfs_layout_segment *lseg,
+ u32 mirror_idx,
+ nfs4_stateid *stateid)
+{
+ struct nfs4_ff_layout_mirror *mirror = FF_LAYOUT_COMP(lseg, mirror_idx);
+
+ if (!ff_layout_mirror_valid(lseg, mirror, false)) {
+ pr_err_ratelimited("NFS: %s: No data server for mirror offset
index %d\n",
+ __func__, mirror_idx);
+ goto out;
+ }
+
+ nfs4_stateid_copy(stateid, >stateid);
+ return 1;
+out:
+ return 0;
+}
+
/**
* nfs4_ff_layout_prepare_ds - prepare a DS connection for an RPC call
* @lseg: the layout segment we're operating on
--
2.17.1
[PATCH AUTOSEL 4.14 28/35] flexfiles: use per-mirror specified stateid for IO
From: Tigran Mkrtchyan
[ Upstream commit bb21ce0ad227b69ec0f83279297ee44232105d96 ]
rfc8435 says:
For tight coupling, ffds_stateid provides the stateid to be used by
the client to access the file.
However current implementation replaces per-mirror provided stateid with
by open or lock stateid.
Ensure that per-mirror stateid is used by ff_layout_write_prepare_v4 and
nfs4_ff_layout_prepare_ds.
Signed-off-by: Tigran Mkrtchyan
Signed-off-by: Rick Macklem
Signed-off-by: Trond Myklebust
Signed-off-by: Sasha Levin
---
fs/nfs/flexfilelayout/flexfilelayout.c| 21 +
fs/nfs/flexfilelayout/flexfilelayout.h| 4
fs/nfs/flexfilelayout/flexfilelayoutdev.c | 19 +++
3 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/fs/nfs/flexfilelayout/flexfilelayout.c
b/fs/nfs/flexfilelayout/flexfilelayout.c
index b0fa83a60754..13612a848378 100644
--- a/fs/nfs/flexfilelayout/flexfilelayout.c
+++ b/fs/nfs/flexfilelayout/flexfilelayout.c
@@ -1365,12 +1365,7 @@ static void ff_layout_read_prepare_v4(struct rpc_task
*task, void *data)
task))
return;
- if (ff_layout_read_prepare_common(task, hdr))
- return;
-
- if (nfs4_set_rw_stateid(>args.stateid, hdr->args.context,
- hdr->args.lock_context, FMODE_READ) == -EIO)
- rpc_exit(task, -EIO); /* lost lock, terminate I/O */
+ ff_layout_read_prepare_common(task, hdr);
}
static void ff_layout_read_call_done(struct rpc_task *task, void *data)
@@ -1539,12 +1534,7 @@ static void ff_layout_write_prepare_v4(struct rpc_task
*task, void *data)
task))
return;
- if (ff_layout_write_prepare_common(task, hdr))
- return;
-
- if (nfs4_set_rw_stateid(>args.stateid, hdr->args.context,
- hdr->args.lock_context, FMODE_WRITE) == -EIO)
- rpc_exit(task, -EIO); /* lost lock, terminate I/O */
+ ff_layout_write_prepare_common(task, hdr);
}
static void ff_layout_write_call_done(struct rpc_task *task, void *data)
@@ -1734,6 +1724,10 @@ ff_layout_read_pagelist(struct nfs_pgio_header *hdr)
fh = nfs4_ff_layout_select_ds_fh(lseg, idx);
if (fh)
hdr->args.fh = fh;
+
+ if (!nfs4_ff_layout_select_ds_stateid(lseg, idx, >args.stateid))
+ goto out_failed;
+
/*
* Note that if we ever decide to split across DSes,
* then we may need to handle dense-like offsets.
@@ -1796,6 +1790,9 @@ ff_layout_write_pagelist(struct nfs_pgio_header *hdr, int
sync)
if (fh)
hdr->args.fh = fh;
+ if (!nfs4_ff_layout_select_ds_stateid(lseg, idx, >args.stateid))
+ goto out_failed;
+
/*
* Note that if we ever decide to split across DSes,
* then we may need to handle dense-like offsets.
diff --git a/fs/nfs/flexfilelayout/flexfilelayout.h
b/fs/nfs/flexfilelayout/flexfilelayout.h
index 679cb087ef3f..d6515f1584f3 100644
--- a/fs/nfs/flexfilelayout/flexfilelayout.h
+++ b/fs/nfs/flexfilelayout/flexfilelayout.h
@@ -214,6 +214,10 @@ unsigned int ff_layout_fetch_ds_ioerr(struct
pnfs_layout_hdr *lo,
unsigned int maxnum);
struct nfs_fh *
nfs4_ff_layout_select_ds_fh(struct pnfs_layout_segment *lseg, u32 mirror_idx);
+int
+nfs4_ff_layout_select_ds_stateid(struct pnfs_layout_segment *lseg,
+ u32 mirror_idx,
+ nfs4_stateid *stateid);
struct nfs4_pnfs_ds *
nfs4_ff_layout_prepare_ds(struct pnfs_layout_segment *lseg, u32 ds_idx,
diff --git a/fs/nfs/flexfilelayout/flexfilelayoutdev.c
b/fs/nfs/flexfilelayout/flexfilelayoutdev.c
index d62279d3fc5d..9f69e83810ca 100644
--- a/fs/nfs/flexfilelayout/flexfilelayoutdev.c
+++ b/fs/nfs/flexfilelayout/flexfilelayoutdev.c
@@ -369,6 +369,25 @@ nfs4_ff_layout_select_ds_fh(struct pnfs_layout_segment
*lseg, u32 mirror_idx)
return fh;
}
+int
+nfs4_ff_layout_select_ds_stateid(struct pnfs_layout_segment *lseg,
+ u32 mirror_idx,
+ nfs4_stateid *stateid)
+{
+ struct nfs4_ff_layout_mirror *mirror = FF_LAYOUT_COMP(lseg, mirror_idx);
+
+ if (!ff_layout_mirror_valid(lseg, mirror, false)) {
+ pr_err_ratelimited("NFS: %s: No data server for mirror offset
index %d\n",
+ __func__, mirror_idx);
+ goto out;
+ }
+
+ nfs4_stateid_copy(stateid, >stateid);
+ return 1;
+out:
+ return 0;
+}
+
/**
* nfs4_ff_layout_prepare_ds - prepare a DS connection for an RPC call
* @lseg: the layout segment we're operating on
--
2.17.1
[PATCH AUTOSEL 4.14 27/35] iommu/vt-d: Use memunmap to free memremap
From: Pan Bian
[ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
memunmap() should be used to free the return of memremap(), not
iounmap().
Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap')
Signed-off-by: Pan Bian
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index aaf3fed97477..e86c1c8ec7f6 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3086,7 +3086,7 @@ static int copy_context_table(struct intel_iommu *iommu,
}
if (old_ce)
- iounmap(old_ce);
+ memunmap(old_ce);
ret = 0;
if (devfn < 0x80)
--
2.17.1
[PATCH AUTOSEL 4.14 27/35] iommu/vt-d: Use memunmap to free memremap
From: Pan Bian
[ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
memunmap() should be used to free the return of memremap(), not
iounmap().
Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap')
Signed-off-by: Pan Bian
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index aaf3fed97477..e86c1c8ec7f6 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3086,7 +3086,7 @@ static int copy_context_table(struct intel_iommu *iommu,
}
if (old_ce)
- iounmap(old_ce);
+ memunmap(old_ce);
ret = 0;
if (devfn < 0x80)
--
2.17.1
[PATCH AUTOSEL 4.14 24/35] qed: Fix QM getters to always return a valid pq
From: Denis Bolotin
[ Upstream commit eb62cca9bee842e5b23bd0ddfb1f271ca95e8759 ]
The getter callers doesn't know the valid Physical Queues (PQ) values.
This patch makes sure that a valid PQ will always be returned.
The patch consists of 3 fixes:
- When qed_init_qm_get_idx_from_flags() receives a disabled flag, it
returned PQ 0, which can potentially be another function's pq. Verify
that flag is enabled, otherwise return default start_pq.
- When qed_init_qm_get_idx_from_flags() receives an unknown flag, it
returned NULL and could lead to a segmentation fault. Return default
start_pq instead.
- A modulo operation was added to MCOS/VFS PQ getters to make sure the
PQ returned is in range of the required flag.
Fixes: b5a9ee7cf3be ("qed: Revise QM cofiguration")
Signed-off-by: Denis Bolotin
Signed-off-by: Michal Kalderon
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 24 +++
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c
b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index a51cd1028ecb..16953c4ebd71 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -446,6 +446,11 @@ static u16 *qed_init_qm_get_idx_from_flags(struct qed_hwfn
*p_hwfn,
goto err;
}
+ if (!(qed_get_pq_flags(p_hwfn) & pq_flags)) {
+ DP_ERR(p_hwfn, "pq flag 0x%x is not set\n", pq_flags);
+ goto err;
+ }
+
switch (pq_flags) {
case PQ_FLAGS_RLS:
return _info->first_rl_pq;
@@ -468,8 +473,7 @@ static u16 *qed_init_qm_get_idx_from_flags(struct qed_hwfn
*p_hwfn,
}
err:
- DP_ERR(p_hwfn, "BAD pq flags %d\n", pq_flags);
- return NULL;
+ return _info->start_pq;
}
/* save pq index in qm info */
@@ -493,20 +497,32 @@ u16 qed_get_cm_pq_idx_mcos(struct qed_hwfn *p_hwfn, u8 tc)
{
u8 max_tc = qed_init_qm_get_num_tcs(p_hwfn);
+ if (max_tc == 0) {
+ DP_ERR(p_hwfn, "pq with flag 0x%lx do not exist\n",
+ PQ_FLAGS_MCOS);
+ return p_hwfn->qm_info.start_pq;
+ }
+
if (tc > max_tc)
DP_ERR(p_hwfn, "tc %d must be smaller than %d\n", tc, max_tc);
- return qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_MCOS) + tc;
+ return qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_MCOS) + (tc % max_tc);
}
u16 qed_get_cm_pq_idx_vf(struct qed_hwfn *p_hwfn, u16 vf)
{
u16 max_vf = qed_init_qm_get_num_vfs(p_hwfn);
+ if (max_vf == 0) {
+ DP_ERR(p_hwfn, "pq with flag 0x%lx do not exist\n",
+ PQ_FLAGS_VFS);
+ return p_hwfn->qm_info.start_pq;
+ }
+
if (vf > max_vf)
DP_ERR(p_hwfn, "vf %d must be smaller than %d\n", vf, max_vf);
- return qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_VFS) + vf;
+ return qed_get_cm_pq_idx(p_hwfn, PQ_FLAGS_VFS) + (vf % max_vf);
}
u16 qed_get_cm_pq_idx_rl(struct qed_hwfn *p_hwfn, u8 rl)
--
2.17.1
[PATCH AUTOSEL 4.14 18/35] gpio: mockup: fix indicated direction
From: Bartosz Golaszewski
[ Upstream commit bff466bac59994cfcceabe4d0be5fdc1c20cd5b8 ]
Commit 3edfb7bd76bd ("gpiolib: Show correct direction from the
beginning") fixed an existing issue but broke libgpiod tests by
changing the default direction of dummy lines to output.
We don't break user-space so make gpio-mockup behave as before.
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
---
drivers/gpio/gpio-mockup.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index 9532d86a82f7..d99c8d8da9a0 100644
--- a/drivers/gpio/gpio-mockup.c
+++ b/drivers/gpio/gpio-mockup.c
@@ -35,8 +35,8 @@
#define GPIO_MOCKUP_MAX_RANGES (GPIO_MOCKUP_MAX_GC * 2)
enum {
- GPIO_MOCKUP_DIR_OUT = 0,
- GPIO_MOCKUP_DIR_IN = 1,
+ GPIO_MOCKUP_DIR_IN = 0,
+ GPIO_MOCKUP_DIR_OUT = 1,
};
/*
@@ -112,7 +112,7 @@ static int gpio_mockup_get_direction(struct gpio_chip *gc,
unsigned int offset)
{
struct gpio_mockup_chip *chip = gpiochip_get_data(gc);
- return chip->lines[offset].dir;
+ return !chip->lines[offset].dir;
}
static int gpio_mockup_name_lines(struct device *dev,
--
2.17.1
[PATCH AUTOSEL 4.14 15/35] net/mlx4_core: Zero out lkey field in SW2HW_MPT fw command
From: Jack Morgenstein
[ Upstream commit bd85fbc2038a1bbe84990b23ff69b6fc81a32b2c ]
When re-registering a user mr, the mpt information for the
existing mr when running SRIOV is obtained via the QUERY_MPT
fw command. The returned information includes the mpt's lkey.
This retrieved mpt information is used to move the mpt back
to hardware ownership in the rereg flow (via the SW2HW_MPT
fw command when running SRIOV).
The fw API spec states that for SW2HW_MPT, the lkey field
must be zero. Any ConnectX-3 PF driver which checks for strict spec
adherence will return failure for SW2HW_MPT if the lkey field is not
zero (although the fw in practice ignores this field for SW2HW_MPT).
Thus, in order to conform to the fw API spec, set the lkey field to zero
before invoking SW2HW_MPT when running SRIOV.
Fixes: e630664c8383 ("mlx4_core: Add helper functions to support MR
re-registration")
Signed-off-by: Jack Morgenstein
Signed-off-by: Tariq Toukan
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/mellanox/mlx4/mr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mr.c
b/drivers/net/ethernet/mellanox/mlx4/mr.c
index c7c0764991c9..20043f82c1d8 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mr.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
@@ -363,6 +363,7 @@ int mlx4_mr_hw_write_mpt(struct mlx4_dev *dev, struct
mlx4_mr *mmr,
container_of((void *)mpt_entry, struct mlx4_cmd_mailbox,
buf);
+ (*mpt_entry)->lkey = 0;
err = mlx4_SW2HW_MPT(dev, mailbox, key);
}
--
2.17.1
[PATCH AUTOSEL 4.14 09/35] batman-adv: Expand merged fragment buffer for full packet
From: Sven Eckelmann
[ Upstream commit d7d8bbb40a5b1f682ee6589e212934f4c6b8ad60 ]
The complete size ("total_size") of the fragmented packet is stored in the
fragment header and in the size of the fragment chain. When the fragments
are ready for merge, the skbuff's tail of the first fragment is expanded to
have enough room after the data pointer for at least total_size. This means
that it gets expanded by total_size - first_skb->len.
But this is ignoring the fact that after expanding the buffer, the fragment
header is pulled by from this buffer. Assuming that the tailroom of the
buffer was already 0, the buffer after the data pointer of the skbuff is
now only total_size - len(fragment_header) large. When the merge function
is then processing the remaining fragments, the code to copy the data over
to the merged skbuff will cause an skb_over_panic when it tries to actually
put enough data to fill the total_size bytes of the packet.
The size of the skb_pull must therefore also be taken into account when the
buffer's tailroom is expanded.
Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge")
Reported-by: Martin Weinelt
Co-authored-by: Linus Lüssing
Signed-off-by: Sven Eckelmann
Signed-off-by: Simon Wunderlich
Signed-off-by: Sasha Levin
---
net/batman-adv/fragmentation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/fragmentation.c b/net/batman-adv/fragmentation.c
index b6abd19ab23e..c6d37d22bd12 100644
--- a/net/batman-adv/fragmentation.c
+++ b/net/batman-adv/fragmentation.c
@@ -274,7 +274,7 @@ batadv_frag_merge_packets(struct hlist_head *chain)
kfree(entry);
packet = (struct batadv_frag_packet *)skb_out->data;
- size = ntohs(packet->total_size);
+ size = ntohs(packet->total_size) + hdr_size;
/* Make room for the rest of the fragments. */
if (pskb_expand_head(skb_out, 0, size - skb_out->len, GFP_ATOMIC) < 0) {
--
2.17.1
[PATCH AUTOSEL 4.14 22/35] mtd: spi-nor: Fix Cadence QSPI page fault kernel panic
From: Thor Thayer
[ Upstream commit a6a66f80c85e8e20573ca03fabf32445954a88d5 ]
The current Cadence QSPI driver caused a kernel panic sporadically
when writing to QSPI. The problem was caused by writing more bytes
than needed because the QSPI operated on 4 bytes at a time.
[ 11.202044] Unable to handle kernel paging request at virtual address
bffd3000
[ 11.209254] pgd = e463054d
[ 11.211948] [bffd3000] *pgd=2fffb811, *pte=, *ppte=
[ 11.218202] Internal error: Oops: 7 [#1] SMP ARM
[ 11.222797] Modules linked in:
[ 11.225844] CPU: 1 PID: 1317 Comm: systemd-hwdb Not tainted
4.17.7-d0c45cd44a8f
[ 11.235796] Hardware name: Altera SOCFPGA Arria10
[ 11.240487] PC is at __raw_writesl+0x70/0xd4
[ 11.244741] LR is at cqspi_write+0x1a0/0x2cc
On a page boundary limit the number of bytes copied from the tx buffer
to remain within the page.
This patch uses a temporary buffer to hold the 4 bytes to write and then
copies only the bytes required from the tx buffer.
Reported-by: Adrian Amborzewicz
Signed-off-by: Thor Thayer
Signed-off-by: Boris Brezillon
Signed-off-by: Sasha Levin
---
drivers/mtd/spi-nor/cadence-quadspi.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 8d89204b90d2..f22dd34f4f83 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -625,9 +625,23 @@ static int cqspi_indirect_write_execute(struct spi_nor
*nor,
reg_base + CQSPI_REG_INDIRECTWR);
while (remaining > 0) {
+ size_t write_words, mod_bytes;
+
write_bytes = remaining > page_size ? page_size : remaining;
- iowrite32_rep(cqspi->ahb_base, txbuf,
- DIV_ROUND_UP(write_bytes, 4));
+ write_words = write_bytes / 4;
+ mod_bytes = write_bytes % 4;
+ /* Write 4 bytes at a time then single bytes. */
+ if (write_words) {
+ iowrite32_rep(cqspi->ahb_base, txbuf, write_words);
+ txbuf += (write_words * 4);
+ }
+ if (mod_bytes) {
+ unsigned int temp = 0x;
+
+ memcpy(, txbuf, mod_bytes);
+ iowrite32(temp, cqspi->ahb_base);
+ txbuf += mod_bytes;
+ }
ret = wait_for_completion_timeout(>transfer_complete,
msecs_to_jiffies
@@ -638,7 +652,6 @@ static int cqspi_indirect_write_execute(struct spi_nor *nor,
goto failwr;
}
- txbuf += write_bytes;
remaining -= write_bytes;
if (remaining > 0)
--
2.17.1
[PATCH AUTOSEL 4.14 21/35] HID: multitouch: Add pointstick support for Cirque Touchpad
From: Kai-Heng Feng
[ Upstream commit 12d43aacf9a74d0eb66fd0ea54ebeb79ca28940f ]
Cirque Touchpad/Pointstick combo is similar to Alps devices, it requires
MT_CLS_WIN_8_DUAL to expose its pointstick as a mouse.
Signed-off-by: Kai-Heng Feng
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin
---
drivers/hid/hid-ids.h| 3 +++
drivers/hid/hid-multitouch.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 87904d2adadb..fcc688df694c 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -266,6 +266,9 @@
#define USB_VENDOR_ID_CIDC 0x1677
+#define I2C_VENDOR_ID_CIRQUE 0x0488
+#define I2C_PRODUCT_ID_CIRQUE_121F 0x121F
+
#define USB_VENDOR_ID_CJTOUCH 0x24b8
#define USB_DEVICE_ID_CJTOUCH_MULTI_TOUCH_0020 0x0020
#define USB_DEVICE_ID_CJTOUCH_MULTI_TOUCH_0040 0x0040
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index c3b9bd5dba75..07d92d4a9f7c 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1474,6 +1474,12 @@ static const struct hid_device_id mt_devices[] = {
MT_USB_DEVICE(USB_VENDOR_ID_CHUNGHWAT,
USB_DEVICE_ID_CHUNGHWAT_MULTITOUCH) },
+ /* Cirque devices */
+ { .driver_data = MT_CLS_WIN_8_DUAL,
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ I2C_VENDOR_ID_CIRQUE,
+ I2C_PRODUCT_ID_CIRQUE_121F) },
+
/* CJTouch panels */
{ .driver_data = MT_CLS_NSMU,
MT_USB_DEVICE(USB_VENDOR_ID_CJTOUCH,
--
2.17.1
