[PATCH] mm, slab: reschedule cache_reap() on the same CPU
cache_reap() is initially scheduled in start_cpu_timer() via
schedule_delayed_work_on(). But then the next iterations are scheduled via
schedule_delayed_work(), i.e. using WORK_CPU_UNBOUND.
Thus since commit ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on
wq_unbound_cpumask CPUs") there is no guarantee the future iterations will run
on the originally intended cpu, although it's still preferred. I was able to
demonstrate this with /sys/module/workqueue/parameters/debug_force_rr_cpu.
IIUC, it may also happen due to migrating timers in nohz context. As a result,
some cpu's would be calling cache_reap() more frequently and others never.
This patch uses schedule_delayed_work_on() with the current cpu when scheduling
the next iteration.
Signed-off-by: Vlastimil Babka
Fixes: ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on
wq_unbound_cpumask CPUs")
CC:
Cc: Joonsoo Kim
Cc: David Rientjes
Cc: Pekka Enberg
Cc: Christoph Lameter
Cc: Tejun Heo
Cc: Lai Jiangshan
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
---
mm/slab.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/slab.c b/mm/slab.c
index 9095c3945425..a76006aae857 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4074,7 +4074,8 @@ static void cache_reap(struct work_struct *w)
next_reap_node();
out:
/* Set up the next iteration */
- schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_AC));
+ schedule_delayed_work_on(smp_processor_id(), work,
+ round_jiffies_relative(REAPTIMEOUT_AC));
}
void get_slabinfo(struct kmem_cache *cachep, struct slabinfo *sinfo)
--
2.16.3
Re: [tip:x86/urgent] x86/apic: Fix signedness bug in APIC ID validity checks
Hi Thomas, At 04/10/2018 10:51 PM, tip-bot for Li RongQing wrote: [...] x86/apic: Fix signedness bug in APIC ID validity checks The APIC ID as parsed from ACPI MADT is validity checked with the apic->apic_id_valid() callback, which depends on the selected APIC type. For non X2APIC types APIC IDs >= 0xFF are invalid, but values > 0x7FFF Today when I am reading "Intel® 64 Architecture x2APIC Specification", I find that below in chapter 2.4.1: The APIC ID value of _H and the highest value corresponding to the imple-mented bit-width of the local APIC ID register in the system are reserved and cannot be assigned to any logical processor. Seems, _H is also invalid for X2APIC types, Shall we also do the validity check for X2APIC ID? acpi_parse_x2apic() ... /* Ignore invalid ID */ if (apic_id == 0x) return 0; ... Thanks, dou
Re: [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5
Hi Ladislav,
> Am 10.04.2018 um 22:56 schrieb Ladislav Michl :
>
> Hi Nikolaus,
>
> On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
>> Hi,
>> we just started testing the v4.16 kernel and found the
>> device no longer bootable (works with v4.15). It turned
>> out that there was a harmful modification somewhere between
>> v4.15.0 and v4.16-rc1.
>>
>> A git bisect points to this patch:
>
> Well, that's a shame... However, this code is in production for several
> months now,
Well, we could have tested earlier release-candidates...
> so could you, please put 'goto out_copy' if 'buf >= high_memory'
> condition is met, ie:
> --- a/drivers/mtd/nand/onenand/omap2.c
> +++ b/drivers/mtd/nand/onenand/omap2.c
> @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info
> *mtd, int area,
> if (buf >= high_memory) {
> struct page *p1;
>
> + goto out_copy;
> if (((size_t)buf & PAGE_MASK) !=
> ((size_t)(buf + count - 1) & PAGE_MASK))
> goto out_copy;
> and in case it does not help put the same goto at the very beginning of
> omap2_onenand_read_bufferram function and report result?
Yes, works for me. Device boots and I can mount the NAND to inspect the
ubifs.
Only omap2_onenand_write_bufferram has the same problem, but that is to
be expected.
I'll try you new patch now.
>
> Thank you for cooperation,
> ladis
Thanks for the quick reply and analysis.
BR,
Nikolaus
>
>> commit bdaca9345d41fd9420995469d27603ea62054691
>> Author: Ladislav Michl
>> Date: Fri Jan 12 14:16:57 2018 +0100
>>
>> mtd: onenand: omap2: Decouple DMA enabling from INT pin availability
>>
>> INT pin (gpio_irq) is not really needed for DMA but only for notification
>> when a command that needs wait has completed. DMA memcpy can be still used
>> even without gpio_irq available, so enable it unconditionally.
>>
>> Signed-off-by: Ladislav Michl
>> Reviewed-by: Peter Ujfalusi
>> Tested-by: Tony Lindgren
>> Tested-by: Aaro Koskinen
>> Acked-by: Roger Quadros
>> Signed-off-by: Boris Brezillon
>>
>> Kernel panic log is attached which indeed indicates a DMA problem.
>>
>> Note that we have added compatible = "ti,omap2-onenand";
>>
>> Any suggestions, fixes?
>>
>> BR and thanks,
>> Nikolaus Schaller
>>
>>
>>
>> ## Booting kernel from Legacy Image at 8200 ...
>> Image Name: Linux-4.16.0-letux+
>> Image Type: ARM Linux Kernel Image (uncompressed)
>> Data Size:4456744 Bytes = 4.3 MiB
>> Load Address: 80008000
>> Entry Point: 80008000
>> Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 81c0
>> Booting using the fdt blob at 0x81c0
>> Loading Kernel Image ... OK
>> Using Device Tree in place at 81c0, end 81c14a1e
>>
>> Starting kernel ...
>>
>> [0.00] Booting Linux on physical CPU 0x0
>> [0.00] Linux version 4.16.0-letux+ (hns@iMac.local) (gcc version
>> 4.9.2 (GCC)) #2187 SMP PREEMPT Tue Apr 10 16:23:45 CEST 2018
>> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
>> cr=10c5387d
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>> instruction cache
>> [0.00] OF: fdt: Machine model: Goldelico GTA04A5/Letux 2804
>> [0.00] debug: ignoring loglevel setting.
>> [0.00] Memory policy: Data cache writeback
>> [0.00] cma: Reserved 16 MiB at 0xbe80
>> [0.00] On node 0 totalpages: 261632
>> [0.00] Normal zone: 1536 pages used for memmap
>> [0.00] Normal zone: 0 pages reserved
>> [0.00] Normal zone: 196608 pages, LIFO batch:31
>> [0.00] HighMem zone: 65024 pages, LIFO batch:15
>> [0.00] CPU: All CPU(s) started in SVC mode.
>> [0.00] OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
>> [0.00] random: fast init done
>> [0.00] percpu: Embedded 17 pages/cpu @(ptrval) s39744 r8192 d21696
>> u69632
>> [0.00] pcpu-alloc: s39744 r8192 d21696 u69632 alloc=17*4096
>> [0.00] pcpu-alloc: [0] 0
>> [0.00] Built 1 zonelists, mobility grouping on. Total pages: 260096
>> [0.00] Kernel command line: console=ttyO2,115200n8
>> mtdoops.mtddev=omap2.nand ubi.mtd=4 root=/dev/mmcblk0p1 rw
>> rootfstype=ext4,ext3 rootwait console=ttyO2,115200n8 vram=12M
>> omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait
>> twl4030_charger.allow_usb=1 log_buf_len=8M ignore_loglevel earlyprintk
>> [0.00] log_buf_len: 8388608 bytes
>> [0.00] early log buf free: 63924(97%)
>> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288
>> bytes)
>> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>> [0.00] Memory: 1002524K/1046528K available (6169K kernel code, 626K
>> rwdata, 1660K rodata, 1024K init, 218K bss, 27620K reserved, 16384K
>> cma-reserved, 243712K highmem)
>> [
Re: [PATCH 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet
Hi,
On Tue, Apr 10, 2018 at 11:31:29PM +0200, Paul Kocialkowski wrote:
> This adds support for the Ainol AW1, an A20-based 7" tablet from Ainol.
>
> The following board-specific features are supported:
> * LCD panel
> * Backlight
> * USB OTG
> * Buttons
> * Touchscreen (doesn't work without non-free firmware)
> * Accelerometer
> * Battery
>
> The following are untested:
> * Audio output
> * Audio speakers
> * USB via SPCI connector
>
> The following are not supported:
> * Wi-Fi
> * Bluetooth
> * NAND
> * Audio via SPCI connector
>
> Signed-off-by: Paul Kocialkowski
> ---
> arch/arm/boot/dts/Makefile| 1 +
> arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts | 358
> ++
> 2 files changed, 359 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9f7133b6fba0..03bfacebfdbd 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -929,6 +929,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
> sun6i-a31s-sinovoip-bpi-m2.dtb \
> sun6i-a31s-yones-toptech-bs1078-v2.dtb
> dtb-$(CONFIG_MACH_SUN7I) += \
> + sun7i-a20-ainol-aw1.dtb \
> sun7i-a20-bananapi.dtb \
> sun7i-a20-bananapi-m1-plus.dtb \
> sun7i-a20-bananapro.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> new file mode 100644
> index ..697586991aea
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> @@ -0,0 +1,358 @@
> +/*
> + * Copyright 2018 Paul Kocialkowski
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
Can you use an SPDX header instead of the whole license text?
> + */
> +
> +/dts-v1/;
> +#include "sun7i-a20.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "Ainol AW1";
> + compatible = "ainol,ainol-aw1", "allwinner,sun7i-a20";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <&backlight_enable_pin>;
You don't need any of the pinctrl nodes for the GPIOs
> + pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
> + default-brightness-level = <5>;
> + enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
> + };
> +
> + panel: panel {
> + compatible = "innolux,at070tn92";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-supply = <&panel_power>;
> + backlight = <&backlight>;
> +
> + port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #
Re: [PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload
On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote: > stir421x_fw_upload() is never called in atomic context. > > The call chain ending up at stir421x_fw_upload() is: > [1] stir421x_fw_upload() <- stir421x_patch_device() <- irda_usb_probe() > > irda_usb_probe() is set as ".probe" in struct usb_driver. > This function is not called in atomic context. > > Despite never getting called from atomic context, stir421x_fw_upload() > calls mdelay() to busily wait. > This is not necessary and can be replaced with usleep_range() to > avoid busy waiting. > > This is found by a static analysis tool named DCNS written by myself. > And I also manually check it. > > Signed-off-by: Jia-Ju Bai This all looks good (also note the call to usb_control_msg(), which may sleep, just above the mdelay()). Reviewed-by: Johan Hovold Thanks, Johan
Re: [PATCH 2/2] staging: irda: Replace mdelay with usleep_range in irda_usb_probe
On Wed, Apr 11, 2018 at 09:33:55AM +0800, Jia-Ju Bai wrote: > irda_usb_probe() is never called in atomic context. > > irda_usb_probe() is only set as ".probe" in struct usb_driver. > > Despite never getting called from atomic context, irda_usb_probe() > calls mdelay() to busily wait. > This is not necessary and can be replaced with usleep_range() to > avoid busy waiting. > > This is found by a static analysis tool named DCNS written by myself. > And I also manually check it. > > Signed-off-by: Jia-Ju Bai Reviewed-by: Johan Hovold
Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend
On 14/03/18 09:48, Jan Beulich wrote:
On 26.02.18 at 15:08, wrote:
>> @@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled)
>>
>> static void xen_vcpu_notify_restore(void *data)
>> {
>> +if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL))
>> +wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl));
>> +
>> /* Boot processor notified via generic timekeeping_resume() */
>> if (smp_processor_id() == 0)
>> return;
>> @@ -44,7 +52,15 @@ static void xen_vcpu_notify_restore(void *data)
>>
>> static void xen_vcpu_notify_suspend(void *data)
>> {
>> +u64 tmp;
>> +
>> tick_suspend_local();
>> +
>> +if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) {
>> +rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
>> +this_cpu_write(spec_ctrl, tmp);
>> +wrmsrl(MSR_IA32_SPEC_CTRL, 0);
>> +}
>> }
>
> While investigating ways how to do something similar on our old,
> non-pvops kernels I've started wondering if this solution is actually
> correct in all cases. Of course discussing this is complicated by the
> fact that the change there might be a conflict with hasn't landed
> in Linus'es tree yet (see e.g.
> https://patchwork.kernel.org/patch/10153843/ for an upstream
> submission; I haven't been able to find any discussion on that
> patch or why it isn't upstream yet), but we have it in our various
> branches. The potential problem I'm seeing is with the clearing
> and re-setting of SPEC_CTRL around CPUs going idle. While the
> active CPU could have preemption disabled (if that isn't the case
> already), the passive CPUs are - afaict - neither under full control
> of drivers/xen/manage.c:do_suspend() nor excluded yet from
> any further scheduling activity. Hence with code like this (taken
> from one of our branches)
>
> static void mwait_idle(void)
> {
> if (!current_set_polling_and_test()) {
> trace_cpu_idle_rcuidle(1, smp_processor_id());
> if (this_cpu_has(X86_BUG_CLFLUSH_MONITOR)) {
> smp_mb(); /* quirk */
> clflush((void *)¤t_thread_info()->flags);
> smp_mb(); /* quirk */
> }
>
> x86_disable_ibrs();
>
> __monitor((void *)¤t_thread_info()->flags, 0, 0);
> if (!need_resched())
> __sti_mwait(0, 0);
> else
> local_irq_enable();
>
> x86_enable_ibrs();
> ...
>
> the MSR might get set to non-zero again after having been
> cleared by the code your patch adds. I therefore think that the
> only race free solution would be to do the clearing from
> stop-machine context. But maybe I'm overlooking something.
Currently and with the above mentioned patch there is no problem: Xen pv
guests always use default_idle(), so mwait_idle() eventually playing
with MSR_IA32_SPEC_CTRL won't affect us.
In order to ensure that won't change in future default_idle() should
never modify MSR_IA32_SPEC_CTRL. In case something like that would be
required we should rather add another idle function doing that.
Juergen
[GIT PULL] arch/nios2 update for v4.17-rc1
Hi Linus Here is nios2 update for v4.17-rc1. Please consider pulling. Regards Ley Foon The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda: Linux 4.16 (2018-04-01 14:20:27 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2.git tags/nios2-v4.17-rc1 for you to fetch changes up to 3d9644ef9a0f6c3ca0c1bd2aea1d82e7ea0a7f24: nios2: Use read_persistent_clock64() instead of read_persistent_clock() (2018-04-03 00:36:55 +0800) nios2 update for v4.17-rc1 nios2: Use read_persistent_clock64() instead of read_persistent_clock() Baolin Wang (1): nios2: Use read_persistent_clock64() instead of read_persistent_clock() arch/nios2/kernel/time.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Re: [PATCH v2 2/2] MAINTAINERS: add maintainer for Renesas I2C related drivers
Hi Wolfram,
On Tue, Apr 10, 2018 at 9:49 PM, Wolfram Sang wrote:
> From: Wolfram Sang
>
> Intentionally missing i2c-riic here, Chris Brandt will add himself for
> that one later.
I guess that's why you're not adding a catch-all "RENESAS I2C DRIVERS"
section?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] net: dsa: b53: Replace mdelay with msleep in b53_switch_reset_gpio
On 2018/4/11 13:30, Phil Reid wrote: On 11/04/2018 09:51, Jia-Ju Bai wrote: b53_switch_reset_gpio() is never called in atomic context. The call chain ending up at b53_switch_reset_gpio() is: [1] b53_switch_reset_gpio() <- b53_switch_reset() <- b53_reset_switch() <- b53_setup() b53_switch_reset_gpio() is set as ".setup" in struct dsa_switch_ops. This function is not called in atomic context. Despite never getting called from atomic context, b53_switch_reset_gpio() calls mdelay() to busily wait. This is not necessary and can be replaced with msleep() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/net/dsa/b53/b53_common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c index 274f367..e070ff6 100644 --- a/drivers/net/dsa/b53/b53_common.c +++ b/drivers/net/dsa/b53/b53_common.c @@ -597,10 +597,10 @@ static void b53_switch_reset_gpio(struct b53_device *dev) /* Reset sequence: RESET low(50ms)->high(20ms) */ gpio_set_value(gpio, 0); -mdelay(50); +msleep(50); gpio_set_value(gpio, 1); -mdelay(20); +msleep(20); dev->current_page = 0xff; } Would that also imply gpio_set_value could be gpio_set_value_cansleep? Yes, I think gpio_set_value_cansleep() is okay here? Do I need to send a V2 patch to replace gpio_set_value()? Best wishes, Jia-Ju Bai
Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5
Hi Ladislav,
On Wed, 11 Apr 2018 08:26:07 +0200
Ladislav Michl wrote:
> Hi Andreas,
>
> On Wed, Apr 11, 2018 at 06:59:03AM +0200, Andreas Kemnade wrote:
> > Hi Ladis,
> >
> > On Tue, 10 Apr 2018 22:56:43 +0200
> > Ladislav Michl wrote:
> >
> > > Hi Nikolaus,
> > >
> > > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> > > > Hi,
> > > > we just started testing the v4.16 kernel and found the
> > > > device no longer bootable (works with v4.15). It turned
> > > > out that there was a harmful modification somewhere between
> > > > v4.15.0 and v4.16-rc1.
> > > >
> > > > A git bisect points to this patch:
> > >
> > > Well, that's a shame... However, this code is in production for several
> > > months now, so could you, please put 'goto out_copy' if 'buf >=
> > > high_memory'
> > > condition is met, ie:
> > > --- a/drivers/mtd/nand/onenand/omap2.c
> > > +++ b/drivers/mtd/nand/onenand/omap2.c
> > > @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct
> > > mtd_info *mtd, int area,
> > > if (buf >= high_memory) {
> > > struct page *p1;
> > >
> > > + goto out_copy;
> > > if (((size_t)buf & PAGE_MASK) !=
> > > ((size_t)(buf + count - 1) & PAGE_MASK))
> > > goto out_copy;
> >
> > I had the same problem here, and that snippet helps here. ubiattach
> > -p /dev/mtdX does not cause kernel oopses here anymore
>
> It seems reviving old code always comes at a price :-) Could you try
> following patch, so far compile tested only?
> (we'll need to do the same for omap2_onenand_write_bufferram, but
> it sould be enough for testing purposes now)
>
> diff --git a/drivers/mtd/nand/onenand/omap2.c
> b/drivers/mtd/nand/onenand/omap2.c
> index 9c159f0dd9a6..04cefd7a6487 100644
> --- a/drivers/mtd/nand/onenand/omap2.c
> +++ b/drivers/mtd/nand/onenand/omap2.c
> @@ -375,11 +375,12 @@ static int omap2_onenand_read_bufferram(struct mtd_info
> *mtd, int area,
> {
> struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> struct onenand_chip *this = mtd->priv;
> + struct device *dev = &c->pdev->dev;
> dma_addr_t dma_src, dma_dst;
> int bram_offset;
> void *buf = (void *)buffer;
> size_t xtra;
> - int ret;
> + int ret, page_dma = 0;
>
> bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> @@ -389,38 +390,43 @@ static int omap2_onenand_read_bufferram(struct mtd_info
> *mtd, int area,
> if (in_interrupt() || oops_in_progress)
> goto out_copy;
>
> + xtra = count & 3;
> + if (xtra) {
> + count -= xtra;
> + memcpy(buf + count, this->base + bram_offset + count, xtra);
> + }
> +
> + /* Handle vmalloc address */
> if (buf >= high_memory) {
> - struct page *p1;
> + struct page *page;
>
> if (((size_t)buf & PAGE_MASK) !=
> ((size_t)(buf + count - 1) & PAGE_MASK))
> goto out_copy;
> - p1 = vmalloc_to_page(buf);
> - if (!p1)
> + page = vmalloc_to_page(buf);
Not sure this approach is safe on all archs: if the cache is VIVT or
VIPT, you may have several entries pointing to the same phys page, and
then, when dma_map_page() does its cache maintenance operations, it's
only taking one of these entries into account.
In other parts of the MTD subsystem, we tend to not do DMA on buffers
that have been vmalloc-ed.
You can do something like
if (virt_addr_valid(buf))
/* Use DMA */
else
/*
* Do not use DMA, or use a bounce buffer
* allocated with kmalloc
*/
Regards,
Boris
> + if (!page)
> goto out_copy;
> - buf = page_address(p1) + ((size_t)buf & ~PAGE_MASK);
> - }
> -
> - xtra = count & 3;
> - if (xtra) {
> - count -= xtra;
> - memcpy(buf + count, this->base + bram_offset + count, xtra);
> + page_dma = 1;
> + dma_dst = dma_map_page(dev, page, (size_t) buf & ~PAGE_MASK,
> +count, DMA_FROM_DEVICE);
> + } else {
> + dma_dst = dma_map_single(dev, buf, count, DMA_FROM_DEVICE);
> }
> -
> dma_src = c->phys_base + bram_offset;
> - dma_dst = dma_map_single(&c->pdev->dev, buf, count, DMA_FROM_DEVICE);
> - if (dma_mapping_error(&c->pdev->dev, dma_dst)) {
> - dev_err(&c->pdev->dev,
> - "Couldn't DMA map a %d byte buffer\n",
> - count);
> +
> + if (dma_mapping_error(dev, dma_dst)) {
> + dev_err(dev, "Couldn't DMA map a %d byte buffer\n", count);
> goto out_copy;
> }
>
> ret = omap2_on
Re: [PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload
On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote: > stir421x_fw_upload() is never called in atomic context. > > The call chain ending up at stir421x_fw_upload() is: > [1] stir421x_fw_upload() <- stir421x_patch_device() <- irda_usb_probe() > > irda_usb_probe() is set as ".probe" in struct usb_driver. > This function is not called in atomic context. > > Despite never getting called from atomic context, stir421x_fw_upload() > calls mdelay() to busily wait. > This is not necessary and can be replaced with usleep_range() to > avoid busy waiting. > > This is found by a static analysis tool named DCNS written by myself. > And I also manually check it. > > Signed-off-by: Jia-Ju Bai > --- > drivers/staging/irda/drivers/irda-usb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Please, at the very least, work off of Linus's tree. There is no drivers/staging/irda/ anymore :) thanks, greg k-h
[PATCH] KVM: X86: fix incorrect reference of trace_kvm_pi_irte_update
In arch/x86/kvm/trace.h, this function is declared as host_irq the
first input, and vcpu_id the second, instead of otherwise.
Signed-off-by: hu huajun
---
arch/x86/kvm/svm.c | 5 ++---
arch/x86/kvm/vmx.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index be9c839..f4e9fb4 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5118,9 +5118,8 @@ static int svm_update_pi_irte(struct kvm *kvm, unsigned
int host_irq,
}
if (!ret && svm) {
- trace_kvm_pi_irte_update(svm->vcpu.vcpu_id,
-host_irq, e->gsi,
-vcpu_info.vector,
+ trace_kvm_pi_irte_update(host_irq, svm->vcpu.vcpu_id,
+e->gsi, vcpu_info.vector,
vcpu_info.pi_desc_addr, set);
}
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index f0fd50b..86fd775 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -12204,7 +12204,7 @@ static int vmx_update_pi_irte(struct kvm *kvm, unsigned
int host_irq,
vcpu_info.pi_desc_addr = __pa(vcpu_to_pi_desc(vcpu));
vcpu_info.vector = irq.vector;
- trace_kvm_pi_irte_update(vcpu->vcpu_id, host_irq, e->gsi,
+ trace_kvm_pi_irte_update(host_irq, vcpu->vcpu_id, e->gsi,
vcpu_info.vector, vcpu_info.pi_desc_addr, set);
if (set)
--
1.8.3.1
Re: [PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload
On 2018/4/11 14:41, Greg KH wrote: On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote: stir421x_fw_upload() is never called in atomic context. The call chain ending up at stir421x_fw_upload() is: [1] stir421x_fw_upload() <- stir421x_patch_device() <- irda_usb_probe() irda_usb_probe() is set as ".probe" in struct usb_driver. This function is not called in atomic context. Despite never getting called from atomic context, stir421x_fw_upload() calls mdelay() to busily wait. This is not necessary and can be replaced with usleep_range() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/staging/irda/drivers/irda-usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Please, at the very least, work off of Linus's tree. There is no drivers/staging/irda/ anymore :) Okay, sorry. Could you please recommend me a right tree or its git address? Best wishes, Jia-Ju Bai
Re: [PATCH v2 2/2] MAINTAINERS: add maintainer for Renesas I2C related drivers
> I guess that's why you're not adding a catch-all "RENESAS I2C DRIVERS" > section? Yes. signature.asc Description: PGP signature
[PATCH v8 0/6] optimize memblock_next_valid_pfn and early_pfn_valid on arm and arm64
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") tried to optimize the loop in memmap_init_zone(). But
there is still some room for improvement.
Patch 1 introduce new config to make codes more generic
Patch 2 remain the memblock_next_valid_pfn on arm and arm64
Patch 3 optimizes the memblock_next_valid_pfn()
Patch 4~6 optimizes the early_pfn_valid()
As for the performance improvement, after this set, I can see the time
overhead of memmap_init() is reduced from 41313 us to 24389 us in my
armv8a server(QDF2400 with 96G memory).
Without this patchset:
[ 117.113677] before memmap_init
[ 117.118195] after memmap_init
>>> memmap_init takes 4518 us
[ 117.121446] before memmap_init
[ 117.154992] after memmap_init
>>> memmap_init takes 33546 us
[ 117.158241] before memmap_init
[ 117.161490] after memmap_init
>>> memmap_init takes 3249 us
>>> totally takes 41313 us
With this patchset:
[ 123.222962] before memmap_init
[ 123.226819] after memmap_init
>>> memmap_init takes 3857
[ 123.230070] before memmap_init
[ 123.247354] after memmap_init
>>> memmap_init takes 17284
[ 123.250604] before memmap_init
[ 123.253852] after memmap_init
>>> memmap_init takes 3248
>>> totally takes 24389 us
Attached the memblock region information in my server.
[ 86.956758] Zone ranges:
[ 86.959452] DMA [mem 0x0020-0x]
[ 86.966041] Normal [mem 0x0001-0x0017]
[ 86.972631] Movable zone start for each node
[ 86.977179] Early memory node ranges
[ 86.980985] node 0: [mem 0x0020-0x0021]
[ 86.987666] node 0: [mem 0x0082-0x0307]
[ 86.994348] node 0: [mem 0x0308-0x0308]
[ 87.001029] node 0: [mem 0x0309-0x031f]
[ 87.007710] node 0: [mem 0x0320-0x033f]
[ 87.014392] node 0: [mem 0x0341-0x0563]
[ 87.021073] node 0: [mem 0x0564-0x0567]
[ 87.027754] node 0: [mem 0x0568-0x056d]
[ 87.034435] node 0: [mem 0x056e-0x086f]
[ 87.041117] node 0: [mem 0x0870-0x0871]
[ 87.047798] node 0: [mem 0x0872-0x0894]
[ 87.054479] node 0: [mem 0x0895-0x08ba]
[ 87.061161] node 0: [mem 0x08bb-0x08bc]
[ 87.067842] node 0: [mem 0x08bd-0x08c4]
[ 87.074524] node 0: [mem 0x08c5-0x08e2]
[ 87.081205] node 0: [mem 0x08e3-0x08e4]
[ 87.087886] node 0: [mem 0x08e5-0x08fc]
[ 87.094568] node 0: [mem 0x08fd-0x0910]
[ 87.101249] node 0: [mem 0x0911-0x092e]
[ 87.107930] node 0: [mem 0x092f-0x0930]
[ 87.114612] node 0: [mem 0x0931-0x0963]
[ 87.121293] node 0: [mem 0x0964-0x0e61]
[ 87.127975] node 0: [mem 0x0e62-0x0e64]
[ 87.134657] node 0: [mem 0x0e65-0x0fff]
[ 87.141338] node 0: [mem 0x1080-0x17fe]
[ 87.148019] node 0: [mem 0x1c00-0x1c00]
[ 87.154701] node 0: [mem 0x1c01-0x1c7f]
[ 87.161383] node 0: [mem 0x1c81-0x7efb]
[ 87.168064] node 0: [mem 0x7efc-0x7efd]
[ 87.174746] node 0: [mem 0x7efe-0x7efe]
[ 87.181427] node 0: [mem 0x7eff-0x7eff]
[ 87.188108] node 0: [mem 0x7f00-0x0017]
[ 87.194791] Initmem setup node 0 [mem 0x0020-0x0017]
Changelog:
V8: - introduce new config and move generic code to early_pfn.h
- optimize memblock_next_valid_pfn as suggested by Matthew Wilcox
V7: - fix i386 compilation error. refine the commit description
V6: - simplify the codes, move arm/arm64 common codes to one file.
- refine patches as suggested by Danial Vacek and Ard Biesheuvel
V5: - further refining as suggested by Danial Vacek. Make codes
arm/arm64 more arch specific
V4: - refine patches as suggested by Danial Vacek and Wei Yang
- optimized on arm besides arm64
V3: - fix 2 issues reported by kbuild test robot
V2: - rebase to mmotm latest
- remain memblock_next_valid_pfn on arm64
- refine memblock_search_pfn_regions and pfn_valid_region
Jia He (6):
arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID
mm: page_alloc: remain memblock_next_valid_pfn() on arm/arm64
arm: arm64: page_alloc: reduce unnecessary binary search in
memblock_next_valid_pfn()
mm/memblock: introduce memblock_search_pfn_regions()
arm: arm64: introduce pfn_valid_region()
mm: page_alloc: reduce unne
[PATCH v8 1/6] arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID
Make CONFIG_HAVE_MEMBLOCK_PFN_VALID a config option so it can move memblock_next_valid_pfn to generic code file. arm/arm64 can benefit from this booting time improvement. Signed-off-by: Jia He --- arch/arm/Kconfig | 4 arch/arm64/Kconfig | 4 mm/Kconfig | 3 +++ 3 files changed, 11 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 51c8df5..77bc1bb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1637,6 +1637,10 @@ config ARCH_SELECT_MEMORY_MODEL config HAVE_ARCH_PFN_VALID def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM +config HAVE_MEMBLOCK_PFN_VALID + def_bool y + depends on HAVE_ARCH_PFN_VALID + config HAVE_GENERIC_GUP def_bool y depends on ARM_LPAE diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index c9a7e9e..f374203 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -747,6 +747,10 @@ config ARCH_SELECT_MEMORY_MODEL config HAVE_ARCH_PFN_VALID def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM +config HAVE_MEMBLOCK_PFN_VALID + def_bool y + depends on HAVE_ARCH_PFN_VALID + config HW_PERF_EVENTS def_bool y depends on ARM_PMU diff --git a/mm/Kconfig b/mm/Kconfig index c782e8f..c53ac38 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -137,6 +137,9 @@ config HAVE_MEMBLOCK_NODE_MAP config HAVE_MEMBLOCK_PHYS_MAP bool +config HAVE_MEMBLOCK_PFN_VALID + bool + config HAVE_GENERIC_GUP bool -- 2.7.4
[PATCH v8 2/6] mm: page_alloc: remain memblock_next_valid_pfn() on arm/arm64
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But it causes
possible panic bug. So Daniel Vacek reverted it later.
But as suggested by Daniel Vacek, it is fine to using memblock to skip
gaps and finding next valid frame with CONFIG_HAVE_ARCH_PFN_VALID.
On arm and arm64, memblock is used by default. But generic version of
pfn_valid() is based on mem sections and memblock_next_valid_pfn() does
not always return the next valid one but skips more resulting in some
valid frames to be skipped (as if they were invalid). And that's why
kernel was eventually crashing on some !arm machines.
And as verified by Eugeniu Rosca, arm can benifit from commit
b92df1de5d28. So remain the memblock_next_valid_pfn on arm/arm64 and
move the related codes to one file include/linux/arm96_common.h
Suggested-by: Daniel Vacek
Signed-off-by: Jia He
---
arch/arm/mm/init.c| 1 +
arch/arm64/mm/init.c | 1 +
include/linux/early_pfn.h | 34 ++
include/linux/mmzone.h| 11 +++
mm/page_alloc.c | 5 -
5 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 include/linux/early_pfn.h
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index a1f11a7..de225a2 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 00e7b90..913c327 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/include/linux/early_pfn.h b/include/linux/early_pfn.h
new file mode 100644
index 000..1b001c7
--- /dev/null
+++ b/include/linux/early_pfn.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2018 HXT-semitech Corp. */
+#ifndef __EARLY_PFN_H
+#define __EARLY_PFN_H
+#ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
+ulong __init_memblock memblock_next_valid_pfn(ulong pfn)
+{
+ struct memblock_type *type = &memblock.memory;
+ unsigned int right = type->cnt;
+ unsigned int mid, left = 0;
+ phys_addr_t addr = PFN_PHYS(++pfn);
+
+ do {
+ mid = (right + left) / 2;
+
+ if (addr < type->regions[mid].base)
+ right = mid;
+ else if (addr >= (type->regions[mid].base +
+ type->regions[mid].size))
+ left = mid + 1;
+ else {
+ /* addr is within the region, so pfn is valid */
+ return pfn;
+ }
+ } while (left < right);
+
+ if (right == type->cnt)
+ return -1UL;
+ else
+ return PHYS_PFN(type->regions[right].base);
+}
+EXPORT_SYMBOL(memblock_next_valid_pfn);
+#endif /*CONFIG_HAVE_MEMBLOCK_PFN_VALID*/
+#endif /*__EARLY_PFN_H*/
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index d797716..c40297d 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1245,6 +1245,8 @@ static inline int pfn_valid(unsigned long pfn)
return 0;
return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
}
+
+#define next_valid_pfn(pfn)(pfn + 1)
#endif
static inline int pfn_present(unsigned long pfn)
@@ -1270,6 +1272,10 @@ static inline int pfn_present(unsigned long pfn)
#endif
#define early_pfn_valid(pfn) pfn_valid(pfn)
+#ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
+extern ulong memblock_next_valid_pfn(ulong pfn);
+#define next_valid_pfn(pfn)memblock_next_valid_pfn(pfn)
+#endif
void sparse_init(void);
#else
#define sparse_init() do {} while (0)
@@ -1291,6 +1297,11 @@ struct mminit_pfnnid_cache {
#define early_pfn_valid(pfn) (1)
#endif
+/* fallback to default defitions*/
+#ifndef next_valid_pfn
+#define next_valid_pfn(pfn)(pfn + 1)
+#endif
+
void memory_present(int nid, unsigned long start, unsigned long end);
unsigned long __init node_memmap_size_bytes(int, unsigned long, unsigned long);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c19f5ac..bab8e1a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5483,8 +5483,11 @@ void __meminit memmap_init_zone(unsigned long size, int
nid, unsigned long zone,
if (context != MEMMAP_EARLY)
goto not_early;
- if (!early_pfn_valid(pfn))
+ if (!early_pfn_valid(pfn)) {
+ pfn = next_valid_pfn(pfn) - 1;
continue;
+ }
+
if (!early_pfn_in_nid(pfn, nid))
continue;
if (!update_defer_init(pgdat, pfn, end_pfn, &nr_initialised))
--
2.7.4
[PATCH v8 4/6] mm/memblock: introduce memblock_search_pfn_regions()
This api is to find the memory region index of input pfn. With this
helper, we can improve the loop in early_pfn_valid by recording last
region index. If current pfn and last pfn are in the same memory
region, we needn't do the unnecessary binary searches because the
result of memblock_is_nomap is the same for whole memory region.
Signed-off-by: Jia He
---
include/linux/memblock.h | 2 ++
mm/memblock.c| 9 +
2 files changed, 11 insertions(+)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 0257aee..a0127b3 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -203,6 +203,8 @@ void __next_mem_pfn_range(int *idx, int nid, unsigned long
*out_start_pfn,
i >= 0; __next_mem_pfn_range(&i, nid, p_start, p_end, p_nid))
#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
+int memblock_search_pfn_regions(unsigned long pfn);
+
/**
* for_each_free_mem_range - iterate through free memblock areas
* @i: u64 used as loop variable
diff --git a/mm/memblock.c b/mm/memblock.c
index ba7c878..0f4004c 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1617,6 +1617,15 @@ static int __init_memblock memblock_search(struct
memblock_type *type, phys_addr
return -1;
}
+/* search memblock with the input pfn, return the region idx */
+int __init_memblock memblock_search_pfn_regions(unsigned long pfn)
+{
+ struct memblock_type *type = &memblock.memory;
+ int mid = memblock_search(type, PFN_PHYS(pfn));
+
+ return mid;
+}
+
bool __init memblock_is_reserved(phys_addr_t addr)
{
return memblock_search(&memblock.reserved, addr) != -1;
--
2.7.4
[PATCH v8 3/6] arm: arm64: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn()
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But there is
still some room for improvement. E.g. if pfn and pfn+1 are in the same
memblock region, we can simply pfn++ instead of doing the binary search
in memblock_next_valid_pfn. Furthermore, if the pfn is in a *gap* of two
memory region, skip to next region directly if possible.
Signed-off-by: Jia He
---
include/linux/early_pfn.h | 37 +
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/include/linux/early_pfn.h b/include/linux/early_pfn.h
index 1b001c7..f9e40c3 100644
--- a/include/linux/early_pfn.h
+++ b/include/linux/early_pfn.h
@@ -3,31 +3,52 @@
#ifndef __EARLY_PFN_H
#define __EARLY_PFN_H
#ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
+static int early_region_idx __init_memblock = -1;
ulong __init_memblock memblock_next_valid_pfn(ulong pfn)
{
struct memblock_type *type = &memblock.memory;
- unsigned int right = type->cnt;
- unsigned int mid, left = 0;
+ struct memblock_region *regions = type->regions;
+ uint right = type->cnt;
+ uint mid, left = 0;
+ ulong start_pfn, end_pfn, next_start_pfn;
phys_addr_t addr = PFN_PHYS(++pfn);
+ /* fast path, return pfn+1 if next pfn is in the same region */
+ if (early_region_idx != -1) {
+ start_pfn = PFN_DOWN(regions[early_region_idx].base);
+ end_pfn = PFN_DOWN(regions[early_region_idx].base +
+ regions[early_region_idx].size);
+
+ if (pfn >= start_pfn && pfn < end_pfn)
+ return pfn;
+
+ early_region_idx++;
+ next_start_pfn = PFN_DOWN(regions[early_region_idx].base);
+
+ if (pfn >= end_pfn && pfn <= next_start_pfn)
+ return next_start_pfn;
+ }
+
+ /* slow path, do the binary searching */
do {
mid = (right + left) / 2;
- if (addr < type->regions[mid].base)
+ if (addr < regions[mid].base)
right = mid;
- else if (addr >= (type->regions[mid].base +
- type->regions[mid].size))
+ else if (addr >= (regions[mid].base + regions[mid].size))
left = mid + 1;
else {
- /* addr is within the region, so pfn is valid */
+ early_region_idx = mid;
return pfn;
}
} while (left < right);
if (right == type->cnt)
return -1UL;
- else
- return PHYS_PFN(type->regions[right].base);
+
+ early_region_idx = right;
+
+ return PHYS_PFN(regions[early_region_idx].base);
}
EXPORT_SYMBOL(memblock_next_valid_pfn);
#endif /*CONFIG_HAVE_MEMBLOCK_PFN_VALID*/
--
2.7.4
[PATCH v8 5/6] arm: arm64: introduce pfn_valid_region()
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But there is
still some room for improvement. E.g. in early_pfn_valid(), we can record
the last returned memblock region. If current pfn and last pfn are in the
same memory region, we needn't do the unnecessary binary searches because
memblock_is_nomap is the same result for whole memory region.
Signed-off-by: Jia He
---
include/linux/early_pfn.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/linux/early_pfn.h b/include/linux/early_pfn.h
index f9e40c3..9609391 100644
--- a/include/linux/early_pfn.h
+++ b/include/linux/early_pfn.h
@@ -51,5 +51,29 @@ ulong __init_memblock memblock_next_valid_pfn(ulong pfn)
return PHYS_PFN(regions[early_region_idx].base);
}
EXPORT_SYMBOL(memblock_next_valid_pfn);
+
+int pfn_valid_region(ulong pfn)
+{
+ ulong start_pfn, end_pfn;
+ struct memblock_type *type = &memblock.memory;
+ struct memblock_region *regions = type->regions;
+
+ if (early_region_idx != -1) {
+ start_pfn = PFN_DOWN(regions[early_region_idx].base);
+ end_pfn = PFN_DOWN(regions[early_region_idx].base +
+ regions[early_region_idx].size);
+
+ if (pfn >= start_pfn && pfn < end_pfn)
+ return !memblock_is_nomap(
+ ®ions[early_region_idx]);
+ }
+
+ early_region_idx = memblock_search_pfn_regions(pfn);
+ if (early_region_idx == -1)
+ return false;
+
+ return !memblock_is_nomap(®ions[early_region_idx]);
+}
+EXPORT_SYMBOL(pfn_valid_region);
#endif /*CONFIG_HAVE_MEMBLOCK_PFN_VALID*/
#endif /*__EARLY_PFN_H*/
--
2.7.4
[PATCH v8 6/6] mm: page_alloc: reduce unnecessary binary search in early_pfn_valid()
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But there is
still some room for improvement. E.g. in early_pfn_valid(), if pfn and
pfn+1 are in the same memblock region, we can record the last returned
memblock region index and check whether pfn++ is still in the same
region.
Currently it only improve the performance on arm/arm64 and will have no
impact on other arches.
For the performance improvement, after this set, I can see the time
overhead of memmap_init() is reduced from 41313 us to 24345 us in my
armv8a server(QDF2400 with 96G memory).
Signed-off-by: Jia He
---
include/linux/mmzone.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index c40297d..426db40 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1271,11 +1271,16 @@ static inline int pfn_present(unsigned long pfn)
#define pfn_to_nid(pfn)(0)
#endif
-#define early_pfn_valid(pfn) pfn_valid(pfn)
#ifdef CONFIG_HAVE_MEMBLOCK_PFN_VALID
extern ulong memblock_next_valid_pfn(ulong pfn);
#define next_valid_pfn(pfn)memblock_next_valid_pfn(pfn)
-#endif
+
+extern int pfn_valid_region(ulong pfn);
+#define early_pfn_valid(pfn) pfn_valid_region(pfn)
+#else
+#define early_pfn_valid(pfn)pfn_valid(pfn)
+#endif /*CONFIG_HAVE_ARCH_PFN_VALID*/
+
void sparse_init(void);
#else
#define sparse_init() do {} while (0)
--
2.7.4
Re: [PATCH] swiotlb: Fix unexpected swiotlb_alloc_coherent() failures
On Tue, 10 Apr 2018 20:10:20 +0200, Christoph Hellwig wrote: > > On Tue, Apr 10, 2018 at 06:50:04PM +0100, Robin Murphy wrote: > > In the first one, the machine appears to have enough RAM that most of it is > > beyond the device's 36-bit DMA mask, thus it's fairly likely for the > > initial direct alloc to come back with something unsuitable. > > But we should try a GFP_DMA32 allocation first, so this is a bit > surprising. Hm, do we really try that? Through a quick glance, dma_alloc_coherent_gfp_flags() gives GFP_DMA32 only when coherent mask <= DMA_BIT_MASK(32); in the case of iwlwifi, it's 36bit, so GFP_DMA isn't set. We had a fallback allocation with GFP_DMA32 in the past, but this seems gone long time ago along with cleanups (commit c647c3bb2d16). But I haven't followed about this topic for long time, so I might have missed obviously... thanks, Takashi
Re: [PATCH] bug.h: Work around GCC PR82365 in BUG()
On Wed, Apr 11, 2018 at 12:48 AM, James Hogan wrote:
> Hi Arnd,
>
> On Tue, Dec 19, 2017 at 12:39:33PM +0100, Arnd Bergmann wrote:
>> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
>> index 5d595cfdb2c4..66cfdad68f7e 100644
>> --- a/include/linux/compiler-gcc.h
>> +++ b/include/linux/compiler-gcc.h
>> @@ -205,6 +205,15 @@
>> #endif
>>
>> /*
>> + * calling noreturn functions, __builtin_unreachable() and __builtin_trap()
>> + * confuse the stack allocation in gcc, leading to overly large stack
>> + * frames, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
>> + *
>> + * Adding an empty inline assembly before it works around the problem
>> + */
>> +#define barrier_before_unreachable() asm volatile("")
>> +
>> +/*
>> * Mark a position in code as unreachable. This can be used to
>> * suppress control flow warnings after asm blocks that transfer
>> * control elsewhere.
>> @@ -214,7 +223,11 @@
>> * unreleased. Really, we need to have autoconf for the kernel.
>> */
>> #define unreachable() \
>> - do { annotate_unreachable(); __builtin_unreachable(); } while (0)
>> + do {\
>> + annotate_unreachable(); \
>> + barrier_before_unreachable(); \
>> + __builtin_unreachable();\
>> + } while (0)
>
> Unfortunately this breaks microMIPS builds (e.g. MIPS
> micro32r2_defconfig and micro32r2el_defconfig) on gcc 7.2, due to the
> lack of .insn in the asm volatile. Because of the
> __builtin_unreachable() there is no code following it. Without the empty
> asm the compiler will apparently put the .insn there automatically, but
> with the empty asm it doesn't. Therefore the assembler won't treat an
> immediately preceeding label as pointing at 16-bit microMIPS
> instructions which need the ISA bit set, i.e. bit 0 of the address.
> This causes assembler errors since the branch target is treated as a
> different ISA mode:
>
> arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA mode
> arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA mode
Ok, I see.
> Due to a compiler bug on gcc 4.9.2 -> somewhere before 7.2, Paul
> submitted these patches a while back:
> https://patchwork.linux-mips.org/patch/13360/
> https://patchwork.linux-mips.org/patch/13361/
>
> Your patch (suitably fixed for microMIPS) would I imagine fix that issue
> too (it certainly fixes the resulting link error on microMIPS builds
> with an old toolchain).
>
> Before I forward port those patches to add .insn for MIPS, is that sort
> of approach (an arch specific asm/compiler-gcc.h to allow MIPS to
> override barrier_before_unreachable()) an acceptable fix?
That sounds fine to me. However, I would suggest making that
asm/compiler.h instead of asm/compiler-gcc.h, so we can also
use the same file to include workarounds for clang if needed.
Arnd
Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction
On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> ("gpio: correct docs about return value of gpiod_get_direction"). Now,
> fix this user (until a better, system-wide solution is in place).
>
> Signed-off-by: Wolfram Sang
> Acked-by: Daniel Thompson
Reviewed-by: Simon Horman
> ---
>
> Changes since V1:
> * rebased to top-of-linus-tree
> * added tag from Daniel, thanks!
>
> Through which tree does this need to go?
>
> drivers/video/backlight/pwm_bl.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 1c2289ddd555..0fa7d2bd0e48 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -301,14 +301,14 @@ static int pwm_backlight_probe(struct platform_device
> *pdev)
>
> /*
>* If the GPIO is not known to be already configured as output, that
> - * is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL,
> - * change the direction to output and set the GPIO as active.
> + * is, if gpiod_get_direction returns either 1 or -EINVAL, change the
> + * direction to output and set the GPIO as active.
>* Do not force the GPIO to active when it was already output as it
>* could cause backlight flickering or we would enable the backlight too
>* early. Leave the decision of the initial backlight state for later.
>*/
> if (pb->enable_gpio &&
> - gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
> + gpiod_get_direction(pb->enable_gpio) != 0)
> gpiod_direction_output(pb->enable_gpio, 1);
>
> pb->power_supply = devm_regulator_get(&pdev->dev, "power");
> --
> 2.11.0
>
[PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4
i40iw_add_mqh_4() is never called in atomic context, because it calls rtnl_lock() that can sleep. Despite never getting called from atomic context, i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC, which does not sleep for allocation. GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, which can sleep and improve the possibility of sucessful allocation. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/infiniband/hw/i40iw/i40iw_cm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c b/drivers/infiniband/hw/i40iw/i40iw_cm.c index 5230dd3..4e79af5 100644 --- a/drivers/infiniband/hw/i40iw/i40iw_cm.c +++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c @@ -1758,7 +1758,7 @@ static enum i40iw_status_code i40iw_add_mqh_4( &ifa->ifa_address, rdma_vlan_dev_vlan_id(dev), dev->dev_addr); - child_listen_node = kzalloc(sizeof(*child_listen_node), GFP_ATOMIC); + child_listen_node = kzalloc(sizeof(*child_listen_node), GFP_KERNEL); cm_parent_listen_node->cm_core->stats_listen_nodes_created++; i40iw_debug(&iwdev->sc_dev, I40IW_DEBUG_CM, -- 1.9.1
[PATCH 2/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_make_listen_node
i40iw_make_listen_node() is never called in atomic context.
i40iw_make_listen_node() is only called by i40iw_create_listen, which is
set as ".create_listen" in struct iw_cm_verbs.
Despite never getting called from atomic context,
i40iw_make_listen_node() calls kzalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/infiniband/hw/i40iw/i40iw_cm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c
b/drivers/infiniband/hw/i40iw/i40iw_cm.c
index 5230dd3..d021399 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
@@ -2834,7 +2834,7 @@ static struct i40iw_cm_listener *i40iw_make_listen_node(
if (!listener) {
/* create a CM listen node (1/2 node to compare incoming
traffic to) */
- listener = kzalloc(sizeof(*listener), GFP_ATOMIC);
+ listener = kzalloc(sizeof(*listener), GFP_KERNEL);
if (!listener)
return NULL;
cm_core->stats_listen_nodes_created++;
--
1.9.1
[PATCH 3/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_l2param_change
i40iw_l2param_change() is never called in atomic context. i40iw_make_listen_node() is only set as ".l2_param_change" in struct i40e_client_ops, and this function pointer is not called in atomic context. Despite never getting called from atomic context, i40iw_l2param_change() calls kzalloc() with GFP_ATOMIC, which does not sleep for allocation. GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, which can sleep and improve the possibility of sucessful allocation. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/infiniband/hw/i40iw/i40iw_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/i40iw/i40iw_main.c b/drivers/infiniband/hw/i40iw/i40iw_main.c index 27590ae..b86bda8 100644 --- a/drivers/infiniband/hw/i40iw/i40iw_main.c +++ b/drivers/infiniband/hw/i40iw/i40iw_main.c @@ -1737,7 +1737,7 @@ static void i40iw_l2param_change(struct i40e_info *ldev, struct i40e_client *cli return; - work = kzalloc(sizeof(*work), GFP_ATOMIC); + work = kzalloc(sizeof(*work), GFP_KERNEL); if (!work) return; -- 1.9.1
[PATCH][next] scsi: fnic: fix spelling mistake in fnic stats "Abord" -> "Abort"
From: Colin Ian King Trivial fix to spelling mistake in fnic stats message text Signed-off-by: Colin Ian King --- drivers/scsi/fnic/fnic_trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/fnic/fnic_trace.c b/drivers/scsi/fnic/fnic_trace.c index abddde11982b..98597b59c12a 100644 --- a/drivers/scsi/fnic/fnic_trace.c +++ b/drivers/scsi/fnic/fnic_trace.c @@ -296,7 +296,7 @@ int fnic_get_stats_data(struct stats_debug_info *debug, "Number of Abort FW Timeouts: %lld\n" "Number of Abort IO NOT Found: %lld\n" - "Abord issued times: \n" + "Abort issued times: \n" "< 6 sec : %lld\n" " 6 sec - 20 sec : %lld\n" "20 sec - 30 sec : %lld\n" -- 2.15.1
Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5
Hi Boris,
On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:
> Hi Ladislav,
>
> On Wed, 11 Apr 2018 08:26:07 +0200
> Ladislav Michl wrote:
>
> > Hi Andreas,
> >
> > On Wed, Apr 11, 2018 at 06:59:03AM +0200, Andreas Kemnade wrote:
> > > Hi Ladis,
> > >
> > > On Tue, 10 Apr 2018 22:56:43 +0200
> > > Ladislav Michl wrote:
> > >
> > > > Hi Nikolaus,
> > > >
> > > > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> > > > > Hi,
> > > > > we just started testing the v4.16 kernel and found the
> > > > > device no longer bootable (works with v4.15). It turned
> > > > > out that there was a harmful modification somewhere between
> > > > > v4.15.0 and v4.16-rc1.
> > > > >
> > > > > A git bisect points to this patch:
> > > >
> > > > Well, that's a shame... However, this code is in production for several
> > > > months now, so could you, please put 'goto out_copy' if 'buf >=
> > > > high_memory'
> > > > condition is met, ie:
> > > > --- a/drivers/mtd/nand/onenand/omap2.c
> > > > +++ b/drivers/mtd/nand/onenand/omap2.c
> > > > @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct
> > > > mtd_info *mtd, int area,
> > > > if (buf >= high_memory) {
> > > > struct page *p1;
> > > >
> > > > + goto out_copy;
> > > > if (((size_t)buf & PAGE_MASK) !=
> > > > ((size_t)(buf + count - 1) & PAGE_MASK))
> > > > goto out_copy;
> > >
> > > I had the same problem here, and that snippet helps here. ubiattach
> > > -p /dev/mtdX does not cause kernel oopses here anymore
> >
> > It seems reviving old code always comes at a price :-) Could you try
> > following patch, so far compile tested only?
> > (we'll need to do the same for omap2_onenand_write_bufferram, but
> > it sould be enough for testing purposes now)
> >
> > diff --git a/drivers/mtd/nand/onenand/omap2.c
> > b/drivers/mtd/nand/onenand/omap2.c
> > index 9c159f0dd9a6..04cefd7a6487 100644
> > --- a/drivers/mtd/nand/onenand/omap2.c
> > +++ b/drivers/mtd/nand/onenand/omap2.c
> > @@ -375,11 +375,12 @@ static int omap2_onenand_read_bufferram(struct
> > mtd_info *mtd, int area,
> > {
> > struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > struct onenand_chip *this = mtd->priv;
> > + struct device *dev = &c->pdev->dev;
> > dma_addr_t dma_src, dma_dst;
> > int bram_offset;
> > void *buf = (void *)buffer;
> > size_t xtra;
> > - int ret;
> > + int ret, page_dma = 0;
> >
> > bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > @@ -389,38 +390,43 @@ static int omap2_onenand_read_bufferram(struct
> > mtd_info *mtd, int area,
> > if (in_interrupt() || oops_in_progress)
> > goto out_copy;
> >
> > + xtra = count & 3;
> > + if (xtra) {
> > + count -= xtra;
> > + memcpy(buf + count, this->base + bram_offset + count, xtra);
> > + }
> > +
> > + /* Handle vmalloc address */
> > if (buf >= high_memory) {
> > - struct page *p1;
> > + struct page *page;
> >
> > if (((size_t)buf & PAGE_MASK) !=
> > ((size_t)(buf + count - 1) & PAGE_MASK))
> > goto out_copy;
> > - p1 = vmalloc_to_page(buf);
> > - if (!p1)
> > + page = vmalloc_to_page(buf);
>
> Not sure this approach is safe on all archs: if the cache is VIVT or
> VIPT, you may have several entries pointing to the same phys page, and
> then, when dma_map_page() does its cache maintenance operations, it's
> only taking one of these entries into account.
Hmm, I used the same approach Samsung OneNAND driver does since commit
dcf08227e964a53a2cb39130b74842c7dcb6adde.
Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
is VIPT. In that case samsung's driver code has the same problem.
> In other parts of the MTD subsystem, we tend to not do DMA on buffers
> that have been vmalloc-ed.
>
> You can do something like
>
> if (virt_addr_valid(buf))
> /* Use DMA */
> else
> /*
>* Do not use DMA, or use a bounce buffer
>* allocated with kmalloc
>*/
Okay, I'll use this approach then, but first I'd like to be sure above is
correct. Anyone?
> Regards,
>
> Boris
Thank you,
ladis
> > + if (!page)
> > goto out_copy;
> > - buf = page_address(p1) + ((size_t)buf & ~PAGE_MASK);
> > - }
> > -
> > - xtra = count & 3;
> > - if (xtra) {
> > - count -= xtra;
> > - memcpy(buf + count, this->base + bram_offset + count, xtra);
> > + page_dma = 1;
> > + dma_dst = dma_map_page(dev, page, (size_t) buf & ~PAGE_MASK,
> > + count, DMA_FROM_
Re: [PATCH v2 8/9] PCI: dwc: Small computation improvement
Hi Jingoo,
On 11/04/2018 01:01, Jingoo Han wrote:
> On Monday, April 9, 2018 5:41 AM, Gustavo Pimentel wrote:
>>
>> Replaces a simple division by 2 to a right shift rotation of 1 bit.
>
> It looks good. However, would you add a simple reason to the commit
> message?
Sure.
Can be this one?
Probably any recent and decent compiler does this kind of substitution
in order to improve code performance. Nevertheless it's a coding good
practice whenever there is a division / multiplication by multiple of 2
to replace it by the equivalent operation in this case, the shift
rotation.
>
> Best regards,
> Jingoo Han
>
>>
>> Signed-off-by: Gustavo Pimentel
>> ---
>> Change v1->v2:
>> - Nothing changed, just to follow the patch set version.
>>
>> drivers/pci/dwc/pcie-designware-host.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/pci/dwc/pcie-designware-host.c
>> b/drivers/pci/dwc/pcie-designware-host.c
>> index 03e9b82..8e6fed4 100644
>> --- a/drivers/pci/dwc/pcie-designware-host.c
>> +++ b/drivers/pci/dwc/pcie-designware-host.c
>> @@ -332,8 +332,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>>
>> cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> "config");
>> if (cfg_res) {
>> -pp->cfg0_size = resource_size(cfg_res) / 2;
>> -pp->cfg1_size = resource_size(cfg_res) / 2;
>> +pp->cfg0_size = resource_size(cfg_res) >> 1;
>> +pp->cfg1_size = resource_size(cfg_res) >> 1;
>> pp->cfg0_base = cfg_res->start;
>> pp->cfg1_base = cfg_res->start + pp->cfg0_size;
>> } else if (!pp->va_cfg0_base) {
>> @@ -377,8 +377,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
>> break;
>> case 0:
>> pp->cfg = win->res;
>> -pp->cfg0_size = resource_size(pp->cfg) / 2;
>> -pp->cfg1_size = resource_size(pp->cfg) / 2;
>> +pp->cfg0_size = resource_size(pp->cfg) >> 1;
>> +pp->cfg1_size = resource_size(pp->cfg) >> 1;
>> pp->cfg0_base = pp->cfg->start;
>> pp->cfg1_base = pp->cfg->start + pp->cfg0_size;
>> break;
>> --
>> 2.7.4
>>
>
>
Regards,
Gustavo
Re: [PATCH v5 07/13] ARM: smp: Add initialization of CNTVOFF
Hello, On Mon, 9 Apr 2018 10:24:41 +0200 Geert Uytterhoeven wrote: > On Wed, Apr 4, 2018 at 4:30 PM, Marc Zyngier wrote: > > On Wed, 04 Apr 2018 14:59:09 +0100, > > Mylčne Josserand wrote: > > [Marc: stuck in ISO-8859-1? ;-] > > >> > It'd be good to take this opportunity to refactor the shmobile code. > >> > >> I can do it in this series but I do not have any shmobile platforms so > >> I will not be able to test my modifications (only compilation). > >> > >> If someone can test it for me (who?), it is okay for me to refactor this > >> code :) > > > > I guess you could Cc the shmobile folks (Geert Uytterhoeven, Simon > > Horman), and get them to review/test the changes. > > Correct. I can test on a remote R-Car E2 ALT board that needs it. Great, thank you! I will add you in CC in my next version, then. Best regards, Mylène -- Mylène Josserand, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com
Re: [linux-sunxi] [PATCH v3] ARM: sun8i: v40: enable USB host ports for Banana Pi M2 Berry
On Mon, Apr 09, 2018 at 03:33:34PM +0800, Chen-Yu Tsai wrote: > On Fri, Apr 6, 2018 at 10:03 PM, Icenowy Zheng wrote: > > Banana Pi M2 Berry has an on-board USB Hub that provides 4 USB Type-A > > ports, and it's connected to the USB1 port of the SoC. > > > > Enable it. > > > > Signed-off-by: Icenowy Zheng > > Verified against public schematics. > > Reviewed-by: Chen-Yu Tsai Applied for 4.18 Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: KASAN: slab-out-of-bounds Read in pfkey_add
On Wed, Apr 11, 2018 at 8:18 AM, Kevin Easton wrote:
> On Mon, Apr 09, 2018 at 01:56:36AM -0400, Kevin Easton wrote:
>> On Sun, Apr 08, 2018 at 09:04:33PM -0700, Eric Biggers wrote:
>> ...
>> >
>> > Looks like this is going to be fixed by
>> > https://patchwork.kernel.org/patch/10327883/ ("af_key: Always verify
>> > length of
>> > provided sadb_key"), but it's not applied yet to the ipsec tree yet.
>> > Kevin, for
>> > future reference, for syzbot bugs it would be helpful to reply to the
>> > original
>> > bug report and say that a patch was sent out, or even better send the
>> > patch as a
>> > reply to the bug report email, e.g.
>> >
>> > git format-patch
>> > --in-reply-to="<001a114292fadd3e250560706...@google.com>"
>> >
>> > for this one (and the Message ID can be found in the syzkaller-bugs
>> > archive even
>> > if the email isn't in your inbox).
>>
>> Sure, I can do that.
>
> I recalled one reason I _didn't_ do this - the message ID is retrievable
> from the archived email, but because the archive is Google Groups the
> message recipients aren't (only masked).
>
> - Kevin
>
Hi Kevin,
This was mailed to other lists too:
To: davem@, herbert@, linux-kernel@vger.kernel.org,
net...@vger.kernel.org, steffen.klassert@,
syzkaller-b...@googlegroups.com
In the groups UI there is a drop down menu with "Show Original" option
which shows raw email which include Message-ID: header.
Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN
On Wed, Apr 11, 2018 at 2:39 AM, Joel Fernandes wrote:
> Hi Steve,
>
> On Tue, Apr 10, 2018 at 11:00 AM, Steven Rostedt wrote:
>> On Tue, 10 Apr 2018 09:45:54 -0700
>> Joel Fernandes wrote:
>>
>>> > diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
>>> > index a0233edc0718..807e2bcb21b3 100644
>>> > --- a/include/linux/ring_buffer.h
>>> > +++ b/include/linux/ring_buffer.h
>>> > @@ -106,7 +106,8 @@ __poll_t ring_buffer_poll_wait(struct ring_buffer
>>> > *buffer, int cpu,
>>> >
>>> > void ring_buffer_free(struct ring_buffer *buffer);
>>> >
>>> > -int ring_buffer_resize(struct ring_buffer *buffer, unsigned long size,
>>> > int cpu);
>>> > +int ring_buffer_resize(struct ring_buffer *buffer, unsigned long size,
>>> > + int cpu, int rbflags);
>>> >
>>> > void ring_buffer_change_overwrite(struct ring_buffer *buffer, int val);
>>> >
>>> > @@ -201,6 +202,7 @@ int ring_buffer_print_page_header(struct trace_seq
>>> > *s);
>>> >
>>> > enum ring_buffer_flags {
>>> > RB_FL_OVERWRITE = 1 << 0,
>>> > + RB_FL_NO_RECLAIM= 1 << 1,
>>>
>>> But the thing is, set_oom_origin doesn't seem to be doing the
>>> desirable thing every time anyway as per my tests last week [1] and
>>> the si_mem_available check alone seems to be working fine for me (and
>>> also Zhaoyang as he mentioned).
>>
>> But did you try it with just plain GFP_KERNEL, and not RETRY_MAYFAIL.
>
> Yes I tried it with just GFP_KERNEL as well. What I did based on your
> suggestion for testing the OOM hint is:
> 1. Comment the si_mem_available check
> 2. Do only GFP_KERNEL
>
> The system gets destabilized with this combination even with the OOM
> hint. These threads are here:
> https://lkml.org/lkml/2018/4/5/720
>
>> My tests would always trigger the allocating task without the
>> RETRY_MAYFAIL, but with RETRY_MAYFAIL it would sometimes take out other
>> tasks.
>>
>>>
>>> Since the problem Zhaoyang is now referring to is caused because of
>>> calling set_oom_origin in the first place, can we not just drop that
>>> patch and avoid adding more complexity?
>>
>> Actually, I'm thinking of dropping the MAYFAIL part. It really should
>> be the one targeted if you are extending the ring buffer.
>
> This then sounds like it should be fixed in -mm code? If we're giving
> the hint and its not getting killed there then that's an -mm issue.
>
>> I could add two loops. One that does NORETRY without the oom origin,
>> and if it succeeds, its fine. But if it requires reclaim, it will then
>> set oom_origin and go harder (where it should be the one targeted).
>>
>> But that may be pointless, because if NORETRY succeeds, there's not
>> really any likelihood of oom triggering in the first place.
>
> Yes.
>
>>
>>>
>>> IMHO I feel like for things like RB memory allocation, we shouldn't
>>> add a knob if we don't need to.
>>
>> It was just a suggestion.
>
> Cool, I understand.
>
>>>
>>> Also I think Zhaoyang is developing for Android too since he mentioned
>>> he ran CTS tests so we both have the same "usecase" but he can feel
>>> free to correct me if that's not the case ;)
>>
>> I think if you are really worried with the task being killed by oom,
>> then I agree with Michal and just fork a process to do the allocation
>> for you.
>
> Yes I agree. So lets just do that and no other patches additional
> patches are needed then. Let me know if there's anything else I
> missed?
>
> Also I got a bit confused, I reread all the threads. Zhaoyang's
> current issue is that the OOM hint *IS* working which is what
> triggered your patch to toggle the behavior through an option. Where
> was in this message we are discussing that the OOM hint doesn't always
> work which is not Zhaoyang's current issue. Let me know if I missed
> something? Sorry if I did.
>
> thanks,
>
> - Joel
Hi Joel, you are right. My issue is to make Steven's patch safer by
keeping -1000 process out of OOM. I think it is ok either we just have
si_mem_available or apply set/clear_current_oom_origin with absolving
-1000 process. The CTS case failed because the system_server was
killed as the innocent. If Steven think it is rared corner case, I am
ok with that.
[PATCH v6 1/4] Add notrace to lib/ucmpdi2.c
From: Palmer Dabbelt
As part of the MIPS conversion to use the generic GCC library routines,
Matt Redfearn discovered that I'd missed a notrace on __ucmpdi2(). This
patch rectifies the problem.
CC: Matt Redfearn
CC: Antony Pavlov
Signed-off-by: Palmer Dabbelt
Reviewed-by: Matt Redfearn
Signed-off-by: Matt Redfearn
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
add notrace to lib/ucmpdi2.c
lib/ucmpdi2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/ucmpdi2.c b/lib/ucmpdi2.c
index 25ca2d4c1e19..597998169a96 100644
--- a/lib/ucmpdi2.c
+++ b/lib/ucmpdi2.c
@@ -17,7 +17,7 @@
#include
#include
-word_type __ucmpdi2(unsigned long long a, unsigned long long b)
+word_type notrace __ucmpdi2(unsigned long long a, unsigned long long b)
{
const DWunion au = {.ll = a};
const DWunion bu = {.ll = b};
--
2.7.4
[PATCH] ide: hpt366: Replace mdelay with usleep_range in init_chipset_hpt366
init_chipset_hpt366() is never called in atomic context.
init_chipset_hpt366() is set as ".init_chipset" in struct ide_port_info.
This function is not called in atomic context.
Despite never getting called from atomic context, init_chipset_hpt366()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/ide/hpt366.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ide/hpt366.c b/drivers/ide/hpt366.c
index 4b5dc01..4045559 100644
--- a/drivers/ide/hpt366.c
+++ b/drivers/ide/hpt366.c
@@ -984,7 +984,7 @@ static int init_chipset_hpt366(struct pci_dev *dev)
for (temp = i = 0; i < 128; i++) {
pci_read_config_word(dev, 0x78, &f_cnt);
temp += f_cnt & 0x1ff;
- mdelay(1);
+ usleep_range(1000, 2000);
}
f_cnt = temp / 128;
} else
--
1.9.1
[PATCH v6 2/4] lib: Rename compiler intrinsic selects to GENERIC_LIB_*
When these are included into arch Kconfig files, maintaining alphabetical ordering of the selects means these get split up. To allow for keeping things tidier and alphabetical, rename the selects to GENERIC_LIB_* Signed-off-by: Matt Redfearn Reviewed-by: Palmer Dabbelt --- Changes in v6: None Changes in v5: None Changes in v4: Rename Kconfig symbols GENERIC_* -> GENERIC_LIB_* Changes in v3: None Changes in v2: None arch/riscv/Kconfig | 6 +++--- lib/Kconfig| 12 ++-- lib/Makefile | 12 ++-- 3 files changed, 15 insertions(+), 15 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 04807c7f64cc..20185aaaf933 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -104,9 +104,9 @@ config ARCH_RV32I bool "RV32I" select CPU_SUPPORTS_32BIT_KERNEL select 32BIT - select GENERIC_ASHLDI3 - select GENERIC_ASHRDI3 - select GENERIC_LSHRDI3 + select GENERIC_LIB_ASHLDI3 + select GENERIC_LIB_ASHRDI3 + select GENERIC_LIB_LSHRDI3 config ARCH_RV64I bool "RV64I" diff --git a/lib/Kconfig b/lib/Kconfig index e96089499371..e54ebe00937e 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -588,20 +588,20 @@ config STRING_SELFTEST endmenu -config GENERIC_ASHLDI3 +config GENERIC_LIB_ASHLDI3 bool -config GENERIC_ASHRDI3 +config GENERIC_LIB_ASHRDI3 bool -config GENERIC_LSHRDI3 +config GENERIC_LIB_LSHRDI3 bool -config GENERIC_MULDI3 +config GENERIC_LIB_MULDI3 bool -config GENERIC_CMPDI2 +config GENERIC_LIB_CMPDI2 bool -config GENERIC_UCMPDI2 +config GENERIC_LIB_UCMPDI2 bool diff --git a/lib/Makefile b/lib/Makefile index a90d4fcd748f..7425e177f08c 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -253,9 +253,9 @@ obj-$(CONFIG_SBITMAP) += sbitmap.o obj-$(CONFIG_PARMAN) += parman.o # GCC library routines -obj-$(CONFIG_GENERIC_ASHLDI3) += ashldi3.o -obj-$(CONFIG_GENERIC_ASHRDI3) += ashrdi3.o -obj-$(CONFIG_GENERIC_LSHRDI3) += lshrdi3.o -obj-$(CONFIG_GENERIC_MULDI3) += muldi3.o -obj-$(CONFIG_GENERIC_CMPDI2) += cmpdi2.o -obj-$(CONFIG_GENERIC_UCMPDI2) += ucmpdi2.o +obj-$(CONFIG_GENERIC_LIB_ASHLDI3) += ashldi3.o +obj-$(CONFIG_GENERIC_LIB_ASHRDI3) += ashrdi3.o +obj-$(CONFIG_GENERIC_LIB_LSHRDI3) += lshrdi3.o +obj-$(CONFIG_GENERIC_LIB_MULDI3) += muldi3.o +obj-$(CONFIG_GENERIC_LIB_CMPDI2) += cmpdi2.o +obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o -- 2.7.4
[PATCH v6 3/4] MIPS: vmlinuz: Use generic ashldi3
In preparation for removing some of the MIPS compiler intrinsics from arch/mips/lib, first update the build of vmlinuz to use the generic ashldi3 from lib. Both ashldi3 and bswapsi objects need to be built with different CFLAGS for inclusion to vmlinuz rather than simply including the object built for the main kernel image. The objects cannot be built directly from source, since CONFIG_MODVERSIONS changes cmd_cc_o_c to prevent this. Split the rule to ship ashldi3 and bswapsi from the relevant source locations. These files make no reference to other files in their directory, so the additional CFLAGS are apparently unnecessary - remove them as well. Signed-off-by: Matt Redfearn --- Changes in v6: New patch to fix vmlinuz which requires ashldi3 so must be switched to come from $(srctree)/lib before the arch/mips/ version is deleted. This version has been build tested with every upstream defconfig since previous versions caused problems with ci20_defconfig and loongson1b_defconfig. Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/mips/boot/compressed/Makefile | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile index adce180f3ee4..e03f522c33ac 100644 --- a/arch/mips/boot/compressed/Makefile +++ b/arch/mips/boot/compressed/Makefile @@ -46,9 +46,12 @@ $(obj)/uart-ath79.c: $(srctree)/arch/mips/ath79/early_printk.c vmlinuzobjs-$(CONFIG_KERNEL_XZ) += $(obj)/ashldi3.o $(obj)/bswapsi.o -extra-y += ashldi3.c bswapsi.c -$(obj)/ashldi3.o $(obj)/bswapsi.o: KBUILD_CFLAGS += -I$(srctree)/arch/mips/lib -$(obj)/ashldi3.c $(obj)/bswapsi.c: $(obj)/%.c: $(srctree)/arch/mips/lib/%.c +extra-y += ashldi3.c +$(obj)/ashldi3.c: $(obj)/%.c: $(srctree)/lib/%.c + $(call cmd,shipped) + +extra-y += bswapsi.c +$(obj)/bswapsi.c: $(obj)/%.c: $(srctree)/arch/mips/lib/%.c $(call cmd,shipped) targets := $(notdir $(vmlinuzobjs-y)) -- 2.7.4
[PATCH 2/2] ide: pdc202xx_new: Replace mdelay with msleep in init_chipset_pdcnew
init_chipset_pdcnew() is never called in atomic context. This function is only set as ".init_chipset" in struct ide_port_info. Despite never getting called from atomic context, init_chipset_pdcnew() calls mdelay() to busily wait. This is not necessary and can be replaced with msleep() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/ide/pdc202xx_new.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ide/pdc202xx_new.c b/drivers/ide/pdc202xx_new.c index b33646b..a654491 100644 --- a/drivers/ide/pdc202xx_new.c +++ b/drivers/ide/pdc202xx_new.c @@ -403,7 +403,7 @@ static int init_chipset_pdcnew(struct pci_dev *dev) outb(pll_ctl1, sec_dma_base + 0x03); /* Wait the PLL circuit to be stable */ - mdelay(30); + msleep(30); #ifdef DEBUG /* -- 1.9.1
[PATCH 1/2] ide: pdc202xx_new: Replace mdelay with usleep_range in detect_pll_input_clock
detect_pll_input_clock() is never called in atomic context. detect_pll_input_clock() is only called by init_chipset_pdcnew(), which is set as ".init_chipset" in struct ide_port_info. This function is not called in atomic context. Despite never getting called from atomic context, detect_pll_input_clock() calls mdelay() to busily wait. This is not necessary and can be replaced with usleep_range() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/ide/pdc202xx_new.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ide/pdc202xx_new.c b/drivers/ide/pdc202xx_new.c index b33646b..6afa66d 100644 --- a/drivers/ide/pdc202xx_new.c +++ b/drivers/ide/pdc202xx_new.c @@ -258,7 +258,7 @@ static long detect_pll_input_clock(unsigned long dma_base) outb(scr1 | 0x40, dma_base + 0x03); /* Let the counter run for 10 ms. */ - mdelay(10); + usleep_range(10); end_count = read_counter(dma_base); end_time = ktime_get(); -- 1.9.1
[PATCH v6 4/4] MIPS: use generic GCC library routines from lib/
From: Antony Pavlov
The commit b35cd9884fa5 ("lib: Add shared copies of some GCC library
routines") makes it possible to share generic GCC library routines by
several architectures.
This commit removes several generic GCC library routines from
arch/mips/lib/ in favour of similar routines from lib/.
Signed-off-by: Antony Pavlov
[Matt Redfearn] Use GENERIC_LIB_* named Kconfig entries
Signed-off-by: Matt Redfearn
Cc: Palmer Dabbelt
Cc: Matt Redfearn
Cc: James Hogan
Cc: Ralf Baechle
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
Changes in v6: None
Changes in v5:
Actually delete the MIPS lib routines
Changes in v4:
Rework to use the new GENERIC_LIB_ Kconfig entries
Changes in v3:
Maintain alphabetical order of MIPS Kconfig
Changes in v2: None
arch/mips/Kconfig | 5 +
arch/mips/lib/Makefile | 3 +--
arch/mips/lib/ashldi3.c | 30 --
arch/mips/lib/ashrdi3.c | 32
arch/mips/lib/cmpdi2.c | 28
arch/mips/lib/lshrdi3.c | 30 --
arch/mips/lib/ucmpdi2.c | 22 --
7 files changed, 6 insertions(+), 144 deletions(-)
delete mode 100644 arch/mips/lib/ashldi3.c
delete mode 100644 arch/mips/lib/ashrdi3.c
delete mode 100644 arch/mips/lib/cmpdi2.c
delete mode 100644 arch/mips/lib/lshrdi3.c
delete mode 100644 arch/mips/lib/ucmpdi2.c
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 8128c3b68d6b..98955a76c656 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -22,6 +22,11 @@ config MIPS
select GENERIC_CPU_AUTOPROBE
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
+ select GENERIC_LIB_ASHLDI3
+ select GENERIC_LIB_ASHRDI3
+ select GENERIC_LIB_CMPDI2
+ select GENERIC_LIB_LSHRDI3
+ select GENERIC_LIB_UCMPDI2
select GENERIC_PCI_IOMAP
select GENERIC_SCHED_CLOCK if !CAVIUM_OCTEON_SOC
select GENERIC_SMP_IDLE_THREAD
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index e84e12655fa8..6537e022ef62 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -16,5 +16,4 @@ obj-$(CONFIG_CPU_R3000) += r3k_dump_tlb.o
obj-$(CONFIG_CPU_TX39XX) += r3k_dump_tlb.o
# libgcc-style stuff needed in the kernel
-obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o multi3.o \
-ucmpdi2.o
+obj-y += bswapsi.o bswapdi.o multi3.o
diff --git a/arch/mips/lib/ashldi3.c b/arch/mips/lib/ashldi3.c
deleted file mode 100644
index 24cd6903e797..
--- a/arch/mips/lib/ashldi3.c
+++ /dev/null
@@ -1,30 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include
-
-#include "libgcc.h"
-
-long long notrace __ashldi3(long long u, word_type b)
-{
- DWunion uu, w;
- word_type bm;
-
- if (b == 0)
- return u;
-
- uu.ll = u;
- bm = 32 - b;
-
- if (bm <= 0) {
- w.s.low = 0;
- w.s.high = (unsigned int) uu.s.low << -bm;
- } else {
- const unsigned int carries = (unsigned int) uu.s.low >> bm;
-
- w.s.low = (unsigned int) uu.s.low << b;
- w.s.high = ((unsigned int) uu.s.high << b) | carries;
- }
-
- return w.ll;
-}
-
-EXPORT_SYMBOL(__ashldi3);
diff --git a/arch/mips/lib/ashrdi3.c b/arch/mips/lib/ashrdi3.c
deleted file mode 100644
index 23f5295af51e..
--- a/arch/mips/lib/ashrdi3.c
+++ /dev/null
@@ -1,32 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include
-
-#include "libgcc.h"
-
-long long notrace __ashrdi3(long long u, word_type b)
-{
- DWunion uu, w;
- word_type bm;
-
- if (b == 0)
- return u;
-
- uu.ll = u;
- bm = 32 - b;
-
- if (bm <= 0) {
- /* w.s.high = 1..1 or 0..0 */
- w.s.high =
- uu.s.high >> 31;
- w.s.low = uu.s.high >> -bm;
- } else {
- const unsigned int carries = (unsigned int) uu.s.high << bm;
-
- w.s.high = uu.s.high >> b;
- w.s.low = ((unsigned int) uu.s.low >> b) | carries;
- }
-
- return w.ll;
-}
-
-EXPORT_SYMBOL(__ashrdi3);
diff --git a/arch/mips/lib/cmpdi2.c b/arch/mips/lib/cmpdi2.c
deleted file mode 100644
index 93cfc785927d..
--- a/arch/mips/lib/cmpdi2.c
+++ /dev/null
@@ -1,28 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include
-
-#include "libgcc.h"
-
-word_type notrace __cmpdi2(long long a, long long b)
-{
- const DWunion au = {
- .ll = a
- };
- const DWunion bu = {
- .ll = b
- };
-
- if (au.s.high < bu.s.high)
- return 0;
- else if (au.s.high > bu.s.high)
- return 2;
-
- if ((unsigned int) au.s.low < (unsigned int) bu.s.low)
- return 0;
- else if ((unsigned int) au.s.low > (unsigned int) bu.s.low)
- return 2;
-
- return 1;
-}
-
-EXPOR
Re: [PATCH v10 05/10] livepatch: Support separate list for replaced patches.
On Tue, 10 Apr 2018, Josh Poimboeuf wrote: > > > I agree here. Practically we use only cumulative replacement patches at > > > SUSE. So with that in mind I don't care about the stacking much. But, it > > > may make sense for someone else. Evgenii mentioned they used it for > > > hotfixes. Therefore I'm reluctant to remove it completely. > > > > Well, it was convenient in some cases to provide a hot fix for a given bug > > on top of our official cumulative patch. So far, such fixes were only used > > on a few of the customers' machines (where they were needed ASAP). It just > > made it easier to see where is the common set of fixes and where is the > > customer-specific addition. > > > > I think, we can use cumulative patches in such cases too without much > > additional effort. For example, we can encode the distinction (base set of > > fixes + addition) in the module name or somewhere else. > > > > So, I think, it is fine for us, if stacking support is removed. Especially > > if that makes the implementation of livepatch less complex and more > > reliable. > > Just to clarify, I think we are just proposing the removal of the > enforcement of the stacking order. We will still allow multiple > non-replace patches to be applied. We just won't enforce which patches > can be disabled/removed at any given time. Heh, so I misunderstood. I thought you were talking about the removal of the stacking. Now it makes more sense. > So I think your old way of doing things (individual unrelated patches on > top of a cumulative patch) would still work. Yes. On the other hand the user needs to be even more careful, so I'd expect an update of documentation with the removal :). Miroslav
Re: [PATCH v4] isofs compress: Remove VLA usage
On Tue 10-04-18 17:02:29, Kyle Spiers wrote:
> As part of the effort to remove VLAs from the kernel[1], this changes
> the allocation of the bhs and pages arrays from being on the stack to being
> kcalloc()ed. This also allows for the removal of the explicit zeroing
> of bhs.
>
> https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Kyle Spiers
> ---
> Fix sparc64 build
> Fix Error recovery Mistakes
Thanks, the patch looks good now and I've merged it to my tree and will
push it to Linus (likely for rc2).
Honza
> ---
> fs/isofs/compress.c | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/fs/isofs/compress.c b/fs/isofs/compress.c
> index 9bb2fe35799d..10205ececc27 100644
> --- a/fs/isofs/compress.c
> +++ b/fs/isofs/compress.c
> @@ -20,6 +20,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -59,7 +60,7 @@ static loff_t zisofs_uncompress_block(struct inode *inode,
> loff_t block_start,
> >> bufshift;
> int haveblocks;
> blkcnt_t blocknum;
> - struct buffer_head *bhs[needblocks + 1];
> + struct buffer_head **bhs;
> int curbh, curpage;
>
> if (block_size > deflateBound(1UL << zisofs_block_shift)) {
> @@ -80,7 +81,11 @@ static loff_t zisofs_uncompress_block(struct inode *inode,
> loff_t block_start,
>
> /* Because zlib is not thread-safe, do all the I/O at the top. */
> blocknum = block_start >> bufshift;
> - memset(bhs, 0, (needblocks + 1) * sizeof(struct buffer_head *));
> + bhs = kcalloc(needblocks + 1, sizeof(*bhs), GFP_KERNEL);
> + if (!bhs) {
> + *errp = -ENOMEM;
> + return 0;
> + }
> haveblocks = isofs_get_blocks(inode, blocknum, bhs, needblocks);
> ll_rw_block(REQ_OP_READ, 0, haveblocks, bhs);
>
> @@ -190,6 +195,7 @@ static loff_t zisofs_uncompress_block(struct inode
> *inode, loff_t block_start,
> b_eio:
> for (i = 0; i < haveblocks; i++)
> brelse(bhs[i]);
> + kfree(bhs);
> return stream.total_out;
> }
>
> @@ -305,7 +311,7 @@ static int zisofs_readpage(struct file *file, struct page
> *page)
> unsigned int zisofs_pages_per_cblock =
> PAGE_SHIFT <= zisofs_block_shift ?
> (1 << (zisofs_block_shift - PAGE_SHIFT)) : 0;
> - struct page *pages[max_t(unsigned, zisofs_pages_per_cblock, 1)];
> + struct page **pages;
> pgoff_t index = page->index, end_index;
>
> end_index = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> @@ -330,6 +336,12 @@ static int zisofs_readpage(struct file *file, struct
> page *page)
> full_page = 0;
> pcount = 1;
> }
> + pages = kcalloc(max_t(unsigned int, zisofs_pages_per_cblock, 1),
> + sizeof(*pages), GFP_KERNEL);
> + if (!pages) {
> + unlock_page(page);
> + return -ENOMEM;
> + }
> pages[full_page] = page;
>
> for (i = 0; i < pcount; i++, index++) {
> @@ -357,6 +369,7 @@ static int zisofs_readpage(struct file *file, struct page
> *page)
> }
>
> /* At this point, err contains 0 or -EIO depending on the "critical"
> page */
> + kfree(pages);
> return err;
> }
>
> --
> 2.17.0.484.g0c8726318c-goog
>
--
Jan Kara
SUSE Labs, CR
Re: [PATCH] sched/fair: schedutil: update only with all info available
On 6 April 2018 at 19:28, Patrick Bellasi wrote:
> }
> @@ -5454,8 +5441,11 @@ static void dequeue_task_fair(struct rq *rq, struct
> task_struct *p, int flags)
> update_cfs_group(se);
> }
>
> - if (!se)
> + /* The task is no more visible from the root cfs_rq */
> + if (!se) {
> sub_nr_running(rq, 1);
> + cpufreq_update_util(rq, 0);
call to cpufreq_update_util() should be done after util_est_dequeue()
> + }
>
> util_est_dequeue(&rq->cfs, p, task_sleep);
> hrtick_update(rq);
[PATCH] panel-jdi-lt070me05000: Replace mdelay with usleep_range and msleep in jdi_panel_init
jdi_panel_init() is never called in atomic context.
Despite never getting called from atomic context, jdi_panel_init()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range()
and msleep() to avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 5b2340e..46b12a6 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -128,7 +128,7 @@ static int jdi_panel_init(struct jdi_panel *jdi)
return ret;
}
- mdelay(10);
+ usleep_range(1, 11000);
/* Interface setting, video mode */
ret = mipi_dsi_generic_write(dsi, (u8[])
@@ -139,7 +139,7 @@ static int jdi_panel_init(struct jdi_panel *jdi)
return ret;
}
- mdelay(20);
+ msleep(20);
ret = mipi_dsi_generic_write(dsi, (u8[]){0xB0, 0x03}, 2);
if (ret < 0) {
--
1.9.1
Re: [PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload
On Wed, Apr 11, 2018 at 03:17:10PM +0800, Jia-Ju Bai wrote: > > > On 2018/4/11 14:41, Greg KH wrote: > > On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote: > > > stir421x_fw_upload() is never called in atomic context. > > > > > > The call chain ending up at stir421x_fw_upload() is: > > > [1] stir421x_fw_upload() <- stir421x_patch_device() <- irda_usb_probe() > > > > > > irda_usb_probe() is set as ".probe" in struct usb_driver. > > > This function is not called in atomic context. > > > > > > Despite never getting called from atomic context, stir421x_fw_upload() > > > calls mdelay() to busily wait. > > > This is not necessary and can be replaced with usleep_range() to > > > avoid busy waiting. > > > > > > This is found by a static analysis tool named DCNS written by myself. > > > And I also manually check it. > > > > > > Signed-off-by: Jia-Ju Bai > > > --- > > > drivers/staging/irda/drivers/irda-usb.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Please, at the very least, work off of Linus's tree. There is no > > drivers/staging/irda/ anymore :) > > > > Okay, sorry. > Could you please recommend me a right tree or its git address? Have you looked in the MAINTAINERS file? Worst case, always use linux-next. greg k-h
[PATCH v3 0/2] move __HAVE_ARCH_PTE_SPECIAL in Kconfig
The per architecture __HAVE_ARCH_PTE_SPECIAL is defined statically in the per architecture header files. This doesn't allow to make other configuration dependent on it. The first patch of this series is replacing __HAVE_ARCH_PTE_SPECIAL by CONFIG_ARCH_HAS_PTE_SPECIAL defined into the Kconfig files, setting it automatically when architectures was already setting it in header file. The second patch is removing the odd define HAVE_PTE_SPECIAL which is a duplicate of CONFIG_ARCH_HAS_PTE_SPECIAL. There is no functional change introduced by this series. -- Changes since v2: * remove __HAVE_ARCH_PTE_SPECIAL in arch/riscv/include/asm/pgtable-bits.h * use IS_ENABLED() instead of #ifdef blocks in patch 2 Laurent Dufour (2): mm: introduce ARCH_HAS_PTE_SPECIAL mm: remove odd HAVE_PTE_SPECIAL .../features/vm/pte_special/arch-support.txt | 2 +- arch/arc/Kconfig | 1 + arch/arc/include/asm/pgtable.h| 2 -- arch/arm/Kconfig | 1 + arch/arm/include/asm/pgtable-3level.h | 1 - arch/arm64/Kconfig| 1 + arch/arm64/include/asm/pgtable.h | 2 -- arch/powerpc/Kconfig | 1 + arch/powerpc/include/asm/book3s/64/pgtable.h | 3 --- arch/powerpc/include/asm/pte-common.h | 3 --- arch/riscv/Kconfig| 1 + arch/riscv/include/asm/pgtable-bits.h | 3 --- arch/s390/Kconfig | 1 + arch/s390/include/asm/pgtable.h | 1 - arch/sh/Kconfig | 1 + arch/sh/include/asm/pgtable.h | 2 -- arch/sparc/Kconfig| 1 + arch/sparc/include/asm/pgtable_64.h | 3 --- arch/x86/Kconfig | 1 + arch/x86/include/asm/pgtable_types.h | 1 - include/linux/pfn_t.h | 4 ++-- mm/Kconfig| 3 +++ mm/gup.c | 4 ++-- mm/memory.c | 19 --- 24 files changed, 25 insertions(+), 37 deletions(-) -- 2.7.4
Re: [PATCH 4.14 134/138] vhost: validate log when IOTLB is enabled
On Tue, Apr 10, 2018 at 08:55:53PM -0400, David Miller wrote: > From: "Michael S. Tsirkin" > Date: Wed, 11 Apr 2018 02:33:16 +0300 > > > That's a bug, davem just queued a patch to fix this upstream. > > It did not get queued up. > > The patch series didn't apply so I asked the submitter to > respin and resubmit: > > https://marc.info/?l=linux-netdev&m=152337186209819&w=2 So should I drop this until a fix comes in? Or keep it for now? I have no objection to staying "bug compatible" with Linus's tree :) thanks, greg k-h
[PATCH v3 2/2] mm: remove odd HAVE_PTE_SPECIAL
Remove the additional define HAVE_PTE_SPECIAL and rely directly on
CONFIG_ARCH_HAS_PTE_SPECIAL.
There is no functional change introduced by this patch
Signed-off-by: Laurent Dufour
---
mm/memory.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 96910c625daa..7f7dc7b2a341 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -817,17 +817,12 @@ static void print_bad_pte(struct vm_area_struct *vma,
unsigned long addr,
* PFNMAP mappings in order to support COWable mappings.
*
*/
-#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
-# define HAVE_PTE_SPECIAL 1
-#else
-# define HAVE_PTE_SPECIAL 0
-#endif
struct page *_vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
pte_t pte, bool with_public_device)
{
unsigned long pfn = pte_pfn(pte);
- if (HAVE_PTE_SPECIAL) {
+ if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) {
if (likely(!pte_special(pte)))
goto check_pfn;
if (vma->vm_ops && vma->vm_ops->find_special_page)
@@ -862,7 +857,7 @@ struct page *_vm_normal_page(struct vm_area_struct *vma,
unsigned long addr,
return NULL;
}
- /* !HAVE_PTE_SPECIAL case follows: */
+ /* !CONFIG_ARCH_HAS_PTE_SPECIAL case follows: */
if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) {
if (vma->vm_flags & VM_MIXEDMAP) {
@@ -881,7 +876,8 @@ struct page *_vm_normal_page(struct vm_area_struct *vma,
unsigned long addr,
if (is_zero_pfn(pfn))
return NULL;
-check_pfn:
+
+check_pfn: __maybe_unused
if (unlikely(pfn > highest_memmap_pfn)) {
print_bad_pte(vma, addr, pte, NULL);
return NULL;
@@ -891,7 +887,7 @@ struct page *_vm_normal_page(struct vm_area_struct *vma,
unsigned long addr,
* NOTE! We still have PageReserved() pages in the page tables.
* eg. VDSO mappings can cause them to exist.
*/
-out:
+out: __maybe_unused
return pfn_to_page(pfn);
}
@@ -904,7 +900,7 @@ struct page *vm_normal_page_pmd(struct vm_area_struct *vma,
unsigned long addr,
/*
* There is no pmd_special() but there may be special pmds, e.g.
* in a direct-access (dax) mapping, so let's just replicate the
-* !HAVE_PTE_SPECIAL case from vm_normal_page() here.
+* !CONFIG_ARCH_HAS_PTE_SPECIAL case from vm_normal_page() here.
*/
if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) {
if (vma->vm_flags & VM_MIXEDMAP) {
@@ -1933,7 +1929,8 @@ static int __vm_insert_mixed(struct vm_area_struct *vma,
unsigned long addr,
* than insert_pfn). If a zero_pfn were inserted into a VM_MIXEDMAP
* without pte special, it would there be refcounted as a normal page.
*/
- if (!HAVE_PTE_SPECIAL && !pfn_t_devmap(pfn) && pfn_t_valid(pfn)) {
+ if (!IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL) &&
+ !pfn_t_devmap(pfn) && pfn_t_valid(pfn)) {
struct page *page;
/*
--
2.7.4
[PATCH v3 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL
Currently the PTE special supports is turned on in per architecture header
files. Most of the time, it is defined in arch/*/include/asm/pgtable.h
depending or not on some other per architecture static definition.
This patch introduce a new configuration variable to manage this directly
in the Kconfig files. It would later replace __HAVE_ARCH_PTE_SPECIAL.
Here notes for some architecture where the definition of
__HAVE_ARCH_PTE_SPECIAL is not obvious:
arm
__HAVE_ARCH_PTE_SPECIAL which is currently defined in
arch/arm/include/asm/pgtable-3level.h which is included by
arch/arm/include/asm/pgtable.h when CONFIG_ARM_LPAE is set.
So select ARCH_HAS_PTE_SPECIAL if ARM_LPAE.
powerpc
__HAVE_ARCH_PTE_SPECIAL is defined in 2 files:
- arch/powerpc/include/asm/book3s/64/pgtable.h
- arch/powerpc/include/asm/pte-common.h
The first one is included if (PPC_BOOK3S & PPC64) while the second is
included in all the other cases.
So select ARCH_HAS_PTE_SPECIAL all the time.
sparc:
__HAVE_ARCH_PTE_SPECIAL is defined if defined(__sparc__) &&
defined(__arch64__) which are defined through the compiler in
sparc/Makefile if !SPARC32 which I assume to be if SPARC64.
So select ARCH_HAS_PTE_SPECIAL if SPARC64
There is no functional change introduced by this patch.
Suggested-by: Jerome Glisse
Reviewed-by: Jerome Glisse
Acked-by: David Rientjes
Signed-off-by: Laurent Dufour
---
Documentation/features/vm/pte_special/arch-support.txt | 2 +-
arch/arc/Kconfig | 1 +
arch/arc/include/asm/pgtable.h | 2 --
arch/arm/Kconfig | 1 +
arch/arm/include/asm/pgtable-3level.h | 1 -
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/pgtable.h | 2 --
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/book3s/64/pgtable.h | 3 ---
arch/powerpc/include/asm/pte-common.h | 3 ---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/pgtable-bits.h | 3 ---
arch/s390/Kconfig | 1 +
arch/s390/include/asm/pgtable.h| 1 -
arch/sh/Kconfig| 1 +
arch/sh/include/asm/pgtable.h | 2 --
arch/sparc/Kconfig | 1 +
arch/sparc/include/asm/pgtable_64.h| 3 ---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/pgtable_types.h | 1 -
include/linux/pfn_t.h | 4 ++--
mm/Kconfig | 3 +++
mm/gup.c | 4 ++--
mm/memory.c| 2 +-
24 files changed, 18 insertions(+), 27 deletions(-)
diff --git a/Documentation/features/vm/pte_special/arch-support.txt
b/Documentation/features/vm/pte_special/arch-support.txt
index 055004f467d2..cd05924ea875 100644
--- a/Documentation/features/vm/pte_special/arch-support.txt
+++ b/Documentation/features/vm/pte_special/arch-support.txt
@@ -1,6 +1,6 @@
#
# Feature name: pte_special
-# Kconfig: __HAVE_ARCH_PTE_SPECIAL
+# Kconfig: ARCH_HAS_PTE_SPECIAL
# description: arch supports the pte_special()/pte_mkspecial() VM
APIs
#
---
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index d76bf4a83740..8516e2b0239a 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -44,6 +44,7 @@ config ARC
select HAVE_GENERIC_DMA_COHERENT
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZMA
+ select ARCH_HAS_PTE_SPECIAL
config MIGHT_HAVE_PCI
bool
diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
index 08fe33830d4b..8ec5599a0957 100644
--- a/arch/arc/include/asm/pgtable.h
+++ b/arch/arc/include/asm/pgtable.h
@@ -320,8 +320,6 @@ PTE_BIT_FUNC(mkexec,|= (_PAGE_EXECUTE));
PTE_BIT_FUNC(mkspecial,|= (_PAGE_SPECIAL));
PTE_BIT_FUNC(mkhuge, |= (_PAGE_HW_SZ));
-#define __HAVE_ARCH_PTE_SPECIAL
-
static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
{
return __pte((pte_val(pte) & _PAGE_CHG_MASK) | pgprot_val(newprot));
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7f8e7f4b88f..c088c851b235 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -8,6 +8,7 @@ config ARM
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
+ select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_PHYS_TO_DMA
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
diff --git a/arch/arm/include/asm/pgtable-3level.h
b/arch/arm/include/asm/pgtable-3level.h
index 2a4836087358..6d50a11d7793 100644
--- a/arch/arm/include/asm
Re: [PATCH] staging: Android: Add 'vsoc' driver for cuttlefish.
On Tue, Apr 10, 2018 at 12:06:47PM -0700, Alistair Strachan wrote:
> +static int do_create_fd_scoped_permission(
> + struct vsoc_device_region *region_p,
> + struct fd_scoped_permission_node *np,
> + struct fd_scoped_permission_arg *__user arg)
> +{
> + struct file *managed_filp;
> + s32 managed_fd;
> + atomic_t *owner_ptr = NULL;
> + struct vsoc_device_region *managed_region_p;
> +
> + if (copy_from_user(&np->permission, &arg->perm, sizeof(*np)) ||
> + copy_from_user(&managed_fd,
> +&arg->managed_region_fd, sizeof(managed_fd))) {
> + return -EFAULT;
> + }
> + managed_filp = fdget(managed_fd).file;
> + /* Check that it's a valid fd, */
> + if (!managed_filp || vsoc_validate_filep(managed_filp))
> + return -EPERM;
> + /* EEXIST if the given fd already has a permission. */
> + if (((struct vsoc_private_data *)managed_filp->private_data)->
> + fd_scoped_permission_node)
> + return -EEXIST;
> + managed_region_p = vsoc_region_from_filep(managed_filp);
> + /* Check that the provided region is managed by this one */
> + if (&vsoc_dev.regions[managed_region_p->managed_by] != region_p)
> + return -EPERM;
> + /* The area must be well formed and have non-zero size */
> + if (np->permission.begin_offset >= np->permission.end_offset)
> + return -EINVAL;
> + /* The area must fit in the memory window */
> + if (np->permission.end_offset >
> + vsoc_device_region_size(managed_region_p))
> + return -ERANGE;
> + /* The area must be in the region data section */
> + if (np->permission.begin_offset <
> + managed_region_p->offset_of_region_data)
> + return -ERANGE;
> + /* The area must be page aligned */
> + if (!PAGE_ALIGNED(np->permission.begin_offset) ||
> + !PAGE_ALIGNED(np->permission.end_offset))
> + return -EINVAL;
> + /* The owner flag must reside in the owner memory */
> + if (np->permission.owner_offset + sizeof(np->permission.owner_offset) >
^
There is a potential integer overflow here
> + vsoc_device_region_size(region_p))
> + return -ERANGE;
> + /* The owner flag must reside in the data section */
> + if (np->permission.owner_offset < region_p->offset_of_region_data)
> + return -EINVAL;
> + /* Owner offset must be naturally aligned in the window */
> + if (np->permission.owner_offset &
> + (sizeof(np->permission.owner_offset) - 1))
^
but then we prevent it here so that's fine. But it would be better to
reverse these checks so that it's easier to review.
> + return -EINVAL;
> + /* The owner value must change to claim the memory */
> + if (np->permission.owned_value == VSOC_REGION_FREE)
> + return -EINVAL;
> + owner_ptr =
> + (atomic_t *)shm_off_to_virtual_addr(region_p->region_begin_offset +
> + np->permission.owner_offset);
> + /* We've already verified that this is in the shared memory window, so
> + * it should be safe to write to this address.
> + */
> + if (atomic_cmpxchg(owner_ptr,
> +VSOC_REGION_FREE,
> +np->permission.owned_value) != VSOC_REGION_FREE) {
> + return -EBUSY;
> + }
> + ((struct vsoc_private_data *)managed_filp->private_data)->
> + fd_scoped_permission_node = np;
> + /* The file offset needs to be adjusted if the calling
> + * process did any read/write operations on the fd
> + * before creating the permission.
> + */
> + if (managed_filp->f_pos) {
> + if (managed_filp->f_pos > np->permission.end_offset) {
> + /* If the offset is beyond the permission end, set it
> + * to the end.
> + */
> + managed_filp->f_pos = np->permission.end_offset;
> + } else {
> + /* If the offset is within the permission interval
> + * keep it there otherwise reset it to zero.
> + */
> + if (managed_filp->f_pos < np->permission.begin_offset) {
> + managed_filp->f_pos = 0;
> + } else {
> + managed_filp->f_pos -=
> + np->permission.begin_offset;
> + }
> + }
> + }
> + return 0;
> +}
> +
[ snip ]
> +
> +/**
> + * Implements the inner logic of cond_wait. Copies to and from userspace are
> + * done in the helper function below.
> + */
> +static int handle_vsoc_cond_wait(struct file *filp, struct vsoc_cond_wait
> *arg)
> +{
> + DEFINE_WAIT(wai
Re: [PATCH v10 05/10] livepatch: Support separate list for replaced patches.
On Tue, 10 Apr 2018, Josh Poimboeuf wrote: > On Tue, Apr 10, 2018 at 10:34:55AM +0200, Petr Mladek wrote: > > > > > > > We were just recently discussing the possibility of not allowing > > > > > > > the > > > > > > > disabling of patches at all. If we're not going that far, let's > > > > > > > at > > > > > > > least further restrict it, for the sanity of our code, so we > > > > > > > don't have > > > > > > > to worry about a nasty mismatched stack of > > > > > > > enabled/disabled/enabled/etc, > > > > > > > at least for the cases where 'replace' patches aren't used. > > > > > > > > > > > > I am not completely sure where all these fears come from. From my > > > > > > point of view, this change is pretty safe and trivial thanks to NOPs > > > > > > and overall design. It would be a shame to do not have it. But I > > > > > > might be blind after spending so much time with the feature. > > > > > > > > > > I think you're missing my point. This isn't about your patch set, per > > > > > se. It's really about our existing code. Today, our patch stack > > > > > doesn't follow real stack semantics, because patches in the middle > > > > > might > > > > > be disabled. I see that as a problem. > > > > > > No, please read it again. I wasn't talking about replaced patches. > > > > I was confused by wording "in the middle". It suggested that there > > might had been enabled patches on the top and the bottom of the stack > > and some disabled patches in between at the same time (or vice versa). > > This was not true. > > That *was* what I meant. Consider the following sequence of events: > > - Register patch 1 > - Enable patch 1 > - Register patch 2 > - Enable patch 2 > - Disable patch 2 > - Register patch 3 > - Enable patch 3 > > Notice that patch 2 (in the middle) is disabled, whereas patch 1 (on the > bottom) and patch 3 (on the top) are enabled. This should not be possible at all. __klp_enable_patch: if (patch->list.prev != &klp_patches && !list_prev_entry(patch, list)->enabled) return -EBUSY; When patch 3 is enabled, list_prev_entry() returns patch 2 and its ->enabled is false. > > Do I understand it correctly that you do not like that the patches > > on the stack might be in two states (disabled/enabled). This might > > be translated that you do not like the state when the patch is > > registered and disabled. > > No, that wasn't really what I meant, but I have often wondered whether > we need such a distinction. > > > I wonder if the problem is in the "stack" abstraction. Would it help > > if we call it "sorted list" or whatever more suitable? > > But I don't even see a reason to have a sorted list (more on that > below). > > > Another possibility would be to get rid of the enable/disable states. > > I mean that the patch will be automatically enabled during > > registration and removed during unregistration. > > I don't see how disabling during unregistration would be possible, since > the unregister is called from the patch module exit function, which > can only be called *after* the patch is disabled. > > However, we could unregister immediately after disabling (i.e., in > enabled_store context). I think this is what Petr meant. So there would be nothing in the patch module exit function. Well, not exactly. We'd need to remove sysfs dir and maybe something more. > > Or we could rename the operation do add/remove or anything else. In > > fact, this is how it worked in kGraft. > > I'm not sure what renaming would solve, unless you mean to combine > registration and enablement into a single concept? Sounds good to me. > > > AFAIK, the enable/disabled state made more sense for immediate > > patches that could not be unloaded. We still need to keep the patches > > when the transaction is forced. The question is if we need to keep > > the sysfs entries for loaded but unused patches. > > I think we wouldn't need the sysfs entries. Just disable/unregister > forced patches like normal, except skipping the module_put(). > > > > Either way, why do we still need a stack? > > > > Good question. I suggest to agree on some terms first: > > > >+ Independent patches make unrelated changes. Any new function > > must not rely on changes done by any other patch. > > > >+ Dependent patches mean that a later patch depend on changes > > done by an earlier patch. For example, a new function might > > use function added by an earlier patch. > > > >+ Each cumulative patch include all necessary changes. I would say > > that it is self-containing and independent. Except that they should > > be able to continue using changes made by earlier patches (shadow > > variables, callbacks). > > > > > > Then we could say: > > > >+ The stack helps to enforce dependencies between dependent > > patches. But there is needed also some external solution > > that forces loading the patches in the right order. > > > >
Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5
On Wed, 11 Apr 2018 09:36:56 +0200
Ladislav Michl wrote:
> Hi Boris,
>
> On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:
> > Hi Ladislav,
> >
> > On Wed, 11 Apr 2018 08:26:07 +0200
> > Ladislav Michl wrote:
> >
> > > Hi Andreas,
> > >
> > > On Wed, Apr 11, 2018 at 06:59:03AM +0200, Andreas Kemnade wrote:
> > > > Hi Ladis,
> > > >
> > > > On Tue, 10 Apr 2018 22:56:43 +0200
> > > > Ladislav Michl wrote:
> > > >
> > > > > Hi Nikolaus,
> > > > >
> > > > > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> > > > >
> > > > > > Hi,
> > > > > > we just started testing the v4.16 kernel and found the
> > > > > > device no longer bootable (works with v4.15). It turned
> > > > > > out that there was a harmful modification somewhere between
> > > > > > v4.15.0 and v4.16-rc1.
> > > > > >
> > > > > > A git bisect points to this patch:
> > > > >
> > > > > Well, that's a shame... However, this code is in production for
> > > > > several
> > > > > months now, so could you, please put 'goto out_copy' if 'buf >=
> > > > > high_memory'
> > > > > condition is met, ie:
> > > > > --- a/drivers/mtd/nand/onenand/omap2.c
> > > > > +++ b/drivers/mtd/nand/onenand/omap2.c
> > > > > @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct
> > > > > mtd_info *mtd, int area,
> > > > > if (buf >= high_memory) {
> > > > > struct page *p1;
> > > > >
> > > > > + goto out_copy;
> > > > > if (((size_t)buf & PAGE_MASK) !=
> > > > > ((size_t)(buf + count - 1) & PAGE_MASK))
> > > > > goto out_copy;
> > > >
> > > > I had the same problem here, and that snippet helps here. ubiattach
> > > > -p /dev/mtdX does not cause kernel oopses here anymore
> > >
> > > It seems reviving old code always comes at a price :-) Could you try
> > > following patch, so far compile tested only?
> > > (we'll need to do the same for omap2_onenand_write_bufferram, but
> > > it sould be enough for testing purposes now)
> > >
> > > diff --git a/drivers/mtd/nand/onenand/omap2.c
> > > b/drivers/mtd/nand/onenand/omap2.c
> > > index 9c159f0dd9a6..04cefd7a6487 100644
> > > --- a/drivers/mtd/nand/onenand/omap2.c
> > > +++ b/drivers/mtd/nand/onenand/omap2.c
> > > @@ -375,11 +375,12 @@ static int omap2_onenand_read_bufferram(struct
> > > mtd_info *mtd, int area,
> > > {
> > > struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > > struct onenand_chip *this = mtd->priv;
> > > + struct device *dev = &c->pdev->dev;
> > > dma_addr_t dma_src, dma_dst;
> > > int bram_offset;
> > > void *buf = (void *)buffer;
> > > size_t xtra;
> > > - int ret;
> > > + int ret, page_dma = 0;
> > >
> > > bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > > if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > > @@ -389,38 +390,43 @@ static int omap2_onenand_read_bufferram(struct
> > > mtd_info *mtd, int area,
> > > if (in_interrupt() || oops_in_progress)
> > > goto out_copy;
> > >
> > > + xtra = count & 3;
> > > + if (xtra) {
> > > + count -= xtra;
> > > + memcpy(buf + count, this->base + bram_offset + count, xtra);
> > > + }
> > > +
> > > + /* Handle vmalloc address */
> > > if (buf >= high_memory) {
> > > - struct page *p1;
> > > + struct page *page;
> > >
> > > if (((size_t)buf & PAGE_MASK) !=
> > > ((size_t)(buf + count - 1) & PAGE_MASK))
> > > goto out_copy;
> > > - p1 = vmalloc_to_page(buf);
> > > - if (!p1)
> > > + page = vmalloc_to_page(buf);
> >
> > Not sure this approach is safe on all archs: if the cache is VIVT or
> > VIPT, you may have several entries pointing to the same phys page, and
> > then, when dma_map_page() does its cache maintenance operations, it's
> > only taking one of these entries into account.
>
> Hmm, I used the same approach Samsung OneNAND driver does since commit
> dcf08227e964a53a2cb39130b74842c7dcb6adde.
> Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
> is VIPT. In that case samsung's driver code has the same problem.
>
> > In other parts of the MTD subsystem, we tend to not do DMA on buffers
> > that have been vmalloc-ed.
> >
> > You can do something like
> >
> > if (virt_addr_valid(buf))
> > /* Use DMA */
> > else
> > /*
> > * Do not use DMA, or use a bounce buffer
> > * allocated with kmalloc
> > */
>
> Okay, I'll use this approach then, but first I'd like to be sure above is
> correct. Anyone?
See this discussion [1]. The problem came up a few times already, so
might find other threads describing why it's not safe.
[1]https://lists.linuxfoundation.org/pipermail/iommu/2016-March/016240.html
Re: [PATCH] MAINTAINERS: I'll maintain Renesas R-Car I2C host drivers
There seems to be some room to enhance the subject, but otherwise: Reviewed-by: Simon Horman On Tue, Apr 10, 2018 at 04:13:47PM +0200, Wolfram Sang wrote: > Signed-off-by: Wolfram Sang > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2f7ccdcf76f7..3bb87e65889c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11897,6 +11897,12 @@ L: linux-...@vger.kernel.org > S: Supported > F: drivers/iio/adc/rcar_gyro_adc.c > > +RENESAS R-CAR I2C DRIVERS > +M: Wolfram Sang > +S: Supported > +F: drivers/i2c/busses/i2c-rcar.c > +F: drivers/i2c/busses/i2c-sh_mobile.c > + > RENESAS USB PHY DRIVER > M: Yoshihiro Shimoda > L: linux-renesas-...@vger.kernel.org > -- > 2.11.0 >
Re: [PATCH v2 1/2] vfio: platform: Fix reset module leak in error path
On Tue, Apr 10, 2018 at 05:53:46PM +0200, Geert Uytterhoeven wrote:
> If the IOMMU group setup fails, the reset module is not released.
>
> Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by
> default")
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Eric Auger
Reviewed-by: Simon Horman
[PATCH v1 0/2] mm: migrate: vm event counter for hugepage migration
Hi everyone, I wrote patches introducing separate vm event counters for hugepage migration (both for hugetlb and thp.) Hugepage migration is different from normal page migration in event frequency and/or how likely it succeeds, so maintaining statistics for them in mixed counters might not be helpful both for develors and users. Thanks, Naoya Horiguchi --- Summary: Naoya Horiguchi (2): mm: migrate: add vm event counters thp_migrate_(success|fail) mm: migrate: add vm event counters hugetlb_migrate_(success|fail) include/linux/vm_event_item.h | 7 +++ mm/migrate.c | 103 +++--- mm/vmstat.c | 8 3 files changed, 102 insertions(+), 16 deletions(-)
[PATCH v1 1/2] mm: migrate: add vm event counters thp_migrate_(success|fail)
Currenly we have some vm event counters for page migration, but all
migration events are counted in a single value regardless of page size.
That is not good for end users who are interested in knowing whether
hugepage migration works. So this patch is suggesting to add separate
counters for thp migration.
Note that when thp migration fails due to ENOMEM or the lack of thp
migration support, the event is not counted in thp_migrate_fail and we
transparently retry the subpages' migrations.
Another note is that the return value of migrate_pages(), which is
claimed as "the number of pages that were not migrated (positive) or an
error code (negative)," doesn't consider the page size now. We could do
this for example by counting a single failure of thp migration event as
512, but this patch doesn't do it for simplicity. It seems to me that
there is no migrate_pages()'s caller which cares about the number itself
of the positive return value, so this should not be critical for now.
Signed-off-by: Naoya Horiguchi
---
include/linux/vm_event_item.h | 4 ++
mm/migrate.c | 93 +++
mm/vmstat.c | 4 ++
3 files changed, 85 insertions(+), 16 deletions(-)
diff --git v4.16-mmotm-2018-04-10-17-02/include/linux/vm_event_item.h
v4.16-mmotm-2018-04-10-17-02_patched/include/linux/vm_event_item.h
index 5c7f010..fa2d2e0 100644
--- v4.16-mmotm-2018-04-10-17-02/include/linux/vm_event_item.h
+++ v4.16-mmotm-2018-04-10-17-02_patched/include/linux/vm_event_item.h
@@ -88,6 +88,10 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
THP_ZERO_PAGE_ALLOC_FAILED,
THP_SWPOUT,
THP_SWPOUT_FALLBACK,
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ THP_MIGRATE_SUCCESS,
+ THP_MIGRATE_FAIL,
+#endif
#endif
#ifdef CONFIG_MEMORY_BALLOON
BALLOON_INFLATE,
diff --git v4.16-mmotm-2018-04-10-17-02/mm/migrate.c
v4.16-mmotm-2018-04-10-17-02_patched/mm/migrate.c
index bb6367d..46ff23a 100644
--- v4.16-mmotm-2018-04-10-17-02/mm/migrate.c
+++ v4.16-mmotm-2018-04-10-17-02_patched/mm/migrate.c
@@ -1348,6 +1348,69 @@ static int unmap_and_move_huge_page(new_page_t
get_new_page,
return rc;
}
+enum migrate_result_type {
+ MIGRATE_SUCCEED,
+ MIGRATE_FAIL,
+ MIGRATE_RETRY,
+ MIGRATE_RESULT_TYPES
+};
+
+enum migrate_page_type {
+ MIGRATE_PAGE_NORMAL,
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ MIGRATE_PAGE_THP,
+#endif
+ MIGRATE_PAGE_TYPES
+};
+
+static struct migrate_event {
+ int succeeded;
+ int failed;
+} migrate_events[] = {
+ { PGMIGRATE_SUCCESS,PGMIGRATE_FAIL },
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ { THP_MIGRATE_SUCCESS, THP_MIGRATE_FAIL },
+#endif
+};
+
+static inline enum migrate_page_type get_type(struct page *page)
+{
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ if (PageTransHuge(page))
+ return MIGRATE_PAGE_THP;
+#endif
+ return MIGRATE_PAGE_NORMAL;
+}
+
+static inline int get_count(int array[][MIGRATE_PAGE_TYPES], int type)
+{
+ int i, ret;
+
+ for (i = 0, ret = 0; i < MIGRATE_PAGE_TYPES; i++)
+ ret += array[type][i];
+ return ret;
+}
+
+static inline void reset_nr_retry(int array[][MIGRATE_PAGE_TYPES])
+{
+ int i;
+
+ for (i = 0; i < MIGRATE_PAGE_TYPES; i++)
+ array[MIGRATE_RETRY][i] = 0;
+}
+
+static inline void update_vm_migrate_events(int array[][MIGRATE_PAGE_TYPES])
+{
+ int i;
+
+ for (i = 0; i < MIGRATE_PAGE_TYPES; i++) {
+ count_vm_events(migrate_events[i].succeeded,
+ array[MIGRATE_SUCCEED][i]);
+ count_vm_events(migrate_events[i].failed,
+ array[MIGRATE_FAIL][i]);
+ }
+}
+
/*
* migrate_pages - migrate the pages specified in a list, to the free pages
*supplied as the target for the page migration
@@ -1373,9 +1436,7 @@ int migrate_pages(struct list_head *from, new_page_t
get_new_page,
free_page_t put_new_page, unsigned long private,
enum migrate_mode mode, int reason)
{
- int retry = 1;
- int nr_failed = 0;
- int nr_succeeded = 0;
+ int counts[MIGRATE_RESULT_TYPES][MIGRATE_PAGE_TYPES] = {0};
int pass = 0;
struct page *page;
struct page *page2;
@@ -1385,13 +1446,16 @@ int migrate_pages(struct list_head *from, new_page_t
get_new_page,
if (!swapwrite)
current->flags |= PF_SWAPWRITE;
- for(pass = 0; pass < 10 && retry; pass++) {
- retry = 0;
+ for (pass = 0; !pass || (pass < 10 && get_count(counts, MIGRATE_RETRY));
+pass++) {
+ reset_nr_retry(counts);
list_for_each_entry_safe(page, page2, from, lru) {
+ enum migrate_page_type mpt;
retry:
cond_resched();
+ mpt
[PATCH v1 2/2] mm: migrate: add vm event counters hugetlb_migrate_(success|fail)
>From the same motivation as the previous patch, this patch is suggesting
to add separate counters for hugetlb migration.
Signed-off-by: Naoya Horiguchi
---
include/linux/vm_event_item.h | 3 +++
mm/migrate.c | 10 ++
mm/vmstat.c | 4
3 files changed, 17 insertions(+)
diff --git v4.16-mmotm-2018-04-10-17-02/include/linux/vm_event_item.h
v4.16-mmotm-2018-04-10-17-02_patched/include/linux/vm_event_item.h
index fa2d2e0..24966ae 100644
--- v4.16-mmotm-2018-04-10-17-02/include/linux/vm_event_item.h
+++ v4.16-mmotm-2018-04-10-17-02_patched/include/linux/vm_event_item.h
@@ -62,6 +62,9 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
#endif
#ifdef CONFIG_HUGETLB_PAGE
HTLB_BUDDY_PGALLOC, HTLB_BUDDY_PGALLOC_FAIL,
+#ifdef CONFIG_MIGRATION
+ HTLB_MIGRATE_SUCCESS, HTLB_MIGRATE_FAIL,
+#endif
#endif
UNEVICTABLE_PGCULLED, /* culled to noreclaim list */
UNEVICTABLE_PGSCANNED, /* scanned for reclaimability */
diff --git v4.16-mmotm-2018-04-10-17-02/mm/migrate.c
v4.16-mmotm-2018-04-10-17-02_patched/mm/migrate.c
index 46ff23a..279b143 100644
--- v4.16-mmotm-2018-04-10-17-02/mm/migrate.c
+++ v4.16-mmotm-2018-04-10-17-02_patched/mm/migrate.c
@@ -1357,6 +1357,9 @@ enum migrate_result_type {
enum migrate_page_type {
MIGRATE_PAGE_NORMAL,
+#ifdef CONFIG_HUGETLB_PAGE
+ MIGRATE_PAGE_HUGETLB,
+#endif
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
MIGRATE_PAGE_THP,
#endif
@@ -1368,6 +1371,9 @@ static struct migrate_event {
int failed;
} migrate_events[] = {
{ PGMIGRATE_SUCCESS,PGMIGRATE_FAIL },
+#ifdef CONFIG_HUGETLB_PAGE
+ { HTLB_MIGRATE_SUCCESS, HTLB_MIGRATE_FAIL },
+#endif
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
{ THP_MIGRATE_SUCCESS, THP_MIGRATE_FAIL },
#endif
@@ -1375,6 +1381,10 @@ static struct migrate_event {
static inline enum migrate_page_type get_type(struct page *page)
{
+#ifdef CONFIG_HUGETLB_PAGE
+ if (PageHuge(page))
+ return MIGRATE_PAGE_HUGETLB;
+#endif
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
if (PageTransHuge(page))
return MIGRATE_PAGE_THP;
diff --git v4.16-mmotm-2018-04-10-17-02/mm/vmstat.c
v4.16-mmotm-2018-04-10-17-02_patched/mm/vmstat.c
index 57e9cc3..27a005f 100644
--- v4.16-mmotm-2018-04-10-17-02/mm/vmstat.c
+++ v4.16-mmotm-2018-04-10-17-02_patched/mm/vmstat.c
@@ -1236,6 +1236,10 @@ const char * const vmstat_text[] = {
#ifdef CONFIG_HUGETLB_PAGE
"htlb_buddy_alloc_success",
"htlb_buddy_alloc_fail",
+#ifdef CONFIG_MIGRATION
+ "htlb_migrate_success",
+ "htlb_migrate_fail",
+#endif
#endif
"unevictable_pgs_culled",
"unevictable_pgs_scanned",
--
2.7.0
Re: [PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload
On 2018/4/11 16:03, Greg KH wrote: On Wed, Apr 11, 2018 at 03:17:10PM +0800, Jia-Ju Bai wrote: On 2018/4/11 14:41, Greg KH wrote: On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote: stir421x_fw_upload() is never called in atomic context. The call chain ending up at stir421x_fw_upload() is: [1] stir421x_fw_upload() <- stir421x_patch_device() <- irda_usb_probe() irda_usb_probe() is set as ".probe" in struct usb_driver. This function is not called in atomic context. Despite never getting called from atomic context, stir421x_fw_upload() calls mdelay() to busily wait. This is not necessary and can be replaced with usleep_range() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/staging/irda/drivers/irda-usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Please, at the very least, work off of Linus's tree. There is no drivers/staging/irda/ anymore :) Okay, sorry. Could you please recommend me a right tree or its git address? Have you looked in the MAINTAINERS file? Worst case, always use linux-next. greg k-h Oh, sorry, I did notice the git tree in the MAINTAINERS file. I always used linux-stable. Thanks for telling me this :) Best wishes, Jia-Ju Bai
Re: [PATCH] checkpatch: Add a --strict test for structs with bool member definitions
On Tue, Apr 10, 2018 at 03:00:11PM -0700, Andrew Morton wrote: > On Tue, 10 Apr 2018 14:53:51 -0700 Joe Perches wrote: > > > On Tue, 2018-04-10 at 14:39 -0700, Andrew Morton wrote: > > > On Tue, 10 Apr 2018 11:19:54 -0700 Joe Perches wrote: > > > > > > > A struct with a bool member can have different sizes on various > > > > architectures because neither bool size nor alignment is standardized. > > > > > > What's wrong with bools in structs? > > > > See above. > > Yeah, but so what? `long' has different sizes on different > architectures too. Right, so we have ILP32/LP64 for all our 32/64 bit archs respectively. So only 2 possible variations to consider, and if you know your bitness you know your layout. (+- some really unfortunate alignment exceptions, the worst of which Arnd recently removed, hooray!) But neither says anything about sizeof(_Bool), and the standard leaves it undefined and only mandates it is large enough to store either 0 or 1 (and I suspect this vagueness is because there are architectures that either have no byte addressibility or it's more expensive than word addressibility). Typically GCC chooses a single byte to represent _Bool, but there are no guarantees. This means that when you care about structure layout (as we all really should) things go wobbly when you use _Bool. If GCC were to guarantee a 1 byte _Bool for all Linux ABIs we could reconsider.
Re: [PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload
On Wed, Apr 11, 2018 at 04:11:00PM +0800, Jia-Ju Bai wrote: > > > On 2018/4/11 16:03, Greg KH wrote: > > On Wed, Apr 11, 2018 at 03:17:10PM +0800, Jia-Ju Bai wrote: > > > > > > On 2018/4/11 14:41, Greg KH wrote: > > > > On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote: > > > > > stir421x_fw_upload() is never called in atomic context. > > > > > > > > > > The call chain ending up at stir421x_fw_upload() is: > > > > > [1] stir421x_fw_upload() <- stir421x_patch_device() <- > > > > > irda_usb_probe() > > > > > > > > > > irda_usb_probe() is set as ".probe" in struct usb_driver. > > > > > This function is not called in atomic context. > > > > > > > > > > Despite never getting called from atomic context, stir421x_fw_upload() > > > > > calls mdelay() to busily wait. > > > > > This is not necessary and can be replaced with usleep_range() to > > > > > avoid busy waiting. > > > > > > > > > > This is found by a static analysis tool named DCNS written by myself. > > > > > And I also manually check it. > > > > > > > > > > Signed-off-by: Jia-Ju Bai > > > > > --- > > > > >drivers/staging/irda/drivers/irda-usb.c | 2 +- > > > > >1 file changed, 1 insertion(+), 1 deletion(-) > > > > Please, at the very least, work off of Linus's tree. There is no > > > > drivers/staging/irda/ anymore :) > > > > > > > Okay, sorry. > > > Could you please recommend me a right tree or its git address? > > Have you looked in the MAINTAINERS file? Worst case, always use > > linux-next. > > > > greg k-h > > Oh, sorry, I did notice the git tree in the MAINTAINERS file. > I always used linux-stable. linux-stable is almost never the tree to use as it is almost always 12000 patches behind what is in Linus's tree and about 2 changes behind linux-next. thanks, greg k-h
[PATCH] cpuidle: menu: tidy up some indenting
These lines were indented 4 spaces less than they should have been. It
was a little confusing.
Signed-off-by: Dan Carpenter
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 1bfe03ceb236..b733dc6aa42b 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -426,8 +426,8 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev,
* tick, so try to correct that.
*/
for (i = idx - 1; i >= 0; i--) {
- if (drv->states[i].disabled ||
- dev->states_usage[i].disable)
+ if (drv->states[i].disabled ||
+ dev->states_usage[i].disable)
continue;
idx = i;
Re: [PATCH] ARM: dts: sunxi: Change sun7i-a20-olimex-som204-evb to not use cd-inverted
On Tue, Apr 10, 2018 at 05:51:19PM +0300, Tuomas Tynkkynen wrote:
> Commit 45e01f401a2a16 ("ARM: dts: sunxi: Switch MMC nodes away from
> cd-inverted property") changed most of the sunxi boards away from using
> the cd-inverted property in MMC nodes. However, the
> sun7i-a20-olimex-som204-evb board which got merged concurrently with
> that commit is now using cd-inverted. Switch it away from using
> cd-inverted to be consistent with rest of the sunxi boards.
>
> Signed-off-by: Tuomas Tynkkynen
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload
On 2018/4/11 16:17, Greg KH wrote: On Wed, Apr 11, 2018 at 04:11:00PM +0800, Jia-Ju Bai wrote: On 2018/4/11 16:03, Greg KH wrote: On Wed, Apr 11, 2018 at 03:17:10PM +0800, Jia-Ju Bai wrote: On 2018/4/11 14:41, Greg KH wrote: On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote: stir421x_fw_upload() is never called in atomic context. The call chain ending up at stir421x_fw_upload() is: [1] stir421x_fw_upload() <- stir421x_patch_device() <- irda_usb_probe() irda_usb_probe() is set as ".probe" in struct usb_driver. This function is not called in atomic context. Despite never getting called from atomic context, stir421x_fw_upload() calls mdelay() to busily wait. This is not necessary and can be replaced with usleep_range() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/staging/irda/drivers/irda-usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Please, at the very least, work off of Linus's tree. There is no drivers/staging/irda/ anymore :) Okay, sorry. Could you please recommend me a right tree or its git address? Have you looked in the MAINTAINERS file? Worst case, always use linux-next. greg k-h Oh, sorry, I did notice the git tree in the MAINTAINERS file. I always used linux-stable. linux-stable is almost never the tree to use as it is almost always 12000 patches behind what is in Linus's tree and about 2 changes behind linux-next. Okay, I now know why many of my patches were not replied. I should choose correct tree in the MAINTAINERS file. Thanks :) Best wishes, Jia-Ju Bai
Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support
On Tue, Apr 10, 2018 at 05:53:47PM +0200, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
>
> On many SoCs, devices are connected to an SoC-internal reset controller.
> If the reset hierarchy is described in DT using "resets" properties,
> such devices can be reset in a generic way through the reset controller
> subsystem. Hence add support for this, avoiding the need to write
> device-specific reset drivers for each single device on affected SoCs.
>
> Devices that do require a more complex reset procedure can still provide
> a device-specific reset driver, as that takes precedence.
>
> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
> becomes a no-op (as in: "No reset function found for device") if reset
> controller support is disabled.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> v2:
> - Don't store error values in vdev->reset_control,
> - Use of_reset_control_get_exclusive() instead of
> __of_reset_control_get(),
> - Improve description.
> ---
> drivers/vfio/platform/vfio_platform_common.c | 26 --
> drivers/vfio/platform/vfio_platform_private.h | 1 +
> 2 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/platform/vfio_platform_common.c
> b/drivers/vfio/platform/vfio_platform_common.c
> index b60bb5326668498c..3c13327b2777f8ec 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -112,11 +113,19 @@ static bool vfio_platform_has_reset(struct
> vfio_platform_device *vdev)
> if (VFIO_PLATFORM_IS_ACPI(vdev))
> return vfio_platform_acpi_has_reset(vdev);
>
> - return vdev->of_reset ? true : false;
> + if (vdev->of_reset)
> + return true;
> +
> + if (vdev->reset_control)
> + return true;
> +
> + return false;
I wonder if the above would be better expressed as:
return vdev->of_reset || vdev->reset_control;
> }
>
> static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
> {
> + struct reset_control *rstc;
> +
> if (VFIO_PLATFORM_IS_ACPI(vdev))
> return vfio_platform_acpi_has_reset(vdev) ? 0 : -ENOENT;
>
> @@ -127,8 +136,16 @@ static int vfio_platform_get_reset(struct
> vfio_platform_device *vdev)
> vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
> &vdev->reset_module);
> }
> + if (vdev->of_reset)
> + return 0;
> +
> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
> + if (!IS_ERR(rstc)) {
> + vdev->reset_control = rstc;
> + return 0;
> + }
>
> - return vdev->of_reset ? 0 : -ENOENT;
> + return PTR_ERR(rstc);
> }
>
> static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
> @@ -138,6 +155,8 @@ static void vfio_platform_put_reset(struct
> vfio_platform_device *vdev)
>
> if (vdev->of_reset)
> module_put(vdev->reset_module);
> +
> + reset_control_put(vdev->reset_control);
> }
>
> static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
> @@ -217,6 +236,9 @@ static int vfio_platform_call_reset(struct
> vfio_platform_device *vdev,
> } else if (vdev->of_reset) {
> dev_info(vdev->device, "reset\n");
> return vdev->of_reset(vdev);
> + } else if (vdev->reset_control) {
> + dev_info(vdev->device, "reset\n");
Would it be useful to differentiate between the above two informational
messages?
> + return reset_control_reset(vdev->reset_control);
> }
>
> dev_warn(vdev->device, "no reset function found!\n");
> diff --git a/drivers/vfio/platform/vfio_platform_private.h
> b/drivers/vfio/platform/vfio_platform_private.h
> index 85ffe5d9d1abd94e..a56e80ae5986540b 100644
> --- a/drivers/vfio/platform/vfio_platform_private.h
> +++ b/drivers/vfio/platform/vfio_platform_private.h
> @@ -60,6 +60,7 @@ struct vfio_platform_device {
> const char *compat;
> const char *acpihid;
> struct module *reset_module;
> + struct reset_control*reset_control;
> struct device *device;
>
> /*
> --
> 2.7.4
>
Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support
On Tue, 2018-04-10 at 17:53 +0200, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
>
> On many SoCs, devices are connected to an SoC-internal reset controller.
> If the reset hierarchy is described in DT using "resets" properties,
> such devices can be reset in a generic way through the reset controller
> subsystem. Hence add support for this, avoiding the need to write
> device-specific reset drivers for each single device on affected SoCs.
>
> Devices that do require a more complex reset procedure can still provide
> a device-specific reset driver, as that takes precedence.
>
> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
> becomes a no-op (as in: "No reset function found for device") if reset
> controller support is disabled.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Philipp Zabel
> ---
> v2:
> - Don't store error values in vdev->reset_control,
> - Use of_reset_control_get_exclusive() instead of
> __of_reset_control_get(),
> - Improve description.
> ---
> drivers/vfio/platform/vfio_platform_common.c | 26 --
> drivers/vfio/platform/vfio_platform_private.h | 1 +
> 2 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/platform/vfio_platform_common.c
> b/drivers/vfio/platform/vfio_platform_common.c
> index b60bb5326668498c..3c13327b2777f8ec 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
[...]
> @@ -127,8 +136,16 @@ static int vfio_platform_get_reset(struct
> vfio_platform_device *vdev)
> vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
> &vdev->reset_module);
> }
> + if (vdev->of_reset)
> + return 0;
> +
> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
If vdev->device->of_node == NULL, this will return -EINVAL ...
> + if (!IS_ERR(rstc)) {
> + vdev->reset_control = rstc;
> + return 0;
> + }
>
> - return vdev->of_reset ? 0 : -ENOENT;
> + return PTR_ERR(rstc);
... instead of -ENOENT, if that makes any difference.
regards
Philipp
Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5
On Wed, Apr 11, 2018 at 10:08:06AM +0200, Boris Brezillon wrote: > On Wed, 11 Apr 2018 09:36:56 +0200 > Ladislav Michl wrote: > > > Hi Boris, > > > > On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote: [...] > > > Not sure this approach is safe on all archs: if the cache is VIVT or > > > VIPT, you may have several entries pointing to the same phys page, and > > > then, when dma_map_page() does its cache maintenance operations, it's > > > only taking one of these entries into account. > > > > Hmm, I used the same approach Samsung OneNAND driver does since commit > > dcf08227e964a53a2cb39130b74842c7dcb6adde. > > Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which > > is VIPT. In that case samsung's driver code has the same problem. > > > > > In other parts of the MTD subsystem, we tend to not do DMA on buffers > > > that have been vmalloc-ed. > > > > > > You can do something like > > > > > > if (virt_addr_valid(buf)) > > > /* Use DMA */ > > > else > > > /* > > >* Do not use DMA, or use a bounce buffer > > >* allocated with kmalloc > > >*/ > > > > Okay, I'll use this approach then, but first I'd like to be sure above is > > correct. Anyone? > > See this discussion [1]. The problem came up a few times already, so > might find other threads describing why it's not safe. > > [1]https://lists.linuxfoundation.org/pipermail/iommu/2016-March/016240.html Question was more likely whenever there might exist more that one mapping of the same page. But okay, I'll disable DMA for highmem. Patch will follow. ladis
Re: [PATCH v2 1/2] MAINTAINERS: remove me as maintainer for I2C host drivers
On Tue, Apr 10, 2018 at 09:49:13PM +0200, Wolfram Sang wrote: > The number of I2C host controller drivers keeps increasing, and although > I had some success acquiring specific driver maintainers, my bandwidth > is by far not enough to act as a fallback for the rest of the drivers. > To reflect this status-quo in MAINTAINERS, add a seperate entry for I2C > host drivers, let the I2C list (= community) be the contact point, and > mark this section as "Odd fixes". > > Signed-off-by: Wolfram Sang Reviewed-by: Simon Horman
Re: [PATCH v2 2/2] MAINTAINERS: add maintainer for Renesas I2C related drivers
On Tue, Apr 10, 2018 at 09:49:14PM +0200, Wolfram Sang wrote: > From: Wolfram Sang > > Intentionally missing i2c-riic here, Chris Brandt will add himself for > that one later. > > Signed-off-by: Wolfram Sang Reviewed-by: Simon Horman
[PATCH 2/2] gpu: drm: ast: Replace mdelay with msleep in ast_post_chip_2500
ast_post_chip_2500() is never called in atomic context.
The call chains ending up at reset_mmc_2500() are:
[1] ast_post_chip_2500() <- ast_post_gpu() <- ast_drm_thaw()
[2] ast_post_chip_2500() <- ast_post_gpu() <- ast_driver_load()
ast_drm_thaw() calls console_lock() which can sleep.
ast_driver_load() is set as ".load" in struct drm_driver.
These functions are not called in atomic context.
Despite never getting called from atomic context, ast_post_chip_2500()
calls mdelay() to busily wait.
This is not necessary and can be replaced with msleep() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/ast/ast_post.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index f7d4213..67c5e50 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -2063,7 +2063,7 @@ void ast_post_chip_2500(struct drm_device *dev)
temp = ast_mindwm(ast, 0x1e6e2070);
if (temp & 0x0080) {
ast_moutdwm(ast, 0x1e6e207c, 0x0080);
- mdelay(100);
+ msleep(100);
ast_moutdwm(ast, 0x1e6e2070, 0x0080);
}
--
1.9.1
[PATCH 1/2] gpu: drm: ast: Replace mdelay with msleep in reset_mmc_2500
reset_mmc_2500() is never called in atomic context. The call chains ending up at reset_mmc_2500() are: [1] reset_mmc_2500() <- ast_dram_init_2500() <- ast_post_chip_2500() <- ast_post_gpu() <- ast_drm_thaw() [2] reset_mmc_2500() <- ast_dram_init_2500() <- ast_post_chip_2500() <- ast_post_gpu() <- ast_driver_load() ast_drm_thaw() calls console_lock() which can sleep. ast_driver_load() is set as ".load" in struct drm_driver. These functions are not called in atomic context. Despite never getting called from atomic context, reset_mmc_2500() calls mdelay() to busily wait. This is not necessary and can be replaced with msleep() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/gpu/drm/ast/ast_post.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c index f7d4213..12bbf64 100644 --- a/drivers/gpu/drm/ast/ast_post.c +++ b/drivers/gpu/drm/ast/ast_post.c @@ -1840,7 +1840,7 @@ static void reset_mmc_2500(struct ast_private *ast) ast_moutdwm(ast, 0x1E785044, 0x0001); ast_moutdwm(ast, 0x1E785048, 0x4755); ast_moutdwm(ast, 0x1E78504C, 0x0013); - mdelay(100); + msleep(100); ast_moutdwm(ast, 0x1E785054, 0x0077); ast_moutdwm(ast, 0x1E6E, 0xFC600309); } -- 1.9.1
Re: [PATCH v3 2/2] mm: remove odd HAVE_PTE_SPECIAL
On Wed 11-04-18 10:03:36, Laurent Dufour wrote:
> @@ -881,7 +876,8 @@ struct page *_vm_normal_page(struct vm_area_struct *vma,
> unsigned long addr,
>
> if (is_zero_pfn(pfn))
> return NULL;
> -check_pfn:
> +
> +check_pfn: __maybe_unused
> if (unlikely(pfn > highest_memmap_pfn)) {
> print_bad_pte(vma, addr, pte, NULL);
> return NULL;
> @@ -891,7 +887,7 @@ struct page *_vm_normal_page(struct vm_area_struct *vma,
> unsigned long addr,
>* NOTE! We still have PageReserved() pages in the page tables.
>* eg. VDSO mappings can cause them to exist.
>*/
> -out:
> +out: __maybe_unused
> return pfn_to_page(pfn);
Why do we need this ugliness all of the sudden?
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/2] ide: pdc202xx_new: Replace mdelay with usleep_range in detect_pll_input_clock
Hello! On 4/11/2018 10:52 AM, Jia-Ju Bai wrote: detect_pll_input_clock() is never called in atomic context. detect_pll_input_clock() is only called by init_chipset_pdcnew(), which is set as ".init_chipset" in struct ide_port_info. This function is not called in atomic context. Despite never getting called from atomic context, detect_pll_input_clock() calls mdelay() to busily wait. This is not necessary and can be replaced with usleep_range() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/ide/pdc202xx_new.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ide/pdc202xx_new.c b/drivers/ide/pdc202xx_new.c index b33646b..6afa66d 100644 --- a/drivers/ide/pdc202xx_new.c +++ b/drivers/ide/pdc202xx_new.c @@ -258,7 +258,7 @@ static long detect_pll_input_clock(unsigned long dma_base) outb(scr1 | 0x40, dma_base + 0x03); /* Let the counter run for 10 ms. */ - mdelay(10); + usleep_range(10); This function takes 2 arguments. [...] MBR, Sergei
[PATCH] gpu: drm: bridge: adv7511: Replace mdelay with usleep_range in adv7511_probe
adv7511_probe() is never called in atomic context.
This function is only set as ".probe" in struct i2c_driver.
Despite never getting called from atomic context, adv7511_probe()
calls mdelay() to busily wait.
This is not necessary and can be replaced with usleep_range() to
avoid busy waiting.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index b2431ae..2cf7fa1 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1054,7 +1054,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
}
if (adv7511->gpio_pd) {
- mdelay(5);
+ usleep_range(5000, 6000);
gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
}
--
1.9.1
Re: [PATCH v3 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL
On Wed 11-04-18 10:03:35, Laurent Dufour wrote: > Currently the PTE special supports is turned on in per architecture header > files. Most of the time, it is defined in arch/*/include/asm/pgtable.h > depending or not on some other per architecture static definition. > > This patch introduce a new configuration variable to manage this directly > in the Kconfig files. It would later replace __HAVE_ARCH_PTE_SPECIAL. > > Here notes for some architecture where the definition of > __HAVE_ARCH_PTE_SPECIAL is not obvious: > > arm > __HAVE_ARCH_PTE_SPECIAL which is currently defined in > arch/arm/include/asm/pgtable-3level.h which is included by > arch/arm/include/asm/pgtable.h when CONFIG_ARM_LPAE is set. > So select ARCH_HAS_PTE_SPECIAL if ARM_LPAE. > > powerpc > __HAVE_ARCH_PTE_SPECIAL is defined in 2 files: > - arch/powerpc/include/asm/book3s/64/pgtable.h > - arch/powerpc/include/asm/pte-common.h > The first one is included if (PPC_BOOK3S & PPC64) while the second is > included in all the other cases. > So select ARCH_HAS_PTE_SPECIAL all the time. > > sparc: > __HAVE_ARCH_PTE_SPECIAL is defined if defined(__sparc__) && > defined(__arch64__) which are defined through the compiler in > sparc/Makefile if !SPARC32 which I assume to be if SPARC64. > So select ARCH_HAS_PTE_SPECIAL if SPARC64 > > There is no functional change introduced by this patch. > > Suggested-by: Jerome Glisse > Reviewed-by: Jerome Glisse > Acked-by: David Rientjes > Signed-off-by: Laurent Dufour Looks good to me. I have checked x86 and the generic code and it looks good to me. Anyway arch maintainers really have to double check this. -- Michal Hocko SUSE Labs
Re: [PATCH 1/2] ide: pdc202xx_new: Replace mdelay with usleep_range in detect_pll_input_clock
On 2018/4/11 16:33, Sergei Shtylyov wrote: Hello! On 4/11/2018 10:52 AM, Jia-Ju Bai wrote: detect_pll_input_clock() is never called in atomic context. detect_pll_input_clock() is only called by init_chipset_pdcnew(), which is set as ".init_chipset" in struct ide_port_info. This function is not called in atomic context. Despite never getting called from atomic context, detect_pll_input_clock() calls mdelay() to busily wait. This is not necessary and can be replaced with usleep_range() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- drivers/ide/pdc202xx_new.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ide/pdc202xx_new.c b/drivers/ide/pdc202xx_new.c index b33646b..6afa66d 100644 --- a/drivers/ide/pdc202xx_new.c +++ b/drivers/ide/pdc202xx_new.c @@ -258,7 +258,7 @@ static long detect_pll_input_clock(unsigned long dma_base) outb(scr1 | 0x40, dma_base + 0x03); /* Let the counter run for 10 ms. */ -mdelay(10); +usleep_range(10); This function takes 2 arguments. [...] MBR, Sergei Oops, sorry for my fault. Thanks for telling me this :) I will modify it and send V2. Best wishes, Jia-Ju Bai
Re: [PATCH] pinctrl/samsung: Correct EINTG banks order
2018-04-10 17:38 GMT+09:00 Tomasz Figa : > 2018-04-10 16:06 GMT+09:00 Krzysztof Kozlowski : >> On Sun, Apr 8, 2018 at 8:07 PM, Paweł Chmiel >> wrote: >>> All banks with GPIO interrupts should be at beginning >>> of bank array and without any other types of banks between them. >>> This order is expected by exynos_eint_gpio_irq, when doing >>> interrupt group to bank translation. >>> Otherwise, kernel NULL pointer dereference would happen >>> when trying to handle interrupt, due to wrong bank being looked up. >>> Observed on s5pv210, when trying to handle gpj0 interrupt, >>> where kernel was mapping it to gpi bank. >> >> Thanks for the patch. The issue looks real although one thing was >> missed - there is a gap in SVC group between GPK2 and GPL0 (pointed by >> Marek Szyprowski): >> >> 0x0 - EINT_23 - gpk0 >> 0x1 - EINT_24 - gpk1 >> 0x2 - EINT_25 - gpk2 >> 0x4 - EINT_27 - gpl0 >> 0x7 - EINT_8 - gpm0 >> >> Maybe this should be done differently - to remove such hidden >> requirement entirely in favor of another parameter of >> EXYNOS_PIN_BANK_EINTG argument? > > Perhaps let's limit this patch to s5pv210 and Exynos5410 alone, where > a simple swap of bank order in the arrays should be okay. > > We might also need to have some fixes on 4x12, because I noticed that > in exynos4x12_pin_banks0[] there is a hole in eint_offsets between > gpd1 and gpf0 and exynos4x12_pin_banks1[] starts with gpk0 that has > eint_offset equal to 0x08 (not 0). To close the loop, after talking offline and checking the documentation, Exynos4x12 is fine, because the group numbers in SVC register actually match what is defined in bank arrays. Best regards, Tomasz
Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support
Hi Simon,
On Wed, Apr 11, 2018 at 10:22 AM, Simon Horman wrote:
> On Tue, Apr 10, 2018 at 05:53:47PM +0200, Geert Uytterhoeven wrote:
>> Vfio-platform requires reset support, provided either by ACPI, or, on DT
>> platforms, by a device-specific reset driver matching against the
>> device's compatible value.
>>
>> On many SoCs, devices are connected to an SoC-internal reset controller.
>> If the reset hierarchy is described in DT using "resets" properties,
>> such devices can be reset in a generic way through the reset controller
>> subsystem. Hence add support for this, avoiding the need to write
>> device-specific reset drivers for each single device on affected SoCs.
>>
>> Devices that do require a more complex reset procedure can still provide
>> a device-specific reset driver, as that takes precedence.
>>
>> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
>> becomes a no-op (as in: "No reset function found for device") if reset
>> controller support is disabled.
>>
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> v2:
>> - Don't store error values in vdev->reset_control,
>> - Use of_reset_control_get_exclusive() instead of
>> __of_reset_control_get(),
>> - Improve description.
>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>> @@ -17,6 +17,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -112,11 +113,19 @@ static bool vfio_platform_has_reset(struct
>> vfio_platform_device *vdev)
>> if (VFIO_PLATFORM_IS_ACPI(vdev))
>> return vfio_platform_acpi_has_reset(vdev);
>>
>> - return vdev->of_reset ? true : false;
>> + if (vdev->of_reset)
>> + return true;
>> +
>> + if (vdev->reset_control)
>> + return true;
>> +
>> + return false;
>
> I wonder if the above would be better expressed as:
>
> return vdev->of_reset || vdev->reset_control;
Makes sense, now both checks are of the same type.
>> @@ -217,6 +236,9 @@ static int vfio_platform_call_reset(struct
>> vfio_platform_device *vdev,
>> } else if (vdev->of_reset) {
>> dev_info(vdev->device, "reset\n");
>> return vdev->of_reset(vdev);
>> + } else if (vdev->reset_control) {
>> + dev_info(vdev->device, "reset\n");
>
> Would it be useful to differentiate between the above two informational
> messages?
Probably not, there's also no differentiation with the message for the
ACPI case above (out of visible context).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[GIT PULL] Thermal management updates for v4.17-rc1
Hi, Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
to receive the latest Thermal Management updates for v4.17-rc1 with
top-most commit f8837aac36cdc7430422cd65f4466071b42654bb:
Merge branches 'thermal-core' and 'thermal-soc' into next (2018-04-02
21:49:31 +0800)
on top of commit 0c8efd610b58cb23cefdfa12015799079aef94ae:
Linux 4.16-rc5 (2018-03-11 17:25:09 -0700)
Specifics:
- Fix race condition in imx_thermal_probe(). (Mikhail Lappo)
- Add cooling device's statistics in sysfs. (Viresh Kumar)
- add support for i.MX7 thermal sensor in imx_thermal driver. (Anson
Huang)
- add support for MT7622 SoC in mtk_thermal driver. (Sean Wang)
- Remove unused min/max cpu cooling DT property. (Viresh Kumar).
- A series of fixes on exynos driver. (Bartlomiej Zolnierkiewicz,
Maciej Purski, Marek Szyprowski)
thanks,
rui
Anson Huang (1):
thermal: imx: add i.MX7 thermal sensor support
Bartlomiej Zolnierkiewicz (10):
thermal: exynos: remove unused "type" field from struct
exynos_tmu_platform_data
thermal: exynos: remove parsing of samsung,
tmu_default_temp_offset property
thermal: exynos: remove parsing of samsung, tmu_[first,
second]_point_trim properties
thermal: exynos: remove parsing of samsung, tmu_noise_cancel_mode
property
thermal: exynos: remove parsing of samsung, tmu[_min,
_max]_efuse_value properties
thermal: exynos: remove parsing of samsung, tmu_reference_voltage
property
thermal: exynos: remove parsing of samsung,tmu_gain property
thermal: exynos: remove parsing of samsung, tmu_cal_type property
thermal: exynos: remove separate exynos_tmu.h header file
dt-bindings: thermal: remove no longer needed samsung thermal
properties
Maciej Purski (1):
thermal: exynos: Read soc_type from match data
Marek Szyprowski (2):
thermal: exynos: Reading temperature makes sense only when TMU is
turned on
thermal: exynos: Propagate error value from tmu_read()
Mikhail Lappo (1):
thermal: imx: Fix race condition in imx_thermal_probe()
Sean Wang (2):
dt-bindings: thermal: add binding for MT7622 SoC
thermal: mediatek: add support for MT7622 SoC
Viresh Kumar (2):
dt-bindings: thermal: Remove "cooling-{min|max}-level" properties
thermal: Add cooling device's statistics in sysfs
Zhang Rui (2):
Merge branch 'linus' of git://git.kernel.org/.../evalenti/linux-
soc-thermal into thermal-soc
Merge branches 'thermal-core' and 'thermal-soc' into next
.../devicetree/bindings/thermal/exynos-thermal.txt | 23 +-
.../devicetree/bindings/thermal/imx-thermal.txt| 9 +-
.../bindings/thermal/mediatek-thermal.txt | 1 +
.../devicetree/bindings/thermal/thermal.txt| 16 +-
Documentation/thermal/sysfs-api.txt| 31 +++
drivers/thermal/Kconfig| 7 +
drivers/thermal/imx_thermal.c | 301
-
drivers/thermal/mtk_thermal.c | 35 +++
drivers/thermal/samsung/exynos_tmu.c | 268 +--
---
drivers/thermal/samsung/exynos_tmu.h | 75 -
drivers/thermal/thermal_core.c | 3 +-
drivers/thermal/thermal_core.h | 10 +
drivers/thermal/thermal_helpers.c | 5 +-
drivers/thermal/thermal_sysfs.c| 225
+++
include/linux/thermal.h| 1 +
15 files changed, 706 insertions(+), 304 deletions(-)
delete mode 100644 drivers/thermal/samsung/exynos_tmu.h
Re: [PATCH v3 2/2] mm: remove odd HAVE_PTE_SPECIAL
On 11/04/2018 10:33, Michal Hocko wrote:
> On Wed 11-04-18 10:03:36, Laurent Dufour wrote:
>> @@ -881,7 +876,8 @@ struct page *_vm_normal_page(struct vm_area_struct *vma,
>> unsigned long addr,
>>
>> if (is_zero_pfn(pfn))
>> return NULL;
>> -check_pfn:
>> +
>> +check_pfn: __maybe_unused
>> if (unlikely(pfn > highest_memmap_pfn)) {
>> print_bad_pte(vma, addr, pte, NULL);
>> return NULL;
>> @@ -891,7 +887,7 @@ struct page *_vm_normal_page(struct vm_area_struct *vma,
>> unsigned long addr,
>> * NOTE! We still have PageReserved() pages in the page tables.
>> * eg. VDSO mappings can cause them to exist.
>> */
>> -out:
>> +out: __maybe_unused
>> return pfn_to_page(pfn);
>
> Why do we need this ugliness all of the sudden?
Indeed the compiler doesn't complaint but in theory it should since these
labels are not used depending on CONFIG_ARCH_HAS_PTE_SPECIAL.
[PATCH 1/2 v2] ide: pdc202xx_new: Replace mdelay with usleep_range in detect_pll_input_clock
detect_pll_input_clock() is never called in atomic context. detect_pll_input_clock() is only called by init_chipset_pdcnew(), which is set as ".init_chipset" in struct ide_port_info. This function is not called in atomic context. Despite never getting called from atomic context, detect_pll_input_clock() calls mdelay() to busily wait. This is not necessary and can be replaced with usleep_range() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai --- v2: * Correct wrong usage of usleep_range() in v1. Thank Sergei for pointing it out. --- drivers/ide/pdc202xx_new.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ide/pdc202xx_new.c b/drivers/ide/pdc202xx_new.c index b33646b..6afa66d 100644 --- a/drivers/ide/pdc202xx_new.c +++ b/drivers/ide/pdc202xx_new.c @@ -258,7 +258,7 @@ static long detect_pll_input_clock(unsigned long dma_base) outb(scr1 | 0x40, dma_base + 0x03); /* Let the counter run for 10 ms. */ - mdelay(10); + usleep_range(1, 11000); end_count = read_counter(dma_base); end_time = ktime_get(); -- 1.9.1
Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support
Hi Philipp,
On Wed, Apr 11, 2018 at 10:22 AM, Philipp Zabel wrote:
> On Tue, 2018-04-10 at 17:53 +0200, Geert Uytterhoeven wrote:
>> Vfio-platform requires reset support, provided either by ACPI, or, on DT
>> platforms, by a device-specific reset driver matching against the
>> device's compatible value.
>>
>> On many SoCs, devices are connected to an SoC-internal reset controller.
>> If the reset hierarchy is described in DT using "resets" properties,
>> such devices can be reset in a generic way through the reset controller
>> subsystem. Hence add support for this, avoiding the need to write
>> device-specific reset drivers for each single device on affected SoCs.
>>
>> Devices that do require a more complex reset procedure can still provide
>> a device-specific reset driver, as that takes precedence.
>>
>> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
>> becomes a no-op (as in: "No reset function found for device") if reset
>> controller support is disabled.
>>
>> Signed-off-by: Geert Uytterhoeven
>
> Reviewed-by: Philipp Zabel
Thanks!
>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c
> [...]
>> @@ -127,8 +136,16 @@ static int vfio_platform_get_reset(struct
>> vfio_platform_device *vdev)
>> vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>> &vdev->reset_module);
>> }
>> + if (vdev->of_reset)
>> + return 0;
>> +
>> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
>
> If vdev->device->of_node == NULL, this will return -EINVAL ...
>
>> + if (!IS_ERR(rstc)) {
>> + vdev->reset_control = rstc;
>> + return 0;
>> + }
>>
>> - return vdev->of_reset ? 0 : -ENOENT;
>> + return PTR_ERR(rstc);
>
> ... instead of -ENOENT, if that makes any difference.
Not really. The single caller (vfio_platform_probe_common()) already returns
-EINVAL if no IOMMU group is found, so this should be handled fine.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCHv2] misc: tifm: Remove VLA
On Wed, Apr 11, 2018 at 3:04 AM, Laura Abbott wrote: > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. The single VLA can either take a value of 2 or 4 so switch > to the upper bound. > > [1] https://lkml.org/lkml/2018/3/7/621 > > Signed-off-by: Laura Abbott Thanks for the new version, Acked-by: Arnd Bergmann
[PATCH for-4.4] writeback: safer lock nesting
lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if
the page's memcg is undergoing move accounting, which occurs when a
process leaves its memcg for a new one that has
memory.move_charge_at_immigrate set.
unlocked_inode_to_wb_begin,end() use spin_lock_irq/spin_unlock_irq() if the
given inode is switching writeback domains. Switches occur when enough
writes are issued from a new domain.
This existing pattern is thus suspicious:
lock_page_memcg(page);
unlocked_inode_to_wb_begin(inode, &locked);
...
unlocked_inode_to_wb_end(inode, locked);
unlock_page_memcg(page);
If both inode switch and process memcg migration are both in-flight then
unlocked_inode_to_wb_end() will unconditionally enable interrupts while
still holding the lock_page_memcg() irq spinlock. This suggests the
possibility of deadlock if an interrupt occurs before
unlock_page_memcg().
truncate
__cancel_dirty_page
lock_page_memcg
unlocked_inode_to_wb_begin
unlocked_inode_to_wb_end
end_page_writeback
test_clear_page_writeback
lock_page_memcg
unlock_page_memcg
Due to configuration limitations this deadlock is not currently possible
because we don't mix cgroup writeback (a cgroupv2 feature) and
memory.move_charge_at_immigrate (a cgroupv1 feature).
If the kernel is hacked to always claim inode switching and memcg
moving_account, then this script triggers lockup in less than a minute:
cd /mnt/cgroup/memory
mkdir a b
echo 1 > a/memory.move_charge_at_immigrate
echo 1 > b/memory.move_charge_at_immigrate
(
echo $BASHPID > a/cgroup.procs
while true; do
dd if=/dev/zero of=/mnt/big bs=1M count=256
done
) &
while true; do
sync
done &
sleep 1h &
SLEEP=$!
while true; do
echo $SLEEP > a/cgroup.procs
echo $SLEEP > b/cgroup.procs
done
The deadlock does not seem possible, so it's debatable if there's
any reason to modify the kernel. I suggest we should to prevent future
surprises. And Wang Long said "this deadlock occurs three times in our
environment", so there's more reason to apply this, even to stable.
[ This patch is only for 4.4 stable. Newer stable kernels should use be able to
cherry pick the upstream "writeback: safer lock nesting" patch. ]
Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and
use it for stat updates")
Cc: sta...@vger.kernel.org # v4.2+
Reported-by: Wang Long
Signed-off-by: Greg Thelen
Acked-by: Michal Hocko
Acked-by: Wang Long
---
fs/fs-writeback.c| 7 ---
include/linux/backing-dev-defs.h | 5 +
include/linux/backing-dev.h | 31 +--
mm/page-writeback.c | 18 +-
4 files changed, 35 insertions(+), 26 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 22b30249fbcb..0fe667875852 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -747,11 +747,12 @@ int inode_congested(struct inode *inode, int cong_bits)
*/
if (inode && inode_to_wb_is_valid(inode)) {
struct bdi_writeback *wb;
- bool locked, congested;
+ struct wb_lock_cookie lock_cookie = {};
+ bool congested;
- wb = unlocked_inode_to_wb_begin(inode, &locked);
+ wb = unlocked_inode_to_wb_begin(inode, &lock_cookie);
congested = wb_congested(wb, cong_bits);
- unlocked_inode_to_wb_end(inode, locked);
+ unlocked_inode_to_wb_end(inode, &lock_cookie);
return congested;
}
diff --git a/include/linux/backing-dev-defs.h b/include/linux/backing-dev-defs.h
index 140c29635069..a307c37c2e6c 100644
--- a/include/linux/backing-dev-defs.h
+++ b/include/linux/backing-dev-defs.h
@@ -191,6 +191,11 @@ static inline void set_bdi_congested(struct
backing_dev_info *bdi, int sync)
set_wb_congested(bdi->wb.congested, sync);
}
+struct wb_lock_cookie {
+ bool locked;
+ unsigned long flags;
+};
+
#ifdef CONFIG_CGROUP_WRITEBACK
/**
diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
index 89d3de3e096b..361274ce5815 100644
--- a/include/linux/backing-dev.h
+++ b/include/linux/backing-dev.h
@@ -366,7 +366,7 @@ static inline struct bdi_writeback *inode_to_wb(struct
inode *inode)
/**
* unlocked_inode_to_wb_begin - begin unlocked inode wb access transaction
* @inode: target inode
- * @lockedp: temp bool output param, to be passed to the end function
+ * @cookie: output param, to be passed to the end function
*
* The caller wants to access the wb associated with @inode but isn't
* holding inode->i_lock, mapping->tree_lock or wb->list_lock. This
@@ -374,12 +374,12 @@ static inline struct bdi_writeback *inode_to_wb(struct
inode *inode)
* as
YOUR URGENT REPLY FOR MORE DETAILS!!
Compliment of the day, I am Mr.Kere Casmire I Have a Business Proposal of $5.3 million For You. I am aware of the unsafe nature of the internet, and was compelled to use this medium due to the nature of this project. I have access to very vital information that can be used to transfer this huge amount of money, which may culminate into the investment of the said funds into your company or any lucrative venture in your country. If you will like to assist me as a partner then indicate your interest, after which we shall both discuss the modalities and the sharing percentage. Upon receipt of your reply on your expression of Interest I will give you full details, on how the business will be executed I am open for negotiation. You should forward your reply to this private email id (casimireker...@gmail.com) Thanks for your anticipated cooperation. Note you might receive this message in your inbox or spam or junk folder, depends on your web host or server network. Regards, Mr.Kere Casmire
[PATCH v4] writeback: safer lock nesting
lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if
the page's memcg is undergoing move accounting, which occurs when a
process leaves its memcg for a new one that has
memory.move_charge_at_immigrate set.
unlocked_inode_to_wb_begin,end() use spin_lock_irq/spin_unlock_irq() if the
given inode is switching writeback domains. Switches occur when enough
writes are issued from a new domain.
This existing pattern is thus suspicious:
lock_page_memcg(page);
unlocked_inode_to_wb_begin(inode, &locked);
...
unlocked_inode_to_wb_end(inode, locked);
unlock_page_memcg(page);
If both inode switch and process memcg migration are both in-flight then
unlocked_inode_to_wb_end() will unconditionally enable interrupts while
still holding the lock_page_memcg() irq spinlock. This suggests the
possibility of deadlock if an interrupt occurs before
unlock_page_memcg().
truncate
__cancel_dirty_page
lock_page_memcg
unlocked_inode_to_wb_begin
unlocked_inode_to_wb_end
end_page_writeback
test_clear_page_writeback
lock_page_memcg
unlock_page_memcg
Due to configuration limitations this deadlock is not currently possible
because we don't mix cgroup writeback (a cgroupv2 feature) and
memory.move_charge_at_immigrate (a cgroupv1 feature).
If the kernel is hacked to always claim inode switching and memcg
moving_account, then this script triggers lockup in less than a minute:
cd /mnt/cgroup/memory
mkdir a b
echo 1 > a/memory.move_charge_at_immigrate
echo 1 > b/memory.move_charge_at_immigrate
(
echo $BASHPID > a/cgroup.procs
while true; do
dd if=/dev/zero of=/mnt/big bs=1M count=256
done
) &
while true; do
sync
done &
sleep 1h &
SLEEP=$!
while true; do
echo $SLEEP > a/cgroup.procs
echo $SLEEP > b/cgroup.procs
done
The deadlock does not seem possible, so it's debatable if there's
any reason to modify the kernel. I suggest we should to prevent future
surprises. And Wang Long said "this deadlock occurs three times in our
environment", so there's more reason to apply this, even to stable.
Stable 4.4 has minor conflicts applying this patch.
For a clean 4.4 patch see "[PATCH for-4.4] writeback: safer lock nesting"
https://lkml.org/lkml/2018/4/11/146
Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and
use it for stat updates")
Cc: sta...@vger.kernel.org # v4.2+
Reported-by: Wang Long
Signed-off-by: Greg Thelen
Acked-by: Michal Hocko
Acked-by: Wang Long
---
Changelog since v3:
- initialize wb_lock_cookie wiht {} rather than {0}.
- comment grammar fix
- commit log footer cleanup (-Change-Id, +Fixes, +Acks, +stable), though patch
does not cleanly apply to 4.4. I'll post a 4.4-stable specific patch.
Changelog since v2:
- explicitly initialize wb_lock_cookie to silence compiler warnings.
Changelog since v1:
- add wb_lock_cookie to record lock context.
fs/fs-writeback.c| 7 ---
include/linux/backing-dev-defs.h | 5 +
include/linux/backing-dev.h | 31 +--
mm/page-writeback.c | 18 +-
4 files changed, 35 insertions(+), 26 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 1280f915079b..b1178acfcb08 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -745,11 +745,12 @@ int inode_congested(struct inode *inode, int cong_bits)
*/
if (inode && inode_to_wb_is_valid(inode)) {
struct bdi_writeback *wb;
- bool locked, congested;
+ struct wb_lock_cookie lock_cookie = {};
+ bool congested;
- wb = unlocked_inode_to_wb_begin(inode, &locked);
+ wb = unlocked_inode_to_wb_begin(inode, &lock_cookie);
congested = wb_congested(wb, cong_bits);
- unlocked_inode_to_wb_end(inode, locked);
+ unlocked_inode_to_wb_end(inode, &lock_cookie);
return congested;
}
diff --git a/include/linux/backing-dev-defs.h b/include/linux/backing-dev-defs.h
index bfe86b54f6c1..0bd432a4d7bd 100644
--- a/include/linux/backing-dev-defs.h
+++ b/include/linux/backing-dev-defs.h
@@ -223,6 +223,11 @@ static inline void set_bdi_congested(struct
backing_dev_info *bdi, int sync)
set_wb_congested(bdi->wb.congested, sync);
}
+struct wb_lock_cookie {
+ bool locked;
+ unsigned long flags;
+};
+
#ifdef CONFIG_CGROUP_WRITEBACK
/**
diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
index 3e4ce54d84ab..96f4a3ddfb81 100644
--- a/include/linux/backing-dev.h
+++ b/include/linux/backing-dev.h
@@ -346,7 +346,7 @@ static inline struct bdi_writeback *inode_to_wb(const
struct inode *inode)
/**
* unlocked_inode_to_wb_begin - begin unlocked inod
Re: [PATCH v3 2/2] mm: remove odd HAVE_PTE_SPECIAL
On Wed 11-04-18 10:41:23, Laurent Dufour wrote:
> On 11/04/2018 10:33, Michal Hocko wrote:
> > On Wed 11-04-18 10:03:36, Laurent Dufour wrote:
> >> @@ -881,7 +876,8 @@ struct page *_vm_normal_page(struct vm_area_struct
> >> *vma, unsigned long addr,
> >>
> >>if (is_zero_pfn(pfn))
> >>return NULL;
> >> -check_pfn:
> >> +
> >> +check_pfn: __maybe_unused
> >>if (unlikely(pfn > highest_memmap_pfn)) {
> >>print_bad_pte(vma, addr, pte, NULL);
> >>return NULL;
> >> @@ -891,7 +887,7 @@ struct page *_vm_normal_page(struct vm_area_struct
> >> *vma, unsigned long addr,
> >> * NOTE! We still have PageReserved() pages in the page tables.
> >> * eg. VDSO mappings can cause them to exist.
> >> */
> >> -out:
> >> +out: __maybe_unused
> >>return pfn_to_page(pfn);
> >
> > Why do we need this ugliness all of the sudden?
> Indeed the compiler doesn't complaint but in theory it should since these
> labels are not used depending on CONFIG_ARCH_HAS_PTE_SPECIAL.
Well, such a warning would be quite pointless so I would rather not make
the code ugly. The value of unused label is quite questionable to start
with...
--
Michal Hocko
SUSE Labs
Re: [PATCH for-4.4] writeback: safer lock nesting
On Wed, Apr 11, 2018 at 1:45 AM Greg Thelen wrote:
> lock_page_memcg()/unlock_page_memcg() use spin_lock_irqsave/restore() if
> the page's memcg is undergoing move accounting, which occurs when a
> process leaves its memcg for a new one that has
> memory.move_charge_at_immigrate set.
> unlocked_inode_to_wb_begin,end() use spin_lock_irq/spin_unlock_irq() if
the
> given inode is switching writeback domains. Switches occur when enough
> writes are issued from a new domain.
> This existing pattern is thus suspicious:
> lock_page_memcg(page);
> unlocked_inode_to_wb_begin(inode, &locked);
> ...
> unlocked_inode_to_wb_end(inode, locked);
> unlock_page_memcg(page);
> If both inode switch and process memcg migration are both in-flight then
> unlocked_inode_to_wb_end() will unconditionally enable interrupts while
> still holding the lock_page_memcg() irq spinlock. This suggests the
> possibility of deadlock if an interrupt occurs before
> unlock_page_memcg().
> truncate
> __cancel_dirty_page
> lock_page_memcg
> unlocked_inode_to_wb_begin
> unlocked_inode_to_wb_end
>
>
> end_page_writeback
> test_clear_page_writeback
> lock_page_memcg
>
> unlock_page_memcg
> Due to configuration limitations this deadlock is not currently possible
> because we don't mix cgroup writeback (a cgroupv2 feature) and
> memory.move_charge_at_immigrate (a cgroupv1 feature).
> If the kernel is hacked to always claim inode switching and memcg
> moving_account, then this script triggers lockup in less than a minute:
>cd /mnt/cgroup/memory
>mkdir a b
>echo 1 > a/memory.move_charge_at_immigrate
>echo 1 > b/memory.move_charge_at_immigrate
>(
> echo $BASHPID > a/cgroup.procs
> while true; do
>dd if=/dev/zero of=/mnt/big bs=1M count=256
> done
>) &
>while true; do
> sync
>done &
>sleep 1h &
>SLEEP=$!
>while true; do
> echo $SLEEP > a/cgroup.procs
> echo $SLEEP > b/cgroup.procs
>done
> The deadlock does not seem possible, so it's debatable if there's
> any reason to modify the kernel. I suggest we should to prevent future
> surprises. And Wang Long said "this deadlock occurs three times in our
> environment", so there's more reason to apply this, even to stable.
Wang Long: I wasn't able to reproduce the 4.4 problem. But tracing
suggests this 4.4 patch is effective. If you can reproduce the problem in
your 4.4 environment, then it'd be nice to confirm this fixes it. Thanks!
> [ This patch is only for 4.4 stable. Newer stable kernels should use be
able to
>cherry pick the upstream "writeback: safer lock nesting" patch. ]
> Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb
transaction and use it for stat updates")
> Cc: sta...@vger.kernel.org # v4.2+
> Reported-by: Wang Long
> Signed-off-by: Greg Thelen
> Acked-by: Michal Hocko
> Acked-by: Wang Long
> ---
> fs/fs-writeback.c| 7 ---
> include/linux/backing-dev-defs.h | 5 +
> include/linux/backing-dev.h | 31 +--
> mm/page-writeback.c | 18 +-
> 4 files changed, 35 insertions(+), 26 deletions(-)
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index 22b30249fbcb..0fe667875852 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -747,11 +747,12 @@ int inode_congested(struct inode *inode, int
cong_bits)
> */
> if (inode && inode_to_wb_is_valid(inode)) {
> struct bdi_writeback *wb;
> - bool locked, congested;
> + struct wb_lock_cookie lock_cookie = {};
> + bool congested;
> - wb = unlocked_inode_to_wb_begin(inode, &locked);
> + wb = unlocked_inode_to_wb_begin(inode, &lock_cookie);
> congested = wb_congested(wb, cong_bits);
> - unlocked_inode_to_wb_end(inode, locked);
> + unlocked_inode_to_wb_end(inode, &lock_cookie);
> return congested;
> }
> diff --git a/include/linux/backing-dev-defs.h
b/include/linux/backing-dev-defs.h
> index 140c29635069..a307c37c2e6c 100644
> --- a/include/linux/backing-dev-defs.h
> +++ b/include/linux/backing-dev-defs.h
> @@ -191,6 +191,11 @@ static inline void set_bdi_congested(struct
backing_dev_info *bdi, int sync)
> set_wb_congested(bdi->wb.congested, sync);
> }
> +struct wb_lock_cookie {
> + bool locked;
> + unsigned long flags;
> +};
> +
> #ifdef CONFIG_CGROUP_WRITEBACK
> /**
> diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
> index 89d3de3e096b..361274ce5815 100644
> --- a/include/linux/backing-dev.h
> +++ b/include/linux/backing-dev.h
> @@ -366,7 +366,7 @@ static inline
3 version of MKDEV: kernel, uapi, libc, why?
Hi, Greg, Thomas
I find 3 version of MKDEV (actually 2 + makedev)
in include/linux/kdev_t.h
#define MINORBITS 20
#define MKDEV(ma,mi)(((ma) << MINORBITS) | (mi))
in inlcude/uapi/linux/kdev_t.h
#define MKDEV(ma,mi)((ma)<<8 | (mi))
in Android bionic
#define makedev(__major, __minor) \
( \
(((__major) & 0xf000ULL) << 32) | (((__major) & 0xfffULL) <<
8) | \
(((__minor) & 0xff00ULL) << 12) | (((__minor) & 0xffULL)) \
)
if I use mknod("renderD128", S_IFCHR|0666, MKDEV(226, 128));
I get wrong device:
crw-rw-rw- 1 root graphics 0, 57984 2011-11-11 11:20 renderD128
if I use ("renderD128",S_IFCHR|0666, makedev(226, 128));
I get right device.
but, when I use: mknod("card0", S_IFCHR|0666, MKDEV(226, 0));
I can get right device.
BR.
Ning.
Re: [PATCH] MAINTAINERS: Update ASPEED entry with details
On Wed, Apr 11, 2018 at 6:06 AM, Joel Stanley wrote: > Hey Arnd, > > On 22 February 2018 at 15:33, Joel Stanley wrote: >> I am interested in all ASPEED drivers, and the previous match wasn't >> grabbing files in nested directories. Use N instead. >> >> Add the arm kernel mailing list so that patches get reviewed there, and >> the linux-aspeed list which exists only so I can use patchwork to track >> patches. >> >> Add Andrew as a reviewer, because he is involved in reviewing ASPEED >> stuff. >> >> Signed-off-by: Joel Stanley > > can you please pick this one up? It would be great to get it into > fixes as Andrew and I have been missing being cc'd on stuff we would > have like to review. Sure, applied to the fixes branch now. In general, when you want a patch to be applied, please send it to a...@kernel.org so we know it's for us. As a rule, I don't pick up patches otherwise but assume that you are asking for feedback and/or Acks but will resend it once everyone is happy with the change. Arnd
Re: [PATCH v3 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver
On 05-04-18, 18:16, Daniel Lezcano wrote: > The cpu idle cooling driver performs synchronized idle injection across all > cpus belonging to the same cluster and offers a new method to cool down a SoC. > > Each cluster has its own idle cooling device, each core has its own idle > injection thread, each idle injection thread uses play_idle to enter idle. In > order to reach the deepest idle state, each cooling device has the idle > injection threads synchronized together. > > It has some similarity with the intel power clamp driver but it is actually > designed to work on the ARM architecture via the DT with a mathematical proof > with the power model which comes with the Documentation. > > The idle injection cycle is fixed while the running cycle is variable. That > allows to have control on the device reactivity for the user experience. At > the mitigation point the idle threads are unparked, they play idle the > specified amount of time and they schedule themselves. The last thread sets > the next idle injection deadline and when the timer expires it wakes up all > the threads which in turn play idle again. Meanwhile the running cycle is > changed by set_cur_state. When the mitigation ends, the threads are parked. > The algorithm is self adaptive, so there is no need to handle hotplugging. > > If we take an example of the balanced point, we can use the DT for the hi6220. > > The sustainable power for the SoC is 3326mW to mitigate at 75°C. Eight cores > running at full blast at the maximum OPP consumes 5280mW. The first value is > given in the DT, the second is calculated from the OPP with the formula: > >Pdyn = Cdyn x Voltage^2 x Frequency > > As the SoC vendors don't want to share the static leakage values, we assume > it is zero, so the Prun = Pdyn + Pstatic = Pdyn + 0 = Pdyn. > > In order to reduce the power to 3326mW, we have to apply a ratio to the > running time. > > ratio = (Prun - Ptarget) / Ptarget = (5280 - 3326) / 3326 = 0,5874 > > We know the idle cycle which is fixed, let's assume 10ms. However from this > duration we have to substract the wake up latency for the cluster idle state. > In our case, it is 1.5ms. So for a 10ms latency for idle, we are really idle > 8.5ms. > > As we know the idle duration and the ratio, we can compute the running cycle. > >running_cycle = 8.5 / 0.5874 = 14.47ms > > So for 8.5ms of idle, we have 14.47ms of running cycle, and that brings the > SoC to the balanced trip point of 75°C. > > The driver has been tested on the hi6220 and it appears the temperature > stabilizes at 75°C with an idle injection time of 10ms (8.5ms real) and > running cycle of 14ms as expected by the theory above. > > Signed-off-by: Kevin Wangtao > Signed-off-by: Daniel Lezcano > --- > drivers/thermal/Kconfig | 10 + > drivers/thermal/cpu_cooling.c | 479 > ++ > include/linux/cpu_cooling.h | 6 + > 3 files changed, 495 insertions(+) > > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > index 5aaae1b..6c34117 100644 > --- a/drivers/thermal/Kconfig > +++ b/drivers/thermal/Kconfig > @@ -166,6 +166,16 @@ config CPU_FREQ_THERMAL > This will be useful for platforms using the generic thermal interface > and not the ACPI interface. > > +config CPU_IDLE_THERMAL > + bool "CPU idle cooling strategy" > + depends on CPU_IDLE > + help > + This implements the generic CPU cooling mechanism through > + idle injection. This will throttle the CPU by injecting > + fixed idle cycle. All CPUs belonging to the same cluster > + will enter idle synchronously to reach the deepest idle > + state. > + > endchoice > > config CLOCK_THERMAL > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c > index 5c219dc..1eec8d6 100644 > --- a/drivers/thermal/cpu_cooling.c > +++ b/drivers/thermal/cpu_cooling.c > @@ -10,18 +10,33 @@ > * Viresh Kumar > * > */ > +#define pr_fmt(fmt) "CPU cooling: " fmt > + > #include > #include > #include > +#include > #include > +#include > #include > +#include > #include > #include > +#include > +#include > +#include > #include > #include > > +#include What part of the code is using this one ? > + Why add above 2 blank lines ? > +#include > +#include > + > #include > > +#include > + > #ifdef CONFIG_CPU_FREQ_THERMAL > /* > * Cooling state <-> CPUFreq frequency > @@ -928,3 +943,467 @@ void cpufreq_cooling_unregister(struct > thermal_cooling_device *cdev) > } > EXPORT_SYMBOL_GPL(cpufreq_cooling_unregister); > #endif /* CONFIG_CPU_FREQ_THERMAL */ > + > +#ifdef CONFIG_CPU_IDLE_THERMAL > +/** > + * struct cpuidle_cooling_device - data for the idle cooling device > + * @cdev: a pointer to a struct thermal_cooling_device > + * @cpumask: a cpumask containing the CPU managed by the cooling device > + * @timer: a hrtimer giving the tempo for the idle injection cycles >
Re: [PATCH v3 7/7] cpuidle/drivers/cpuidle-arm: Register the cooling device
On 05-04-18, 18:16, Daniel Lezcano wrote: > Register the ARM generic cpuidle driver as a cooling device. > > Signed-off-by: Daniel Lezcano > --- > drivers/cpuidle/cpuidle-arm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c > index ddee1b6..44b4fe3 100644 > --- a/drivers/cpuidle/cpuidle-arm.c > +++ b/drivers/cpuidle/cpuidle-arm.c > @@ -11,6 +11,7 @@ > > #define pr_fmt(fmt) "CPUidle arm: " fmt > > +#include > #include > #include > #include > @@ -172,6 +173,8 @@ static int __init arm_idle_init(void) > goto out_fail; > } > > + cpuidle_cooling_register(); > + > return 0; > > out_fail: Acked-by: Viresh Kumar -- viresh
Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5
On Wed, 11 Apr 2018 10:27:46 +0200 Ladislav Michl wrote: > On Wed, Apr 11, 2018 at 10:08:06AM +0200, Boris Brezillon wrote: > > On Wed, 11 Apr 2018 09:36:56 +0200 > > Ladislav Michl wrote: > > > > > Hi Boris, > > > > > > On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote: > [...] > > > > Not sure this approach is safe on all archs: if the cache is VIVT or > > > > VIPT, you may have several entries pointing to the same phys page, and > > > > then, when dma_map_page() does its cache maintenance operations, it's > > > > only taking one of these entries into account. > > > > > > Hmm, I used the same approach Samsung OneNAND driver does since commit > > > dcf08227e964a53a2cb39130b74842c7dcb6adde. > > > Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which > > > is VIPT. In that case samsung's driver code has the same problem. > > > > > > > In other parts of the MTD subsystem, we tend to not do DMA on buffers > > > > that have been vmalloc-ed. > > > > > > > > You can do something like > > > > > > > > if (virt_addr_valid(buf)) > > > > /* Use DMA */ > > > > else > > > > /* > > > > * Do not use DMA, or use a bounce buffer > > > > * allocated with kmalloc > > > > */ > > > > > > Okay, I'll use this approach then, but first I'd like to be sure above is > > > correct. Anyone? > > > > See this discussion [1]. The problem came up a few times already, so > > might find other threads describing why it's not safe. > > > > [1]https://lists.linuxfoundation.org/pipermail/iommu/2016-March/016240.html > > > > Question was more likely whenever there might exist more that one mapping > of the same page. I'm clearly not an expert, so I might be wrong, but I think a physical page can be both in the identity mapping and mapped in the vmalloc space. Now, is there a real risk that both ends are accessed in parallel thus making different cache entries pointing to the same phys page dirty, I'm not sure. Or maybe there are other corner case, but you'll have to ask Russell (or any other ARM expert) to get a clearer answer. > But okay, I'll disable DMA for highmem. Patch will follow. > > ladis
[PATCH v2 00/12] refactor dts and add support for more boards
From: Sean Wang Changes since v1: - Dropped several patches which have been merged. - Rebased to linux-next-20180410 where those dependent patches including [1] and [2] all have been got merged. - Revised according to suggestions and comments on v1, where the major work is to put board-specific nodes into DTS files and to leave the common nodes among boards in DTSI files as done in patch 7,9,10,11 and 12. - Merged Ryder Lee's patch for update audio nodes reflecting the latest bindings. - Revised commit message. The series is to refactor current .dts for allowing more boards can properly join and reuse almost the same device node definitions. Before we're doing that, some works about enhancements and fixups are being made on the dt-binding document and .dts files. In addition, the series has to depend on the patch [1][2]. Otherwise, certain build failure would have an occurrence. [1] arm: dts: mt7623: add PCIe related nodes http://lists.infradead.org/pipermail/linux-mediatek/2018-February/012053.html [2] dt-bindings: soc: add header files required for MT7623A SCPSYS dt-binding http://lists.infradead.org/pipermail/linux-mediatek/2018-February/011930.html Ryder Lee (1): arm: dts: mediatek: modify audio related nodes for both MT2701 and MT7623 Sean Wang (11): dt-bindings: cpufreq: mediatek: use - instead of _ in examples arm: dts: mediatek: converted to using SPDX identifiers arm: dts: mt7623: fix invalid memory node being generated arm: dts: mt7623: fix available memory size on bananapi-r2 arm: dts: mt7623: fix all Warnings (unit_address_vs_reg) arm: dts: mt7623: add BTIF, HSDMA and SPI-NOR device nodes arm: dts: mt6323: move node mt6323 leds to mt6323.dtsi arm: dts: mt7623: extend common file reused by all boards with MT7623 SoCs arm: dts: mt7623: add MT7623A SoC level DTS arm: dts: mt7623: add MT7623A reference boards arm: dts: mt7623: add MT7623N reference board with eMMC .../bindings/cpufreq/cpufreq-mediatek.txt | 6 +- arch/arm/boot/dts/Makefile | 3 + arch/arm/boot/dts/mt2701-evb.dts | 9 +- arch/arm/boot/dts/mt2701.dtsi | 197 arch/arm/boot/dts/mt6323.dtsi | 17 +- arch/arm/boot/dts/mt6580-evbp1.dts | 9 +- arch/arm/boot/dts/mt6580.dtsi | 9 +- arch/arm/boot/dts/mt6589-aquaris5.dts | 10 +- arch/arm/boot/dts/mt6589.dtsi | 12 +- arch/arm/boot/dts/mt6592-evb.dts | 9 +- arch/arm/boot/dts/mt6592.dtsi | 9 +- arch/arm/boot/dts/mt7623.dtsi | 537 - arch/arm/boot/dts/mt7623a-rfb-emmc.dts | 291 +++ arch/arm/boot/dts/mt7623a-rfb-nand.dts | 337 + arch/arm/boot/dts/mt7623a.dtsi | 44 ++ arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 279 ++- arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 326 + arch/arm/boot/dts/mt7623n-rfb-nand.dts | 40 +- arch/arm/boot/dts/mt7623n-rfb.dtsi | 12 +- arch/arm/boot/dts/mt8127-moose.dts | 9 +- arch/arm/boot/dts/mt8127.dtsi | 9 +- arch/arm/boot/dts/mt8135-evbp1.dts | 9 +- arch/arm/boot/dts/mt8135.dtsi | 9 +- 23 files changed, 1576 insertions(+), 616 deletions(-) create mode 100644 arch/arm/boot/dts/mt7623a-rfb-emmc.dts create mode 100644 arch/arm/boot/dts/mt7623a-rfb-nand.dts create mode 100644 arch/arm/boot/dts/mt7623a.dtsi create mode 100644 arch/arm/boot/dts/mt7623n-rfb-emmc.dts -- 2.7.4
[PATCH v2 07/12] arm: dts: mt6323: move node mt6323 leds to mt6323.dtsi
From: Sean Wang
Since those LEDs are parts of PMIC MT6323, it is reasonable to merge
those LEDs node definition back into mt6323.dtsi. This way can improve
the reusability of those nodes among different boards with the same PMIC.
And LED is very much board specific and thus the mt6323.dtsi only includes
the parent node here and leave these child nodes in the board specific
dts file.
Signed-off-by: Sean Wang
Cc: Lee Jones
Cc: Rob Herring
---
arch/arm/boot/dts/mt6323.dtsi | 9 -
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 50 ---
2 files changed, 30 insertions(+), 29 deletions(-)
diff --git a/arch/arm/boot/dts/mt6323.dtsi b/arch/arm/boot/dts/mt6323.dtsi
index 958980c..ba39740 100644
--- a/arch/arm/boot/dts/mt6323.dtsi
+++ b/arch/arm/boot/dts/mt6323.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (c) 2017 MediaTek Inc.
+ * Copyright (c) 2017-2018 MediaTek Inc.
* Author: John Crispin
*Sean Wang
*
@@ -14,6 +14,13 @@
interrupt-controller;
#interrupt-cells = <2>;
+ mt6323_leds: leds {
+ compatible = "mediatek,mt6323-led";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
mt6323regulator: mt6323regulator{
compatible = "mediatek,mt6323-regulator";
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 1fd6f55..395912e 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -237,6 +237,28 @@
vqmmc-supply = <®_3p3v>;
};
+&mt6323_leds {
+ status = "okay";
+
+ led@0 {
+ reg = <0>;
+ label = "bpi-r2:isink:green";
+ default-state = "off";
+ };
+
+ led@1 {
+ reg = <1>;
+ label = "bpi-r2:isink:red";
+ default-state = "off";
+ };
+
+ led@2 {
+ reg = <2>;
+ label = "bpi-r2:isink:blue";
+ default-state = "off";
+ };
+};
+
&pcie {
pinctrl-names = "default";
pinctrl-0 = <&pcie_default>;
@@ -482,34 +504,6 @@
status = "okay";
};
-&pwrap {
- mt6323 {
- mt6323led: led {
- compatible = "mediatek,mt6323-led";
- #address-cells = <1>;
- #size-cells = <0>;
-
- led@0 {
- reg = <0>;
- label = "bpi-r2:isink:green";
- default-state = "off";
- };
-
- led@1 {
- reg = <1>;
- label = "bpi-r2:isink:red";
- default-state = "off";
- };
-
- led@2 {
- reg = <2>;
- label = "bpi-r2:isink:blue";
- default-state = "off";
- };
- };
- };
-};
-
&spi0 {
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins_a>;
--
2.7.4
[PATCH v2 09/12] arm: dts: mt7623: extend common file reused by all boards with MT7623 SoCs
From: Sean Wang
Move all possible setups for pio into SoC level DTSI file mt7623.dtsi in
order to introduce more boards such as official MT7623A reference boards
without copy-n-pasting almost the same content of nodes in pio into every
new file.
So, it should be better to reuse those nodes by consolidating them into
the common file mt7623.dtsi from the current existent DTS and allow new
DTS files to refer to them.
Signed-off-by: Sean Wang
---
arch/arm/boot/dts/mt7623.dtsi | 246 ++
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 217 ---
arch/arm/boot/dts/mt7623n-rfb-nand.dts| 31
3 files changed, 246 insertions(+), 248 deletions(-)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index eef81d2..01893858 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -935,3 +935,249 @@
status = "disabled";
};
};
+
+&pio {
+ cir_pins_a:cir-default {
+ pins-cir {
+ pinmux = ;
+ bias-disable;
+ };
+ };
+
+ i2c0_pins_a: i2c0-default {
+ pins-i2c0 {
+ pinmux = ,
+;
+ bias-disable;
+ };
+ };
+
+ i2c1_pins_a: i2c1-default {
+ pin-i2c1 {
+ pinmux = ,
+;
+ bias-disable;
+ };
+ };
+
+ i2s0_pins_a: i2s0-default {
+ pin-i2s0 {
+ pinmux = ,
+,
+,
+,
+;
+ drive-strength = ;
+ bias-pull-down;
+ };
+ };
+
+ i2s1_pins_a: i2s1-default {
+ pin-i2s1 {
+ pinmux = ,
+,
+,
+,
+;
+ drive-strength = ;
+ bias-pull-down;
+ };
+ };
+
+ key_pins_a: keys-alt {
+ pins-keys {
+ pinmux = ,
+ ;
+ input-enable;
+ };
+ };
+
+ led_pins_a: leds-alt {
+ pins-leds {
+ pinmux = ,
+,
+;
+ };
+ };
+
+ mmc0_pins_default: mmc0default {
+ pins-cmd-dat {
+ pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+;
+ input-enable;
+ bias-pull-up;
+ };
+
+ pins-clk {
+ pinmux = ;
+ bias-pull-down;
+ };
+
+ pins-rst {
+ pinmux = ;
+ bias-pull-up;
+ };
+ };
+
+ mmc0_pins_uhs: mmc0 {
+ pins-cmd-dat {
+ pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+;
+ input-enable;
+ drive-strength = ;
+ bias-pull-up = ;
+ };
+
+ pins-clk {
+ pinmux = ;
+ drive-strength = ;
+ bias-pull-down = ;
+ };
+
+ pins-rst {
+ pinmux = ;
+ bias-pull-up;
+ };
+ };
+
+ mmc1_pins_default: mmc1default {
+ pins-cmd-dat {
+ pinmux = ,
+,
+,
+,
+;
+ input-enable;
+ drive-strength = ;
+ bias-pull-up = ;
+ };
+
+ pins-clk {
+ pinmux = ;
+ bias-pull-down;
+ drive-strength = ;
+ };
+
+ pins-wp {
+ pinmux = ;
+ input-enable;
+ bias-pull-up;
+ };
+
+ pins-insert {
+ pinmux = ;
+
[PATCH v2 01/12] dt-bindings: cpufreq: mediatek: use - instead of _ in examples
From: Sean Wang
It should be good that no use "_" is in examples. Consequently,
those nodes in certain files which have an inappropriate name containing
"_" are all being replaced with "-".
Signed-off-by: Sean Wang
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Acked-by: Viresh Kumar
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
index d36f07e..38cfbb5 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
@@ -26,7 +26,7 @@ Optional properties:
Example 1 (MT7623 SoC):
- cpu_opp_table: opp_table {
+ cpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-shared;
@@ -86,7 +86,7 @@ Example 1 (MT7623 SoC):
};
Example 2 (MT8173 SoC):
- cpu_opp_table_a: opp_table_a {
+ cpu_opp_table_a: opp-table-a {
compatible = "operating-points-v2";
opp-shared;
@@ -131,7 +131,7 @@ Example 2 (MT8173 SoC):
};
};
- cpu_opp_table_b: opp_table_b {
+ cpu_opp_table_b: opp-table-b {
compatible = "operating-points-v2";
opp-shared;
--
2.7.4
[PATCH v2 02/12] arm: dts: mediatek: converted to using SPDX identifiers
From: Sean Wang
Convert boilerplate license statement into proper SPDX identifier style.
Signed-off-by: Sean Wang
Cc: Philippe Ombredanne
Cc: Rob Herring
---
arch/arm/boot/dts/mt2701-evb.dts | 9 +
arch/arm/boot/dts/mt2701.dtsi | 9 +
arch/arm/boot/dts/mt6323.dtsi | 8 +---
arch/arm/boot/dts/mt6580-evbp1.dts | 9 +
arch/arm/boot/dts/mt6580.dtsi | 9 +
arch/arm/boot/dts/mt6589-aquaris5.dts | 10 +-
arch/arm/boot/dts/mt6589.dtsi | 12 ++--
arch/arm/boot/dts/mt6592-evb.dts | 9 +
arch/arm/boot/dts/mt6592.dtsi | 9 +
arch/arm/boot/dts/mt7623.dtsi | 9 +
arch/arm/boot/dts/mt7623n-rfb-nand.dts | 9 +
arch/arm/boot/dts/mt7623n-rfb.dtsi | 9 +
arch/arm/boot/dts/mt8127-moose.dts | 9 +
arch/arm/boot/dts/mt8127.dtsi | 9 +
arch/arm/boot/dts/mt8135-evbp1.dts | 9 +
arch/arm/boot/dts/mt8135.dtsi | 9 +
16 files changed, 17 insertions(+), 130 deletions(-)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 63af4b1..be0edb3 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -1,15 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2015 MediaTek Inc.
* Author: Erin Lo
*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
/dts-v1/;
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 05557fc..cf1c8eb 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -1,15 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2015 MediaTek Inc.
* Author: Erin.Lo
*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include
diff --git a/arch/arm/boot/dts/mt6323.dtsi b/arch/arm/boot/dts/mt6323.dtsi
index 7c783d6..958980c 100644
--- a/arch/arm/boot/dts/mt6323.dtsi
+++ b/arch/arm/boot/dts/mt6323.dtsi
@@ -1,15 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2017 MediaTek Inc.
* Author: John Crispin
*Sean Wang
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
*
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
&pwrap {
diff --git a/arch/arm/boot/dts/mt6580-evbp1.dts
b/arch/arm/boot/dts/mt6580-evbp1.dts
index 17daeae..ca13789 100644
--- a/arch/arm/boot/dts/mt6580-evbp1.dts
+++ b/arch/arm/boot/dts/mt6580-evbp1.dts
@@ -1,15 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2015 MediaTek Inc.
* Author: Mars.C
*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
/dts-v1/;
diff --git a/arch/arm/boot/dts/mt6580.dtsi b/arch/arm/boot/dts/mt6580.dtsi
index a349dba..2bdc5ed 100644
--- a/arch/arm/boot/dts/mt6580.dtsi
+++ b/arch/arm/boot/dts/mt6580.dtsi
@@ -1,15 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2015 MediaTek Inc.
* Author: Mars.C
*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include
diff --git a/arch/arm/boot/dts/mt6589-aquaris5.dt
[PATCH v2 12/12] arm: dts: mt7623: add MT7623N reference board with eMMC
From: Sean Wang
Add MT7623N reference board with eMMC. On the board, there is additional
external PHY ICPlus IP1001 transceiver available by port 5 on the MDIO
bus connectted with GMAC2.
Signed-off-by: Sean Wang
Suggested-by: Ryder Lee
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/mt7623.dtsi | 17 ++
arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 326 +
3 files changed, 344 insertions(+)
create mode 100644 arch/arm/boot/dts/mt7623n-rfb-emmc.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bc33a3c..19013d4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1152,6 +1152,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt6592-evb.dtb \
mt7623a-rfb-emmc.dtb \
mt7623a-rfb-nand.dtb \
+ mt7623n-rfb-emmc.dtb \
mt7623n-rfb-nand.dtb \
mt7623n-bananapi-bpi-r2.dtb \
mt8127-moose.dtb \
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index f84c37b..d1eb123 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -968,6 +968,14 @@
};
};
+ i2c2_pins_a: i2c2-default {
+ pin-i2c2 {
+ pinmux = ,
+;
+ bias-disable;
+ };
+ };
+
i2c2_pins_b: i2c2-alt {
pin-i2c2 {
pinmux = ,
@@ -1185,6 +1193,15 @@
};
};
+ spi2_pins_a: spi2-default {
+ pins-spi {
+ pinmux = ,
+,
+,
+;
+ };
+ };
+
uart0_pins_a: uart0-default {
pins-dat {
pinmux = ,
diff --git a/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
new file mode 100644
index 000..b760613
--- /dev/null
+++ b/arch/arm/boot/dts/mt7623n-rfb-emmc.dts
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2017-2018 MediaTek Inc.
+ * Author: Sean Wang
+ *
+ */
+
+/dts-v1/;
+#include
+#include "mt7623.dtsi"
+#include "mt6323.dtsi"
+
+/ {
+ model = "MediaTek MT7623N with eMMC reference board";
+ compatible = "mediatek,mt7623n-rfb-emmc", "mediatek,mt7623";
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ cpus {
+ cpu@0 {
+ proc-supply = <&mt6323_vproc_reg>;
+ };
+
+ cpu@1 {
+ proc-supply = <&mt6323_vproc_reg>;
+ };
+
+ cpu@2 {
+ proc-supply = <&mt6323_vproc_reg>;
+ };
+
+ cpu@3 {
+ proc-supply = <&mt6323_vproc_reg>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&key_pins_a>;
+
+ factory {
+ label = "factory";
+ linux,code = ;
+ gpios = <&pio 256 GPIO_ACTIVE_LOW>;
+ };
+
+ wps {
+ label = "wps";
+ linux,code = ;
+ gpios = <&pio 257 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0 0x8000 0 0x4000>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-5V";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "mediatek,mt2701-wm8960-machine";
+ mediatek,platform = <&afe>;
+ audio-routing =
+ "Headphone", "HP_L",
+ "Headphone", "HP_R",
+ "LINPUT1", "AMIC",
+ "R
