Re: [PATCH v3] Add driver to force WMI Thunderbolt controller power status
On Thu, Sep 14, 2017 at 05:59:19PM +0300, Mika Westerberg wrote: > On Thu, Sep 14, 2017 at 02:52:27PM +, mario.limoncie...@dell.com wrote: > > > Looking at drivers/platform/x86/wmi.c:wmi_dev_uevent() it seems that > > > a modalias consisting of "wmi:" followed by the GUID is sent to udevd. > > > For udevd to then load the module, I suspect you need to add a > > > MODULE_DEVICE_TABLE(wmi, ...) to your driver. > > > > Ah, you're looking for this code from the WMI bus driver: > > https://github.com/torvalds/linux/blob/master/drivers/platform/x86/wmi.c#L724 > > > > That happens when the bus is initialized. > > That's right you get the uevent and whatnot but Lucas means that if you > don't have MODULE_DEVICE_TABLE(wmi, ...) in the driver, udev cannot load > the module automatically when the device appears. I meant to say Lukas, not Lucas. Sorry about that.
Re: [PATCH] mtd: spi-nor: stm32-quadspi: avoid unintialized return code
hi Arnd, Geert
On 09/14/2017 03:38 PM, Geert Uytterhoeven wrote:
Hi Arnd,
On Thu, Sep 14, 2017 at 1:06 PM, Arnd Bergmann wrote:
If we send zero-length data to stm32_qspi_tx_poll() on older
compiler versions such as gcc-4.6, we get warned that the
return code is uninitialized:
drivers/mtd/spi-nor/stm32-quadspi.c:248:2: error: ‘ret’ may be used
uninitialized in this function [-Werror=uninitialized]
On newer compiler versions, the return code is always zero
in this case, as the local variable gets optimized away and
is assumed to be zero after the loop completes without error.
This changes the function to instead return -EINVAL if it
ever gets called with a zero length buffer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82203
Signed-off-by: Arnd Bergmann
---
drivers/mtd/spi-nor/stm32-quadspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/stm32-quadspi.c
b/drivers/mtd/spi-nor/stm32-quadspi.c
index 86c0931543c5..711cfe7aa4bf 100644
--- a/drivers/mtd/spi-nor/stm32-quadspi.c
+++ b/drivers/mtd/spi-nor/stm32-quadspi.c
@@ -227,7 +227,7 @@ static int stm32_qspi_tx_poll(struct stm32_qspi *qspi,
void (*tx_fifo)(u8 *, void __iomem *);
u32 len = cmd->len, sr;
u8 *buf = cmd->buf;
- int ret;
+ int ret = -EINVAL;
if (cmd->qspimode == CCR_FMODE_INDW)
tx_fifo = stm32_qspi_write_fifo;
See also "[PATCH] mtd: spi-nor: stm32-quadspi: Fix uninitialized error
return code"
(https://patchwork.kernel.org/patch/9842173/)
hi Arnd, Geert
sorry, I was forgot this thread while my holidays
Geert: what do you mean like "similar bugs in the future" in "If you
initialized ret at the beginning, you lose the ability to catch newly
introduced similar bugs in the future."
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: kernel BUG at fs/ext4/fsync.c:LINE!
Hi GeneBlue, Thanks for this reporting, do you have any logs related to the bug and could find the syscalls enabled for fuzzing during triggering this bug? I do not think it is not reproducible, but first, it needs some inspections manually. - ChunYu On Thu, Sep 14, 2017 at 7:54 PM, GeneBlue wrote: > Hi: > I've got this crash when fuzzing linux kernel 4.13.0-rc7 on commit > 42ff72cf27027fa28dd79acabe01d9196f1480a7. Unfortunately this crash is not > reproducible. And this crash was found by syzkaller. > > > [ cut here ] > kernel BUG at fs/ext4/fsync.c:106! > invalid opcode: [#1] SMP KASAN > Dumping ftrace buffer: >(ftrace buffer empty) > Modules linked in: > CPU: 0 PID: 25424 Comm: syz-executor5 Not tainted 4.13.0-rc7+ #2 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 > task: 88003869 task.stack: 880024648000 > RIP: 0010:ext4_sync_file+0x7b6/0xfb0 fs/ext4/fsync.c:106 > RSP: 0018:88003ec07ae0 EFLAGS: 00010206 > RAX: 88003869 RBX: 8800239adaa0 RCX: dc00 > RDX: 0100 RSI: 1100070d21ff RDI: 880038690ff8 > RBP: 88003ec07b30 R08: dc00 R09: 11000cbf5730 > R10: dc00 R11: 11000cbf58f7 R12: 880065fab300 > R13: 88003dc36a80 R14: 880065fac400 R15: 88003869 > FS: 02188940() GS:88003ec0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7ffd1350fbb0 CR3: 2718d000 CR4: 06f0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0600 > Call Trace: > > vfs_fsync_range+0x10c/0x250 fs/sync.c:195 > generic_write_sync include/linux/fs.h:2625 [inline] > dio_complete+0x564/0x710 fs/direct-io.c:282 > dio_bio_end_aio+0x120/0x360 fs/direct-io.c:323 > bio_endio+0x1df/0x5d0 block/bio.c:1839 > req_bio_endio block/blk-core.c:204 [inline] > blk_update_request+0x210/0xd30 block/blk-core.c:2729 > scsi_end_request+0xa7/0x5b0 drivers/scsi/scsi_lib.c:634 > scsi_io_completion+0x73d/0x1430 drivers/scsi/scsi_lib.c:834 > scsi_finish_command+0x3e9/0x560 drivers/scsi/scsi.c:248 > scsi_softirq_done+0x2db/0x360 drivers/scsi/scsi_lib.c:1602 > blk_done_softirq+0x247/0x380 block/blk-softirq.c:36 > __do_softirq+0x23f/0x924 kernel/softirq.c:284 > invoke_softirq kernel/softirq.c:364 [inline] > irq_exit+0x1a7/0x1e0 kernel/softirq.c:405 > exiting_irq arch/x86/include/asm/apic.h:638 [inline] > do_IRQ+0x81/0x1a0 arch/x86/kernel/irq.c:256 > common_interrupt+0x93/0x93 arch/x86/entry/entry_64.S:482 > RIP: 0010:__ext4_handle_dirty_metadata+0x5d/0x5c0 fs/ext4/ext4_jbd2.c:275 > RSP: 0018:88002464f9d0 EFLAGS: 0297 ORIG_RAX: ffc1 > RAX: 88003869 RBX: 88003e4199d8 RCX: > RDX: RSI: 88003e4199d8 RDI: 88003869004c > RBP: 88002464fa18 R08: 0007 R09: dc00 > R10: 1100070d211c R11: R12: 8800381f95c0 > R13: R14: 00a0 R15: 141f > > ext4_do_update_inode fs/ext4/inode.c:5151 [inline] > ext4_mark_iloc_dirty+0x17e1/0x2980 fs/ext4/inode.c:5673 > ext4_orphan_del+0x711/0x930 fs/ext4/namei.c:2901 > ext4_evict_inode+0xe6b/0x1690 fs/ext4/inode.c:308 > evict+0x248/0x620 fs/inode.c:553 > iput_final fs/inode.c:1514 [inline] > iput+0x538/0x840 fs/inode.c:1541 > do_unlinkat+0x28b/0x640 fs/namei.c:4049 > SYSC_unlink fs/namei.c:4090 [inline] > SyS_unlink+0x1a/0x20 fs/namei.c:4088 > entry_SYSCALL_64_fastpath+0x1f/0xbe > RIP: 0033:0x447077 > RSP: 002b:7ffd135102e8 EFLAGS: 0206 ORIG_RAX: 0057 > RAX: ffda RBX: 0066 RCX: 00447077 > RDX: 7ffd13510300 RSI: 7ffd13510390 RDI: 7ffd13510390 > RBP: 0046 R08: R09: 0218acdb > R10: 0005 R11: 0206 R12: 004a8919 > R13: 7ffd13510218 R14: 0001 R15: 7ffd13510218 > Code: 8b 4d c0 41 f6 01 20 0f 85 1c 03 00 00 e8 f3 ae bb ff 48 8b 7d c0 44 > 89 e6 e8 37 76 13 00 41 89 c4 e9 dc fa ff ff e8 da ae bb ff <0f> 0b e8 d3 ae > bb ff 8b 4d d4 48 8b 55 b0 4c 89 ef 48 8b 75 b8 > RIP: ext4_sync_file+0x7b6/0xfb0 fs/ext4/fsync.c:106 RSP: 88003ec07ae0 > ---[ end trace 3049124842185959 ]--- > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.
Re: [PATCH v3] Add driver to force WMI Thunderbolt controller power status
On Thu, Sep 14, 2017 at 02:52:27PM +, mario.limoncie...@dell.com wrote: > > Looking at drivers/platform/x86/wmi.c:wmi_dev_uevent() it seems that > > a modalias consisting of "wmi:" followed by the GUID is sent to udevd. > > For udevd to then load the module, I suspect you need to add a > > MODULE_DEVICE_TABLE(wmi, ...) to your driver. > > Ah, you're looking for this code from the WMI bus driver: > https://github.com/torvalds/linux/blob/master/drivers/platform/x86/wmi.c#L724 > > That happens when the bus is initialized. That's right you get the uevent and whatnot but Lucas means that if you don't have MODULE_DEVICE_TABLE(wmi, ...) in the driver, udev cannot load the module automatically when the device appears.
Re: [PATCH] selftests/bpf: Make bpf_util work on uniprocessor systems
On 09/08/2017 05:05 PM, Daniel Borkmann wrote:
> On 09/09/2017 01:01 AM, Alexei Starovoitov wrote:
>> On Fri, Sep 08, 2017 at 01:19:23PM +0200, Thomas Meyer wrote:
>>> The current implementation fails to work on uniprocessor systems.
>>> Fix the parser to also handle the uniprocessor case.
>>>
>>> Signed-off-by: Thomas Meyer
>>
>> Thanks for the fix. lgtm
>> Acked-by: Alexei Starovoitov
>
> Looks good from here as well:
>
> Acked-by: Daniel Borkmann
>
>> This time it's ok to go via selftest tree, but next time please use
>> net-next/net
>> to avoid conflicts.
>
> +1
>
>> Thanks
Thank you. I will get this into 4.14-rc2 or rc3.
thanks,
-- Shuah
>>
>>> ---
>>> tools/testing/selftests/bpf/bpf_util.h | 17 +
>>> 1 file changed, 9 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/tools/testing/selftests/bpf/bpf_util.h
>>> b/tools/testing/selftests/bpf/bpf_util.h
>>> index 20ecbaa0d85d..6c53a8906eff 100644
>>> --- a/tools/testing/selftests/bpf/bpf_util.h
>>> +++ b/tools/testing/selftests/bpf/bpf_util.h
>>> @@ -12,6 +12,7 @@ static inline unsigned int bpf_num_possible_cpus(void)
>>> unsigned int start, end, possible_cpus = 0;
>>> char buff[128];
>>> FILE *fp;
>>> +int n;
>>>
>>> fp = fopen(fcpu, "r");
>>> if (!fp) {
>>> @@ -20,17 +21,17 @@ static inline unsigned int bpf_num_possible_cpus(void)
>>> }
>>>
>>> while (fgets(buff, sizeof(buff), fp)) {
>>> -if (sscanf(buff, "%u-%u", &start, &end) == 2) {
>>> -possible_cpus = start == 0 ? end + 1 : 0;
>>> -break;
>>> +n = sscanf(buff, "%u-%u", &start, &end);
>>> +if (n == 0) {
>>> +printf("Failed to retrieve # possible CPUs!\n");
>>> +exit(1);
>>> +} else if (n == 1) {
>>> +end = start;
>>> }
>>> +possible_cpus = start == 0 ? end + 1 : 0;
>>> +break;
>>> }
>>> -
>>> fclose(fp);
>>> -if (!possible_cpus) {
>>> -printf("Failed to retrieve # possible CPUs!\n");
>>> -exit(1);
>>> -}
>>>
>>> return possible_cpus;
>>> }
>>> --
>>> 2.11.0
>>>
>
>
>
Re: [PATCH] net: phy: Fix mask value write on gmii2rgmii converter speed register.
On Thu, Sep 14, 2017 at 12:46:31PM +0530, Fahad Kunnathadi wrote:
> To clear Speed Selection in MDIO control register(0x10),
> ie, clear bits 6 and 13 to zero while keeping other bits same.
> Before AND operation,The Mask value has to be perform with bitwise NOT
> operation (ie, ~ operator)
>
> This patch clears current speed selection before writing the
> new speed settings to gmii2rgmii converter
Hi Fahad
I expect you will find other issues with this driver. I pointed some
out at the time it is submitted, but the developers went quiet as soon
as it was accepted.
Anyway, please ensure David Miller gets a copy.
The subject line should be:
[PATCH net] net: phy: Fix mask value write on gmii2rgmii converter speed
register.
and include a fixes tag:
Fixes: f411a6160bd4 ("net: phy: Add gmiitorgmii converter support")
Reviewed-by: Andrew Lunn
Andrew
Re: [PATCH 2/3] selftests/intel_pstate: No need to compile test progs in the run script
On 09/08/2017 06:01 AM, Thomas Meyer wrote:
> Both test programs are being compiled by make, so no need to compile both
> programs in the runner script.
> This resolves an error when installing all selftests via make install
> and run them in a different environemnt.
>
> Running tests in intel_pstate
>
> ./run.sh: line 35: gcc: command not found
> Problem compiling aperf.c.
>
> Signed-off-by: Thomas Meyer
> ---
> tools/testing/selftests/intel_pstate/run.sh | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/tools/testing/selftests/intel_pstate/run.sh
> b/tools/testing/selftests/intel_pstate/run.sh
> index 7868c106b8b1..96878e44f465 100755
> --- a/tools/testing/selftests/intel_pstate/run.sh
> +++ b/tools/testing/selftests/intel_pstate/run.sh
> @@ -31,12 +31,6 @@ EVALUATE_ONLY=0
>
> max_cpus=$(($(nproc)-1))
>
> -# compile programs
> -gcc aperf.c -Wall -D_GNU_SOURCE -o aperf -lm
> -[ $? -ne 0 ] && echo "Problem compiling aperf.c." && exit 1
> -gcc -o msr msr.c -lm
> -[ $? -ne 0 ] && echo "Problem compiling msr.c." && exit 1
> -
> function run_test () {
>
> file_ext=$1
>
Thanks for the patch. I will get this into 4.14-rc2 or rc3
thanks,
-- Shuah
Re: [PATCH 1/3] selftests/ftrace: multiple_kprobes: Also check for support
On 09/08/2017 06:01 AM, Thomas Meyer wrote: > The multiple_kprobes test case fails to check for KPROBE_EVENT support. > Add the check to prevent a false test result. > > Signed-off-by: Thomas Meyer > --- > tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc > b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc > index 2a1cb9908746..a4fd4c851a5b 100644 > --- a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc > +++ b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc > @@ -1,6 +1,8 @@ > #!/bin/sh > # description: Register/unregister many kprobe events > > +[ -f kprobe_events ] || exit_unsupported # this is configurable > + > # ftrace fentry skip size depends on the machine architecture. > # Currently HAVE_KPROBES_ON_FTRACE defined on x86 and powerpc64le > case `uname -m` in > Hi Steve/Masami, This patch looks good to me. Adds a check similar to the one one in tools/testing/selftests/ftrace/test.d/kprobe/functions If you don't have objections, I will get this into 4.14-rc2 or rc3 thanks, -- Shuah
[GIT PULL] Kbuild updates for v4.14
Hi Linus, Here are Kbuild updates for v4.14. Please pull! The following changes since commit aae4e7a8bc44722fe70d58920a36916b1043195e: Linux 4.13-rc4 (2017-08-06 18:44:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git tags/kbuild-v4.14 for you to fetch changes up to 77780f799e66cd261746a281dbbef1ee0c6997cd: kbuild: buildtar: do not print successful message if tar returns error (2017-09-13 00:20:33 +0900) Kbuild updates for v4.14 - Use Make-builtin $(abspath ...) helper to get absolute path - Add W=2 extra warning option to detect unused macros - Use more KCONFIG_CONFIG instead hard-coded .config - Fix bugs of tar*-pkg targets Johannes Thumshirn (1): Kbuild: enable -Wunused-macros warning for "make W=2" Masahiro Yamada (3): kbuild: use $(abspath ...) instead of $(shell cd ... && /bin/pwd) kbuild: buildtar: fix tar error when CONFIG_MODULES is disabled kbuild: buildtar: do not print successful message if tar returns error Nicolas Porcel (1): kbuild: Use KCONFIG_CONFIG in buildtar Makefile | 12 ++-- scripts/Makefile.extrawarn | 1 + scripts/gdb/linux/Makefile | 2 +- scripts/package/buildtar | 36 +--- tools/power/cpupower/Makefile | 2 +- tools/scripts/Makefile.include | 6 +++--- 6 files changed, 29 insertions(+), 30 deletions(-) -- Best Regards Masahiro Yamada
Re: usb/uwb: WARNING in hwarc_neep_init/usb_submit_urb
On Wed, Sep 13, 2017 at 4:59 PM, Alan Stern wrote: > On Wed, 13 Sep 2017, Dmitry Vyukov wrote: > >> On Tue, Sep 12, 2017 at 9:57 PM, Greg Kroah-Hartman >> wrote: >> > On Tue, Sep 12, 2017 at 08:53:11PM +0200, Andrey Konovalov wrote: >> >> Hi! >> >> >> >> I've got the following crash while fuzzing the kernel with syzkaller. >> >> >> >> On commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432 (Sep 3). >> >> >> >> gadgetfs: bound to dummy_udc driver >> >> usb 1-1: new full-speed USB device number 2 using dummy_hcd >> >> gadgetfs: connected >> >> gadgetfs: disconnected >> >> gadgetfs: connected >> >> usb 1-1: New USB device found, idVendor=, idProduct= >> >> usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=203 >> >> usb 1-1: SerialNumber: a >> >> gadgetfs: configuration #7 >> >> usb 1-1: BOGUS urb xfer, pipe 1 != type 3 >> >> [ cut here ] >> >> WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 >> >> usb_submit_urb+0xf8a/0x11d0 >> >> Modules linked in: >> >> CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #111 >> >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs >> >> 01/01/2011 >> >> Workqueue: usb_hub_wq hub_event >> >> task: 88006bdc1a00 task.stack: 88006bde8000 >> >> RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448 >> >> RSP: 0018:88006bdee3c0 EFLAGS: 00010282 >> >> RAX: 0029 RBX: 8800672a7200 RCX: >> >> RDX: 0029 RSI: 88006c815c78 RDI: ed000d7bdc6a >> >> RBP: 88006bdee4c0 R08: fbfff0fe00ff R09: fbfff0fe00ff >> >> R10: 0018 R11: fbfff0fe00fe R12: 11000d7bdc7f >> >> R13: 0003 R14: 0001 R15: 88006b02cc90 >> >> FS: () GS:88006c80() >> >> knlGS: >> >> CS: 0010 DS: ES: CR0: 80050033 >> >> CR2: 7fe4daddf000 CR3: 6add6000 CR4: 06f0 >> >> Call Trace: >> >> hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710 >> >> uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361 >> >> hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858 >> >> usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361 >> >> really_probe drivers/base/dd.c:385 >> >> driver_probe_device+0x610/0xa00 drivers/base/dd.c:529 >> >> __device_attach_driver+0x230/0x290 drivers/base/dd.c:625 >> >> bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463 >> >> __device_attach+0x269/0x3c0 drivers/base/dd.c:682 >> >> device_initial_probe+0x1f/0x30 drivers/base/dd.c:729 >> >> bus_probe_device+0x1da/0x280 drivers/base/bus.c:523 >> >> device_add+0xcf9/0x1640 drivers/base/core.c:1703 >> >> usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932 >> >> generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174 >> >> usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266 >> >> really_probe drivers/base/dd.c:385 >> >> driver_probe_device+0x610/0xa00 drivers/base/dd.c:529 >> >> __device_attach_driver+0x230/0x290 drivers/base/dd.c:625 >> >> bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463 >> >> __device_attach+0x269/0x3c0 drivers/base/dd.c:682 >> >> device_initial_probe+0x1f/0x30 drivers/base/dd.c:729 >> >> bus_probe_device+0x1da/0x280 drivers/base/bus.c:523 >> >> device_add+0xcf9/0x1640 drivers/base/core.c:1703 >> >> usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457 >> >> hub_port_connect drivers/usb/core/hub.c:4890 >> >> hub_port_connect_change drivers/usb/core/hub.c:4996 >> >> port_event drivers/usb/core/hub.c:5102 >> >> hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182 >> >> process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097 >> >> worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231 >> >> kthread+0x324/0x3f0 kernel/kthread.c:231 >> >> ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425 >> >> Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89 >> >> e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f> >> >> ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6 >> >> ---[ end trace 55d741234124cfc3 ]--- >> > >> > It's a WARN_ON(), here, not really a "problem", right? You are trying >> > to fuzz the drivers by giving it crappy descriptors, and you triggered a >> > valid warning from the kernel notifying you that your "hardware" is >> > really an invalid USB device :) >> > >> > So nothing to really "fix" here, this is "working as expected", right? >> >> >> WARNING means bug in kernel source code that kernel can tolerate (as >> opposed to BUG). >> Invalid inputs to kernel should not trigger WARNINGs nor BUGs. The >> stack is pointless here, the registers are pointless, what's relevant >> here is: >> >> usb 1-1: BOGUS urb xfer, pipe 1 != type 3 >> >> And this looks like enough information (can be extended if there are >> some other relevant values). >> WARNINGs on invalid inputs cause local DoS, does not allow any testing >> automation and cause spam for kernel developers (what do you do w
Re: [RFC Part2 PATCH v3 25/26] KVM: SVM: Do not install #UD intercept when SEV is enabled
On Mon, Jul 24, 2017 at 03:03:02PM -0500, Brijesh Singh wrote:
> On #UD, x86_emulate_instruction() fetches the data from guest memory and
> decodes the instruction bytes to assist further. When SEV is enabled, the
> instruction bytes will be encrypted using the guest-specific key, hypervisor
"... key and the
hypervisor... "
> will no longer able to fetch the instruction bytes to assist UD handling.
> By not installing intercept we let the guest receive and handle #UD.
>
> Signed-off-by: Brijesh Singh
> ---
> arch/x86/kvm/svm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 64b9f60..4581d03 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -1432,8 +1432,10 @@ static void init_vmcb(struct vcpu_svm *svm)
> svm->vmcb->control.virt_ext |=
> VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK;
> }
>
> - if (sev_guest(svm->vcpu.kvm))
> + if (sev_guest(svm->vcpu.kvm)) {
> svm->vmcb->control.nested_ctl |= SVM_NESTED_CTL_SEV_ENABLE;
> + clr_exception_intercept(svm, UD_VECTOR);
> + }
>
> mark_all_dirty(svm->vmcb);
>
> --
Otherwise:
Reviewed-by: Borislav Petkov
Btw, if this is really important for the hypervisor to continue to be
able to do decode assist, we probably should think about having the
guest give the hypervisor the couple instruction bytes in a controlled
manner...
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
RE: [PATCH v3] Add driver to force WMI Thunderbolt controller power status
> -Original Message-
> From: Lukas Wunner [mailto:lu...@wunner.de]
> Sent: Thursday, September 14, 2017 4:14 AM
> To: Limonciello, Mario
> Cc: dvh...@infradead.org; linux-kernel@vger.kernel.org; platform-driver-
> x...@vger.kernel.org; hughsi...@gmail.com; yehezkel...@gmail.com;
> mika.westerb...@linux.intel.com
> Subject: Re: [PATCH v3] Add driver to force WMI Thunderbolt controller power
> status
>
> On Thu, Sep 14, 2017 at 06:42:03AM +, mario.limoncie...@dell.com wrote:
> > > On Fri, Sep 08, 2017 at 10:23:11AM -0500, Mario Limonciello wrote:
> > > > +static const struct wmi_device_id intel_wmi_thunderbolt_id_table[] = {
> > > > + { .guid_string = INTEL_WMI_THUNDERBOLT_GUID },
> > > > + { },
> > > > +};
> > >
> > > I'm not familiar with WMI, but don't you need a MODULE_DEVICE_TABLE here?
> > > How does user space know which module to load upon receiving the uevent?
> >
> > Some macros for WMI bus devices.
> >
> https://github.com/torvalds/linux/blob/e0f25a3f2d052e36ff67a9b4db835c3e27e9
> 50d8/include/linux/wmi.h#L55
> > https://github.com/torvalds/linux/blob/master/include/linux/device.h#L1487
>
> No, the init and exit hooks defined by this macro are executed
> *after* the module has been loaded. The question was, how does
> the module get loaded in the first place?
>
> Looking at drivers/platform/x86/wmi.c:wmi_dev_uevent() it seems that
> a modalias consisting of "wmi:" followed by the GUID is sent to udevd.
> For udevd to then load the module, I suspect you need to add a
> MODULE_DEVICE_TABLE(wmi, ...) to your driver.
Ah, you're looking for this code from the WMI bus driver:
https://github.com/torvalds/linux/blob/master/drivers/platform/x86/wmi.c#L724
That happens when the bus is initialized.
[PATCH] ocfs2: remove some redundant assignments
From: Colin Ian King The initialization of free_space is redundant as free_space is updated later on and the initialized value is hence never used. The pointer new_list is set but never used so it can be completely removed. Cleans up clang scan-build warnings. "Value stored to 'free_space' during its initialization is never read" "Value stored to 'new_list' is never read" Signed-off-by: Colin Ian King --- fs/ocfs2/dir.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c index febe6312ceff..fe7e8653f4a9 100644 --- a/fs/ocfs2/dir.c +++ b/fs/ocfs2/dir.c @@ -3371,7 +3371,7 @@ static int ocfs2_find_dir_space_id(struct inode *dir, struct buffer_head *di_bh, struct ocfs2_dir_entry *de, *last_de = NULL; char *de_buf, *limit; unsigned long offset = 0; - unsigned int rec_len, new_rec_len, free_space = dir->i_sb->s_blocksize; + unsigned int rec_len, new_rec_len, free_space; /* * This calculates how many free bytes we'd have in block zero, should @@ -3662,7 +3662,7 @@ static void ocfs2_dx_dir_transfer_leaf(struct inode *dir, u32 split_hash, int i, j, num_used; u32 major_hash; struct ocfs2_dx_leaf *orig_dx_leaf, *new_dx_leaf; - struct ocfs2_dx_entry_list *orig_list, *new_list, *tmp_list; + struct ocfs2_dx_entry_list *orig_list, *tmp_list; struct ocfs2_dx_entry *dx_entry; tmp_list = &tmp_dx_leaf->dl_list; @@ -3671,7 +3671,6 @@ static void ocfs2_dx_dir_transfer_leaf(struct inode *dir, u32 split_hash, orig_dx_leaf = (struct ocfs2_dx_leaf *) orig_dx_leaves[i]->b_data; orig_list = &orig_dx_leaf->dl_list; new_dx_leaf = (struct ocfs2_dx_leaf *) new_dx_leaves[i]->b_data; - new_list = &new_dx_leaf->dl_list; num_used = le16_to_cpu(orig_list->de_num_used); -- 2.14.1
[PATCH v4 3/6] iio: adc: sun4i-gpadc-iio: rework code for supporting newer THS variants
The SoCs after H3 has newer thermal sensor ADCs, which have two clock
inputs (bus clock and sampling clock) and a reset. The registers are
also re-arranged.
This commit reworks the code, adds the process of the clocks and
resets, and allows the sampling start/end code and the position of value
readout register to be altered.
Signed-off-by: Icenowy Zheng
---
drivers/iio/adc/sun4i-gpadc-iio.c | 123 +++---
1 file changed, 116 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
b/drivers/iio/adc/sun4i-gpadc-iio.c
index 68926b986cd0..97845982d050 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -22,6 +22,7 @@
* shutdown for not being used.
*/
+#include
#include
#include
#include
@@ -31,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -49,6 +51,15 @@ static unsigned int sun6i_gpadc_chan_select(unsigned int
chan)
return SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
}
+struct sun4i_gpadc_iio;
+
+/*
+ * Prototypes for these functions, which enable these functions to be
+ * referenced in gpadc_data structures.
+ */
+static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info);
+static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info);
+
struct gpadc_data {
int temp_offset;
int temp_scale;
@@ -56,6 +67,12 @@ struct gpadc_data {
unsigned inttp_adc_select;
unsigned int(*adc_chan_select)(unsigned int chan);
unsigned intadc_chan_mask;
+ unsigned inttemp_data;
+ int (*sample_start)(struct sun4i_gpadc_iio *info);
+ int (*sample_end)(struct sun4i_gpadc_iio *info);
+ boolhas_bus_clk;
+ boolhas_bus_rst;
+ boolhas_mod_clk;
};
static const struct gpadc_data sun4i_gpadc_data = {
@@ -65,6 +82,9 @@ static const struct gpadc_data sun4i_gpadc_data = {
.tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = &sun4i_gpadc_chan_select,
.adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
+ .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .sample_start = sun4i_gpadc_sample_start,
+ .sample_end = sun4i_gpadc_sample_end,
};
static const struct gpadc_data sun5i_gpadc_data = {
@@ -74,6 +94,9 @@ static const struct gpadc_data sun5i_gpadc_data = {
.tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = &sun4i_gpadc_chan_select,
.adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
+ .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .sample_start = sun4i_gpadc_sample_start,
+ .sample_end = sun4i_gpadc_sample_end,
};
static const struct gpadc_data sun6i_gpadc_data = {
@@ -83,12 +106,18 @@ static const struct gpadc_data sun6i_gpadc_data = {
.tp_adc_select = SUN6I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = &sun6i_gpadc_chan_select,
.adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
+ .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .sample_start = sun4i_gpadc_sample_start,
+ .sample_end = sun4i_gpadc_sample_end,
};
static const struct gpadc_data sun8i_a33_gpadc_data = {
.temp_offset = -1662,
.temp_scale = 162,
.tp_mode_en = SUN8I_A33_GPADC_CTRL1_CHOP_TEMP_EN,
+ .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .sample_start = sun4i_gpadc_sample_start,
+ .sample_end = sun4i_gpadc_sample_end,
};
struct sun4i_gpadc_iio {
@@ -103,6 +132,9 @@ struct sun4i_gpadc_iio {
atomic_tignore_temp_data_irq;
const struct gpadc_data *data;
boolno_irq;
+ struct clk *bus_clk;
+ struct clk *mod_clk;
+ struct reset_control*reset;
/* prevents concurrent reads of temperature and ADC */
struct mutexmutex;
struct thermal_zone_device *tzd;
@@ -277,7 +309,7 @@ static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev,
int *val)
if (info->no_irq) {
pm_runtime_get_sync(indio_dev->dev.parent);
- regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
+ regmap_read(info->regmap, info->data->temp_data, val);
pm_runtime_mark_last_busy(indio_dev->dev.parent);
pm_runtime_put_autosuspend(indio_dev->dev.parent);
@@ -383,10 +415,8 @@ static irqreturn_t sun4i_gpadc_fifo_data_irq_handler(int
irq, void *dev_id)
return IRQ_HANDLED;
}
-static int sun4i_gpadc_runtime_suspend(struct device *dev)
+static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info)
{
- struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
-
/* Disable the ADC on IP */
regmap_write(info->regmap, SUN4I_GPADC_CTRL1, 0);
/* Disable temperature sensor on IP */
@@ -395,10 +425,15 @
[PATCH v4 4/6] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor
This adds support for the Allwinner H3 thermal sensor.
Allwinner H3 has a thermal sensor like the one in A33, but have its
registers nearly all re-arranged, sample clock moved to CCU and a pair
of bus clock and reset added. It's also the base of newer SoCs' thermal
sensors.
The thermal sensors on A64 and H5 is like the one on H3, but with of
course different formula factors.
Signed-off-by: Icenowy Zheng
---
Changes in v4:
- Splitted out some code refactors.
- Code sequence changed back. (The gpadc_data went back to the start of
the source file)
drivers/iio/adc/sun4i-gpadc-iio.c | 48 +++
include/linux/mfd/sun4i-gpadc.h | 27 ++
2 files changed, 75 insertions(+)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
b/drivers/iio/adc/sun4i-gpadc-iio.c
index 97845982d050..f7e4df6bd17a 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -59,6 +59,8 @@ struct sun4i_gpadc_iio;
*/
static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info);
static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info);
+static int sun8i_h3_gpadc_sample_start(struct sun4i_gpadc_iio *info);
+static int sun8i_h3_gpadc_sample_end(struct sun4i_gpadc_iio *info);
struct gpadc_data {
int temp_offset;
@@ -120,6 +122,24 @@ static const struct gpadc_data sun8i_a33_gpadc_data = {
.sample_end = sun4i_gpadc_sample_end,
};
+static const struct gpadc_data sun8i_h3_gpadc_data = {
+ /*
+* The original formula on the datasheet seems to be wrong.
+* These factors are calculated based on the formula in the BSP
+* kernel, which is originally Tem = 217 - (T / 8.253), in which Tem
+* is the temperature in Celsius degree and T is the raw value
+* from the sensor.
+*/
+ .temp_offset = -1791,
+ .temp_scale = -121,
+ .temp_data = SUN8I_H3_GPADC_TEMP_DATA,
+ .sample_start = sun8i_h3_gpadc_sample_start,
+ .sample_end = sun8i_h3_gpadc_sample_end,
+ .has_bus_clk = true,
+ .has_bus_rst = true,
+ .has_mod_clk = true,
+};
+
struct sun4i_gpadc_iio {
struct iio_dev *indio_dev;
struct completion completion;
@@ -425,6 +445,14 @@ static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio
*info)
return 0;
}
+static int sun8i_h3_gpadc_sample_end(struct sun4i_gpadc_iio *info)
+{
+ /* Disable temperature sensor */
+ regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL2, 0);
+
+ return 0;
+}
+
static int sun4i_gpadc_runtime_suspend(struct device *dev)
{
struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
@@ -451,6 +479,22 @@ static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio
*info)
return 0;
}
+static int sun8i_h3_gpadc_sample_start(struct sun4i_gpadc_iio *info)
+{
+ regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL2,
+SUN8I_H3_GPADC_CTRL2_TEMP_SENSE_EN |
+SUN8I_H3_GPADC_CTRL2_T_ACQ1(31));
+ regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
+SUN4I_GPADC_CTRL0_T_ACQ(31));
+ regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL3,
+SUN4I_GPADC_CTRL3_FILTER_EN |
+SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
+ regmap_write(info->regmap, SUN8I_H3_GPADC_INTC,
+SUN8I_H3_GPADC_INTC_TEMP_PERIOD(800));
+
+ return 0;
+}
+
static int sun4i_gpadc_runtime_resume(struct device *dev)
{
struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
@@ -537,6 +581,10 @@ static const struct of_device_id sun4i_gpadc_of_id[] = {
.compatible = "allwinner,sun8i-a33-ths",
.data = &sun8i_a33_gpadc_data,
},
+ {
+ .compatible = "allwinner,sun8i-h3-ths",
+ .data = &sun8i_h3_gpadc_data,
+ },
{ /* sentinel */ }
};
diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
index 78d31984a222..5c2a12101052 100644
--- a/include/linux/mfd/sun4i-gpadc.h
+++ b/include/linux/mfd/sun4i-gpadc.h
@@ -42,6 +42,9 @@
#define SUN8I_A33_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
#define SUN8I_A33_GPADC_CTRL1_GPADC_CALI_ENBIT(7)
+/* TP_CTRL1 bits for SoCs after H3 */
+#define SUN8I_H3_GPADC_CTRL1_GPADC_CALI_EN BIT(17)
+
#define SUN4I_GPADC_CTRL2 0x08
#define SUN4I_GPADC_CTRL2_TP_SENSITIVE_ADJUST(x) ((GENMASK(3, 0) & (x))
<< 28)
@@ -49,7 +52,17 @@
#define SUN4I_GPADC_CTRL2_PRE_MEA_EN BIT(24)
#define SUN4I_GPADC_CTRL2_PRE_MEA_THRE_CNT(x) (GENMASK(23, 0) & (x))
+#define SUN8I_H3_GPADC_CTRL2 0x40
+
+#define SUN8I_H3_GPADC_CTRL2_TEMP_SENSE_EN BIT(0)
+#define SUN8I_H3_GPADC_CTRL2_T_ACQ1(x) ((GENMASK(15, 0) * (x))
<< 16)
+
#define SUN4I_GPADC_CTRL3 0x0c
[PATCH] uwb: ensure that endpoint is interrupt
hwarc_neep_init() assumes that endpoint 0 is interrupt, but there's no check for that, which results in a WARNING in USB core code, when a bad USB descriptor is provided from a device: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 [ cut here ] WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0 Modules linked in: CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #111 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event task: 88006bdc1a00 task.stack: 88006bde8000 RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448 RSP: 0018:88006bdee3c0 EFLAGS: 00010282 RAX: 0029 RBX: 8800672a7200 RCX: RDX: 0029 RSI: 88006c815c78 RDI: ed000d7bdc6a RBP: 88006bdee4c0 R08: fbfff0fe00ff R09: fbfff0fe00ff R10: 0018 R11: fbfff0fe00fe R12: 11000d7bdc7f R13: 0003 R14: 0001 R15: 88006b02cc90 FS: () GS:88006c80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fe4daddf000 CR3: 6add6000 CR4: 06f0 Call Trace: hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710 uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361 hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858 usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:385 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463 __device_attach+0x269/0x3c0 drivers/base/dd.c:682 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523 device_add+0xcf9/0x1640 drivers/base/core.c:1703 usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266 really_probe drivers/base/dd.c:385 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463 __device_attach+0x269/0x3c0 drivers/base/dd.c:682 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523 device_add+0xcf9/0x1640 drivers/base/core.c:1703 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457 hub_port_connect drivers/usb/core/hub.c:4890 hub_port_connect_change drivers/usb/core/hub.c:4996 port_event drivers/usb/core/hub.c:5102 hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231 kthread+0x324/0x3f0 kernel/kthread.c:231 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425 Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89 e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f> ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6 ---[ end trace 55d741234124cfc3 ]--- Check that endpoint is interrupt. Found by syzkaller. Signed-off-by: Andrey Konovalov --- drivers/uwb/hwa-rc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/uwb/hwa-rc.c b/drivers/uwb/hwa-rc.c index 35a1e777b449..9a53912bdfe9 100644 --- a/drivers/uwb/hwa-rc.c +++ b/drivers/uwb/hwa-rc.c @@ -825,6 +825,8 @@ static int hwarc_probe(struct usb_interface *iface, if (iface->cur_altsetting->desc.bNumEndpoints < 1) return -ENODEV; + if (!usb_endpoint_xfer_int(&iface->cur_altsetting->endpoint[0].desc)) + return -ENODEV; result = -ENOMEM; uwb_rc = uwb_rc_alloc(); -- 2.14.1.690.gbb1197296e-goog
[PATCH v4 5/6] ARM: sun8i: h3: add support for the thermal sensor in H3
As we have gained the support for the thermal sensor in H3, we can now
add its device nodes to the device tree.
Add them to the H3 device tree.
The calibration data of the thermal sensor is still not added, as
it's currently not used, and the SID node is not added yet.
The H5 thermal sensor has some differences, and will be added furtherly.
Signed-off-by: Icenowy Zheng
Reviewed-by: Chen-Yu Tsai
---
Changes in v4:
- Mention calibration data in commit message.
Changes in v3:
- Clock name changes.
- Splited out thermal zone addition.
arch/arm/boot/dts/sun8i-h3.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index b36f9f423c39..3220da3ad790 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -72,6 +72,23 @@
};
};
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&ths>;
+ };
+
+ soc {
+ ths: thermal-sensor@1c25000 {
+ compatible = "allwinner,sun8i-h3-ths";
+ reg = <0x01c25000 0x100>;
+ clocks = <&ccu CLK_BUS_THS>, <&ccu CLK_THS>;
+ clock-names = "bus", "mod";
+ resets = <&ccu RST_BUS_THS>;
+ #thermal-sensor-cells = <0>;
+ #io-channel-cells = <0>;
+ };
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
--
2.13.5
[PATCH v4 6/6] ARM: sun8i: h3: add partial CPU thermal zone
Because of the restriction of the OF thermal framework, the thermal
sensor will fail to probe if the thermal zone doesn't exist.
Add a partial thermal zone which claims the H3 THS as the thermal sensor.
The cooling device (CPU DVFS) is still not added as it's not ready, and
the trip points are also not added yet.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-h3.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 3220da3ad790..687c6457d214 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -89,6 +89,15 @@
};
};
+ thermal-zones {
+ cpu-thermal {
+ /* milliseconds */
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&ths>;
+ };
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
--
2.13.5
[PATCH v4 1/6] dt-bindings: update the Allwinner GPADC device tree binding for H3
Allwinner H3 features a thermal sensor like the one in A33, but has its
register re-arranged, the clock divider moved to CCU (originally the
clock divider is in ADC) and added a pair of bus clock and reset.
Update the binding document to cover H3.
Signed-off-by: Icenowy Zheng
Reviewed-by: Chen-Yu Tsai
---
Changes in v4:
- Add nvmem calibration data (not yet used by the driver)
Changes in v3:
- Clock name changes.
- Example node name changes.
- Add interupts (not yet used by the driver).
.../devicetree/bindings/mfd/sun4i-gpadc.txt| 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
index badff3611a98..6c470d584bf9 100644
--- a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
+++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
@@ -4,12 +4,26 @@ The Allwinner SoCs all have an ADC that can also act as a
thermal sensor
and sometimes as a touchscreen controller.
Required properties:
- - compatible: "allwinner,sun8i-a33-ths",
+ - compatible: must contain one of the following compatibles:
+ - "allwinner,sun8i-a33-ths"
+ - "allwinner,sun8i-h3-ths"
- reg: mmio address range of the chip,
- #thermal-sensor-cells: shall be 0,
- #io-channel-cells: shall be 0,
-Example:
+Optional properties:
+ - nvmem-cells: A phandle to the calibration data provided by a nvmem device.
+ If unspecified default values shall be used.
+ - nvmem-cell-names: Should be "calibration-data"
+
+Required properties for the following compatibles:
+ - "allwinner,sun8i-h3-ths"
+ - clocks: the bus clock and the input clock of the ADC,
+ - clock-names: should be "bus" and "mod",
+ - resets: the bus reset of the ADC,
+ - interrupts: the sampling interrupt of the ADC,
+
+Example for A33:
ths: ths@01c25000 {
compatible = "allwinner,sun8i-a33-ths";
reg = <0x01c25000 0x100>;
@@ -17,6 +31,18 @@ Example:
#io-channel-cells = <0>;
};
+Example for H3:
+ ths: thermal-sensor@1c25000 {
+ compatible = "allwinner,sun8i-h3-ths";
+ reg = <0x01c25000 0x400>;
+ clocks = <&ccu CLK_BUS_THS>, <&ccu CLK_THS>;
+ clock-names = "bus", "mod";
+ resets = <&ccu RST_BUS_THS>;
+ interrupts = ;
+ #thermal-sensor-cells = <0>;
+ #io-channel-cells = <0>;
+ };
+
sun4i, sun5i and sun6i SoCs are also supported via the older binding:
sun4i resistive touchscreen controller
--
2.13.5
[PATCH v4 2/6] iio: adc: sun4i-gpadc-iio: rename A33-specified registers to contain A33
As the H3 SoC, which is also in sun8i line, has totally different
register map for the thermal sensor (a cut down version of GPADC), we
should rename A23/A33-specified registers to contain A33, in order to
prevent obfuscation with H3 registers. Currently these registers are
only prefixed "SUN8I", not "SUN8I_A33".
Add "_A33" after "SUN8I" on the register names.
Signed-off-by: Icenowy Zheng
Reviewed-by: Chen-Yu Tsai
---
Changes in v4:
- Change A23 to A33, as the driver never supports A23.
drivers/iio/adc/sun4i-gpadc-iio.c | 2 +-
include/linux/mfd/sun4i-gpadc.h | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
b/drivers/iio/adc/sun4i-gpadc-iio.c
index 137f577d9432..68926b986cd0 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -88,7 +88,7 @@ static const struct gpadc_data sun6i_gpadc_data = {
static const struct gpadc_data sun8i_a33_gpadc_data = {
.temp_offset = -1662,
.temp_scale = 162,
- .tp_mode_en = SUN8I_GPADC_CTRL1_CHOP_TEMP_EN,
+ .tp_mode_en = SUN8I_A33_GPADC_CTRL1_CHOP_TEMP_EN,
};
struct sun4i_gpadc_iio {
diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
index 139872c2e0fe..78d31984a222 100644
--- a/include/linux/mfd/sun4i-gpadc.h
+++ b/include/linux/mfd/sun4i-gpadc.h
@@ -38,9 +38,9 @@
#define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
#define SUN6I_GPADC_CTRL1_ADC_CHAN_MASKGENMASK(3, 0)
-/* TP_CTRL1 bits for sun8i SoCs */
-#define SUN8I_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
-#define SUN8I_GPADC_CTRL1_GPADC_CALI_ENBIT(7)
+/* TP_CTRL1 bits for A33 */
+#define SUN8I_A33_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
+#define SUN8I_A33_GPADC_CTRL1_GPADC_CALI_ENBIT(7)
#define SUN4I_GPADC_CTRL2 0x08
--
2.13.5
[PATCH v4 0/6] IIO-based thermal sensor driver for Allwinner H3 SoC
Allwiner H3 SoC has a thermal sensor, which is a large refactored version of the old Allwinner "GPADC" (although it have already only thermal part left in A33). This patch tried to add support for the sensor in H3 based on the A33 thermal sensor driver by Quentin Schulz, which is already merged. Icenowy Zheng (6): dt-bindings: update the Allwinner GPADC device tree binding for H3 iio: adc: sun4i-gpadc-iio: rename A33-specified registers to contain A33 iio: adc: sun4i-gpadc-iio: rework code for supporting newer THS variants iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor ARM: sun8i: h3: add support for the thermal sensor in H3 ARM: sun8i: h3: add partial CPU thermal zone .../devicetree/bindings/mfd/sun4i-gpadc.txt| 30 +++- arch/arm/boot/dts/sun8i-h3.dtsi| 26 drivers/iio/adc/sun4i-gpadc-iio.c | 173 - include/linux/mfd/sun4i-gpadc.h| 33 +++- 4 files changed, 249 insertions(+), 13 deletions(-) -- 2.13.5
Re: [PATCH v2 1/2] watchdog: dw_wdt: add stop watchdog operation
On Thu, Sep 14, 2017 at 01:30:12PM +0200, Oleksij Rempel wrote:
> From: Steffen Trumtrar
>
> The only way of stopping the watchdog is by resetting it.
> Add the watchdog op for stopping the device and reset if
> a reset line is provided.
>
> Signed-off-by: Steffen Trumtrar
> Signed-off-by: Oleksij Rempel
> Cc: Wim Van Sebroeck
> Cc: Guenter Roeck
> Cc: linux-watch...@vger.kernel.org
> ---
>
> changes v2:
> - test if dw_wdt->rst is NULL instead of IS_ERR
>
> drivers/watchdog/dw_wdt.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
> index 36be987ff9ef..a507f36302e1 100644
> --- a/drivers/watchdog/dw_wdt.c
> +++ b/drivers/watchdog/dw_wdt.c
> @@ -135,6 +135,21 @@ static int dw_wdt_start(struct watchdog_device *wdd)
> return 0;
> }
>
> +static int dw_wdt_stop(struct watchdog_device *wdd)
> +{
> + struct dw_wdt *dw_wdt = to_dw_wdt(wdd);
> +
> + if (!dw_wdt->rst) {
> + dev_warn(wdd->parent, "No reset line. Will not stop.\n");
> + return -EOPNOTSUPP;
Sorry, not the way to go. It now reports an error to user space when
there was none previously, and it still reboots the system. Plus, this
was a perfectly fine condition previously, and the reset line is optional.
It is not appropriate to generate a warning for a perfectly valid
condition.
You can not change behavior for existing users.
Guenter
> + }
> +
> + reset_control_assert(dw_wdt->rst);
> + reset_control_deassert(dw_wdt->rst);
> +
> + return 0;
> +}
> +
> static int dw_wdt_restart(struct watchdog_device *wdd,
> unsigned long action, void *data)
> {
> @@ -173,6 +188,7 @@ static const struct watchdog_info dw_wdt_ident = {
> static const struct watchdog_ops dw_wdt_ops = {
> .owner = THIS_MODULE,
> .start = dw_wdt_start,
> + .stop = dw_wdt_stop,
> .ping = dw_wdt_ping,
> .set_timeout= dw_wdt_set_timeout,
> .get_timeleft = dw_wdt_get_timeleft,
> --
> 2.11.0
>
Re: [PATCH] fs/proc: report eip/esp in /prod/PID/stat for coredumping
On Thu, Sep 14, 2017 at 2:42 AM, John Ogness wrote:
> Commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in
> /proc/PID/stat") stopped reporting eip/esp because it is
> racey and dangerous for executing tasks. The comment adds:
>
> As far as I know, there are no use programs that make any
> material use of these fields, so just get rid of them.
>
> However, existing userspace core-dump-handler applications (for
> example, minicoredumper) are using these fields since they
> provide an excellent cross-platform interface to these valuable
> pointers. So that commit introduced a user space visible
> regression.
>
> Partially revert the change and make the readout possible for
> tasks with the proper permissions and only if the target task
> has the PF_DUMPCORE flag set.
Looks okay to me.
Reviewed-by: Andy Lutomirski
--Andy
[PATCH] ACPI / PCI: Bail early in acpi_pci_add_bus() if there is no ACPI handle
Hyper-V instances support PCI pass-through which is implemented through PV pci-hyperv driver. When a device is passed through a new root PCI bus is created in the guest. The bus sits on top of VMBus and has no associated information in ACPI. acpi_pci_add_bus() in this case proceeds all the way to acpi_evaluate_dsm() with reports ACPI: \: failed to evaluate _DSM (0x1001) While acpi_pci_slot_enumerate() and acpiphp_enumerate_slots() are protected against ACPI_HANDLE() being NULL and do nothing acpi_evaluate_dsm() is not and gives us the error. It seems the correct fix is to not do anything in acpi_pci_add_bus() in such cases. Signed-off-by: Vitaly Kuznetsov --- drivers/pci/pci-acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index a8da543b3814..4708eb9df71b 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -624,7 +624,7 @@ void acpi_pci_add_bus(struct pci_bus *bus) union acpi_object *obj; struct pci_host_bridge *bridge; - if (acpi_pci_disabled || !bus->bridge) + if (acpi_pci_disabled || !bus->bridge || !ACPI_HANDLE(bus->bridge)) return; acpi_pci_slot_enumerate(bus); -- 2.13.5
Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent
On Sat, Sep 02, 2017 at 12:32:21PM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > On Thu, Aug 31, 2017 at 12:25:42PM -0500, Josh Poimboeuf wrote: > > > 2) Put "sp" in the clobbers list instead of as an i/o constraint. This > > >mostly works for GCC, and doesn't break clang. However, it causes > > >GCC to insert a "lea -0x10(%rbp),%rsp" in the epilogue of every > > >affected function. > > > > And maybe this extra instruction is negligible for performance and not a > > big deal? I might look at this one after the holiday too. > > Please do statistics of how many functions are affected, on a defconfig-ish > kernel. As it turns out, the real problem with this option is that it imposes a penalty for CONFIG_FRAME_POINTER=n: even with frame pointers disabled, it forces the frame pointer to be saved for each function which uses the inline asm "call" statements. Our current solution doesn't do that. - On a defconfig-based kernel, this adds +6k of .text (+0.06%). - On a Fedora distro-based config, it adds +27k of .text (+0.3%). (I think the difference from defconfig is mostly caused by CONFIG_PARAVIRT.) I'll try a few more experiments, but I'll probably end up engaging the compiler people as Linus suggested. -- Josh
Re: [PATCH] scsi: lpfc: remove redundant null check on eqe
On 9/8/2017 1:02 AM, Colin King wrote:
From: Colin Ian King
The pointer eqe is always non-null inside the while loop, so the
check to see if eqe is NULL is redudant and hence can be removed.
Detected by CoverityScan CID#1248693 ("Logically Dead Code")
Signed-off-by: Colin Ian King
Yep. thank you
Signed-off-by: James Smart
Re: [Intel-wired-lan] [PATCH] igb: check memory allocation failure
On 9/13/17 7:24 PM, Brown, Aaron F wrote: >> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf >> Of Christophe JAILLET >> Sent: Monday, August 28, 2017 10:13 AM >> To: Waskiewicz Jr, Peter ; Kirsher, Jeffrey T >> >> Cc: net...@vger.kernel.org; kernel-janit...@vger.kernel.org; intel-wired- >> l...@lists.osuosl.org; linux-kernel@vger.kernel.org >> Subject: Re: [Intel-wired-lan] [PATCH] igb: check memory allocation failure >> >> Le 28/08/2017 à 01:09, Waskiewicz Jr, Peter a écrit : >>> On 8/27/17 2:42 AM, Christophe JAILLET wrote: Check memory allocation failures and return -ENOMEM in such cases, as already done for other memory allocations in this function. This avoids NULL pointers dereference. Signed-off-by: Christophe JAILLET --- drivers/net/ethernet/intel/igb/igb_main.c | 2 ++ 1 file changed, 2 insertions(+) > > This seems to be fine from a "it does not break in testing" perspective, so... > > Tested-by: Aaron Brown >>> -PJ >>> >> Hi, >> >> in fact, there is no leak because the only caller of 'igb_sw_init()' >> (i.e. 'igb_probe()'), already frees these resources in case of error, >> see [1] >> >> These resources are also freed in 'igb_remove()'. >> >> Best reagrds, >> CJ >> >> [1]: >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux- >> next.git/tree/drivers/net/ethernet/intel/igb/igb_main.c#n2775 > > But is PJ's comment saying that it is not really necessary? If so I tend to > lean towards the don't touch it if it's not broken perspective. I guess I didn't respond after Christophe replied, sorry about that. The patch is good to me. It's definitely catching an issue where we're not checking for a memory failure, then just follows the same de-allocation path on unwind. If you want it: Acked-by: PJ Waskiewicz
Re: [PATCH] selftests: intel_pstate: compile programs if executable not found
On 09/14/2017 08:42 AM, Shuah Khan wrote: > Hi Naresh, > > On 09/14/2017 04:51 AM, naresh.kamb...@linaro.org wrote: >> From: Naresh Kamboju >> >> Test exit due to aperf.c: No such file or directory >> ./run.sh >> gcc: error: aperf.c: No such file or directory >> Problem compiling aperf.c. >> > > Please give me more details on where do you see this problem? > I don't think the below is the right fix. It adds checks for > executables and they doesn't exist, goes and tries to build. > >> The Makefile installs executable programs "aperf" and "msr" >> so skip compile on target. >> >> Signed-off-by: Naresh Kamboju >> --- >> tools/testing/selftests/intel_pstate/run.sh | 15 ++- >> 1 file changed, 10 insertions(+), 5 deletions(-) >> >> diff --git a/tools/testing/selftests/intel_pstate/run.sh >> b/tools/testing/selftests/intel_pstate/run.sh >> index 7868c106b8b1..2149b9b5876a 100755 >> --- a/tools/testing/selftests/intel_pstate/run.sh >> +++ b/tools/testing/selftests/intel_pstate/run.sh >> @@ -31,11 +31,16 @@ EVALUATE_ONLY=0 >> >> max_cpus=$(($(nproc)-1)) >> >> -# compile programs >> -gcc aperf.c -Wall -D_GNU_SOURCE -o aperf -lm >> -[ $? -ne 0 ] && echo "Problem compiling aperf.c." && exit 1 >> -gcc -o msr msr.c -lm >> -[ $? -ne 0 ] && echo "Problem compiling msr.c." && exit 1 >> +# Compile programs if executable not found >> +if [ ! -x aperf ]; then >> +gcc aperf.c -Wall -D_GNU_SOURCE -o aperf -lm >> +[ $? -ne 0 ] && echo "Problem compiling aperf.c." && exit 1 >> +fi >> + >> +if [ ! -x msr ]; then >> +gcc -o msr msr.c -lm >> +[ $? -ne 0 ] && echo "Problem compiling msr.c." && exit 1 >> +fi > > As such run.sh shouldn't have any compile code. These should > be strictly for running tests. > > Instead of adding checks, please remove the compile logic from this > file. > Hi Naresh, I already have a patch from Thomas Meyer that removes the compile logic. No need to redo the patch. thanks, -- Shuah
Re: [PATCH v1 1/2] watchdog: dw_wdt: add stop watchdog operation
On Thu, Sep 14, 2017 at 10:14:01AM +0200, Oleksij Rempel wrote:
> From: Steffen Trumtrar
>
> The only way of stopping the watchdog is by resetting it.
> Add the watchdog op for stopping the device and reset if
> a reset line is provided.
>
> Signed-off-by: Steffen Trumtrar
> Signed-off-by: Oleksij Rempel
> Cc: Wim Van Sebroeck
> Cc: Guenter Roeck
> Cc: linux-watch...@vger.kernel.org
> ---
> drivers/watchdog/dw_wdt.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
> index 36be987ff9ef..50d8a6a5b5ac 100644
> --- a/drivers/watchdog/dw_wdt.c
> +++ b/drivers/watchdog/dw_wdt.c
> @@ -135,6 +135,21 @@ static int dw_wdt_start(struct watchdog_device *wdd)
> return 0;
> }
>
> +static int dw_wdt_stop(struct watchdog_device *wdd)
> +{
> + struct dw_wdt *dw_wdt = to_dw_wdt(wdd);
> +
> + if (IS_ERR(dw_wdt->rst)) {
> + dev_warn(wdd->parent, "No reset line. Will not stop.\n");
> + return PTR_ERR(dw_wdt->rst);
> + }
This is a change in behavior. Previously, with no stop function,
the watchdog core would keep pinging the watchdog in this situation.
Now it would end up spitting a warning and resetting the system.
> +
> + reset_control_assert(dw_wdt->rst);
> + reset_control_deassert(dw_wdt->rst);
> +
> + return 0;
> +}
> +
> static int dw_wdt_restart(struct watchdog_device *wdd,
> unsigned long action, void *data)
> {
> @@ -173,6 +188,7 @@ static const struct watchdog_info dw_wdt_ident = {
> static const struct watchdog_ops dw_wdt_ops = {
> .owner = THIS_MODULE,
> .start = dw_wdt_start,
> + .stop = dw_wdt_stop,
> .ping = dw_wdt_ping,
> .set_timeout= dw_wdt_set_timeout,
> .get_timeleft = dw_wdt_get_timeleft,
> --
> 2.11.0
>
Re: [PATCH] selftests: intel_pstate: compile programs if executable not found
Hi Naresh, On 09/14/2017 04:51 AM, naresh.kamb...@linaro.org wrote: > From: Naresh Kamboju > > Test exit due to aperf.c: No such file or directory > ./run.sh > gcc: error: aperf.c: No such file or directory > Problem compiling aperf.c. > Please give me more details on where do you see this problem? I don't think the below is the right fix. It adds checks for executables and they doesn't exist, goes and tries to build. > The Makefile installs executable programs "aperf" and "msr" > so skip compile on target. > > Signed-off-by: Naresh Kamboju > --- > tools/testing/selftests/intel_pstate/run.sh | 15 ++- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git a/tools/testing/selftests/intel_pstate/run.sh > b/tools/testing/selftests/intel_pstate/run.sh > index 7868c106b8b1..2149b9b5876a 100755 > --- a/tools/testing/selftests/intel_pstate/run.sh > +++ b/tools/testing/selftests/intel_pstate/run.sh > @@ -31,11 +31,16 @@ EVALUATE_ONLY=0 > > max_cpus=$(($(nproc)-1)) > > -# compile programs > -gcc aperf.c -Wall -D_GNU_SOURCE -o aperf -lm > -[ $? -ne 0 ] && echo "Problem compiling aperf.c." && exit 1 > -gcc -o msr msr.c -lm > -[ $? -ne 0 ] && echo "Problem compiling msr.c." && exit 1 > +# Compile programs if executable not found > +if [ ! -x aperf ]; then > + gcc aperf.c -Wall -D_GNU_SOURCE -o aperf -lm > + [ $? -ne 0 ] && echo "Problem compiling aperf.c." && exit 1 > +fi > + > +if [ ! -x msr ]; then > + gcc -o msr msr.c -lm > + [ $? -ne 0 ] && echo "Problem compiling msr.c." && exit 1 > +fi As such run.sh shouldn't have any compile code. These should be strictly for running tests. Instead of adding checks, please remove the compile logic from this file. thanks, -- Shuah
Re: [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
On Thu, Sep 14, 2017 at 10:07 AM, nixiaoming wrote:
> From: l00219569
>
> If fanout_add is preempted after running po-> fanout = match
> and before running __fanout_link,
> it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink
>
> so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook
The packet socket code has no shortage of locks, so there are many
ways to avoid the race condition between fanout_add and packet_set_ring.
Another option would be to lock the socket when calling fanout_add:
- return fanout_add(sk, val & 0x, val >> 16);
+ lock_sock(sk);
+ ret = fanout_add(sk, val & 0x, val >> 16);
+ release_sock(sk);
+ return ret;
But, for consistency, and to be able to continue to make sense of the
locking policy, we should use the most appropriate lock. This
is po->bind_lock, as it ensures atomicity between testing whether
a protocol hook is active through po->running and the actual existence
of that hook on the protocol hook list.
fanout_mutex protects the fanout object's list. Taking that on
__unregister_prot_hook even in the case where fanout is not
used (and __dev_remove_pack is called) complicates locking
in this already complicated code.
> or add spin_lock(&po->bind_lock) before po-> fanout = match
>
> this is a patch for add po->bind_lock in fanout_add
>
> test on linux 4.1.12:
> ./trinity -c setsockopt -C 2 -X &
Thanks for testing!
>
> BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
> Kernel panic - not syncing: BUG!
> CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: GW O4.1.12 #1
> Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
> Call trace:
> [] dump_backtrace+0x0/0xf8
> [] show_stack+0x20/0x28
> [] dump_stack+0xac/0xe4
> [] panic+0xf8/0x268
> [] __unregister_prot_hook+0xa0/0x144
> [] packet_set_ring+0x280/0x5b4
> [] packet_setsockopt+0x320/0x950
> [] SyS_setsockopt+0xa4/0xd4
>
> Signed-off-by: nixiaoming
> Tested-by: wudesheng
> ---
> net/packet/af_packet.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 54a18a8..7a52a3b 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1446,12 +1446,16 @@ static int fanout_add(struct sock *sk, u16 id, u16
> type_flags)
> default:
> return -EINVAL;
> }
> -
> - if (!po->running)
> + spin_lock(&po->bind_lock);
> + if (!po->running) {
> + spin_unlock(&po->bind_lock);
> return -EINVAL;
> + }
>
> - if (po->fanout)
> + if (po->fanout) {
> + spin_unlock(&po->bind_lock);
> return -EALREADY;
> + }
>
> mutex_lock(&fanout_mutex);
> match = NULL;
> @@ -1501,6 +1505,7 @@ static int fanout_add(struct sock *sk, u16 id, u16
> type_flags)
> }
> out:
> mutex_unlock(&fanout_mutex);
> + spin_unlock(&po->bind_lock);
This function can call kzalloc with GFP_KERNEL, which may sleep. It is
not correct to sleep while holding a spinlock. Which is why I take the lock
later and test po->running again.
I will clean up that patch and send it for review.
Re: [RFC Part2 PATCH v3 24/26] KVM: SVM: Clear C-bit from the page fault address
On Mon, Jul 24, 2017 at 03:03:01PM -0500, Brijesh Singh wrote:
> When SEV is active, on #NPF the page fault address will contain C-bit.
"... contain the C-bit."
> We must clear the C-bit before handling the fault.
>
> Signed-off-by: Brijesh Singh
> ---
> arch/x86/kvm/svm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 0bbd050..64b9f60 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -2321,7 +2321,7 @@ static void svm_set_dr7(struct kvm_vcpu *vcpu, unsigned
> long value)
>
> static int pf_interception(struct vcpu_svm *svm)
> {
> - u64 fault_address = svm->vmcb->control.exit_info_2;
> + u64 fault_address = __sme_clr(svm->vmcb->control.exit_info_2);
> u64 error_code = svm->vmcb->control.exit_info_1;
>
> return kvm_handle_page_fault(&svm->vcpu, error_code, fault_address,
> --
Otherwise:
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
Re: keyboard backlight max_brightness bug on Dell Latitude E6410
2017-09-14 15:54 GMT+02:00 Pali Rohár : > Adding Gabriele to thread, IIRC you have machine which uses > "supported keyboard light brightness levels" > Can you look at this bug, if your machine is affected by it too? My keyboard has two brightness levels + off. The value of max_brightness is 2, as expected. Gabriele Yes, my laptop uses "supported keyboard light brightness levels". > > Important parts in ouptput: > >> ... --info >> Supported Keyboard light brightness levels : 10 > >> ... --get-status >> Current keyboard light level : 9 > > Gabriel, can you play with this tool, which values can be set via > --set-level= parameter? Is 10 accepted? --get-status can be used to > check if value was accepted. > > On Thursday 14 September 2017 06:35:15 Gabriel M. Elder wrote: >> >> output from smbios-keyboard-ctl --info: >> >> Libsmbios version : 2.3.0 >> smbios-keyboard-ctl version : 2.3.0 >> >> Capabilities of KeyBoard Illumination on your system: >> --- >> Supported USER Selectable Modes : >>Always OFF >>Auto: ALS- and input-activity-based On; input-activity based Off >>Auto: Input-activity-based On; input-activity based Off >> >> Supported Keyboard illumination type : Backlight >> >> Supports Keyboard illumination on : >> Any Keystroke >> Touchpad activity >> Pointing stick >> >> Can configure Keyboard illumination timeout unit in : >> Seconds >> Minutes >> Hours >> >> Supported Keyboard light brightness levels : 10 >> >> Maximum acceptable seconds timeout value : 255 >> >> Maximum acceptable minutes timeout value : 255 >> >> Maximum acceptable hours timeout value : 12 >> >> Maximum acceptable days timeout value : 0 >> >> >> output from smbios-keyboard-ctl --get-status: >> >> Helper function to print current status of keyboard illumination >> >> Current status of KeyBoard Illumination setting on your system: >> --- >> >> Configured mode state: >>Auto: Input-activity-based On; input-activity based Off >> >> Your Keyboard will illumination on: >> Any Keystroke >> Touchpad activity >> Pointing stick >> >> Keyboard illumination timeout has bee set at: 10 Seconds >> >> Current setting of ALS value that turns the light on or off: 18 >> Current ALS Reading : 16 >> Current keyboard light level : 9 >> >> >> Original Message >> Subject: Re: keyboard backlight max_brightness bug on Dell Latitude >> E6410 >> From: Pali Rohár >> Date: Thu, September 14, 2017 3:06 am >> To: "Gabriel M. Elder" >> Cc: dvh...@infradead.org, a...@infradead.org, >> platform-driver-...@vger.kernel.org, linux-kernel@vger.kernel.org >> >> On Monday 11 September 2017 23:25:27 Gabriel M. Elder wrote: >> > Hi all, >> > Hans de Goede, one of the upower maintainers, suggested I alert you all to >> > this bug: >> > >> > https://bugs.freedesktop.org/show_bug.cgi?id=100041 >> > >> > and the new one I filed via the kernel bugzilla: >> > >> > https://bugzilla.kernel.org/show_bug.cgi?id=196913 >> > "keyboard backlight max_brightness value outside allowable range on Dell >> > Latitude E6410 laptop" >> > >> > Please check it out at your earliest convenience. >> > >> > thanks, >> > - Gabriel >> >> Hi Gabriel, please avoid sending such html emails to mailing list as it >> is hard to read them and also you have a very big chance that email >> would be eaten by spam filter or other developers would completely >> ignore it... >> >> To debug your problem, can you run smbios-keyboard-ctl tool from the >> libsmbios project? https://github.com/dell/libsmbios >> >> We would need output from --info parameter and also from --get-status. >> > > -- > Pali Rohár > pali.ro...@gmail.com
RE: keyboard backlight max_brightness bug on Dell Latitude E6410
I've also been updating https://bugzilla.kernel.org/show_bug.cgi?id=196913 btw. What source file is responsible for setting this; led-class.c? I would like to know, so I can tell it to use the correct value: max_brightness = supported_brightness_levels-1; // !actual_max_brightness+1 :) # smbios-keyboard-ctl --set-level=10; echo $? Old Keyboard illumination level is: 9 Set Trigger Failed. Failed to write config Error Return Code : cbRES1: 0x-2 cbRES2: 0x93512 cbRES3: 0xC 0 # smbios-keyboard-ctl --get-status; echo $? Helper function to print current status of keyboard illumination Current status of KeyBoard Illumination setting on your system: --- Configured mode state: Auto: ALS- and input-activity-based On; input-activity based Off Your Keyboard will illumination on: Any Keystroke Touchpad activity Keyboard illumination timeout has bee set at: 10 Seconds Current setting of ALS value that turns the light on or off: 18 Current ALS Reading : 45 Current keyboard light level : 9 0 Original Message Subject: Re: keyboard backlight max_brightness bug on Dell Latitude E6410 From: Pali Rohár Date: Thu, September 14, 2017 8:54 am To: "Gabriel M. Elder" , Gabriele Mazzotta Cc: dvh...@infradead.org, a...@infradead.org, platform-driver-...@vger.kernel.org, linux-kernel@vger.kernel.org Adding Gabriele to thread, IIRC you have machine which uses "supported keyboard light brightness levels" Can you look at this bug, if your machine is affected by it too? Important parts in ouptput: > ... --info > Supported Keyboard light brightness levels : 10 > ... --get-status > Current keyboard light level : 9 Gabriel, can you play with this tool, which values can be set via --set-level= parameter? Is 10 accepted? --get-status can be used to check if value was accepted. On Thursday 14 September 2017 06:35:15 Gabriel M. Elder wrote: > > output from smbios-keyboard-ctl --info: > > Libsmbios version : 2.3.0 > smbios-keyboard-ctl version : 2.3.0 > > Capabilities of KeyBoard Illumination on your system: > --- > Supported USER Selectable Modes : > Always OFF > Auto: ALS- and input-activity-based On; input-activity based Off > Auto: Input-activity-based On; input-activity based Off > > Supported Keyboard illumination type : Backlight > > Supports Keyboard illumination on : > Any Keystroke > Touchpad activity > Pointing stick > > Can configure Keyboard illumination timeout unit in : > Seconds > Minutes > Hours > > Supported Keyboard light brightness levels : 10 > > Maximum acceptable seconds timeout value : 255 > > Maximum acceptable minutes timeout value : 255 > > Maximum acceptable hours timeout value : 12 > > Maximum acceptable days timeout value : 0 > > > output from smbios-keyboard-ctl --get-status: > > Helper function to print current status of keyboard illumination > > Current status of KeyBoard Illumination setting on your system: > --- > > Configured mode state: > Auto: Input-activity-based On; input-activity based Off > > Your Keyboard will illumination on: > Any Keystroke > Touchpad activity > Pointing stick > > Keyboard illumination timeout has bee set at: 10 Seconds > > Current setting of ALS value that turns the light on or off: 18 > Current ALS Reading : 16 > Current keyboard light level : 9 > > > Original Message > Subject: Re: keyboard backlight max_brightness bug on Dell Latitude > E6410 > From: Pali Rohár > Date: Thu, September 14, 2017 3:06 am > To: "Gabriel M. Elder" > Cc: dvh...@infradead.org, a...@infradead.org, > platform-driver-...@vger.kernel.org, linux-kernel@vger.kernel.org > > On Monday 11 September 2017 23:25:27 Gabriel M. Elder wrote: > > Hi all, > > Hans de Goede, one of the upower maintainers, suggested I alert you all to > > this bug: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=100041 > > > > and the new one I filed via the kernel bugzilla: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=196913 > > "keyboard backlight max_brightness value outside allowable range on Dell > > Latitude E6410 laptop" > > > > Please check it out at your earliest convenience. > > > > thanks, > > - Gabriel > > Hi Gabriel, please avoid sending such html emails to mailing list as it > is hard to read them and also you have a very big chance that email > would be eaten by spam filter or other developers would completely > ignore it... > > To debug your problem, can you run smbios-keyboard-ctl tool from the > libsmbios project? https://github.com/dell/libsmbios > > We would need output from --info parameter and also from --get-status. > -- Pali Rohár pali.ro...@gmail.com
Re: [PATCH v2] kbuild: (bin)rpm-pkg: fix version number handling
Hi Riku.
2017-09-14 22:10 GMT+09:00 Riku Voipio :
> On 14 September 2017 at 14:26, Masahiro Yamada
> wrote:
>> The "Release:" field of the spec file is determined based on the
>> .version file.
>>
>> However, the .version file is not copied to the source tar file.
>> So, when we build the kernel from the source package, the UTS_VERSION
>> always indicates #1. This does not match with "rpm -q".
>>
>> The kernel UTS_VERSION and "rpm -q" do not agree for binrpm-pkg, either.
>> Please note the kernel has already been built before the spec file is
>> created. Currently, mkspec invokes mkversion. This script returns an
>> incremented version. So, the "Release:" field of the spec file is
>> greater than the version in the kernel by one.
>>
>> For the source package build (where .version file is missing), we can
>> give KBUILD_BUILD_VERSION=%{release} to the build command.
>>
>> For the binary package build, we can simply read out the .version file
>> because it contains the version number that was used for building the
>> kernel image.
>>
>> We can remove scripts/mkversion because scripts/package/Makefile need
>> not touch the .version file.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> Changes in v2:
>> - Remove bogus comment in mkspec
>>
>> scripts/mkversion| 6 --
>> scripts/package/Makefile | 5 -
>> scripts/package/mkspec | 6 ++
>> 3 files changed, 2 insertions(+), 15 deletions(-)
>> delete mode 100644 scripts/mkversion
>>
>> diff --git a/scripts/mkversion b/scripts/mkversion
>> deleted file mode 100644
>> index c12addc..000
>> --- a/scripts/mkversion
>> +++ /dev/null
>> @@ -1,6 +0,0 @@
>> -if [ ! -f .version ]
>> -then
>> -echo 1
>> -else
>> -expr 0`cat .version` + 1
>> -fi
>> diff --git a/scripts/package/Makefile b/scripts/package/Makefile
>> index 71b4a8a..73f9f31 100644
>> --- a/scripts/package/Makefile
>> +++ b/scripts/package/Makefile
>> @@ -50,8 +50,6 @@ rpm-pkg rpm: FORCE
>> $(MAKE) clean
>> $(CONFIG_SHELL) $(MKSPEC) >$(objtree)/kernel.spec
>> $(call cmd,src_tar,$(KERNELPATH),kernel.spec)
>> - $(CONFIG_SHELL) $(srctree)/scripts/mkversion >
>> $(objtree)/.tmp_version
>> - mv -f $(objtree)/.tmp_version $(objtree)/.version
>> rpmbuild $(RPMOPTS) --target $(UTS_MACHINE) -ta $(KERNELPATH).tar.gz
>> rm $(KERNELPATH).tar.gz kernel.spec
>>
>> @@ -60,9 +58,6 @@ rpm-pkg rpm: FORCE
>> binrpm-pkg: FORCE
>> $(MAKE) KBUILD_SRC=
>> $(CONFIG_SHELL) $(MKSPEC) prebuilt > $(objtree)/binkernel.spec
>> - $(CONFIG_SHELL) $(srctree)/scripts/mkversion >
>> $(objtree)/.tmp_version
>> - mv -f $(objtree)/.tmp_version $(objtree)/.version
>> -
>> rpmbuild $(RPMOPTS) --define "_builddir $(objtree)" --target \
>> $(UTS_MACHINE) -bb $(objtree)/binkernel.spec
>> rm binkernel.spec
>> diff --git a/scripts/package/mkspec b/scripts/package/mkspec
>> index bb43f15..e81dafc 100755
>> --- a/scripts/package/mkspec
>> +++ b/scripts/package/mkspec
>> @@ -27,9 +27,7 @@ __KERNELRELEASE=`echo $KERNELRELEASE | sed -e "s/-/_/g"`
>> echo "Name: kernel"
>> echo "Summary: The Linux Kernel"
>> echo "Version: $__KERNELRELEASE"
>> -# we need to determine the NEXT version number so that uname and
>> -# rpm -q will agree
>> -echo "Release: `. $srctree/scripts/mkversion`"
>> +echo "Release: $(cat .version)"
>
> $(cat .version||echo 1)"
>
> .version might not exist at that point - for example when calling
> make rpm-pkg from a pristine source tree. Apart from that looks good
> to me.
>
Good catch. I will fix it. Thanks!
--
Best Regards
Masahiro Yamada
Re: [PATCH v1 1/4] perf annotate: create a new hists to manage multiple events samples
On 9/14/2017 10:05 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Sep 14, 2017 at 09:03:55AM +0800, Jin, Yao escreveu:
>> On 9/11/2017 9:33 AM, Jin, Yao wrote:
>>> On 9/8/2017 9:43 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Aug 16, 2017 at 06:18:33PM +0800, Jin Yao escreveu:
> An issue is found during using perf annotate.
>
> perf record -e cycles,branches ...
> perf annotate main --stdio
>
> The result only shows cycles. It should show both cycles and
> branches on the left side. It works with "--group", but need
> this to work even without groups.
>
> In current design, the hists is per event. So we need a new
> hists to manage the samples for multiple events and use a new
> hist_event data structure to save the map/symbol information
> for per event.
Humm, why do we need another hists? Don't we have one per evsel, don't
we have a evlist from where to get all of those evsels, can't we just
use that to add one column per evsel?
>
>>> I'm considering a case.
>
>>> Suppose we sample 2 events ("branches" and "cache-misses"). The samples of
>>> "branches" are hit in function A and the samples of "cache-misses" are hit
>>> in function B.
>>>
>>> The branches evsel has one hists and cache-misses evsel has another hists.
>>>
>>> The hists of branches evsel has one hist-entry which stands for the
>>> function A symbol. The hists of cache-misses evsel has one hist-entry which
>>> stands for the function B symbol.
>>>
>>> If we start to show the instructions in function B from cache-misses evsel,
>>> we will lose the function A.
>>>
>>> Because even if we get the branches evsel from the link in cache-misses
>>> evsel, but the function A is before function B and function B has been
>>> displayed yet, so the function A is lost.
>>>
>>> Considering the number of events can be greater than 2, the code will be
>>> much more complicated. So using a global hists should be an easy solution.
>>
>> Could the solution of using a new hists for multiple events be accepted?
>>
>> Or anything I should update in the patches?
>
> I'm not having time at this moment for doing a proper review, wait a bit
> more please.
>
> - Arnaldo
>
No problem, that's fine. Thanks in advance.
[PATCH v4 1/5] dt-bindings: i2c-stm32: Document the STM32F7 I2C bindings
This patch adds the documentation of device tree bindings for STM32F7 I2C
Signed-off-by: M'boumba Cedric Madianga
Signed-off-by: Pierre-Yves MORDRET
Acked-by: Rob Herring
---
Version history:
v4:
v3:
* None
v2:
* Remove i2c-timing binding in order to use generic bindings SCL
Rising and Falling time instead
---
---
.../devicetree/bindings/i2c/i2c-stm32.txt | 29 +++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
index 78eaf7b..3b54899 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -1,7 +1,9 @@
* I2C controller embedded in STMicroelectronics STM32 I2C platform
Required properties :
-- compatible : Must be "st,stm32f4-i2c"
+- compatible : Must be one of the following
+ - "st,stm32f4-i2c"
+ - "st,stm32f7-i2c"
- reg : Offset and length of the register set for the device
- interrupts : Must contain the interrupt id for I2C event and then the
interrupt id for I2C error.
@@ -14,8 +16,16 @@ Required properties :
Optional properties :
- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
- the default 100 kHz frequency will be used. As only Normal and Fast modes
- are supported, possible values are 10 and 40.
+ the default 100 kHz frequency will be used.
+ For STM32F4 SoC Standard-mode and Fast-mode are supported, possible values
are
+ 10 and 40.
+ For STM32F7 SoC, Standard-mode, Fast-mode and Fast-mode Plus are supported,
+ possible values are 10, 40 and 100.
+- i2c-scl-rising-time-ns : Only for STM32F7, I2C SCL Rising time for the board
+ (default: 25)
+- i2c-scl-falling-time-ns : Only for STM32F7, I2C SCL Falling time for the
board
+ (default: 10)
+ I2C Timings are derived from these 2 values
Example :
@@ -31,3 +41,16 @@ Example :
pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
pinctrl-names = "default";
};
+
+ i2c@40005400 {
+ compatible = "st,stm32f7-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x40005400 0x400>;
+ interrupts = <31>,
+<32>;
+ resets = <&rcc STM32F7_APB1_RESET(I2C1)>;
+ clocks = <&rcc 1 CLK_I2C1>;
+ pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
+ pinctrl-names = "default";
+ };
--
2.7.4
[PATCH v4 0/5] Add support for the STM32F7 I2C
This patchset adds support for the I2C controller embedded in STM32F7xx SoC. It enables I2C transfer in interrupt mode with Standard-mode, Fast-mode and Fast-mode+ bus speed. --- Version history: v4: * Fix max I2C Bus clock to 100% * Solve typo issue * Add retries value v3: * Move stm32f7_i2c_match above stm32f7_i2c_driver * of_device_get_match_data instead of of_match_device * Improve I2C Speed DT gathering * dev_err into dev_dbg for Arbitration loss * Remove useless space aligned v2: * Implement an I2C timings computation algorithm instead of static values(bindings). Algorithm uses generic I2C SCL Falling/Rising bindings and System clock to compute its timings. * I2C Device Tree Update --- Pierre-Yves MORDRET (5): dt-bindings: i2c-stm32: Document the STM32F7 I2C bindings i2c: i2c-stm32f4: use generic definition of speed enum i2c: i2c-stm32f7: add driver ARM: dts: stm32: Add I2C1 support for STM32F746 SoC ARM: dts: stm32: Add I2C1 support for STM32F746 eval board .../devicetree/bindings/i2c/i2c-stm32.txt | 29 +- arch/arm/boot/dts/stm32746g-eval.dts | 8 + arch/arm/boot/dts/stm32f746.dtsi | 22 + drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile| 1 + drivers/i2c/busses/i2c-stm32.h | 20 + drivers/i2c/busses/i2c-stm32f4.c | 18 +- drivers/i2c/busses/i2c-stm32f7.c | 972 + 8 files changed, 1066 insertions(+), 14 deletions(-) create mode 100644 drivers/i2c/busses/i2c-stm32.h create mode 100644 drivers/i2c/busses/i2c-stm32f7.c -- 2.7.4
[PATCH v4 4/5] ARM: dts: stm32: Add I2C1 support for STM32F746 SoC
This patch adds I2C1 support for STM32F746 SoC.
Signed-off-by: M'boumba Cedric Madianga
Signed-off-by: Pierre-Yves MORDRET
---
Version history:
v4:
v3:
* None
v2:
* Update I2C SoC device tree with latest Linux version
---
---
arch/arm/boot/dts/stm32f746.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index 4506eb9..ddd8f2c 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -361,6 +361,16 @@
bias-disable;
};
};
+
+ i2c1_pins_b: i2c1@0 {
+ pins {
+ pinmux = ,
+;
+ bias-disable;
+ drive-open-drain;
+ slew-rate = <0>;
+ };
+ };
};
crc: crc@40023000 {
@@ -380,6 +390,18 @@
assigned-clocks = <&rcc 1 CLK_HSE_RTC>;
assigned-clock-rates = <100>;
};
+
+ i2c1: i2c@40005400 {
+ compatible = "st,stm32f7-i2c";
+ reg = <0x40005400 0x400>;
+ interrupts = <31>,
+<32>;
+ resets = <&rcc STM32F7_APB1_RESET(I2C1)>;
+ clocks = <&rcc 1 CLK_I2C1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
};
--
2.7.4
[PATCH v4 2/5] i2c: i2c-stm32f4: use generic definition of speed enum
This patch uses a more generic definition of speed enum for i2c-stm32f4
driver.
Signed-off-by: M'boumba Cedric Madianga
Signed-off-by: Pierre-Yves MORDRET
Reviewed-by: Ludovic BARRE
---
Version history:
v4:
v3:
v2:
* None
---
---
drivers/i2c/busses/i2c-stm32.h | 20
drivers/i2c/busses/i2c-stm32f4.c | 18 +++---
2 files changed, 27 insertions(+), 11 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-stm32.h
diff --git a/drivers/i2c/busses/i2c-stm32.h b/drivers/i2c/busses/i2c-stm32.h
new file mode 100644
index 000..dab5176
--- /dev/null
+++ b/drivers/i2c/busses/i2c-stm32.h
@@ -0,0 +1,20 @@
+/*
+ * i2c-stm32.h
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2017
+ * Author: M'boumba Cedric Madianga
+ *
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#ifndef _I2C_STM32_H
+#define _I2C_STM32_H
+
+enum stm32_i2c_speed {
+ STM32_I2C_SPEED_STANDARD, /* 100 kHz */
+ STM32_I2C_SPEED_FAST, /* 400 kHz */
+ STM32_I2C_SPEED_FAST_PLUS, /* 1 MHz */
+ STM32_I2C_SPEED_END,
+};
+
+#endif /* _I2C_STM32_H */
diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
index f9dd7e8..b81557d 100644
--- a/drivers/i2c/busses/i2c-stm32f4.c
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -27,6 +27,8 @@
#include
#include
+#include "i2c-stm32.h"
+
/* STM32F4 I2C offset registers */
#define STM32F4_I2C_CR10x00
#define STM32F4_I2C_CR20x04
@@ -90,12 +92,6 @@
#define STM32F4_I2C_MAX_FREQ 46U
#define HZ_TO_MHZ 100
-enum stm32f4_i2c_speed {
- STM32F4_I2C_SPEED_STANDARD, /* 100 kHz */
- STM32F4_I2C_SPEED_FAST, /* 400 kHz */
- STM32F4_I2C_SPEED_END,
-};
-
/**
* struct stm32f4_i2c_msg - client specific data
* @addr: 8-bit slave addr, including r/w bit
@@ -159,7 +155,7 @@ static int stm32f4_i2c_set_periph_clk_freq(struct
stm32f4_i2c_dev *i2c_dev)
i2c_dev->parent_rate = clk_get_rate(i2c_dev->clk);
freq = DIV_ROUND_UP(i2c_dev->parent_rate, HZ_TO_MHZ);
- if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD) {
+ if (i2c_dev->speed == STM32_I2C_SPEED_STANDARD) {
/*
* To reach 100 kHz, the parent clk frequency should be between
* a minimum value of 2 MHz and a maximum value of 46 MHz due
@@ -216,7 +212,7 @@ static void stm32f4_i2c_set_rise_time(struct
stm32f4_i2c_dev *i2c_dev)
* is not higher than 46 MHz . As a result trise is at most 4 bits wide
* and so fits into the TRISE bits [5:0].
*/
- if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD)
+ if (i2c_dev->speed == STM32_I2C_SPEED_STANDARD)
trise = freq + 1;
else
trise = freq * 3 / 10 + 1;
@@ -230,7 +226,7 @@ static void stm32f4_i2c_set_speed_mode(struct
stm32f4_i2c_dev *i2c_dev)
u32 val;
u32 ccr = 0;
- if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD) {
+ if (i2c_dev->speed == STM32_I2C_SPEED_STANDARD) {
/*
* In standard mode:
* t_scl_high = t_scl_low = CCR * I2C parent clk period
@@ -808,10 +804,10 @@ static int stm32f4_i2c_probe(struct platform_device *pdev)
udelay(2);
reset_control_deassert(rst);
- i2c_dev->speed = STM32F4_I2C_SPEED_STANDARD;
+ i2c_dev->speed = STM32_I2C_SPEED_STANDARD;
ret = of_property_read_u32(np, "clock-frequency", &clk_rate);
if (!ret && clk_rate >= 40)
- i2c_dev->speed = STM32F4_I2C_SPEED_FAST;
+ i2c_dev->speed = STM32_I2C_SPEED_FAST;
i2c_dev->dev = &pdev->dev;
--
2.7.4
[PATCH 2/3] ARM: dts: at91: sama5d27_som1_ek: fix typos
From: Ludovic Desroches
Fix typos that prevent proper using of uart2 and uart4 devices.
Signed-off-by: Ludovic Desroches
Signed-off-by: Claudiu Beznea
---
arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index f13ef4fbab60..be5cd913f274 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -120,7 +120,7 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_mikrobus2_uart>;
atmel,use-dma-rx;
- atmel-use-dma-tx;
+ atmel,use-dma-tx;
status = "okay";
};
@@ -178,7 +178,7 @@
uart4: serial@fc00c000 {
atmel,use-dma-rx;
atmel,use-dma-tx;
- pinctrl-name = "default";
+ pinctrl-names = "default";
pinctrl-0 = <&pinctrl_mikrobus1_uart>;
status = "okay";
};
--
2.7.4
[PATCH 1/3] ARM: dts: at91: sama5d27_som1_ek: update pinmux/pinconf for LEDs and USB
From: Ludovic Desroches
There are some changes from the prototype board concerning LEDs and USB
pins:
- USBB power enable and red LED pins are inverted.
- The polarity of LEDs is inverted too.
Signed-off-by: Ludovic Desroches
Signed-off-by: Claudiu Beznea
---
arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index 9c9088c99cc4..f13ef4fbab60 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -67,7 +67,7 @@
usb1: ohci@0040 {
num-ports = <3>;
- atmel,vbus-gpio = <&pioA PIN_PA10 GPIO_ACTIVE_HIGH>;
+ atmel,vbus-gpio = <&pioA PIN_PA27 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usb_default>;
status = "okay";
@@ -330,7 +330,7 @@
};
pinctrl_led_gpio_default: led_gpio_default {
- pinmux = ,
+ pinmux = ,
,
;
bias-pull-up;
@@ -396,7 +396,7 @@
};
pinctrl_usb_default: usb_default {
- pinmux = ,
+ pinmux = ,
;
bias-disable;
};
@@ -520,17 +520,17 @@
red {
label = "red";
- gpios = <&pioA PIN_PA27 GPIO_ACTIVE_LOW>;
+ gpios = <&pioA PIN_PA10 GPIO_ACTIVE_HIGH>;
};
green {
label = "green";
- gpios = <&pioA PIN_PB1 GPIO_ACTIVE_LOW>;
+ gpios = <&pioA PIN_PB1 GPIO_ACTIVE_HIGH>;
};
blue {
label = "blue";
- gpios = <&pioA PIN_PA31 GPIO_ACTIVE_LOW>;
+ gpios = <&pioA PIN_PA31 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "heartbeat";
};
};
--
2.7.4
[PATCH 0/3] SoM1 EK board fixes
Hi, This series contains fixes for SAMA5D27 SoM1 EK board. It would be good if we will have this in 4.14 version. Thank you, Claudiu Ludovic Desroches (2): ARM: dts: at91: sama5d27_som1_ek: update pinmux/pinconf for LEDs and USB ARM: dts: at91: sama5d27_som1_ek: fix typos Nicolas Ferre (1): ARM: dts: at91: sama5d27_som1_ek: fix USB host vbus arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) -- 2.7.4
[PATCH 3/3] ARM: dts: at91: sama5d27_som1_ek: fix USB host vbus
From: Nicolas Ferre
The USB host has 3 ports so we must specify the entries for each
in the atmel,vbus-gpio property.
The specified pin (PA27) is the vbus for USBB and not USBA.
Signed-off-by: Nicolas Ferre
[claudiu.bez...@microchip.com: change subject to match the desired prefix]
Signed-off-by: Claudiu Beznea
---
arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index be5cd913f274..60cb084a8d92 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -67,7 +67,10 @@
usb1: ohci@0040 {
num-ports = <3>;
- atmel,vbus-gpio = <&pioA PIN_PA27 GPIO_ACTIVE_HIGH>;
+ atmel,vbus-gpio = <0 /* &pioA PIN_PD20 GPIO_ACTIVE_HIGH
*/
+ &pioA PIN_PA27 GPIO_ACTIVE_HIGH
+ 0
+ >;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usb_default>;
status = "okay";
--
2.7.4
[PATCH v4 3/5] i2c: i2c-stm32f7: add driver
This patch adds initial support for the STM32F7 I2C controller. Signed-off-by: M'boumba Cedric Madianga Signed-off-by: Pierre-Yves MORDRET --- Version history: v4: * Fix max I2C Bus clock to 100% * Solve typo issue * Add retries value v3: * Move stm32f7_i2c_match above stm32f7_i2c_driver * of_device_get_match_data instead of of_match_device * Improve I2C Speed DT gathering * dev_err into dev_dbg for Arbitration loss * Remove useless space aligned v2: * Remove st,i2c-timing binding usage * Implement an I2C timings computation algorithm instead of static values(bindings). Algorithm uses generic I2C SCL Falling/Rising bindings and System clock to compute its timings. --- --- drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-stm32f7.c | 972 +++ 3 files changed, 983 insertions(+) create mode 100644 drivers/i2c/busses/i2c-stm32f7.c diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 65fa295..fdcff92 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -920,6 +920,16 @@ config I2C_STM32F4 This driver can also be built as module. If so, the module will be called i2c-stm32f4. +config I2C_STM32F7 + tristate "STMicroelectronics STM32F7 I2C support" + depends on ARCH_STM32 || COMPILE_TEST + help + Enable this option to add support for STM32 I2C controller embedded + in STM32F7 SoCs. + + This driver can also be built as module. If so, the module + will be called i2c-stm32f7. + config I2C_STU300 tristate "ST Microelectronics DDC I2C interface" depends on MACH_U300 diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index 1b2fc81..7816a9f 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -91,6 +91,7 @@ obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o obj-$(CONFIG_I2C_ST) += i2c-st.o obj-$(CONFIG_I2C_STM32F4) += i2c-stm32f4.o +obj-$(CONFIG_I2C_STM32F7) += i2c-stm32f7.o obj-$(CONFIG_I2C_STU300) += i2c-stu300.o obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c new file mode 100644 index 000..47c67b0 --- /dev/null +++ b/drivers/i2c/busses/i2c-stm32f7.c @@ -0,0 +1,972 @@ +/* + * Driver for STMicroelectronics STM32F7 I2C controller + * + * This I2C controller is described in the STM32F75xxx and STM32F74xxx Soc + * reference manual. + * Please see below a link to the documentation: + * http://www.st.com/resource/en/reference_manual/dm00124865.pdf + * + * Copyright (C) M'boumba Cedric Madianga 2017 + * Author: M'boumba Cedric Madianga + * + * This driver is based on i2c-stm32f4.c + * + * License terms: GNU General Public License (GPL), version 2 + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "i2c-stm32.h" + +/* STM32F7 I2C registers */ +#define STM32F7_I2C_CR10x00 +#define STM32F7_I2C_CR20x04 +#define STM32F7_I2C_TIMINGR0x10 +#define STM32F7_I2C_ISR0x18 +#define STM32F7_I2C_ICR0x1C +#define STM32F7_I2C_RXDR 0x24 +#define STM32F7_I2C_TXDR 0x28 + +/* STM32F7 I2C control 1 */ +#define STM32F7_I2C_CR1_ANFOFF BIT(12) +#define STM32F7_I2C_CR1_ERRIE BIT(7) +#define STM32F7_I2C_CR1_TCIE BIT(6) +#define STM32F7_I2C_CR1_STOPIE BIT(5) +#define STM32F7_I2C_CR1_NACKIE BIT(4) +#define STM32F7_I2C_CR1_ADDRIE BIT(3) +#define STM32F7_I2C_CR1_RXIE BIT(2) +#define STM32F7_I2C_CR1_TXIE BIT(1) +#define STM32F7_I2C_CR1_PE BIT(0) +#define STM32F7_I2C_ALL_IRQ_MASK (STM32F7_I2C_CR1_ERRIE \ + | STM32F7_I2C_CR1_TCIE \ + | STM32F7_I2C_CR1_STOPIE \ + | STM32F7_I2C_CR1_NACKIE \ + | STM32F7_I2C_CR1_RXIE \ + | STM32F7_I2C_CR1_TXIE) + +/* STM32F7 I2C control 2 */ +#define STM32F7_I2C_CR2_RELOAD BIT(24) +#define STM32F7_I2C_CR2_NBYTES_MASKGENMASK(23, 16) +#define STM32F7_I2C_CR2_NBYTES(n) (((n) & 0xff) << 16) +#define STM32F7_I2C_CR2_NACK BIT(15) +#define STM32F7_I2C_CR2_STOP
[PATCH v4 5/5] ARM: dts: stm32: Add I2C1 support for STM32F746 eval board
This patch adds I2C1 support for STM32F746 eval board
Signed-off-by: M'boumba Cedric Madianga
Signed-off-by: Pierre-Yves MORDRET
---
Version history:
v4:
v3:
* None
v2:
* Add SCL Rising/Falling time for eval board
---
---
arch/arm/boot/dts/stm32746g-eval.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/stm32746g-eval.dts
b/arch/arm/boot/dts/stm32746g-eval.dts
index 69a9579..9288c7a 100644
--- a/arch/arm/boot/dts/stm32746g-eval.dts
+++ b/arch/arm/boot/dts/stm32746g-eval.dts
@@ -102,3 +102,11 @@
pinctrl-names = "default";
status = "okay";
};
+
+&i2c1 {
+ pinctrl-0 = <&i2c1_pins_b>;
+ pinctrl-names = "default";
+ i2c-scl-rising-time-ns = <185>;
+ i2c-scl-falling-time-ns = <20>;
+ status = "okay";
+};
--
2.7.4
[PATCH v2] ARC: reset: introduce AXS10x reset driver
ARC AXS10x boards support custom IP-block which allows to control
reset signals of selected peripherals. For example DW GMAC, etc...
This block is controlled via memory-mapped register (AKA CREG) which
represents up-to 32 reset lines. This regiter is self-clearing so we
don't need to deassert line after reset.
As of today only the following lines are used:
- DW GMAC - line 5
Signed-off-by: Eugeniy Paltsev
---
Changes v1 -> v2:
* The creg reset register is self-clearing so we don't need to clear it
manually. Fixed it.
* Use reset callback instead of assert/deassert pair.
* Rename reset node in documentation to "reset-controller" for consistency
with the other bindings.
* Use devm_reset_controller_register instead of reset_controller_register
NOTE:
This driver couldn't be replaced by reset-simple driver as we mustn't
read from reset register or clear it.
.../bindings/reset/snps,axs10x-reset.txt | 33 +
MAINTAINERS| 6 ++
drivers/reset/Kconfig | 6 ++
drivers/reset/Makefile | 1 +
drivers/reset/reset-axs10x.c | 83 ++
5 files changed, 129 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reset/snps,axs10x-reset.txt
create mode 100644 drivers/reset/reset-axs10x.c
diff --git a/Documentation/devicetree/bindings/reset/snps,axs10x-reset.txt
b/Documentation/devicetree/bindings/reset/snps,axs10x-reset.txt
new file mode 100644
index 000..32d8435
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/snps,axs10x-reset.txt
@@ -0,0 +1,33 @@
+Binding for the AXS10x reset controller
+
+This binding describes the ARC AXS10x boards custom IP-block which allows
+to control reset signals of selected peripherals. For example DW GMAC, etc...
+This block is controlled via memory-mapped register (AKA CREG) which
+represents up-to 32 reset lines.
+
+As of today only the following lines are used:
+ - DW GMAC - line 5
+
+This binding uses the common reset binding[1].
+
+[1] Documentation/devicetree/bindings/reset/reset.txt
+
+Required properties:
+- compatible: should be "snps,axs10x-reset".
+- reg: should always contain pair address - length: for creg reset
+ bits register.
+- #reset-cells: from common reset binding; Should always be set to 1.
+
+Example:
+ reset: reset-controller@11220 {
+ compatible = "snps,axs10x-reset";
+ #reset-cells = <1>;
+ reg = <0x11220 0x4>;
+ };
+
+Specifying reset lines connected to IP modules:
+ ethernet@ {
+
+ resets = <&reset 5>;
+
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 93dfb9d..f14e804 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12711,6 +12711,12 @@ F: arch/arc/plat-axs10x
F: arch/arc/boot/dts/ax*
F: Documentation/devicetree/bindings/arc/axs10*
+SYNOPSYS AXS10x RESET CONTROLLER DRIVER
+M: Eugeniy Paltsev
+S: Supported
+F: drivers/reset/reset-axs10x.c
+F: Documentation/devicetree/bindings/reset/snps,axs10x-reset.txt
+
SYNOPSYS DESIGNWARE DMAC DRIVER
M: Viresh Kumar
M: Andy Shevchenko
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 52d5251..65d13f4 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -28,6 +28,12 @@ config RESET_ATH79
This enables the ATH79 reset controller driver that supports the
AR71xx SoC reset controller.
+config RESET_AXS10X
+ bool "AXS10x Reset Driver" if COMPILE_TEST
+ default ARC_PLAT_AXS10X
+ help
+ This enables the reset controller driver for AXS10x.
+
config RESET_BERLIN
bool "Berlin Reset Driver" if COMPILE_TEST
default ARCH_BERLIN
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index b62783f..45000a5 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_RESET_A10SR) += reset-a10sr.o
obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_AXS10X) += reset-axs10x.o
obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
obj-$(CONFIG_RESET_HSDK) += reset-hsdk.o
obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
diff --git a/drivers/reset/reset-axs10x.c b/drivers/reset/reset-axs10x.c
new file mode 100644
index 000..afb298e
--- /dev/null
+++ b/drivers/reset/reset-axs10x.c
@@ -0,0 +1,83 @@
+/*
+ * Copyright (C) 2017 Synopsys.
+ *
+ * Synopsys AXS10x reset driver.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+
+#define to_axs10x_rst(p) container_of((p), struct axs10x_rst, rcdev)
+
+#define AXS10X_MAX_RESETS 32
+
+struct axs10x_rst {
+ void __iomem
Re: [PATCH] staging: iio: ad7192: Use the dedicated reset function
On 14.09.2017 15:50, Stefan Popa wrote: SPI host drivers can use DMA to transfer data, so the buffer should be properly allocated. Keeping it on the stack could cause an undefined behavior. The dedicated reset function solves this issue. Signed-off-by: Stefan Popa Acked-by: Michael Hennerich Well done! --- drivers/staging/iio/adc/ad7192.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c index d11c6de..6150d27 100644 --- a/drivers/staging/iio/adc/ad7192.c +++ b/drivers/staging/iio/adc/ad7192.c @@ -223,11 +223,9 @@ static int ad7192_setup(struct ad7192_state *st, struct iio_dev *indio_dev = spi_get_drvdata(st->sd.spi); unsigned long long scale_uv; int i, ret, id; - u8 ones[6]; /* reset the serial interface */ - memset(&ones, 0xFF, 6); - ret = spi_write(st->sd.spi, &ones, 6); + ret = ad_sd_reset(&st->sd, 48); if (ret < 0) goto out; usleep_range(500, 1000); /* Wait for at least 500us */ -- Greetings, Michael -- Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München Sitz der Gesellschaft München, Registergericht München HRB 40368, Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne
[PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
From: l00219569
If fanout_add is preempted after running po-> fanout = match
and before running __fanout_link,
it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink
so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook
or add spin_lock(&po->bind_lock) before po-> fanout = match
this is a patch for add po->bind_lock in fanout_add
test on linux 4.1.12:
./trinity -c setsockopt -C 2 -X &
BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: GW O4.1.12 #1
Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
Call trace:
[] dump_backtrace+0x0/0xf8
[] show_stack+0x20/0x28
[] dump_stack+0xac/0xe4
[] panic+0xf8/0x268
[] __unregister_prot_hook+0xa0/0x144
[] packet_set_ring+0x280/0x5b4
[] packet_setsockopt+0x320/0x950
[] SyS_setsockopt+0xa4/0xd4
Signed-off-by: nixiaoming
Tested-by: wudesheng
---
net/packet/af_packet.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 54a18a8..7a52a3b 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1446,12 +1446,16 @@ static int fanout_add(struct sock *sk, u16 id, u16
type_flags)
default:
return -EINVAL;
}
-
- if (!po->running)
+ spin_lock(&po->bind_lock);
+ if (!po->running) {
+ spin_unlock(&po->bind_lock);
return -EINVAL;
+ }
- if (po->fanout)
+ if (po->fanout) {
+ spin_unlock(&po->bind_lock);
return -EALREADY;
+ }
mutex_lock(&fanout_mutex);
match = NULL;
@@ -1501,6 +1505,7 @@ static int fanout_add(struct sock *sk, u16 id, u16
type_flags)
}
out:
mutex_unlock(&fanout_mutex);
+ spin_unlock(&po->bind_lock);
return err;
}
--
2.10.1
[PATCH] mtd: cfi_cmdset_0002: fix Cypress S29GL flash erase suspend
On UBIFS, Cypress S29GL01GT flash is failed to access occasionally
, and throw below error information and call trace:
MTD get_chip(): chip not ready after erase suspend
UBI error: ubi_io_write: error -5 while writing 512 bytes to
PEB 932:36992, written 0 bytes
Call Trace: [jiffies: 0x1ad9b]
[] dump_stack+0x8/0x34
[] ubi_io_write+0x52c/0x670
[] ubi_eba_write_leb+0xd8/0x758
[] ubifs_leb_write+0xd0/0x178
[] ubifs_wbuf_write_nolock+0x430/0x798
[] ubifs_jnl_write_data+0x1e4/0x348
[] do_writepage+0xc8/0x258
[] __writepage+0x18/0x78
[] write_cache_pages+0x1e0/0x4c8
[] generic_writepages+0x40/0x78
[] __writeback_single_inode+0x58/0x370
[] writeback_sb_inodes+0x2e4/0x498
[] __writeback_inodes_wb+0xc0/0x118
[] wb_writeback+0x234/0x3c0
[] wb_do_writeback+0x230/0x2b0
[] bdi_writeback_workfn+0x84/0x268
[] process_one_work+0x180/0x4d0
[] worker_thread+0x158/0x420
[] kthread+0xa8/0xb0
[] ret_from_kernel_thread+0x10/0x18
After issue erase suspend command, flash don't go to ready state,
and fail to access consequently.
In Cypress S29GL01GT/S29GL512T flash datasheet, the type value of
Erase Resume to next Erase suspend(tERS) is 100 µs.
If Erase Suspend followed Erase Resume without enough delay time,
Erase Suspend would fail to work.
500 μs is chosen because it works well and the latency is acceptable.
Signed-off-by: Chen Bin
---
drivers/mtd/chips/cfi_cmdset_0002.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
b/drivers/mtd/chips/cfi_cmdset_0002.c
index 56aa6b7..c7d18ec 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -513,6 +513,22 @@ static void cfi_fixup_m29ew_delay_after_resume(struct
cfi_private *cfi)
cfi_udelay(500);
}
+static void cfi_fixup_delay_after_resume(struct cfi_private *cfi)
+{
+ cfi_fixup_m29ew_delay_after_resume(cfi);
+
+ /*
+* For Cypress S29GL01GT/S29GL512T flash, the type value of
+* Erase Resume to next Erase suspend(tERS) is 100 µs.
+* If Erase Suspend followed Erase Resume without enough delay time,
+* Erase Suspend would fail to work.
+* 500 μs is chosen because it works well and the latency
+* is acceptable.
+*/
+ if (cfi->mfr == CFI_MFR_AMD && (cfi->id == 0x2801 || cfi->id == 0x2301))
+ cfi_udelay(500);
+}
+
struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary)
{
struct cfi_private *cfi = map->fldrv_priv;
@@ -890,7 +906,7 @@ static void put_chip(struct map_info *map, struct flchip
*chip, unsigned long ad
cfi_fixup_m29ew_erase_suspend(map,
chip->in_progress_block_addr);
map_write(map, cfi->sector_erase_cmd,
chip->in_progress_block_addr);
- cfi_fixup_m29ew_delay_after_resume(cfi);
+ cfi_fixup_delay_after_resume(cfi);
chip->oldstate = FL_READY;
chip->state = FL_ERASING;
break;
--
2.7.4
Helloo
[tip:core/urgent] tools/objtool: Fix memory leak in elf_create_rela_section()
Commit-ID: 5d0be52d44e32ae98b1345e9ecfa6a97783ca2c9 Gitweb: http://git.kernel.org/tip/5d0be52d44e32ae98b1345e9ecfa6a97783ca2c9 Author: Martin Kepplinger AuthorDate: Thu, 14 Sep 2017 08:01:38 +0200 Committer: Ingo Molnar CommitDate: Thu, 14 Sep 2017 16:02:30 +0200 tools/objtool: Fix memory leak in elf_create_rela_section() Let's free the allocated char array 'relaname' before returning, in order to avoid leaking memory. Signed-off-by: Martin Kepplinger Reviewed-by: Don Zickus Acked-by: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: mingo.kernel@gmail.com Link: http://lkml.kernel.org/r/20170914060138.26472-1-mart...@posteo.de Signed-off-by: Ingo Molnar --- tools/objtool/elf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index 6e9f980..1e89a5f 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -508,6 +508,7 @@ struct section *elf_create_rela_section(struct elf *elf, struct section *base) strcat(relaname, base->name); sec = elf_create_section(elf, relaname, sizeof(GElf_Rela), 0); + free(relaname); if (!sec) return NULL;
WINNING NOTIFICATION
Congratulation you have won 85,000,000.00GBP For Claim email:i...@winningsclaimsoffice.com
Re: [RFC Part2 PATCH v3 23/26] KVM: X86: Add memory encryption enabled ops
On Mon, Jul 24, 2017 at 03:03:00PM -0500, Brijesh Singh wrote:
> Extend kvm_x86_ops to add memory_encyption_enabled() ops.
> It returns a
> boolean indicating whether memory encryption is enabled on the VCPU.
You don't need that sentence.
>
> Signed-off-by: Brijesh Singh
> ---
> arch/x86/include/asm/kvm_host.h | 1 +
> arch/x86/kvm/svm.c | 8
> 2 files changed, 9 insertions(+)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index a91aadf..a14d4dd 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1073,6 +1073,7 @@ struct kvm_x86_ops {
> struct kvm_memory_encrypt_ram *ram);
> int (*memory_encryption_unregister_ram)(struct kvm *kvm,
> struct kvm_memory_encrypt_ram *ram);
> + bool (*memory_encryption_enabled)(struct kvm_vcpu *vcpu);
> };
>
> struct kvm_arch_async_pf {
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index cdb1cf3..0bbd050 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -6548,6 +6548,12 @@ static int mem_encrypt_unregister_ram(struct kvm *kvm,
> return 0;
> }
>
> +static bool mem_encrypt_enabled(struct kvm_vcpu *vcpu)
> +{
> + return !!(to_svm(vcpu)->vmcb->control.nested_ctl &
> + SVM_NESTED_CTL_SEV_ENABLE);
You don't need the !!
> +}
> +
> static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
> .cpu_has_kvm_support = has_svm,
> .disabled_by_bios = is_disabled,
> @@ -6664,6 +6670,8 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init =
> {
> .memory_encryption_op = svm_memory_encryption_op,
> .memory_encryption_register_ram = mem_encrypt_register_ram,
> .memory_encryption_unregister_ram = mem_encrypt_unregister_ram,
> + .memory_encryption_enabled = mem_encrypt_enabled,
> +
mem_enc_enabled looks better to me.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
Re: [PATCH] xen: don't compile pv-specific parts if XEN_PV isn't configured
>> Did you make any changes in xenbus_map_ring_valloc_pv()? I don't see any >> but the diff looks pretty big --- I'd expect only the preprocessor >> directives to show up. > I moved the functions to require only one #ifdef (plus 1 for setting > the pv variants). Oh, OK, I didn't notice that. Reviewed-by: Boris Ostrovsky
Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case
(remove most cc's) Hi all, Apologies for digging up this old thread. I am currently looking into whether it is feasible to refactor some of the ACPI PCI quirk code we have so it can apply to more instances of the Synopsys Designware PCIe (i.e., for Marvell and Socionext SOCs), which all suffer from the same issue that type 0 config TLPs are not filtered before being sent out on the link, resulting in devices appearing multiple times. The pci-hisi.c quirk already appears to do exactly what would solve the problem on other SoCs as well. So I will try to refactor this code into something that I could propose for upstream, while probably getting the ARM SBSA authors to offer some guidance that this IP must not be used for new designs. In any case, the chances of any such changes being acceptable upstream are probably higher if we can reuse the exact same quirk as we have already implemented for HiSilicon, so I wonder if anyone from Huawei could comment on some questions I have: - Why does the config space accessor override use 32-bit accesses only for bus #0? Is that really necessary? - Why does the Hisi quirk use different config base addresses for bus #0 and the other buses? Is this simply because the firmware does not use contiguous iATU windows for bus #0 and buses #1 and up? So is there anything mapped in the 1 MB slice at the base of the respective 256 MB mappings that generate type1 config cycles? Having just a shared set of config space accessor overrides would already be an improvement, given that they can be shared with a DT based driver for this IP in ECAM mode as well. Thanks, Ard.
Re: [PATCH v1 1/4] perf annotate: create a new hists to manage multiple events samples
Em Thu, Sep 14, 2017 at 09:03:55AM +0800, Jin, Yao escreveu:
> On 9/11/2017 9:33 AM, Jin, Yao wrote:
> > On 9/8/2017 9:43 PM, Arnaldo Carvalho de Melo wrote:
> >> Em Wed, Aug 16, 2017 at 06:18:33PM +0800, Jin Yao escreveu:
> >>> An issue is found during using perf annotate.
> >>>
> >>> perf record -e cycles,branches ...
> >>> perf annotate main --stdio
> >>>
> >>> The result only shows cycles. It should show both cycles and
> >>> branches on the left side. It works with "--group", but need
> >>> this to work even without groups.
> >>>
> >>> In current design, the hists is per event. So we need a new
> >>> hists to manage the samples for multiple events and use a new
> >>> hist_event data structure to save the map/symbol information
> >>> for per event.
> >> Humm, why do we need another hists? Don't we have one per evsel, don't
> >> we have a evlist from where to get all of those evsels, can't we just
> >> use that to add one column per evsel?
> > I'm considering a case.
> > Suppose we sample 2 events ("branches" and "cache-misses"). The samples of
> > "branches" are hit in function A and the samples of "cache-misses" are hit
> > in function B.
> >
> > The branches evsel has one hists and cache-misses evsel has another hists.
> >
> > The hists of branches evsel has one hist-entry which stands for the
> > function A symbol. The hists of cache-misses evsel has one hist-entry which
> > stands for the function B symbol.
> >
> > If we start to show the instructions in function B from cache-misses evsel,
> > we will lose the function A.
> >
> > Because even if we get the branches evsel from the link in cache-misses
> > evsel, but the function A is before function B and function B has been
> > displayed yet, so the function A is lost.
> >
> > Considering the number of events can be greater than 2, the code will be
> > much more complicated. So using a global hists should be an easy solution.
>
> Could the solution of using a new hists for multiple events be accepted?
>
> Or anything I should update in the patches?
I'm not having time at this moment for doing a proper review, wait a bit
more please.
- Arnaldo
[PATCH] ALSA: oxygen: Xonar DG(X): make model_xonar_dg const
Make this const as it not modified anywhere. It is only used during a
copy operation. Also, add const to the declaration in header.
Signed-off-by: Bhumika Goyal
---
sound/pci/oxygen/xonar_dg.h | 2 +-
sound/pci/oxygen/xonar_dg_mixer.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/pci/oxygen/xonar_dg.h b/sound/pci/oxygen/xonar_dg.h
index d461df3..5a07cda 100644
--- a/sound/pci/oxygen/xonar_dg.h
+++ b/sound/pci/oxygen/xonar_dg.h
@@ -51,6 +51,6 @@ void dump_cs4245_registers(struct oxygen *chip,
void dg_resume(struct oxygen *chip);
void dg_cleanup(struct oxygen *chip);
-extern struct oxygen_model model_xonar_dg;
+extern const struct oxygen_model model_xonar_dg;
#endif
diff --git a/sound/pci/oxygen/xonar_dg_mixer.c
b/sound/pci/oxygen/xonar_dg_mixer.c
index b885dac..d22fbe8 100644
--- a/sound/pci/oxygen/xonar_dg_mixer.c
+++ b/sound/pci/oxygen/xonar_dg_mixer.c
@@ -449,7 +449,7 @@ static int dg_mixer_init(struct oxygen *chip)
return 0;
}
-struct oxygen_model model_xonar_dg = {
+const struct oxygen_model model_xonar_dg = {
.longname = "C-Media Oxygen HD Audio",
.chip = "CMI8786",
.init = dg_init,
--
1.9.1
Re: [PATCH] xen: don't compile pv-specific parts if XEN_PV isn't configured
On 14/09/17 16:00, Boris Ostrovsky wrote:
> On 09/14/2017 08:38 AM, Juergen Gross wrote:
>> xenbus_client.c contains some functions specific for pv guests.
>> Enclose them with #ifdef CONFIG_XEN_PV to avoid compiling them when
>> they are not needed (e.g. on ARM).
>>
>> Signed-off-by: Juergen Gross
>> ---
>> drivers/xen/xenbus/xenbus_client.c | 130
>> +++--
>> 1 file changed, 67 insertions(+), 63 deletions(-)
>>
>> diff --git a/drivers/xen/xenbus/xenbus_client.c
>> b/drivers/xen/xenbus/xenbus_client.c
>> index 82a8866758ee..a1c17000129b 100644
>> --- a/drivers/xen/xenbus/xenbus_client.c
>> +++ b/drivers/xen/xenbus/xenbus_client.c
>> @@ -519,64 +519,6 @@ static int __xenbus_map_ring(struct xenbus_device *dev,
>> return err;
>> }
>>
>> -static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
>> - grant_ref_t *gnt_refs,
>> - unsigned int nr_grefs,
>> - void **vaddr)
>> -{
>> -struct xenbus_map_node *node;
>> -struct vm_struct *area;
>> -pte_t *ptes[XENBUS_MAX_RING_GRANTS];
>> -phys_addr_t phys_addrs[XENBUS_MAX_RING_GRANTS];
>> -int err = GNTST_okay;
>> -int i;
>> -bool leaked;
>> -
>> -*vaddr = NULL;
>> -
>> -if (nr_grefs > XENBUS_MAX_RING_GRANTS)
>> -return -EINVAL;
>> -
>> -node = kzalloc(sizeof(*node), GFP_KERNEL);
>> -if (!node)
>> -return -ENOMEM;
>> -
>> -area = alloc_vm_area(XEN_PAGE_SIZE * nr_grefs, ptes);
>> -if (!area) {
>> -kfree(node);
>> -return -ENOMEM;
>> -}
>> -
>> -for (i = 0; i < nr_grefs; i++)
>> -phys_addrs[i] = arbitrary_virt_to_machine(ptes[i]).maddr;
>> -
>> -err = __xenbus_map_ring(dev, gnt_refs, nr_grefs, node->handles,
>> -phys_addrs,
>> -GNTMAP_host_map | GNTMAP_contains_pte,
>> -&leaked);
>> -if (err)
>> -goto failed;
>> -
>> -node->nr_handles = nr_grefs;
>> -node->pv.area = area;
>> -
>> -spin_lock(&xenbus_valloc_lock);
>> -list_add(&node->next, &xenbus_valloc_pages);
>> -spin_unlock(&xenbus_valloc_lock);
>> -
>> -*vaddr = area->addr;
>> -return 0;
>> -
>> -failed:
>> -if (!leaked)
>> -free_vm_area(area);
>> -else
>> -pr_alert("leaking VM area %p size %u page(s)", area, nr_grefs);
>> -
>> -kfree(node);
>> -return err;
>> -}
>> -
>> struct map_ring_valloc_hvm
>> {
>> unsigned int idx;
>> @@ -725,6 +667,65 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev,
>> void *vaddr)
>> }
>> EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>>
>> +#ifdef CONFIG_XEN_PV
>> +static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
>> + grant_ref_t *gnt_refs,
>> + unsigned int nr_grefs,
>> + void **vaddr)
>> +{
>> +struct xenbus_map_node *node;
>> +struct vm_struct *area;
>> +pte_t *ptes[XENBUS_MAX_RING_GRANTS];
>> +phys_addr_t phys_addrs[XENBUS_MAX_RING_GRANTS];
>> +int err = GNTST_okay;
>> +int i;
>> +bool leaked;
>> +
>> +*vaddr = NULL;
>> +
>> +if (nr_grefs > XENBUS_MAX_RING_GRANTS)
>> +return -EINVAL;
>> +
>> +node = kzalloc(sizeof(*node), GFP_KERNEL);
>> +if (!node)
>> +return -ENOMEM;
>> +
>> +area = alloc_vm_area(XEN_PAGE_SIZE * nr_grefs, ptes);
>> +if (!area) {
>> +kfree(node);
>> +return -ENOMEM;
>> +}
>> +
>> +for (i = 0; i < nr_grefs; i++)
>> +phys_addrs[i] = arbitrary_virt_to_machine(ptes[i]).maddr;
>> +
>> +err = __xenbus_map_ring(dev, gnt_refs, nr_grefs, node->handles,
>> +phys_addrs,
>> +GNTMAP_host_map | GNTMAP_contains_pte,
>> +&leaked);
>> +if (err)
>> +goto failed;
>> +
>> +node->nr_handles = nr_grefs;
>> +node->pv.area = area;
>> +
>> +spin_lock(&xenbus_valloc_lock);
>> +list_add(&node->next, &xenbus_valloc_pages);
>> +spin_unlock(&xenbus_valloc_lock);
>> +
>> +*vaddr = area->addr;
>> +return 0;
>> +
>> +failed:
>> +if (!leaked)
>> +free_vm_area(area);
>> +else
>> +pr_alert("leaking VM area %p size %u page(s)", area, nr_grefs);
>> +
>> +kfree(node);
>> +return err;
>> +}
>> +
>
> Did you make any changes in xenbus_map_ring_valloc_pv()? I don't see any
> but the diff looks pretty big --- I'd expect only the preprocessor
> directives to show up.
I moved the functions to require only one #ifdef (plus 1 for setting
the pv variants).
Juergen
[PATCH] lib: add module support to string tests
Extract the string test code into its own source file, to allow to
compile it either to a loadable module, or builtin into the kernel.
Fixes: 03270c13c5ffaa6a ("lib/string.c: add testcases for memset16/32/64")
Signed-off-by: Geert Uytterhoeven
---
lib/Kconfig | 2 +-
lib/Makefile | 1 +
lib/string.c | 141 --
lib/test_string.c | 141 ++
4 files changed, 143 insertions(+), 142 deletions(-)
create mode 100644 lib/test_string.c
diff --git a/lib/Kconfig b/lib/Kconfig
index a85e6f76add5c914..7c013b5ca19ed240 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -573,6 +573,6 @@ config PRIME_NUMBERS
tristate
config STRING_SELFTEST
- bool "Test string functions"
+ tristate "Test string functions"
endmenu
diff --git a/lib/Makefile b/lib/Makefile
index 469ce5e24e4f9bb6..917d08a2e685d6e8 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -39,6 +39,7 @@ obj-y += bcd.o div64.o sort.o parser.o debug_locks.o
random32.o \
bsearch.o find_bit.o llist.o memweight.o kfifo.o \
percpu-refcount.o percpu_ida.o rhashtable.o reciprocal_div.o \
once.o refcount.o usercopy.o errseq.o
+obj-$(CONFIG_STRING_SELFTEST) += test_string.o
obj-y += string_helpers.o
obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
obj-y += hexdump.o
diff --git a/lib/string.c b/lib/string.c
index 9921dc202db440a0..198148bb61fd1b0d 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -1051,144 +1051,3 @@ void fortify_panic(const char *name)
BUG();
}
EXPORT_SYMBOL(fortify_panic);
-
-#ifdef CONFIG_STRING_SELFTEST
-#include
-#include
-
-static __init int memset16_selftest(void)
-{
- unsigned i, j, k;
- u16 v, *p;
-
- p = kmalloc(256 * 2 * 2, GFP_KERNEL);
- if (!p)
- return -1;
-
- for (i = 0; i < 256; i++) {
- for (j = 0; j < 256; j++) {
- memset(p, 0xa1, 256 * 2 * sizeof(v));
- memset16(p + i, 0xb1b2, j);
- for (k = 0; k < 512; k++) {
- v = p[k];
- if (k < i) {
- if (v != 0xa1a1)
- goto fail;
- } else if (k < i + j) {
- if (v != 0xb1b2)
- goto fail;
- } else {
- if (v != 0xa1a1)
- goto fail;
- }
- }
- }
- }
-
-fail:
- kfree(p);
- if (i < 256)
- return (i << 24) | (j << 16) | k;
- return 0;
-}
-
-static __init int memset32_selftest(void)
-{
- unsigned i, j, k;
- u32 v, *p;
-
- p = kmalloc(256 * 2 * 4, GFP_KERNEL);
- if (!p)
- return -1;
-
- for (i = 0; i < 256; i++) {
- for (j = 0; j < 256; j++) {
- memset(p, 0xa1, 256 * 2 * sizeof(v));
- memset32(p + i, 0xb1b2b3b4, j);
- for (k = 0; k < 512; k++) {
- v = p[k];
- if (k < i) {
- if (v != 0xa1a1a1a1)
- goto fail;
- } else if (k < i + j) {
- if (v != 0xb1b2b3b4)
- goto fail;
- } else {
- if (v != 0xa1a1a1a1)
- goto fail;
- }
- }
- }
- }
-
-fail:
- kfree(p);
- if (i < 256)
- return (i << 24) | (j << 16) | k;
- return 0;
-}
-
-static __init int memset64_selftest(void)
-{
- unsigned i, j, k;
- u64 v, *p;
-
- p = kmalloc(256 * 2 * 8, GFP_KERNEL);
- if (!p)
- return -1;
-
- for (i = 0; i < 256; i++) {
- for (j = 0; j < 256; j++) {
- memset(p, 0xa1, 256 * 2 * sizeof(v));
- memset64(p + i, 0xb1b2b3b4b5b6b7b8ULL, j);
- for (k = 0; k < 512; k++) {
- v = p[k];
- if (k < i) {
- if (v != 0xa1a1a1a1a1a1a1a1ULL)
- goto fail;
- } else if (k < i + j) {
- if (v != 0xb1b2b3b4b5b6b7b8ULL)
- goto fail;
- } else {
- if (v != 0xa1a1a
Re: [PATCH] xen: don't compile pv-specific parts if XEN_PV isn't configured
On 09/14/2017 08:38 AM, Juergen Gross wrote:
> xenbus_client.c contains some functions specific for pv guests.
> Enclose them with #ifdef CONFIG_XEN_PV to avoid compiling them when
> they are not needed (e.g. on ARM).
>
> Signed-off-by: Juergen Gross
> ---
> drivers/xen/xenbus/xenbus_client.c | 130
> +++--
> 1 file changed, 67 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/xen/xenbus/xenbus_client.c
> b/drivers/xen/xenbus/xenbus_client.c
> index 82a8866758ee..a1c17000129b 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -519,64 +519,6 @@ static int __xenbus_map_ring(struct xenbus_device *dev,
> return err;
> }
>
> -static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
> - grant_ref_t *gnt_refs,
> - unsigned int nr_grefs,
> - void **vaddr)
> -{
> - struct xenbus_map_node *node;
> - struct vm_struct *area;
> - pte_t *ptes[XENBUS_MAX_RING_GRANTS];
> - phys_addr_t phys_addrs[XENBUS_MAX_RING_GRANTS];
> - int err = GNTST_okay;
> - int i;
> - bool leaked;
> -
> - *vaddr = NULL;
> -
> - if (nr_grefs > XENBUS_MAX_RING_GRANTS)
> - return -EINVAL;
> -
> - node = kzalloc(sizeof(*node), GFP_KERNEL);
> - if (!node)
> - return -ENOMEM;
> -
> - area = alloc_vm_area(XEN_PAGE_SIZE * nr_grefs, ptes);
> - if (!area) {
> - kfree(node);
> - return -ENOMEM;
> - }
> -
> - for (i = 0; i < nr_grefs; i++)
> - phys_addrs[i] = arbitrary_virt_to_machine(ptes[i]).maddr;
> -
> - err = __xenbus_map_ring(dev, gnt_refs, nr_grefs, node->handles,
> - phys_addrs,
> - GNTMAP_host_map | GNTMAP_contains_pte,
> - &leaked);
> - if (err)
> - goto failed;
> -
> - node->nr_handles = nr_grefs;
> - node->pv.area = area;
> -
> - spin_lock(&xenbus_valloc_lock);
> - list_add(&node->next, &xenbus_valloc_pages);
> - spin_unlock(&xenbus_valloc_lock);
> -
> - *vaddr = area->addr;
> - return 0;
> -
> -failed:
> - if (!leaked)
> - free_vm_area(area);
> - else
> - pr_alert("leaking VM area %p size %u page(s)", area, nr_grefs);
> -
> - kfree(node);
> - return err;
> -}
> -
> struct map_ring_valloc_hvm
> {
> unsigned int idx;
> @@ -725,6 +667,65 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev,
> void *vaddr)
> }
> EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
>
> +#ifdef CONFIG_XEN_PV
> +static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
> + grant_ref_t *gnt_refs,
> + unsigned int nr_grefs,
> + void **vaddr)
> +{
> + struct xenbus_map_node *node;
> + struct vm_struct *area;
> + pte_t *ptes[XENBUS_MAX_RING_GRANTS];
> + phys_addr_t phys_addrs[XENBUS_MAX_RING_GRANTS];
> + int err = GNTST_okay;
> + int i;
> + bool leaked;
> +
> + *vaddr = NULL;
> +
> + if (nr_grefs > XENBUS_MAX_RING_GRANTS)
> + return -EINVAL;
> +
> + node = kzalloc(sizeof(*node), GFP_KERNEL);
> + if (!node)
> + return -ENOMEM;
> +
> + area = alloc_vm_area(XEN_PAGE_SIZE * nr_grefs, ptes);
> + if (!area) {
> + kfree(node);
> + return -ENOMEM;
> + }
> +
> + for (i = 0; i < nr_grefs; i++)
> + phys_addrs[i] = arbitrary_virt_to_machine(ptes[i]).maddr;
> +
> + err = __xenbus_map_ring(dev, gnt_refs, nr_grefs, node->handles,
> + phys_addrs,
> + GNTMAP_host_map | GNTMAP_contains_pte,
> + &leaked);
> + if (err)
> + goto failed;
> +
> + node->nr_handles = nr_grefs;
> + node->pv.area = area;
> +
> + spin_lock(&xenbus_valloc_lock);
> + list_add(&node->next, &xenbus_valloc_pages);
> + spin_unlock(&xenbus_valloc_lock);
> +
> + *vaddr = area->addr;
> + return 0;
> +
> +failed:
> + if (!leaked)
> + free_vm_area(area);
> + else
> + pr_alert("leaking VM area %p size %u page(s)", area, nr_grefs);
> +
> + kfree(node);
> + return err;
> +}
> +
Did you make any changes in xenbus_map_ring_valloc_pv()? I don't see any
but the diff looks pretty big --- I'd expect only the preprocessor
directives to show up.
-boris
Re: [RFC Part2 PATCH v3 22/26] KVM: SVM: Pin guest memory when SEV is active
On Mon, Jul 24, 2017 at 03:02:59PM -0500, Brijesh Singh wrote:
> The SEV memory encryption engine uses a tweak such that two identical
> plaintexts at different location will have a different ciphertexts.
plaintexts or plaintext pages? also, s/a //
> So swapping or moving ciphertexts of two pages will not result in
> plaintexts being swapped. Relocating (or migrating) a physical backing
s/a //
> pages for SEV guest will require some additional steps. The current SEV
"for a SEV guest"
> key management spec does not provide commands to swap or migrate (move)
> ciphertexts. For now, we pin the guest memory registered through
> KVM_MEMORY_ENCRYPT_REGISTER_RAM ioctl.
>
> Signed-off-by: Brijesh Singh
> ---
> arch/x86/include/asm/kvm_host.h | 1 +
> arch/x86/kvm/svm.c | 113
>
> 2 files changed, 114 insertions(+)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 150177e..a91aadf 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -747,6 +747,7 @@ struct kvm_sev_info {
> unsigned int handle;/* firmware handle */
> unsigned int asid; /* asid for this guest */
> int sev_fd; /* SEV device fd */
> + struct list_head ram_list; /* list of registered ram */
regions_list I guess.
> };
>
> struct kvm_arch {
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 75dcaa9..cdb1cf3 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -333,8 +333,19 @@ static int sev_asid_new(void);
> static void sev_asid_free(int asid);
> static void sev_deactivate_handle(struct kvm *kvm, int *error);
> static void sev_decommission_handle(struct kvm *kvm, int *error);
> +static void sev_unpin_memory(struct page **pages, unsigned long npages);
Unneeded.
> +
> #define __sme_page_pa(x) __sme_set(page_to_pfn(x) << PAGE_SHIFT)
>
> +struct kvm_sev_pin_ram {
sev_pinned_region
> + struct list_head list;
> + unsigned long npages;
> + struct page **pages;
> + struct kvm_memory_encrypt_ram userspace;
That member would need a comment what it is.
> +};
> +
> +static void __mem_encrypt_unregister_ram(struct kvm_sev_pin_ram *ram);
Move code so that you don't need that one.
> +
> static bool svm_sev_enabled(void)
> {
> return !!max_sev_asid;
> @@ -385,6 +396,11 @@ static inline void sev_set_fd(struct kvm *kvm, int fd)
> to_sev_info(kvm)->sev_fd = fd;
> }
>
> +static inline struct list_head *sev_get_ram_list(struct kvm *kvm)
> +{
> + return &to_sev_info(kvm)->ram_list;
> +}
> +
> static inline void mark_all_dirty(struct vmcb *vmcb)
> {
> vmcb->control.clean = 0;
> @@ -1566,10 +1582,24 @@ static void sev_firmware_uninit(void)
> static void sev_vm_destroy(struct kvm *kvm)
> {
> int state, error;
> + struct list_head *pos, *q;
> + struct kvm_sev_pin_ram *ram;
> + struct list_head *head = sev_get_ram_list(kvm);
Please sort function local variables declaration in a reverse christmas
tree order:
longest_variable_name;
shorter_var_name;
even_shorter;
i;
>
> if (!sev_guest(kvm))
> return;
>
> + /*
> + * if userspace was terminated before unregistering the memory region
> + * then lets unpin all the registered memory.
> + */
> + if (!list_empty(head)) {
> + list_for_each_safe(pos, q, head) {
> + ram = list_entry(pos, struct kvm_sev_pin_ram, list);
> + __mem_encrypt_unregister_ram(ram);
You don't need the local "ram" varible here:
__mem_encrypt_unregister_ram(list_entry(pos, struct
kvm_sev_pin_ram, list));
> + }
> + }
> +
> /* release the firmware resources for this guest */
> if (sev_get_handle(kvm)) {
> sev_deactivate_handle(kvm, &error);
> @@ -5640,6 +5670,7 @@ static int sev_guest_init(struct kvm *kvm, struct
> kvm_sev_cmd *argp)
> sev_set_active(kvm);
> sev_set_asid(kvm, asid);
> sev_set_fd(kvm, argp->sev_fd);
> + INIT_LIST_HEAD(sev_get_ram_list(kvm));
> ret = 0;
> e_err:
> fdput(f);
> @@ -6437,6 +6468,86 @@ static int svm_memory_encryption_op(struct kvm *kvm,
> void __user *argp)
> return r;
> }
>
> +static int mem_encrypt_register_ram(struct kvm *kvm,
> + struct kvm_memory_encrypt_ram *ram)
> +{
Please call that arg "regions" or so. "ram" is strange. In the other
functions too.
> + struct list_head *head = sev_get_ram_list(kvm);
> + struct kvm_sev_pin_ram *pin_ram;
> +
> + if (!sev_guest(kvm))
> + return -ENOTTY;
> +
> + pin_ram = kzalloc(sizeof(*pin_ram), GFP_KERNEL);
> + if (!pin_ram)
> + return -ENOMEM;
> +
> + pin_ram->pages = sev_pin_memory(ram->address, ram->size,
> + &pin_ram->npages, 1);
L
Re: [v4 07/11] soc/fsl/qbman: Rework portal mapping calls for ARM/PPC
On Thu, Aug 24, 2017 at 04:37:51PM -0400, Roy Pledge wrote:
> diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c
> index ff8998f..e31c843 100644
> --- a/drivers/soc/fsl/qbman/bman.c
> +++ b/drivers/soc/fsl/qbman/bman.c
> @@ -154,7 +154,7 @@ struct bm_mc {
> };
>
> struct bm_addr {
> - void __iomem *ce; /* cache-enabled */
> + void *ce; /* cache-enabled */
> void __iomem *ci; /* cache-inhibited */
> };
You dropped __iomem from ce, which is fine since it is now set via
memremap. However, I haven't seen (at least not in this patch), a change
to bm_ce_in() which still uses __raw_readl().
(it may be worth checking this code with sparse, it may warn about this)
> diff --git a/drivers/soc/fsl/qbman/bman_portal.c
> b/drivers/soc/fsl/qbman/bman_portal.c
> index 39b39c8..bb03503 100644
> --- a/drivers/soc/fsl/qbman/bman_portal.c
> +++ b/drivers/soc/fsl/qbman/bman_portal.c
> @@ -91,7 +91,6 @@ static int bman_portal_probe(struct platform_device *pdev)
> struct device_node *node = dev->of_node;
> struct bm_portal_config *pcfg;
> struct resource *addr_phys[2];
> - void __iomem *va;
> int irq, cpu;
>
> pcfg = devm_kmalloc(dev, sizeof(*pcfg), GFP_KERNEL);
> @@ -123,23 +122,34 @@ static int bman_portal_probe(struct platform_device
> *pdev)
> }
> pcfg->irq = irq;
>
> - va = ioremap_prot(addr_phys[0]->start, resource_size(addr_phys[0]), 0);
> - if (!va) {
> - dev_err(dev, "ioremap::CE failed\n");
> + /*
> + * TODO: Ultimately we would like to use a cacheable/non-shareable
> + * (coherent) mapping for the portal on both architectures but that
> + * isn't currently available in the kernel. Because of HW differences
> + * PPC needs to be mapped cacheable while ARM SoCs will work with non
> + * cacheable mappings
> + */
This comment mentions "cacheable/non-shareable (coherent)". Was this
meant for ARM platforms? Because non-shareable is not coherent, nor is
this combination guaranteed to work with different CPUs and
interconnects.
> +#ifdef CONFIG_PPC
> + /* PPC requires a cacheable/non-coherent mapping of the portal */
> + pcfg->addr_virt_ce = memremap(addr_phys[0]->start,
> + resource_size(addr_phys[0]), MEMREMAP_WB);
> +#else
> + /* ARM can use a write combine mapping. */
> + pcfg->addr_virt_ce = memremap(addr_phys[0]->start,
> + resource_size(addr_phys[0]), MEMREMAP_WC);
> +#endif
Nitpick: you could define something like QBMAN_MAP_ATTR to be different
between PPC and the rest and just keep a single memremap() call.
One may complain that "ce" is no longer "cache enabled" but I'm
personally fine to keep the same name for historical reasons.
> diff --git a/drivers/soc/fsl/qbman/dpaa_sys.h
> b/drivers/soc/fsl/qbman/dpaa_sys.h
> index 81a9a5e..0a1d573 100644
> --- a/drivers/soc/fsl/qbman/dpaa_sys.h
> +++ b/drivers/soc/fsl/qbman/dpaa_sys.h
> @@ -51,12 +51,12 @@
>
> static inline void dpaa_flush(void *p)
> {
> + /*
> + * Only PPC needs to flush the cache currently - on ARM the mapping
> + * is non cacheable
> + */
> #ifdef CONFIG_PPC
> flush_dcache_range((unsigned long)p, (unsigned long)p+64);
> -#elif defined(CONFIG_ARM)
> - __cpuc_flush_dcache_area(p, 64);
> -#elif defined(CONFIG_ARM64)
> - __flush_dcache_area(p, 64);
> #endif
> }
Dropping the private API cache maintenance is fine and the memory is WC
now for ARM (mapping to Normal NonCacheable). However, do you require
any barriers here? Normal NC doesn't guarantee any ordering.
> diff --git a/drivers/soc/fsl/qbman/qman_portal.c
> b/drivers/soc/fsl/qbman/qman_portal.c
> index cbacdf4..41fe33a 100644
> --- a/drivers/soc/fsl/qbman/qman_portal.c
> +++ b/drivers/soc/fsl/qbman/qman_portal.c
> @@ -224,7 +224,6 @@ static int qman_portal_probe(struct platform_device *pdev)
> struct device_node *node = dev->of_node;
> struct qm_portal_config *pcfg;
> struct resource *addr_phys[2];
> - void __iomem *va;
> int irq, cpu, err;
> u32 val;
>
> @@ -262,23 +261,34 @@ static int qman_portal_probe(struct platform_device
> *pdev)
> }
> pcfg->irq = irq;
>
> - va = ioremap_prot(addr_phys[0]->start, resource_size(addr_phys[0]), 0);
> - if (!va) {
> - dev_err(dev, "ioremap::CE failed\n");
> + /*
> + * TODO: Ultimately we would like to use a cacheable/non-shareable
> + * (coherent) mapping for the portal on both architectures but that
> + * isn't currently available in the kernel. Because of HW differences
> + * PPC needs to be mapped cacheable while ARM SoCs will work with non
> + * cacheable mappings
> + */
Same comment as above non non-shareable.
> +#ifdef CONFIG_PPC
> + /* PPC requires a cacheable mapping of the portal */
> + pcfg->addr_virt_ce = memremap(addr_phys[0]->start,
> +
[PATCH] z3fold: fix stale list handling
Fix the situation when clear_bit() is called for page->private before
the page pointer is actually assigned. While at it, remove work_busy()
check because it is costly and does not give 100% guarantee anyway.
Signed-of-by: Vitaly Wool
---
mm/z3fold.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index b04fa3ba1bf2..b2ba2ba585f3 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -250,6 +250,7 @@ static void __release_z3fold_page(struct z3fold_header
*zhdr, bool locked)
WARN_ON(!list_empty(&zhdr->buddy));
set_bit(PAGE_STALE, &page->private);
+ clear_bit(NEEDS_COMPACTING, &page->private);
spin_lock(&pool->lock);
if (!list_empty(&page->lru))
list_del(&page->lru);
@@ -303,7 +304,6 @@ static void free_pages_work(struct work_struct *w)
list_del(&zhdr->buddy);
if (WARN_ON(!test_bit(PAGE_STALE, &page->private)))
continue;
- clear_bit(NEEDS_COMPACTING, &page->private);
spin_unlock(&pool->stale_lock);
cancel_work_sync(&zhdr->work);
free_z3fold_page(page);
@@ -624,10 +624,8 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t
size, gfp_t gfp,
* stale pages list. cancel_work_sync() can sleep so we must make
* sure it won't be called in case we're in atomic context.
*/
- if (zhdr && (can_sleep || !work_pending(&zhdr->work) ||
- !unlikely(work_busy(&zhdr->work {
+ if (zhdr && (can_sleep || !work_pending(&zhdr->work))) {
list_del(&zhdr->buddy);
- clear_bit(NEEDS_COMPACTING, &page->private);
spin_unlock(&pool->stale_lock);
if (can_sleep)
cancel_work_sync(&zhdr->work);
--
2.11.0
Re: [PATCH 14/16] gpio: Add support for banked GPIO controllers
On Fri, Sep 1, 2017 at 8:57 PM, Thierry Reding wrote: > From: Thierry Reding > > Some GPIO controllers are subdivided into multiple logical blocks called > banks (or ports). This is often caused by the design assigning separate > resources, such as register regions or interrupts, to each bank, or some > set of banks. > > This commit adds support for describing controllers that have such a > banked design and provides common code for dealing with them. > > Signed-off-by: Thierry Reding This patch makes me really happy. It pulls in a lot of weirdness to the OF core and creates a coherent way of handling these "banked" GPIO chips. CC to Tony to make sure he checks that OMAP is ready to use this too. I would change num_pins to num_lines everywhere in this patch, so if you resend the series, please fix that. > +void gpio_irq_chip_banked_handler(struct irq_desc *desc) Maybe we should name this gpio_irq_chip_banked_chained_handler() since it only deals with chained IRQs? Sooner or later we will have a nested bank too... Otherwise it looks fine. Yours, Linus Walleij
Re: [PATCH] staging: iio: ad7192: Use the dedicated reset function
On 09/14/2017 03:50 PM, Stefan Popa wrote: > SPI host drivers can use DMA to transfer data, so the buffer should be > properly allocated. > Keeping it on the stack could cause an undefined behavior. > > The dedicated reset function solves this issue. > > Signed-off-by: Stefan Popa Acked-by: Lars-Peter Clausen Thanks. > --- > drivers/staging/iio/adc/ad7192.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/staging/iio/adc/ad7192.c > b/drivers/staging/iio/adc/ad7192.c > index d11c6de..6150d27 100644 > --- a/drivers/staging/iio/adc/ad7192.c > +++ b/drivers/staging/iio/adc/ad7192.c > @@ -223,11 +223,9 @@ static int ad7192_setup(struct ad7192_state *st, > struct iio_dev *indio_dev = spi_get_drvdata(st->sd.spi); > unsigned long long scale_uv; > int i, ret, id; > - u8 ones[6]; > > /* reset the serial interface */ > - memset(&ones, 0xFF, 6); > - ret = spi_write(st->sd.spi, &ones, 6); > + ret = ad_sd_reset(&st->sd, 48); > if (ret < 0) > goto out; > usleep_range(500, 1000); /* Wait for at least 500us */ >
Re: [PATCH 00/16] gpio: Tight IRQ chip integration and banked infrastructure
On Fri, Sep 1, 2017 at 8:57 PM, Thierry Reding wrote: > here's the latest series of patches that implement the tighter IRQ chip > integration as well as the banked GPIO infrastructure that we had > discussed a couple of weeks/months back. Yes it has become really tasty now, don't you think :) I really like the series. Banks are handled in the core, exactly as I wanted. I will likely go in and change some things I don't like, like switching num_pins in the bank to num_lines. I have preferred that terminology to avoid confusion with pin control. So GPIO chips have lines, not pins. But it's so minor that I can fix it up if you don't want to. We also need to go in and patch Documentation/gpio/driver.txt to represent the current best practice. But that can be later, separate patch. > The first couple of patches are mostly preparatory work in order to > consolidate all IRQ chip related fields in a new structure and create > the base functionality for adding IRQ chips. > > After that, I've added the Tegra186 GPIO support patch that makes use of > the new tight integration. > > To round things off the new banked GPIO infrastructure is added (along > with some more preparatory work), followed by the conversion of the two > Tegra GPIO drivers to the new infrastructure. I have put all on a branch for pushing to the test builders to begin with. Then I plan to make one branch with all infrastructure patches (patches 1-10, 12-14) and pull that into devel, then apply patch 11 and 15-16 directly on devel. That way other subsystems (pinctrl ...) can pull in the infrastructure for people adding new gpiochips this cycle. > Any thoughts on this? I'd like to target 4.15 with this, Me, too. > unless you'd be > willing to take this into 4.14, which I doubt at this point. The absence > of a GPIO driver has been hampering Tegra186 support upstream for a > while now, so it'd be good to make progress on this. Sorry about that. Let's move ahead with this now, it is neat and clean. What I want (as maintainer) is a bit of fingerpointing at the drivers that need to be converted to use the new banking infrastructure so they don't stay with their old crappy design pattern. OMAP is a clear candidate right? (Added Tony to CC...) Who else? Yours, Linus Walleij
Re: keyboard backlight max_brightness bug on Dell Latitude E6410
Adding Gabriele to thread, IIRC you have machine which uses "supported keyboard light brightness levels" Can you look at this bug, if your machine is affected by it too? Important parts in ouptput: > ... --info > Supported Keyboard light brightness levels : 10 > ... --get-status > Current keyboard light level : 9 Gabriel, can you play with this tool, which values can be set via --set-level= parameter? Is 10 accepted? --get-status can be used to check if value was accepted. On Thursday 14 September 2017 06:35:15 Gabriel M. Elder wrote: > > output from smbios-keyboard-ctl --info: > > Libsmbios version : 2.3.0 > smbios-keyboard-ctl version : 2.3.0 > > Capabilities of KeyBoard Illumination on your system: > --- > Supported USER Selectable Modes : >Always OFF >Auto: ALS- and input-activity-based On; input-activity based Off >Auto: Input-activity-based On; input-activity based Off > > Supported Keyboard illumination type : Backlight > > Supports Keyboard illumination on : > Any Keystroke > Touchpad activity > Pointing stick > > Can configure Keyboard illumination timeout unit in : > Seconds > Minutes > Hours > > Supported Keyboard light brightness levels : 10 > > Maximum acceptable seconds timeout value : 255 > > Maximum acceptable minutes timeout value : 255 > > Maximum acceptable hours timeout value : 12 > > Maximum acceptable days timeout value : 0 > > > output from smbios-keyboard-ctl --get-status: > > Helper function to print current status of keyboard illumination > > Current status of KeyBoard Illumination setting on your system: > --- > > Configured mode state: >Auto: Input-activity-based On; input-activity based Off > > Your Keyboard will illumination on: > Any Keystroke > Touchpad activity > Pointing stick > > Keyboard illumination timeout has bee set at: 10 Seconds > > Current setting of ALS value that turns the light on or off: 18 > Current ALS Reading : 16 > Current keyboard light level : 9 > > > Original Message > Subject: Re: keyboard backlight max_brightness bug on Dell Latitude > E6410 > From: Pali Rohár > Date: Thu, September 14, 2017 3:06 am > To: "Gabriel M. Elder" > Cc: dvh...@infradead.org, a...@infradead.org, > platform-driver-...@vger.kernel.org, linux-kernel@vger.kernel.org > > On Monday 11 September 2017 23:25:27 Gabriel M. Elder wrote: > > Hi all, > > Hans de Goede, one of the upower maintainers, suggested I alert you all to > > this bug: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=100041 > > > > and the new one I filed via the kernel bugzilla: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=196913 > > "keyboard backlight max_brightness value outside allowable range on Dell > > Latitude E6410 laptop" > > > > Please check it out at your earliest convenience. > > > > thanks, > > - Gabriel > > Hi Gabriel, please avoid sending such html emails to mailing list as it > is hard to read them and also you have a very big chance that email > would be eaten by spam filter or other developers would completely > ignore it... > > To debug your problem, can you run smbios-keyboard-ctl tool from the > libsmbios project? https://github.com/dell/libsmbios > > We would need output from --info parameter and also from --get-status. > -- Pali Rohár pali.ro...@gmail.com
[PATCH] staging: iio: ad7192: Use the dedicated reset function
SPI host drivers can use DMA to transfer data, so the buffer should be properly allocated. Keeping it on the stack could cause an undefined behavior. The dedicated reset function solves this issue. Signed-off-by: Stefan Popa --- drivers/staging/iio/adc/ad7192.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c index d11c6de..6150d27 100644 --- a/drivers/staging/iio/adc/ad7192.c +++ b/drivers/staging/iio/adc/ad7192.c @@ -223,11 +223,9 @@ static int ad7192_setup(struct ad7192_state *st, struct iio_dev *indio_dev = spi_get_drvdata(st->sd.spi); unsigned long long scale_uv; int i, ret, id; - u8 ones[6]; /* reset the serial interface */ - memset(&ones, 0xFF, 6); - ret = spi_write(st->sd.spi, &ones, 6); + ret = ad_sd_reset(&st->sd, 48); if (ret < 0) goto out; usleep_range(500, 1000); /* Wait for at least 500us */ -- 2.7.4
Re: [v4 05/11] soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check
On Thu, Aug 24, 2017 at 04:37:49PM -0400, Roy Pledge wrote: > From: Claudiu Manoil > > Not relevant and arch dependent. Overkill for PPC. > > Signed-off-by: Claudiu Manoil > Signed-off-by: Roy Pledge > --- > drivers/soc/fsl/qbman/dpaa_sys.h | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/soc/fsl/qbman/dpaa_sys.h > b/drivers/soc/fsl/qbman/dpaa_sys.h > index 2ce394a..f85c319 100644 > --- a/drivers/soc/fsl/qbman/dpaa_sys.h > +++ b/drivers/soc/fsl/qbman/dpaa_sys.h > @@ -49,10 +49,6 @@ > #define DPAA_PORTAL_CE 0 > #define DPAA_PORTAL_CI 1 > > -#if (L1_CACHE_BYTES != 32) && (L1_CACHE_BYTES != 64) > -#error "Unsupported Cacheline Size" > -#endif Maybe this check was for a reason on PPC as it uses WB memory mappings for some of the qbman descriptors (which IIUC fit within a cacheline). You could add a check for CONFIG_PPC if you think there is any chance of this constant going higher. -- Catalin
Re: [v4 03/11] dt-bindings: soc/fsl: Update reserved memory binding for QBMan
On Thu, Aug 24, 2017 at 04:37:47PM -0400, Roy Pledge wrote: > Updates the QMan and BMan device tree bindings for reserved memory > nodes. This makes the reserved memory allocation compatible with > the shared-dma-pool usage. > > Signed-off-by: Roy Pledge > --- > Documentation/devicetree/bindings/soc/fsl/bman.txt | 12 +- > Documentation/devicetree/bindings/soc/fsl/qman.txt | 26 > -- This needs reviewed by the DT maintainers. -- Catalin
Re: [v4 01/11] soc/fsl/qbman: Use shared-dma-pool for BMan private memory allocations
On Thu, Aug 24, 2017 at 04:37:45PM -0400, Roy Pledge wrote:
> --- a/drivers/soc/fsl/qbman/bman_ccsr.c
> +++ b/drivers/soc/fsl/qbman/bman_ccsr.c
[...]
> @@ -201,6 +202,38 @@ static int fsl_bman_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> + /*
> + * If FBPR memory wasn't defined using the qbman compatible string
> + * try using the of_reserved_mem_device method
> + */
> + if (!fbpr_a) {
> + ret = of_reserved_mem_device_init(dev);
> + if (ret) {
> + dev_err(dev, "of_reserved_mem_device_init() failed
> 0x%x\n",
> + ret);
> + return -ENODEV;
> + }
> + mem_node = of_parse_phandle(dev->of_node, "memory-region", 0);
> + if (mem_node) {
> + ret = of_property_read_u64(mem_node, "size", &size);
> + if (ret) {
> + dev_err(dev, "FBPR: of_address_to_resource
> fails 0x%x\n",
> + ret);
> + return -ENODEV;
> + }
> + fbpr_sz = size;
> + } else {
> + dev_err(dev, "No memory-region found for FBPR\n");
> + return -ENODEV;
> + }
> + if (!dma_zalloc_coherent(dev, fbpr_sz, &fbpr_a, 0)) {
> + dev_err(dev, "Alloc FBPR memory failed\n");
> + return -ENODEV;
> + }
> + }
At a quick look, I think I spotted this pattern a couple of more times
in the subsequent patch. Could it be moved to a common function?
--
Catalin
Re: [patch V2 04/29] parisc: Use lockup_detector_stop()
On Thu, Sep 14, 2017 at 10:59:17AM +0200, Helge Deller wrote: > * Thomas Gleixner : > > The broken lockup_detector_suspend/resume() interface is going away. Use > > the new lockup_detector_soft_poweroff() interface to stop the watchdog from > > the busy looping power off routine. > > > > Signed-off-by: Thomas Gleixner > > Cc: Don Zickus > > Cc: Chris Metcalf > > Cc: linux-par...@vger.kernel.org > > Cc: Peter Zijlstra > > Cc: Sebastian Siewior > > Cc: Nicholas Piggin > > Cc: Ulrich Obergfell > > Cc: Borislav Petkov > > Cc: Andrew Morton > > Cc: Helge Deller > > Link: http://lkml.kernel.org/r/20170831073053.281414...@linutronix.de > > > > --- > > arch/parisc/kernel/process.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > --- a/arch/parisc/kernel/process.c > > +++ b/arch/parisc/kernel/process.c > > @@ -146,7 +146,7 @@ void machine_power_off(void) > > > > /* prevent soft lockup/stalled CPU messages for endless loop. */ > > rcu_sysrq_start(); > > - lockup_detector_suspend(); > > + lockup_detector_soft_poweroff(); > > for (;;); > > } > > Thomas, thanks for cleaning that up. > You may add to patches 03/04: > Acked-by: Helge Deller > > > On a side-note, there is sadly no general function like > turn_off_all_kind_of_runtime_hang_detectors() > which turns off *all* detectors at once (including soft lockup detector). > I've seen another detector complaing at runtime that we were hanging > here. I would need to dig up more info if you are interested... There are numerous detectors I have seen over the years: rcu, clocksource, hard/soft, hang, fs, network, wq?, etc.. I am not sure it is easy to put them all in one place or makes sense. I know working with the kvm folks, when they swap back in, the real clock can do a massive jump forward and causes a flood of warnings such that they had to 'touch' all of them before running the vm again. Cheers, Don
Re: [v8 1/4] mm, oom: refactor the oom_kill_process() function
On Mon 11-09-17 14:17:39, Roman Gushchin wrote:
> The oom_kill_process() function consists of two logical parts:
> the first one is responsible for considering task's children as
> a potential victim and printing the debug information.
> The second half is responsible for sending SIGKILL to all
> tasks sharing the mm struct with the given victim.
>
> This commit splits the oom_kill_process() function with
> an intention to re-use the the second half: __oom_kill_process().
>
> The cgroup-aware OOM killer will kill multiple tasks
> belonging to the victim cgroup. We don't need to print
> the debug information for the each task, as well as play
> with task selection (considering task's children),
> so we can't use the existing oom_kill_process().
>
> Signed-off-by: Roman Gushchin
> Cc: Michal Hocko
> Cc: Vladimir Davydov
> Cc: Johannes Weiner
> Cc: Tetsuo Handa
> Cc: David Rientjes
> Cc: Andrew Morton
> Cc: Tejun Heo
> Cc: kernel-t...@fb.com
> Cc: cgro...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@kvack.org
Acked-by: Michal Hocko
> ---
> mm/oom_kill.c | 123
> +++---
> 1 file changed, 65 insertions(+), 58 deletions(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 99736e026712..f061b627092c 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -804,68 +804,12 @@ static bool task_will_free_mem(struct task_struct *task)
> return ret;
> }
>
> -static void oom_kill_process(struct oom_control *oc, const char *message)
> +static void __oom_kill_process(struct task_struct *victim)
> {
> - struct task_struct *p = oc->chosen;
> - unsigned int points = oc->chosen_points;
> - struct task_struct *victim = p;
> - struct task_struct *child;
> - struct task_struct *t;
> + struct task_struct *p;
> struct mm_struct *mm;
> - unsigned int victim_points = 0;
> - static DEFINE_RATELIMIT_STATE(oom_rs, DEFAULT_RATELIMIT_INTERVAL,
> - DEFAULT_RATELIMIT_BURST);
> bool can_oom_reap = true;
>
> - /*
> - * If the task is already exiting, don't alarm the sysadmin or kill
> - * its children or threads, just give it access to memory reserves
> - * so it can die quickly
> - */
> - task_lock(p);
> - if (task_will_free_mem(p)) {
> - mark_oom_victim(p);
> - wake_oom_reaper(p);
> - task_unlock(p);
> - put_task_struct(p);
> - return;
> - }
> - task_unlock(p);
> -
> - if (__ratelimit(&oom_rs))
> - dump_header(oc, p);
> -
> - pr_err("%s: Kill process %d (%s) score %u or sacrifice child\n",
> - message, task_pid_nr(p), p->comm, points);
> -
> - /*
> - * If any of p's children has a different mm and is eligible for kill,
> - * the one with the highest oom_badness() score is sacrificed for its
> - * parent. This attempts to lose the minimal amount of work done while
> - * still freeing memory.
> - */
> - read_lock(&tasklist_lock);
> - for_each_thread(p, t) {
> - list_for_each_entry(child, &t->children, sibling) {
> - unsigned int child_points;
> -
> - if (process_shares_mm(child, p->mm))
> - continue;
> - /*
> - * oom_badness() returns 0 if the thread is unkillable
> - */
> - child_points = oom_badness(child,
> - oc->memcg, oc->nodemask, oc->totalpages);
> - if (child_points > victim_points) {
> - put_task_struct(victim);
> - victim = child;
> - victim_points = child_points;
> - get_task_struct(victim);
> - }
> - }
> - }
> - read_unlock(&tasklist_lock);
> -
> p = find_lock_task_mm(victim);
> if (!p) {
> put_task_struct(victim);
> @@ -939,6 +883,69 @@ static void oom_kill_process(struct oom_control *oc,
> const char *message)
> }
> #undef K
>
> +static void oom_kill_process(struct oom_control *oc, const char *message)
> +{
> + struct task_struct *p = oc->chosen;
> + unsigned int points = oc->chosen_points;
> + struct task_struct *victim = p;
> + struct task_struct *child;
> + struct task_struct *t;
> + unsigned int victim_points = 0;
> + static DEFINE_RATELIMIT_STATE(oom_rs, DEFAULT_RATELIMIT_INTERVAL,
> + DEFAULT_RATELIMIT_BURST);
> +
> + /*
> + * If the task is already exiting, don't alarm the sysadmin or kill
> + * its children or threads, just give it access to memory reserves
> + * so it can die quickly
> + */
> + task_lock(p);
> + if (task_will_free_mem(p)) {
> +
Re: [v8 0/4] cgroup-aware OOM killer
On Wed 13-09-17 14:56:07, Roman Gushchin wrote: > On Wed, Sep 13, 2017 at 02:29:14PM +0200, Michal Hocko wrote: [...] > > I strongly believe that comparing only leaf memcgs > > is more straightforward and it doesn't lead to unexpected results as > > mentioned before (kill a small memcg which is a part of the larger > > sub-hierarchy). > > One of two main goals of this patchset is to introduce cgroup-level > fairness: bigger cgroups should be affected more than smaller, > despite the size of tasks inside. I believe the same principle > should be used for cgroups. Yes bigger cgroups should be preferred but I fail to see why bigger hierarchies should be considered as well if they are not kill-all. And whether non-leaf memcgs should allow kill-all is not entirely clear to me. What would be the usecase? Consider that it might be not your choice (as a user) how deep is your leaf memcg. I can already see how people complain that their memcg has been killed just because it was one level deeper in the hierarchy... I would really start simple and only allow kill-all on leaf memcgs and only compare leaf memcgs & root. If we ever need to kill whole hierarchies then allow kill-all on intermediate memcgs as well and then consider cumulative consumptions only on those that have kill-all enabled. Or do I miss any reasonable usecase that would suffer from such a semantic? -- Michal Hocko SUSE Labs
Re: [PATCH manpages] stat.2: correct AT_NO_AUTOMOUNT text and general revisions.
Hi Neil,
On 25 August 2017 at 07:32, NeilBrown wrote:
>
> Expand on the relationship between fstatat() and the other
> three functions, and improve the description of AT_NO_AUTOMOUNT.
> Specifically, both stat() and lstat() act the same way
> with respect to automounts, and that behavior matches
> fstatat with the AT_NO_AUTOMOUNT flag.
>
> The text in the NOTES is removed and places with the text for
> AT_NO_AUTOMOUNT to improve cohesion.
>
> New text for a difference to be introduced in 4.14.
Has the 4.14 piece gone in?
Cheers,
Michael
> Cc: Ian Kent
> Signed-off-by: NeilBrown
> ---
>
> Thanks Ian and Michael. I considered your input and read
> through the whole again, and came up with this which is
> quite different to what I suggested before.
>
> If this patch is applied, the result probably shouldn't be released
> until the relevant patch actually lands in Linus's tree.
>
> NeilBrown
>
>
> man2/stat.2 | 37 -
> 1 file changed, 24 insertions(+), 13 deletions(-)
>
> diff --git a/man2/stat.2 b/man2/stat.2
> index d8a9e76b3d9f..c6dddfe0d3a7 100644
> --- a/man2/stat.2
> +++ b/man2/stat.2
> @@ -260,9 +260,12 @@ For further information on the above fields, see
> .SS fstatat()
> The
> .BR fstatat ()
> -system call operates in exactly the same way as
> +system call is a more general interface for accessing file information
> +which can still provide exactly the behavior of each of
> .BR stat (),
> -except for the differences described here.
> +.BR lstat (),
> +and
> +.BR fstat ().
> .PP
> If the pathname given in
> .I pathname
> @@ -272,6 +275,8 @@ referred to by the file descriptor
> (rather than relative to the current working directory of
> the calling process, as is done by
> .BR stat ()
> +and
> +.BR lstat ()
> for a relative pathname).
> .PP
> If
> @@ -284,7 +289,9 @@ then
> .I pathname
> is interpreted relative to the current working
> directory of the calling process (like
> -.BR stat ()).
> +.BR stat ()
> +and
> +.BR lstat ()).
> .PP
> If
> .I pathname
> @@ -307,7 +314,11 @@ is an empty string, operate on the file referred to by
> flag).
> In this case,
> .I dirfd
> -can refer to any type of file, not just a directory.
> +can refer to any type of file, not just a directory, and
> +the behavior of
> +.BR fstatat ()
> +is similar to that of
> +.BR fstat ().
> If
> .I dirfd
> is
> @@ -324,6 +335,8 @@ Don't automount the terminal ("basename") component of
> if it is a directory that is an automount point.
> This allows the caller to gather attributes of an automount point
> (rather than the location it would mount).
> +Since Linux 4.14, also don't instantiate a non-existent name in an
> +on-demand directory such as used for automounter indirect maps.
> This flag can be used in tools that scan directories
> to prevent mass-automounting of a directory of automount points.
> The
> @@ -333,6 +346,13 @@ This flag is Linux-specific; define
> .B _GNU_SOURCE
> .\" Before glibc 2.16, defining _ATFILE_SOURCE sufficed
> to obtain its definition.
> +Both
> +.BR stat ()
> +and
> +.BR lstat ()
> +act as though
> +.B AT_NO_AUTOMOUNT
> +was set.
> .TP
> .B AT_SYMLINK_NOFOLLOW
> If
> @@ -474,15 +494,6 @@ fields may be less portable.
> The interpretation differs between systems,
> and possibly on a single system when NFS mounts are involved.)
> .SH NOTES
> -On Linux,
> -.BR lstat ()
> -will generally not trigger automounter action, whereas
> -.BR stat ()
> -will (but see the description of the
> -.BR fstatat ()
> -.B AT_NO_AUTOMOUNT
> -fag, above).
> -.\"
> .SS Timestamp fields
> Older kernels and older standards did not support nanosecond timestamp
> fields.
> --
> 2.14.0.rc0.dirty
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH] mtd: spi-nor: stm32-quadspi: avoid unintialized return code
Hi Arnd,
On Thu, Sep 14, 2017 at 1:06 PM, Arnd Bergmann wrote:
> If we send zero-length data to stm32_qspi_tx_poll() on older
> compiler versions such as gcc-4.6, we get warned that the
> return code is uninitialized:
>
> drivers/mtd/spi-nor/stm32-quadspi.c:248:2: error: ‘ret’ may be used
> uninitialized in this function [-Werror=uninitialized]
>
> On newer compiler versions, the return code is always zero
> in this case, as the local variable gets optimized away and
> is assumed to be zero after the loop completes without error.
>
> This changes the function to instead return -EINVAL if it
> ever gets called with a zero length buffer.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82203
> Signed-off-by: Arnd Bergmann
> ---
> drivers/mtd/spi-nor/stm32-quadspi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/stm32-quadspi.c
> b/drivers/mtd/spi-nor/stm32-quadspi.c
> index 86c0931543c5..711cfe7aa4bf 100644
> --- a/drivers/mtd/spi-nor/stm32-quadspi.c
> +++ b/drivers/mtd/spi-nor/stm32-quadspi.c
> @@ -227,7 +227,7 @@ static int stm32_qspi_tx_poll(struct stm32_qspi *qspi,
> void (*tx_fifo)(u8 *, void __iomem *);
> u32 len = cmd->len, sr;
> u8 *buf = cmd->buf;
> - int ret;
> + int ret = -EINVAL;
>
> if (cmd->qspimode == CCR_FMODE_INDW)
> tx_fifo = stm32_qspi_write_fifo;
See also "[PATCH] mtd: spi-nor: stm32-quadspi: Fix uninitialized error
return code"
(https://patchwork.kernel.org/patch/9842173/)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: keyboard backlight max_brightness bug on Dell Latitude E6410
output from smbios-keyboard-ctl --info: Libsmbios version : 2.3.0 smbios-keyboard-ctl version : 2.3.0 Capabilities of KeyBoard Illumination on your system: --- Supported USER Selectable Modes : Always OFF Auto: ALS- and input-activity-based On; input-activity based Off Auto: Input-activity-based On; input-activity based Off Supported Keyboard illumination type : Backlight Supports Keyboard illumination on : Any Keystroke Touchpad activity Pointing stick Can configure Keyboard illumination timeout unit in : Seconds Minutes Hours Supported Keyboard light brightness levels : 10 Maximum acceptable seconds timeout value : 255 Maximum acceptable minutes timeout value : 255 Maximum acceptable hours timeout value : 12 Maximum acceptable days timeout value : 0 output from smbios-keyboard-ctl --get-status: Helper function to print current status of keyboard illumination Current status of KeyBoard Illumination setting on your system: --- Configured mode state: Auto: Input-activity-based On; input-activity based Off Your Keyboard will illumination on: Any Keystroke Touchpad activity Pointing stick Keyboard illumination timeout has bee set at: 10 Seconds Current setting of ALS value that turns the light on or off: 18 Current ALS Reading : 16 Current keyboard light level : 9 Original Message Subject: Re: keyboard backlight max_brightness bug on Dell Latitude E6410 From: Pali Rohár Date: Thu, September 14, 2017 3:06 am To: "Gabriel M. Elder" Cc: dvh...@infradead.org, a...@infradead.org, platform-driver-...@vger.kernel.org, linux-kernel@vger.kernel.org On Monday 11 September 2017 23:25:27 Gabriel M. Elder wrote: > Hi all, > Hans de Goede, one of the upower maintainers, suggested I alert you all to > this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=100041 > > and the new one I filed via the kernel bugzilla: > > https://bugzilla.kernel.org/show_bug.cgi?id=196913 > "keyboard backlight max_brightness value outside allowable range on Dell > Latitude E6410 laptop" > > Please check it out at your earliest convenience. > > thanks, > - Gabriel Hi Gabriel, please avoid sending such html emails to mailing list as it is hard to read them and also you have a very big chance that email would be eaten by spam filter or other developers would completely ignore it... To debug your problem, can you run smbios-keyboard-ctl tool from the libsmbios project? https://github.com/dell/libsmbios We would need output from --info parameter and also from --get-status. -- Pali Rohár pali.ro...@gmail.com
Re: [v8 0/4] cgroup-aware OOM killer
On Wed 13-09-17 13:46:08, David Rientjes wrote: > On Wed, 13 Sep 2017, Michal Hocko wrote: > > > > > This patchset makes the OOM killer cgroup-aware. > > > > > > > > v8: > > > > - Do not kill tasks with OOM_SCORE_ADJ -1000 > > > > - Make the whole thing opt-in with cgroup mount option control > > > > - Drop oom_priority for further discussions > > > > > > Nack, we specifically require oom_priority for this to function > > > correctly, > > > otherwise we cannot prefer to kill from low priority leaf memcgs as > > > required. > > > > While I understand that your usecase might require priorities I do not > > think this part missing is a reason to nack the cgroup based selection > > and kill-all parts. This can be done on top. The only important part > > right now is the current selection semantic - only leaf memcgs vs. size > > of the hierarchy). I strongly believe that comparing only leaf memcgs > > is more straightforward and it doesn't lead to unexpected results as > > mentioned before (kill a small memcg which is a part of the larger > > sub-hierarchy). > > > > The problem is that we cannot enable the cgroup-aware oom killer and > oom_group behavior because, without oom priorities, we have no ability to > influence the cgroup that it chooses. It is doing two things: providing > more fairness amongst cgroups by selecting based on cumulative usage > rather than single large process (good!), and effectively is removing all > userspace control of oom selection (bad). We want the former, but it > needs to be coupled with support so that we can protect vital cgroups, > regardless of their usage. I understand that your usecase needs a more fine grained control over the selection but that alone is not a reason to nack the implementation which doesn't provide it (yet). > It is certainly possible to add oom priorities on top before it is merged, > but I don't see why it isn't part of the patchset. Because the semantic of the priority for non-leaf memcgs is not fully clear and I would rather have the core of the functionality merged before this is sorted out. > We need it before its > merged to avoid users playing with /proc/pid/oom_score_adj to prevent any > killing in the most preferable memcg when they could have simply changed > the oom priority. I am sorry but I do not really understand your concern. Are you suggesting that users would start oom disable all tasks in a memcg to give it a higher priority? Even if that was the case why should such an abuse be a blocker for generic memcg aware oom killer being merged? -- Michal Hocko SUSE Labs
Re: [RFC Part2 PATCH v3 21/26] KVM: SVM: Add support for SEV DEBUG_ENCRYPT command
On Mon, Jul 24, 2017 at 03:02:58PM -0500, Brijesh Singh wrote:
> The command copies a plain text into guest memory and encrypts it using
> the VM encryption key. The command will be used for debug purposes
> (e.g setting breakpoint through gdbserver)
"setting a breakpoint" or "setting breakpoints"
>
> Signed-off-by: Brijesh Singh
> ---
> arch/x86/kvm/svm.c | 174
> +
> 1 file changed, 174 insertions(+)
>
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 933384a..75dcaa9 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -6214,6 +6214,176 @@ static int sev_dbg_decrypt(struct kvm *kvm, struct
> kvm_sev_cmd *argp)
> return ret;
> }
>
> +static int __sev_dbg_enc(struct kvm *kvm, unsigned long __user vaddr,
__sev_dbg_encrypt
> + unsigned long paddr, unsigned long __user dst_vaddr,
> + unsigned long dst_paddr, int size, int *error)
> +{
> + struct page *src_tpage = NULL;
> + struct page *dst_tpage = NULL;
> + int ret, len = size;
> +
> + /*
> + * Debug encrypt command works with 16-byte aligned inputs. Function
> + * handles the alingment issue as below:
> + *
> + * case 1
> + * If source buffer is not 16-byte aligned then we copy the data from
> + * source buffer into a PAGE aligned intermediate (src_tpage) buffer
"page-aligned"
> + * and use this intermediate buffer as source buffer
> + *
> + * case 2
> + * If destination buffer or length is not 16-byte aligned then:
> + * - decrypt portion of destination buffer into intermediate buffer
> + * (dst_tpage)
> + * - copy the source data into intermediate buffer
> + * - use the intermediate buffer as source buffer
> + */
> +
> + /* If source is not aligned (case 1) */
So put the whole case 1 comment here directly - no need to reference it
again. Ditto for case 2 below.
> + if (!IS_ALIGNED(vaddr, 16)) {
> + src_tpage = alloc_page(GFP_KERNEL);
> + if (!src_tpage)
> + return -ENOMEM;
> +
> + if (copy_from_user(page_address(src_tpage),
> + (uint8_t *)vaddr, size)) {
Let it stick out.
> + __free_page(src_tpage);
> + return -EFAULT;
> + }
> + paddr = __sme_page_pa(src_tpage);
> +
> + /* flush the caches to ensure that DRAM has recent contents */
That comment needs improving.
> + clflush_cache_range(page_address(src_tpage), PAGE_SIZE);
> + }
> +
> + /* If destination buffer or length is not aligned (case 2) */
> + if (!IS_ALIGNED(dst_vaddr, 16) || !IS_ALIGNED(size, 16)) {
> + int dst_offset;
> +
> + dst_tpage = alloc_page(GFP_KERNEL);
> + if (!dst_tpage) {
> + ret = -ENOMEM;
> + goto e_free;
> + }
> +
> + /* decrypt destination buffer into intermediate buffer */
> + ret = __sev_dbg_dec(kvm,
> + round_down(dst_paddr, 16),
> + 0,
> + (unsigned long)page_address(dst_tpage),
> + __sme_page_pa(dst_tpage),
> + round_up(size, 16),
> + error);
> + if (ret)
> + goto e_free;
> +
> + dst_offset = dst_paddr & 15;
> +
> + /*
> + * modify the intermediate buffer with data from source
> + * buffer.
> + */
> + if (src_tpage)
> + memcpy(page_address(dst_tpage) + dst_offset,
> + page_address(src_tpage), size);
> + else {
> + if (copy_from_user(page_address(dst_tpage) + dst_offset,
> + (void *) vaddr, size)) {
Let it stick out.
> + ret = -EFAULT;
> + goto e_free;
> + }
> + }
> +
> +
> + /* use intermediate buffer as source */
> + paddr = __sme_page_pa(dst_tpage);
> +
> + /* flush the caches to ensure that DRAM gets recent updates */
Comment needs improvement.
> + clflush_cache_range(page_address(dst_tpage), PAGE_SIZE);
> +
> + /* now we have length and destination buffer aligned */
> + dst_paddr = round_down(dst_paddr, 16);
> + len = round_up(size, 16);
> + }
> +
> + ret = __sev_dbg_enc_dec(kvm, paddr, dst_paddr, len, error, true);
< newline here.
> +e_free:
> + if (src_tpage)
> + __free_page(src_tpage);
> + if (dst_tpage)
> + __free_page(dst_tpage);
> + return ret;
> +}
> +
> +static int sev_dbg_encrypt(struct kv
Re: [PATCH v2 2/3] livepatch: add atomic replace
On Tue 2017-09-12 23:47:32, Jason Baron wrote:
>
>
> On 09/12/2017 01:35 AM, Petr Mladek wrote:
> > On Mon 2017-09-11 23:46:28, Jason Baron wrote:
> >> On 09/11/2017 09:53 AM, Petr Mladek wrote:
> >>> On Wed 2017-08-30 17:38:44, Jason Baron wrote:
> diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
> index 8d3df55..ee6d18b 100644
> --- a/include/linux/livepatch.h
> +++ b/include/linux/livepatch.h
> @@ -119,10 +121,12 @@ struct klp_object {
> * @mod:reference to the live patch module
> * @objs: object entries for kernel objects to be patched
> * @immediate: patch all funcs immediately, bypassing safety mechanisms
> + * @replace:replace all funcs, reverting functions that are no
> longer patched
> * @list: list node for global list of registered patches
> * @kobj: kobject for sysfs resources
> * @obj_list: head of list for dynamically allocated struct klp_object
> * @enabled:the patch is enabled (but operation may be incomplete)
> + * @replaced: the patch has been replaced an can not be re-enabled
> >>>
> >>> I finally understand why you do this. I forgot that even disabled
> >>> patches are still in klp_patch list.
> >>>
> >>> This makes some sense for patches that fix different bugs and
> >>> touch the same function. They should be applied and enabled
> >>> in the right order because a later patch for the same function
> >>> must be based on the code from the previous one.
> >>>
> >>> It makes less sense for cummulative patches that we use in kGraft.
> >>> There basically every patch has the "replace" flag set. If
> >>> we enable one patch it simply replaces any other one. Then
> >>> ordering is not important. Each patch is standalone and
> >>> consistent on its own.
> >>>
> >>>
> >>> I see two problems with your approach. One is cosmetic.
> >>> The names of the two flags replace/replaced are too similar.
> >>> It is quite prone for mistakes ;-)
> >>>
> >>> Second, we could not remove module where any function is patched
> >>> usign the "immediate" flag. But people might want to revert
> >>> to this patch if the last one does not work as expected.
> >>> After all the main purpose of livepatching is to fix
> >>> problems without a system reboot. Therefore we should
> >>> allow to enable the replaced patches even without
> >>> removing the module.
> >>>
> >>
> >> If the livepatch has the 'replace' bit set and not the 'immediate' bit,
> >> then I believe that we could remove *all* types of previous livepatches
> >> even if they have the 'immediate' flag set. That is, because of the
> >> consistency model, we are sure that we are running only functions from
> >> the cumulative replace patch.
> >
> > You are partly right. The catch is if a function was previously
> > patched using the immediate flag and the function is not longer
> > patched by the new cumulative patch with the 'replace' flag.
> > Then we need to create "no_op" for the function and the 'no_op'
> > must inherit the immediate flag set. Then the consistency model
> > does not guarantee that the code from the older patch is not running
> > and we could not allow to remove the older patch.
> >
>
> Agreed - the replace patch should 'inherit' the immediate flag. This
> raises the question, what if say two patches have the immediate flag set
> differently for the same function? This would be unlikely since
> presumably we would set it the same way for all patches. In this case, I
> think a reasonable thing to do would be to 'inherit' the immediate flag
> from the immediately proceeding patch, since that's the one we are
> reverting from.
Good question. I would personally use immediate = false if there
is a mismatch. It might block the transition but it will not break
the consistency model. The consistency and stability is always
more important. The user could always either revert the transition.
Or there is going to be a way to force it.
IMHO, there are basically two approaches how to use
the immediate flag:
Some people might enable it only when it is safe and needed
to patch a function that might sleep for long. These people
either want to be on the safe side. Or they want to remove
disabled patches when possible. Your approach would be fine
in this case.
Another group of people might always enable the immediate flag
when it is safe. They would disable the immediate flag only when
the patch does a semantic change. These people want to keep
it easy and avoid potential troubles with a transition
(complex code, might get blocked, ...). This is the reason
to be conservative. The cumulative patch is going to replace
all existing patches. If one of them needed the complex
consistency model, we should use it as well.
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index 6004be3..21cecc5 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@
Re: [PATCH 00/12] x86/crypto: Fix RBP usage in several crypto .S files
On Thu, Sep 14, 2017 at 11:16:12AM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > I'm still looking at the other one (sha512-avx2), but so far I haven't > > found a way to speed it back up. > > Here's a couple of very quick observations with possible optimizations: > > AFAICS the main effect of the RBP fixes is the introduction of a memory load > into > the critical path, into the body unrolled loop: > > + mov frame_TBL(%rsp), TBL > vpaddq (TBL), Y_0, XFER > vmovdqa XFER, frame_XFER(%rsp) > FOUR_ROUNDS_AND_SCHED > > Both 'TLB' and 'T1' are mapped to R12, which is why TBL has to be spilled to > be > reloaded from the stack. > > 1) > > Note how R12 is used immediately, right in the next instruction: > > vpaddq (TBL), Y_0, XFER > > I.e. the RBP fixes lengthen the program order data dependencies - that's a > new > constraint and a few extra cycles per loop iteration if the workload is > address-generator bandwidth limited on that. > > A simple way to ease that constraint would be to move the 'TLB' load up into > the > loop, body, to the point where 'T1' is used for the last time - which is: > > > mov a, T1 # T1 = a# MAJB > and c, T1 # T1 = a&c # MAJB > > add y0, y2 # y2 = S1 + CH # -- > or T1, y3 # y3 = MAJ = (a|c)&b)|(a&c) # MAJ > > + mov frame_TBL(%rsp), TBL > > add y1, h # h = k + w + h + S0# -- > > add y2, d # d = k + w + h + d + S1 + CH = d + t1 # -- > > add y2, h # h = k + w + h + S0 + S1 + CH = t1 + S0# -- > add y3, h # h = t1 + S0 + MAJ # -- > > Note how this moves up the 'TLB' reload by 4 instructions. > > 2) > > If this does not get back performance, then maybe another reason is that it's > cache access latency limited, in which case a more involved optimization > would be > to look at the register patterns and usages: > > > first-use last-useuse-length > a: #10 #29 20 > b: #24 #24 1 > c: #14 #30 17 > d: #23 #34 12 > e: #11 #20 10 > f: #15 #15 1 > g: #18 #27 10 > h: #13 #36 24 > > y0: #11 #31 21 > y1: #12 #33 22 > y2: #15 #35 21 > y3: #10 #36 27 > > T1: #16 #32 17 > > The 'first-use' colums shows the number of the instruction within the loop > body > that the register gets used - with '#1' denoting the first instruction ad #36 > the > last instruction, the 'last-use' column is showing the last instruction, and > the > 'use-length' colum shows the 'window' in which a register is used. > > What we want are the registers that are used the most tightly, i.e. these two: > > b: #24 #24 1 > f: #15 #15 1 > > Of these two 'f' is the best one, because it has an earlier use and longer > cooldown. > > If alias 'TBL' with 'f' then we could reload 'TLB' for the next iteration > very > early on: > > mov f, y2 # y2 = f# CH > + mov frame_TBL(%rsp), TBL > rorx$34, a, T1 # T1 = a >> 34 # S0B > > And there will be 21 instructions that don't depend on TLB after this, plenty > of > time for the load to be generated and propagated. > > NOTE: my pseudo-patch is naive, due to the complication caused by the > RotateState > macro name rotation. It's still fundamentally possible I believe, it's just > that > 'TBL' has to be rotated too, together with the other varibles. > > 3) > > If even this does not help, because the workload is ucode-cache limited, and > the > extra reloads pushed the critical path just beyond some cache limit, then > another > experiment to try would be to roll _back_ the loop some more: instead of 4x > FOUR_ROUNDS_AND_SCHED unrolled loops, try just having 2. > > The CPU should still be smart enough with 2x interleaving of the loop body, > and > the extra branches should be relatively small and we could get back some > performance. > > In theory ... > > 4) > > If the workloa
Re: [PATCH RFC 0/3] A few round_pipe_size() and pipe-max-size fixups
Hello Joe, On 5 September 2017 at 16:44, Joe Lawrence wrote: > While backporting Michael's "pipe: fix limit handling" [1] patchset to a > distro-kernel, Mikulas noticed that current upstream pipe limit handling > contains a few problems: > > 1 - round_pipe_size() nr_pages overflow on 32bit: this would > subsequently try roundup_pow_of_two(0), which is undefined. > > 2 - visible non-rounded pipe-max-size value: there is no mutual > exclusion or protection between the time pipe_max_size is assigned > a raw value from proc_dointvec_minmax() and when it is rounded. > > 3 - procfs signed wrap: echo'ing a large number into > /proc/sys/fs/pipe-max-size and then cat'ing it back out shows a > negative value. > > > This RFC serves as a bug report and a contains a few possible fixes. > There may be better / more consistent ways to fix the overflows and > procfs bugs, but I figured I'd throw an RFC w/code out there for initial > conversation. Suggestions welcome! Thank for working on this. I have no improvements to suggest. The patches all look sane to me. For the whole series: Reviewed-by: MIchael Kerrisk Cheers, Michael > Testing > === > > Patch 1 - 32bit overflow > > From userspace: > > fcntl(fd, F_SETPIPE_SZ, 0x); > > - Before the fix, return value was 4096 as pipe size overflowed and > was set to 4096 > > - After the fix, returns -1 and sets errno EINVAL, pipe size remains > untouched > > > Patch 2 - non-rounded pipe-max-size value > - > Keep plugging in values that need to be rounded: > > while (true); do echo 1048570 > /proc/sys/fs/pipe-max-size; done > > and in another terminal, loop around reading the value: > > time (while (true); do SIZE=$(cat /proc/sys/fs/pipe-max-size); [[ $(( $SIZE > % 4096 )) -ne 0 ]] && break; done; echo "$SIZE") > 1048570 > > real0m46.213s > user0m29.688s > sys 0m20.042s > > after the fix, the test loop never encountered a non-page-rounded value. > > > Patch 3 - procfs signed wrap > > Before: > > % echo 2147483647 >/proc/sys/fs/pipe-max-size > % cat /proc/sys/fs/pipe-max-size > -2147483648 > > After: > > % echo 2147483647 >/proc/sys/fs/pipe-max-size > % cat /proc/sys/fs/pipe-max-size > 2147483648 > > > Joe Lawrence (3): > pipe: avoid round_pipe_size() nr_pages overflow on 32-bit > pipe: protect pipe_max_size access with a mutex > pipe: match pipe_max_size data type with procfs > > fs/pipe.c | 48 +--- > kernel/sysctl.c | 2 +- > 2 files changed, 42 insertions(+), 8 deletions(-) > > -- > 1.8.3.1 > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request
[Sorry for a later reply]
On Wed 06-09-17 13:35:25, Joonsoo Kim wrote:
> From: Joonsoo Kim
>
> Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that
> important to reserve.
I am still not convinced this is a good idea. I do agree that reserving
memory in both HIGHMEM and MOVABLE is just wasting memory but removing
the reserve from the highmem as well will result that an oom victim will
allocate from lower zones and that might have unexpected side effects.
Can we simply leave HIGHMEM reserve and only remove it from the movable
zone if both are present?
> When ZONE_MOVABLE is used, this problem would
> theorectically cause to decrease usable memory for GFP_HIGHUSER_MOVABLE
> allocation request which is mainly used for page cache and anon page
> allocation. So, fix it by setting 0 to
> sysctl_lowmem_reserve_ratio[ZONE_HIGHMEM].
>
> And, defining sysctl_lowmem_reserve_ratio array by MAX_NR_ZONES - 1 size
> makes code complex. For example, if there is highmem system, following
> reserve ratio is activated for *NORMAL ZONE* which would be easyily
s@easyily@easily@
> misleading people.
>
> #ifdef CONFIG_HIGHMEM
> 32
> #endif
>
> This patch also fix this situation by defining sysctl_lowmem_reserve_ratio
> array by MAX_NR_ZONES and place "#ifdef" to right place.
I would probably split this patch into two but this is up to you
> Reviewed-by: Aneesh Kumar K.V
> Acked-by: Vlastimil Babka
> Signed-off-by: Joonsoo Kim
> ---
> Documentation/sysctl/vm.txt | 5 ++---
> include/linux/mmzone.h | 2 +-
> mm/page_alloc.c | 25 ++---
> 3 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
> index 9baf66a..e9059d3 100644
> --- a/Documentation/sysctl/vm.txt
> +++ b/Documentation/sysctl/vm.txt
> @@ -336,8 +336,6 @@ The lowmem_reserve_ratio is an array. You can see them by
> reading this file.
> % cat /proc/sys/vm/lowmem_reserve_ratio
> 256 256 32
> -
> -Note: # of this elements is one fewer than number of zones. Because the
> highest
> - zone's value is not necessary for following calculation.
>
> But, these values are not used directly. The kernel calculates # of
> protection
> pages for each zones from them. These are shown as array of protection pages
> @@ -388,7 +386,8 @@ As above expression, they are reciprocal number of ratio.
> pages of higher zones on the node.
>
> If you would like to protect more pages, smaller values are effective.
> -The minimum value is 1 (1/1 -> 100%).
> +The minimum value is 1 (1/1 -> 100%). The value less than 1 completely
> +disables protection of the pages.
>
> ==
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 356a814..d549c4e 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -890,7 +890,7 @@ int min_free_kbytes_sysctl_handler(struct ctl_table *,
> int,
> void __user *, size_t *, loff_t *);
> int watermark_scale_factor_sysctl_handler(struct ctl_table *, int,
> void __user *, size_t *, loff_t *);
> -extern int sysctl_lowmem_reserve_ratio[MAX_NR_ZONES-1];
> +extern int sysctl_lowmem_reserve_ratio[MAX_NR_ZONES];
> int lowmem_reserve_ratio_sysctl_handler(struct ctl_table *, int,
> void __user *, size_t *, loff_t *);
> int percpu_pagelist_fraction_sysctl_handler(struct ctl_table *, int,
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 0f34356..2a7f7e9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -203,17 +203,18 @@ static void __free_pages_ok(struct page *page, unsigned
> int order);
> * TBD: should special case ZONE_DMA32 machines here - in those we normally
> * don't need any ZONE_NORMAL reservation
> */
> -int sysctl_lowmem_reserve_ratio[MAX_NR_ZONES-1] = {
> +int sysctl_lowmem_reserve_ratio[MAX_NR_ZONES] = {
> #ifdef CONFIG_ZONE_DMA
> - 256,
> + [ZONE_DMA] = 256,
> #endif
> #ifdef CONFIG_ZONE_DMA32
> - 256,
> + [ZONE_DMA32] = 256,
> #endif
> + [ZONE_NORMAL] = 32,
> #ifdef CONFIG_HIGHMEM
> - 32,
> + [ZONE_HIGHMEM] = 0,
> #endif
> - 32,
> + [ZONE_MOVABLE] = 0,
> };
>
> EXPORT_SYMBOL(totalram_pages);
> @@ -6921,13 +6922,15 @@ static void setup_per_zone_lowmem_reserve(void)
> struct zone *lower_zone;
>
> idx--;
> -
> - if (sysctl_lowmem_reserve_ratio[idx] < 1)
> - sysctl_lowmem_reserve_ratio[idx] = 1;
> -
> lower_zone = pgdat->node_zones + idx;
> - lower_zone->lowmem_reserve[j] = managed_pages /
> - sysctl_lowmem_reserve_ratio[idx];
> +
> + if (sysctl_lowmem_reserve_ratio[idx]
Re: [PATCH 2/2] usb: host: Implement workaround for Erratum A-009668
On 11.09.2017 12:43, yinbo@nxp.com wrote: From: "yinbo.zhu" Description: This issue is observed in USB 2.0 mode when the USB 3.0 host controller is connected to a FS/LS device via a hub. The host controller issues start-split (SSPLIT) and complete-split (CSPLIT) tokens to accomplish a split-transaction. A split-transaction consists of a SSPLIT token, token/data packets, CSPLIT token and token/data/handshake packets. A SSPLIT token is issued by the host controller to the hub followed by token/data/handshake packets. The hub then relays the token/data/handshake packets to the FS /LS device. Sometime later, the host controller issues a CSPLIT token followed by the same token/data/handshake packets to the hub to complete the split-transaction. As an example scenario, when the xHCI driver issues an Address device command with BSR=0, the host controller sends SETUP(SET_ADDRESS) tokens on the USB as part of splittransactions. If the host controller receives a NYET response from the hub for the CSPLIT SETUP token, it means that the split-transaction has not yet been completed or the hub is not able to handle the split transaction. In such a case, the host controller keeps retrying the splittransactions until such time an ACK response is received from the hub for the CSPLIT SETUP token. If the split-transactions do not complete in a time bound manner, the xHCI driver may issue a Stop Endpoint Command. The host controller does not service the Stop Endpoint Command and eventually the xHCI driver times out waiting for the Stop Endpoint Command to complete. Normally we start a command timeout timer each time we start servicing a new command, this gives each command 5 seconds time to finish. If it times out we stop the command ring and abort the command. The Stop endpoint command has an additinal separate timeout timer that is started when the stop endpoint command is queued to the ring, not when host starts to service the command. I see that we could end up in a situation where one device is being address (address device command), and a URB is being canceled for another device almost at the same time (stop endpoint command queued right after address device command). If the address device commands times out then the host doesn't have enough time to service the stop endpoint command before the stop endpoint timeout timer triggers. This needs to be fixed, but disabling the entire slot just because URB is being canceled for a LS/FS device is not the right way to go. -Mathias
Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead
On Thu, Sep 14, 2017 at 08:01:30PM +0800, Huang, Ying wrote:
> Minchan Kim writes:
>
> > On Wed, Sep 13, 2017 at 02:02:29PM -0700, Andrew Morton wrote:
> >> On Wed, 13 Sep 2017 10:40:19 +0900 Minchan Kim wrote:
> >>
> >> > Every zram users like low-end android device has used 0 page-cluster
> >> > to disable swap readahead because it has no seek cost and works as
> >> > synchronous IO operation so if we do readahead multiple pages,
> >> > swap falut latency would be (4K * readahead window size). IOW,
> >> > readahead is meaningful only if it doesn't bother faulted page's
> >> > latency.
> >> >
> >> > However, this patch introduces additional knob /sys/kernel/mm/swap/
> >> > vma_ra_max_order as well as page-cluster. It means existing users
> >> > has used disabled swap readahead doesn't work until they should be
> >> > aware of new knob and modification of their script/code to disable
> >> > vma_ra_max_order as well as page-cluster.
> >> >
> >> > I say it's a *regression* and wanted to fix it but Huang's opinion
> >> > is that it's not a functional regression so userspace should be fixed
> >> > by themselves.
> >> > Please look into detail of discussion in
> >> > http://lkml.kernel.org/r/%3c1505183833-4739-4-git-send-email-minc...@kernel.org%3E
> >>
> >> hm, tricky problem. I do agree that linking the physical and virtual
> >> readahead schemes in the proposed fashion is unfortunate. I also agree
> >> that breaking existing setups (a bit) is also unfortunate.
> >>
> >> Would it help if, when page-cluster is written to zero, we do
> >>
> >> printk_once("physical readahead disabled, virtual readahead still
> >> enabled. Disable virtual readhead via
> >> /sys/kernel/mm/swap/vma_ra_max_order").
> >>
> >> Or something like that. It's pretty lame, but it should help alert the
> >> zram-readahead-disabling people to the issue?
> >
> > It was my last resort. If we cannot find other ways after all, yes, it would
> > be a minimum we should do. But it still breaks users don't/can't read/modify
> > alert and program.
> >
> > How about this?
> >
> > Can't we make vma-based readahead config option?
> > With that, users who no interest on readahead don't enable vma-based
> > readahead. In this case, page-cluster works as expected "disable readahead
> > completely" so it doesn't break anything.
>
> Now. Users can choose between VMA based readahead and original
> readahead via a knob as follow at runtime,
>
> /sys/kernel/mm/swap/vma_ra_enabled
It's not a config option and is enabled by default. IOW, it's under the radar
so current users cannot notice it. That's why we want to emit big fat warnning.
when old user set 0 to page-cluster. However, as Andrew said, it's lame.
If we make it config option, product maker/kernel upgrade user can have
a chance to notice and read description so they could be aware of two weird
knobs and help to solve the problem in advance without printk_once warn.
If user has no interest about swap-readahead or skip the new config option
by mistake, it works physcial readahead which means no regression.
>
> Best Regards,
> Huang, Ying
>
>
> > People who want to use upcoming vma-based readahead can enable the feature
> > and we can say such unfortunate things in config/document description
> > somewhere so upcoming users will be aware of that unforunate two knobs.
Re: [PATCH v2] kbuild: (bin)rpm-pkg: fix version number handling
On 14 September 2017 at 14:26, Masahiro Yamada
wrote:
> The "Release:" field of the spec file is determined based on the
> .version file.
>
> However, the .version file is not copied to the source tar file.
> So, when we build the kernel from the source package, the UTS_VERSION
> always indicates #1. This does not match with "rpm -q".
>
> The kernel UTS_VERSION and "rpm -q" do not agree for binrpm-pkg, either.
> Please note the kernel has already been built before the spec file is
> created. Currently, mkspec invokes mkversion. This script returns an
> incremented version. So, the "Release:" field of the spec file is
> greater than the version in the kernel by one.
>
> For the source package build (where .version file is missing), we can
> give KBUILD_BUILD_VERSION=%{release} to the build command.
>
> For the binary package build, we can simply read out the .version file
> because it contains the version number that was used for building the
> kernel image.
>
> We can remove scripts/mkversion because scripts/package/Makefile need
> not touch the .version file.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2:
> - Remove bogus comment in mkspec
>
> scripts/mkversion| 6 --
> scripts/package/Makefile | 5 -
> scripts/package/mkspec | 6 ++
> 3 files changed, 2 insertions(+), 15 deletions(-)
> delete mode 100644 scripts/mkversion
>
> diff --git a/scripts/mkversion b/scripts/mkversion
> deleted file mode 100644
> index c12addc..000
> --- a/scripts/mkversion
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -if [ ! -f .version ]
> -then
> -echo 1
> -else
> -expr 0`cat .version` + 1
> -fi
> diff --git a/scripts/package/Makefile b/scripts/package/Makefile
> index 71b4a8a..73f9f31 100644
> --- a/scripts/package/Makefile
> +++ b/scripts/package/Makefile
> @@ -50,8 +50,6 @@ rpm-pkg rpm: FORCE
> $(MAKE) clean
> $(CONFIG_SHELL) $(MKSPEC) >$(objtree)/kernel.spec
> $(call cmd,src_tar,$(KERNELPATH),kernel.spec)
> - $(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version
> - mv -f $(objtree)/.tmp_version $(objtree)/.version
> rpmbuild $(RPMOPTS) --target $(UTS_MACHINE) -ta $(KERNELPATH).tar.gz
> rm $(KERNELPATH).tar.gz kernel.spec
>
> @@ -60,9 +58,6 @@ rpm-pkg rpm: FORCE
> binrpm-pkg: FORCE
> $(MAKE) KBUILD_SRC=
> $(CONFIG_SHELL) $(MKSPEC) prebuilt > $(objtree)/binkernel.spec
> - $(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version
> - mv -f $(objtree)/.tmp_version $(objtree)/.version
> -
> rpmbuild $(RPMOPTS) --define "_builddir $(objtree)" --target \
> $(UTS_MACHINE) -bb $(objtree)/binkernel.spec
> rm binkernel.spec
> diff --git a/scripts/package/mkspec b/scripts/package/mkspec
> index bb43f15..e81dafc 100755
> --- a/scripts/package/mkspec
> +++ b/scripts/package/mkspec
> @@ -27,9 +27,7 @@ __KERNELRELEASE=`echo $KERNELRELEASE | sed -e "s/-/_/g"`
> echo "Name: kernel"
> echo "Summary: The Linux Kernel"
> echo "Version: $__KERNELRELEASE"
> -# we need to determine the NEXT version number so that uname and
> -# rpm -q will agree
> -echo "Release: `. $srctree/scripts/mkversion`"
> +echo "Release: $(cat .version)"
$(cat .version||echo 1)"
.version might not exist at that point - for example when calling
make rpm-pkg from a pristine source tree. Apart from that looks good
to me.
> echo "License: GPL"
> echo "Group: System Environment/Kernel"
> echo "Vendor: The Linux Community"
> @@ -77,7 +75,7 @@ fi
> echo "%build"
>
> if ! $PREBUILT; then
> -echo "make clean && make %{?_smp_mflags}"
> +echo "make clean && make %{?_smp_mflags} KBUILD_BUILD_VERSION=%{release}"
> echo ""
> fi
>
> --
> 2.7.4
>
Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace
Hi gengdongjiu, (re-ordered hunks) On 13/09/17 08:32, gengdongjiu wrote: > On 2017/9/8 0:30, James Morse wrote: >> On 28/08/17 11:38, Dongjiu Geng wrote: >> For BUS_MCEERR_A* from memory_failure() we can't know if they are caused by >> an access or not. Actually it looks like we can: I thought 'BUS_MCEERR_AR' could be triggered via some CPER flags, but its not. The only code that flags MF_ACTION_REQUIRED is x86's kernel-first handling, which nicely matches this 'direct access' problem. BUS_MCEERR_AR also come from KVM stage2 faults (and the x86 equivalent). Powerpc also triggers these directly, both from what look to be synchronous paths, so I think its fair to equate BUS_MCEERR_AR to a synchronous access and BUS_MCEERR_AO to something_else. I don't think we need anything else. >> When the mm code gets -EHWPOISON when trying to resolve a > > Because of that, so I allow userspace getting exception information ... and there are cases where you can't get the exception information, and other cases where it wasn't an exception at all. [...] >> What happens if the dram-scrub hardware spots an error in guest memory, but >> the guest wasn't running? KVM won't have a relevant ESR value to give you. > if the dram-scrub hardware spots an error in guest memory, it will generate > IRQ in DDR controller, not SEA or SEI exception. I still do not consider the > GSIV. For GSIV, may be we can only handle it in the host OS. Great example: this IRQ pulls us out of a guest, we tromp through APEI and then memory_failure(), the memory happened to belong to the same guest (coincidence!), we send it some signal and now its user-space's problem. Your KVM_REG_ARM64_FAULT mechanism is going to return stale data, even though the notification interrupted the guest, and it was guest memory that was affected. KVM doesn't have a relevant ESR. I'm strongly against exposing 'which notification type' this error originally came from because: * it doesn't matter once we've got the CPER records, * there isn't always an answer (there are/will-be other ways of tripping memory_failure()) * it creates ABI between firwmare, host userspace and guest userspace. Firmware's choice of notification type shouldn't affect anything other than the host kernel. On 13/09/17 08:32, gengdongjiu wrote: > On 2017/9/8 0:30, James Morse wrote: >> On 28/08/17 11:38, Dongjiu Geng wrote: >>> when userspace gets SIGBUS signal, it does not know whether >>> this is a synchronous external abort or SError, >> >> Why would Qemu/kvmtool need to know if the original notification (if there >> was >> one) was synchronous or asynchronous? This is between firmware and the >> kernel. > there are two reasons: > > 1. Let us firstly discuss the SEA and SEI, there are different workflow for > the two different Errors. > 2. when record the CPER in the user space, it needs to know the error type, > because SEA and SEI are different Error source, >so they have different offset in the APEI table, that is to say they will > be recorded to different place of the APEI table. user-space can choose whether to use SEA or SEI, it doesn't have to choose the same notification type that firmware used, which in turn doesn't have to be the same as that used by the CPU to notify firmware. The choice only matters because these notifications hang on an existing pieces of the Arm-architecture, so the notification can only add to the architecturally defined meaning. (i.e. You can only send an SEA for something that can already be described as a synchronous external abort). Once we get to user-space, for memory_failure() notifications, (which so far is all we are talking about here), the only thing that could matter is whether the guest hit a PG_hwpoison page as a stage2 fault. These can be described as Synchronous-External-Abort. The Synchronous-External-Abort/SError-Interrupt distinction matters for the CPU because it can't always make an error synchronous. For memory_failure() notifications to a KVM guest we really can do this, and we already have this behaviour for free. An example: A guest touches some hardware:poisoned memory, for whatever reason the CPU can't put the world back together to make this a synchronous exception, so it reports it to firmware as an SError-interrupt. Linux gets an APEI notification and memory_failure() causes the affected page to be unmapped from the guest's stage2, and SIGBUS_MCEERR_AO sent to user-space. Qemu/kvmtool can now notify the guest with an IRQ or POLLed notification. AO-> action optional, probably asynchronous. But in our example it wasn't really asynchronous, that was just a property of the original CPU->firmware notification. What happens? The guest vcpu is re-run, it re-runs the same instructions (this was a contained error so KVM's ELR points at/before the instruction that steps in the problem). This time KVM takes a stage2 fault, which the mm code will refuse to fixup because the relevant page was marked as PG_hwpoisi
Re: [PATCH] Support for secure erase functionality
Dear Damien, Thank you for your feedback. > On 14. Sep 2017, at 10:46, Damien Le Moal wrote: […] > Writing once to a sector stored on spinning rust will *not* fully erase > the previous data. Part of the signal used for storing that data will > remain on the track (because the disk head is never perfectly aligned on > the track). With some signal processing work, the old data can be retrieved. > > You will need a *lot* of normal writes to make sure nothing remains of > the old data signal. Granted, even a single write will make it hard to > get to the old data, but it is possible nevertheless. Hence the standard > defined SANITIZE with cryptographic erase option to ensure that the old > data is really dead. We constructed our patch based on a paper called “Overwriting Hard Drive Data: The Great Wiping Controversy” which stated that a single overwrite of the data is sufficient. Nevertheless this should not be a solution to replace encryption but to improve data security when better techniques are not viable (e.g. travelling between countries while importing or exporting encrypted data may be prohibited without a license). > I think that a similar problem also exist for SSDs, and it is even worse > there since writing twice to the same logical sector does not even go to > the same physical sector. The old data is not even overwritten. We know about the problems regarding the data placement on SSDs, but there is very little we can do with code against the hardware controller of specific devices. On SSDs, you would probably want to use full disk encryption, because it should be no problem, when encrypted blocks are left on the drive. However in cases where encryption is too slow or not possible, this could improve data confidentiality. Best regards, Philipp
Re: [PATCH v6 3/7] acpi: apei: remove the unused code
On 2017/9/14 20:35, James Morse wrote: >> James, whether it is possible you can review the previous v5 patch which >> adds the support for > Spreading 'current discussion' over two versions is a problem for anyone > trying > to follow this series. > > If you post a newer version its normal for people to delete the older > versions. > When you post a new version you should be happy that its the latest and > greatest. > > James, today I paste the new version here, thanks. https://patchwork.kernel.org/patch/9952495/ https://patchwork.kernel.org/patch/9950955/
Re: [PATCH] megaraid: kmemleak: Track page allocation for fusion
On Thu, Sep 14, 2017 at 02:16:46PM +0800, shuw...@redhat.com wrote:
> From: Shu Wang
>
> Kmemleak reports about a thousand false positives for fusion->
> cmd_list[]. Root casue is the cmd_list objects are allocated from
> slab allocator, and stored its pointer in object allocated by page
> allocator. The fix will tell kmemleak to track and scan fusion
> object.
>
> Before patch:
> kmemleak: 1004 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>
> unreferenced object 0x88042584e000 (size 8192):
> backtrace:
> kmemleak_alloc+0x4a/0xa0
> __kmalloc+0xec/0x220
> megasas_alloc_cmdlist_fusion+0x3e/0x140 [megaraid_sas]
> megasas_alloc_cmds_fusion+0x44/0x450 [megaraid_sas]
> megasas_init_adapter_fusion+0x21d/0x6e0 [megaraid_sas]
> megasas_init_fw+0x357/0xd30 [megaraid_sas]
> megasas_probe_one.part.34+0x5be/0x1040 [megaraid_sas]
> megasas_probe_one+0x46/0xc0 [megaraid_sas]
> local_pci_probe+0x45/0xa0
> work_for_cpu_fn+0x14/0x20
> process_one_work+0x149/0x360
> worker_thread+0x1d8/0x3c0
> kthread+0x109/0x140
> ret_from_fork+0x25/0x30
>
> Signed-off-by: Shu Wang
> ---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index 11bd2e698b84..621299edd8de 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -48,6 +48,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -4512,7 +4513,9 @@ megasas_alloc_fusion_context(struct megasas_instance
> *instance)
> dev_err(&instance->pdev->dev, "Failed from %s %d\n",
> __func__, __LINE__);
> return -ENOMEM;
> }
> - }
> + } else
> + kmemleak_alloc(instance->ctrl_context,
> + sizeof(struct fusion_context), 1, GFP_KERNEL);
>
> fusion = instance->ctrl_context;
>
> @@ -4548,9 +4551,11 @@ megasas_free_fusion_context(struct megasas_instance
> *instance)
>
> if (is_vmalloc_addr(fusion))
> vfree(fusion);
> - else
> + else {
> free_pages((ulong)fusion,
> instance->ctrl_context_pages);
> + kmemleak_free(fusion);
> + }
Apart from Bart's comments on braces and comment before
kmemleak_alloc(), I'd call kmemleak_free() before free_pages(),
otherwise it may not interact nicely with other tools checking for use
after free. With that:
Reviewed-by: Catalin Marinas
--
Catalin
Re: [Outreachy kernel] [PATCH v2] Staging: ccree: Use kcalloc instead of kzalloc
On Thu, 14 Sep 2017, Srishti Sharma wrote:
> Use kcalloc instead of kzalloc to check for overflow before
> multiplication. Done using the following semantic patch by
> coccinelle.
>
> http://coccinelle.lip6.fr/rules/kzalloc.cocci
>
> Signed-off-by: Srishti Sharma
Acked-by: Julia Lawall
> ---
> Changes in v2:
> - eliminate parentheses around the first argument
>
> drivers/staging/ccree/ssi_sysfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/ccree/ssi_sysfs.c
> b/drivers/staging/ccree/ssi_sysfs.c
> index 0655658..f7e0c502 100644
> --- a/drivers/staging/ccree/ssi_sysfs.c
> +++ b/drivers/staging/ccree/ssi_sysfs.c
> @@ -376,7 +376,7 @@ static int sys_init_dir(struct sys_dir *sys_dir, struct
> ssi_drvdata *drvdata,
> return -ENOMEM;
> /* allocate memory for directory's attributes list */
> sys_dir->sys_dir_attr_list =
> - kzalloc(sizeof(struct attribute *) * (num_of_attrs + 1),
> + kcalloc(num_of_attrs + 1, sizeof(struct attribute *),
> GFP_KERNEL);
>
> if (!(sys_dir->sys_dir_attr_list)) {
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/1505393293-5941-1-git-send-email-srishtishar%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
Re: [PATCH] net/mlx5: fpga: avoid uninitialized return codes
On Thu, Sep 14, 2017 at 01:06:18PM +0200, Arnd Bergmann wrote:
> calling mlx5_fpga_mem_{read,write}_i2c() with a zero length on
> older compiler version such as gcc-4.6 results in a warning that
> the return code is not initialized:
>
> drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.c:147:6: error: ‘err’ may be
> used uninitialized in this function [-Werror=uninitialized]
> drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.c:126:6: error: ‘err’ may be
> used uninitialized in this function [-Werror=uninitialized]
>
> On newer compilers, the 'err' variable is optimized away in this
> code path and assumed to be zero when the loop completes, so we
> don't get this warning.
>
> I'm changing the function here to instead return -EINVAL for the
> case, under the assumption that it was never meant to be called
> with a zero length argument.
I agree with you that size can't be zero and this patch will fix the
warning, but if it is possible, I will prefer to have this check is
written explicitly and not implicitly.
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.c
b/drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.c
index 3c11d6e2160a..0e85bebe1dad 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.c
@@ -69,6 +69,9 @@ static int mlx5_fpga_mem_read_i2c(struct mlx5_fpga_device
*fdev, size_t size,
if (!fdev->mdev)
return -ENOTCONN;
+ if (!size)
+ return -EINVAL;
+
while (bytes_done < size) {
actual_size = min(max_size, (size - bytes_done));
Thanks
>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82203
> Signed-off-by: Arnd Bergmann
> ---
> drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.c
> b/drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.c
> index 3c11d6e2160a..914fb9d77a1a 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.c
> @@ -64,7 +64,7 @@ static int mlx5_fpga_mem_read_i2c(struct mlx5_fpga_device
> *fdev, size_t size,
> size_t max_size = MLX5_FPGA_ACCESS_REG_SIZE_MAX;
> size_t bytes_done = 0;
> u8 actual_size;
> - int err;
> + int err = -EINVAL;
>
> if (!fdev->mdev)
> return -ENOTCONN;
> @@ -93,7 +93,7 @@ static int mlx5_fpga_mem_write_i2c(struct mlx5_fpga_device
> *fdev, size_t size,
> size_t max_size = MLX5_FPGA_ACCESS_REG_SIZE_MAX;
> size_t bytes_done = 0;
> u8 actual_size;
> - int err;
> + int err = -EINVAL;
>
> if (!fdev->mdev)
> return -ENOTCONN;
> --
> 2.9.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: PGP signature
RE: [PATCH] megaraid: kmemleak: Track page allocation for fusion
-Original Message-
From: shuw...@redhat.com [mailto:shuw...@redhat.com]
Sent: Thursday, September 14, 2017 11:47 AM
To: kashyap.de...@broadcom.com; sumit.sax...@broadcom.com;
shivasharan.srikanteshw...@broadcom.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: megaraidlinux@broadcom.com; linux-s...@vger.kernel.org;
linux-kernel@vger.kernel.org; catalin.mari...@arm.com; liw...@redhat.com;
ch...@redhat.com; Shu Wang
Subject: [PATCH] megaraid: kmemleak: Track page allocation for fusion
From: Shu Wang
Kmemleak reports about a thousand false positives for fusion-> cmd_list[].
Root casue is the cmd_list objects are allocated from slab allocator, and
stored its pointer in object allocated by page allocator. The fix will
tell kmemleak to track and scan fusion object.
Before patch:
kmemleak: 1004 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
unreferenced object 0x88042584e000 (size 8192):
backtrace:
kmemleak_alloc+0x4a/0xa0
__kmalloc+0xec/0x220
megasas_alloc_cmdlist_fusion+0x3e/0x140 [megaraid_sas]
megasas_alloc_cmds_fusion+0x44/0x450 [megaraid_sas]
megasas_init_adapter_fusion+0x21d/0x6e0 [megaraid_sas]
megasas_init_fw+0x357/0xd30 [megaraid_sas]
megasas_probe_one.part.34+0x5be/0x1040 [megaraid_sas]
megasas_probe_one+0x46/0xc0 [megaraid_sas]
local_pci_probe+0x45/0xa0
work_for_cpu_fn+0x14/0x20
process_one_work+0x149/0x360
worker_thread+0x1d8/0x3c0
kthread+0x109/0x140
ret_from_fork+0x25/0x30
Signed-off-by: Shu Wang
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 11bd2e698b84..621299edd8de 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#include
@@ -4512,7 +4513,9 @@ megasas_alloc_fusion_context(struct megasas_instance
*instance)
dev_err(&instance->pdev->dev, "Failed from %s
%d\n", __func__, __LINE__);
return -ENOMEM;
}
- }
+ } else
+ kmemleak_alloc(instance->ctrl_context,
+ sizeof(struct fusion_context), 1, GFP_KERNEL);
fusion = instance->ctrl_context;
@@ -4548,9 +4551,11 @@ megasas_free_fusion_context(struct megasas_instance
*instance)
if (is_vmalloc_addr(fusion))
vfree(fusion);
- else
+ else {
free_pages((ulong)fusion,
instance->ctrl_context_pages);
+ kmemleak_free(fusion);
+ }
}
}
Looks good. Thanks for catching this.
Acked-by: Sumit Saxena
--
2.13.5
Re: [PATCH v2] tools: objtool: fix memory leak in elf_create_rela_section()
On Thu, Sep 14, 2017 at 08:01:38AM +0200, Martin Kepplinger wrote: > Let's free the allocated char array relaname before returning > in order to avoid leaking memory. > > Signed-off-by: Martin Kepplinger > --- > > I should've allocated some brain resources before freeing some computer's. Oops. I also failed to engage the brain. Sometimes the simplest patches are the most deceptive. ;-) Acked-by: Josh Poimboeuf -- Josh
[PATCH v2] Staging: ccree: Use kcalloc instead of kzalloc
Use kcalloc instead of kzalloc to check for overflow before
multiplication. Done using the following semantic patch by
coccinelle.
http://coccinelle.lip6.fr/rules/kzalloc.cocci
Signed-off-by: Srishti Sharma
---
Changes in v2:
- eliminate parentheses around the first argument
drivers/staging/ccree/ssi_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_sysfs.c
b/drivers/staging/ccree/ssi_sysfs.c
index 0655658..f7e0c502 100644
--- a/drivers/staging/ccree/ssi_sysfs.c
+++ b/drivers/staging/ccree/ssi_sysfs.c
@@ -376,7 +376,7 @@ static int sys_init_dir(struct sys_dir *sys_dir, struct
ssi_drvdata *drvdata,
return -ENOMEM;
/* allocate memory for directory's attributes list */
sys_dir->sys_dir_attr_list =
- kzalloc(sizeof(struct attribute *) * (num_of_attrs + 1),
+ kcalloc(num_of_attrs + 1, sizeof(struct attribute *),
GFP_KERNEL);
if (!(sys_dir->sys_dir_attr_list)) {
--
2.7.4
Re: [PATCH] megaraid: kmemleak: Track page allocation for fusion
On Thu, 2017-09-14 at 14:16 +0800, shuw...@redhat.com wrote:
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index 11bd2e698b84..621299edd8de 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -48,6 +48,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -4512,7 +4513,9 @@ megasas_alloc_fusion_context(struct megasas_instance
> *instance)
> dev_err(&instance->pdev->dev, "Failed from %s %d\n",
> __func__, __LINE__);
> return -ENOMEM;
> }
> - }
> + } else
> + kmemleak_alloc(instance->ctrl_context,
> + sizeof(struct fusion_context), 1, GFP_KERNEL);
>
> fusion = instance->ctrl_context;
Thank you for having tracked this down and for having shared this patch. But
please keep braces balanced to keep checkpatch happy and please also consider
adding a comment similar to the following above the kmemleak_alloc() call:
/* Allow kmemleak to scan these pages as they contain pointers to additional
allocations. */
> @@ -4548,9 +4551,11 @@ megasas_free_fusion_context(struct megasas_instance
> *instance)
>
> if (is_vmalloc_addr(fusion))
> vfree(fusion);
> - else
> + else {
> free_pages((ulong)fusion,
> instance->ctrl_context_pages);
> + kmemleak_free(fusion);
> + }
> }
Please keep braces balanced in the above code too.
Thanks,
Bart.
Re: [PATCH v6 5/7] arm64: kvm: route synchronous external abort exceptions to el2
Hi gengdongjiu, On 14/09/17 12:12, gengdongjiu wrote: > On 2017/9/8 0:31, James Morse wrote: >> KVM already handles external aborts from lower exception levels, no more work >> needs doing for TEA. > If it is firmware first solution, that is SCR_EL3.EA=1, all SError interrupt > and synchronous External > Abort exceptions are taken to EL3, so EL3 firmware will handle it, KVM no > needs to handle it. ... and presumably your firmware generates a fake-Synchronous-external-abort to hand to EL2 as an APEI SEA notification? My point: this is fine, KVM already handles synchronous-external aborts, no more work needed for this trap, (in contrast to the TERR, which you've fixed) > HCR_EL3.TEA is only for EL3 to check its value to decide to jump to > hypervisor or kernel. HCR_EL3!?! >> What happens when a guest access the RAS-Error-Record registers? >> >> Before we can set HCR_EL2.TERR I think we need to add some minimal emulation >> for >> the registers it traps. Most of them should be RAZ/WI, so it should be >> straightforward. (I think KVMs default is to emulate an undef for unknown >> traps). > Today I added the support to do some minimal emulation for RAS-Error-Record > registers, thanks > for the good suggestion. Thanks. Software has the bad habit of living much longer than we think, if KVM traps part of the architecture then we have to emulate it... Some bright spark might boot a future Linux-v4.42 guest on a Linux-v4.16 host. I had a run through the RAS spec: if we make ERRIDR_EL1 RAZ/WI then we can do the same with ERRSELR_EL1. Then following the rules for 'If ERRSELR_EL1.SEL is [>=] ERRIDR_EL1.NUM' that makes the ERX* registers RAZ/WI too. >> Eventually we will want to back this with a page of memory that lets >> Qemu/kvmtool configure what the guest can see. (i.e. the emulated machine's >> errors for kernel-first handling.) Thanks, James
[PATCH] xen: don't compile pv-specific parts if XEN_PV isn't configured
xenbus_client.c contains some functions specific for pv guests.
Enclose them with #ifdef CONFIG_XEN_PV to avoid compiling them when
they are not needed (e.g. on ARM).
Signed-off-by: Juergen Gross
---
drivers/xen/xenbus/xenbus_client.c | 130 +++--
1 file changed, 67 insertions(+), 63 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index 82a8866758ee..a1c17000129b 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -519,64 +519,6 @@ static int __xenbus_map_ring(struct xenbus_device *dev,
return err;
}
-static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
-grant_ref_t *gnt_refs,
-unsigned int nr_grefs,
-void **vaddr)
-{
- struct xenbus_map_node *node;
- struct vm_struct *area;
- pte_t *ptes[XENBUS_MAX_RING_GRANTS];
- phys_addr_t phys_addrs[XENBUS_MAX_RING_GRANTS];
- int err = GNTST_okay;
- int i;
- bool leaked;
-
- *vaddr = NULL;
-
- if (nr_grefs > XENBUS_MAX_RING_GRANTS)
- return -EINVAL;
-
- node = kzalloc(sizeof(*node), GFP_KERNEL);
- if (!node)
- return -ENOMEM;
-
- area = alloc_vm_area(XEN_PAGE_SIZE * nr_grefs, ptes);
- if (!area) {
- kfree(node);
- return -ENOMEM;
- }
-
- for (i = 0; i < nr_grefs; i++)
- phys_addrs[i] = arbitrary_virt_to_machine(ptes[i]).maddr;
-
- err = __xenbus_map_ring(dev, gnt_refs, nr_grefs, node->handles,
- phys_addrs,
- GNTMAP_host_map | GNTMAP_contains_pte,
- &leaked);
- if (err)
- goto failed;
-
- node->nr_handles = nr_grefs;
- node->pv.area = area;
-
- spin_lock(&xenbus_valloc_lock);
- list_add(&node->next, &xenbus_valloc_pages);
- spin_unlock(&xenbus_valloc_lock);
-
- *vaddr = area->addr;
- return 0;
-
-failed:
- if (!leaked)
- free_vm_area(area);
- else
- pr_alert("leaking VM area %p size %u page(s)", area, nr_grefs);
-
- kfree(node);
- return err;
-}
-
struct map_ring_valloc_hvm
{
unsigned int idx;
@@ -725,6 +667,65 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev,
void *vaddr)
}
EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
+#ifdef CONFIG_XEN_PV
+static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
+grant_ref_t *gnt_refs,
+unsigned int nr_grefs,
+void **vaddr)
+{
+ struct xenbus_map_node *node;
+ struct vm_struct *area;
+ pte_t *ptes[XENBUS_MAX_RING_GRANTS];
+ phys_addr_t phys_addrs[XENBUS_MAX_RING_GRANTS];
+ int err = GNTST_okay;
+ int i;
+ bool leaked;
+
+ *vaddr = NULL;
+
+ if (nr_grefs > XENBUS_MAX_RING_GRANTS)
+ return -EINVAL;
+
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (!node)
+ return -ENOMEM;
+
+ area = alloc_vm_area(XEN_PAGE_SIZE * nr_grefs, ptes);
+ if (!area) {
+ kfree(node);
+ return -ENOMEM;
+ }
+
+ for (i = 0; i < nr_grefs; i++)
+ phys_addrs[i] = arbitrary_virt_to_machine(ptes[i]).maddr;
+
+ err = __xenbus_map_ring(dev, gnt_refs, nr_grefs, node->handles,
+ phys_addrs,
+ GNTMAP_host_map | GNTMAP_contains_pte,
+ &leaked);
+ if (err)
+ goto failed;
+
+ node->nr_handles = nr_grefs;
+ node->pv.area = area;
+
+ spin_lock(&xenbus_valloc_lock);
+ list_add(&node->next, &xenbus_valloc_pages);
+ spin_unlock(&xenbus_valloc_lock);
+
+ *vaddr = area->addr;
+ return 0;
+
+failed:
+ if (!leaked)
+ free_vm_area(area);
+ else
+ pr_alert("leaking VM area %p size %u page(s)", area, nr_grefs);
+
+ kfree(node);
+ return err;
+}
+
static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
{
struct xenbus_map_node *node;
@@ -788,6 +789,12 @@ static int xenbus_unmap_ring_vfree_pv(struct xenbus_device
*dev, void *vaddr)
return err;
}
+static const struct xenbus_ring_ops ring_ops_pv = {
+ .map = xenbus_map_ring_valloc_pv,
+ .unmap = xenbus_unmap_ring_vfree_pv,
+};
+#endif
+
struct unmap_ring_vfree_hvm
{
unsigned int idx;
@@ -916,11 +923,6 @@ enum xenbus_state xenbus_read_driver_state(const char
*path)
}
EXPORT_SYMBOL_GPL(xenbus_read_driver_state);
-static const struct xenbus_ring_ops ring_ops_pv = {
- .map = xenbus_map_ring_valloc_pv,
- .unmap = xenbus_unmap_ring_vfree_pv,
-};
-
st
Re: [PATCH] mtd: spi-nor: stm32-quadspi: avoid unintialized return code
hi Arnd thx Arnd for compilation warning (gcc <= 4.6) Acked-by: Ludovic Barre PS: at runtime stm32_qspi_tx_poll can't be call, because stm32_qspi_tx check if there is tx data available if (!cmd->tx_data) return 0; BR Ludo On 09/14/2017 01:06 PM, Arnd Bergmann wrote: If we send zero-length data to stm32_qspi_tx_poll() on older compiler versions such as gcc-4.6, we get warned that the return code is uninitialized: drivers/mtd/spi-nor/stm32-quadspi.c:248:2: error: ‘ret’ may be used uninitialized in this function [-Werror=uninitialized] On newer compiler versions, the return code is always zero in this case, as the local variable gets optimized away and is assumed to be zero after the loop completes without error. This changes the function to instead return -EINVAL if it ever gets called with a zero length buffer. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82203 Signed-off-by: Arnd Bergmann --- drivers/mtd/spi-nor/stm32-quadspi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/stm32-quadspi.c b/drivers/mtd/spi-nor/stm32-quadspi.c index 86c0931543c5..711cfe7aa4bf 100644 --- a/drivers/mtd/spi-nor/stm32-quadspi.c +++ b/drivers/mtd/spi-nor/stm32-quadspi.c @@ -227,7 +227,7 @@ static int stm32_qspi_tx_poll(struct stm32_qspi *qspi, void (*tx_fifo)(u8 *, void __iomem *); u32 len = cmd->len, sr; u8 *buf = cmd->buf; - int ret; + int ret = -EINVAL; if (cmd->qspimode == CCR_FMODE_INDW) tx_fifo = stm32_qspi_write_fifo;
