Re: KASAN: use-after-free Read in snd_timer_process_callbacks
syzbot has found a reproducer for the following crash on:
HEAD commit:cfd24a53 Add linux-next specific files for 20190409
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=111d56af20
kernel config: https://syzkaller.appspot.com/x/.config?x=75160b904dadd291
dashboard link: https://syzkaller.appspot.com/bug?extid=58813d77154713f4de15
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=137ba6af20
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1749585b20
The bug was bisected to:
commit a7588c896b05444929ecb3d0115481988720abf6
Author: Takashi Iwai
Date: Wed Mar 27 15:56:08 2019 +
ALSA: timer: Check ack_list emptiness instead of bit flag
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1100d3ab20
final crash:https://syzkaller.appspot.com/x/report.txt?x=1300d3ab20
console output: https://syzkaller.appspot.com/x/log.txt?x=1500d3ab20
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+58813d77154713f4d...@syzkaller.appspotmail.com
Fixes: a7588c896b05 ("ALSA: timer: Check ack_list emptiness instead of bit
flag")
==
BUG: KASAN: use-after-free in __list_del_entry_valid+0xd2/0xf5
lib/list_debug.c:42
Read of size 8 at addr 8880a9363ee0 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.1.0-rc4-next-20190409 #21
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
__list_del_entry_valid+0xd2/0xf5 lib/list_debug.c:42
__list_del_entry include/linux/list.h:117 [inline]
list_del_init include/linux/list.h:176 [inline]
snd_timer_process_callbacks+0x7f/0x2f0 sound/core/timer.c:763
snd_timer_interrupt sound/core/timer.c:883 [inline]
snd_timer_interrupt+0x578/0xdd0 sound/core/timer.c:804
snd_hrtimer_callback+0x219/0x3e0 sound/core/hrtimer.c:64
__run_hrtimer kernel/time/hrtimer.c:1389 [inline]
__hrtimer_run_queues+0x33e/0xde0 kernel/time/hrtimer.c:1451
hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1509
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1035 [inline]
smp_apic_timer_interrupt+0x120/0x570 arch/x86/kernel/apic/apic.c:1060
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
RIP: 0010:native_safe_halt+0x2/0x10 arch/x86/include/asm/irqflags.h:58
Code: ff ff ff 48 89 c7 48 89 45 d8 e8 99 65 8e fa 48 8b 45 d8 e9 ce fe ff
ff 48 89 df e8 88 65 8e fa eb 82 90 90 90 90 90 90 fb f4 0f 1f 00 66
2e 0f 1f 84 00 00 00 00 00 f4 c3 90 90 90 90 90 90
RSP: 0018:88807d08 EFLAGS: 0286 ORIG_RAX: ff13
RAX: 11124ad9 RBX: 8887a100 RCX:
RDX: dc00 RSI: 0006 RDI: 8887a97c
RBP: 88807d38 R08: 8887a100 R09:
R10: R11: R12:
R13: 889256b8 R14: R15:
arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:567
default_idle_call+0x36/0x90 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x386/0x570 kernel/sched/idle.c:262
cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:353
rest_init+0x245/0x37b init/main.c:450
arch_call_rest_init+0xe/0x1b
start_kernel+0x816/0x84f init/main.c:747
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:470
x86_64_start_kernel+0x77/0x7b arch/x86/kernel/head64.c:451
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
Allocated by task 7722:
save_stack+0x45/0xd0 mm/kasan/common.c:75
set_track mm/kasan/common.c:87 [inline]
__kasan_kmalloc mm/kasan/common.c:497 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:511
kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3621
kmalloc include/linux/slab.h:547 [inline]
kzalloc include/linux/slab.h:742 [inline]
snd_timer_instance_new+0x4f/0x3d0 sound/core/timer.c:109
snd_timer_open+0x8a7/0x1760 sound/core/timer.c:313
snd_seq_timer_open+0x240/0x590 sound/core/seq/seq_timer.c:290
queue_use+0xcb/0x240 sound/core/seq/seq_queue.c:502
snd_seq_queue_alloc+0x2c5/0x4d0 sound/core/seq/seq_queue.c:189
snd_seq_ioctl_create_queue+0xb0/0x330 sound/core/seq/seq_clientmgr.c:1522
snd_seq_ioctl+0x224/0x3e0 sound/core/seq/seq_clientmgr.c:2138
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:509 [inline]
do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696
ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
__do_sys_ioctl fs/ioctl.c:720 [inline]
__se_sys_ioctl fs/ioctl.c:718 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/i
RE: linux-next: Tree for Apr 9 (spi/spi-zynq-qspi.c)
Hi Randy, I have sent the patch on top of the patch sent by yuehaib...@huawei.com. Thanks, Naga Sureshkumar Relli > -Original Message- > From: Randy Dunlap > Sent: Tuesday, April 9, 2019 8:52 PM > To: Stephen Rothwell ; Linux Next Mailing List n...@vger.kernel.org> > Cc: Linux Kernel Mailing List ; Naga > Sureshkumar Relli > ; Michal Simek ; linux-spi s...@vger.kernel.org> > Subject: Re: linux-next: Tree for Apr 9 (spi/spi-zynq-qspi.c) > > On 4/9/19 1:00 AM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20190408: > > > > on x86_64: > > ld: drivers/spi/spi-zynq-qspi.o: in function `zynq_qspi_supports_op': > spi-zynq-qspi.c:(.text+0x185): undefined reference to > `spi_mem_default_supports_op' > > > Full randconfig file is attached. > > -- > ~Randy
Re: [PATCH 3/3] thermal: cpu_cooling: Migrate to using the EM framework
On 28-03-19, 10:13, Quentin Perret wrote:
> +static unsigned int get_state_freq(struct cpufreq_cooling_device
> *cpufreq_cdev,
> + unsigned long state)
> +{
> + struct cpufreq_policy *policy;
> + unsigned long idx;
> +
> + /* Use the Energy Model table if available */
> + if (cpufreq_cdev->em) {
> + idx = cpufreq_cdev->max_level - state;
> + return cpufreq_cdev->em->table[idx].frequency;
> + }
> +
> + /* Otherwise, fallback on the CPUFreq table */
> + policy = cpufreq_cdev->policy;
> + if (policy->freq_table_sorted == CPUFREQ_TABLE_SORTED_ASCENDING)
It is not guaranteed that the frequency table is sorted in any order, isn't it ?
> + idx = cpufreq_cdev->max_level - state;
> + else
> + idx = state;
--
viresh
[LINUX PATCH v2] spi: spi-mem: Fix build error without CONFIG_SPI_MEM
When building with CONFIG_SPI_MEM is not set
gc warns this:
drivers/spi/spi-zynq-qspi.o: In function `zynq_qspi_supports_op':
spi-zynq-qspi.c:(.text+0x1da): undefined reference to
`spi_mem_default_supports_op'
Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI controller")
Signed-off-by: YueHaibing
Signed-off-by: Naga Sureshkumar Relli
---
Changes in v2
- Added static inline to the function spi_mem_default_supports_op();
---
include/linux/spi/spi-mem.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index eb71e9d..bf399f2 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -295,6 +295,8 @@ int spi_controller_dma_map_mem_op_data(struct
spi_controller *ctlr,
void spi_controller_dma_unmap_mem_op_data(struct spi_controller *ctlr,
const struct spi_mem_op *op,
struct sg_table *sg);
+bool spi_mem_default_supports_op(struct spi_mem *mem,
+const struct spi_mem_op *op);
#else
static inline int
spi_controller_dma_map_mem_op_data(struct spi_controller *ctlr,
@@ -310,6 +312,9 @@ spi_controller_dma_unmap_mem_op_data(struct spi_controller
*ctlr,
struct sg_table *sg)
{
}
+
+static inline bool spi_mem_default_supports_op(struct spi_mem *mem,
+const struct spi_mem_op *op);
#endif /* CONFIG_SPI_MEM */
int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op);
@@ -336,9 +341,6 @@ int spi_mem_driver_register_with_owner(struct
spi_mem_driver *drv,
void spi_mem_driver_unregister(struct spi_mem_driver *drv);
-bool spi_mem_default_supports_op(struct spi_mem *mem,
-const struct spi_mem_op *op);
-
#define spi_mem_driver_register(__drv) \
spi_mem_driver_register_with_owner(__drv, THIS_MODULE)
--
2.7.4
RE: [PATCH] spi: spi-mem: Fix build error without CONFIG_SPI_MEM
Hi Vignesh,
> -Original Message-
> From: linux-spi-ow...@vger.kernel.org On
> Behalf Of
> Naga Sureshkumar Relli
> Sent: Wednesday, April 10, 2019 10:53 AM
> To: YueHaibing ; Vignesh Raghavendra ;
> broo...@kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: RE: [PATCH] spi: spi-mem: Fix build error without CONFIG_SPI_MEM
>
> Hi Vignesh,
>
> > -Original Message-
> > From: linux-spi-ow...@vger.kernel.org
> > On Behalf Of YueHaibing
> > Sent: Wednesday, April 10, 2019 9:03 AM
> > To: Vignesh Raghavendra ; broo...@kernel.org; Naga
> > Sureshkumar Relli
> > Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> > Subject: Re: [PATCH] spi: spi-mem: Fix build error without
> > CONFIG_SPI_MEM
> >
> > On 2019/4/10 0:30, Vignesh Raghavendra wrote:
> > > On 08/04/19 8:09 PM, Yue Haibing wrote:
> > >> From: YueHaibing
> > >>
> > >> When building with CONFIG_SPI_MEM is not set gc warns this:
> > >>
> > >> drivers/spi/spi-zynq-qspi.o: In function `zynq_qspi_supports_op':
> > >> spi-zynq-qspi.c:(.text+0x1da): undefined reference to
> > >> `spi_mem_default_supports_op'
> > >>
> > >> Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI
> > >> controller")
> > >> Signed-off-by: YueHaibing
> > >> ---
> > >> include/linux/spi/spi-mem.h | 14 +++---
> > >> 1 file changed, 11 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/include/linux/spi/spi-mem.h
> > >> b/include/linux/spi/spi-mem.h index c845cd6..1941b84 100644
> > >> --- a/include/linux/spi/spi-mem.h
> > >> +++ b/include/linux/spi/spi-mem.h
> > >> @@ -295,6 +295,10 @@ int spi_controller_dma_map_mem_op_data(struct
> > >> spi_controller *ctlr, void
> > >> spi_controller_dma_unmap_mem_op_data(struct spi_controller
> > *ctlr,
> > >>const struct spi_mem_op *op,
> > >>struct sg_table *sg);
> > >> +
> > >> +bool spi_mem_default_supports_op(struct spi_mem *mem,
> > >> + const struct spi_mem_op *op);
> > >> +
> > >> #else
> > >> static inline int
> > >> spi_controller_dma_map_mem_op_data(struct spi_controller *ctlr, @@
> > >> -310,6 +314,13 @@ spi_controller_dma_unmap_mem_op_data(struct
> > >> spi_controller
> *ctlr,
> > >> struct sg_table *sg)
> > >> {
> > >> }
> > >> +
> > >> +bool spi_mem_default_supports_op(struct spi_mem *mem,
> > >> + const struct spi_mem_op *op)
> > >
> > > This needs to be declared static inline to avoid multiple definitions.
> > > Right?
> >
> > Indeed, thanks!
Please ignore this. I did mistake in declaring.
It compiled with out any issues using static inline.
Thanks,
Naga Sureshkumar Relli
> If we declare this as static inline, then we can't access that in zynq-qspi
> driver.
> This is the error I am getting.
> In file included from drivers/spi/spi-zynq-qspi.c:19:0:
> ./include/linux/spi/spi-mem.h:298:20: warning: ‘spi_mem_default_supports_op’
> used but
> never defined static inline bool spi_mem_default_supports_op(struct spi_mem
> *mem,
> ^~~
> drivers/spi/spi-zynq-qspi.c: In function ‘zynq_qspi_supports_op’:
> ./include/linux/spi/spi-mem.h:298:20: error: inlining failed in call to
> always_inline
> ‘spi_mem_default_supports_op’: function body not available
> drivers/spi/spi-zynq-qspi.c:223:7: note: called from here
> if (!spi_mem_default_supports_op(mem, op))
>
> Thanks,
> Naga Sureshkumar Relli
> >
> > >
> > >> +{
> > >> +return false;
> > >> +}
> > >> +
> > >> #endif /* CONFIG_SPI_MEM */
> > >>
> > >> int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op
> > >> *op); @@ -341,9 +352,6 @@ int
> > >> spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
> > >>
> > >> void spi_mem_driver_unregister(struct spi_mem_driver *drv);
> > >>
> > >> -bool spi_mem_default_supports_op(struct spi_mem *mem,
> > >> - const struct spi_mem_op *op);
> > >> -
> > >> #define spi_mem_driver_register(__drv)
> > >> \
> > >> spi_mem_driver_register_with_owner(__drv, THIS_MODULE)
> > >>
> > >>
> > >
Re: [RFC PATCH 0/3] Add support of busfreq
On 15-03-19, 17:17, Leonard Crestez wrote: > On 3/15/19 11:31 AM, Alexandre Bailon wrote: > >>> This series is sent as RFC mostly because the current support of i.MX SoC > >>> won't > >>> benefit of busfreq framework, because the clocks' driver don't support > >>> interconnect / dram frequency scaling. > >>> As exemple, this series implements busfreq for i.MX8MM whose upstreaming > >>> is in progress. Because this relies on ATF to do the frequency scaling, > >>> it won't > >>> be hard make it work. > > >> How can I test this patch series? > >> Any additional patches you can share with us? > >> Or what else we need to do to test it? We can help with it. > > > Many other patches will be required to test the series. > > There are a couple of patches that updates i.MX device drivers to > > request for bandwidth (does similar thing as bus_freq_request and > > bus_freq_release). > > The interconnect framework asks for bandwidth in bytes/second but in NXP > tree most requests are of the form "request_bus_freq(BUS_FREQ_HIGH);". > In many cases (ethernet) it doesn't seem you can calculate a specific > bandwidth usefully. > > Instead of asking for "infinite bandwidth zero latency" to force > everything to "high" it would be nicer to "request an opp". > > Power-domain bindings mentioned that consumer-devices can specify a > "required-opps" property but I've found zero users in tree. Maybe some > helpers could be written to parse that property and automatically > request ICC opp on device suspend/resume via device-links? Documentation/devicetree/bindings/power/qcom,rpmpd.txt is using it currently in mainline. > I know that stuff was written for genpd but it looks like a very good > fit to me. Yes, the very first user is genpd but we have designed it with an open mind and so it shouldn't be difficult to make use of it at other places. There is some WIP which you can look at : - Introduce OPP bandwidth bindings lore.kernel.org/lkml/20190313090010.20534-1-georgi.dja...@linaro.org - DVFS in the OPP core https://lore.kernel.org/lkml/20190320094918.20234-1-rna...@codeaurora.org -- viresh
RE: [PATCH] spi: spi-mem: Fix build error without CONFIG_SPI_MEM
Hi Vignesh,
> -Original Message-
> From: linux-spi-ow...@vger.kernel.org On
> Behalf Of
> YueHaibing
> Sent: Wednesday, April 10, 2019 9:03 AM
> To: Vignesh Raghavendra ; broo...@kernel.org; Naga
> Sureshkumar Relli
>
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH] spi: spi-mem: Fix build error without CONFIG_SPI_MEM
>
> On 2019/4/10 0:30, Vignesh Raghavendra wrote:
> > On 08/04/19 8:09 PM, Yue Haibing wrote:
> >> From: YueHaibing
> >>
> >> When building with CONFIG_SPI_MEM is not set gc warns this:
> >>
> >> drivers/spi/spi-zynq-qspi.o: In function `zynq_qspi_supports_op':
> >> spi-zynq-qspi.c:(.text+0x1da): undefined reference to
> >> `spi_mem_default_supports_op'
> >>
> >> Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI
> >> controller")
> >> Signed-off-by: YueHaibing
> >> ---
> >> include/linux/spi/spi-mem.h | 14 +++---
> >> 1 file changed, 11 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/include/linux/spi/spi-mem.h
> >> b/include/linux/spi/spi-mem.h index c845cd6..1941b84 100644
> >> --- a/include/linux/spi/spi-mem.h
> >> +++ b/include/linux/spi/spi-mem.h
> >> @@ -295,6 +295,10 @@ int spi_controller_dma_map_mem_op_data(struct
> >> spi_controller *ctlr, void spi_controller_dma_unmap_mem_op_data(struct
> >> spi_controller
> *ctlr,
> >> const struct spi_mem_op *op,
> >> struct sg_table *sg);
> >> +
> >> +bool spi_mem_default_supports_op(struct spi_mem *mem,
> >> + const struct spi_mem_op *op);
> >> +
> >> #else
> >> static inline int
> >> spi_controller_dma_map_mem_op_data(struct spi_controller *ctlr, @@
> >> -310,6 +314,13 @@ spi_controller_dma_unmap_mem_op_data(struct
> >> spi_controller *ctlr,
> >> struct sg_table *sg)
> >> {
> >> }
> >> +
> >> +bool spi_mem_default_supports_op(struct spi_mem *mem,
> >> + const struct spi_mem_op *op)
> >
> > This needs to be declared static inline to avoid multiple definitions.
> > Right?
>
> Indeed, thanks!
If we declare this as static inline, then we can't access that in zynq-qspi
driver.
This is the error I am getting.
In file included from drivers/spi/spi-zynq-qspi.c:19:0:
./include/linux/spi/spi-mem.h:298:20: warning: ‘spi_mem_default_supports_op’
used but never defined
static inline bool spi_mem_default_supports_op(struct spi_mem *mem,
^~~
drivers/spi/spi-zynq-qspi.c: In function ‘zynq_qspi_supports_op’:
./include/linux/spi/spi-mem.h:298:20: error: inlining failed in call to
always_inline ‘spi_mem_default_supports_op’: function body not available
drivers/spi/spi-zynq-qspi.c:223:7: note: called from here
if (!spi_mem_default_supports_op(mem, op))
Thanks,
Naga Sureshkumar Relli
>
> >
> >> +{
> >> + return false;
> >> +}
> >> +
> >> #endif /* CONFIG_SPI_MEM */
> >>
> >> int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op
> >> *op); @@ -341,9 +352,6 @@ int
> >> spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
> >>
> >> void spi_mem_driver_unregister(struct spi_mem_driver *drv);
> >>
> >> -bool spi_mem_default_supports_op(struct spi_mem *mem,
> >> - const struct spi_mem_op *op);
> >> -
> >> #define spi_mem_driver_register(__drv) \
> >>spi_mem_driver_register_with_owner(__drv, THIS_MODULE)
> >>
> >>
> >
[PATCH] staging: pi433: add dependency to PA0,1,2 setting for output power level
When setting output power level called, the power level should be
checked by power amplifier level register and high power option. There
was todo about it. Add some variables for checking power level range.
The values that used for checking high power or minimum power are from
rf69 datasheets. The maximum power level is always same regardless of
mode.
Signed-off-by: Sidong Yang
---
drivers/staging/pi433/rf69.c | 45 ++--
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 340ffa7ccf18..4cd16257f0aa 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -349,18 +349,51 @@ int rf69_disable_amplifier(struct spi_device *spi, u8
amplifier_mask)
int rf69_set_output_power_level(struct spi_device *spi, u8 power_level)
{
- // TODO: Dependency to PA0,1,2 setting
- power_level += 18;
+ u8 pa_level, ocp, test_pa1, test_pa2;
+ bool pa0, pa1, pa2, high_power;
+ u8 min_power_level;
+
+ // check register pa_level
+ pa_level = rf69_read_reg(spi, REG_PALEVEL);
+ pa0 = pa_level & MASK_PALEVEL_PA0;
+ pa1 = pa_level & MASK_PALEVEL_PA1;
+ pa2 = pa_level & MASK_PALEVEL_PA2;
+
+ // check high power mode
+ ocp = rf69_read_reg(spi, REG_OCP);
+ test_pa1 = rf69_read_reg(spi, REG_TESTPA1);
+ test_pa2 = rf69_read_reg(spi, REG_TESTPA2);
+ high_power = (ocp == 0x0f) && (test_pa1 == 0x5d) && (test_pa2 == 0x7c);
+
+ if (pa0 && !pa1 && !pa2) {
+ power_level += 18;
+ min_power_level = 0;
+ } else if (!pa0 && pa1 && !pa2) {
+ power_level += 18;
+ min_power_level = 16;
+ } else if (!pa0 && pa1 && pa2) {
+ if (high_power)
+ power_level += 11;
+ else
+ power_level += 14;
+ min_power_level = 16;
+ } else {
+ goto failed;
+ }
// check input value
- if (power_level > 0x1f) {
- dev_dbg(>dev, "set: illegal input param");
- return -EINVAL;
- }
+ if (power_level > 0x1f)
+ goto failed;
+
+ if (power_level < min_power_level)
+ goto failed;
// write value
return rf69_read_mod_write(spi, REG_PALEVEL, MASK_PALEVEL_OUTPUT_POWER,
power_level);
+failed:
+ dev_dbg(>dev, "set: illegal input param");
+ return -EINVAL;
}
int rf69_set_pa_ramp(struct spi_device *spi, enum pa_ramp pa_ramp)
--
2.11.0
Re: linux-next: build failure after merge of the scsi-mkp tree
Hi all, On Wed, 10 Apr 2019 06:04:19 +0200 James Bottomley wrote: > > On Tue, 2019-04-09 at 21:33 -0400, Martin K. Petersen wrote: > > > > > > I have reverted that commit for today. > > > > > > This has now migrated to the scsi tree. > > > > I have a fix in my tree but I haven't pushed it yet. > > It's upstream in both trees now. Thanks, it'll be in -next tomorrow. -- Cheers, Stephen Rothwell pgpt8oplJ80Oi.pgp Description: OpenPGP digital signature
[PATCH] MAINTAINERS: Update email for Qualcomm SoC maintainer
This patch changes the email for Andy Gross to agr...@kernel.org. Signed-off-by: Andy Gross --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e17ebf7..cf39fb06 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1984,7 +1984,7 @@ W:http://www.armlinux.org.uk/ S: Maintained ARM/QUALCOMM SUPPORT -M: Andy Gross +M: Andy Gross M: David Brown L: linux-arm-...@vger.kernel.org S: Maintained -- 2.7.4
Re: [RFC][PATCH 13/16] sched: Add core wide task selection and scheduling.
On Tue, Apr 09, 2019 at 11:09:45AM -0700, Tim Chen wrote: > Now that we have accumulated quite a number of different fixes to your orginal > posted patches. Would you like to post a v2 of the core scheduler with the > fixes? One more question I'm not sure: should a task with cookie=0, i.e. tasks that are untagged, be allowed to scheduled on the the same core with another tagged task? The current patch seems to disagree on this, e.g. in pick_task(), if max is already chosen but max->core_cookie == 0, then we didn't care about cookie and simply use class_pick for the other cpu. This means we could schedule two tasks with different cookies(one is zero and the other can be tagged). But then sched_core_find() only allow idle task to match with any tagged tasks(we didn't place untagged tasks to the core tree of course :-). Thoughts? Do I understand this correctly? If so, I think we probably want to make this clear before v2. I personally feel, we shouldn't allow untagged tasks(like kernel threads) to match with tagged tasks.
Re: [PATCH 2/2] module: Make srcu_struct ptr array as read-only post init
- On Apr 9, 2019, at 11:38 PM, Joel Fernandes joe...@google.com wrote: > On Tue, Apr 9, 2019 at 10:48 PM Steven Rostedt wrote: >> >> On Tue, 9 Apr 2019 22:41:03 -0400 >> Joel Fernandes wrote: >> >> > > Other than that, the two patches look fine to me. >> > >> > Could I add your Reviewed-by in the respin? >> >> You can add an Acked-by, as I haven't spent enough time to offer a >> Reviewed-by tag. ;-) >> >> Maybe I'll get some time to vet it a bit more tomorrow, and then >> upgrade the ack to a review. >> >> Acked-by: Steven Rostedt (VMware) >> > > Thanks! > > Also we could possibly consider adding the tracepoint ptrs array as > well to the list, which would be useful I think, if one were to over > write that array by accident (and the bpf tps related array too). Yes, please! Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: rseq/x86: choosing rseq code signature
- On Apr 9, 2019, at 9:57 PM, Andy Lutomirski l...@kernel.org wrote: > On Tue, Apr 9, 2019 at 5:51 PM Zack Weinberg wrote: >> >> On Tue, Apr 9, 2019 at 4:43 PM Mathieu Desnoyers >> wrote: >> > - On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers >> > mathieu.desnoy...@efficios.com wrote: >> > > >> > > We are about to include the code signature required prior to restartable >> > > sequences abort handlers into glibc, which will make this ABI choice >> > > final. >> > > We need architecture maintainer input on that signature value. >> > > >> > > That code signature is placed before each abort handler, so the kernel >> > > can >> > > validate that it is indeed jumping to an abort handler (and not some >> > > arbitrary attacker-chosen code). The signature is never executed. >> > > >> > > Currently, tools/testing/selftests/rseq/rseq-x86.h defines RSEQ_SIG >> > > as 0x53053053, and uses it as an immediate operand to the following >> > > instruction opcodes (as suggested by Andy Lutomirski): >> > > >> > > x86-32: >> > > - .byte 0x0f, 0x1f, 0x05: nopl >> > > >> > > x86-64: >> > > - .byte 0x0f, 0x1f, 0x05: nopl (%rip) >> > > >> > > The current discussion thread on the glibc mailing list leads us towards >> > > using a trap with uncommon immediate operand, which simplifies >> > > integration >> > > with disassemblers, emulators, makes it easier to debug if the control >> > > flow gets redirected there by mistake, and is nicer for some >> > > architecture's >> > > speculative execution. >> ... >> > Peter Zijlstra suggested to use "invlpg" in user-space, which should >> > generate >> > a trap. The only concern would be emulators, but ideally they would not >> > try to >> > decode an instruction that is never executed. This would lead to the >> > following >> > patch. Any objections/ack ? >> ... >> > +/* >> > + * RSEQ_SIG is used with the following privileged instructions, which >> > trap in >> > user-space: >> > + * x86-32:0f 01 3d 53 30 05 53 invlpg 0x53053053 >> > + * x86-64:0f 01 3d 53 30 05 53 invlpg 0x53053053(%rip) >> > + */ >> > #define RSEQ_SIG 0x53053053 >> >> On x86, you have to worry about what happens if control flow gets >> redirected to an arbitrary byte address. The proposed sequence `0f 01 >> 3d 53 30 05 53` is a trap instruction if control lands seven bytes >> before the beginning of the abort handler, but if it lands anywhere >> _else_ within the marker sequence, you get one of these instruction >> sequences, none of which trap, all but one of which will corrupt the >> process state, and three of which will consume three bytes from the >> beginning of the abort handler's code, continuing execution with a >> misaligned PC: >> >> 01 3d 53 30 05 53add %edi,0x53053053(%rip) >> 3d 53 30 05 53 cmp $0x53053053,%eax >> 53 30 05 53 XX XX XX push %rbx; xor %al,0xXX78(%rip) >> 30 05 53 XX XX XXxor %al,0xXX78(%rip) >> 05 53 XX XX XX add $0xXX53,%eax >> 53 push %rbx >> >> So I'm going to suggest instead the four-byte sequence CD CF CD CF. >> That's INT $0xCF if control lands either two or four bytes before the >> beginning of the abort handler, and IRET if it lands one or three >> bytes before. I believe both of these possibilities are currently >> also forbidden in user mode. It doesn't need to be longer, does it? >> > > IRET works in user mode just fine. Why are you concerned about > landing in the middle of the signature? A misaligned jump into code > is screwy pretty much no matter what. It does seem genuinely useful > to trap if you accidentally fall through to the beginning of the > signature, but I don't see the point of worrying about jumping to the > middle. > > There's some argument that, for consistency with CET, the last couple > bytes of the signature should match ENDBR. > > Mathieu, how many bytes do we have for the signature? The signature is 4 bytes. Those 4 bytes need to be uncommon. You can have a longer instruction than that, but then the additional bytes at the beginning of the instruction will not be part of the signature per se. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
[PATCH v6 12/12] soc: ti: am6: Enable interrupt controller driver
Select the TISCI Interrupt Router, Aggregator drivers and all its dependencies for AM6 SoC. Suggested-by: Marc Zyngier Signed-off-by: Lokesh Vutla --- Changes since v5: - None drivers/soc/ti/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig index 82f110fe4953..a56cd70acbe1 100644 --- a/drivers/soc/ti/Kconfig +++ b/drivers/soc/ti/Kconfig @@ -5,6 +5,11 @@ if ARCH_K3 config ARCH_K3_AM6_SOC bool "K3 AM6 SoC" + select MAILBOX + select TI_MESSAGE_MANAGER + select TI_SCI_PROTOCOL + select TI_SCI_INTR_IRQCHIP + select TI_SCI_INTA_IRQCHIP help Enable support for TI's AM6 SoC Family support -- 2.21.0
[PATCH v6 10/12] soc: ti: Add MSI domain bus support for Interrupt Aggregator
With the system coprocessor managing the range allocation of the
inputs to Interrupt Aggregator, it is difficult to represent
the device IRQs from DT.
The suggestion is to use MSI in such cases where devices wants
to allocate and group interrupts dynamically.
Create a MSI domain bus layer that allocates and frees MSIs for
a device.
APIs that are implemented:
- ti_sci_inta_msi_create_irq_domain() that creates a MSI domain
- ti_sci_inta_msi_domain_alloc_irqs() that creates MSIs for the
specified device and resource.
- ti_sci_inta_msi_domain_free_irqs() frees the irqs attached to the device.
- ti_sci_inta_msi_get_virq() for getting the virq attached to a specific event.
Signed-off-by: Lokesh Vutla
---
Changes since v5:
- Updated the input parametes to all apis
- Updated the default chip ops.
- Prefixed all the apis with ti_sci_inta_
Marc,
Right now ti_sci_resource is being passed for irq allocatons.
I couldn't get to use resources attached to platform_device. Because
platform_device resources are allocated in of_device_alloc() and number
of resources are fixed in it. In order to update the resources, driver
has to do a krealloc(pdev->resources) and update the num of resources.
Is it allowed to update the pdev->resources during probe time? If yes,
Ill be happy to update the patch to use platform_dev resources.
MAINTAINERS| 2 +
drivers/soc/ti/Kconfig | 6 +
drivers/soc/ti/Makefile| 1 +
drivers/soc/ti/ti_sci_inta_msi.c | 167 +
include/linux/irqdomain.h | 1 +
include/linux/msi.h| 6 +
include/linux/soc/ti/ti_sci_inta_msi.h | 23
7 files changed, 206 insertions(+)
create mode 100644 drivers/soc/ti/ti_sci_inta_msi.c
create mode 100644 include/linux/soc/ti/ti_sci_inta_msi.h
diff --git a/MAINTAINERS b/MAINTAINERS
index ba88b3033fe4..dd31d7cb2fc6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15353,6 +15353,8 @@ F:
Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
F: drivers/irqchip/irq-ti-sci-intr.c
F: drivers/irqchip/irq-ti-sci-inta.c
+F: include/linux/soc/ti/ti_sci_inta_msi.h
+F: drivers/soc/ti/ti_sci_inta_msi.c
Texas Instruments ASoC drivers
M: Peter Ujfalusi
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index be4570baad96..82f110fe4953 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -73,4 +73,10 @@ config TI_SCI_PM_DOMAINS
called ti_sci_pm_domains. Note this is needed early in boot before
rootfs may be available.
+config TI_SCI_INTA_MSI_DOMAIN
+ bool
+ select GENERIC_MSI_IRQ_DOMAIN
+ help
+ Driver to enable Interrupt Aggregator specific MSI Domain.
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index a22edc0b258a..b3868d392d4f 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA)+= knav_dma.o
obj-$(CONFIG_AMX3_PM) += pm33xx.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
obj-$(CONFIG_TI_SCI_PM_DOMAINS)+= ti_sci_pm_domains.o
+obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
diff --git a/drivers/soc/ti/ti_sci_inta_msi.c b/drivers/soc/ti/ti_sci_inta_msi.c
new file mode 100644
index ..247a5e5f216b
--- /dev/null
+++ b/drivers/soc/ti/ti_sci_inta_msi.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Aggregator MSI bus
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void ti_sci_inta_msi_write_msg(struct irq_data *data,
+ struct msi_msg *msg)
+{
+ /* Nothing to do */
+}
+
+static void ti_sci_inta_msi_compose_msi_msg(struct irq_data *data,
+ struct msi_msg *msg)
+{
+ /* Nothing to do */
+}
+
+static int ti_sci_inta_msi_request_resources(struct irq_data *data)
+{
+ data = data->parent_data;
+
+ return data->chip->irq_request_resources(data);
+}
+
+static void ti_sci_inta_msi_release_resources(struct irq_data *data)
+{
+ data = data->parent_data;
+ data->chip->irq_release_resources(data);
+}
+
+static void ti_sci_inta_msi_update_chip_ops(struct msi_domain_info *info)
+{
+ struct irq_chip *chip = info->chip;
+
+ WARN_ON(!chip);
+ if (!chip->irq_mask)
+ chip->irq_mask = irq_chip_mask_parent;
+ if (!chip->irq_unmask)
+ chip->irq_unmask = irq_chip_unmask_parent;
+ if (!chip->irq_ack)
+ chip->irq_ack = irq_chip_ack_parent;
+ if (!chip->irq_set_type)
+ chip->irq_set_type =
[PATCH v6 09/12] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver
Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
which is an interrupt controller that does the following:
- Converts events to interrupts that can be understood by
an interrupt router.
- Allows for multiplexing of events to interrupts.
Configuration of the interrupt aggregator registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.
Add support for Interrupt Aggregator driver with 2 IRQ Domains:
- INTA MSI domain that interfaces the devices using which interrupts can be
allocated dynamically.
- INTA domain that is parent to the MSI domain that manages the interrupt
resources.
Signed-off-by: Lokesh Vutla
---
Changes since v5:
- Moved all the allocation of events and parent irqs to .irq_request_resources
callback of irqchip. This is based on the offline discussion with Marc.
Marc,
This version has a deviation from our discussion:
- Could not create separate irq_domains for each output(vint) of INTA, instead
stick to a single irq_domain for the entire INTA. Because when creating
msi_domain there is no parent available to attach. Even then I create
irq_domains for all the available vints during probe, how do we decide
which is the parent of msi_domain?
MAINTAINERS | 1 +
drivers/irqchip/Kconfig | 11 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ti-sci-inta.c | 622 ++
4 files changed, 635 insertions(+)
create mode 100644 drivers/irqchip/irq-ti-sci-inta.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 90173038f674..ba88b3033fe4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15352,6 +15352,7 @@ F: drivers/reset/reset-ti-sci.c
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
F: drivers/irqchip/irq-ti-sci-intr.c
+F: drivers/irqchip/irq-ti-sci-inta.c
Texas Instruments ASoC drivers
M: Peter Ujfalusi
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index a1ff64c1d40d..946c062fcec0 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -436,6 +436,17 @@ config TI_SCI_INTR_IRQCHIP
If you wish to use interrupt router irq resources managed by the
TI System Controller, say Y here. Otherwise, say N.
+config TI_SCI_INTA_IRQCHIP
+ bool
+ depends on TI_SCI_PROTOCOL && ARCH_K3
+ select IRQ_DOMAIN
+ select IRQ_DOMAIN_HIERARCHY
+ help
+ This enables the irqchip driver support for K3 Interrupt aggregator
+ over TI System Control Interface available on some new TI's SoCs.
+ If you wish to use interrupt aggregator irq resources managed by the
+ TI System Controller, say Y here. Otherwise, say N.
+
endmenu
config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index fa5c865788b5..8a33013da953 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -98,3 +98,4 @@ obj-$(CONFIG_IMX_IRQSTEER)+= irq-imx-irqsteer.o
obj-$(CONFIG_MADERA_IRQ) += irq-madera.o
obj-$(CONFIG_LS1X_IRQ) += irq-ls1x.o
obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o
+obj-$(CONFIG_TI_SCI_INTA_IRQCHIP) += irq-ti-sci-inta.o
diff --git a/drivers/irqchip/irq-ti-sci-inta.c
b/drivers/irqchip/irq-ti-sci-inta.c
new file mode 100644
index ..3eb935ebe10f
--- /dev/null
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -0,0 +1,622 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Aggregator irqchip driver
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TI_SCI_DEV_ID_MASK 0x
+#define TI_SCI_DEV_ID_SHIFT16
+#define TI_SCI_IRQ_ID_MASK 0x
+#define TI_SCI_IRQ_ID_SHIFT0
+#define HWIRQ_TO_DEVID(hwirq) (((hwirq) >> (TI_SCI_DEV_ID_SHIFT)) & \
+(TI_SCI_DEV_ID_MASK))
+#define HWIRQ_TO_IRQID(hwirq) ((hwirq) & (TI_SCI_IRQ_ID_MASK))
+
+#define MAX_EVENTS_PER_VINT64
+#define VINT_ENABLE_SET_OFFSET 0x0
+#define VINT_ENABLE_CLR_OFFSET 0x8
+#define VINT_STATUS_OFFSET 0x18
+
+/**
+ * struct ti_sci_inta_event_desc - Description of an event coming to
+ *Interrupt Aggregator. This serves
+ *as a mapping table between global
+ *event and hwirq.
+ * @global_event: Global event number corresponding to this event
+ * @hwirq: Hwirq of the incoming interrupt
+ */
+struct ti_sci_inta_event_desc {
+ u16 global_event;
+ u32 hwirq;
+};
+
+/**
+ * struct ti_sci_inta_vint_desc - Description of a virtual
[PATCH v6 08/12] dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings
Add the DT binding documentation for Interrupt Aggregator driver.
Signed-off-by: Lokesh Vutla
---
Changes since v5:
- Dropped interrupt-cells property
- Added msi controller property
.../interrupt-controller/ti,sci-inta.txt | 66 +++
MAINTAINERS | 1 +
2 files changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
new file mode 100644
index ..0c2cee3be45f
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
@@ -0,0 +1,66 @@
+Texas Instruments K3 Interrupt Aggregator
+=
+
+The Interrupt Aggregator (INTA) provides a centralized machine
+which handles the termination of system events to that they can
+be coherently processed by the host(s) in the system. A maximum
+of 64 events can be mapped to a single interrupt.
+
+
+ Interrupt Aggregator
+ +-+
+ | IntmapVINT |
+ | +--+ ++|
+m -->| | vint | bit | | 0 |.|63| vint0 |
+ . | +--+ ++| +--+
+ . | . . | | HOST |
+Globalevents -->| . . |-->| IRQ |
+ . | . . | | CTRL |
+ . | . . | +--+
+n -->| +--+ ++|
+ | | vint | bit | | 0 |.|63| vintx |
+ | +--+ ++|
+ | |
+ +-+
+
+Configuration of these Intmap registers that maps global events to vint is done
+by a system controller (like the Device Memory and Security Controller on K3
+AM654 SoC). Driver should request the system controller to get the range
+of global events and vints assigned to the requesting host. Management
+of these requested resources should be handled by driver and requests
+system controller to map specific global event to vint, bit pair.
+
+Communication between the host processor running an OS and the system
+controller happens through a protocol called TI System Control Interface
+(TISCI protocol). For more details refer:
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+TISCI Interrupt Aggregator Node:
+---
+- compatible: Must be "ti,sci-inta".
+- reg: Should contain registers location and length.
+- interrupt-controller:Identifies the node as an interrupt controller
+- msi-controller: Identifies the node as an MSI controller.
+- interrupt-parent:phandle of irq parent.
+- ti,sci: Phandle to TI-SCI compatible System controller node.
+- ti,sci-dev-id: TISCI device ID of the Interrupt Aggregator.
+- ti,sci-rm-range-vint:TISCI subtype ids representing the virtual
interrupts
+ (vints) range within this IA, assigned to the
+ requesting host context.
+- ti,sci-rm-range-global-event:TISCI subtype ids representing the
global
+ events range reaching this IA and are assigned
+ to the requesting host context.
+
+Example:
+
+main_udmass_inta: interrupt-controller@33d0 {
+ compatible = "ti,sci-inta";
+ reg = <0x0 0x33d0 0x0 0x10>;
+ interrupt-controller;
+ msi-controller;
+ interrupt-parent = <_navss_intr>;
+ ti,sci = <>;
+ ti,sci-dev-id = <179>;
+ ti,sci-rm-range-vint = <0x0>;
+ ti,sci-rm-range-global-event = <0x1>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 6f551053627f..90173038f674 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15350,6 +15350,7 @@ F:
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
F: drivers/clk/keystone/sci-clk.c
F: drivers/reset/reset-ti-sci.c
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
+F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
F: drivers/irqchip/irq-ti-sci-intr.c
Texas Instruments ASoC drivers
--
2.21.0
[PATCH v6 11/12] irqchip: ti-sci-inta: Add msi domain support
Add a msi domain that is child to the INTA domain. Clients
uses the INTA msi bus layer to allocate irqs in this
msi domain.
Signed-off-by: Lokesh Vutla
---
Changes since v5:
- New patch. Seperated out msi domain part from the intial patch.
Marc,
I feel this is too simple to be a separate driver. So I am
sticking it into the same file.
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-ti-sci-inta.c | 39 ++-
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 946c062fcec0..e0a1ec55ca93 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -441,6 +441,7 @@ config TI_SCI_INTA_IRQCHIP
depends on TI_SCI_PROTOCOL && ARCH_K3
select IRQ_DOMAIN
select IRQ_DOMAIN_HIERARCHY
+ select TI_SCI_INTA_MSI_DOMAIN
help
This enables the irqchip driver support for K3 Interrupt aggregator
over TI System Control Interface available on some new TI's SoCs.
diff --git a/drivers/irqchip/irq-ti-sci-inta.c
b/drivers/irqchip/irq-ti-sci-inta.c
index 3eb935ebe10f..945e635847b2 100644
--- a/drivers/irqchip/irq-ti-sci-inta.c
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -28,6 +29,9 @@
#define HWIRQ_TO_DEVID(hwirq) (((hwirq) >> (TI_SCI_DEV_ID_SHIFT)) & \
(TI_SCI_DEV_ID_MASK))
#define HWIRQ_TO_IRQID(hwirq) ((hwirq) & (TI_SCI_IRQ_ID_MASK))
+#define TO_HWIRQ(dev, index) dev) & TI_SCI_DEV_ID_MASK) << \
+TI_SCI_DEV_ID_SHIFT) | \
+ ((index) & TI_SCI_IRQ_ID_MASK))
#define MAX_EVENTS_PER_VINT64
#define VINT_ENABLE_SET_OFFSET 0x0
@@ -528,9 +532,32 @@ static const struct irq_domain_ops
ti_sci_inta_irq_domain_ops = {
.free = ti_sci_inta_irq_domain_free,
};
+static struct irq_chip ti_sci_inta_msi_irq_chip = {
+ .name = "MSI-INTA",
+ .flags = IRQCHIP_SUPPORTS_LEVEL_MSI,
+};
+
+static void ti_sci_inta_msi_set_desc(msi_alloc_info_t *arg,
+struct msi_desc *desc)
+{
+ arg->desc = desc;
+ arg->hwirq = TO_HWIRQ(desc->inta.dev_id, desc->inta.index);
+}
+
+static struct msi_domain_ops ti_sci_inta_msi_ops = {
+ .set_desc = ti_sci_inta_msi_set_desc,
+};
+
+static struct msi_domain_info ti_sci_inta_msi_domain_info = {
+ .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+ MSI_FLAG_LEVEL_CAPABLE),
+ .ops= _sci_inta_msi_ops,
+ .chip = _sci_inta_msi_irq_chip,
+};
+
static int ti_sci_inta_irq_domain_probe(struct platform_device *pdev)
{
- struct irq_domain *parent_domain, *domain;
+ struct irq_domain *parent_domain, *domain, *msi_domain;
struct device_node *parent_node, *node;
struct ti_sci_inta_irq_domain *inta;
struct device *dev = >dev;
@@ -596,6 +623,16 @@ static int ti_sci_inta_irq_domain_probe(struct
platform_device *pdev)
return -ENOMEM;
}
+ msi_domain =
+ ti_sci_inta_msi_create_irq_domain(of_node_to_fwnode(node),
+ _sci_inta_msi_domain_info,
+ domain);
+ if (!msi_domain) {
+ irq_domain_remove(domain);
+ dev_err(dev, "Failed to allocate msi domain\n");
+ return -ENOMEM;
+ }
+
INIT_LIST_HEAD(>vint_list);
mutex_init(>vint_mutex);
--
2.21.0
[PATCH v6 05/12] firmware: ti_sci: Add helper apis to manage resources
Each resource with in the device can be uniquely identified as defined
by TISCI. Since this is generic across the devices, resource allocation
also can be made generic instead of each client driver handling the
resource. So add helper apis to manage the resource.
Signed-off-by: Lokesh Vutla
---
Changes since v5:
- New patch. Abstracted out resource managemented into firmware driver after
discussing with Nishanth and Marc.
drivers/firmware/ti_sci.c | 130 +
include/linux/soc/ti/ti_sci_protocol.h | 54 ++
2 files changed, 184 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 88e461498def..e4b01cfc5883 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -2277,6 +2277,136 @@ const struct ti_sci_handle
*devm_ti_sci_get_by_phandle(struct device *dev,
}
EXPORT_SYMBOL_GPL(devm_ti_sci_get_by_phandle);
+/**
+ * ti_sci_get_free_resource() - Get a free resource from TISCI resource.
+ * @res: Pointer to the TISCI resource
+ *
+ * Return: resource num if all went ok else TI_SCI_RESOURCE_NULL.
+ */
+u16 ti_sci_get_free_resource(struct ti_sci_resource *res)
+{
+ unsigned long flags;
+ u16 set, free_bit;
+
+ raw_spin_lock_irqsave(>lock, flags);
+ for (set = 0; set < res->sets; set++) {
+ free_bit = find_first_zero_bit(res->desc[set].res_map,
+ res->desc[set].num);
+ if (free_bit != res->desc[set].num) {
+ set_bit(free_bit, res->desc[set].res_map);
+ raw_spin_unlock_irqrestore(>lock, flags);
+ return res->desc[set].start + free_bit;
+ }
+ }
+ raw_spin_unlock_irqrestore(>lock, flags);
+
+ return TI_SCI_RESOURCE_NULL;
+}
+EXPORT_SYMBOL_GPL(ti_sci_get_free_resource);
+
+/**
+ * ti_sci_release_resource() - Release a resource from TISCI resource.
+ * @res: Pointer to the TISCI resource
+ * @id:Resource id to be released.
+ */
+void ti_sci_release_resource(struct ti_sci_resource *res, u16 id)
+{
+ unsigned long flags;
+ u16 set;
+
+ raw_spin_lock_irqsave(>lock, flags);
+ for (set = 0; set < res->sets; set++) {
+ if (res->desc[set].start <= id &&
+ (res->desc[set].num + res->desc[set].start) > id)
+ clear_bit(id - res->desc[set].start,
+ res->desc[set].res_map);
+ }
+ raw_spin_unlock_irqrestore(>lock, flags);
+}
+EXPORT_SYMBOL_GPL(ti_sci_release_resource);
+
+/**
+ * ti_sci_get_num_resources() - Get the number of resources in TISCI resource
+ * @res: Pointer to the TISCI resource
+ *
+ * Return: Total number of available resources.
+ */
+u32 ti_sci_get_num_resources(struct ti_sci_resource *res)
+{
+ u32 set, count = 0;
+
+ for (set = 0; set < res->sets; set++)
+ count += res->desc[set].num;
+
+ return count;
+}
+EXPORT_SYMBOL_GPL(ti_sci_get_num_resources);
+
+/**
+ * devm_ti_sci_get_of_resource() - Get a TISCI resource assigned to a device
+ * @handle:TISCI handle
+ * @dev: Device pointer to which the resource is assigned
+ * @dev_id:TISCI device id to which the resource is assigned
+ * @of_prop: property name by which the resource are represented
+ *
+ * Return: Pointer to ti_sci_resource if all went well else appropriate
+ *error pointer.
+ */
+struct ti_sci_resource *
+devm_ti_sci_get_of_resource(const struct ti_sci_handle *handle,
+ struct device *dev, u32 dev_id, char *of_prop)
+{
+ struct ti_sci_resource *res;
+ u32 resource_subtype;
+ int i, ret;
+
+ res = devm_kzalloc(dev, sizeof(*res), GFP_KERNEL);
+ if (!res)
+ return ERR_PTR(-ENOMEM);
+
+ res->sets = of_property_count_elems_of_size(dev_of_node(dev), of_prop,
+ sizeof(u32));
+ if (res->sets < 0) {
+ dev_err(dev, "%s resource type ids not available\n", of_prop);
+ return ERR_PTR(res->sets);
+ }
+
+ res->desc = devm_kcalloc(dev, res->sets, sizeof(*res->desc),
+GFP_KERNEL);
+ if (!res->desc)
+ return ERR_PTR(-ENOMEM);
+
+ for (i = 0; i < res->sets; i++) {
+ ret = of_property_read_u32_index(dev_of_node(dev), of_prop, i,
+_subtype);
+ if (ret)
+ return ERR_PTR(-EINVAL);
+
+ ret = handle->ops.rm_core_ops.get_range(handle, dev_id,
+ resource_subtype,
+ >desc[i].start,
+ >desc[i].num);
+ if (ret) {
+ dev_err(dev, "dev = %d subtype %d
[PATCH v6 01/12] firmware: ti_sci: Add support to get TISCI handle using of_phandle
From: Grygorii Strashko
TISCI has been updated to have support for Resource management(likes
interrupts etc..). And there can be multiple device instances of a
resource type in a SoC. So every driver corresponding to a resource type
should get a TISCI handle so that it can make TISCI calls. And each
DT node corresponding to a device should exist under its corresponding
bus node as per the SoC architecture.
But existing apis in TISCI library assumes that all TISCI users are
child nodes of TISCI. Which is not true in the above case. So introduce
(devm_)ti_sci_get_by_phandle() apis that can be used by TISCI users
to get TISCI handle using of phandle property.
Signed-off-by: Grygorii Strashko
Signed-off-by: Lokesh Vutla
---
Changes since v5:
- None
drivers/firmware/ti_sci.c | 83 ++
include/linux/soc/ti/ti_sci_protocol.h | 17 ++
2 files changed, 100 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 3fbbb61012c4..852043531233 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1764,6 +1764,89 @@ const struct ti_sci_handle
*devm_ti_sci_get_handle(struct device *dev)
}
EXPORT_SYMBOL_GPL(devm_ti_sci_get_handle);
+/**
+ * ti_sci_get_by_phandle() - Get the TI SCI handle using DT phandle
+ * @np:device node
+ * @property: property name containing phandle on TISCI node
+ *
+ * NOTE: The function does not track individual clients of the framework
+ * and is expected to be maintained by caller of TI SCI protocol library.
+ * ti_sci_put_handle must be balanced with successful ti_sci_get_by_phandle
+ * Return: pointer to handle if successful, else:
+ * -EPROBE_DEFER if the instance is not ready
+ * -ENODEV if the required node handler is missing
+ * -EINVAL if invalid conditions are encountered.
+ */
+const struct ti_sci_handle *ti_sci_get_by_phandle(struct device_node *np,
+ const char *property)
+{
+ struct ti_sci_handle *handle = NULL;
+ struct device_node *ti_sci_np;
+ struct ti_sci_info *info;
+ struct list_head *p;
+
+ if (!np) {
+ pr_err("I need a device pointer\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ ti_sci_np = of_parse_phandle(np, property, 0);
+ if (!ti_sci_np)
+ return ERR_PTR(-ENODEV);
+
+ mutex_lock(_sci_list_mutex);
+ list_for_each(p, _sci_list) {
+ info = list_entry(p, struct ti_sci_info, node);
+ if (ti_sci_np == info->dev->of_node) {
+ handle = >handle;
+ info->users++;
+ break;
+ }
+ }
+ mutex_unlock(_sci_list_mutex);
+ of_node_put(ti_sci_np);
+
+ if (!handle)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return handle;
+}
+EXPORT_SYMBOL_GPL(ti_sci_get_by_phandle);
+
+/**
+ * devm_ti_sci_get_by_phandle() - Managed get handle using phandle
+ * @dev: Device pointer requesting TISCI handle
+ * @property: property name containing phandle on TISCI node
+ *
+ * NOTE: This releases the handle once the device resources are
+ * no longer needed. MUST NOT BE released with ti_sci_put_handle.
+ * The function does not track individual clients of the framework
+ * and is expected to be maintained by caller of TI SCI protocol library.
+ *
+ * Return: 0 if all went fine, else corresponding error.
+ */
+const struct ti_sci_handle *devm_ti_sci_get_by_phandle(struct device *dev,
+ const char *property)
+{
+ const struct ti_sci_handle *handle;
+ const struct ti_sci_handle **ptr;
+
+ ptr = devres_alloc(devm_ti_sci_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+ handle = ti_sci_get_by_phandle(dev_of_node(dev), property);
+
+ if (!IS_ERR(handle)) {
+ *ptr = handle;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return handle;
+}
+EXPORT_SYMBOL_GPL(devm_ti_sci_get_by_phandle);
+
static int tisci_reboot_handler(struct notifier_block *nb, unsigned long mode,
void *cmd)
{
diff --git a/include/linux/soc/ti/ti_sci_protocol.h
b/include/linux/soc/ti/ti_sci_protocol.h
index 18435e5c6364..515587e9d373 100644
--- a/include/linux/soc/ti/ti_sci_protocol.h
+++ b/include/linux/soc/ti/ti_sci_protocol.h
@@ -217,6 +217,10 @@ struct ti_sci_handle {
const struct ti_sci_handle *ti_sci_get_handle(struct device *dev);
int ti_sci_put_handle(const struct ti_sci_handle *handle);
const struct ti_sci_handle *devm_ti_sci_get_handle(struct device *dev);
+const struct ti_sci_handle *ti_sci_get_by_phandle(struct device_node *np,
+ const char *property);
+const struct ti_sci_handle *devm_ti_sci_get_by_phandle(struct device *dev,
+
[PATCH v6 06/12] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
Add the DT binding documentation for Interrupt router driver.
Signed-off-by: Lokesh Vutla
---
Changes since v5:
- Introduced a new property for specifying router trigger type.
- Dropped the trigger type from interrupt cells property.
Marc,
Firmware change to not differentiate INTA interrupts and peripheral
interrupts might take couple more weeks, but it is going to come.
I am posting this series to get a review on the INTA driver.
.../interrupt-controller/ti,sci-intr.txt | 83 +++
MAINTAINERS | 1 +
2 files changed, 84 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
new file mode 100644
index ..613911013db1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
@@ -0,0 +1,83 @@
+Texas Instruments K3 Interrupt Router
+=
+
+The Interrupt Router (INTR) module provides a mechanism to mux M
+interrupt inputs to N interrupt outputs, where all M inputs are selectable
+to be driven per N output. An Interrupt Router can either handle edge triggered
+or level triggered interrupts and that is fixed in hardware.
+
+ Interrupt Router
+ +--+
+ | Inputs Outputs |
++---+| +--+ |
+| GPIO |--->| | irq0 | | Host IRQ
++---+| +--+ | controller
+ |.+-+ | +---+
++---+|.| 0 | |->| IRQ |
+| INTA |--->|.+-+ | +---+
++---+|. . |
+ | +--+ . |
+ | | irqM |+-+ |
+ | +--+| N | |
+ | +-+ |
+ +--+
+
+There is one register per output (MUXCNTL_N) that controls the selection.
+Configuration of these MUXCNTL_N registers is done by a system controller
+(like the Device Memory and Security Controller on K3 AM654 SoC). System
+controller will keep track of the used and unused registers within the Router.
+Driver should request the system controller to get the range of GIC IRQs
+assigned to the requesting hosts. It is the drivers responsibility to keep
+track of Host IRQs.
+
+Communication between the host processor running an OS and the system
+controller happens through a protocol called TI System Control Interface
+(TISCI protocol). For more details refer:
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+TISCI Interrupt Router Node:
+
+Required Properties:
+- compatible: Must be "ti,sci-intr".
+- ti,intr-trigger-type:Should be 1 if the interrupt router supports
edge
+ triggered interrupts, 4 for level triggered interrupts.
+- interrupt-controller:Identifies the node as an interrupt controller
+- #interrupt-cells:Specifies the number of cells needed to encode an
+ interrupt source. The value should be 3.
+ First cell should contain the TISCI device ID of source
+ Second cell should contain the interrupt source offset
+ within the device.
+ Third cell should be 1 if the irq is coming from the
+ interrupt aggregator else 0.
+- ti,sci: Phandle to TI-SCI compatible System controller node.
+- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
+- ti,sci-rm-range-girq:Array of TISCI subtype ids representing the
host irqs
+ assigned to this interrupt router. Each subtype id
+ corresponds to a range of host irqs.
+
+For more details on TISCI IRQ resource management refer:
+http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
+
+Example:
+
+The following example demonstrates both interrupt router node and the consumer
+node(main gpio) on the AM654 SoC:
+
+main_intr: interrupt-controller0 {
+ compatible = "ti,sci-intr";
+ ti,intr-trigger-type = <1>;
+ interrupt-controller;
+ interrupt-parent = <>;
+ #interrupt-cells = <3>;
+ ti,sci = <>;
+ ti,sci-dst-id = <56>;
+ ti,sci-rm-range-girq = <0x1>;
+};
+
+main_gpio0: gpio@60 {
+ ...
+ interrupt-parent = <_intr>;
+ interrupts = <57 256 0>, <57 257 0>, <57 258 0>,
+<57 259 0>, <57 260 0>, <57 261
[PATCH v6 07/12] irqchip: ti-sci-intr: Add support for Interrupt Router driver
Texas Instruments' K3 generation SoCs has an IP Interrupt Router
that does allows for redirection of input interrupts to host
interrupt controller. Interrupt Router inputs are either from a
peripheral or from an Interrupt Aggregator which is another
interrupt controller.
Configuration of the interrupt router registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.
Add support for Interrupt Router driver over TISCI protocol.
Signed-off-by: Lokesh Vutla
---
Changes since v5:
- Updated to latest bindings
MAINTAINERS | 1 +
drivers/irqchip/Kconfig | 11 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ti-sci-intr.c | 289 ++
4 files changed, 302 insertions(+)
create mode 100644 drivers/irqchip/irq-ti-sci-intr.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 9c4e71187ca1..6f551053627f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15350,6 +15350,7 @@ F:
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
F: drivers/clk/keystone/sci-clk.c
F: drivers/reset/reset-ti-sci.c
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
+F: drivers/irqchip/irq-ti-sci-intr.c
Texas Instruments ASoC drivers
M: Peter Ujfalusi
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 5438abb1baba..a1ff64c1d40d 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -425,6 +425,17 @@ config LS1X_IRQ
help
Support for the Loongson-1 platform Interrupt Controller.
+config TI_SCI_INTR_IRQCHIP
+ bool
+ depends on TI_SCI_PROTOCOL && ARCH_K3
+ select IRQ_DOMAIN
+ select IRQ_DOMAIN_HIERARCHY
+ help
+ This enables the irqchip driver support for K3 Interrupt router
+ over TI System Control Interface available on some new TI's SoCs.
+ If you wish to use interrupt router irq resources managed by the
+ TI System Controller, say Y here. Otherwise, say N.
+
endmenu
config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 85972ae1bd7f..fa5c865788b5 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -97,3 +97,4 @@ obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o
obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
obj-$(CONFIG_MADERA_IRQ) += irq-madera.o
obj-$(CONFIG_LS1X_IRQ) += irq-ls1x.o
+obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o
diff --git a/drivers/irqchip/irq-ti-sci-intr.c
b/drivers/irqchip/irq-ti-sci-intr.c
new file mode 100644
index ..03d0e201153c
--- /dev/null
+++ b/drivers/irqchip/irq-ti-sci-intr.c
@@ -0,0 +1,289 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Router irqchip driver
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TI_SCI_DEV_ID_MASK 0x
+#define TI_SCI_DEV_ID_SHIFT16
+#define TI_SCI_IRQ_ID_MASK 0x
+#define TI_SCI_IRQ_ID_SHIFT0
+#define HWIRQ_TO_DEVID(hwirq) (((hwirq) >> (TI_SCI_DEV_ID_SHIFT)) & \
+(TI_SCI_DEV_ID_MASK))
+#define HWIRQ_TO_IRQID(hwirq) ((hwirq) & (TI_SCI_IRQ_ID_MASK))
+#define TO_HWIRQ(dev, index) dev) & TI_SCI_DEV_ID_MASK) << \
+TI_SCI_DEV_ID_SHIFT) | \
+ ((index) & TI_SCI_IRQ_ID_MASK))
+
+/**
+ * struct ti_sci_intr_irq_domain - Structure representing a TISCI based
+ *Interrupt Router IRQ domain.
+ * @sci: Pointer to TISCI handle
+ * @dst_irq: TISCI resource pointer representing GIC irq controller.
+ * @dst_id:TISCI device ID of the GIC irq controller.
+ * @num_inta: No. of Interrupt Aggregators attached to this Interrupt Router
+ * @inta_ids: List of Interrupt Aggregator IDs.
+ * @type: Specifies the trigger type supported by this Interrupt Router
+ */
+struct ti_sci_intr_irq_domain {
+ const struct ti_sci_handle *sci;
+ struct ti_sci_resource *dst_irq;
+ u32 dst_id;
+ int num_inta;
+ u32 *inta_ids;
+ u32 type;
+};
+
+static struct irq_chip ti_sci_intr_irq_chip = {
+ .name = "INTR",
+ .irq_eoi= irq_chip_eoi_parent,
+ .irq_mask = irq_chip_mask_parent,
+ .irq_unmask = irq_chip_unmask_parent,
+ .irq_retrigger = irq_chip_retrigger_hierarchy,
+ .irq_set_type = irq_chip_set_type_parent,
+ .irq_set_affinity = irq_chip_set_affinity_parent,
+};
+
+/**
+ * ti_sci_intr_irq_domain_translate() - Retrieve hwirq and type from
+ * IRQ firmware specific handler.
+ * @domain:Pointer
[PATCH v6 03/12] firmware: ti_sci: Add support for IRQ management
TISCI abstracts the handling of IRQ routes where interrupt sources
are not directly connected to host interrupt controller. Add support
for the set of TISCI commands for requesting and releasing IRQs.
Signed-off-by: Lokesh Vutla
---
Changes since v5:
- None
drivers/firmware/ti_sci.c | 260 +
drivers/firmware/ti_sci.h | 60 ++
include/linux/soc/ti/ti_sci_protocol.h | 28 +++
3 files changed, 348 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 503195223c09..d303f5a14da9 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1765,6 +1765,260 @@ int ti_sci_cmd_get_resource_range_from_shost(const
struct ti_sci_handle *handle,
range_start, range_num);
}
+/**
+ * ti_sci_manage_irq() - Helper api to configure/release the irq route between
+ * the requested source and destination
+ * @handle:Pointer to TISCI handle.
+ * @valid_params: Bit fields defining the validity of certain params
+ * @src_id:Device ID of the IRQ source
+ * @src_index: IRQ source index within the source device
+ * @dst_id:Device ID of the IRQ destination
+ * @dst_host_irq: IRQ number of the destination device
+ * @ia_id: Device ID of the IA, if the IRQ flows through this IA
+ * @vint: Virtual interrupt to be used within the IA
+ * @global_event: Global event number to be used for the requesting event
+ * @vint_status_bit: Virtual interrupt status bit to be used for the event
+ * @s_host:Secondary host ID to which the irq/event is being
+ * requested for.
+ * @type: Request type irq set or release.
+ *
+ * Return: 0 if all went fine, else return appropriate error.
+ */
+static int ti_sci_manage_irq(const struct ti_sci_handle *handle,
+u32 valid_params, u16 src_id, u16 src_index,
+u16 dst_id, u16 dst_host_irq, u16 ia_id, u16 vint,
+u16 global_event, u8 vint_status_bit, u8 s_host,
+u16 type)
+{
+ struct ti_sci_msg_req_manage_irq *req;
+ struct ti_sci_msg_hdr *resp;
+ struct ti_sci_xfer *xfer;
+ struct ti_sci_info *info;
+ struct device *dev;
+ int ret = 0;
+
+ if (IS_ERR(handle))
+ return PTR_ERR(handle);
+ if (!handle)
+ return -EINVAL;
+
+ info = handle_to_ti_sci_info(handle);
+ dev = info->dev;
+
+ xfer = ti_sci_get_one_xfer(info, type, TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+ sizeof(*req), sizeof(*resp));
+ if (IS_ERR(xfer)) {
+ ret = PTR_ERR(xfer);
+ dev_err(dev, "Message alloc failed(%d)\n", ret);
+ return ret;
+ }
+ req = (struct ti_sci_msg_req_manage_irq *)xfer->xfer_buf;
+ req->valid_params = valid_params;
+ req->src_id = src_id;
+ req->src_index = src_index;
+ req->dst_id = dst_id;
+ req->dst_host_irq = dst_host_irq;
+ req->ia_id = ia_id;
+ req->vint = vint;
+ req->global_event = global_event;
+ req->vint_status_bit = vint_status_bit;
+ req->secondary_host = s_host;
+
+ ret = ti_sci_do_xfer(info, xfer);
+ if (ret) {
+ dev_err(dev, "Mbox send fail %d\n", ret);
+ goto fail;
+ }
+
+ resp = (struct ti_sci_msg_hdr *)xfer->xfer_buf;
+
+ ret = ti_sci_is_response_ack(resp) ? 0 : -ENODEV;
+
+fail:
+ ti_sci_put_one_xfer(>minfo, xfer);
+
+ return ret;
+}
+
+/**
+ * ti_sci_set_irq() - Helper api to configure the irq route between the
+ * requested source and destination
+ * @handle:Pointer to TISCI handle.
+ * @valid_params: Bit fields defining the validity of certain params
+ * @src_id:Device ID of the IRQ source
+ * @src_index: IRQ source index within the source device
+ * @dst_id:Device ID of the IRQ destination
+ * @dst_host_irq: IRQ number of the destination device
+ * @ia_id: Device ID of the IA, if the IRQ flows through this IA
+ * @vint: Virtual interrupt to be used within the IA
+ * @global_event: Global event number to be used for the requesting event
+ * @vint_status_bit: Virtual interrupt status bit to be used for the event
+ * @s_host:Secondary host ID to which the irq/event is being
+ * requested for.
+ *
+ * Return: 0 if all went fine, else return appropriate error.
+ */
+static int ti_sci_set_irq(const struct ti_sci_handle *handle, u32 valid_params,
+ u16 src_id, u16 src_index, u16 dst_id,
+ u16 dst_host_irq, u16 ia_id, u16 vint,
+ u16 global_event, u8 vint_status_bit, u8 s_host)
+{
+
[PATCH v6 04/12] firmware: ti_sci: Add RM mapping table for am654
From: Peter Ujfalusi
Add the resource mapping table for AM654 SoC as defined in
http://downloads.ti.com/tisci/esd/latest/5_soc_doc/am6x/resasg_types.html
Introduce a new compatible for AM654 "ti,am654-sci" for using
this resource map table.
Reviewed-by: Rob Herring
Signed-off-by: Peter Ujfalusi
Signed-off-by: Lokesh Vutla
---
Changes since v4:
- None
.../bindings/arm/keystone/ti,sci.txt | 3 ++-
.../bindings/arm/keystone/ti,sci.txt | 3 ++-
drivers/firmware/ti_sci.c | 23 +++
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
index b56a02c10ae6..6f0cd31c1520 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
@@ -24,7 +24,8 @@ relationship between the TI-SCI parent node to the child node.
Required properties:
---
-- compatible: should be "ti,k2g-sci"
+- compatible: should be "ti,k2g-sci" for TI 66AK2G SoC
+ should be "ti,am654-sci" for for TI AM654 SoC
- mbox-names:
"rx" - Mailbox corresponding to receive path
"tx" - Mailbox corresponding to transmit path
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index d303f5a14da9..88e461498def 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -2297,10 +2297,33 @@ static const struct ti_sci_desc ti_sci_pmmc_k2g_desc = {
/* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
.max_msgs = 20,
.max_msg_size = 64,
+ .rm_type_map = NULL,
+};
+
+static struct ti_sci_rm_type_map ti_sci_am654_rm_type_map[] = {
+ {.dev_id = 56, .type = 0x00b}, /* GIC_IRQ */
+ {.dev_id = 179, .type = 0x000}, /* MAIN_NAV_UDMASS_IA0 */
+ {.dev_id = 187, .type = 0x009}, /* MAIN_NAV_RA */
+ {.dev_id = 188, .type = 0x006}, /* MAIN_NAV_UDMAP */
+ {.dev_id = 194, .type = 0x007}, /* MCU_NAV_UDMAP */
+ {.dev_id = 195, .type = 0x00a}, /* MCU_NAV_RA */
+ {.dev_id = 0, .type = 0x000}, /* end of table */
+};
+
+/* Description for AM654 */
+static const struct ti_sci_desc ti_sci_pmmc_am654_desc = {
+ .default_host_id = 12,
+ /* Conservative duration */
+ .max_rx_timeout_ms = 1,
+ /* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
+ .max_msgs = 20,
+ .max_msg_size = 60,
+ .rm_type_map = ti_sci_am654_rm_type_map,
};
static const struct of_device_id ti_sci_of_match[] = {
{.compatible = "ti,k2g-sci", .data = _sci_pmmc_k2g_desc},
+ {.compatible = "ti,am654-sci", .data = _sci_pmmc_am654_desc},
{ /* Sentinel */ },
};
MODULE_DEVICE_TABLE(of, ti_sci_of_match);
--
2.21.0
[PATCH v6 02/12] firmware: ti_sci: Add support for RM core ops
TISCI provides support for getting the resources(IRQ, RING etc..)
assigned to a specific device. These resources can be handled by
the client and in turn sends TISCI cmd to configure the resources.
It is very important that client should keep track on usage of these
resources.
Add support for TISCI commands to get resource ranges.
Signed-off-by: Lokesh Vutla
Signed-off-by: Peter Ujfalusi
---
Changes since v5:
- None
drivers/firmware/ti_sci.c | 170 +
drivers/firmware/ti_sci.h | 42 ++
include/linux/soc/ti/ti_sci_protocol.h | 27
3 files changed, 239 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 852043531233..503195223c09 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -64,6 +64,22 @@ struct ti_sci_xfers_info {
spinlock_t xfer_lock;
};
+/**
+ * struct ti_sci_rm_type_map - Structure representing TISCI Resource
+ * management representation of dev_ids.
+ * @dev_id:TISCI device ID
+ * @type: Corresponding id as identified by TISCI RM.
+ *
+ * Note: This is used only as a work around for using RM range apis
+ * for AM654 SoC. For future SoCs dev_id will be used as type
+ * for RM range APIs. In order to maintain ABI backward compatibility
+ * type is not being changed for AM654 SoC.
+ */
+struct ti_sci_rm_type_map {
+ u32 dev_id;
+ u16 type;
+};
+
/**
* struct ti_sci_desc - Description of SoC integration
* @default_host_id: Host identifier representing the compute entity
@@ -71,12 +87,14 @@ struct ti_sci_xfers_info {
* @max_msgs: Maximum number of messages that can be pending
* simultaneously in the system
* @max_msg_size: Maximum size of data per message that can be handled.
+ * @rm_type_map: RM resource type mapping structure.
*/
struct ti_sci_desc {
u8 default_host_id;
int max_rx_timeout_ms;
int max_msgs;
int max_msg_size;
+ struct ti_sci_rm_type_map *rm_type_map;
};
/**
@@ -1600,6 +1618,153 @@ static int ti_sci_cmd_core_reboot(const struct
ti_sci_handle *handle)
return ret;
}
+static int ti_sci_get_resource_type(struct ti_sci_info *info, u16 dev_id,
+ u16 *type)
+{
+ struct ti_sci_rm_type_map *rm_type_map = info->desc->rm_type_map;
+ bool found = false;
+ int i;
+
+ /* If map is not provided then assume dev_id is used as type */
+ if (!rm_type_map) {
+ *type = dev_id;
+ return 0;
+ }
+
+ for (i = 0; rm_type_map[i].dev_id; i++) {
+ if (rm_type_map[i].dev_id == dev_id) {
+ *type = rm_type_map[i].type;
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * ti_sci_get_resource_range - Helper to get a range of resources assigned
+ *to a host. Resource is uniquely identified by
+ *type and subtype.
+ * @handle:Pointer to TISCI handle.
+ * @dev_id:TISCI device ID.
+ * @subtype: Resource assignment subtype that is being requested
+ * from the given device.
+ * @s_host:Host processor ID to which the resources are allocated
+ * @range_start: Start index of the resource range
+ * @range_num: Number of resources in the range
+ *
+ * Return: 0 if all went fine, else return appropriate error.
+ */
+static int ti_sci_get_resource_range(const struct ti_sci_handle *handle,
+u32 dev_id, u8 subtype, u8 s_host,
+u16 *range_start, u16 *range_num)
+{
+ struct ti_sci_msg_resp_get_resource_range *resp;
+ struct ti_sci_msg_req_get_resource_range *req;
+ struct ti_sci_xfer *xfer;
+ struct ti_sci_info *info;
+ struct device *dev;
+ u16 type;
+ int ret = 0;
+
+ if (IS_ERR(handle))
+ return PTR_ERR(handle);
+ if (!handle)
+ return -EINVAL;
+
+ info = handle_to_ti_sci_info(handle);
+ dev = info->dev;
+
+ xfer = ti_sci_get_one_xfer(info, TI_SCI_MSG_GET_RESOURCE_RANGE,
+ TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+ sizeof(*req), sizeof(*resp));
+ if (IS_ERR(xfer)) {
+ ret = PTR_ERR(xfer);
+ dev_err(dev, "Message alloc failed(%d)\n", ret);
+ return ret;
+ }
+
+ ret = ti_sci_get_resource_type(info, dev_id, );
+ if (ret) {
+ dev_err(dev, "rm type lookup failed for %u\n", dev_id);
+ goto fail;
+ }
+
+ req = (struct ti_sci_msg_req_get_resource_range *)xfer->xfer_buf;
+ req->secondary_host = s_host;
+ req->type = type
[PATCH v6 00/12] Add support for TISCI Interrupt controller drivers
TI AM65x SoC based on K3 architecture introduced support for Events which are message based interrupts with minimal latency. These events are not compatible with regular interrupts and are valid only through an event transport lane. An Interrupt Aggregator(INTA) is introduced to convert these events to interrupts. INTA can also group 64 events into a single interrupt. Now the SoC has many peripherals and a large number of event sources (time sync or DMA), the use of events is completely dependent on a user's specific application, which drives a need for maximum flexibility in which event sources are used in the system. It is also completely up to software control as to how the events are serviced. Because of the huge flexibility there are certain standard peripherals (like GPIO etc)where all interrupts cannot be directly corrected to host interrupt controller. For this purpose, Interrupt Router(INTR) is introduced in the SoC. INTR just does a classic interrupt redirection. So the SoC has 3 types of interrupt controllers: - GIC500 - Interrupt Router - Interrupt Aggregator Below is a diagrammatic view of how SoC integration of these interrupt controllers:(https://pastebin.ubuntu.com/p/9ngV3jdGj2/) Device Index-x Device Index-y | | | | \ / \ / \ (global events) / +---+ +-+ | | | | | INTA | | GPIO | | | | | +---+ +-+ | (vint)| | | \|/| +---+| | |<---+ | INTR| | | +---+ | | \|/ (gic irq) +---+ | | | GIC | | | +---+ While at it, TISCI abstracts the handling of all above IRQ routes where interrupt sources are not directly connected to host interrupt controller. That would be configuration of Interrupt Aggregator and Interrupt Router. This series adds support for: - TISCI commands needed for IRQ configuration - Interrupt Router(INTR) driver. - Interrupt Aggregator(INTA) driver. - Interrupt Aggregator MSI bus layer. Changes since v5: - Each patch has respective changes mentioned. Grygorii Strashko (1): firmware: ti_sci: Add support to get TISCI handle using of_phandle Lokesh Vutla (10): firmware: ti_sci: Add support for RM core ops firmware: ti_sci: Add support for IRQ management firmware: ti_sci: Add helper apis to manage resources dt-bindings: irqchip: Introduce TISCI Interrupt router bindings irqchip: ti-sci-intr: Add support for Interrupt Router driver dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver soc: ti: Add MSI domain bus support for Interrupt Aggregator irqchip: ti-sci-inta: Add msi domain support soc: ti: am6: Enable interrupt controller driver Peter Ujfalusi (1): firmware: ti_sci: Add RM mapping table for am654 .../bindings/arm/keystone/ti,sci.txt | 3 +- .../interrupt-controller/ti,sci-inta.txt | 66 ++ .../interrupt-controller/ti,sci-intr.txt | 83 +++ MAINTAINERS | 6 + drivers/firmware/ti_sci.c | 666 ++ drivers/firmware/ti_sci.h | 102 +++ drivers/irqchip/Kconfig | 23 + drivers/irqchip/Makefile | 2 + drivers/irqchip/irq-ti-sci-inta.c | 659 + drivers/irqchip/irq-ti-sci-intr.c | 289 drivers/soc/ti/Kconfig| 11 + drivers/soc/ti/Makefile | 1 + drivers/soc/ti/ti_sci_inta_msi.c | 167 + include/linux/irqdomain.h | 1 + include/linux/msi.h | 6 + include/linux/soc/ti/ti_sci_inta_msi.h| 23 + include/linux/soc/ti/ti_sci_protocol.h| 126 17 files changed, 2233 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt create mode 100644 drivers/irqchip/irq-ti-sci-inta.c create mode 100644 drivers/irqchip/irq-ti-sci-intr.c create mode
[PATCH v5 4/6] dax: check synchronous mapping is supported
This patch introduces 'daxdev_mapping_supported' helper
which checks if 'MAP_SYNC' is supported with filesystem
mapping. It also checks if corresponding dax_device is
synchronous. Virtio pmem device is asynchronous and
does not not support VM_SYNC.
Suggested-by: Jan Kara
Signed-off-by: Pankaj Gupta
---
include/linux/dax.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/include/linux/dax.h b/include/linux/dax.h
index b896706a5ee9..4a2a60ffec86 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -38,6 +38,24 @@ void kill_dax(struct dax_device *dax_dev);
void dax_write_cache(struct dax_device *dax_dev, bool wc);
bool dax_write_cache_enabled(struct dax_device *dax_dev);
bool dax_synchronous(struct dax_device *dax_dev);
+
+/*
+ * Callers check if synchronous mapping is enabled for DAX file
+ * and attached dax device is also synchronous.
+ *
+ * dax_synchronous function verifies if dax device is synchronous.
+ * Currently, only virtio pmem device supports asynchronous device
+ * flush.
+ */
+static inline bool daxdev_mapping_supported(struct vm_area_struct *vma,
+ struct dax_device *dax_dev)
+{
+ if (!(vma->vm_flags & VM_SYNC))
+ return true;
+ if (!IS_DAX(file_inode(vma->vm_file)))
+ return false;
+ return dax_synchronous(dax_dev);
+}
#else
static inline struct dax_device *dax_get_by_host(const char *host)
{
@@ -69,6 +87,11 @@ static inline bool dax_synchronous(struct dax_device
*dax_dev)
{
return true;
}
+static inline bool daxdev_mapping_supported(struct vm_area_struct *vma,
+ struct dax_device *dax_dev)
+{
+ return true;
+}
#endif
struct writeback_control;
--
2.20.1
Re: [PATCH 2/3] RISC-V: Make setup_vm() independent of GCC code model
On Tue, Apr 9, 2019 at 10:17 PM Palmer Dabbelt wrote:
>
> On Tue, 12 Mar 2019 15:08:16 PDT (-0700), Anup Patel wrote:
> > The setup_vm() must access kernel symbols in a position independent way
> > because it will be called from head.S with MMU off.
> >
> > If we compile kernel with cmodel=medany then PC-relative addressing will
> > be used in setup_vm() to access kernel symbols so it works perfectly fine.
> >
> > Although, if we compile kernel with cmodel=medlow then either absolute
> > addressing or PC-relative addressing (based on whichever requires fewer
> > instructions) is used to access kernel symbols in setup_vm(). This can
> > break setup_vm() whenever any absolute addressing is used to access
> > kernel symbols.
> >
> > With the movement of setup_vm() from kernel/setup.c to mm/init.c, the
> > setup_vm() is now broken for cmodel=medlow but it works perfectly fine
> > for cmodel=medany.
> >
> > This patch fixes setup_vm() and makes it independent of GCC code model
> > by accessing kernel symbols relative to kernel load address instead of
> > assuming PC-relative addressing.
>
> I think we ended up with a cleaner solution as 387181dcdb6c ("RISC-V: Always
> compile mm/init.c with cmodel=medany and notrace"), but let me know if I
> missed
> something here.
Yes, please ignore this patch. I have dropped it in latest version of
this patch series.
Regards,
Anup
[PATCH v5 5/6] ext4: disable map_sync for async flush
Dont support 'MAP_SYNC' with non-DAX files and DAX files
with asynchronous dax_device. Virtio pmem provides
asynchronous host page cache flush mechanism. We don't
support 'MAP_SYNC' with virtio pmem and ext4.
Signed-off-by: Pankaj Gupta
---
fs/ext4/file.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 69d65d49837b..4b2ccaf1932e 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -360,15 +360,16 @@ static const struct vm_operations_struct ext4_file_vm_ops
= {
static int ext4_file_mmap(struct file *file, struct vm_area_struct *vma)
{
struct inode *inode = file->f_mapping->host;
+ struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
+ struct dax_device *dax_dev = sbi->s_daxdev;
- if (unlikely(ext4_forced_shutdown(EXT4_SB(inode->i_sb
+ if (unlikely(ext4_forced_shutdown(sbi)))
return -EIO;
- /*
-* We don't support synchronous mappings for non-DAX files. At least
-* until someone comes with a sensible use case.
+ /* We don't support synchronous mappings for non-DAX files and
+* for DAX files if underneath dax_device is not synchronous.
*/
- if (!IS_DAX(file_inode(file)) && (vma->vm_flags & VM_SYNC))
+ if (!daxdev_mapping_supported(vma, dax_dev))
return -EOPNOTSUPP;
file_accessed(file);
--
2.20.1
Re: [PATCH 1/4] dt-bindings: opp: Introduce opp-bw-MBs bindings
On 09-04-19, 17:36, Georgi Djakov wrote:
> Hi Viresh,
>
> On 3/14/19 08:23, Viresh Kumar wrote:
> > On 13-03-19, 11:00, Georgi Djakov wrote:
> >> In addition to frequency and voltage, some devices may have bandwidth
> >> requirements for their interconnect throughput - for example a CPU
> >> or GPU may also need to increase or decrease their bandwidth to DDR
> >> memory based on the current operating performance point.
> >>
> >> Extend the OPP tables with additional property to describe the bandwidth
> >> needs of a device. The average and peak bandwidth values depend on the
> >> hardware and its properties.
> >>
> >> Signed-off-by: Georgi Djakov
> >> ---
> >> Documentation/devicetree/bindings/opp/opp.txt | 45 +++
> >> 1 file changed, 45 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/opp/opp.txt
> >> b/Documentation/devicetree/bindings/opp/opp.txt
> >> index 76b6c79604a5..fa598264615f 100644
> >> --- a/Documentation/devicetree/bindings/opp/opp.txt
> >> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> >> @@ -129,6 +129,9 @@ Optional properties:
> >> - opp-microamp-: Named opp-microamp property. Similar to
> >>opp-microvolt- property, but for microamp instead.
> >>
> >> +- opp-bw-MBs: The interconnect bandwidth is specified with an array
> >> containing
> >> + the two integer values for average and peak bandwidth in megabytes per
> >> second.
> >> +
> >> - opp-level: A value representing the performance level of the device,
> >>expressed as a 32-bit integer.
> >>
> >> @@ -546,3 +549,45 @@ Example 6: opp-microvolt-, opp-microamp-:
> >>};
> >>};
> >> };
> >> +
> >> +Example 7: opp-bw-MBs:
> >> +(example: average and peak bandwidth values are defined for each OPP and
> >> the
> >> +interconnect between CPU and DDR memory is scaled together with CPU
> >> frequency)
> >> +
> >> +/ {
> >> + cpus {
> >> + CPU0: cpu@0 {
> >> + compatible = "arm,cortex-a53", "arm,armv8";
> >> + ...
> >> + operating-points-v2 = <_opp_table>;
> >> + /* path between the CPU and DDR memory */
> >> + interconnects = <_bimc MASTER_AMPSS_M0
> >> + _bimc SLAVE_EBI_CH0>;
> >
> > Can we have multiple paths for a device ?
>
> I suppose that this is also a possible scenario. Will propose something
> to handle multiple paths too.
>
> >> + };
> >> + };
> >> +
> >> + cpu_opp_table: cpu_opp_table {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + opp-2 {
> >> + opp-hz = /bits/ 64 <2>;
> >> + /* 457 MB/s average and 1525 MB/s peak bandwidth */
> >> + opp-bw-MBs = <457 1525>;
> >
> > In that case fixing this to just 2 entries in the array is incorrect
> > and we should take care of that in the bindings here.
>
> We can encode the path name into the property (when there are multiple
> paths). We already have opp-microamp- and opp-microamp-, so
> we can follow the same practice.
>
> For example:
>
> CPU0: cpu@0 {
> compatible = "arm,cortex-a53", "arm,armv8";
> ...
> operating-points-v2 = <_opp_table>;
> /* path between the CPU and DDR and path between CPU and L3 */
> interconnects = < MASTER_AMPSS_M0 SLAVE_EBI_CH0>,
> < MASTER_AMPSS_M0 SLAVE_L3>;
> interconnect-names "cpu-mem", "cpu-l3";
> };
>
> cpu_opp_table: cpu_opp_table {
> compatible = "operating-points-v2";
> opp-shared;
>
> opp-2 {
> opp-hz = /bits/ 64 <2>;
> /* 457 MB/s average, 1525 MB/s peak bandwidth to DDR */
> opp-bw-MBps-cpu-mem = <457 1525>;
> /* 914 MB/s average, 3050 MB/s peak bandwidth to L3 */
> opp-bw-MBps-cpu-l3 = <914 3050>;
> };
> };
The - property is different as only one of the value is ever used, i.e. we
can have opp-microvolt-speed0/1/2/3 (4 different values/properties) and only
opp-microvolt-speed1 will be used eventually and all others are discarded.
Also I am not sure if this will be actually required. We already have a list of
interconnects above and the order of that can be taken as reference here. i.e.
CPU0: cpu@0 {
compatible = "arm,cortex-a53", "arm,armv8";
...
operating-points-v2 = <_opp_table>;
/* path between the CPU and DDR and path between CPU and L3 */
interconnects = < MASTER_AMPSS_M0 SLAVE_EBI_CH0>,
< MASTER_AMPSS_M0 SLAVE_L3>;
};
cpu_opp_table: cpu_opp_table {
compatible = "operating-points-v2";
opp-shared;
opp-2 {
opp-hz = /bits/ 64 <2>;
/* 457 MB/s average, 1525 MB/s peak bandwidth to DDR */
/* 914 MB/s average, 3050 MB/s peak bandwidth to L3 */
opp-bw-MBps = <457
Re: linux-next: build failure after merge of the scsi-mkp tree
On Tue, 2019-04-09 at 21:33 -0400, Martin K. Petersen wrote: > Stephen, > > > > I have reverted that commit for today. > > > > This has now migrated to the scsi tree. > > I have a fix in my tree but I haven't pushed it yet. It's upstream in both trees now. James
Re: [PATCH 2/4] OPP: Add support for parsing the interconnect bandwidth
On 09-04-19, 17:37, Georgi Djakov wrote: > Hi Viresh, > > On 3/14/19 08:30, Viresh Kumar wrote: > > On 13-03-19, 11:00, Georgi Djakov wrote: > >> The OPP bindings now support bandwidth values, so add support to parse it > >> from device tree and store it into the new dev_pm_opp_icc_bw struct, which > >> is part of the dev_pm_opp. > >> > >> Also add and export the dev_pm_opp_set_path() and dev_pm_opp_put_path() > >> helpers, to set (and release) an interconnect path to a device. The > >> bandwidth of this path will be updated when the OPPs are switched. > >> > >> Signed-off-by: Georgi Djakov > >> --- > >> drivers/opp/core.c | 67 ++ > >> drivers/opp/of.c | 44 +++ > >> drivers/opp/opp.h | 6 > >> include/linux/pm_opp.h | 14 + > >> 4 files changed, 131 insertions(+) > >> > >> diff --git a/drivers/opp/core.c b/drivers/opp/core.c > >> index e06a0ab05ad6..4b019cecaa07 100644 > >> --- a/drivers/opp/core.c > >> +++ b/drivers/opp/core.c > >> @@ -19,6 +19,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> #include > >> #include > >> > >> @@ -1645,6 +1646,72 @@ void dev_pm_opp_put_clkname(struct opp_table > >> *opp_table) > >> } > >> EXPORT_SYMBOL_GPL(dev_pm_opp_put_clkname); > >> > >> +/** > >> + * dev_pm_opp_set_path() - Set interconnect path for a device > >> + * @dev: Device for which interconnect path is being set. > >> + * @name: Interconnect path name or NULL. > >> + * > >> + * This must be called before any OPPs are initialized for the device. > >> + */ > >> +struct opp_table *dev_pm_opp_set_path(struct device *dev, const char > >> *name) > > > > Maybe the OPP core can do it itself in a similar way to how we do > > clk_get() today ? It took me a decade to understand my own comment ;) > Do you mean to directly call of_icc_get() in _allocate_opp_table()? I believe I wanted to say s/clk_get()/clk_set_rate()/ . i.e. if someone calls set-opp-rate, then the path should get set as well accordingly automagically. -- viresh
Re: [PULL -- 5.1 REGRESSION] Bluetooth: btusb: request wake pin with NOAUTOEN
On Tue, Apr 9, 2019 at 5:26 PM Brian Norris wrote: > > So, I think the problem is still potentially present no matter when we > request the IRQ. The "uninitialized" state of the hardware (or, > firmware) just exposes the issue extremely clearly. Well, I think that as long as you don't request the irq, and it's not shared with anything else, the bogus state of the irq line simply doesn't matter. So the NOAUTOEN shouldn't matter if the irq is requested properly late. Either it's edge-triggered and you'll get one possibly spurious interrupt for an old issue, or it's level-triggered and setting up the hw should bring the irq line inactive and you'll be ok. But I've applied your patch for now simply because it seems to be a smaller change. But I think you should look into whether it can be fixed by just requesting the irq once the hardware is really up (which may indeed be as late as open time). Linus
Re: [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output
On 2019/4/10 10:36, Li, Aubrey wrote:
> On 2019/4/10 10:25, Andy Lutomirski wrote:
>> On Tue, Apr 9, 2019 at 7:20 PM Li, Aubrey wrote:
>>>
>>> On 2019/4/10 9:58, Andy Lutomirski wrote:
On Tue, Apr 9, 2019 at 6:55 PM Aubrey Li wrote:
>
> The architecture specific information of the running processes could
> be useful to the userland. Add support to examine process architecture
> specific information externally.
>
> Signed-off-by: Aubrey Li
> Cc: Peter Zijlstra
> Cc: Andi Kleen
> Cc: Tim Chen
> Cc: Dave Hansen
> Cc: Arjan van de Ven
> Cc: Linux API
> Cc: Alexey Dobriyan
> Cc: Andrew Morton
> ---
> fs/proc/array.c | 5 +
> include/linux/proc_fs.h | 2 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index 2edbb657f859..331592a61718 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -401,6 +401,10 @@ static inline void task_thp_status(struct seq_file
> *m, struct mm_struct *mm)
> seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
> }
>
> +void __weak arch_proc_pid_status(struct seq_file *m, struct task_struct
> *task)
> +{
> +}
This pointlessly bloats other architectures. Do this instead in an
appropriate header:
#ifndef arch_proc_pid_status
static inline void arch_proc_pid_status(...)
{
}
#endif
>>>
>>> I saw a bunch of similar weak functions, is it not acceptable?
>>>
>>> fs/proc$ grep weak *.c
>>> cpuinfo.c:__weak void arch_freq_prepare_all(void)
>>> meminfo.c:void __attribute__((weak)) arch_report_meminfo(struct seq_file *m)
>>> vmcore.c:int __weak elfcorehdr_alloc(unsigned long long *addr, unsigned
>>> long long *size)
>>> vmcore.c:void __weak elfcorehdr_free(unsigned long long addr)
>>> vmcore.c:ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos)
>>> vmcore.c:ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64
>>> *ppos)
>>> vmcore.c:int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
>>> vmcore.c:ssize_t __weak
>>
>> I think they're acceptable, but I don't personally like them.
>>
>
> okay, let me try to see if I can refine it in an appropriate way.
Hi Andy,
Is this what you want?
Thanks,
-Aubrey
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 2bb3a648fc12..82d77d3aefff 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -990,5 +990,8 @@ enum l1tf_mitigations {
};
extern enum l1tf_mitigations l1tf_mitigation;
+/* Add support for architecture specific output in /proc/pid/status */
+void arch_proc_pid_status(struct seq_file *m, struct task_struct *task);
+#define arch_proc_pid_status arch_proc_pid_status
#endif /* _ASM_X86_PROCESSOR_H */
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 2edbb657f859..fd65a6ba2864 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -401,6 +401,11 @@ static inline void task_thp_status(struct seq_file *m,
struct mm_struct *mm)
seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
}
+/* Add support for architecture specific output in /proc/pid/status */
+#ifndef arch_proc_pid_status
+#define arch_proc_pid_status(m, task)
+#endif
+
int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task)
{
@@ -424,6 +429,7 @@ int proc_pid_status(struct seq_file *m, struct
pid_namespace *ns,
task_cpus_allowed(m, task);
cpuset_task_status_allowed(m, task);
task_context_switch_counts(m, task);
+ arch_proc_pid_status(m, task);
return 0;
}
Re: [PATCH 2/2] module: Make srcu_struct ptr array as read-only post init
On Tue, Apr 9, 2019 at 10:48 PM Steven Rostedt wrote: > > On Tue, 9 Apr 2019 22:41:03 -0400 > Joel Fernandes wrote: > > > > Other than that, the two patches look fine to me. > > > > Could I add your Reviewed-by in the respin? > > You can add an Acked-by, as I haven't spent enough time to offer a > Reviewed-by tag. ;-) > > Maybe I'll get some time to vet it a bit more tomorrow, and then > upgrade the ack to a review. > > Acked-by: Steven Rostedt (VMware) > Thanks! Also we could possibly consider adding the tracepoint ptrs array as well to the list, which would be useful I think, if one were to over write that array by accident (and the bpf tps related array too). - Joel
Re: [PATCH 0/6] objtool: Add support for Arm64
On Tue, Apr 09, 2019 at 10:43:18AM -0700, Ard Biesheuvel wrote: > On Tue, 9 Apr 2019 at 06:53, Raphael Gault wrote: > > > > Hi, > > > > As of now, objtool only supports the x86_64 architecture but the > > groundwork has already been done in order to add support for other > > architecture without too much effort. > > > > This series of patches adds support for the arm64 architecture > > based on the Armv8.5 Architecture Reference Manual. > > > > I think it makes sense to clarify *why* we want this on arm64. Also, > we should identify things that objtool does today that maybe we don't > want on arm64, rather than buy into all of it by default. Agreed, the "why" should at least be in the cover letter. From my perspective, the "why" includes: - Live patching - objtool stack validation is the foundation for a reliable unwinder - ORC unwinder - benefits include presumed improved overall performance from disabling frame pointers, and the ability to unwind across interrupts and exceptions - PeterZ's new uaccess validation? -- Josh
Re: [PATCH] spi: spi-mem: Fix build error without CONFIG_SPI_MEM
On 2019/4/10 0:30, Vignesh Raghavendra wrote:
> On 08/04/19 8:09 PM, Yue Haibing wrote:
>> From: YueHaibing
>>
>> When building with CONFIG_SPI_MEM is not set
>> gc warns this:
>>
>> drivers/spi/spi-zynq-qspi.o: In function `zynq_qspi_supports_op':
>> spi-zynq-qspi.c:(.text+0x1da): undefined reference to
>> `spi_mem_default_supports_op'
>>
>> Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI controller")
>> Signed-off-by: YueHaibing
>> ---
>> include/linux/spi/spi-mem.h | 14 +++---
>> 1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
>> index c845cd6..1941b84 100644
>> --- a/include/linux/spi/spi-mem.h
>> +++ b/include/linux/spi/spi-mem.h
>> @@ -295,6 +295,10 @@ int spi_controller_dma_map_mem_op_data(struct
>> spi_controller *ctlr,
>> void spi_controller_dma_unmap_mem_op_data(struct spi_controller *ctlr,
>>const struct spi_mem_op *op,
>>struct sg_table *sg);
>> +
>> +bool spi_mem_default_supports_op(struct spi_mem *mem,
>> + const struct spi_mem_op *op);
>> +
>> #else
>> static inline int
>> spi_controller_dma_map_mem_op_data(struct spi_controller *ctlr,
>> @@ -310,6 +314,13 @@ spi_controller_dma_unmap_mem_op_data(struct
>> spi_controller *ctlr,
>> struct sg_table *sg)
>> {
>> }
>> +
>> +bool spi_mem_default_supports_op(struct spi_mem *mem,
>> + const struct spi_mem_op *op)
>
> This needs to be declared static inline to avoid multiple definitions.
> Right?
Indeed, thanks!
>
>> +{
>> +return false;
>> +}
>> +
>> #endif /* CONFIG_SPI_MEM */
>>
>> int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op);
>> @@ -341,9 +352,6 @@ int spi_mem_driver_register_with_owner(struct
>> spi_mem_driver *drv,
>>
>> void spi_mem_driver_unregister(struct spi_mem_driver *drv);
>>
>> -bool spi_mem_default_supports_op(struct spi_mem *mem,
>> - const struct spi_mem_op *op);
>> -
>> #define spi_mem_driver_register(__drv) \
>> spi_mem_driver_register_with_owner(__drv, THIS_MODULE)
>>
>>
>
Re: [PULL -- 5.1 REGRESSION] Bluetooth: btusb: request wake pin with NOAUTOEN
Hi Linus,
Thanks for the reply! It's amusing that you're the only one (well,
besides the gentleman who sits a few feet from me and kindly provided
his Reviewed-by) to review my patch.
On Tue, Apr 9, 2019 at 7:20 PM Linus Torvalds
wrote:
> On Tue, Apr 9, 2019 at 8:49 AM Brian Norris wrote:
> > Badly-designed systems might have (for example) active-high wake pins
> > that default to high (e.g., because of external pull ups) until they
> > have an active firmware which starts driving it low. This can cause an
> > interrupt storm in the time between request_irq() and disable_irq().
>
> Why is the fix not to move the request_irq() down to below the proper
> initialization sequence?
>
> That's what drivers *should* do: initialize their hardware first,
> request interrupts only after that. Initializing the interrupt handler
> before the hw is actually up seems wrong..
I suppose that's a possible solution. It appears that would involve
moving this IRQ management into btusb_{open,close}, after
->setup_on_usb(). I don't immediately see a good reason why we
couldn't do that.
But the use of NOAUTOEN is still important, because there's not really
any direct way to ack/clear the underlying signal, even when the
hardware is fully initialized. It's just a level-triggered wakeup
signal, which represents "activity" from the device, and we're relying
on the disable_irq_nosync() / BTUSB_OOB_WAKE_ENABLED dance to keep
things in sync. (I'm not proud of that exactly, but I think it's
otherwise correct.) Currently, this is the only window of time where
we trust that the device remains "quiet". Even if we move this until
after full HW initialization, I think we're still trusting the BT
firmware (a bit too much) not to assert this signal.
So, I think the problem is still potentially present no matter when we
request the IRQ. The "uninitialized" state of the hardware (or,
firmware) just exposes the issue extremely clearly.
If you'd rather send this back to the drawing board, I can just send a
revert for commit 5364a0b4f4be ("arm64: dts: rockchip: move QCA6174A
wakeup pin into its USB node") for 5.1 instead. I don't mean to take
too much of your time; I just want my regression fixed, and nothing
further up the MAINTAINERS file helped so far.
Thanks,
Brian
Re: [PATCH v2 2/2] dt-bindings: cpufreq: Document operating-points-v2-sunxi-cpu
On 09-04-19, 13:25, Yangtao Li wrote: > Allwinner Process Voltage Scaling Tables defines the voltage and > frequency value based on the speedbin blown in the efuse combination. > The sunxi-cpufreq-nvmem driver reads the efuse value from the SoC to > provide the OPP framework with required information. > This is used to determine the voltage and frequency value for each > OPP of operating-points-v2 table when it is parsed by the OPP framework. > > The "operating-points-v2-sunxi-cpu" DT extends the "operating-points-v2" > with following parameters: > - nvmem-cells (NVMEM area containig the speedbin information) > - opp-microvolt-: voltage in micro Volts. > At runtime, the platform can pick a and matching > opp-microvolt- property > > Signed-off-by: Yangtao Li > --- > .../bindings/opp/sunxi-nvmem-cpufreq.txt | 166 ++ > 1 file changed, 166 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt LGTM. -- viresh
Re: [PATCH v2 1/2] cpufreq: Add sunxi nvmem based CPU scaling driver
On 09-04-19, 13:25, Yangtao Li wrote:
> +static const struct sunxi_cpufreq_soc_data sun50i_h6_data = {
> + .efuse_xlate = sun50i_efuse_xlate,
> + .nvmem_mask = 0x7,
> + .nvmem_shift = 5,
> +};
> +
> +static const struct of_device_id sunxi_cpufreq_match_list[] = {
> + { .compatible = "allwinner,sun50i-h6", .data = _h6_data },
> + {}
> +};
> +
> +static const struct of_device_id *sunxi_cpufreq_match_node(void)
> +{
> + struct device_node *np;
> + const struct of_device_id *match;
> +
> + np = of_find_node_by_path("/");
> + match = of_match_node(sunxi_cpufreq_match_list, np);
> + of_node_put(np);
> +
> + return match;
> +}
> +
Above code can be placed just above sunxi_cpufreq_init(), if you ...
> +static int sunxi_cpufreq_nvmem_probe(struct platform_device *pdev)
> +{
> + const struct sunxi_cpufreq_soc_data *soc_data;
> + struct opp_table **opp_tables;
> + const struct of_device_id *match;
> + char name[MAX_NAME_LEN];
> + unsigned int cpu;
> + u32 speed = 0;
> + int ret;
> +
> + opp_tables = kcalloc(num_possible_cpus(), sizeof(*opp_tables),
> + GFP_KERNEL);
> + if (!opp_tables)
> + return -ENOMEM;
> +
> + match = sunxi_cpufreq_match_node();
... avoid this and ...
> + soc_data = match->data;
> + if (!soc_data)
> + return -EINVAL;
> +
> + ret = sunxi_cpufreq_get_efuse(soc_data, );
> + if (ret)
> + return ret;
> +
> + snprintf(name, MAX_NAME_LEN, "speed%d", speed);
> +
> + for_each_possible_cpu(cpu) {
> + struct device *cpu_dev = get_cpu_device(cpu);
> +
> + if (NULL == cpu_dev) {
> + ret = -ENODEV;
> + goto free_opp;
> + }
> +
> + opp_tables[cpu] = dev_pm_opp_set_prop_name(cpu_dev, name);
> + if (IS_ERR(opp_tables[cpu])) {
> + ret = PTR_ERR(opp_tables[cpu]);
> + pr_err("Failed to set prop name\n");
> + goto free_opp;
> + }
> + }
> +
> + cpufreq_dt_pdev = platform_device_register_simple("cpufreq-dt", -1,
> + NULL, 0);
> + if (!IS_ERR(cpufreq_dt_pdev)) {
> + platform_set_drvdata(pdev, opp_tables);
> + return 0;
> + }
> +
> + ret = PTR_ERR(cpufreq_dt_pdev);
> + pr_err("Failed to register platform device\n");
> +
> +free_opp:
> + for_each_possible_cpu(cpu) {
> + if (IS_ERR_OR_NULL(opp_tables[cpu]))
> + break;
> + dev_pm_opp_put_prop_name(opp_tables[cpu]);
> + }
> + kfree(opp_tables);
> +
> + return ret;
> +}
> +
> +static int sunxi_cpufreq_nvmem_remove(struct platform_device *pdev)
> +{
> + struct opp_table **opp_tables = platform_get_drvdata(pdev);
> + unsigned int cpu;
> +
> + platform_device_unregister(cpufreq_dt_pdev);
> +
> + for_each_possible_cpu(cpu)
> + dev_pm_opp_put_prop_name(opp_tables[cpu]);
> +
> + kfree(opp_tables);
> +
> + return 0;
> +}
> +
> +static struct platform_driver sunxi_cpufreq_driver = {
> + .probe = sunxi_cpufreq_nvmem_probe,
> + .remove = sunxi_cpufreq_nvmem_remove,
> + .driver = {
> + .name = "sunxi-cpufreq-nvmem",
> + },
> +};
> +
> +/*
> + * Since the driver depends on nvmem drivers, which may return EPROBE_DEFER,
> + * all the real activity is done in the probe, which may be defered as well.
> + * The init here is only registering the driver and the platform device.
> + */
> +static int __init sunxi_cpufreq_init(void)
> +{
> + const struct of_device_id *match;
> + int ret;
> +
> + match = sunxi_cpufreq_match_node();
> + if (!match)
> + return -ENODEV;
> +
> + ret = platform_driver_register(_cpufreq_driver);
> + if (unlikely(ret < 0))
> + return ret;
> +
> + sunxi_cpufreq_pdev = platform_device_register_simple(
> + "sunxi-cpufreq-nvmem", -1, NULL, 0);
... pass match->data as platform device's data here..
> + ret = PTR_ERR_OR_ZERO(sunxi_cpufreq_pdev);
> + if (0 == ret)
> + return 0;
> +
> + platform_driver_unregister(_cpufreq_driver);
> + return ret;
> +}
> +module_init(sunxi_cpufreq_init);
> +
> +static void __exit sunxi_cpufreq_exit(void)
> +{
> + platform_device_unregister(sunxi_cpufreq_pdev);
> + platform_driver_unregister(_cpufreq_driver);
> +}
> +module_exit(sunxi_cpufreq_exit);
> +
> +MODULE_DESCRIPTION("Sunxi cpufreq driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.17.0
--
viresh
Re: [PATCH 2/2] module: Make srcu_struct ptr array as read-only post init
On Tue, 9 Apr 2019 22:41:03 -0400 Joel Fernandes wrote: > > Other than that, the two patches look fine to me. > > Could I add your Reviewed-by in the respin? You can add an Acked-by, as I haven't spent enough time to offer a Reviewed-by tag. ;-) Maybe I'll get some time to vet it a bit more tomorrow, and then upgrade the ack to a review. Acked-by: Steven Rostedt (VMware) -- Steve
[PATCH 0/1] mm: Remove the SLAB allocator
Recently a 2 year old bug was found in the SLAB allocator that crashes the kernel. This seems to imply that not that many people are using the SLAB allocator. Currently we have 3 slab allocators. Two is company three is a crowd - let's get rid of one. - The SLUB allocator has been the default since 2.6.23 - The SLOB allocator is kinda sexy. Its only 664 LOC, the general design is outlined in KnR, and there is an optimisation taken from Knuth - say no more. If you are using the SLAB allocator please speak now or forever hold your peace ... Testing: Build kernel with `make defconfig` (on x86_64 machine) followed by `make kvmconfig`. Then do the same and manually select SLOB. Boot both kernels in Qemu. thanks, Tobin. Tobin C. Harding (1): mm: Remove SLAB allocator include/linux/slab.h | 26 - kernel/cpu.c |5 - mm/slab.c| 4493 -- mm/slab.h| 31 +- mm/slab_common.c | 20 +- 5 files changed, 5 insertions(+), 4570 deletions(-) delete mode 100644 mm/slab.c -- 2.21.0
[PATCH 1/1] mm: Remove SLAB allocator
We have SLOB for embedded devices and SLUB for everyone else.
Signed-off-by: Tobin C. Harding
---
include/linux/slab.h | 26 -
kernel/cpu.c |5 -
mm/slab.c| 4493 --
mm/slab.h| 31 +-
mm/slab_common.c | 20 +-
5 files changed, 5 insertions(+), 4570 deletions(-)
delete mode 100644 mm/slab.c
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 9449b19c5f10..5b5e40ca2756 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -229,24 +229,6 @@ static inline void __check_heap_object(const void *ptr,
unsigned long n,
* Kmalloc array related definitions
*/
-#ifdef CONFIG_SLAB
-/*
- * The largest kmalloc size supported by the SLAB allocators is
- * 32 megabyte (2^25) or the maximum allocatable page order if that is
- * less than 32 MB.
- *
- * WARNING: Its not easy to increase this value since the allocators have
- * to do various tricks to work around compiler limitations in order to
- * ensure proper constant folding.
- */
-#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT - 1) <= 25 ? \
- (MAX_ORDER + PAGE_SHIFT - 1) : 25)
-#define KMALLOC_SHIFT_MAX KMALLOC_SHIFT_HIGH
-#ifndef KMALLOC_SHIFT_LOW
-#define KMALLOC_SHIFT_LOW 5
-#endif
-#endif
-
#ifdef CONFIG_SLUB
/*
* SLUB directly allocates requests fitting in to an order-1 page
@@ -756,12 +738,4 @@ static inline void *kzalloc_node(size_t size, gfp_t flags,
int node)
unsigned int kmem_cache_size(struct kmem_cache *s);
void __init kmem_cache_init_late(void);
-#if defined(CONFIG_SMP) && defined(CONFIG_SLAB)
-int slab_prepare_cpu(unsigned int cpu);
-int slab_dead_cpu(unsigned int cpu);
-#else
-#define slab_prepare_cpu NULL
-#define slab_dead_cpu NULL
-#endif
-
#endif /* _LINUX_SLAB_H */
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 6754f3ecfd94..223835ae0940 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1378,11 +1378,6 @@ static struct cpuhp_step cpuhp_hp_states[] = {
.startup.single = relay_prepare_cpu,
.teardown.single= NULL,
},
- [CPUHP_SLAB_PREPARE] = {
- .name = "slab:prepare",
- .startup.single = slab_prepare_cpu,
- .teardown.single= slab_dead_cpu,
- },
[CPUHP_RCUTREE_PREP] = {
.name = "RCU/tree:prepare",
.startup.single = rcutree_prepare_cpu,
diff --git a/mm/slab.c b/mm/slab.c
deleted file mode 100644
index 329bfe67f2ca..
--- a/mm/slab.c
+++ /dev/null
@@ -1,4493 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * linux/mm/slab.c
- * Written by Mark Hemment, 1996/97.
- * (mar...@nextd.demon.co.uk)
- *
- * kmem_cache_destroy() + some cleanup - 1999 Andrea Arcangeli
- *
- * Major cleanup, different bufctl logic, per-cpu arrays
- * (c) 2000 Manfred Spraul
- *
- * Cleanup, make the head arrays unconditional, preparation for NUMA
- * (c) 2002 Manfred Spraul
- *
- * An implementation of the Slab Allocator as described in outline in;
- * UNIX Internals: The New Frontiers by Uresh Vahalia
- * Pub: Prentice Hall ISBN 0-13-101908-2
- * or with a little more detail in;
- * The Slab Allocator: An Object-Caching Kernel Memory Allocator
- * Jeff Bonwick (Sun Microsystems).
- * Presented at: USENIX Summer 1994 Technical Conference
- *
- * The memory is organized in caches, one cache for each object type.
- * (e.g. inode_cache, dentry_cache, buffer_head, vm_area_struct)
- * Each cache consists out of many slabs (they are small (usually one
- * page long) and always contiguous), and each slab contains multiple
- * initialized objects.
- *
- * This means, that your constructor is used only for newly allocated
- * slabs and you must pass objects with the same initializations to
- * kmem_cache_free.
- *
- * Each cache can only support one memory type (GFP_DMA, GFP_HIGHMEM,
- * normal). If you need a special memory type, then must create a new
- * cache for that memory type.
- *
- * In order to reduce fragmentation, the slabs are sorted in 3 groups:
- * full slabs with 0 free objects
- * partial slabs
- * empty slabs with no allocated objects
- *
- * If partial slabs exist, then new allocations come from these slabs,
- * otherwise from empty slabs or new slabs are allocated.
- *
- * kmem_cache_destroy() CAN CRASH if you try to allocate from the cache
- * during kmem_cache_destroy(). The caller must prevent concurrent allocs.
- *
- * Each cache has a short per-cpu head array, most allocs
- * and frees go into that array, and if that array overflows, then 1/2
- * of the entries in the array are given back into the global cache.
- * The head array is strictly LIFO and should improve the cache hit rates.
- * On SMP, it additionally reduces the spinlock operations.
- *
- * The c_cpuarray may not be read with enabled local interrupts -
- *
Re: [PATCH 2/2] module: Make srcu_struct ptr array as read-only post init
On Tue, Apr 09, 2019 at 10:38:20PM -0400, Steven Rostedt wrote:
> On Tue, 9 Apr 2019 21:14:18 -0400
> "Joel Fernandes (Google)" wrote:
>
> > /*
> > - * Mark ro_after_init section with SHF_RO_AFTER_INIT so that
> > + * These are section names marked with SHF_RO_AFTER_INIT so that
>
> I'm curious to this much of a change. Wouldn't just making "section"
> plural also work?
>
> "Mark ro_after_init sections with ..."
Yes, I will change it to that and actually this comment change should go in
the previous patch so I'll squash it into that.
> Other than that, the two patches look fine to me.
Could I add your Reviewed-by in the respin?
thanks,
- Joel
> -- Steve
>
> > * layout_sections() can put it in the right place.
> > * Note: ro_after_init sections also have SHF_{WRITE,ALLOC} set.
> > */
> > @@ -3314,6 +3314,13 @@ static char *ro_after_init_sections[] = {
Re: [PATCH 2/2] module: Make srcu_struct ptr array as read-only post init
On Tue, 9 Apr 2019 21:14:18 -0400
"Joel Fernandes (Google)" wrote:
> /*
> - * Mark ro_after_init section with SHF_RO_AFTER_INIT so that
> + * These are section names marked with SHF_RO_AFTER_INIT so that
I'm curious to this much of a change. Wouldn't just making "section"
plural also work?
"Mark ro_after_init sections with ..."
Other than that, the two patches look fine to me.
-- Steve
> * layout_sections() can put it in the right place.
> * Note: ro_after_init sections also have SHF_{WRITE,ALLOC} set.
> */
> @@ -3314,6 +3314,13 @@ static char *ro_after_init_sections[] = {
Re: [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output
On 2019/4/10 10:25, Andy Lutomirski wrote:
> On Tue, Apr 9, 2019 at 7:20 PM Li, Aubrey wrote:
>>
>> On 2019/4/10 9:58, Andy Lutomirski wrote:
>>> On Tue, Apr 9, 2019 at 6:55 PM Aubrey Li wrote:
The architecture specific information of the running processes could
be useful to the userland. Add support to examine process architecture
specific information externally.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
Cc: Linux API
Cc: Alexey Dobriyan
Cc: Andrew Morton
---
fs/proc/array.c | 5 +
include/linux/proc_fs.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 2edbb657f859..331592a61718 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -401,6 +401,10 @@ static inline void task_thp_status(struct seq_file
*m, struct mm_struct *mm)
seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
}
+void __weak arch_proc_pid_status(struct seq_file *m, struct task_struct
*task)
+{
+}
>>>
>>> This pointlessly bloats other architectures. Do this instead in an
>>> appropriate header:
>>>
>>> #ifndef arch_proc_pid_status
>>> static inline void arch_proc_pid_status(...)
>>> {
>>> }
>>> #endif
>>>
>>
>> I saw a bunch of similar weak functions, is it not acceptable?
>>
>> fs/proc$ grep weak *.c
>> cpuinfo.c:__weak void arch_freq_prepare_all(void)
>> meminfo.c:void __attribute__((weak)) arch_report_meminfo(struct seq_file *m)
>> vmcore.c:int __weak elfcorehdr_alloc(unsigned long long *addr, unsigned long
>> long *size)
>> vmcore.c:void __weak elfcorehdr_free(unsigned long long addr)
>> vmcore.c:ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos)
>> vmcore.c:ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64
>> *ppos)
>> vmcore.c:int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
>> vmcore.c:ssize_t __weak
>
> I think they're acceptable, but I don't personally like them.
>
okay, let me try to see if I can refine it in an appropriate way.
>>
>>> Or add /proc/PID/x86_status, which sounds better in most respects to me.
>>>
>>
>> I didn't figure out how to make /proc/PID/x86_status invisible to other
>> architectures in an appropriate way, do you have any suggestions?
>
> #ifdef CONFIG_X86?
>
I'm not sure if everyone like adding an arch #ifdef in a common file,
please allow me to wait a while to see if there are other comments.
Thanks,
-Aubrey
RE: [EXT] Re: [v7 3/3] ahci: qoriq: add lx2160 platforms support
Hi Axboe, Thanks very much. Best Regards, Peng >-Original Message- >From: Jens Axboe >Sent: 2019年4月9日 22:17 >To: Peng Ma ; robh...@kernel.org; >mark.rutl...@arm.com; shawn...@kernel.org; Leo Li >Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; >linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Andy Tang >; Jianchao Wang >Subject: Re: [EXT] Re: [v7 3/3] ahci: qoriq: add lx2160 platforms support > >WARNING: This email was created outside of NXP. DO NOT CLICK links or >attachments unless you recognize the sender and know the content is safe. > > > >On 4/9/19 12:44 AM, Peng Ma wrote: >> Hi Axboe, >> >> Patch link: >> >> >https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwo >rk.ozlabs.org%2Fpatch%2F1055028%2Fdata=02%7C01%7Cpeng.ma%40 >nxp.com%7Ce76be539c24a4733cf3f08d6bcf618de%7C686ea1d3bc2b4c6fa92 >cd99c5c301635%7C0%7C1%7C636904162505501500sdata=Am7QEJ2Y >sqkNLXUtIMXU%2Fs5Mt4QhzYYa1FjbhWaAXiw%3Dreserved=0 >> >> >https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwo >rk.ozlabs.org%2Fpatch%2F1054189%2Fdata=02%7C01%7Cpeng.ma%40 >nxp.com%7Ce76be539c24a4733cf3f08d6bcf618de%7C686ea1d3bc2b4c6fa92 >cd99c5c301635%7C0%7C1%7C636904162505501500sdata=ikpNC4M% >2BDq3%2FPYsXLHbPDcDu2KfgIRXs%2BjDDXWtp2jk%3Dreserved=0 > >Applied, thanks. > >-- >Jens Axboe
Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API
On Wed, Apr 10, 2019 at 1:31 AM Nicolas Dufresne wrote: > > Le mardi 09 avril 2019 à 18:59 +0900, Tomasz Figa a écrit : > > On Thu, Feb 7, 2019 at 4:33 PM Tomasz Figa wrote: > > > On Tue, Feb 5, 2019 at 7:35 PM Hans Verkuil wrote: > > > > On 2/5/19 10:31 AM, Tomasz Figa wrote: > > > > > On Tue, Feb 5, 2019 at 6:00 PM Hans Verkuil > > > > > wrote: > > > > > > On 2/5/19 7:26 AM, Tomasz Figa wrote: > > > > > > > On Fri, Feb 1, 2019 at 12:18 AM Nicolas Dufresne > > > > > > > wrote: > > > > > > > > Le jeudi 31 janvier 2019 à 22:34 +0900, Tomasz Figa a écrit : > > > > > > > > > On Thu, Jan 31, 2019 at 9:42 PM Philipp Zabel > > > > > > > > > wrote: > > > > > > > > > > Hi Nicolas, > > > > > > > > > > > > > > > > > > > > On Wed, 2019-01-30 at 10:32 -0500, Nicolas Dufresne wrote: > > > > > > > > > > > Le mercredi 30 janvier 2019 à 15:17 +0900, Tomasz Figa a > > > > > > > > > > > écrit : > > > > > > > > > > > > > I don't remember saying that, maybe I meant to say > > > > > > > > > > > > > there might be a > > > > > > > > > > > > > workaround ? > > > > > > > > > > > > > > > > > > > > > > > > > > For the fact, here we queue the headers (or first > > > > > > > > > > > > > frame): > > > > > > > > > > > > > > > > > > > > > > > > > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2videodec.c#L624 > > > > > > > > > > > > > > > > > > > > > > > > > > Then few line below this helper does G_FMT internally: > > > > > > > > > > > > > > > > > > > > > > > > > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2videodec.c#L634 > > > > > > > > > > > > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2object.c#L3907 > > > > > > > > > > > > > > > > > > > > > > > > > > And just plainly fails if G_FMT returns an error of > > > > > > > > > > > > > any type. This was > > > > > > > > > > > > > how Kamil designed it initially for MFC driver. There > > > > > > > > > > > > > was no other > > > > > > > > > > > > > alternative back then (no EAGAIN yet either). > > > > > > > > > > > > > > > > > > > > > > > > Hmm, was that ffmpeg then? > > > > > > > > > > > > > > > > > > > > > > > > So would it just set the OUTPUT width and height to 0? > > > > > > > > > > > > Does it mean > > > > > > > > > > > > that gstreamer doesn't work with coda and mtk-vcodec, > > > > > > > > > > > > which don't have > > > > > > > > > > > > such wait in their g_fmt implementations? > > > > > > > > > > > > > > > > > > > > > > I don't know for MTK, I don't have the hardware and > > > > > > > > > > > didn't integrate > > > > > > > > > > > their vendor pixel format. For the CODA, I know it works, > > > > > > > > > > > if there is > > > > > > > > > > > no wait in the G_FMT, then I suppose we are being really > > > > > > > > > > > lucky with the > > > > > > > > > > > timing (it would be that the drivers process the SPS/PPS > > > > > > > > > > > synchronously, > > > > > > > > > > > and a simple lock in the G_FMT call is enough to wait). > > > > > > > > > > > Adding Philipp > > > > > > > > > > > in CC, he could explain how this works, I know they use > > > > > > > > > > > GStreamer in > > > > > > > > > > > production, and he would have fixed GStreamer already if > > > > > > > > > > > that was > > > > > > > > > > > causing important issue. > > > > > > > > > > > > > > > > > > > > CODA predates the width/height=0 rule on the coded/OUTPUT > > > > > > > > > > queue. > > > > > > > > > > It currently behaves more like a traditional mem2mem device. > > > > > > > > > > > > > > > > > > The rule in the latest spec is that if width/height is 0 then > > > > > > > > > CAPTURE > > > > > > > > > format is determined only after the stream is parsed. > > > > > > > > > Otherwise it's > > > > > > > > > instantly deduced from the OUTPUT resolution. > > > > > > > > > > > > > > > > > > > When width/height is set via S_FMT(OUT) or output crop > > > > > > > > > > selection, the > > > > > > > > > > driver will believe it and set the same (rounded up to > > > > > > > > > > macroblock > > > > > > > > > > alignment) on the capture queue without ever having seen > > > > > > > > > > the SPS. > > > > > > > > > > > > > > > > > > That's why I asked whether gstreamer sets width and height of > > > > > > > > > OUTPUT > > > > > > > > > to non-zero values. If so, there is no regression, as the > > > > > > > > > specs mimic > > > > > > > > > the coda behavior. > > > > > > > > > > > > > > > > I see, with Philipp's answer it explains why it works. Note that > > > > > > > > GStreamer sets the display size on the OUTPUT format (in fact > > > > > > > > we pass > > > > > > > > as much information as we have, because a) it's generic code > > > > > > > > and b) it > > > > > > > > will be needed someday when we enable pre-allocation (REQBUFS > > > > > > > > before > > > > > > > > SPS/PPS is passed, to avoid the setup delay introduce by > > > > > > > > allocation, > > > > > > > >
Re: [PATCH v3 0/4] perf: Support a new 'percore' event qualifier
Hi Arnaldo, Can this patch be accepted? Thanks Jin Yao On 3/19/2019 6:20 PM, Jiri Olsa wrote: On Tue, Mar 19, 2019 at 04:56:52PM +0800, Jin Yao wrote: The 'percore' event qualifier which sums up the event counts for both hardware threads in a core. For example, perf stat -e cpu/event=0,umask=0x3,percore=1/,cpu/event=0,umask=0x3/ In this example, we count the event 'ref-cycles' per-core and per-CPU in one perf stat command-line. We can already support per-core counting with --per-core, but it's often useful to do this together with other metrics that are collected per CPU (per hardware thread). So this patch series supports this per-core counting on a event level. v3: --- Simplify the patch: "perf: Add a 'percore' event qualifier" Other patches don't have changes. Acked-by: Jiri Olsa thanks, jirka v2: --- 1. Change 'coresum' to 'percore'. 2. Move the aggregate counts printing to a seperate patch. Jin Yao (4): perf: Add a 'percore' event qualifier perf stat: Factor out aggregate counts printing perf stat: Support 'percore' event qualifier perf test: Add a simple test for term 'percore' tools/perf/Documentation/perf-stat.txt | 4 ++ tools/perf/builtin-stat.c | 21 +++ tools/perf/tests/parse-events.c| 10 ++- tools/perf/util/evsel.c| 2 + tools/perf/util/evsel.h| 3 + tools/perf/util/parse-events.c | 27 + tools/perf/util/parse-events.h | 1 + tools/perf/util/parse-events.l | 1 + tools/perf/util/stat-display.c | 108 - tools/perf/util/stat.c | 8 ++- 10 files changed, 151 insertions(+), 34 deletions(-) -- 2.7.4
Re: [GIT PULL] MIPS fixes
The pull request you sent on Tue, 9 Apr 2019 23:26:36 +: > git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git > tags/mips_fixes_5.1_2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0ee7fb36f988539f52f83ce6048d696bd540066f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [git pull] several fixes
The pull request you sent on Wed, 10 Apr 2019 00:12:03 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/972acfb49446b30a3533ceb5682bf8350c786bc8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH 4/4] locking/lockdep: Test all incompatible scenario at once in check_irq_usage()
On Tue, Apr 09, 2019 at 03:03:52PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 02, 2019 at 06:02:44PM +0200, Frederic Weisbecker wrote:
> > @@ -1988,45 +1961,151 @@ static int exclusive_bit(int new_bit)
> > return state | (dir ^ LOCK_USAGE_DIR_MASK);
> > }
> >
> > +static unsigned long exclusive_dir_mask(unsigned long mask)
>
> Would you mind terribly if I call that: invert_dir_mask() ?
That's indeed much better.
>
> > +{
> > + unsigned long excl;
> > +
> > + /* Invert dir */
> > + excl = (mask & LOCKF_ENABLED_IRQ_ALL) >> LOCK_USAGE_DIR_MASK;
> > + excl |= (mask & LOCKF_USED_IN_IRQ_ALL) << LOCK_USAGE_DIR_MASK;
> > +
> > + return excl;
> > +}
> > +
> > +static unsigned long exclusive_mask(unsigned long mask)
> > +{
> > + unsigned long excl = exclusive_dir_mask(mask);
> > +
> > + /* Strip read */
> > + excl |= (excl & LOCKF_IRQ_READ) >> LOCK_USAGE_READ_MASK;
> > + excl &= ~LOCKF_IRQ_READ;
> > +
> > + return excl;
> > +}
>
> And I might write a comment to go with those functions; they're too
> clever by half. I'm sure I'll have forgotten how they work in a few
> months time.
It only takes a night for me to forget how my code works. Then I need
a whole day long to recollect. But once I'm done the next night starts.
So I'm not against comments, thanks :-)
> > +/*
> > + * Find the first pair of bit match between an original
> > + * usage mask and an exclusive usage mask.
> > + */
> > +static int find_exclusive_match(unsigned long mask,
> > + unsigned long excl_mask,
> > + enum lock_usage_bit *bit,
> > + enum lock_usage_bit *excl_bit)
> > +{
> > + int fs, nr = 0;
> > +
> > + while ((fs = ffs(mask))) {
> > + int excl;
> > +
> > + nr += fs;
> > + excl = exclusive_bit(nr - 1);
> > + if (excl_mask & lock_flag(excl)) {
> > + *bit = nr - 1;
> > + *excl_bit = excl;
> > + return 0;
> > + }
> > + mask >>= fs - 1;
> > + /*
> > +* Prevent from shifts of sizeof(long) which can
> > +* give unpredictable results.
> > +*/
> > + mask >>= 1;
> > + }
> > + return -1;
>
> Should we write that like:
>
> for_each_set_bit(bit, , LOCK_USED) {
> int excl = exclusive_bit(bit);
> if (excl_mask & lock_flag(excl)) {
> *bitp = bit;
> *excl_bitp = excl;
> return 0;
> }
> }
> return -1;
>
> Or something along those lines?
Ah yes indeed. Linus didn't like the idea of using bitmap functions for lockdep
usage bits in the softirq vector patchset but here the case is different as it's
not used in lockdep fastpath. That's only for the bad locking scenario path so
it's
all good I think.
Should I re-issue the set or you do the changes?
Thanks.
Re: [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output
On Tue, Apr 9, 2019 at 7:20 PM Li, Aubrey wrote:
>
> On 2019/4/10 9:58, Andy Lutomirski wrote:
> > On Tue, Apr 9, 2019 at 6:55 PM Aubrey Li wrote:
> >>
> >> The architecture specific information of the running processes could
> >> be useful to the userland. Add support to examine process architecture
> >> specific information externally.
> >>
> >> Signed-off-by: Aubrey Li
> >> Cc: Peter Zijlstra
> >> Cc: Andi Kleen
> >> Cc: Tim Chen
> >> Cc: Dave Hansen
> >> Cc: Arjan van de Ven
> >> Cc: Linux API
> >> Cc: Alexey Dobriyan
> >> Cc: Andrew Morton
> >> ---
> >> fs/proc/array.c | 5 +
> >> include/linux/proc_fs.h | 2 ++
> >> 2 files changed, 7 insertions(+)
> >>
> >> diff --git a/fs/proc/array.c b/fs/proc/array.c
> >> index 2edbb657f859..331592a61718 100644
> >> --- a/fs/proc/array.c
> >> +++ b/fs/proc/array.c
> >> @@ -401,6 +401,10 @@ static inline void task_thp_status(struct seq_file
> >> *m, struct mm_struct *mm)
> >> seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
> >> }
> >>
> >> +void __weak arch_proc_pid_status(struct seq_file *m, struct task_struct
> >> *task)
> >> +{
> >> +}
> >
> > This pointlessly bloats other architectures. Do this instead in an
> > appropriate header:
> >
> > #ifndef arch_proc_pid_status
> > static inline void arch_proc_pid_status(...)
> > {
> > }
> > #endif
> >
>
> I saw a bunch of similar weak functions, is it not acceptable?
>
> fs/proc$ grep weak *.c
> cpuinfo.c:__weak void arch_freq_prepare_all(void)
> meminfo.c:void __attribute__((weak)) arch_report_meminfo(struct seq_file *m)
> vmcore.c:int __weak elfcorehdr_alloc(unsigned long long *addr, unsigned long
> long *size)
> vmcore.c:void __weak elfcorehdr_free(unsigned long long addr)
> vmcore.c:ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos)
> vmcore.c:ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64
> *ppos)
> vmcore.c:int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
> vmcore.c:ssize_t __weak
I think they're acceptable, but I don't personally like them.
>
> > Or add /proc/PID/x86_status, which sounds better in most respects to me.
> >
>
> I didn't figure out how to make /proc/PID/x86_status invisible to other
> architectures in an appropriate way, do you have any suggestions?
#ifdef CONFIG_X86?
Re: [PULL -- 5.1 REGRESSION] Bluetooth: btusb: request wake pin with NOAUTOEN
On Tue, Apr 9, 2019 at 8:49 AM Brian Norris wrote: > > Badly-designed systems might have (for example) active-high wake pins > that default to high (e.g., because of external pull ups) until they > have an active firmware which starts driving it low. This can cause an > interrupt storm in the time between request_irq() and disable_irq(). Why is the fix not to move the request_irq() down to below the proper initialization sequence? That's what drivers *should* do: initialize their hardware first, request interrupts only after that. Initializing the interrupt handler before the hw is actually up seems wrong.. Linus
Re: [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output
On 2019/4/10 9:58, Andy Lutomirski wrote:
> On Tue, Apr 9, 2019 at 6:55 PM Aubrey Li wrote:
>>
>> The architecture specific information of the running processes could
>> be useful to the userland. Add support to examine process architecture
>> specific information externally.
>>
>> Signed-off-by: Aubrey Li
>> Cc: Peter Zijlstra
>> Cc: Andi Kleen
>> Cc: Tim Chen
>> Cc: Dave Hansen
>> Cc: Arjan van de Ven
>> Cc: Linux API
>> Cc: Alexey Dobriyan
>> Cc: Andrew Morton
>> ---
>> fs/proc/array.c | 5 +
>> include/linux/proc_fs.h | 2 ++
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/fs/proc/array.c b/fs/proc/array.c
>> index 2edbb657f859..331592a61718 100644
>> --- a/fs/proc/array.c
>> +++ b/fs/proc/array.c
>> @@ -401,6 +401,10 @@ static inline void task_thp_status(struct seq_file *m,
>> struct mm_struct *mm)
>> seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
>> }
>>
>> +void __weak arch_proc_pid_status(struct seq_file *m, struct task_struct
>> *task)
>> +{
>> +}
>
> This pointlessly bloats other architectures. Do this instead in an
> appropriate header:
>
> #ifndef arch_proc_pid_status
> static inline void arch_proc_pid_status(...)
> {
> }
> #endif
>
I saw a bunch of similar weak functions, is it not acceptable?
fs/proc$ grep weak *.c
cpuinfo.c:__weak void arch_freq_prepare_all(void)
meminfo.c:void __attribute__((weak)) arch_report_meminfo(struct seq_file *m)
vmcore.c:int __weak elfcorehdr_alloc(unsigned long long *addr, unsigned long
long *size)
vmcore.c:void __weak elfcorehdr_free(unsigned long long addr)
vmcore.c:ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos)
vmcore.c:ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64
*ppos)
vmcore.c:int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
vmcore.c:ssize_t __weak
> Or add /proc/PID/x86_status, which sounds better in most respects to me.
>
I didn't figure out how to make /proc/PID/x86_status invisible to other
architectures in an appropriate way, do you have any suggestions?
Thanks,
-Aubrey
Re: [PATCH 1/2] printk: Add an option to flush all messages on panic
Hi Petr and Sergey, On Wed, Apr 10, 2019 at 10:47:05AM +0900, Sergey Senozhatsky wrote: > On (04/09/19 15:41), Petr Mladek wrote: > > I suggest to merge the two patches into one. It will > > still be rather small and easier to review. > > Agreed, was going to suggest the same. Ok, will merge. Splitting to 2 patches did confuse people. Thanks, Feng
[PATCH -next v2] acpi/hmat: fix memory leaks in hmat_init()
The commit 665ac7e92757 ("acpi/hmat: Register processor domain to its
memory") introduced some memory leaks below due to it fails to release
the heap memory in an error path, and then those statically-allocated
__initdata memory which reference them get freed during boot renders
those heap memory as leaks. Since it is valid to pass NULL to
acpi_put_table(), it is fine to call it even if acpi_get_table() returns
an error.
unreferenced object 0xc8ff8008349e9400 (size 128):
comm "swapper/0", pid 1, jiffies 4294709236 (age 48121.476s)
hex dump (first 32 bytes):
00 d0 9e 34 08 80 ff 84 d8 00 43 11 00 10 ff ff ...4..C.
00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00
backtrace:
[<869d4503>] __kmalloc+0x568/0x600
[<70fd6afb>] alloc_memory_target+0x50/0xd8
[] srat_parse_mem_affinity+0x58/0x5c
[<8bfaef74>] acpi_parse_entries_array+0x1c8/0x2c0
[<22804877>] acpi_table_parse_entries_array+0x11c/0x138
[] acpi_table_parse_entries+0x7c/0xac
[] hmat_init+0x90/0x174
[<694a86c1>] do_one_initcall+0x2d8/0x5f8
[<24889da9>] do_initcall_level+0x37c/0x3fc
[<9be02908>] do_basic_setup+0x38/0x50
[<37b3ac0a>] kernel_init_freeable+0x194/0x258
[] kernel_init+0x18/0x334
[<7b30f423>] ret_from_fork+0x10/0x18
[<6c7147a8>] 0x
Signed-off-by: Qian Cai
---
v2: goto out_put per Rafael.
drivers/acpi/hmat/hmat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/hmat/hmat.c b/drivers/acpi/hmat/hmat.c
index b7824a0309f7..69cdb3cea545 100644
--- a/drivers/acpi/hmat/hmat.c
+++ b/drivers/acpi/hmat/hmat.c
@@ -637,7 +637,7 @@ static __init int hmat_init(void)
status = acpi_get_table(ACPI_SIG_HMAT, 0, );
if (ACPI_FAILURE(status))
- return 0;
+ goto out_put;
hmat_revision = tbl->revision;
switch (hmat_revision) {
--
2.17.2 (Apple Git-113)
RE: [EXT] Re: [PATCH V11 5/5] ARM: dts: imx7ulp-evk: Add backlight support
Hi, Fabio Best Regards! Anson Huang > -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: 2019年4月10日 10:03 > To: Anson Huang > Cc: thierry.red...@gmail.com; robh...@kernel.org; mark.rutl...@arm.com; > shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de; > li...@armlinux.org.uk; ste...@agner.ch; ota...@ossystems.com.br; > Leonard Crestez ; Robin Gong > ; u.kleine-koe...@pengutronix.de; linux- > p...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; dl-linux-imx > > Subject: [EXT] Re: [PATCH V11 5/5] ARM: dts: imx7ulp-evk: Add backlight > support > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > On Tue, Apr 9, 2019 at 10:47 PM Anson Huang > wrote: > > > #include "imx7ulp.dtsi" > > +#include > > This inclusion is not needed here as PWM_POLARITY_INVERTED is not used > in this dts. Thanks for reminder, I will remove it later. Anson.
Re: [PATCH V11 5/5] ARM: dts: imx7ulp-evk: Add backlight support
On Tue, Apr 9, 2019 at 10:47 PM Anson Huang wrote: > #include "imx7ulp.dtsi" > +#include This inclusion is not needed here as PWM_POLARITY_INVERTED is not used in this dts.
Re: [PATCH 11/17] fpga: dfl: afu: add error reporting support.
On Tue, Apr 09, 2019 at 03:57:37PM -0500, Alan Tull wrote:
> On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote:
>
> Hi Hao,
>
> >
> > Error reporting is one important private feature, it reports error
> > detected on port and accelerated function unit (AFU). It introduces
> > several sysfs interfaces to allow userspace to check and clear
> > errors detected by hardware.
> >
> > Signed-off-by: Xu Yilun
> > Signed-off-by: Wu Hao
> > ---
> > Documentation/ABI/testing/sysfs-platform-dfl-port | 29 +++
> > drivers/fpga/Makefile | 1 +
> > drivers/fpga/dfl-afu-error.c | 225
> > ++
> > drivers/fpga/dfl-afu-main.c | 4 +
> > drivers/fpga/dfl-afu.h| 4 +
> > 5 files changed, 263 insertions(+)
> > create mode 100644 drivers/fpga/dfl-afu-error.c
> >
> > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-port
> > b/Documentation/ABI/testing/sysfs-platform-dfl-port
> > index f611e47..e6140aa 100644
> > --- a/Documentation/ABI/testing/sysfs-platform-dfl-port
> > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-port
> > @@ -79,3 +79,32 @@ KernelVersion: 5.2
> > Contact: Wu Hao
> > Description: Read-only. Read this file to get the status of issued
> > command
> > to userclck_freqcntrcmd.
> > +
> > +What: /sys/bus/platform/devices/dfl-port.0/errors/errors
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Read-only. Read this file to get errors detected on port and
> > + Accelerated Function Unit (AFU).
> > +
> > +What: /sys/bus/platform/devices/dfl-port.0/errors/first_error
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Read-only. Read this file to get the first error detected by
> > + hardware.
> > +
> > +What:
> > /sys/bus/platform/devices/dfl-port.0/errors/first_malformed_req
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Read-only. Read this file to get the first malformed request
> > + captured by hardware.
> > +
> > +What: /sys/bus/platform/devices/dfl-port.0/errors/clear
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Write-only. Write error code to this file to clear errors.
> > If
> > + the input error code doesn't match, it returns -EBUSY error
> > + code.
>
> I understand how -EBUSY could be the right error code for when the
> hardware is in a state where the error can't be cleared. But if the
> input error code doesn't match, shouldn't the code be -EINVAL? Also
> as noted below, the way this is currently coded, -ETIMEDOUT could get
> returned.
Thanks for the comments, let me try to capture all possible error return
values in doc in the next version to avoid confusion.
>
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index c0dd4c8..f1f0af7 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -40,6 +40,7 @@ obj-$(CONFIG_FPGA_DFL_AFU)+= dfl-afu.o
> >
> > dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o
> > dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o dfl-afu-dma-region.o
> > +dfl-afu-objs += dfl-afu-error.o
> >
> > # Drivers for FPGAs which implement DFL
> > obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
> > diff --git a/drivers/fpga/dfl-afu-error.c b/drivers/fpga/dfl-afu-error.c
> > new file mode 100644
> > index 000..b66bd4a
> > --- /dev/null
> > +++ b/drivers/fpga/dfl-afu-error.c
> > @@ -0,0 +1,225 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Driver for FPGA Accelerated Function Unit (AFU) Error Reporting
> > + *
> > + * Copyright 2019 Intel Corporation, Inc.
> > + *
> > + * Authors:
> > + * Wu Hao
> > + * Xiao Guangrong
> > + * Joseph Grecco
> > + * Enno Luebbers
> > + * Tim Whisonant
> > + * Ananda Ravuri
> > + * Mitchel Henry
> > + */
> > +
> > +#include
> > +
> > +#include "dfl-afu.h"
> > +
> > +#define PORT_ERROR_MASK0x8
> > +#define PORT_ERROR 0x10
> > +#define PORT_FIRST_ERROR 0x18
> > +#define PORT_MALFORMED_REQ00x20
> > +#define PORT_MALFORMED_REQ10x28
> > +
> > +#define ERROR_MASK GENMASK_ULL(63, 0)
> > +
> > +/* mask or unmask port errors by the error mask register. */
> > +static void __port_err_mask(struct device *dev, bool mask)
> > +{
> > + void __iomem *base;
> > +
> > + base = dfl_get_feature_ioaddr_by_id(dev, PORT_FEATURE_ID_ERROR);
> > +
> > + writeq(mask ? ERROR_MASK : 0, base + PORT_ERROR_MASK);
> > +}
> > +
> > +/* clear port errors. */
> > +static int __port_err_clear(struct device *dev, u64 err)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > + void __iomem *base_err,
Re: [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output
On Tue, Apr 9, 2019 at 6:55 PM Aubrey Li wrote:
>
> The architecture specific information of the running processes could
> be useful to the userland. Add support to examine process architecture
> specific information externally.
>
> Signed-off-by: Aubrey Li
> Cc: Peter Zijlstra
> Cc: Andi Kleen
> Cc: Tim Chen
> Cc: Dave Hansen
> Cc: Arjan van de Ven
> Cc: Linux API
> Cc: Alexey Dobriyan
> Cc: Andrew Morton
> ---
> fs/proc/array.c | 5 +
> include/linux/proc_fs.h | 2 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index 2edbb657f859..331592a61718 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -401,6 +401,10 @@ static inline void task_thp_status(struct seq_file *m,
> struct mm_struct *mm)
> seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
> }
>
> +void __weak arch_proc_pid_status(struct seq_file *m, struct task_struct
> *task)
> +{
> +}
This pointlessly bloats other architectures. Do this instead in an
appropriate header:
#ifndef arch_proc_pid_status
static inline void arch_proc_pid_status(...)
{
}
#endif
Or add /proc/PID/x86_status, which sounds better in most respects to me.
Re: [PATCH 2/2] panic: Enable to print out all printk msg in buffer
On (04/09/19 16:14), Petr Mladek wrote:
> We should:
>
>+ Flush the latest messages before we replay the log.
Do you mean the pending messages? When we replay the log we also should
print "header line" and panic-cpu backtrace. So we will print panic-cpu
oops twice
// from panic-cpu flush_on_panic
[header]
backtrace
[end of header]
// from console_replay
then all logbuf messages
and then the same header/backtrace one more time
[header]
backtrace]
[end of backtrace]
Is there any particular reason to flush pending messages before
we play the buffer? Replaying the logbuf can take some time, so
my guess would be that you want to print panic-cpu backtrace as
soon as possible. Is there something else?
[..]
> Then I would update cosole_unlock() with something like:
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 02ca827b8fac..14ef4e2431e7 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2386,21 +2386,32 @@ void console_unlock(void)
>
> for (;;) {
> struct printk_log *msg;
> + int reset_idx = 0;
> size_t ext_len = 0;
> - size_t len;
> + size_t len = 0;
>
> printk_safe_enter_irqsave(flags);
> raw_spin_lock(_lock);
> +
> if (console_seq < log_first_seq) {
> len = sprintf(text,
> "** %llu printk messages dropped **\n",
> log_first_seq - console_seq);
>
> /* messages are gone, move to first one */
> + reset_idx = 1;
> + }
> +
> + if (console_replay) {
> + len += sprintf(text + len,
> +"Replaying the entire log:\n");
> + reset_idx = 1;
> + console_replay = 0;
> + }
> +
> + if (reset_idx) {
> console_seq = log_first_seq;
> console_idx = log_first_idx;
> - } else {
> - len = 0;
> }
The printing loop becomes a bit complex with one more state, I should
say; but can do. We handle exclusive consoles there, dropped messages,
panic reset. But I see what you are trying to do.
-ss
Re: rseq/x86: choosing rseq code signature
On Tue, Apr 9, 2019 at 5:51 PM Zack Weinberg wrote: > > On Tue, Apr 9, 2019 at 4:43 PM Mathieu Desnoyers > wrote: > > - On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers > > mathieu.desnoy...@efficios.com wrote: > > > > > > We are about to include the code signature required prior to restartable > > > sequences abort handlers into glibc, which will make this ABI choice > > > final. > > > We need architecture maintainer input on that signature value. > > > > > > That code signature is placed before each abort handler, so the kernel can > > > validate that it is indeed jumping to an abort handler (and not some > > > arbitrary attacker-chosen code). The signature is never executed. > > > > > > Currently, tools/testing/selftests/rseq/rseq-x86.h defines RSEQ_SIG > > > as 0x53053053, and uses it as an immediate operand to the following > > > instruction opcodes (as suggested by Andy Lutomirski): > > > > > > x86-32: > > > - .byte 0x0f, 0x1f, 0x05: nopl > > > > > > x86-64: > > > - .byte 0x0f, 0x1f, 0x05: nopl (%rip) > > > > > > The current discussion thread on the glibc mailing list leads us towards > > > using a trap with uncommon immediate operand, which simplifies integration > > > with disassemblers, emulators, makes it easier to debug if the control > > > flow gets redirected there by mistake, and is nicer for some > > > architecture's > > > speculative execution. > ... > > Peter Zijlstra suggested to use "invlpg" in user-space, which should > > generate > > a trap. The only concern would be emulators, but ideally they would not try > > to > > decode an instruction that is never executed. This would lead to the > > following > > patch. Any objections/ack ? > ... > > +/* > > + * RSEQ_SIG is used with the following privileged instructions, which trap > > in user-space: > > + * x86-32:0f 01 3d 53 30 05 53 invlpg 0x53053053 > > + * x86-64:0f 01 3d 53 30 05 53 invlpg 0x53053053(%rip) > > + */ > > #define RSEQ_SIG 0x53053053 > > On x86, you have to worry about what happens if control flow gets > redirected to an arbitrary byte address. The proposed sequence `0f 01 > 3d 53 30 05 53` is a trap instruction if control lands seven bytes > before the beginning of the abort handler, but if it lands anywhere > _else_ within the marker sequence, you get one of these instruction > sequences, none of which trap, all but one of which will corrupt the > process state, and three of which will consume three bytes from the > beginning of the abort handler's code, continuing execution with a > misaligned PC: > > 01 3d 53 30 05 53add %edi,0x53053053(%rip) > 3d 53 30 05 53 cmp $0x53053053,%eax > 53 30 05 53 XX XX XX push %rbx; xor %al,0xXX78(%rip) > 30 05 53 XX XX XXxor %al,0xXX78(%rip) > 05 53 XX XX XX add $0xXX53,%eax > 53 push %rbx > > So I'm going to suggest instead the four-byte sequence CD CF CD CF. > That's INT $0xCF if control lands either two or four bytes before the > beginning of the abort handler, and IRET if it lands one or three > bytes before. I believe both of these possibilities are currently > also forbidden in user mode. It doesn't need to be longer, does it? > IRET works in user mode just fine. Why are you concerned about landing in the middle of the signature? A misaligned jump into code is screwy pretty much no matter what. It does seem genuinely useful to trap if you accidentally fall through to the beginning of the signature, but I don't see the point of worrying about jumping to the middle. There's some argument that, for consistency with CET, the last couple bytes of the signature should match ENDBR. Mathieu, how many bytes do we have for the signature?
[PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output
The architecture specific information of the running processes could
be useful to the userland. Add support to examine process architecture
specific information externally.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
Cc: Linux API
Cc: Alexey Dobriyan
Cc: Andrew Morton
---
fs/proc/array.c | 5 +
include/linux/proc_fs.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 2edbb657f859..331592a61718 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -401,6 +401,10 @@ static inline void task_thp_status(struct seq_file *m,
struct mm_struct *mm)
seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
}
+void __weak arch_proc_pid_status(struct seq_file *m, struct task_struct *task)
+{
+}
+
int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task)
{
@@ -424,6 +428,7 @@ int proc_pid_status(struct seq_file *m, struct
pid_namespace *ns,
task_cpus_allowed(m, task);
cpuset_task_status_allowed(m, task);
task_context_switch_counts(m, task);
+ arch_proc_pid_status(m, task);
return 0;
}
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index 52a283ba0465..bf4328cb58ed 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -74,6 +74,8 @@ struct proc_dir_entry *proc_create_net_single_write(const
char *name, umode_t mo
proc_write_t write,
void *data);
extern struct pid *tgid_pidfd_to_pid(const struct file *file);
+/* Add support for architecture specific output in /proc/pid/status */
+void arch_proc_pid_status(struct seq_file *m, struct task_struct *task);
#else /* CONFIG_PROC_FS */
--
2.21.0
[PATCH v14 3/3] Documentation/filesystems/proc.txt: add AVX512_elapsed_ms
Added AVX512_elapsed_ms in /proc//status. Report it in Documentation/filesystems/proc.txt Signed-off-by: Aubrey Li Cc: Peter Zijlstra Cc: Andi Kleen Cc: Tim Chen Cc: Dave Hansen Cc: Arjan van de Ven Cc: Linux API Cc: Alexey Dobriyan Cc: Andrew Morton --- Documentation/filesystems/proc.txt | 29 - 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 66cad5c86171..c4a9e48681ad 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -207,6 +207,7 @@ read the file /proc/PID/status: Speculation_Store_Bypass: thread vulnerable voluntary_ctxt_switches:0 nonvoluntary_ctxt_switches: 1 + AVX512_elapsed_ms: 8 This shows you nearly the same information you would get if you viewed it with the ps command. In fact, ps uses the proc file system to obtain its @@ -224,7 +225,7 @@ asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc//smaps file and scan page table. It's slow but very precise. -Table 1-2: Contents of the status files (as of 4.19) +Table 1-2: Contents of the status files (as of 5.1) .. Field Content Namefilename of the executable @@ -289,6 +290,32 @@ Table 1-2: Contents of the status files (as of 4.19) Mems_allowed_list Same as previous, but in "list format" voluntary_ctxt_switches number of voluntary context switches nonvoluntary_ctxt_switches number of non voluntary context switches + AVX512_elapsed_ms time elapsed since last AVX512 usage recorded + + AVX512_elapsed_ms: + -- + If AVX512 is supported on the machine, this entry shows the milliseconds + elapsed since the last time AVX512 usage was recorded. The recording + happens on a best effort basis when a task is scheduled out. This means + that the value depends on two factors: + +1) The time which the task spent on the CPU without being scheduled + out. With CPU isolation and a single runnable task this can take + several seconds. + +2) The time since the task was scheduled out last. Depending on the + reason for being scheduled out (time slice exhausted, syscall ...) + this can be arbitrary long time. + + As a consequence the value cannot be considered precise and authoritative + information. The application which uses this information has to be aware + of the overall scenario on the system in order to determine whether a + task is a real AVX512 user or not. + + A special value of '-1' indicates that no AVX512 usage was recorded, thus + the task is unlikely an AVX512 user, but depends on the workload and the + scheduling scenario, it also could be a false negative mentioned above. + .. Table 1-3: Contents of the statm files (as of 2.6.8-rc3) -- 2.21.0
[PATCH v14 2/3] x86,/proc/pid/status: Add AVX-512 usage elapsed time
AVX-512 components use could cause core turbo frequency drop. So
it's useful to expose AVX-512 usage elapsed time as a heuristic hint
for the user space job scheduler to cluster the AVX-512 using tasks
together.
Tensorflow example:
$ while [ 1 ]; do cat /proc/tid/status | grep AVX; sleep 1; done
AVX512_elapsed_ms: 4
AVX512_elapsed_ms: 8
AVX512_elapsed_ms: 4
This means that 4 milliseconds have elapsed since the AVX512 usage
of tensorflow task was detected when the task was scheduled out.
Or:
$ cat /proc/tid/status | grep AVX512_elapsed_ms
AVX512_elapsed_ms: -1
The number '-1' indicates that no AVX512 usage recorded before
thus the task unlikely has frequency drop issue.
User space tools may want to further check by:
$ perf stat --pid -e core_power.lvl2_turbo_license -- sleep 1
Performance counter stats for process id '3558':
3,251,565,961 core_power.lvl2_turbo_license
1.004031387 seconds time elapsed
Non-zero counter value confirms that the task causes frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
Cc: Linux API
Cc: Alexey Dobriyan
Cc: Andrew Morton
---
arch/x86/kernel/fpu/xstate.c | 42
1 file changed, 42 insertions(+)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index d7432c2b1051..5e55ed9584ab 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -7,6 +7,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -1243,3 +1245,43 @@ int copy_user_to_xstate(struct xregs_state *xsave, const
void __user *ubuf)
return 0;
}
+
+/*
+ * Report the amount of time elapsed in millisecond since last AVX512
+ * use in the task.
+ */
+static void avx512_status(struct seq_file *m, struct task_struct *task)
+{
+ unsigned long timestamp = READ_ONCE(task->thread.fpu.avx512_timestamp);
+ long delta;
+
+ if (!timestamp) {
+ /*
+* Report -1 if no AVX512 usage
+*/
+ delta = -1;
+ } else {
+ delta = (long)(jiffies - timestamp);
+ /*
+* Cap to LONG_MAX if time difference > LONG_MAX
+*/
+ if (delta < 0)
+ delta = LONG_MAX;
+ delta = jiffies_to_msecs(delta);
+ }
+
+ seq_put_decimal_ll(m, "AVX512_elapsed_ms:\t", delta);
+ seq_putc(m, '\n');
+}
+
+/*
+ * Report architecture specific information
+ */
+void arch_proc_pid_status(struct seq_file *m, struct task_struct *task)
+{
+ /*
+* Report AVX512 state if the processor and build option supported.
+*/
+ if (cpu_feature_enabled(X86_FEATURE_AVX512F))
+ avx512_status(m, task);
+}
--
2.21.0
Re: [PATCH 16/17] fpga: dfl: fme: add global error reporting support
On Tue, Apr 09, 2019 at 04:35:25PM -0500, Alan Tull wrote: > On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote: > > Hi Hao, > > > > > This patch adds support for global error reporting for FPGA > > Management Engine (FME), it introduces sysfs interfaces to > > report different error detected by the hardware, and allow > > user to clear errors or inject error for testing purpose. > > > > Signed-off-by: Luwei Kang > > Signed-off-by: Ananda Ravuri > > Signed-off-by: Xu Yilun > > Signed-off-by: Wu Hao > > --- > > Documentation/ABI/testing/sysfs-platform-dfl-fme | 58 > > drivers/fpga/Makefile| 2 +- > > drivers/fpga/dfl-fme-error.c | 390 > > +++ > > drivers/fpga/dfl-fme-main.c | 4 + > > drivers/fpga/dfl-fme.h | 2 + > > drivers/fpga/dfl.h | 2 + > > 6 files changed, 457 insertions(+), 1 deletion(-) > > create mode 100644 drivers/fpga/dfl-fme-error.c > > > > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme > > b/Documentation/ABI/testing/sysfs-platform-dfl-fme > > index 4b6448f..38f9cdd 100644 > > --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme > > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme > > @@ -156,3 +156,61 @@ KernelVersion: 5.2 > > Contact: Wu Hao > > Description: Read-only. Read this file to get power limit for fpga, it > > is only valid for integrated solution. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/errors > > +Date: March 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-only. Read this file to get errors detected by > > hardware. > > + > > +What: > > /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/first_error > > +Date: March 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-only. Read this file to get the first error detected by > > + hardware. > > + > > +What: > > /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/next_error > > +Date: March 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-only. Read this file to get the second error detected > > by > > + hardware. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/errors/fme-errors/clear > > +Date: March 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Write-only. Write error code to this file to clear errors. > > If > > + the input error code doesn't match, it returns -EBUSY. > > As with the afu errors patch, seems like -EINVAL would be better. > > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/errors/pcie0_errors > > +Date: March 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-only. It returns errors detected on pcie0 link. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/errors/pcie1_errors > > +Date: March 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-only. It returns errors detected on pcie1 link. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/errors/nonfatal_errors > > +Date: March 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-only. It returns non-fatal errors detected. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/errors/catfatal_errors > > +Date: March 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-only. It returns catastrophic and fatal errors > > detected. > > + > > +What: /sys/bus/platform/devices/dfl-fme.0/errors/inject_error > > +Date: March 2019 > > +KernelVersion: 5.2 > > +Contact: Wu Hao > > +Description: Read-Write. Write this file to inject errors for testing > > + purpose. Read this file to check errors injected. > > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile > > index f1f0af7..1a9fa3d 100644 > > --- a/drivers/fpga/Makefile > > +++ b/drivers/fpga/Makefile > > @@ -38,7 +38,7 @@ obj-$(CONFIG_FPGA_DFL_FME_BRIDGE) += dfl-fme-br.o > > obj-$(CONFIG_FPGA_DFL_FME_REGION) += dfl-fme-region.o > > obj-$(CONFIG_FPGA_DFL_AFU) += dfl-afu.o > > > > -dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o > > +dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o dfl-fme-error.o > > dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o dfl-afu-dma-region.o > > dfl-afu-objs += dfl-afu-error.o > > > > diff --git a/drivers/fpga/dfl-fme-error.c b/drivers/fpga/dfl-fme-error.c > > new file mode 100644 > > index 000..f2bd5f8 > > --- /dev/null > > +++ b/drivers/fpga/dfl-fme-error.c > > @@ -0,0 +1,390 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Driver for FPGA Management Engine Error Management > > + * > > + * Copyright 2019 Intel
[PATCH V11 5/5] ARM: dts: imx7ulp-evk: Add backlight support
This patch adds i.MX7ULP EVK board MIPI-DSI backlight support.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm/boot/dts/imx7ulp-evk.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp-evk.dts
b/arch/arm/boot/dts/imx7ulp-evk.dts
index a09026a..94891c7 100644
--- a/arch/arm/boot/dts/imx7ulp-evk.dts
+++ b/arch/arm/boot/dts/imx7ulp-evk.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "imx7ulp.dtsi"
+#include
/ {
model = "NXP i.MX7ULP EVK";
@@ -22,6 +23,14 @@
reg = <0x6000 0x4000>;
};
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = < 1 5 0>;
+ brightness-levels = <0 20 25 30 35 40 100>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+
reg_vsd_3v3: regulator-vsd-3v3 {
compatible = "regulator-fixed";
regulator-name = "VSD_3V3";
@@ -40,6 +49,12 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwm0>;
+ status = "okay";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_usdhc0>;
@@ -57,6 +72,12 @@
bias-pull-up;
};
+ pinctrl_pwm0: pwm0grp {
+ fsl,pins = <
+ IMX7ULP_PAD_PTF2__TPM4_CH1 0x2
+ >;
+ };
+
pinctrl_usdhc0: usdhc0grp {
fsl,pins = <
IMX7ULP_PAD_PTD1__SDHC0_CMD 0x43
--
2.7.4
[PATCH V11 4/5] ARM: dts: imx7ulp: Add tpm pwm support
Add i.MX7ULP EVK board PWM support.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm/boot/dts/imx7ulp.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index d6b7110..8fb9559 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -124,6 +124,16 @@
status = "disabled";
};
+ tpm4: pwm@4025 {
+ compatible = "fsl,imx7ulp-pwm";
+ reg = <0x4025 0x1000>;
+ assigned-clocks = < IMX7ULP_CLK_LPTPM4>;
+ assigned-clock-parents = <
IMX7ULP_CLK_SOSC_BUS_CLK>;
+ clocks = < IMX7ULP_CLK_LPTPM4>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
tpm5: tpm@4026 {
compatible = "fsl,imx7ulp-tpm";
reg = <0x4026 0x1000>;
--
2.7.4
[PATCH V11 0/5] Add i.MX7ULP EVK PWM backlight support
i.MX7ULP EVK board has MIPI-DSI display, its backlight is supplied by TPM PWM module, this patch set enables i.MX7ULP TPM PWM driver support and also add backlight support for MIPI-DSI display. Changes since V10: - ONLY change the pwm driver patch. Anson Huang (5): dt-bindings: pwm: Add i.MX TPM PWM binding pwm: Add i.MX TPM PWM driver support ARM: imx_v6_v7_defconfig: Add TPM PWM support by default ARM: dts: imx7ulp: Add tpm pwm support ARM: dts: imx7ulp-evk: Add backlight support .../devicetree/bindings/pwm/imx-tpm-pwm.txt| 22 + arch/arm/boot/dts/imx7ulp-evk.dts | 21 + arch/arm/boot/dts/imx7ulp.dtsi | 10 + arch/arm/configs/imx_v6_v7_defconfig | 1 + drivers/pwm/Kconfig| 11 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-imx-tpm.c | 442 + 7 files changed, 508 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt create mode 100644 drivers/pwm/pwm-imx-tpm.c -- 2.7.4
[PATCH V11 2/5] pwm: Add i.MX TPM PWM driver support
i.MX7ULP has TPM(Low Power Timer/Pulse Width Modulation Module)
inside, it can support multiple PWM channels, all the channels
share same counter and period setting, but each channel can
configure its duty and polarity independently.
There are several TPM modules in i.MX7ULP, the number of channels
in TPM modules are different, it can be read from each TPM module's
PARAM register.
Signed-off-by: Anson Huang
---
Changes since V10:
- remove channel private data which is ONLY for storing polarity, just
read it from HW register;
- improve pwm_imx_tpm_round_state() and pwm_imx_tpm_apply_hw()
parameters sequence;
- improve comments for polarity setting;
- refuse polarity change if PWM is active.
---
drivers/pwm/Kconfig | 11 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-imx-tpm.c | 442 ++
3 files changed, 454 insertions(+)
create mode 100644 drivers/pwm/pwm-imx-tpm.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index c054bd1..1311b540 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -210,6 +210,17 @@ config PWM_IMX27
To compile this driver as a module, choose M here: the module
will be called pwm-imx27.
+config PWM_IMX_TPM
+ tristate "i.MX TPM PWM support"
+ depends on ARCH_MXC || COMPILE_TEST
+ depends on HAVE_CLK && HAS_IOMEM
+ help
+ Generic PWM framework driver for i.MX7ULP TPM module, TPM's full
+ name is Low Power Timer/Pulse Width Modulation Module.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-imx-tpm.
+
config PWM_JZ4740
tristate "Ingenic JZ47xx PWM support"
depends on MACH_INGENIC
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 448825e..c368599 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_PWM_HIBVT) += pwm-hibvt.o
obj-$(CONFIG_PWM_IMG) += pwm-img.o
obj-$(CONFIG_PWM_IMX1) += pwm-imx1.o
obj-$(CONFIG_PWM_IMX27)+= pwm-imx27.o
+obj-$(CONFIG_PWM_IMX_TPM) += pwm-imx-tpm.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LP3943) += pwm-lp3943.o
obj-$(CONFIG_PWM_LPC18XX_SCT) += pwm-lpc18xx-sct.o
diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
new file mode 100644
index 000..9349f4f
--- /dev/null
+++ b/drivers/pwm/pwm-imx-tpm.c
@@ -0,0 +1,442 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018-2019 NXP.
+ *
+ * Limitations:
+ * - The TPM counter and period counter are shared between
+ * multiple channels, so all channels should use same period
+ * settings.
+ * - Changes to polarity cannot be latched at the time of the
+ * next period start.
+ * - Changing period and duty cycle together isn't atomic,
+ * with the wrong timing it might happen that a period is
+ * produced with old duty cycle but new period settings.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PWM_IMX_TPM_PARAM 0x4
+#define PWM_IMX_TPM_GLOBAL 0x8
+#define PWM_IMX_TPM_SC 0x10
+#define PWM_IMX_TPM_CNT0x14
+#define PWM_IMX_TPM_MOD0x18
+#define PWM_IMX_TPM_CnSC(n)(0x20 + (n) * 0x8)
+#define PWM_IMX_TPM_CnV(n) (0x24 + (n) * 0x8)
+
+#define PWM_IMX_TPM_PARAM_CHAN GENMASK(7, 0)
+
+#define PWM_IMX_TPM_SC_PS GENMASK(2, 0)
+#define PWM_IMX_TPM_SC_CMODGENMASK(4, 3)
+#define PWM_IMX_TPM_SC_CMOD_INC_EVERY_CLK FIELD_PREP(PWM_IMX_TPM_SC_CMOD,
1)
+#define PWM_IMX_TPM_SC_CPWMS BIT(5)
+
+#define PWM_IMX_TPM_CnSC_CHF BIT(7)
+#define PWM_IMX_TPM_CnSC_MSB BIT(5)
+#define PWM_IMX_TPM_CnSC_MSA BIT(4)
+
+/*
+ * The reference manual describes this field as two separate bits. The
+ * semantic of the two bits isn't orthogonal though, so they are treated
+ * together as a 2-bit field here.
+ */
+#define PWM_IMX_TPM_CnSC_ELS GENMASK(3, 2)
+#define PWM_IMX_TPM_CnSC_ELS_INVERSED FIELD_PREP(PWM_IMX_TPM_CnSC_ELS, 1)
+#define PWM_IMX_TPM_CnSC_ELS_NORMALFIELD_PREP(PWM_IMX_TPM_CnSC_ELS, 2)
+
+
+#define PWM_IMX_TPM_MOD_WIDTH 16
+#define PWM_IMX_TPM_MOD_MODGENMASK(PWM_IMX_TPM_MOD_WIDTH - 1, 0)
+
+struct imx_tpm_pwm_chip {
+ struct pwm_chip chip;
+ struct clk *clk;
+ void __iomem *base;
+ struct mutex lock;
+ u32 user_count;
+ u32 enable_count;
+ u32 real_period;
+};
+
+struct imx_tpm_pwm_param {
+ u8 prescale;
+ u32 mod;
+ u32 val;
+};
+
+static inline struct imx_tpm_pwm_chip *to_imx_tpm_pwm_chip(struct pwm_chip
*chip)
+{
+ return container_of(chip, struct imx_tpm_pwm_chip, chip);
+}
+
+static int pwm_imx_tpm_round_state(struct pwm_chip *chip,
+ struct imx_tpm_pwm_param *p,
+
[PATCH V11 3/5] ARM: imx_v6_v7_defconfig: Add TPM PWM support by default
Select CONFIG_PWM_IMX_TPM by default to support i.MX7ULP TPM PWM. Signed-off-by: Anson Huang --- No changes. --- arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 765003a..f33a035 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -401,6 +401,7 @@ CONFIG_MPL3115=y CONFIG_PWM=y CONFIG_PWM_FSL_FTM=y CONFIG_PWM_IMX27=y +CONFIG_PWM_IMX_TPM=y CONFIG_NVMEM_IMX_OCOTP=y CONFIG_NVMEM_VF610_OCOTP=y CONFIG_TEE=y -- 2.7.4
[PATCH V11 1/5] dt-bindings: pwm: Add i.MX TPM PWM binding
Add i.MX TPM(Low Power Timer/Pulse Width Modulation Module) PWM binding.
Signed-off-by: Anson Huang
Reviewed-by: Rob Herring
---
No changes.
---
.../devicetree/bindings/pwm/imx-tpm-pwm.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
new file mode 100644
index 000..3ba958d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.txt
@@ -0,0 +1,22 @@
+Freescale i.MX TPM PWM controller
+
+Required properties:
+- compatible : Should be "fsl,imx7ulp-pwm".
+- reg: Physical base address and length of the controller's registers.
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
the cells format.
+- clocks : The clock provided by the SoC to drive the PWM.
+- interrupts: The interrupt for the PWM controller.
+
+Note: The TPM counter and period counter are shared between multiple channels,
so all channels
+should use same period setting.
+
+Example:
+
+tpm4: pwm@4025 {
+ compatible = "fsl,imx7ulp-pwm";
+ reg = <0x4025 0x1000>;
+ assigned-clocks = < IMX7ULP_CLK_LPTPM4>;
+ assigned-clock-parents = < IMX7ULP_CLK_SOSC_BUS_CLK>;
+ clocks = < IMX7ULP_CLK_LPTPM4>;
+ #pwm-cells = <3>;
+};
--
2.7.4
Re: [PATCH 1/2] printk: Add an option to flush all messages on panic
On (04/09/19 15:41), Petr Mladek wrote: > I suggest to merge the two patches into one. It will > still be rather small and easier to review. Agreed, was going to suggest the same. -ss
Re: linux-next: build failure after merge of the scsi-mkp tree
Stephen, >> I have reverted that commit for today. > > This has now migrated to the scsi tree. I have a fix in my tree but I haven't pushed it yet. -- Martin K. Petersen Oracle Linux Engineering
[rcu:dev.2019.04.09a 55/55] htmldocs: include/linux/rcupdate.h:837: warning: Function parameter or member 'rhf' not described in 'kfree_rcu'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2019.04.09a head: 108210466eaf3f9e0e18e250c3af4f2525963a60 commit: 108210466eaf3f9e0e18e250c3af4f2525963a60 [55/55] rcu: Make kfree_rcu() ignore NULL pointers reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/generic-radix-tree.h:1: warning: no structured comments found >> include/linux/rcupdate.h:837: warning: Function parameter or member 'rhf' >> not described in 'kfree_rcu' include/linux/rcupdate.h:837: warning: Excess function parameter 'rcu_head' description in 'kfree_rcu' kernel/rcu/tree_plugin.h:1: warning: no structured comments found kernel/rcu/tree_plugin.h:1: warning: no structured comments found include/linux/firmware/intel/stratix10-svc-client.h:1: warning: no structured comments found include/linux/gpio/driver.h:371: warning: Function parameter or member 'init_valid_mask' not described in 'gpio_chip' include/linux/i2c.h:343: warning: Function parameter or member 'init_irq' not described in 'i2c_client' include/linux/iio/hw-consumer.h:1: warning: no structured comments found include/linux/input/sparse-keymap.h:46: warning: Function parameter or member 'sw' not described in 'key_entry' include/linux/regulator/machine.h:199: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:228: warning: Function parameter or member 'resume' not described in 'regulator_ops' drivers/slimbus/stream.c:1: warning: no structured comments found include/linux/spi/spi.h:188: warning: Function parameter or member 'driver_override' not described in 'spi_device' drivers/target/target_core_device.c:1: warning: no structured comments found drivers/usb/typec/bus.c:1: warning: no structured comments found drivers/usb/typec/class.c:1: warning: no structured comments found include/linux/w1.h:281: warning: Function parameter or member 'of_match_table' not described in 'w1_family' fs/direct-io.c:257: warning: Excess function parameter 'offset' description in 'dio_complete' fs/file_table.c:1: warning: no structured comments found fs/libfs.c:477: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:646: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:646: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:646: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function parameter 'mm' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function parameter 'start' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:294: warning: Excess function parameter 'end' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:343: warning: Excess function parameter 'mm' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:343: warning: Excess function parameter 'start' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:343: warning: Excess function parameter 'end' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:183: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_read_lock' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:295: warning: Function parameter or member 'range' not described in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:295: warning: Excess function parameter 'mm' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:295: warning: Excess function parameter 'start' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:295: warning: Excess function parameter 'end' description in 'amdgpu_mn_invalidate_range_start_hsa' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:344: warning: Function parameter or member 'range' not described in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:344: warning: Excess function parameter 'mm' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:344: warning: Excess function parameter 'start' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:344: warning: Excess function parameter 'end' description in 'amdgpu_mn_invalidate_range_end' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:374: warning: cannot understand function prototype: 'struct amdgpu_vm_pt_cursor '
Re: linux-next: build failure after merge of the scsi-mkp tree
Hi all,
On Tue, 9 Apr 2019 16:27:49 +1000 Stephen Rothwell
wrote:
>
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/scsi/qla2xxx/tcm_qla2xxx.c: In function 'tcm_qla2xxx_init_lport':
> drivers/scsi/qla2xxx/tcm_qla2xxx.c:1614:3: error: implicit declaration of
> function 'vzalloc'; did you mean 'kvzalloc'?
> [-Werror=implicit-function-declaration]
>vzalloc(array_size(65536,
>^~~
>kvzalloc
> drivers/scsi/qla2xxx/tcm_qla2xxx.c:1613:26: warning: assignment to 'struct
> tcm_qla2xxx_fc_loopid *' from 'int' makes pointer from integer without a cast
> [-Wint-conversion]
> lport->lport_loopid_map =
> ^
> drivers/scsi/qla2xxx/tcm_qla2xxx.c: In function 'tcm_qla2xxx_make_lport':
> drivers/scsi/qla2xxx/tcm_qla2xxx.c:1677:2: error: implicit declaration of
> function 'vfree'; did you mean 'kvfree'?
> [-Werror=implicit-function-declaration]
> vfree(lport->lport_loopid_map);
> ^
> kvfree
>
> Caused by commit
>
> 523c106ad4b1 ("scsi: tcm_qla2xxx: Minimize #include directives")
>
> I have reverted that commit for today.
This has now migrated to the scsi tree.
--
Cheers,
Stephen Rothwell
pgp0V5CWB4Mn2.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH v2 12/14] x86/watchdog/hardlockup/hpet: Determine if HPET timer caused NMI
On Tue, Apr 09, 2019 at 01:28:17PM +0200, Peter Zijlstra wrote:
> On Wed, Feb 27, 2019 at 08:05:16AM -0800, Ricardo Neri wrote:
> > @@ -62,7 +67,18 @@ static inline void set_comparator(struct hpet_hld_data
> > *hdata,
> > static void kick_timer(struct hpet_hld_data *hdata, bool force)
> > {
> > bool kick_needed = force || !(hdata->flags & HPET_DEV_PERI_CAP);
> > - unsigned long new_compare, count;
> > + unsigned long tsc_curr, tsc_delta, new_compare, count;
> > +
> > + /* Start obtaining the current TSC and HPET counts. */
> > + tsc_curr = rdtsc();
> > +
> > + if (kick_needed)
> > + count = get_count();
> > +
> > + tsc_delta = (unsigned long)watchdog_thresh * (unsigned long)tsc_khz
> > + * 1000L;
> > + hdata->tsc_next = tsc_curr + tsc_delta;
> > + hdata->tsc_next_error = tsc_delta >> 6;
>
> What do we need a per hld_data tsc_next_error for? It is basically a
> global 'constant'.
>
This is true. I thought I'd keep all the needed variables in a single
struct to make the code more readable. I guess, I did not achieve that
goal. I'll put it as a static global variable.
> > /*
> > * Update the comparator in increments of watch_thresh seconds relative
> > @@ -74,8 +90,6 @@ static void kick_timer(struct hpet_hld_data *hdata, bool
> > force)
> > */
> >
> > if (kick_needed) {
> > - count = get_count();
> > -
> > new_compare = count + watchdog_thresh * hdata->ticks_per_second;
> >
> > set_comparator(hdata, new_compare);
> > @@ -147,6 +161,14 @@ static void set_periodic(struct hpet_hld_data *hdata)
> > */
> > static bool is_hpet_wdt_interrupt(struct hpet_hld_data *hdata)
> > {
> > + if (smp_processor_id() == hdata->handling_cpu) {
> > + unsigned long tsc_curr;
>
> TSC is u64
In x86_64, isn't u64 an unsigned long? Do you mean to consider the
32-bit case?
>
> > +
> > + tsc_curr = rdtsc();
> > + if (abs(tsc_curr - hdata->tsc_next) < hdata->tsc_next_error)
> > + return true;
>
> You can write that as:
>
> (tsc_curr - hdata->tsc_next) + tsc_error < 2*tsc_error
>
> which doesn't contain any branches what so ever.
>
Sure, I'll add this change.
Thanks and BR,
Ricardo
Re: [PATCH 1/2] mm/gup.c: fix the wrong comments
On Tue, Apr 09, 2019 at 02:55:31PM +, Weiny, Ira wrote:
> > On Tue, Apr 09, 2019 at 11:04:18AM +0800, Huang Shijie wrote:
> > > On Mon, Apr 08, 2019 at 07:49:29PM -0700, Matthew Wilcox wrote:
> > > > On Tue, Apr 09, 2019 at 09:08:33AM +0800, Huang Shijie wrote:
> > > > > On Mon, Apr 08, 2019 at 07:13:13AM -0700, Matthew Wilcox wrote:
> > > > > > On Mon, Apr 08, 2019 at 10:37:45AM +0800, Huang Shijie wrote:
> > > > > > > The root cause is that sg_alloc_table_from_pages() requires
> > > > > > > the page order to keep the same as it used in the user space,
> > > > > > > but
> > > > > > > get_user_pages_fast() will mess it up.
> > > > > >
> > > > > > I don't understand how get_user_pages_fast() can return the
> > > > > > pages in a different order in the array from the order they appear
> > > > > > in
> > userspace.
> > > > > > Can you explain?
> > > > > Please see the code in gup.c:
> > > > >
> > > > > int get_user_pages_fast(unsigned long start, int nr_pages,
> > > > > unsigned int gup_flags, struct page
> > > > > **pages)
> > > > > {
> > > > > ...
> > > > > if (gup_fast_permitted(start, nr_pages)) {
> > > > > local_irq_disable();
> > > > > gup_pgd_range(addr, end, gup_flags, pages, );
> > // The @pages array maybe filled at the first time.
> > > >
> > > > Right ... but if it's not filled entirely, it will be filled
> > > > part-way, and then we stop.
> > > >
> > > > > local_irq_enable();
> > > > > ret = nr;
> > > > > }
> > > > > ...
> > > > > if (nr < nr_pages) {
> > > > > /* Try to get the remaining pages with
> > get_user_pages */
> > > > > start += nr << PAGE_SHIFT;
> > > > > pages += nr;
> > > > > // The
> > @pages is moved forward.
> > > >
> > > > Yes, to the point where gup_pgd_range() stopped.
> > > >
> > > > > if (gup_flags & FOLL_LONGTERM) {
> > > > > down_read(>mm->mmap_sem);
> > > > > ret = __gup_longterm_locked(current,
> > current->mm, // The @pages maybe filled at the second time
> > > >
> > > > Right.
> > > >
> > > > > /*
> > > > >* retain FAULT_FOLL_ALLOW_RETRY
> > optimization if
> > > > >* possible
> > > > >*/
> > > > > ret = get_user_pages_unlocked(start,
> > nr_pages - nr,// The @pages maybe filled at the second time.
> > > > > pages,
> > > > > gup_flags);
> > > >
> > > > Yes. But they'll be in the same order.
> > > >
> > > > > BTW, I do not know why we mess up the page order. It maybe used in
> > some special case.
> > > >
> > > > I'm not discounting the possibility that you've found a bug.
> > > > But documenting that a bug exists is not the solution; the solution
> > > > is fixing the bug.
> > > I do not think it is a bug :)
> > >
> > > If we use the get_user_pages_unlocked(), DMA is okay, such as:
> > >
> > >get_user_pages_unlocked()
> > >sg_alloc_table_from_pages()
> > >.
> > >
> > > I think the comment is not accurate enough. So just add more comments,
> > > and tell the driver users how to use the GUPs.
> >
> > gup_fast() and gup_unlocked() should return the pages in the same order.
> > If they do not, then it is a bug.
>
> Is there a reproducer for this? Or do you have some debug output which shows
> this problem?
Is Matthew right?
" gup_fast() and gup_unlocked() should return the pages in the same order.
If they do not, then it is a bug."
If Matthew is right,
I need more time to debug the DMA issue...
Thanks
Huang Shijie
>
> Ira
>
Re: [PATCH 1/2] mm/gup.c: fix the wrong comments
On Tue, Apr 09, 2019 at 01:23:16PM -0700, Ira Weiny wrote:
> On Tue, Apr 09, 2019 at 09:08:33AM +0800, Huang Shijie wrote:
> > On Mon, Apr 08, 2019 at 07:13:13AM -0700, Matthew Wilcox wrote:
> > > On Mon, Apr 08, 2019 at 10:37:45AM +0800, Huang Shijie wrote:
> > > > When CONFIG_HAVE_GENERIC_GUP is defined, the kernel will use its own
> > > > get_user_pages_fast().
> > > >
> > > > In the following scenario, we will may meet the bug in the DMA case:
> > > > .
> > > > get_user_pages_fast(start,,, pages);
> > > > ..
> > > > sg_alloc_table_from_pages(, pages, ...);
> > > > .
> > > >
> > > > The root cause is that sg_alloc_table_from_pages() requires the
> > > > page order to keep the same as it used in the user space, but
> > > > get_user_pages_fast() will mess it up.
> > >
> > > I don't understand how get_user_pages_fast() can return the pages in a
> > > different order in the array from the order they appear in userspace.
> > > Can you explain?
> > Please see the code in gup.c:
> >
> > int get_user_pages_fast(unsigned long start, int nr_pages,
> > unsigned int gup_flags, struct page **pages)
> > {
> > ...
> > if (gup_fast_permitted(start, nr_pages)) {
> > local_irq_disable();
> > gup_pgd_range(addr, end, gup_flags, pages, );
> >// The @pages array maybe filled at the first time.
> > local_irq_enable();
> > ret = nr;
> > }
> > ...
> > if (nr < nr_pages) {
> > /* Try to get the remaining pages with get_user_pages */
> > start += nr << PAGE_SHIFT;
> > pages += nr;
> > // The @pages is moved forward.
> >
> > if (gup_flags & FOLL_LONGTERM) {
> > down_read(>mm->mmap_sem);
> > ret = __gup_longterm_locked(current,
> > current->mm, // The @pages maybe filled at the second time
> >
>
> Neither this nor the get_user_pages_unlocked is filling the pages a second
The get_user_pages_unlocked() will call the handle_mm_fault which will allocate
a
new page for the empty PTE, and save the new page into the @pages array.
> time. It is adding to the page array having moved start and the page array
> forward.
Yes. This will mess up the page order.
I will read the code again to check if I am wrong :)
>
> Are you doing a FOLL_LONGTERM GUP? Or are you in the else clause below when
> you get this bug?
I do not use FOLL_LONGTERM, I just use the FOLL_WRITE.
So it seems it runs into the else clause below.
Thanks
Huang Shijie
>
> Ira
>
> > start, nr_pages -
> > nr,
> > pages, NULL,
> > gup_flags);
> > up_read(>mm->mmap_sem);
> > } else {
> > /*
> > * retain FAULT_FOLL_ALLOW_RETRY optimization if
> > * possible
> > */
> > ret = get_user_pages_unlocked(start, nr_pages -
> > nr,// The @pages maybe filled at the second time.
> > pages, gup_flags);
> > }
> > }
> >
> >
Re: [PATCH 2/2] module: Make srcu_struct ptr array as read-only post init
On Tue, Apr 09, 2019 at 09:14:18PM -0400, Joel Fernandes (Google) wrote:
> Since commit title ("srcu: Allocate per-CPU data for DEFINE_SRCU() in
> modules"), modules that call DEFINE_{STATIC,}SRCU will have a new array
> of srcu_struct pointers which is used by srcu code to initialize and
> clean up these structures.
>
> There is no reason for this array of pointers to be writable, and can
> cause security or other hidden bugs. Mark these are read-only after the
> module init has completed.
>
> Suggested-by: paul...@linux.vnet.ibm.com
> Suggested-by: keesc...@chromium.org
> Signed-off-by: Joel Fernandes (Google)
Just wanted to mention, that I tested that the srcu_struct_ptrs array is not
writeable any more after init, but doing the following after
module_enable_ro() :
@@ -3513,6 +3523,14 @@ static noinline int do_init_module(struct module *mod)
rcu_assign_pointer(mod->kallsyms, >core_kallsyms);
#endif
module_enable_ro(mod, true);
+
+ if (mod->srcu_struct_ptrs) {
+ // Check if SRCU Access is possible
+ char x = *(char *)mod->srcu_struct_ptrs;
+ *(char *)mod->srcu_struct_ptrs = 0;
+ *(char *)mod->srcu_struct_ptrs = x;
+ }
+
mod_tree_remove_init(mod);
disable_ro_nx(>init_layout);
module_arch_freeing_init(mod);
thanks,
- Joel
>
> ---
> kernel/module.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index f9221381d076..ed1f2612aebc 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3301,7 +3301,7 @@ static bool blacklisted(const char *module_name)
> core_param(module_blacklist, module_blacklist, charp, 0400);
>
> /*
> - * Mark ro_after_init section with SHF_RO_AFTER_INIT so that
> + * These are section names marked with SHF_RO_AFTER_INIT so that
> * layout_sections() can put it in the right place.
> * Note: ro_after_init sections also have SHF_{WRITE,ALLOC} set.
> */
> @@ -3314,6 +3314,13 @@ static char *ro_after_init_sections[] = {
>* annotated as such at module load time.
>*/
> "__jump_table",
> +
> + /*
> + * Used for SRCU structures which need to be initialized/cleaned up
> + * by the SRCU notifiers
> + */
> + "___srcu_struct_ptrs",
> +
> NULL
> };
>
> --
> 2.21.0.392.gf8f6787159e-goog
>
[PATCH 2/2] module: Make srcu_struct ptr array as read-only post init
Since commit title ("srcu: Allocate per-CPU data for DEFINE_SRCU() in
modules"), modules that call DEFINE_{STATIC,}SRCU will have a new array
of srcu_struct pointers which is used by srcu code to initialize and
clean up these structures.
There is no reason for this array of pointers to be writable, and can
cause security or other hidden bugs. Mark these are read-only after the
module init has completed.
Suggested-by: paul...@linux.vnet.ibm.com
Suggested-by: keesc...@chromium.org
Signed-off-by: Joel Fernandes (Google)
---
kernel/module.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/module.c b/kernel/module.c
index f9221381d076..ed1f2612aebc 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3301,7 +3301,7 @@ static bool blacklisted(const char *module_name)
core_param(module_blacklist, module_blacklist, charp, 0400);
/*
- * Mark ro_after_init section with SHF_RO_AFTER_INIT so that
+ * These are section names marked with SHF_RO_AFTER_INIT so that
* layout_sections() can put it in the right place.
* Note: ro_after_init sections also have SHF_{WRITE,ALLOC} set.
*/
@@ -3314,6 +3314,13 @@ static char *ro_after_init_sections[] = {
* annotated as such at module load time.
*/
"__jump_table",
+
+ /*
+* Used for SRCU structures which need to be initialized/cleaned up
+* by the SRCU notifiers
+*/
+ "___srcu_struct_ptrs",
+
NULL
};
--
2.21.0.392.gf8f6787159e-goog
Re: [RFC PATCH v2 11/14] x86/watchdog/hardlockup: Add an HPET-based hardlockup detector
On Tue, Apr 09, 2019 at 12:59:46PM +0200, Peter Zijlstra wrote:
> On Tue, Mar 26, 2019 at 09:49:13PM +0100, Thomas Gleixner wrote:
> > So way you should handle this is:
> >
> > cpumask_set_cpu(cpu, hld_data->cpu_monitored_mask);
> >
> > if (!hld_data->enabled_cpus++) {
> > hld_data->handling_cpu = cpu;
> > kick_timer();
> > enable_timer();
> > }
> >
> > The cpu mask starts off empty and each CPU sets itself when the function is
> > invoked on it.
> >
> > data->enabled_cpus keeps track of the enabled cpus so you avoid
> > reconfiguration just because a different cpu comes online. And it's
> > required for disable as well.
> >
> > > +void hardlockup_detector_hpet_disable(void)
> > > +{
> > > + struct cpumask *allowed = watchdog_get_allowed_cpumask();
> > > +
> > > + if (!hld_data)
> > > + return;
> > > +
> > > + /* Only disable the timer if there are no more CPUs to monitor. */
> > > + if (!cpumask_weight(allowed))
> > > + disable_timer(hld_data);
> >
> > Again this should be:
> >
> > cpumask_clear_cpu(cpu, hld_data->cpu_monitored_mask);
> > hld_data->enabled_cpus--;
> >
> > if (hld_data->handling_cpu != cpu)
> > return;
> >
> > disable_timer();
> > if (hld_data->enabled_cpus)
> > return;
>
> if (!hld_data->enabled_cpus)
> return;
>
> >
> > hld_data->handling_cpu = cpumask_first(hld_data->cpu_monitored_mask);
> > enable_timer();
>
> That said; you can do the above without ->enabled_cpus, by using
> ->handling_cpu == nr_cpu_ids to indicate 'empty'. But I'm not at all
> sure that is worth the effort, it results in less obious code.
I agree. It is probably clearer to check for !hld_data->enabled_cpus as
it clearly indicates what happens if there are no more CPUs to monitor.
Thanks and BR,
Ricardo
[PATCH 1/2] module: Prepare for addition of new ro_after_init sections
For the purposes of hardening modules by adding sections to
ro_after_init sections, prepare for addition of new ro_after_init
entries which we do in future patches. Create a table to which new
entries could be added later. This makes it less error prone and reduce
code duplication.
Cc: paul...@linux.vnet.ibm.com
Cc: rost...@goodmis.org
Cc: mathieu.desnoy...@efficios.com
Cc: r...@vger.kernel.org
Cc: kernel-harden...@lists.openwall.com
Cc: kernel-t...@android.com
Suggested-by: keesc...@chromium.org
Signed-off-by: Joel Fernandes (Google)
---
kernel/module.c | 42 --
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 524da609c884..f9221381d076 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3300,11 +3300,28 @@ static bool blacklisted(const char *module_name)
}
core_param(module_blacklist, module_blacklist, charp, 0400);
+/*
+ * Mark ro_after_init section with SHF_RO_AFTER_INIT so that
+ * layout_sections() can put it in the right place.
+ * Note: ro_after_init sections also have SHF_{WRITE,ALLOC} set.
+ */
+static char *ro_after_init_sections[] = {
+ ".data..ro_after_init",
+
+ /*
+* __jump_table structures are never modified, with the exception of
+* entries that refer to code in the __init section, which are
+* annotated as such at module load time.
+*/
+ "__jump_table",
+ NULL
+};
+
static struct module *layout_and_allocate(struct load_info *info, int flags)
{
struct module *mod;
unsigned int ndx;
- int err;
+ int err, i;
err = check_modinfo(info->mod, info, flags);
if (err)
@@ -3319,23 +3336,12 @@ static struct module *layout_and_allocate(struct
load_info *info, int flags)
/* We will do a special allocation for per-cpu sections later. */
info->sechdrs[info->index.pcpu].sh_flags &= ~(unsigned long)SHF_ALLOC;
- /*
-* Mark ro_after_init section with SHF_RO_AFTER_INIT so that
-* layout_sections() can put it in the right place.
-* Note: ro_after_init sections also have SHF_{WRITE,ALLOC} set.
-*/
- ndx = find_sec(info, ".data..ro_after_init");
- if (ndx)
- info->sechdrs[ndx].sh_flags |= SHF_RO_AFTER_INIT;
- /*
-* Mark the __jump_table section as ro_after_init as well: these data
-* structures are never modified, with the exception of entries that
-* refer to code in the __init section, which are annotated as such
-* at module load time.
-*/
- ndx = find_sec(info, "__jump_table");
- if (ndx)
- info->sechdrs[ndx].sh_flags |= SHF_RO_AFTER_INIT;
+ /* Set sh_flags for read-only after init sections */
+ for (i = 0; ro_after_init_sections[i]; i++) {
+ ndx = find_sec(info, ro_after_init_sections[i]);
+ if (ndx)
+ info->sechdrs[ndx].sh_flags |= SHF_RO_AFTER_INIT;
+ }
/* Determine total sizes, and put offsets in sh_entsize. For now
this is done generically; there doesn't appear to be any
--
2.21.0.392.gf8f6787159e-goog
[PATCH 0/2] perf: Add Tremont support
From: Kan Liang The patch series intends to add Tremont support for Linux perf. The patch series is on top of Icelake V5 patch series (with Peter's cleanup patch). https://lkml.org/lkml/2019/4/8/630 PATCH 1: The feature is for both Icelake and Tremont. It missed the Icelake patch series. PATCH 2: Tremont core PMU support. Kan Liang (2): perf/x86/intel: Support adaptive PEBS for fixed counters perf/x86/intel: Add Tremont core PMU support arch/x86/events/intel/core.c | 93 +++ arch/x86/include/asm/perf_event.h | 1 + 2 files changed, 94 insertions(+) -- 2.7.4
[PATCH 1/2] perf/x86/intel: Support adaptive PEBS for fixed counters
From: Kan Liang
Fixed counters can also generate adaptive PEBS record, if the
corresponding bit in IA32_FIXED_CTR_CTRL is set.
Otherwise, only basic record is generated.
Unconditionally set the bit when PEBS is enabled on fixed counters.
Let MSR_PEBS_CFG decide which format of PEBS record should be generated.
There is no harmful to leave the bit set.
Signed-off-by: Kan Liang
---
arch/x86/events/intel/core.c | 5 +
arch/x86/include/asm/perf_event.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 56df0f6..f34d92b 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -2174,6 +2174,11 @@ static void intel_pmu_enable_fixed(struct perf_event
*event)
bits <<= (idx * 4);
mask = 0xfULL << (idx * 4);
+ if (x86_pmu.intel_cap.pebs_baseline && event->attr.precise_ip) {
+ bits |= ICL_FIXED_0_ADAPTIVE << (idx * 4);
+ mask |= ICL_FIXED_0_ADAPTIVE << (idx * 4);
+ }
+
rdmsrl(hwc->config_base, ctrl_val);
ctrl_val &= ~mask;
ctrl_val |= bits;
diff --git a/arch/x86/include/asm/perf_event.h
b/arch/x86/include/asm/perf_event.h
index dcb8bac..ce0dc88 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -33,6 +33,7 @@
#define HSW_IN_TX (1ULL << 32)
#define HSW_IN_TX_CHECKPOINTED (1ULL << 33)
#define ICL_EVENTSEL_ADAPTIVE (1ULL << 34)
+#define ICL_FIXED_0_ADAPTIVE (1ULL << 32)
#define AMD64_EVENTSEL_INT_CORE_ENABLE (1ULL << 36)
#define AMD64_EVENTSEL_GUESTONLY (1ULL << 40)
--
2.7.4
[PATCH 2/2] perf/x86/intel: Add Tremont core PMU support
From: Kan Liang
Add perf core PMU support for Intel Tremont CPU.
The init code is based on Goldmont plus.
The generic purpose counter 0 and fixed counter 0 have less skid.
Force :ppp events on generic purpose counter 0.
Force instruction:ppp always on fixed counter 0.
Updates LLC cache event table and OFFCORE_RESPONSE mask.
The adaptive PEBS, which is already enabled on ICL, is also supported
on Tremont. No extra codes required.
Signed-off-by: Kan Liang
---
arch/x86/events/intel/core.c | 88
1 file changed, 88 insertions(+)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index f34d92b..f478831 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -1856,6 +1856,45 @@ static __initconst const u64 glp_hw_cache_extra_regs
},
};
+#define TNT_LOCAL_DRAM BIT_ULL(26)
+#define TNT_DEMAND_READGLM_DEMAND_DATA_RD
+#define TNT_DEMAND_WRITE GLM_DEMAND_RFO
+#define TNT_LLC_ACCESS GLM_ANY_RESPONSE
+#define TNT_SNP_ANY(SNB_SNP_NOT_NEEDED|SNB_SNP_MISS| \
+SNB_NO_FWD|SNB_SNP_FWD|SNB_HITM)
+#define TNT_LLC_MISS
(TNT_SNP_ANY|SNB_NON_DRAM|TNT_LOCAL_DRAM)
+
+static __initconst const u64 tnt_hw_cache_extra_regs
+ [PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
+ [C(LL)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = TNT_DEMAND_READ|
+ TNT_LLC_ACCESS,
+ [C(RESULT_MISS)]= TNT_DEMAND_READ|
+ TNT_LLC_MISS,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = TNT_DEMAND_WRITE|
+ TNT_LLC_ACCESS,
+ [C(RESULT_MISS)]= TNT_DEMAND_WRITE|
+ TNT_LLC_MISS,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = 0x0,
+ [C(RESULT_MISS)]= 0x0,
+ },
+ },
+};
+
+static struct extra_reg intel_tnt_extra_regs[] __read_mostly = {
+ /* must define OFFCORE_RSP_X first, see intel_fixup_er() */
+ INTEL_UEVENT_EXTRA_REG(0x01b7, MSR_OFFCORE_RSP_0, 0xff9fffull,
RSP_0),
+ INTEL_UEVENT_EXTRA_REG(0x02b7, MSR_OFFCORE_RSP_1, 0xff9fffull,
RSP_1),
+ EVENT_EXTRA_END
+};
+
#define KNL_OT_L2_HITE BIT_ULL(19) /* Other Tile L2 Hit */
#define KNL_OT_L2_HITF BIT_ULL(20) /* Other Tile L2 Hit */
#define KNL_MCDRAM_LOCAL BIT_ULL(21)
@@ -3451,6 +3490,29 @@ glp_get_event_constraints(struct cpu_hw_events *cpuc,
int idx,
return c;
}
+static struct event_constraint *
+tnt_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
+ struct perf_event *event)
+{
+ struct event_constraint *c;
+
+ /*
+* :ppp means to do reduced skid PEBS,
+* which is available at PMC0 and fixed counter 0.
+*/
+ if (event->attr.precise_ip == 3) {
+ /* Force instruction:ppp in Fixed counter 0 */
+ if (event->hw.config == X86_CONFIG(.event=0xc0))
+ return _counter0_constraint;
+
+ return _constraint;
+ }
+
+ c = intel_get_event_constraints(cpuc, idx, event);
+
+ return c;
+}
+
static bool allow_tsx_force_abort = true;
static struct event_constraint *
@@ -4530,6 +4592,32 @@ __init int intel_pmu_init(void)
name = "goldmont_plus";
break;
+ case INTEL_FAM6_ATOM_TREMONT_X:
+ x86_pmu.late_ack = true;
+ memcpy(hw_cache_event_ids, glp_hw_cache_event_ids,
+ sizeof(hw_cache_event_ids));
+ memcpy(hw_cache_extra_regs, tnt_hw_cache_extra_regs,
+ sizeof(hw_cache_extra_regs));
+ hw_cache_event_ids[C(ITLB)][C(OP_READ)][C(RESULT_ACCESS)] = -1;
+
+ intel_pmu_lbr_init_skl();
+
+ x86_pmu.event_constraints = intel_slm_event_constraints;
+ x86_pmu.extra_regs = intel_tnt_extra_regs;
+ /*
+* It's recommended to use CPU_CLK_UNHALTED.CORE_P + NPEBS
+* for precise cycles.
+*/
+ x86_pmu.pebs_aliases = NULL;
+ x86_pmu.pebs_prec_dist = true;
+ x86_pmu.lbr_pt_coexist = true;
+ x86_pmu.flags |= PMU_FL_HAS_RSP_1;
+ x86_pmu.get_event_constraints = tnt_get_event_constraints;
+ extra_attr = slm_format_attr;
+ pr_cont("Tremont events, ");
+
Re: [RFC PATCH v2 11/14] x86/watchdog/hardlockup: Add an HPET-based hardlockup detector
On Tue, Apr 09, 2019 at 01:03:40PM +0200, Peter Zijlstra wrote:
> On Wed, Feb 27, 2019 at 08:05:15AM -0800, Ricardo Neri wrote:
> > diff --git a/arch/x86/include/asm/hpet.h b/arch/x86/include/asm/hpet.h
> > index 4d559e0c746f..15dc3b576496 100644
> > --- a/arch/x86/include/asm/hpet.h
> > +++ b/arch/x86/include/asm/hpet.h
> > @@ -123,12 +123,24 @@ struct hpet_hld_data {
> > u32 num;
> > u32 flags;
> > u64 ticks_per_second;
> > + u32 handling_cpu;
> > + struct cpumask cpu_monitored_mask;
> > + struct msi_msg msi_msg;
> > };
>
> Please don't use struct cpumask unless you absolutely have to.
>
> The above is better written as:
>
>
> struct hpet_hld_data {
> ...
> unsigned long cpumask[0];
> };
>
> and allocated using:
>
> struct hpet_hld_data *hhd = kzalloc(sizeof(struct hpet_hld_data) +
> cpumask_size());
>
> and used as:
>
> to_cpumask(hhd->cpumask);
Thanks for your feedback, Peter!
Sure. I will make this change.
Thanks and BR,
Ricardo
[PATCH v2 net-next 02/22] net: dsa: Fix pharse -> phase typo
Signed-off-by: Vladimir Oltean
Reviewed-by: Andrew Lunn
---
Changes in v2:
None
net/dsa/switch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index e1fae969aa73..fde4e9195709 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -196,7 +196,7 @@ static int dsa_port_vlan_check(struct dsa_switch *ds, int
port,
if (!dp->bridge_dev)
return err;
- /* dsa_slave_vlan_rx_{add,kill}_vid() cannot use the prepare pharse and
+ /* dsa_slave_vlan_rx_{add,kill}_vid() cannot use the prepare phase and
* already checks whether there is an overlapping bridge VLAN entry
* with the same VID, so here we only need to check that if we are
* adding a bridge VLAN entry there is not an overlapping VLAN device
--
2.17.1
[PATCH 2/2] ARM: dts: imx6ul-pico: Add support for the nymph baseboard
From: Fabio Estevam
Add support for the imx6ul pico board with nymph baseboard combination.
Signed-off-by: Fabio Estevam
Signed-off-by: Otavio Salvador
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-pico-nymph.dts | 77 +
2 files changed, 78 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-pico-nymph.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e4a2349e130e..7b9b3d384902 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -568,6 +568,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-opos6uldev.dtb \
imx6ul-pico-dwarf.dtb \
imx6ul-pico-hobbit.dtb \
+ imx6ul-pico-nymph.dtb \
imx6ul-pico-pi.dtb \
imx6ul-phytec-phyboard-segin-full.dtb \
imx6ul-tx6ul-0010.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-pico-nymph.dts
b/arch/arm/boot/dts/imx6ul-pico-nymph.dts
new file mode 100644
index ..cb5ec45341bc
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-pico-nymph.dts
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Copyright 2015 Technexion Ltd.
+//
+// Author: Wig Cheng
+//Richard Hu
+//Tapani Utriainen
+/dts-v1/;
+
+#include "imx6ul-pico.dtsi"
+/ {
+ model = "TechNexion PICO-IMX6UL and NYMPH baseboard";
+ compatible = "technexion,imx6ul-pico-nymph", "fsl,imx6ul";
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio_leds>;
+
+ led {
+ label = "gpio-led";
+ gpios = < 29 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "fsl,imx-audio-sgtl5000";
+ model = "imx6ul-sgtl5000";
+ audio-cpu = <>;
+ audio-codec = <>;
+ audio-routing =
+ "LINE_IN", "Line In Jack",
+ "MIC_IN", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "Headphone Jack", "HP_OUT";
+ };
+
+ sys_mclk: clock-sys-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24576000>;
+ };
+};
+
+ {
+ clock_frequency = <10>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c2>;
+ status = "okay";
+
+ sgtl5000: codec@a {
+ reg = <0x0a>;
+ compatible = "fsl,sgtl5000";
+ clocks = <_mclk>;
+ VDDA-supply = <_2p5v>;
+ VDDIO-supply = <_3p3v>;
+ };
+
+ adc081c: adc@52 {
+ compatible = "ti,adc081c";
+ reg = <0x52>;
+ vref-supply = <_2p5v>;
+ };
+
+ ds1337: rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ };
+};
+
+ {
+ pinctrl_gpio_leds: gpioledsgrp {
+ fsl,pins = <
+ MX6UL_PAD_UART4_RX_DATA__GPIO1_IO29 0x10b0
+ >;
+ };
+};
--
2.21.0
[PATCH 1/2] dt-bindings: arm: fsl: Add support for imx6ul-pico-nymph
From: Fabio Estevam Add support for TechNexion's imx6ul-pico-nymph board. Signed-off-by: Fabio Estevam Signed-off-by: Otavio Salvador --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 944687df45b8..f19ca45a9333 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -124,6 +124,7 @@ properties: - enum: - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board - technexion,imx6ul-pico-dwarf # i.MX6 UltraLite Pico Dwarf Board + - technexion,imx6ul-pico-nymph # i.MX6 UltraLite Pico Nymph Board - const: fsl,imx6ul - description: i.MX6ULL based Boards -- 2.21.0
Dear Friend 27/03/2019
Dear Friend, I am Mrs. Kath-leen Jacob. an aging widow suffering from Cancer illness.I have some funds Which I have inherited from my late husband, the sum of (US$5.5 Million Dollars) And I needed a very honest and sincere Individual or co-operate organization that will use the fund for work of humanity, I found your email address from the Human resources data base and decided to contact you. Please if you would be able to use the funds for the work of humanity as I have stated here in order to fulfill my late husband wishes please, kindly reply me back immediately through my private email address (mrskathleenjaco...@yahoo.com ) for more details Yours in Christ Mrs Kath-leen Jacob
mmotm 2019-04-09-17-51 uploaded
The mm-of-the-moment snapshot 2019-04-09-17-51 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 5.1-rc4: (patches marked "*" will be included in linux-next) origin.patch * checkpatch-dont-interpret-stack-dumps-as-commit-ids.patch * mm-add-sys-kernel-slab-cache-cache_dma32.patch * coredump-fix-race-condition-between-mmget_not_zero-get_task_mm-and-core-dumping.patch * userfaultfd-use-rcu-to-free-the-task-struct-when-fork-fails.patch * slab-store-tagged-freelist-for-off-slab-slabmgmt.patch * mm-swapoff-shmem_find_swap_entries-filter-out-other-types.patch * mm-swapoff-remove-too-limiting-swap_unuse_max_tries.patch * mm-swapoff-take-notice-of-completion-sooner.patch * mm-swapoff-shmem_unuse-stop-eviction-without-igrab.patch * mm-swapoff-shmem_unuse-stop-eviction-without-igrab-fix.patch * mm-memory_hotplug-do-not-unlock-when-fails-to-take-the-device_hotplug_lock.patch * mm-vmstat-fix-proc-vmstat-format-for-config_debug_tlbflush=y-config_smp=n.patch * prctl-fix-false-positive-in-validate_prctl_map.patch * scripts-spellingtxt-add-more-typos-to-spellingtxt-and-sort.patch * arch-sh-boards-mach-dreamcast-irqc-remove-duplicate-header.patch * debugobjects-move-printk-out-of-db-lock-critical-sections.patch * ocfs2-use-common-file-type-conversion.patch * ocfs2-fix-ocfs2-read-inode-data-panic-in-ocfs2_iget.patch * ocfs2-clear-zero-in-unaligned-direct-io.patch * ocfs2-clear-zero-in-unaligned-direct-io-checkpatch-fixes.patch * ocfs2-wait-for-recovering-done-after-direct-unlock-request.patch * ocfs2-checkpoint-appending-truncate-log-transaction-before-flushing.patch * ramfs-support-o_tmpfile.patch mm.patch * list-add-function-list_rotate_to_front.patch * slob-respect-list_head-abstraction-layer.patch * slob-use-slab_list-instead-of-lru.patch * slub-add-comments-to-endif-pre-processor-macros.patch * slub-use-slab_list-instead-of-lru.patch * slab-use-slab_list-instead-of-lru.patch * mm-remove-stale-comment-from-page-struct.patch * slub-remove-useless-kmem_cache_debug-before-remove_full.patch * mm-slab-remove-unneed-check-in-cpuup_canceled.patch * slub-update-the-comment-about-slab-frozen.patch * mm-vmscan-drop-zone-id-from-kswapd-tracepoints.patch * mm-cma_debugc-fix-the-break-condition-in-cma_maxchunk_get.patch * userfaultfd-sysctl-add-vmunprivileged_userfaultfd.patch * userfaultfd-sysctl-add-vmunprivileged_userfaultfd-fix.patch * page-cache-store-only-head-pages-in-i_pages.patch * page-cache-store-only-head-pages-in-i_pages-fix.patch * page-cache-store-only-head-pages-in-i_pages-fix-fix.patch * mm-page_alloc-disallow-__gfp_comp-in-alloc_pages_exact.patch * mm-move-recent_rotated-pages-calculation-to-shrink_inactive_list.patch * mm-move-nr_deactivate-accounting-to-shrink_active_list.patch * mm-move-nr_deactivate-accounting-to-shrink_active_list-fix.patch * mm-remove-pages_to_free-argument-of-move_active_pages_to_lru.patch * mm-generalize-putback-scan-functions.patch * mm-gup-replace-get_user_pages_longterm-with-foll_longterm.patch * mm-gup-replace-get_user_pages_longterm-with-foll_longterm-v3.patch * mm-gup-change-write-parameter-to-flags-in-fast-walk.patch * mm-gup-change-gup-fast-to-use-flags-rather-than-a-write-bool.patch * mm-gup-add-foll_longterm-capability-to-gup-fast.patch * mm-gup-add-foll_longterm-capability-to-gup-fast-v3.patch * ib-hfi1-use-the-new-foll_longterm-flag-to-get_user_pages_fast.patch *
Re: rseq/x86: choosing rseq code signature
On Tue, Apr 9, 2019 at 4:43 PM Mathieu Desnoyers wrote: > - On Apr 9, 2019, at 3:32 PM, Mathieu Desnoyers > mathieu.desnoy...@efficios.com wrote: > > > > We are about to include the code signature required prior to restartable > > sequences abort handlers into glibc, which will make this ABI choice final. > > We need architecture maintainer input on that signature value. > > > > That code signature is placed before each abort handler, so the kernel can > > validate that it is indeed jumping to an abort handler (and not some > > arbitrary attacker-chosen code). The signature is never executed. > > > > Currently, tools/testing/selftests/rseq/rseq-x86.h defines RSEQ_SIG > > as 0x53053053, and uses it as an immediate operand to the following > > instruction opcodes (as suggested by Andy Lutomirski): > > > > x86-32: > > - .byte 0x0f, 0x1f, 0x05: nopl > > > > x86-64: > > - .byte 0x0f, 0x1f, 0x05: nopl (%rip) > > > > The current discussion thread on the glibc mailing list leads us towards > > using a trap with uncommon immediate operand, which simplifies integration > > with disassemblers, emulators, makes it easier to debug if the control > > flow gets redirected there by mistake, and is nicer for some architecture's > > speculative execution. ... > Peter Zijlstra suggested to use "invlpg" in user-space, which should generate > a trap. The only concern would be emulators, but ideally they would not try to > decode an instruction that is never executed. This would lead to the following > patch. Any objections/ack ? ... > +/* > + * RSEQ_SIG is used with the following privileged instructions, which trap > in user-space: > + * x86-32:0f 01 3d 53 30 05 53 invlpg 0x53053053 > + * x86-64:0f 01 3d 53 30 05 53 invlpg 0x53053053(%rip) > + */ > #define RSEQ_SIG 0x53053053 On x86, you have to worry about what happens if control flow gets redirected to an arbitrary byte address. The proposed sequence `0f 01 3d 53 30 05 53` is a trap instruction if control lands seven bytes before the beginning of the abort handler, but if it lands anywhere _else_ within the marker sequence, you get one of these instruction sequences, none of which trap, all but one of which will corrupt the process state, and three of which will consume three bytes from the beginning of the abort handler's code, continuing execution with a misaligned PC: 01 3d 53 30 05 53add %edi,0x53053053(%rip) 3d 53 30 05 53 cmp $0x53053053,%eax 53 30 05 53 XX XX XX push %rbx; xor %al,0xXX78(%rip) 30 05 53 XX XX XXxor %al,0xXX78(%rip) 05 53 XX XX XX add $0xXX53,%eax 53 push %rbx So I'm going to suggest instead the four-byte sequence CD CF CD CF. That's INT $0xCF if control lands either two or four bytes before the beginning of the abort handler, and IRET if it lands one or three bytes before. I believe both of these possibilities are currently also forbidden in user mode. It doesn't need to be longer, does it? zw
[PATCH] staging: rtl8192e: remove a blank line
Fix the checkpath error:
CHECK: Blank lines aren't necessary after an open brace '{'
Signed-off-by: Daniel Junho
---
drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c
b/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c
index 467287ae6..b2ef3462e 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_cmdpkt.c
@@ -20,7 +20,6 @@
bool rtl92e_send_cmd_pkt(struct net_device *dev, u32 type, const void *data,
u32 len)
{
-
boolrt_status = true;
struct r8192_priv *priv = rtllib_priv(dev);
u16 frag_length = 0, frag_offset = 0;
--
2.19.1
Re: kernel BUG at fs/inode.c:LINE!
On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> Bisection is inconclusive: the first bad commit could be any of:
[snip the useless pile]
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15e1fc2b20
> start commit: [unknown
> git tree: linux-next
> dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
If I'm not misreading the "crash report" there, it has injected an allocation
failure in dentry allocation in d_make_root() from autofs_fill_super() (
root_inode = autofs_get_inode(s, S_IFDIR | 0755);
root = d_make_root(root_inode);
) which has triggered iput() on the inode passed to d_make_root() (as it ought
to). At which point it stepped into some BUG_ON() in fs/inode.c, but I've
no idea which one it is - line numbers do not match anything in linux-next
or in mainline. Reported line 1566 is
if (inode->i_nlink && (inode->i_state & I_DIRTY_TIME)) {
in all of them; as the matter of fact, the diff in fs/inode.c between
-next and mainline is empty.
There is a BUG_ON() several lines prior, and in 4.20 it used to be line 1566,
so _probably_ that's what it is. With that assumption, it's
BUG_ON(inode->i_state & I_CLEAR);
IOW, we'd got I_CLEAR in the inode passed to d_make_root() there. Which
should not happen - the inode must have come from new_inode(), which
gets it from new_inode_pseudo(), which zeroes ->i_state. And I_CLEAR
is set only in clear_inode(). For autofs inodes that can come only
from autofs_evict_inode(), called as ->evict() from evict_inode().
Which should never ever be called for inode with positive ->i_count...
It might be memory corruption; it might be a dangling inode pointer
somewhere, it might be something else.
To get any further we really need a confirmation of the identity of
triggered BUG_ON().
As an aside, your "sample crash reports" would've been much more useful if
they went with commit SHA1 in question, especially when they contain line
numbers.
Re: [PATCH v2 17/21] drivers: Remove explicit invocations of mmiowb()
Will Deacon's on April 9, 2019 11:46 pm: > Hi Nick, > > On Tue, Apr 09, 2019 at 07:00:52PM +1000, Nicholas Piggin wrote: >> Linus Torvalds's on April 6, 2019 1:50 am: >> > On Fri, Apr 5, 2019 at 4:01 AM Will Deacon wrote: >> >> >> >> mmiowb() is now implied by spin_unlock() on architectures that require >> >> it, so there is no reason to call it from driver code. This patch was >> >> generated using coccinelle: >> >> >> >> @mmiowb@ >> >> @@ >> >> - mmiowb(); >> > >> > So I love the patch series, and think we should just do it, but I do >> > wonder if some of the drivers involved end up relying on memory >> > ordering things (store_release -> load_aquire) and IO ordering rather >> > than using locking... >> >> Hopefully the convention that smp_ prefix does not work for MMIO >> ordering helps there. Drivers relying on that would be broken today >> on powerpc, at least. >> >> > Wouldn't such use now be broken on ia64 SN platforms? Do we care? >> >> Hopefully not too much, what changed since last thread? :) >> >> > So it might be worth noting that a lot of the mmiowb()s here weren't >> > paired with spin_unlock? >> >> I repeat myself, but the correct change is for ia64 to #define wmb to >> mmiowb, then nothing is silently broken, nothing has to be noted, and >> nobody has to care. The ia64/sn2 platform will run a little slower >> that's all. > > That's certainly something for the ia64 maintainers to consider, if they > care about this behaviour. I still have hope that we'll drop ia64 in the > near future :) Well we don't need to for this reason, at least. Wouldn't cost architecture independent code anything. I don't have much opinion about it, but Itaniums of course are still being sold and the latest chip released in 2017. The last Itanium Altix seems more than 10 years old though so it might be reasonable to remove sn2 (if it's causing a big headache). > >> But deliberately breaking sn2 I guess is implicitly acknowledging the >> same end result that I wanted, so fine. >> >> I think it might be an idea to remove all the mmiowb() that obviously >> come before spin_unlock in one big patch, but then submit the rest >> individually to driver maintainers. I could do that rather than ask >> more work from Will, if he and you agree. > > That's an option, I suppose, but I'd much rather just kill off mmiowb() in > one fell swoop and be done with it. I've added the following message to > the commit of the coccinelle patch so any breakage should be easily > rectified: > > | NOTE: mmiowb() has only ever guaranteed ordering in conjunction with > | spin_unlock(). However, pairing each mmiowb() removal in this patch > | with the corresponding call to spin_unlock() is not at all trivial, > | so there is a small chance that this change may regress any drivers > | incorrectly relying on mmiowb() to order MMIO writes between CPUs using > | lock-free synchronisation. If you've ended up bisecting to this commit, > | you can reintroduce the mmiowb() calls using wmb() instead, which should > | restore the old behaviour on all architectures other than some esoteric > | ia64 systems. > > That way we don't have to worry about the long tail of commits removing > undocumented, dangling barriers. > > It's not like we're losing the information about where the mmiowb()s used to > be, so it should be easy to address any fallout (but I'm not really expecting > anything significant, to be honest with you). Well if you feel strongly about it I don't object. Thanks, Nick
Collaboration
Good day. I am D C Johnston, a broker working with Sikhombo Wealth Services. We are a wealth management company based in South Africa. I am contacting you because one of my high profile clients is interested in investing in your country and has asked me to look for individuals and companies with interesting business ideas and companies that he can invest in. He wants to expand his portfolio and has interest in investing a substantial amount of revenue abroad. I got your contact when searching the internet through the directory enquiries and I believe that my client will be interested in working with you. As you can imagine, we have not had any prior communication before so I will be keeping the details to a minimum until I get a confirmation from you that you are interested in this proposal. I will then give you more details upon receiving your positive response. Please provide your direct telephone number as well so that I can give you a call to discuss further. Best regards D C Johnston Sikhombo Wealth Services
linux-next: manual merge of the printk tree with Linus' tree
Hi all,
Today's linux-next merge of the printk tree got a conflict in:
include/trace/events/sunrpc.h
between commit:
6f701383368d ("SUNRPC: Display symbolic flag names in RPC trace events")
from Linus' tree and commit:
d75f773c86a2 ("treewide: Switch printk users from %pf and %pF to %ps and %pS,
respectively")
from the printk tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/trace/events/sunrpc.h
index 7e899e635d33,7b8b987d332e..
--- a/include/trace/events/sunrpc.h
+++ b/include/trace/events/sunrpc.h
@@@ -146,10 -102,10 +146,10 @@@ DECLARE_EVENT_CLASS(rpc_task_running
__entry->flags = task->tk_flags;
),
- TP_printk("task:%u@%d flags=%s runstate=%s status=%d action=%pf",
- TP_printk("task:%u@%d flags=%4.4x state=%4.4lx status=%d action=%ps",
++ TP_printk("task:%u@%d flags=%s runstate=%s status=%d action=%ps",
__entry->task_id, __entry->client_id,
- __entry->flags,
- __entry->runstate,
+ rpc_show_task_flags(__entry->flags),
+ rpc_show_runstate(__entry->runstate),
__entry->status,
__entry->action
)
pgp2rYH6ARPzC.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/1] Smack: Create smack_rule cache to optimize memory usage
On 3/14/2019 2:06 AM, Vishal Goel wrote:
This patch allows for small memory optimization by creating the
kmem cache for "struct smack_rule" instead of using kzalloc.
For adding new smack rule, kzalloc is used to allocate the memory
for "struct smack_rule". kzalloc will always allocate 32 or 64 bytes
for 1 structure depending upon the kzalloc cache sizes available in
system. Although the size of structure is 20 bytes only, resulting
in memory wastage per object in the default pool.
For e.g., if there are 2 rules, then it will save 240KB(2*12)
which is crucial for small memory targets.
Signed-off-by: Vishal Goel
Signed-off-by: Amit Sahrawat
I have taken this patch in for
https://github.com/cschaufler/next-smack.git#smack-for-5.2
---
security/smack/smack.h | 1 +
security/smack/smack_lsm.c | 12 ++--
security/smack/smackfs.c | 2 +-
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/security/smack/smack.h b/security/smack/smack.h
index 6a71fc7..a5d7461 100644
--- a/security/smack/smack.h
+++ b/security/smack/smack.h
@@ -354,6 +354,7 @@ int smk_tskacc(struct task_smack *, struct smack_known *,
#define SMACK_HASH_SLOTS 16
extern struct hlist_head smack_known_hash[SMACK_HASH_SLOTS];
+extern struct kmem_cache *smack_rule_cache;
/*
* Is the directory transmuting?
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 319add3..16b6cf5 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -56,6 +56,7 @@
static LIST_HEAD(smk_ipv6_port_list);
#endif
static struct kmem_cache *smack_inode_cache;
+struct kmem_cache *smack_rule_cache;
int smack_enabled;
static const match_table_t smk_mount_tokens = {
@@ -349,7 +350,7 @@ static int smk_copy_rules(struct list_head *nhead, struct
list_head *ohead,
int rc = 0;
list_for_each_entry_rcu(orp, ohead, list) {
- nrp = kzalloc(sizeof(struct smack_rule), gfp);
+ nrp = kmem_cache_zalloc(smack_rule_cache, gfp);
if (nrp == NULL) {
rc = -ENOMEM;
break;
@@ -1995,7 +1996,7 @@ static void smack_cred_free(struct cred *cred)
list_for_each_safe(l, n, >smk_rules) {
rp = list_entry(l, struct smack_rule, list);
list_del(>list);
- kfree(rp);
+ kmem_cache_free(smack_rule_cache, rp);
}
kfree(tsp);
}
@@ -4788,10 +4789,17 @@ static __init int smack_init(void)
if (!smack_inode_cache)
return -ENOMEM;
+ smack_rule_cache = KMEM_CACHE(smack_rule, 0);
+ if (!smack_rule_cache) {
+ kmem_cache_destroy(smack_inode_cache);
+ return -ENOMEM;
+ }
+
tsp = new_task_smack(_known_floor, _known_floor,
GFP_KERNEL);
if (tsp == NULL) {
kmem_cache_destroy(smack_inode_cache);
+ kmem_cache_destroy(smack_rule_cache);
return -ENOMEM;
}
diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
index 2a8a1f5..d8a0e25 100644
--- a/security/smack/smackfs.c
+++ b/security/smack/smackfs.c
@@ -236,7 +236,7 @@ static int smk_set_access(struct smack_parsed_rule *srp,
}
if (found == 0) {
- sp = kzalloc(sizeof(*sp), GFP_KERNEL);
+ sp = kmem_cache_zalloc(smack_rule_cache, GFP_KERNEL);
if (sp == NULL) {
rc = -ENOMEM;
goto out;
