Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq
On 2020-06-02 21:54, Thomas Gleixner wrote:
"Herrenschmidt, Benjamin" writes:
On Sun, 2020-05-31 at 12:09 +0100, Marc Zyngier wrote:
> The semantic of activate/deactivate (which maps to started/shutdown
> in the IRQ code) is that the HW resources for a given interrupt are
> only committed when the interrupt is activated. Trying to perform
> actions involving the HW on an interrupt that isn't active cannot be
> guaranteed to take effect.
>
> I'd rather address it in the core code, by preventing set_affinity (and
> potentially others) to take place when the interrupt is not in the
> STARTED state. Userspace would get an error, which is perfectly
> legitimate, and which it already has to deal with it for plenty of
> other
> reasons.
So I finally found time to dig a bit in there :) Code has changed a
bit
since last I looked. But I have memories of the startup code messing
around with the affinity, and here it is. In irq_startup() :
switch (__irq_startup_managed(desc, aff, force)) {
case IRQ_STARTUP_NORMAL:
ret = __irq_startup(desc);
irq_setup_affinity(desc);
break;
case IRQ_STARTUP_MANAGED:
irq_do_set_affinity(d, aff, false);
ret = __irq_startup(desc);
Grump. Nice catch. In hindsight, this is obvious, as managed interrupts
may have been allocated to target CPUs that have been hot-plugged off.
break;
case IRQ_STARTUP_ABORT:
irqd_set_managed_shutdown(d);
return 0;
So we have two cases here. Normal and managed.
In the managed case, we set the affinity before startup. I feel like
your
patch might break that or am I missing something ?
It will break stuff because the affinity is not stored in case that the
interrupt is not started.
I think we can fix this in the core code but that needs more thought.
__irq_can_set_affinity() is definitely the wrong place.
Indeed. I completely missed the above. Back to square one.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: twist: allow disabling reboot request
On Wed 2020-06-03 20:03:28, Tetsuo Handa wrote:
> On 2020/05/29 22:26, Tetsuo Handa wrote:
> > By the way, I do worry that people forget to perform these steps when
> > they do
> > their tests without asking syzbot...
>
> Here is a draft of boot-time switching. Since kconfig can handle string
> variable up to
> 2048 characters, we could hold the content of the "your-config" file inside
> .config file
> in order to avoid relying on external file in "syzkaller tree". But since
> only one kconfig
> option is used, basically the way to temporarily include/exclude specific
> options (under
> automated testing by syzbot) seems to remain directly patching
> apply_twist_flags(), for
> https://github.com/google/syzkaller/blob/master/dashboard/config/util.sh will
> automatically
> overwrite CONFIG_DEFAULT_TWIST_FLAGS settings. If each twist flag were using
> independent
> kconfig option, the way to temporarily include/exclude specific options will
> become directly
> patching Kconfig file.
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 82d91547d122..78fdbb4f17b1 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -1038,4 +1038,12 @@ static inline void ftrace_dump(enum ftrace_dump_mode
> oops_dump_mode) { }
>/* OTHER_WRITABLE? Generally considered a bad idea. */
> \
>BUILD_BUG_ON_ZERO((perms) & 2) +
> \
>(perms))
> +
> +/* Flags for twisting kernel behavior. */
> +struct twist_flags {
> + bool disable_kbd_k_spec_handler;
> + bool disable_reboot_request;
> +};
> +extern struct twist_flags twist_flags;
Why all these options have to be in a single structure?
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 498d344ea53a..41cfabc74ad7 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -2338,4 +2338,9 @@ config HYPERV_TESTING
>
> endmenu # "Kernel Testing and Coverage"
>
> +menuconfig DEFAULT_TWIST_FLAGS
> + string "Default twist options (DANGEROUS)"
> + help
> + Don't specify anything unless you know what you are doing.
> +
> endmenu # Kernel hacking
Why such a crazy build configure option?
I think that the only way to get this upstream is to:
+ Add separate boot options that might theoretically be used also
by other people.
+ Use boot parameters and not build configuration.
+ Avoid the meaningless word "twist" !!!
Best Regards,
Petr
Re: [PATCH] efi/libstub: refactor Makefile to not use lib-y syntax
On Wed, 3 Jun 2020 at 13:23, Masahiro Yamada wrote: > > On Wed, Jun 3, 2020 at 6:16 PM Ard Biesheuvel wrote: > > > > On Wed, 3 Jun 2020 at 11:15, Masahiro Yamada wrote: > > > > > > On Wed, Jun 3, 2020 at 6:02 PM Ard Biesheuvel wrote: > > > > > > > > On Wed, 3 Jun 2020 at 10:59, Masahiro Yamada > > > > wrote: > > > > > > > > > > On Wed, Jun 3, 2020 at 5:45 PM Ard Biesheuvel wrote: > > > > > > > > > > > > On Wed, 3 Jun 2020 at 10:36, Masahiro Yamada > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Jun 3, 2020 at 3:45 PM Ard Biesheuvel > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, 3 Jun 2020 at 07:34, Masahiro Yamada > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Documentation/kbuild/makefiles.rst says: > > > > > > > > > > > > > > > > > > Use of lib-y is normally restricted to `lib/` and > > > > > > > > > `arch/*/lib`. > > > > > > > > > > > > > > > > > > I want to disallow lib-y outside of them. > > > > > > > > > > > > > > > > > > > > > > > > > Why? > > > > > > > > > > > > > > > > > > > > > Because I plan to remove lib-y entirely at some point. > > > > > > > > > > > > > > lib-y is not so useful to shrink the image size because: > > > > > > > > > > > > > > - An object in lib.a can be omitted only when no symbol > > > > > > > in that object is referenced. This rarely happens. > > > > > > > > > > > > > > - lib-y objects are often exported by nature > > > > > > > because lib-y is a collection of utility functions. > > > > > > > Even if no in-tree user, we always need to keep them > > > > > > > because EXPORT_SYMBOL() is the interface to modules. > > > > > > > > > > > > > > > > > > > > > When I worked on commit 7273ad2b08f8ac9563579d16a3cf528857b26f49, > > > > > > > I made some research. > > > > > > > > > > > > > > The benefit of lib-y is just 362 byte for x86_64_defconfig. > > > > > > > ( Before: 26578002, After: 26578364) > > > > > > > > > > > > > > My hope is lib-y will be replaced by dead-code elimination or > > > > > > > ultimately by LTO. > > > > > > > > > > > > > > drivers/firmware/efi/libstub/Makefile > > > > > > > is the only Makefile that breaks the rule: > > > > > > > "Use of lib-y is normally restricted to `lib/` and `arch/*/lib`" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Add a custom rule to build lib.a, which is linked to the > > > > > > > > > decompressor > > > > > > > > > for ARCH=x86, ARCH=arm. > > > > > > > > > > > > > > > > > > For ARCH=arm64, use obj-y to link objects to vmlinux in the > > > > > > > > > ordinary > > > > > > > > > way. > > > > > > > > > > > > > > > > > > > > > > > > > The code works perfectly fine as is, and I don't see what is > > > > > > > > fundamentally wrong with using static libraries outside of lib/ > > > > > > > > and > > > > > > > > arch/*/lib. > > > > > > > > > > > > > > The intended usage of lib-y is to hook lib.a > > > > > > > to scripts/vmlinux.sh via KBUILD_VMLINUX_LIBS. > > > > > > > > > > > > > > This Makefile is just what you found to work. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, I would like this code to still be incorporated as a > > > > > > > > static > > > > > > > > library into arm64 as well, so that only pieces that are > > > > > > > > actually > > > > > > > > needed are incorporated into the final image. > > > > > > > > > > > > > > No. > > > > > > > It is not working like that because you set > > > > > > > lib.a to core-y. > > > > > > > > > > > > > > All objects in core-y are always linked to vmlinux. > > > > > > > > > > > > > > > > > > > The lib.a file is passed to the linker as a static library, so it > > > > > > will > > > > > > only grab what it needs. > > > > > > > > > > > > For instance, if you build arm64 from mainline today, the > > > > > > efi_relocate_kernel will not be in the final image, even though it > > > > > > is > > > > > > built as part of libstub > > > > > > > > > > > > > > > I built today's mainline kernel > > > > > (d6f9469a03d832dcd17041ed67774ffb5f3e73b3). > > > > > > > > > > > > > > > I see it in vmlinux. > > > > > > > > > > > > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig > > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j24 > > > > > ... > > > > > $ aarch64-linux-gnu-nm -n vmlinux | grep efi_relocate_kernel > > > > > 8000114afb90 t __efistub_efi_relocate_kernel > > > > > > > > > > > > > That is strange. I tested this before, and it worked. > > > > > > > > Did anything change recently in the way the linker is invoked? > > > > > > > > > Nothing recently. > > > > > > This is obvious result because > > > drivers/firmware/efi/libstub/lib.a > > > is passed after whole-archive flag. > > > > > > > > > I guess the following commit is it, > > > but it is already 3 years ago. > > > > > > > Right. > > > > So that means there is no point at all in using static libraries, no? > > Or does --whole-archive still allow duplicate definitions
Re: Re: [PATCH v14 13/15] mm/damon-test: Add a kunit test for recording setup
On Tue, 2 Jun 2020 13:28:03 -0700 Brendan Higgins wrote: > On Tue, Jun 2, 2020 at 6:16 AM SeongJae Park wrote: > > > > From: SeongJae Park > > > > This commit adds another unit test case for the recording setup. > > > > Signed-off-by: SeongJae Park > > Reviewed-by: Brendan Higgins Thanks for the review! As the previous patch is also for the kunit test and it already received your 'Reviewed-by', I would like to merge this patch into the previous one in the next spin. If there is any problem, please let me know. Thanks, SeongJae Park
Re: [PATCH 1/2] sched/uclamp: Add a new sysctl to control RT default boost value
On 06/03/20 10:40, Mel Gorman wrote: > On Tue, Jun 02, 2020 at 06:46:00PM +0200, Dietmar Eggemann wrote: > > On 29.05.20 12:08, Mel Gorman wrote: > > > On Thu, May 28, 2020 at 06:11:12PM +0200, Peter Zijlstra wrote: > > >>> FWIW, I think you're referring to Mel's notice in OSPM regarding the > > >>> overhead. > > >>> Trying to see what goes on in there. > > >> > > >> Indeed, that one. The fact that regular distros cannot enable this > > >> feature due to performance overhead is unfortunate. It means there is a > > >> lot less potential for this stuff. > > > > > > During that talk, I was a vague about the cost, admitted I had not looked > > > too closely at mainline performance and had since deleted the data given > > > that the problem was first spotted in early April. If I heard someone > > > else making statements like I did at the talk, I would consider it a bit > > > vague, potentially FUD, possibly wrong and worth rechecking myself. In > > > terms of distributions "cannot enable this", we could but I was unwilling > > > to pay the cost for a feature no one has asked for yet. If they had, I > > > would endevour to put it behind static branches and disable it by default > > > (like what happened for PSI). I was contacted offlist about my comments > > > at OSPM and gathered new data to respond properly. For the record, here > > > is an editted version of my response; > > > > [...] > > > > I ran these tests on 'Ubuntu 18.04 Desktop' on Intel E5-2690 v2 > > (2 sockets * 10 cores * 2 threads) with powersave governor as: > > > > $ numactl -N 0 ./run-mmtests.sh XXX > > > > w/ config-network-netperf-unbound. > > > > Running w/o 'numactl -N 0' gives slightly worse results. > > > > without-clamp : CONFIG_UCLAMP_TASK is not set > > with-clamp : CONFIG_UCLAMP_TASK=y, > > CONFIG_UCLAMP_TASK_GROUP is not set > > with-clamp-tskgrp : CONFIG_UCLAMP_TASK=y, > > CONFIG_UCLAMP_TASK_GROUP=y > > > > > > netperf-udp > > ./5.7.0-rc7./5.7.0-rc7 > > ./5.7.0-rc7 > > without-clamp with-clamp > > with-clamp-tskgrp > > > > Hmean send-64 153.62 ( 0.00%) 151.80 * -1.19%* > > 155.60 * 1.28%* > > Hmean send-128306.77 ( 0.00%) 306.27 * -0.16%* > > 309.39 * 0.85%* > > Hmean send-256608.54 ( 0.00%) 604.28 * -0.70%* > > 613.42 * 0.80%* > > Hmean send-1024 2395.80 ( 0.00%) 2365.67 * -1.26%* > > 2409.50 * 0.57%* > > Hmean send-2048 4608.70 ( 0.00%) 4544.02 * -1.40%* > > 4665.96 * 1.24%* > > Hmean send-3312 7223.97 ( 0.00%) 7158.88 * -0.90%* > > 7331.23 * 1.48%* > > Hmean send-4096 8729.53 ( 0.00%) 8598.78 * -1.50%* > > 8860.47 * 1.50%* > > Hmean send-8192 14961.77 ( 0.00%)14418.92 * -3.63%* > > 14908.36 * -0.36%* > > Hmean send-1638425799.50 ( 0.00%)25025.64 * -3.00%* > > 25831.20 * 0.12%* > > Hmean recv-64 153.62 ( 0.00%) 151.80 * -1.19%* > > 155.60 * 1.28%* > > Hmean recv-128306.77 ( 0.00%) 306.27 * -0.16%* > > 309.39 * 0.85%* > > Hmean recv-256608.54 ( 0.00%) 604.28 * -0.70%* > > 613.42 * 0.80%* > > Hmean recv-1024 2395.80 ( 0.00%) 2365.67 * -1.26%* > > 2409.50 * 0.57%* > > Hmean recv-2048 4608.70 ( 0.00%) 4544.02 * -1.40%* > > 4665.95 * 1.24%* > > Hmean recv-3312 7223.97 ( 0.00%) 7158.88 * -0.90%* > > 7331.23 * 1.48%* > > Hmean recv-4096 8729.53 ( 0.00%) 8598.78 * -1.50%* > > 8860.47 * 1.50%* > > Hmean recv-8192 14961.61 ( 0.00%)14418.88 * -3.63%* > > 14908.30 * -0.36%* > > Hmean recv-1638425799.39 ( 0.00%)25025.49 * -3.00%* > > 25831.00 * 0.12%* > > > > netperf-tcp > > > > Hmean 64 818.65 ( 0.00%) 812.98 * -0.69%* > > 826.17 * 0.92%* > > Hmean 1281569.55 ( 0.00%) 1555.79 * -0.88%* > > 1586.94 * 1.11%* > > Hmean 2562952.86 ( 0.00%) 2915.07 * -1.28%* > > 2968.15 * 0.52%* > > Hmean 1024 10425.91 ( 0.00%)10296.68 * -1.24%* > > 10418.38 * -0.07%* > > Hmean 2048 17454.51 ( 0.00%)17369.57 * -0.49%* > > 17419.24 * -0.20%* > > Hmean 3312 22509.95 ( 0.00%)9.69 * -1.25%* > > 22373.32 * -0.61%* > > Hmean 4096 25033.23 ( 0.00%)24859.59 * -0.69%* > > 24912.50 * -0.48%* > > Hmean 8192 32080.51 ( 0.00%)31744.51 * -1.05%* > > 31800.45 * -0.87%* > > Hmean 16384 36531.86 ( 0.00%)37064.68 * 1.46%* > > 37397.71 * 2.37%* > > > > The diffs are smaller than on openSUSE Leap 15.1 and some of the > > uclamp taskgroup
Re: [PATCH] media: marvell-ccic: Add missed v4l2_async_notifier_cleanup()
Hi Chuhong,
Thanks for the patch.
On Wed, Jun 03, 2020 at 07:56:05PM +0800, Chuhong Yuan wrote:
> mccic_register() forgets to cleanup the notifier in its error handler.
> Add the missed call to fix it.
>
> Fixes: 3eefe36cc00c ("media: marvell-ccic: use async notifier to get the
> sensor")
> Signed-off-by: Chuhong Yuan
> ---
> drivers/media/platform/marvell-ccic/mcam-core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
> b/drivers/media/platform/marvell-ccic/mcam-core.c
> index 09775b6624c6..cf2a0119e679 100644
> --- a/drivers/media/platform/marvell-ccic/mcam-core.c
> +++ b/drivers/media/platform/marvell-ccic/mcam-core.c
> @@ -1940,6 +1940,7 @@ int mccic_register(struct mcam_camera *cam)
> out:
> v4l2_async_notifier_unregister(>notifier);
> v4l2_device_unregister(>v4l2_dev);
> + v4l2_async_notifier_cleanup(>notifier);
> return ret;
> }
> EXPORT_SYMBOL_GPL(mccic_register);
The same issue appears to be present in the mcam_shutdown(), could you fix
that one as well?
--
Regards,
Sakari Ailus
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
- On Jun 3, 2020, at 8:31 AM, Florian Weimer fwei...@redhat.com wrote: > * Mathieu Desnoyers: > >> - On Jun 3, 2020, at 8:05 AM, Florian Weimer fwei...@redhat.com wrote: >> >>> * Mathieu Desnoyers: >>> +#ifdef __cplusplus +# if __cplusplus >= 201103L +# define __rseq_static_assert(expr, diagnostic) static_assert (expr, diagnostic) +# define __rseq_alignof(type) alignof (type) +# define __rseq_alignas(x) alignas (x) +# define __rseq_tls_storage_class thread_local +# endif +#elif (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) >= 201112L +# define __rseq_static_assert(expr, diagnostic) _Static_assert (expr, diagnostic) +# define __rseq_alignof(type)_Alignof (type) +# define __rseq_alignas(x) _Alignas (x) +# define __rseq_tls_storage_class_Thread_local +#endif >>> >>> This does not seem to work. I get this with GCC 9: >>> >>> In file included from /tmp/cih_test_gsrKbC.cc:8:0: >>> ../sysdeps/unix/sysv/linux/sys/rseq.h:42:50: error: attribute ignored >>> [-Werror=attributes] >>> # define __rseq_alignas(x) alignas (x) >>> ^ >>> ../sysdeps/unix/sysv/linux/sys/rseq.h:122:14: note: in expansion of macro >>> ‘__rseq_alignas’ >>> uint32_t __rseq_alignas (32) version; >>> ^ >> >> Is that when compiling C or C++ code ? If it's C code, I would expect >> "_Alignas" to be used, not "alignas". >> >> Which exact version of gcc do you use ? > > C++ code. CXX was set to this compiler at configure time: > > gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC) I think I found the culprit: it should be: __rseq_alignas (32) uint32_t version; rather than the other way around. > >>> In any case, these changes really have to go into the UAPI header first. >>> Only the __thread handling should remain. Otherwise, we'll have a tough >>> situation on our hands changing the UAPI header, without introducing >>> macro definition conflicts. I'd suggest to stick to the aligned >>> attribute for the time being, like the current UAPI headers. OK, so I just remove the __rseq_alignas for now and use "aligned()" instead like the UAPI header. I plan to keep the other macros for now. >> >> OK. Should I do that in a separate patch, or you do it on top of my patchset, >> or should I re-spin another round of the series ? > > I think the initial commit should mirror the current UAPI header > contents. > > Keep the macros for the UAPI patch though. 8-) We can pick up these > changes once they have been merged into Linux. OK, Thanks! Mathieu > > Thanks, > Florian -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH] sound: usb: pcm: fix incorrect power state when playing sound after PM_AUTO suspend
On Wed, 2020-06-03 at 10:45 +0200, Takashi Iwai wrote:
> On Wed, 03 Jun 2020 08:54:51 +0200,
> Takashi Iwai wrote:
> >
> > On Wed, 03 Jun 2020 08:28:09 +0200,
> > Takashi Iwai wrote:
> > >
> > > And, the most suspicious case is the last one,
> > > chip->num_suspended-intf. It means that the device has multiple
> > > USB interfaces and they went to suspend, while the resume isn't
> > > performed for the all suspended interfaces in return.
> >
> > If this is the cause, a patch like below might help.
> > It gets/puts the all assigned interfaced instead of only the primary
> > one.
>
> ... and considering of the problem again, rather the patch below might
> be the right answer. Now the driver tries to remember at which state
> it entered into the system-suspend. Upon resume, in return, when the
> state reaches back to that point, set the card state to D0.
>
> The previous patch can be applied on the top, too, and it might be
> worth to apply both.
>
> Let me know if any of those actually helps.
>
>
> Takashi
Thanks for your response so quickly.
I've just test this patch since it looks like enough for the issue.
This patch worked since the flag system_suspend will be set at the same
time when power state has been changed. I have 2 interface with the head
set. But actually the problem happened when primary one is suspended.
So I didn't test the earlier patch "suspend all interface instead of
only the primary one."
Will you resend this patch officially later? I think this solution is
required to send to stable, too. It's better to have it for other stable
kernel versions include android's.
> ---
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -843,9 +843,6 @@ static int usb_audio_suspend(struct usb_interface *intf,
> pm_message_t message)
> if (chip == (void *)-1L)
> return 0;
>
> - chip->autosuspended = !!PMSG_IS_AUTO(message);
> - if (!chip->autosuspended)
> - snd_power_change_state(chip->card, SNDRV_CTL_POWER_D3hot);
> if (!chip->num_suspended_intf++) {
> list_for_each_entry(as, >pcm_list, list) {
> snd_usb_pcm_suspend(as);
> @@ -858,6 +855,11 @@ static int usb_audio_suspend(struct usb_interface *intf,
> pm_message_t message)
> snd_usb_mixer_suspend(mixer);
> }
>
> + if (!PMSG_IS_AUTO(message) && !chip->system_suspend) {
> + snd_power_change_state(chip->card, SNDRV_CTL_POWER_D3hot);
> + chip->system_suspend = chip->num_suspended_intf;
> + }
> +
> return 0;
> }
>
> @@ -871,10 +873,10 @@ static int __usb_audio_resume(struct usb_interface
> *intf, bool reset_resume)
>
> if (chip == (void *)-1L)
> return 0;
> - if (--chip->num_suspended_intf)
> - return 0;
>
> atomic_inc(>active); /* avoid autopm */
> + if (chip->num_suspended_intf > 1)
> + goto out;
>
> list_for_each_entry(as, >pcm_list, list) {
> err = snd_usb_pcm_resume(as);
> @@ -896,9 +898,12 @@ static int __usb_audio_resume(struct usb_interface
> *intf, bool reset_resume)
> snd_usbmidi_resume(p);
> }
>
> - if (!chip->autosuspended)
> + out:
> + if (chip->num_suspended_intf == chip->system_suspend) {
> snd_power_change_state(chip->card, SNDRV_CTL_POWER_D0);
> - chip->autosuspended = 0;
> + chip->system_suspend = 0;
> + }
> + chip->num_suspended_intf--;
>
> err_out:
> atomic_dec(>active); /* allow autopm after this point */
> diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h
> index 1c892c7f14d7..e0ebfb25fbd5 100644
> --- a/sound/usb/usbaudio.h
> +++ b/sound/usb/usbaudio.h
> @@ -26,7 +26,7 @@ struct snd_usb_audio {
> struct usb_interface *pm_intf;
> u32 usb_id;
> struct mutex mutex;
> - unsigned int autosuspended:1;
> + unsigned int system_suspend;
> atomic_t active;
> atomic_t shutdown;
> atomic_t usage_count;
>
> ___
Thank you very much!
Best regards,
Macpaul Lin
Re: arm64 build issue and mainline crash (was Re: linux-next: Tree for Jun 3)
On Wed, 3 Jun 2020 at 14:20, Stephen Rothwell wrote: > > Hi all, > > Just resending to get past the infradead.org mail filters (hopefully). > > On Wed, 3 Jun 2020 22:13:41 +1000 Stephen Rothwell > wrote: > > > > Hi John, > > > > On Wed, 3 Jun 2020 12:45:18 +0100 John Garry wrote: > > > > > > On 03/06/2020 12:06, Stephen Rothwell wrote: > > > > > > JFYI, I am finding the vanilla defconfig build broken for arm64: > > > > > > LD vmlinux.o > > > > > > > > > /home/john/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-ld: > > > cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file > > > or directory > > > make[1]: *** [vmlinux] Error 1 > > > > > > > > > make: *** [__sub-make] Error 2 > > > > > > > > > john@htsatcamb-server:~/linux-next$ > > > > > > In addition, the reason I was testing this was because Linus' master > > > (d6f9469a03d8 Merge tag 'erofs-for-5.8-rc1' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs) was crashing: > > > > > > [ 5.368948] loop: module loaded > > > [ 5.372113] Unable to handle kernel paging request at virtual address > > > f9ffcfec4000 > > > [ 5.380067] Mem abort info: > > > [ 5.382865]ESR = 0x9644 > > > [ 5.385927]EC = 0x25: DABT (current EL), IL = 32 bits > > > [ 5.391260]SET = 0, FnV = 0 > > > [ 5.394319]EA = 0, S1PTW = 0 > > > [ 5.397467] Data abort info: > > > [ 5.400354]ISV = 0, ISS = 0x0044 > > > [ 5.404203]CM = 0, WnR = 1 > > > [ 5.407178] swapper pgtable: 4k pages, 48-bit VAs, pgdp=2f3f1000 > > > [ 5.413909] [f9ffcfec4000] pgd= > > > [ 5.418807] Internal error: Oops: 9644 [#1] PREEMPT SMP > > > [ 5.424399] Modules linked in: > > > [ 5.427462] CPU: 11 PID: 1 Comm: swapper/0 Not tainted > > > 5.7.0-05047-gd6f9469a03d8 #388 > > > [ 5.435325] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 > > > IT21 Nemo 2.0 RC0 04/18/2018 > > > [ 5.99] pstate: 4005 (nZcv daif -PAN -UAO BTYPE=--) > > > [ 5.450098] pc : __memset+0x16c/0x1c0 > > > [ 5.453770] lr : pcpu_alloc+0x1a0/0x668 > > > [ 5.457615] sp : 800011d3bbd0 > > > [ 5.460936] x29: 800011d3bbd0 x28: 001fb5495180 > > > [ 5.466267] x27: 0001 x26: 0100 > > > [ 5.471597] x25: 0001 x24: 0001 > > > [ 5.476928] x23: 80001135e9a0 x22: 80001196a200 > > > [ 5.482259] x21: 80001196a360 x20: > > > [ 5.487590] x19: x18: fe107e6fdb08 > > > [ 5.492920] x17: 003f x16: > > > [ 5.498251] x15: 001ffbffee00 x14: 0002 > > > [ 5.503581] x13: x12: 003f > > > [ 5.508912] x11: 0040 x10: 0040 > > > [ 5.514243] x9 : x8 : f9ffcfec4000 > > > [ 5.519573] x7 : x6 : 003f > > > [ 5.524904] x5 : 0040 x4 : > > > [ 5.530234] x3 : 0004 x2 : 00c0 > > > [ 5.535565] x1 : x0 : f9ffcfec4000 > > > [ 5.540896] Call trace: > > > [ 5.543344] __memset+0x16c/0x1c0 > > > [ 5.54] __alloc_percpu+0x14/0x1c > > > [ 5.550338] alloc_workqueue+0x164/0x42c > > > [ 5.554273] init+0x24/0xa4 > > > [ 5.557071] do_one_initcall+0x50/0x194 > > > [ 5.560917] kernel_init_freeable+0x1e4/0x250 > > > [ 5.565288] kernel_init+0x10/0x104 > > > [ 5.568785] ret_from_fork+0x10/0x18 > > > [ 5.572372] Code: 91010108 544a 8b040108 cb050042 (d50b7428) > > > [ 5.578568] ---[ end trace 63c299bbe9b8ea9e ]--- > > > [ 5.583205] Kernel panic - not syncing: Attempted to kill init! > > > exitcode=0x000b > > > [ 5.590903] SMP: stopping secondary CPUs > > > [ 5.594846] Kernel Offset: 0xf from 0x80001000 > > > [ 5.600350] PHYS_OFFSET: 0x0 > > > [ 5.603235] CPU features: 0x240022,20806008 > > > [ 5.607430] Memory Limit: none > > > [ 5.610500] ---[ end Kernel panic - not syncing: Attempted to kill init! > > > exitcode=0x000b ]--- > > > > > > I'll check that when I get a chance. Maybe all just transient. > > > > Yeah, I forgot to add a patch to make arm64 build again (it will be in > > linux-next tomorrow). If you want to apply it to your tree, here is > > what I was given: > > > > diff --git a/Makefile b/Makefile > > index f80c4ff93ec9..fbb4b95ae648 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1074,7 +1074,7 @@ build-dirs:= $(vmlinux-dirs) > > clean-dirs := $(vmlinux-alldirs) > > > > # Externally visible symbols (used by link-vmlinux.sh) > > -KBUILD_VMLINUX_OBJS := $(head-y) $(addsuffix built-in.a, $(core-y)) > > +KBUILD_VMLINUX_OBJS := $(head-y) $(patsubst %/,%/built-in.a, $(core-y)) > > KBUILD_VMLINUX_OBJS += $(addsuffix built-in.a, $(filter %/, $(libs-y))) > > ifdef CONFIG_MODULES > > KBUILD_VMLINUX_OBJS += $(patsubst %/, %/lib.a, $(filter %/, $(libs-y))) > 9203be13ef5bfd1fcf39f7b7fe94597d2d2a0eb4 is the first bad commit commit 9203be13ef5bfd1fcf39f7b7fe94597d2d2a0eb4 Author: Masahiro Yamada Date:
Re: linux-next: arm64 build failed - aarch64-linux-gnu-ld: cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file or directory
On Wed, 3 Jun 2020 at 14:31, Naresh Kamboju wrote:
>
> arm64 build failed on Linux-next 20200603.
>
> make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm64
> CROSS_COMPILE=aarch64-linux-gnu- HOSTCC=gcc CC="sccache
> aarch64-linux-gnu-gcc" O=build Image
> #
> aarch64-linux-gnu-ld: cannot find
> ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file or
> directory
> make[1]: *** [/linux/Makefile:1132: vmlinux] Error 1
>
9203be13ef5bfd1fcf39f7b7fe94597d2d2a0eb4 is the first bad commit
commit 9203be13ef5bfd1fcf39f7b7fe94597d2d2a0eb4
Author: Masahiro Yamada
Date: Mon Jun 1 14:56:59 2020 +0900
kbuild: refactor KBUILD_VMLINUX_{OBJS,LIBS} calculation
Do not overwrite core-y or drivers-y. Remove libs-y1 and libs-y2.
Signed-off-by: Masahiro Yamada
Re: [PATCH] pinctrl: freescale: imx: Fix an error handling path in 'imx_pinctrl_probe()'
On Sat, May 30, 2020 at 10:49 PM Christophe JAILLET
wrote:
> 'pinctrl_unregister()' should not be called to undo
> 'devm_pinctrl_register_and_init()', it is already handled by the framework.
>
> This simplifies the error handling paths of the probe function.
> The 'imx_free_resources()' can be removed as well.
>
> Fixes: a51c158bf0f7 ("pinctrl: imx: use radix trees for groups and functions")
> Signed-off-by: Christophe JAILLET
Patch applied!
Yours,
Linus Walleij
Re: [PATCH 1/5] drm/omap: Fix suspend resume regression after platform data removal
Hi Tony, On 31/05/2020 22:39, Tony Lindgren wrote: When booting without legacy platform data, we no longer have omap_device calling PM runtime suspend for us on suspend. This causes the driver context not be saved as we have no suspend and resume functions defined. Let's fix the issue by switching over to use UNIVERSAL_DEV_PM_OPS as it will call the existing PM runtime suspend functions on suspend. I don't think we can use UNIVERSAL_DEV_PM_OPS, as we can't disable DSS modules in any order, but things have to be shut down in orderly manner. omapdrm hasn't relied on omap_device calling runtime suspend for us (I didn't know it does that). We have system suspend hooks in omap_drv.c: SIMPLE_DEV_PM_OPS(omapdrm_pm_ops, omap_drm_suspend, omap_drm_resume) omap_drm_suspend() is supposed to turn off the displays, which then cause dispc_runtime_put (and other runtime_puts) to be called, which result in dispc_runtime_suspend (and other runtime PM suspends). So... For some reason that's no longer happening? I need to try to find a board with which suspend/resume works (without DSS)... Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires more registers than available
Hi Jason,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d6f9469a03d832dcd17041ed67774ffb5f3e73b3
commit: 07b586fe06625b0b610dc3d3a969c51913d143d4 crypto: x86/curve25519 -
replace with formally verified implementation
date: 4 months ago
config: x86_64-randconfig-r012-20200603 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
16437992cac249f6fe1efd392d20e3469b47e39e)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout 07b586fe06625b0b610dc3d3a969c51913d143d4
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires
>> more registers than available
" movq 0(%1), %%rdx;" /* f[0] */
^
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires
>> more registers than available
>> arch/x86/crypto/curve25519-x86_64.c:518:3: error: inline assembly requires
>> more registers than available
arch/x86/crypto/curve25519-x86_64.c:609:3: error: inline assembly requires more
registers than available
" movq 0(%1), %%rdx;" /* f[0] */
^
arch/x86/crypto/curve25519-x86_64.c:609:3: error: inline assembly requires more
registers than available
11 errors generated.
vim +518 arch/x86/crypto/curve25519-x86_64.c
509
510 /* Computes the square of a field element: out <- f * f
511 * Uses the 8-element buffer tmp for intermediate results */
512 static inline void fsqr(u64 *out, const u64 *f, u64 *tmp)
513 {
514 asm volatile(
515 /* Compute the raw multiplication: tmp <- f * f */
516
517 /* Step 1: Compute all partial products */
> 518 " movq 0(%1), %%rdx;"
> /* f[0] */
519 " mulxq 8(%1), %%r8, %%r14;" " xor %%r15,
%%r15;" /* f[1]*f[0] */
520 " mulxq 16(%1), %%r9, %%r10;" " adcx %%r14,
%%r9;" /* f[2]*f[0] */
521 " mulxq 24(%1), %%rax, %%rcx;"" adcx %%rax,
%%r10;"/* f[3]*f[0] */
522 " movq 24(%1), %%rdx;"
/* f[3] */
523 " mulxq 8(%1), %%r11, %%r12;" " adcx %%rcx,
%%r11;"/* f[1]*f[3] */
524 " mulxq 16(%1), %%rax, %%r13;"" adcx %%rax,
%%r12;"/* f[2]*f[3] */
525 " movq 8(%1), %%rdx;" " adcx %%r15,
%%r13;"/* f1 */
526 " mulxq 16(%1), %%rax, %%rcx;"" mov $0, %%r14;"
/* f[2]*f[1] */
527
528 /* Step 2: Compute two parallel carry chains */
529 " xor %%r15, %%r15;"
530 " adox %%rax, %%r10;"
531 " adcx %%r8, %%r8;"
532 " adox %%rcx, %%r11;"
533 " adcx %%r9, %%r9;"
534 " adox %%r15, %%r12;"
535 " adcx %%r10, %%r10;"
536 " adox %%r15, %%r13;"
537 " adcx %%r11, %%r11;"
538 " adox %%r15, %%r14;"
539 " adcx %%r12, %%r12;"
540 " adcx %%r13, %%r13;"
541 " adcx %%r
Re: [PATCH V2] pinctrl: sirf: add missing put_device() call in sirfsoc_gpio_probe()
On Wed, Jun 3, 2020 at 3:36 AM yu kuai wrote:
> A coccicheck run provided information like the following:
>
> drivers/pinctrl/sirf/pinctrl-sirf.c:798:2-8: ERROR: missing put_device;
> call of_find_device_by_node on line 792, but without a corresponding
> object release within this function.
>
> Generated by: scripts/coccinelle/free/put_device.cocci
>
> Thus add a jump target to fix the exception handling for this
> function implementation.
>
> Fixes: 5130216265f6 ("PINCTRL: SiRF: add GPIO and GPIO irq support in CSR
> SiRFprimaII")
> Signed-off-by: yu kuai
Patch applied, thanks!
Yours,
Linus Walleij
drivers/soundwire/intel_init.c:192:7: warning: no previous prototype for 'sdw_intel_init'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d6f9469a03d832dcd17041ed67774ffb5f3e73b3
commit: f98f690fb03c2a8d21dfa31aa1042480cf6f7f9b soundwire: intel: update
interfaces between ASoC and SoundWire
date: 6 months ago
config: ia64-randconfig-r026-20200603 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f98f690fb03c2a8d21dfa31aa1042480cf6f7f9b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=ia64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/soundwire/intel_init.c:192:7: warning: no previous prototype for
>> 'sdw_intel_init' [-Wmissing-prototypes]
192 | void *sdw_intel_init(acpi_handle *parent_handle, struct sdw_intel_res
*res)
| ^~
vim +/sdw_intel_init +192 drivers/soundwire/intel_init.c
d62a7d41f38e1d3 Vinod Koul 2017-12-14 183
d62a7d41f38e1d3 Vinod Koul 2017-12-14 184 /**
d62a7d41f38e1d3 Vinod Koul 2017-12-14 185 * sdw_intel_init() - SoundWire
Intel init routine
d62a7d41f38e1d3 Vinod Koul 2017-12-14 186 * @parent_handle: ACPI parent
handle
d62a7d41f38e1d3 Vinod Koul 2017-12-14 187 * @res: resource data
d62a7d41f38e1d3 Vinod Koul 2017-12-14 188 *
d62a7d41f38e1d3 Vinod Koul 2017-12-14 189 * This scans the namespace and
creates SoundWire link controller devices
d62a7d41f38e1d3 Vinod Koul 2017-12-14 190 * based on the info queried.
d62a7d41f38e1d3 Vinod Koul 2017-12-14 191 */
d62a7d41f38e1d3 Vinod Koul 2017-12-14 @192 void *sdw_intel_init(acpi_handle
*parent_handle, struct sdw_intel_res *res)
d62a7d41f38e1d3 Vinod Koul 2017-12-14 193 {
d62a7d41f38e1d3 Vinod Koul 2017-12-14 194 acpi_status status;
d62a7d41f38e1d3 Vinod Koul 2017-12-14 195
d62a7d41f38e1d3 Vinod Koul 2017-12-14 196 status =
acpi_walk_namespace(ACPI_TYPE_DEVICE,
d62a7d41f38e1d3 Vinod Koul 2017-12-14 197
parent_handle, 1,
d62a7d41f38e1d3 Vinod Koul 2017-12-14 198
sdw_intel_acpi_cb,
d62a7d41f38e1d3 Vinod Koul 2017-12-14 199
NULL, res, NULL);
d62a7d41f38e1d3 Vinod Koul 2017-12-14 200 if (ACPI_FAILURE(status))
d62a7d41f38e1d3 Vinod Koul 2017-12-14 201 return NULL;
d62a7d41f38e1d3 Vinod Koul 2017-12-14 202
d62a7d41f38e1d3 Vinod Koul 2017-12-14 203 return
sdw_intel_add_controller(res);
d62a7d41f38e1d3 Vinod Koul 2017-12-14 204 }
d62a7d41f38e1d3 Vinod Koul 2017-12-14 205
:: The code at line 192 was first introduced by commit
:: d62a7d41f38e1d3f8f8a1c0db4dec7a5bb39268a soundwire: intel: Add Intel
init module
:: TO: Vinod Koul
:: CC: Greg Kroah-Hartman
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
* Mathieu Desnoyers: > - On Jun 3, 2020, at 8:05 AM, Florian Weimer fwei...@redhat.com wrote: > >> * Mathieu Desnoyers: >> >>> +#ifdef __cplusplus >>> +# if __cplusplus >= 201103L >>> +# define __rseq_static_assert(expr, diagnostic) static_assert (expr, >>> diagnostic) >>> +# define __rseq_alignof(type) alignof (type) >>> +# define __rseq_alignas(x) alignas (x) >>> +# define __rseq_tls_storage_class thread_local >>> +# endif >>> +#elif (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) >= 201112L >>> +# define __rseq_static_assert(expr, diagnostic) _Static_assert (expr, >>> diagnostic) >>> +# define __rseq_alignof(type)_Alignof (type) >>> +# define __rseq_alignas(x) _Alignas (x) >>> +# define __rseq_tls_storage_class_Thread_local >>> +#endif >> >> This does not seem to work. I get this with GCC 9: >> >> In file included from /tmp/cih_test_gsrKbC.cc:8:0: >> ../sysdeps/unix/sysv/linux/sys/rseq.h:42:50: error: attribute ignored >> [-Werror=attributes] >> # define __rseq_alignas(x) alignas (x) >> ^ >> ../sysdeps/unix/sysv/linux/sys/rseq.h:122:14: note: in expansion of macro >> ‘__rseq_alignas’ >> uint32_t __rseq_alignas (32) version; >> ^ > > Is that when compiling C or C++ code ? If it's C code, I would expect > "_Alignas" to be used, not "alignas". > > Which exact version of gcc do you use ? C++ code. CXX was set to this compiler at configure time: gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC) >> In any case, these changes really have to go into the UAPI header first. >> Only the __thread handling should remain. Otherwise, we'll have a tough >> situation on our hands changing the UAPI header, without introducing >> macro definition conflicts. I'd suggest to stick to the aligned >> attribute for the time being, like the current UAPI headers. > > OK. Should I do that in a separate patch, or you do it on top of my patchset, > or should I re-spin another round of the series ? I think the initial commit should mirror the current UAPI header contents. Keep the macros for the UAPI patch though. 8-) We can pick up these changes once they have been merged into Linux. Thanks, Florian
Re: [PATCH net] net: mvpp2: Enable autoneg bypass for 1000BaseX/2500BaseX ports
On Tue, Jun 02, 2020 at 11:50:16PM +0100, Russell King - ARM Linux admin wrote: > On Fri, May 29, 2020 at 06:33:40PM +0200, Andrew Lunn wrote: > > Given the current code, you cannot. Now we understand the > > requirements, we can come up with some ideas how to do this properly. > > Okay, I've been a little quiet because of sorting out the ARM tree > for merging with Linus (now done) and I've been working on a solution > to this problem. > > The good news is, I have an implementation in phylink to use the sync > status reported from a PCS, and to appropriately enable sync status > reporting. I'm quite nervous about having that enabled as a matter of > routine as I've seen some Marvell hardware end up with interrupt storms > from it - presumably due to noise pickup on the serdes lines being > interpreted as an intermittently valid signal. Yes, as expected - though not quite a storm - I'm seeing: [root@buildroot ~]# dmesg |grep 'eno2:' | wc -l 1604 [root@buildroot ~]# dmesg |grep 'eno2: mac link down' | wc -l 1598 [root@buildroot ~]# cat /proc/uptime 68868.10 137231.62 Similar happens with mvpp2 hardware - for Marvell's older mvpp2x driver, I had to disable the AN bypass bit: net: marvell: mvpp2x: avoid link status flood eth2 on the Macchiatobin board floods the system with link status interrupts whilethe link is down. This appears to be caused by the AN bypass logic causing spurious link status change interrupts, despite the port status register indicating that the link remains down. Avoid this by not setting the AN bypass bit for SGMII links. Signed-off-by: Russell King So, it looks like a different approach will be needed, since having a system flooded with unnecessary interrupts is obviously bad. This isn't limited to just Marvell mvneta and mvpp2, I think Chris at ZII has reported a similar behaviour on his boards with noise inducing serdes sync/link events. Hmm. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
linux-next: arm64 build failed - aarch64-linux-gnu-ld: cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file or directory
arm64 build failed on Linux-next 20200603. make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- HOSTCC=gcc CC="sccache aarch64-linux-gnu-gcc" O=build Image # aarch64-linux-gnu-ld: cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file or directory make[1]: *** [/linux/Makefile:1132: vmlinux] Error 1 -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] pinctrl: imxl: Fix an error handling path in 'imx1_pinctrl_core_probe()'
On Sat, May 30, 2020 at 10:20 PM Christophe JAILLET
wrote:
> When 'pinctrl_register()' has been turned into 'devm_pinctrl_register()',
> an error handling path has not been updated.
>
> Axe a now unneeded 'pinctrl_unregister()'.
>
> Fixes: e55e025d1687 ("pinctrl: imxl: Use devm_pinctrl_register() for pinctrl
> registration")
> Signed-off-by: Christophe JAILLET
Patch applied.
Yours,
Linus Walleij
Re: [PATCH v2 0/3] More frequency invariance fixes for x86
On Sun, May 31, 2020 at 08:24:50PM +0200, Giovanni Gherdovich wrote: > changes wrt v1: > > - add Peter Zijlstra's code to check for multiplication overflow, see > > https://lore.kernel.org/lkml/20200501133042.ge3...@hirez.programming.kicks-ass.net/ > - put all frequence invariant code behind CONFIG_X86_64, as the overflow > checks need 64 bits operations, see the build error at > > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org/thread/7GDIBOMNVDG5W2XZD4EICE2TUZR3THBN/ > - add additional patch to check for when base_freq > turbo_freq, > suggested by Peter Zijlstra at > > https://lore.kernel.org/lkml/20200501130427.gd3...@hirez.programming.kicks-ass.net/ Thanks!
RE: [PATCH v6 01/13] tools/libperf: introduce notion of static polled file descriptors
> -Original Message- > From: Hunter, Adrian > Sent: Wednesday, June 3, 2020 3:24 PM > To: Alexey Budankov > Cc: Arnaldo Carvalho de Melo ; Jiri Olsa > ; Namhyung Kim ; Alexander > Shishkin ; Peter Zijlstra > ; Ingo Molnar ; Andi Kleen > ; linux-kernel > Subject: Re: [PATCH v6 01/13] tools/libperf: introduce notion of static polled > file descriptors > > On 3/06/20 3:01 pm, Alexey Budankov wrote: > > Hi, > > > > On 03.06.2020 14:38, Adrian Hunter wrote: > >> On 1/06/20 11:05 pm, Alexey Budankov wrote: > >>> > >>> Implement adding of file descriptors by fdarray__add_stat() to > >>> fix-sized (currently 1) stat_entries array located at struct fdarray. > >>> Append added file descriptors to the array used by poll() syscall > >>> during fdarray__poll() call. Copy poll() result of the added > >>> descriptors from the array back to the storage for separate analysis. > >> > >> Why not instead call evlist__add_pollfd() before other fds are added, > >> so the fda->entries[] position is always fixed. Then this patch is not > needed. > > > > It then will block event consumption loop, at least in record mode, > > due to change sin initial assumptions behind fdarray__filter(). So > > extension of the API with 'static' fds looks safer w.r.t. possible > > functional regressions at the same time extending the API with ability > > to atomically wait for (poll()) not only event fds but also any other fds > during monitoring. > > So make fdarray__filter() return the number of filterable fds remaining. > Or perhaps simpler, compare the return value to the number of fds that are known not to be filterable
Re: [PATCH v2 1/4] gpio: gpiolib: Allow GPIO IRQs to lazy disable
On Fri, May 29, 2020 at 12:27 AM Stephen Boyd wrote:
> Quoting Linus Walleij (2020-05-28 14:33:36)
> > On Sat, May 23, 2020 at 7:11 PM Maulik Shah wrote:
> >
> > > With 'commit 461c1a7d4733 ("gpiolib: override irq_enable/disable")'
> > > gpiolib
> > > overrides irqchip's irq_enable and irq_disable callbacks. If irq_disable
> > > callback is implemented then genirq takes unlazy path to disable irq.
> > >
> > > Underlying irqchip may not want to implement irq_disable callback to lazy
> > > disable irq when client drivers invokes disable_irq(). By overriding
> > > irq_disable callback, gpiolib ends up always unlazy disabling IRQ.
> > >
> > > Allow gpiolib to lazy disable IRQs by overriding irq_disable callback only
> > > if irqchip implemented irq_disable. In cases where irq_disable is not
> > > implemented irq_mask is overridden. Similarly override irq_enable callback
> > > only if irqchip implemented irq_enable otherwise irq_unmask is overridden.
> > >
> > > Fixes: 461c1a7d47 (gpiolib: override irq_enable/disable)
> > > Signed-off-by: Maulik Shah
> >
> > I applied this patch 1/4 to the GPIO tree since it is nice on its own
> > and it is soon merge window.
> >
>
> Can you please clarify how this doesn't break things as discussed in a
> fork of this thread[1]?
>
> [1]
> https://lore.kernel.org/r/948defc1-5ea0-adbb-185b-5f5a81f2e...@codeaurora.org
I don't really understand I'm afraid.
Hans tested this on the one system that uses the method to disable the IRQ
and turn the line into an output, play around with it, then switch it back to
input (actually open drain) and then use the IRQ again.
Is something broken in practice or in theory?
Yours,
Linus Walleij
Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
Hi Robin, On 2020-06-03 17:51, Robin Murphy wrote: On 2020-06-03 13:00, Sai Prakash Ranjan wrote: Hi Robin, Mathieu On 2020-06-03 17:07, Robin Murphy wrote: On 2020-06-01 22:28, Mathieu Poirier wrote: That being said I'm sure that dependencies on an IOMMU isn't a problem confined to coresight. I am adding Robin Murphy, who added this commit [1], to the thread in the hope that he can provide guidance on the right way to do this. Right, it's not specific to CoreSight, and it's not even specific to IOMMUs really. In short, blame kexec ;) Yes it is not specific to coresight, we are targeting this for all consumers/clients of SMMU(atleast on SC7180 SoC). We have display throwing NoC/interconnect errors[1] during reboot after SMMU is disabled. This is also not specific to kexec either as you explained here [2] about a case with display which is exacly what is happening in our system [1]. Sure, but those instances are begging the question of why the SMMU is disabled at reboot in the first place ;) That is what happens in SMMU shutdown callback right? It is the reboot/shutdown flow. arm_smmu_device_shutdown() platform_drv_shutdown() device_shutdown() kernel_restart_prepare() kernel_restart() Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v6 13/13] perf record: introduce --ctl-fd[-ack] options
On 1/06/20 11:20 pm, Alexey Budankov wrote:
>
> Introduce --ctl-fd[-ack] options to pass open file descriptors numbers
> from command line. Extend perf-record.txt file with --ctl-fd[-ack]
perf-record.txt change seems to be missing.
> options description. Document possible usage model introduced by
> --ctl-fd[-ack] options by providing example bash shell script.
>
> Signed-off-by: Alexey Budankov
> ---
> tools/perf/builtin-record.c | 10 ++
> tools/perf/util/record.h| 2 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 0394e068dde8..8494ce964738 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -1749,6 +1749,9 @@ static int __cmd_record(struct record *rec, int argc,
> const char **argv)
> perf_evlist__start_workload(rec->evlist);
> }
>
> + if (evlist__initialize_ctlfd(rec->evlist, opts->ctl_fd,
> opts->ctl_fd_ack))
> + goto out_child;
> +
> if (opts->initial_delay) {
> pr_info(EVLIST_DISABLED_MSG);
> if (opts->initial_delay > 0) {
> @@ -1895,6 +1898,7 @@ static int __cmd_record(struct record *rec, int argc,
> const char **argv)
> record__synthesize_workload(rec, true);
>
> out_child:
> + evlist__finalize_ctlfd(rec->evlist);
> record__mmap_read_all(rec, true);
> record__aio_mmap_read_sync(rec);
>
> @@ -2380,6 +2384,8 @@ static struct record record = {
> },
> .mmap_flush = MMAP_FLUSH_DEFAULT,
> .nr_threads_synthesize = 1,
> + .ctl_fd = -1,
> + .ctl_fd_ack = -1,
> },
> .tool = {
> .sample = process_sample_event,
> @@ -2581,6 +2587,10 @@ static struct option __record_options[] = {
> "libpfm4 event selector. use 'perf list' to list available
> events",
> parse_libpfm_events_option),
> #endif
> + OPT_INTEGER(0, "ctl-fd", _fd,
> + "Listen on fd descriptor for command to control measurement
> ('enable': enable events, 'disable': disable events)"),
> + OPT_INTEGER(0, "ctl-fd-ack", _fd_ack,
> +"Send control command completion ('ack') to fd ack
> descriptor"),
> OPT_END()
> };
>
> diff --git a/tools/perf/util/record.h b/tools/perf/util/record.h
> index da138dcb4d34..4cb72a478af1 100644
> --- a/tools/perf/util/record.h
> +++ b/tools/perf/util/record.h
> @@ -70,6 +70,8 @@ struct record_opts {
> int mmap_flush;
> unsigned int comp_level;
> unsigned int nr_threads_synthesize;
> + int ctl_fd;
> + int ctl_fd_ack;
> };
>
> extern const char * const *record_usage;
>
Re: [PATCH v6 01/13] tools/libperf: introduce notion of static polled file descriptors
On 3/06/20 3:01 pm, Alexey Budankov wrote: > Hi, > > On 03.06.2020 14:38, Adrian Hunter wrote: >> On 1/06/20 11:05 pm, Alexey Budankov wrote: >>> >>> Implement adding of file descriptors by fdarray__add_stat() to >>> fix-sized (currently 1) stat_entries array located at struct fdarray. >>> Append added file descriptors to the array used by poll() syscall >>> during fdarray__poll() call. Copy poll() result of the added >>> descriptors from the array back to the storage for separate analysis. >> >> Why not instead call evlist__add_pollfd() before other fds are added, so >> the fda->entries[] position is always fixed. Then this patch is not needed. > > It then will block event consumption loop, at least in record mode, due to > change sin initial assumptions behind fdarray__filter(). So extension of the > API with 'static' fds looks safer w.r.t. possible functional regressions at > the same time extending the API with ability to atomically wait for (poll()) > not only event fds but also any other fds during monitoring. So make fdarray__filter() return the number of filterable fds remaining.
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
- On Jun 3, 2020, at 8:05 AM, Florian Weimer fwei...@redhat.com wrote: > * Mathieu Desnoyers: > >> +#ifdef __cplusplus >> +# if __cplusplus >= 201103L >> +# define __rseq_static_assert(expr, diagnostic) static_assert (expr, >> diagnostic) >> +# define __rseq_alignof(type) alignof (type) >> +# define __rseq_alignas(x) alignas (x) >> +# define __rseq_tls_storage_class thread_local >> +# endif >> +#elif (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) >= 201112L >> +# define __rseq_static_assert(expr, diagnostic) _Static_assert (expr, >> diagnostic) >> +# define __rseq_alignof(type)_Alignof (type) >> +# define __rseq_alignas(x) _Alignas (x) >> +# define __rseq_tls_storage_class_Thread_local >> +#endif > > This does not seem to work. I get this with GCC 9: > > In file included from /tmp/cih_test_gsrKbC.cc:8:0: > ../sysdeps/unix/sysv/linux/sys/rseq.h:42:50: error: attribute ignored > [-Werror=attributes] > # define __rseq_alignas(x) alignas (x) > ^ > ../sysdeps/unix/sysv/linux/sys/rseq.h:122:14: note: in expansion of macro > ‘__rseq_alignas’ > uint32_t __rseq_alignas (32) version; > ^ Is that when compiling C or C++ code ? If it's C code, I would expect "_Alignas" to be used, not "alignas". Which exact version of gcc do you use ? > > In any case, these changes really have to go into the UAPI header first. > Only the __thread handling should remain. Otherwise, we'll have a tough > situation on our hands changing the UAPI header, without introducing > macro definition conflicts. I'd suggest to stick to the aligned > attribute for the time being, like the current UAPI headers. OK. Should I do that in a separate patch, or you do it on top of my patchset, or should I re-spin another round of the series ? > > The resut looks okay to me. > > I'm still waiting for feedback from other maintainers whether the level > of documentation and testing is appropriate. OK. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
On 2020-06-03 13:00, Sai Prakash Ranjan wrote: Hi Robin, Mathieu On 2020-06-03 17:07, Robin Murphy wrote: On 2020-06-01 22:28, Mathieu Poirier wrote: That being said I'm sure that dependencies on an IOMMU isn't a problem confined to coresight. I am adding Robin Murphy, who added this commit [1], to the thread in the hope that he can provide guidance on the right way to do this. Right, it's not specific to CoreSight, and it's not even specific to IOMMUs really. In short, blame kexec ;) Yes it is not specific to coresight, we are targeting this for all consumers/clients of SMMU(atleast on SC7180 SoC). We have display throwing NoC/interconnect errors[1] during reboot after SMMU is disabled. This is also not specific to kexec either as you explained here [2] about a case with display which is exacly what is happening in our system [1]. Sure, but those instances are begging the question of why the SMMU is disabled at reboot in the first place ;) Robin. [1] https://lore.kernel.org/lkml/1591009402-681-1-git-send-email-mkri...@codeaurora.org/ [2] https://lore.kernel.org/lkml/5858bdac-b7f9-ac26-0c0d-c9653cef8...@arm.com/ The fundamental thing is that devices should stop any DMA activity at shutdown. For a normal poweroff you can typically get away without doing so, but over kexec, ongoing DMA traffic may corrupt memory in the new kernel (at worst, I think even DMA reads could potentially cause unexpected cache behaviour that might lead to mishaps, given the right combination of memory attributes). IOMMUs merely help to make the situation more serious. For similar kexec reasons, they need to disable any existing translations at shutdown (imagine if the second kernel didn't have an IOMMU driver). And at that point, even the normal poweroff case becomes problematic, because any device DMA that hasn't been shut down beforehand is now not necessarily going benignly to memory as it would in the no-IOMMU case above, but potentially to random physical addresses, with all the hilarity ensuing that you would expect from that. Thanks, Sai
Re: NAK: [PATCH][next] usb: xhci: fix spelling mistake in Kconfig "firwmare" -> "firmware"
On 03/06/2020 13:15, Colin Ian King wrote: > On 03/06/2020 13:11, Colin King wrote: >> From: Colin Ian King >> >> There are two spelling mistakes in the Kconfig text. Fix these. >> >> Signed-off-by: Colin Ian King >> --- >> drivers/usb/host/Kconfig | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig >> index 62c348062e48..5f4b6c71392c 100644 >> --- a/drivers/usb/host/Kconfig >> +++ b/drivers/usb/host/Kconfig >> @@ -44,10 +44,10 @@ config USB_XHCI_PCI >> default y >> >> config USB_XHCI_PCI_RENESAS >> -tristate "Support for additional Renesas xHCI controller with firwmare" >> +tristate "Support for additional Renesas xHCI controller with firmware" >> ---help--- >>Say 'Y' to enable the support for the Renesas xHCI controller with >> - firwmare. Make sure you have the firwmare for the device and >> + firmware. Make sure you have the firwmare for the device and >>installed on your system for this device to work. >>If unsure, say 'N'. >> >> > Spotted one more, I'll send a V2 > Please ignore the NAK, I was looking at the wrong file, doh. The original patch is fine. Colin
Re: arm64 build issue and mainline crash (was Re: linux-next: Tree for Jun 3)
Hi all, Just resending to get past the infradead.org mail filters (hopefully). On Wed, 3 Jun 2020 22:13:41 +1000 Stephen Rothwell wrote: > > Hi John, > > On Wed, 3 Jun 2020 12:45:18 +0100 John Garry wrote: > > > > On 03/06/2020 12:06, Stephen Rothwell wrote: > > > > JFYI, I am finding the vanilla defconfig build broken for arm64: > > > > LD vmlinux.o > > > > > > /home/john/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-ld: > > > > cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file > > or directory > > make[1]: *** [vmlinux] Error 1 > > > > > > make: *** [__sub-make] Error 2 > > > > > > john@htsatcamb-server:~/linux-next$ > > > > In addition, the reason I was testing this was because Linus' master > > (d6f9469a03d8 Merge tag 'erofs-for-5.8-rc1' of > > git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs) was crashing: > > > > [ 5.368948] loop: module loaded > > [ 5.372113] Unable to handle kernel paging request at virtual address > > f9ffcfec4000 > > [ 5.380067] Mem abort info: > > [ 5.382865]ESR = 0x9644 > > [ 5.385927]EC = 0x25: DABT (current EL), IL = 32 bits > > [ 5.391260]SET = 0, FnV = 0 > > [ 5.394319]EA = 0, S1PTW = 0 > > [ 5.397467] Data abort info: > > [ 5.400354]ISV = 0, ISS = 0x0044 > > [ 5.404203]CM = 0, WnR = 1 > > [ 5.407178] swapper pgtable: 4k pages, 48-bit VAs, pgdp=2f3f1000 > > [ 5.413909] [f9ffcfec4000] pgd= > > [ 5.418807] Internal error: Oops: 9644 [#1] PREEMPT SMP > > [ 5.424399] Modules linked in: > > [ 5.427462] CPU: 11 PID: 1 Comm: swapper/0 Not tainted > > 5.7.0-05047-gd6f9469a03d8 #388 > > [ 5.435325] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 > > IT21 Nemo 2.0 RC0 04/18/2018 > > [ 5.99] pstate: 4005 (nZcv daif -PAN -UAO BTYPE=--) > > [ 5.450098] pc : __memset+0x16c/0x1c0 > > [ 5.453770] lr : pcpu_alloc+0x1a0/0x668 > > [ 5.457615] sp : 800011d3bbd0 > > [ 5.460936] x29: 800011d3bbd0 x28: 001fb5495180 > > [ 5.466267] x27: 0001 x26: 0100 > > [ 5.471597] x25: 0001 x24: 0001 > > [ 5.476928] x23: 80001135e9a0 x22: 80001196a200 > > [ 5.482259] x21: 80001196a360 x20: > > [ 5.487590] x19: x18: fe107e6fdb08 > > [ 5.492920] x17: 003f x16: > > [ 5.498251] x15: 001ffbffee00 x14: 0002 > > [ 5.503581] x13: x12: 003f > > [ 5.508912] x11: 0040 x10: 0040 > > [ 5.514243] x9 : x8 : f9ffcfec4000 > > [ 5.519573] x7 : x6 : 003f > > [ 5.524904] x5 : 0040 x4 : > > [ 5.530234] x3 : 0004 x2 : 00c0 > > [ 5.535565] x1 : x0 : f9ffcfec4000 > > [ 5.540896] Call trace: > > [ 5.543344] __memset+0x16c/0x1c0 > > [ 5.54] __alloc_percpu+0x14/0x1c > > [ 5.550338] alloc_workqueue+0x164/0x42c > > [ 5.554273] init+0x24/0xa4 > > [ 5.557071] do_one_initcall+0x50/0x194 > > [ 5.560917] kernel_init_freeable+0x1e4/0x250 > > [ 5.565288] kernel_init+0x10/0x104 > > [ 5.568785] ret_from_fork+0x10/0x18 > > [ 5.572372] Code: 91010108 544a 8b040108 cb050042 (d50b7428) > > [ 5.578568] ---[ end trace 63c299bbe9b8ea9e ]--- > > [ 5.583205] Kernel panic - not syncing: Attempted to kill init! > > exitcode=0x000b > > [ 5.590903] SMP: stopping secondary CPUs > > [ 5.594846] Kernel Offset: 0xf from 0x80001000 > > [ 5.600350] PHYS_OFFSET: 0x0 > > [ 5.603235] CPU features: 0x240022,20806008 > > [ 5.607430] Memory Limit: none > > [ 5.610500] ---[ end Kernel panic - not syncing: Attempted to kill init! > > exitcode=0x000b ]--- > > > > I'll check that when I get a chance. Maybe all just transient. > > Yeah, I forgot to add a patch to make arm64 build again (it will be in > linux-next tomorrow). If you want to apply it to your tree, here is > what I was given: > > diff --git a/Makefile b/Makefile > index f80c4ff93ec9..fbb4b95ae648 100644 > --- a/Makefile > +++ b/Makefile > @@ -1074,7 +1074,7 @@ build-dirs:= $(vmlinux-dirs) > clean-dirs := $(vmlinux-alldirs) > > # Externally visible symbols (used by link-vmlinux.sh) > -KBUILD_VMLINUX_OBJS := $(head-y) $(addsuffix built-in.a, $(core-y)) > +KBUILD_VMLINUX_OBJS := $(head-y) $(patsubst %/,%/built-in.a, $(core-y)) > KBUILD_VMLINUX_OBJS += $(addsuffix built-in.a, $(filter %/, $(libs-y))) > ifdef CONFIG_MODULES > KBUILD_VMLINUX_OBJS += $(patsubst %/, %/lib.a, $(filter %/, $(libs-y))) -- Cheers, Stephen Rothwell pgpCFfuRVJwIG.pgp Description: OpenPGP digital signature
Re: [PATCH 0/9] x86/entry fixes
On Wed, Jun 03, 2020 at 02:08:57PM +0200, Marco Elver wrote: > What is the .config you used? I somehow can't reproduce. I've applied > the patches on top of -tip/master. So tip/master, my patches, your patches, this series. $ make CC=/opt/llvm/bin/clang O=defconfig-build/ -j80 -s bzImage is what I used, with the below config. # # Automatically generated file; DO NOT EDIT. # Linux/x86 5.7.0 Kernel Configuration # # # Compiler: ClangBuiltLinux clang version 11.0.0 (https://github.com/llvm/llvm-project a3ada630d8abd00930db1c2822427be2301a489e) # CONFIG_GCC_VERSION=0 CONFIG_LD_VERSION=23400 CONFIG_CC_IS_CLANG=y CONFIG_CLANG_VERSION=11 CONFIG_CC_CAN_LINK=y CONFIG_CC_HAS_ASM_GOTO=y CONFIG_CC_HAS_ASM_INLINE=y CONFIG_CC_HAS_WORKING_NOSANITIZE=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_TABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_IRQ_MSI_IOMMU=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set # end of IRQ subsystem CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_INIT=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set # CONFIG_NO_HZ_IDLE is not set CONFIG_NO_HZ_FULL=y CONFIG_CONTEXT_TRACKING=y # CONFIG_CONTEXT_TRACKING_FORCE is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # end of Timers subsystem # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y CONFIG_PREEMPTION=y # # CPU/Task time and stats accounting # CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_VIRT_CPU_ACCOUNTING_GEN=y # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_SCHED_THERMAL_PRESSURE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # CONFIG_PSI is not set # end of CPU/Task time and stats accounting CONFIG_CPU_ISOLATION=y # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_PREEMPT_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_TASKS_RCU_GENERIC=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y CONFIG_RCU_NOCB_CPU=y # end of RCU Subsystem # CONFIG_IKCONFIG is not set # CONFIG_IKHEADERS is not set CONFIG_LOG_BUF_SHIFT=18 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # # Scheduler features # # CONFIG_UCLAMP_TASK is not set # end of Scheduler features CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_CC_HAS_INT128=y CONFIG_ARCH_SUPPORTS_INT128=y # CONFIG_NUMA_BALANCING is not set CONFIG_CGROUPS=y # CONFIG_MEMCG is not set # CONFIG_BLK_CGROUP is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set # CONFIG_RT_GROUP_SCHED is not set # CONFIG_CGROUP_PIDS is not set # CONFIG_CGROUP_RDMA is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_HUGETLB is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_DEBUG is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_TIME_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set CONFIG_PID_NS=y CONFIG_NET_NS=y # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y # CONFIG_BOOT_CONFIG is not set CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_HAVE_UID16=y
Re: [PATCH v3 0/4] pinctrl: bcm2835: Add support for wake-up interrupts
On Sun, May 31, 2020 at 2:11 AM Florian Fainelli wrote: > This patch series updates the bcm2835 pinctrl driver to support > the BCM7211 SoC which is quite similar to 2711 (Raspberry Pi 4) > except that it also supports wake-up interrupts. > > Thanks! > > Changes in v3: > > - added Rob's Acked-by for the binding patches (#1 and #2) > - correct check on the number of GPIOs in irq_set_irq_wake (Stefan) Applied this v3 version right in time for the merge window. Yours, Linus Walleij
Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers
On Wed, Jun 03, 2020 at 04:51:18AM -0700, Rajat Jain wrote: > Hello, > > > > > > Thanks for the pointer! I'm still looking at the details yet, but a > > > quick look (usb_dev_authorized()) seems to suggest that this API is > > > "device based". The multiple levels of "authorized" seem to take shape > > > from either how it is wired or from userspace choice. Once authorized, > > > USB device or interface is authorized to be used by *anyone* (can be > > > attached to any drivers). Do I understand it right that it does not > > > differentiate between drivers? > > > > Yes, and that is what you should do, don't fixate on drivers. Users > > know how to control and manage devices. Us kernel developers are > > responsible for writing solid drivers and getting them merged into the > > kernel tree and maintaining them over time. Drivers in the kernel > > should always be trusted, ... > > 1) Yes, I agree that this would be ideal, and this should be our > mission. I should clarify that I may have used the wrong term > "Trusted/Certified drivers". I didn't really mean that the drivers may > be malicious by intent. What I really meant is that a driver may have > an attack surface, which is a vulnerability that may be exploited. Any code has such a thing, proving otherwise is a tough problem :) > Realistically speaking, finding vulnerabilities in drivers, creating > attacks to exploit them, and fixing them is a never ending cat and > mouse game. At Least "identifying the vulnerabilities" part is better > performed by security folks rather than driver writers. Are you sure about that? It's hard to prove a negative :) > Earlier in the > thread I had mentioned certain studies/projects that identified and > exploited such vulnerabilities in the drivers. I should have used the > term "Vetted Drivers" maybe to convey the intent better - drivers that > have been vetted by a security focussed team (admin). What I'm > advocating here is an administrator's right to control the drivers > that he wants to allow for external ports on his systems. That's an odd thing, but sure, if you want to write up such a policy for your systems, great. But that policy does not belong in the kernel, it belongs in userspace. > 2) In addition to the problem of driver negligences / vulnerabilities > to be exploited, we ran into another problem with the "whitelist > devices only" approach. We did start with the "device based" approach > only initially - but quickly realized that anything we use to > whitelist an external device can only be based on the info provided by > *that device* itself. So until we have devices that exchange > certificates with kernel [1], it is easy for a malicious device to > spoof a whitelisted device (by presenting the same VID:DID or any > other data that is used by us to whitelist it). > > [1] > https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-security-enhancements-spec.html > > I hope that helps somewhat clarify how / why we reached here? Kind of, I still think all you need to do is worry about controling the devices and if a driver should bind to it or not. Again, much like USB has been doing for a very long time now. The idea of "spoofing" ids also is not new, and has been around for a very long time as well, and again, the controls that the USB core gives you allows you to make any type of policy decision you want to, in userspace. So please, in summary: - don't think this is some new type of thing, it's an old issue transferred to yet-another-hardware-bus. Not to say this is not important, just please look at the work that others have done in the past to help mitigate and solve this (reading the Wireless USB spec should help you out here too, as they detailed all of this.) - do copy what USB did, by moving that logic into the driver core so that all busses who want to take advantage of this type of functionality, easily can do so. thanks, greg k-h
[no subject]
-- Contact me for your family inheritance valued at seven million united states contact my private email here for more details: coulibalyk...@yahoo.com Many thanks in advance. Barrister Coulibaly Kone
Re: [PATCH] sched/debug: Add new tracepoints to track util_est
On Wed, Jun 03, 2020 at 01:04:26PM +0100, Valentin Schneider wrote: > > On 27/05/20 17:39, vincent.donnef...@arm.com wrote: > > From: Vincent Donnefort > > > > The util_est signals are key elements for EAS task placement and > > frequency selection. Having tracepoints to track these signals enables > > load-tracking and schedutil testing and/or debugging by a toolkit. > > > > Signed-off-by: Vincent Donnefort > > > > To put it more bluntly, we can't really do task placement / load tracking > testing if util_est is enabled (which reminds me we may want to get rid of > the SCHED_FEAT at some point, it's been default on since ~v4.17), since > there can be noticeable gaps between util_avg and util_est. > > Reviewed-by: Valentin Schneider Thanks!
NAK: [PATCH][next] usb: xhci: fix spelling mistake in Kconfig "firwmare" -> "firmware"
On 03/06/2020 13:11, Colin King wrote: > From: Colin Ian King > > There are two spelling mistakes in the Kconfig text. Fix these. > > Signed-off-by: Colin Ian King > --- > drivers/usb/host/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > index 62c348062e48..5f4b6c71392c 100644 > --- a/drivers/usb/host/Kconfig > +++ b/drivers/usb/host/Kconfig > @@ -44,10 +44,10 @@ config USB_XHCI_PCI > default y > > config USB_XHCI_PCI_RENESAS > - tristate "Support for additional Renesas xHCI controller with firwmare" > + tristate "Support for additional Renesas xHCI controller with firmware" > ---help--- > Say 'Y' to enable the support for the Renesas xHCI controller with > - firwmare. Make sure you have the firwmare for the device and > + firmware. Make sure you have the firwmare for the device and > installed on your system for this device to work. > If unsure, say 'N'. > > Spotted one more, I'll send a V2
Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
Hi Mike, On 2020-06-03 16:57, Mike Leach wrote: Hi, On Wed, 3 Jun 2020 at 11:24, Sai Prakash Ranjan wrote: Hi Mike, Thanks again for looking at this. On 2020-06-03 03:42, Mike Leach wrote: [...] >> >> SMMU/IOMMU won't be able to do much here as it is the client's >> responsiblity to >> properly shutdown and SMMU device link just makes sure that >> SMMU(supplier) shutdown is >> called only after its consumers shutdown callbacks are called. > > I think this use case can be handled slightly differently than the > general requirements for modular CoreSight drivers. > > What is needed here is a way of stopping the underlying ETR hardware > from issuing data to the SMMU, until the entire device has been shut > down, in a way that does not remove the driver, breaking existing > references and causing a system crash. > > We could introduce a new mode to the ETR driver - e.g. > CS_MODE_SHUTDOWN. > > At the end of the block tmc_shutdown(struct amba_device *adev), set > drvdata->mode to CS_MODE_SHUTDOWN & remove the coresight_unregister(). > This new mode can be used to prevent the underlying hardware from > being able to restart until the device is re-powered. > > This mode can be detected in the code that enables / disables the ETR > and handled appropriately (updates to tmc_enable_etr_sink and > tmc_disable_etr_sink). > This mode will persist until the device is re-started - but because we > are on the device shutdown path this is not an issue. > > This should leave the CoreSight infrastructure stable until the > drivers are shut down normally as part of the device power down > process. > Sounds good to me, but if the coresight_unregister() is the trouble point causing these crashes, then can't we just remove that from tmc_shutdown() callback? This would be like maintaining the same behaviour as now where on reboot/shutdown we basically don't do anything except for disabling ETR. No - the new mode prevents race conditions where the thread shutting down the SMMU does the ETR shutdown, but then another thread happens to be trying to start trace and restarts the ETR. It also prevents the condition Mathieu discussed where a thread might be attempting to shutdown trace - this could try to disable the hardware again re-releasing resources/ re-flushing and waiting for stop. I do not think there will a race between SMMU shutdown and ETR shutdown. Driver core takes care of calling SMMU shutdown after its consumer shutdown callbacks via device link, otherwise there would already be bugs in all other client drivers. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH][next] usb: xhci: fix spelling mistake in Kconfig "firwmare" -> "firmware"
From: Colin Ian King There are two spelling mistakes in the Kconfig text. Fix these. Signed-off-by: Colin Ian King --- drivers/usb/host/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 62c348062e48..5f4b6c71392c 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -44,10 +44,10 @@ config USB_XHCI_PCI default y config USB_XHCI_PCI_RENESAS - tristate "Support for additional Renesas xHCI controller with firwmare" + tristate "Support for additional Renesas xHCI controller with firmware" ---help--- Say 'Y' to enable the support for the Renesas xHCI controller with - firwmare. Make sure you have the firwmare for the device and + firmware. Make sure you have the firwmare for the device and installed on your system for this device to work. If unsure, say 'N'. -- 2.25.1
Re: [PATCH 14/15] dt-bindings: pinctrl: stm32: Add missing interrupts property
On Wed, May 13, 2020 at 5:00 PM Benjamin Gaignard wrote: > Driver use interrupt-parent field so update the bindings to allow it. > > Signed-off-by: Benjamin Gaignard Patch applied. Yours, Linus Walleij
Re: [PATCH] fsi: master-ast-cf: fix spelling mistake "firwmare" -> "firmware"
On Wed, 3 Jun 2020, at 21:35, Colin King wrote: > From: Colin Ian King > > There is a spelling mistake in a dev_err error message. Fix it. > > Signed-off-by: Colin Ian King Reviewed-by: Andrew Jeffery
Re: [PATCH 0/9] x86/entry fixes
On Wed, 3 Jun 2020 at 14:08, Peter Zijlstra wrote: > > On Wed, Jun 03, 2020 at 02:00:37PM +0200, Peter Zijlstra wrote: > > On Wed, Jun 03, 2020 at 01:40:14PM +0200, Peter Zijlstra wrote: > > > The first patch is a fix for x86/entry, I'm quicky runing out of brown > > > paper bags again :/ > > > > > > The rest goes on top of these: > > > > > > https://lkml.kernel.org/r/20200602173103.931412...@infradead.org > > > https://lkml.kernel.org/r/20200602184409.22142-1-el...@google.com > > > > > > patches from myself and Marco that enable *SAN builds. So far GCC-KASAN > > > seen to > > > behave quite well, I've yet to try UBSAN. > > > > GCC10 + UBSAN: > > > > vmlinux.o: warning: objtool: match_held_lock()+0x1b2: call to > > __ubsan_handle_type_mismatch_v1() leaves .noinstr.text section > > vmlinux.o: warning: objtool: rcu_nmi_enter()+0x234: call to > > __ubsan_handle_out_of_bounds() leaves .noinstr.text section > > vmlinux.o: warning: objtool: __rcu_is_watching()+0x59: call to > > __ubsan_handle_out_of_bounds() leaves .noinstr.text section > > > > All of them are marked noinstr. So I suppose UBSAN is just buggered in > > GCC :-/ > > CLANG11 + UBSAN: > > vmlinux.o: warning: objtool: exc_nmi()+0x1c3: call to > __ubsan_handle_load_invalid_value() leaves .noinstr.text section > vmlinux.o: warning: objtool: poke_int3_handler()+0x72: call to > __ubsan_handle_load_invalid_value() leaves .noinstr.text section > vmlinux.o: warning: objtool: mce_check_crashing_cpu()+0x71: call to > __ubsan_handle_load_invalid_value() leaves .noinstr.text section > vmlinux.o: warning: objtool: lock_is_held_type()+0x95: call to > __ubsan_handle_out_of_bounds() leaves .noinstr.text section > vmlinux.o: warning: objtool: rcu_nmi_enter()+0xba: call to > __ubsan_handle_out_of_bounds() leaves .noinstr.text section > vmlinux.o: warning: objtool: __rcu_is_watching()+0x2c: call to > __ubsan_handle_out_of_bounds() leaves .noinstr.text section > > IOW, UBSAN appears to be completely hosed. What is the .config you used? I somehow can't reproduce. I've applied the patches on top of -tip/master. Thanks, -- Marco
[PATCH v2] usb: dwc3: Add support for VBUS power control
Support VBUS power control using regulator framework. Enables the regulator
while the port is in host mode.
Signed-off-by: Mike Looijmans
---
v2: Add missing devm_regulator_get call which got lost during rebase
.../devicetree/bindings/usb/dwc3.txt | 1 +
drivers/usb/dwc3/core.c | 34 ++-
drivers/usb/dwc3/core.h | 4 +++
drivers/usb/dwc3/drd.c| 6 ++--
4 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 9946ff9ba735..56bc3f238e2d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -37,6 +37,7 @@ Optional properties:
- phys: from the *Generic PHY* bindings
- phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy"
or "usb3-phy".
+ - vbus-supply: Regulator handle that provides the VBUS power.
- resets: set of phandle and reset specifier pairs
- snps,usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
- snps,usb3_lpm_capable: determines if platform is USB3 LPM capable
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index edc17155cb2b..ad341a182999 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -112,6 +113,23 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
dwc->current_dr_role = mode;
}
+void dwc3_set_vbus(struct dwc3 *dwc, bool enable)
+{
+ int ret;
+
+ if (enable != dwc->vbus_reg_enabled) {
+ if (enable)
+ ret = regulator_enable(dwc->vbus_reg);
+ else
+ ret = regulator_disable(dwc->vbus_reg);
+ if (!ret)
+ dwc->vbus_reg_enabled = enable;
+ }
+
+ if (dwc->usb2_phy)
+ otg_set_vbus(dwc->usb2_phy->otg, enable);
+}
+
static void __dwc3_set_mode(struct work_struct *work)
{
struct dwc3 *dwc = work_to_dwc(work);
@@ -164,8 +182,7 @@ static void __dwc3_set_mode(struct work_struct *work)
if (ret) {
dev_err(dwc->dev, "failed to initialize host\n");
} else {
- if (dwc->usb2_phy)
- otg_set_vbus(dwc->usb2_phy->otg, true);
+ dwc3_set_vbus(dwc, true);
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_HOST);
}
@@ -173,8 +190,7 @@ static void __dwc3_set_mode(struct work_struct *work)
case DWC3_GCTL_PRTCAP_DEVICE:
dwc3_event_buffers_setup(dwc);
- if (dwc->usb2_phy)
- otg_set_vbus(dwc->usb2_phy->otg, false);
+ dwc3_set_vbus(dwc, false);
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_DEVICE);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_DEVICE);
@@ -1183,8 +1199,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
case USB_DR_MODE_PERIPHERAL:
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
- if (dwc->usb2_phy)
- otg_set_vbus(dwc->usb2_phy->otg, false);
+ dwc3_set_vbus(dwc, false);
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_DEVICE);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_DEVICE);
@@ -1198,8 +1213,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
case USB_DR_MODE_HOST:
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
- if (dwc->usb2_phy)
- otg_set_vbus(dwc->usb2_phy->otg, true);
+ dwc3_set_vbus(dwc, true);
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_HOST);
@@ -1470,6 +1484,10 @@ static int dwc3_probe(struct platform_device *pdev)
dwc3_get_properties(dwc);
+ dwc->vbus_reg = devm_regulator_get_optional(dev, "vbus");
+ if (IS_ERR(dwc->vbus_reg))
+ return PTR_ERR(dwc->vbus_reg);
+
dwc->reset = devm_reset_control_array_get(dev, true, true);
if (IS_ERR(dwc->reset))
return PTR_ERR(dwc->reset);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4c171a8e215f..cee2574d7bf4 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1085,6 +1085,9 @@ struct dwc3 {
boolphys_ready;
+ struct regulator*vbus_reg;
+ boolvbus_reg_enabled;
+
struct ulpi *ulpi;
boolulpi_ready;
@@ -1397,6 +1400,7 @@ struct dwc3_gadget_ep_cmd_params {
/* prototypes */
void
Re: [PATCH 0/9] x86/entry fixes
On Wed, Jun 03, 2020 at 02:00:37PM +0200, Peter Zijlstra wrote: > On Wed, Jun 03, 2020 at 01:40:14PM +0200, Peter Zijlstra wrote: > > The first patch is a fix for x86/entry, I'm quicky runing out of brown > > paper bags again :/ > > > > The rest goes on top of these: > > > > https://lkml.kernel.org/r/20200602173103.931412...@infradead.org > > https://lkml.kernel.org/r/20200602184409.22142-1-el...@google.com > > > > patches from myself and Marco that enable *SAN builds. So far GCC-KASAN > > seen to > > behave quite well, I've yet to try UBSAN. > > GCC10 + UBSAN: > > vmlinux.o: warning: objtool: match_held_lock()+0x1b2: call to > __ubsan_handle_type_mismatch_v1() leaves .noinstr.text section > vmlinux.o: warning: objtool: rcu_nmi_enter()+0x234: call to > __ubsan_handle_out_of_bounds() leaves .noinstr.text section > vmlinux.o: warning: objtool: __rcu_is_watching()+0x59: call to > __ubsan_handle_out_of_bounds() leaves .noinstr.text section > > All of them are marked noinstr. So I suppose UBSAN is just buggered in > GCC :-/ CLANG11 + UBSAN: vmlinux.o: warning: objtool: exc_nmi()+0x1c3: call to __ubsan_handle_load_invalid_value() leaves .noinstr.text section vmlinux.o: warning: objtool: poke_int3_handler()+0x72: call to __ubsan_handle_load_invalid_value() leaves .noinstr.text section vmlinux.o: warning: objtool: mce_check_crashing_cpu()+0x71: call to __ubsan_handle_load_invalid_value() leaves .noinstr.text section vmlinux.o: warning: objtool: lock_is_held_type()+0x95: call to __ubsan_handle_out_of_bounds() leaves .noinstr.text section vmlinux.o: warning: objtool: rcu_nmi_enter()+0xba: call to __ubsan_handle_out_of_bounds() leaves .noinstr.text section vmlinux.o: warning: objtool: __rcu_is_watching()+0x2c: call to __ubsan_handle_out_of_bounds() leaves .noinstr.text section IOW, UBSAN appears to be completely hosed.
Re: [PATCH 4/4] sched/fair: Remove unused 'sd' parameter from scale_rt_capacity()
On Wed, 3 Jun 2020 at 10:03, Dietmar Eggemann wrote:
>
> Since commit 8ec59c0f5f49 ("sched/topology: Remove unused 'sd'
> parameter from arch_scale_cpu_capacity()") it is no longer needed.
>
> Signed-off-by: Dietmar Eggemann
> ---
> kernel/sched/fair.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Vincent Guittot
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 5c4a559d0dae..7158d4e3c855 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8039,7 +8039,7 @@ static inline void init_sd_lb_stats(struct sd_lb_stats
> *sds)
> };
> }
>
> -static unsigned long scale_rt_capacity(struct sched_domain *sd, int cpu)
> +static unsigned long scale_rt_capacity(int cpu)
> {
> struct rq *rq = cpu_rq(cpu);
> unsigned long max = arch_scale_cpu_capacity(cpu);
> @@ -8071,7 +8071,7 @@ static unsigned long scale_rt_capacity(struct
> sched_domain *sd, int cpu)
>
> static void update_cpu_capacity(struct sched_domain *sd, int cpu)
> {
> - unsigned long capacity = scale_rt_capacity(sd, cpu);
> + unsigned long capacity = scale_rt_capacity(cpu);
> struct sched_group *sdg = sd->groups;
>
> cpu_rq(cpu)->cpu_capacity_orig = arch_scale_cpu_capacity(cpu);
> --
> 2.17.1
>
Re: [PATCH v4 10/10] perf record: introduce --ctl-fd[-ack] options
On 25/05/20 5:23 pm, Alexey Budankov wrote:
>
> Introduce --ctl-fd[-ack] options to pass open file descriptors numbers
> from command line. Extend perf-record.txt file with --ctl-fd[-ack]
> options description. Document possible usage model introduced by
> --ctl-fd[-ack] options by providing example bash shell script.
>
> Signed-off-by: Alexey Budankov
> ---
> tools/perf/Documentation/perf-record.txt | 39
> tools/perf/builtin-record.c | 10 ++
> tools/perf/util/record.h | 2 ++
> 3 files changed, 51 insertions(+)
>
> diff --git a/tools/perf/Documentation/perf-record.txt
> b/tools/perf/Documentation/perf-record.txt
> index c2c4ce7ccee2..5c012cfe68a4 100644
> --- a/tools/perf/Documentation/perf-record.txt
> +++ b/tools/perf/Documentation/perf-record.txt
> @@ -614,6 +614,45 @@ appended unit character - B/K/M/G
> The number of threads to run when synthesizing events for existing
> processes.
> By default, the number of threads equals 1.
>
> +--ctl-fd::
> +--ctl-fd-ack::
> +Listen on ctl-fd descriptor for command to control measurement ('enable':
> enable events,
> +'disable': disable events. Optionally send control command completion
> ('ack') to fd-ack
> +descriptor to synchronize with the controlling process.
You should also explain the use of --delay=-1 here.
Example of bash shell script
> +to enable and disable events during measurements:
> +
> +#!/bin/bash
> +
> +ctl_dir=/tmp/
> +
> +ctl_fifo=${ctl_dir}perf_ctl.fifo
> +test -p ${ctl_fifo} && unlink ${ctl_fifo}
> +mkfifo ${ctl_fifo}
> +exec {ctl_fd}<>${ctl_fifo}
> +
> +ctl_ack_fifo=${ctl_dir}perf_ctl_ack.fifo
> +test -p ${ctl_ack_fifo} && unlink ${ctl_ack_fifo}
> +mkfifo ${ctl_ack_fifo}
> +exec {ctl_fd_ack}<>${ctl_ack_fifo}
> +
> +perf record -D -1 -e cpu-cycles -a\
> +--ctl-fd ${ctl_fd} --ctl-fd-ack ${ctl_fd_ack} \
> +-- sleep 30 &
> +perf_pid=$!
> +
> +sleep 5 && echo 'enable' >&${ctl_fd} && read -u ${ctl_fd_ack} e1 && echo
> "enabled(${e1})"
> +sleep 10 && echo 'disable' >&${ctl_fd} && read -u ${ctl_fd_ack} d1 && echo
> "disabled(${d1})"
> +
> +exec {ctl_fd_ack}>&-
> +unlink ${ctl_ack_fifo}
> +
> +exec {ctl_fd}>&-
> +unlink ${ctl_fifo}
> +
> +wait -n ${perf_pid}
> +exit $?
> +
> +
> SEE ALSO
>
> linkperf:perf-stat[1], linkperf:perf-list[1], linkperf:perf-intel-pt[1]
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 1ff3b7a77283..e057a2be42b7 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -1761,6 +1761,9 @@ static int __cmd_record(struct record *rec, int argc,
> const char **argv)
> perf_evlist__start_workload(rec->evlist);
> }
>
> + if (evlist__initialize_ctlfd(rec->evlist, opts->ctl_fd,
> opts->ctl_fd_ack))
> + goto out_child;
> +
> if (opts->initial_delay) {
> pr_info(EVLIST_DISABLED_MSG);
> if (opts->initial_delay > 0) {
> @@ -1907,6 +1910,7 @@ static int __cmd_record(struct record *rec, int argc,
> const char **argv)
> record__synthesize_workload(rec, true);
>
> out_child:
> + evlist__finalize_ctlfd(rec->evlist);
> record__mmap_read_all(rec, true);
> record__aio_mmap_read_sync(rec);
>
> @@ -2392,6 +2396,8 @@ static struct record record = {
> },
> .mmap_flush = MMAP_FLUSH_DEFAULT,
> .nr_threads_synthesize = 1,
> + .ctl_fd = -1,
> + .ctl_fd_ack = -1,
> },
> .tool = {
> .sample = process_sample_event,
> @@ -2587,6 +2593,10 @@ static struct option __record_options[] = {
> OPT_UINTEGER(0, "num-thread-synthesize",
>_threads_synthesize,
>"number of threads to run for event synthesis"),
> + OPT_INTEGER(0, "ctl-fd", _fd,
> + "Listen on fd descriptor for command to control measurement
> ('enable': enable events, 'disable': disable events)"),
> + OPT_INTEGER(0, "ctl-fd-ack", _fd_ack,
> + "Send control command completion ('ack') to fd ack
> descriptor"),
> OPT_END()
> };
>
> diff --git a/tools/perf/util/record.h b/tools/perf/util/record.h
> index 96a73bbd8cd4..da18aeca3623 100644
> --- a/tools/perf/util/record.h
> +++ b/tools/perf/util/record.h
> @@ -69,6 +69,8 @@ struct record_opts {
> int mmap_flush;
> unsigned int comp_level;
> unsigned int nr_threads_synthesize;
> + int ctl_fd;
> + int ctl_fd_ack;
> };
>
> extern const char * const *record_usage;
>
Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20)
* Mathieu Desnoyers: > +#ifdef __cplusplus > +# if __cplusplus >= 201103L > +# define __rseq_static_assert(expr, diagnostic) static_assert (expr, > diagnostic) > +# define __rseq_alignof(type) alignof (type) > +# define __rseq_alignas(x) alignas (x) > +# define __rseq_tls_storage_class thread_local > +# endif > +#elif (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) >= 201112L > +# define __rseq_static_assert(expr, diagnostic) _Static_assert (expr, > diagnostic) > +# define __rseq_alignof(type)_Alignof (type) > +# define __rseq_alignas(x) _Alignas (x) > +# define __rseq_tls_storage_class_Thread_local > +#endif This does not seem to work. I get this with GCC 9: In file included from /tmp/cih_test_gsrKbC.cc:8:0: ../sysdeps/unix/sysv/linux/sys/rseq.h:42:50: error: attribute ignored [-Werror=attributes] # define __rseq_alignas(x) alignas (x) ^ ../sysdeps/unix/sysv/linux/sys/rseq.h:122:14: note: in expansion of macro ‘__rseq_alignas’ uint32_t __rseq_alignas (32) version; ^ In any case, these changes really have to go into the UAPI header first. Only the __thread handling should remain. Otherwise, we'll have a tough situation on our hands changing the UAPI header, without introducing macro definition conflicts. I'd suggest to stick to the aligned attribute for the time being, like the current UAPI headers. The resut looks okay to me. I'm still waiting for feedback from other maintainers whether the level of documentation and testing is appropriate. Thanks, Florian
[PATCH] fsi: master-ast-cf: fix spelling mistake "firwmare" -> "firmware"
From: Colin Ian King
There is a spelling mistake in a dev_err error message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/fsi/fsi-master-ast-cf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fsi/fsi-master-ast-cf.c b/drivers/fsi/fsi-master-ast-cf.c
index 04d10ea8d343..85d9be38b32b 100644
--- a/drivers/fsi/fsi-master-ast-cf.c
+++ b/drivers/fsi/fsi-master-ast-cf.c
@@ -838,7 +838,7 @@ static int load_copro_firmware(struct fsi_master_acf
*master)
rc = request_firmware(, FW_FILE_NAME, master->dev);
if (rc) {
dev_err(
- master->dev, "Error %d to load firwmare '%s' !\n",
+ master->dev, "Error %d to load firmware '%s' !\n",
rc, FW_FILE_NAME);
return rc;
}
--
2.25.1
Re: [PATCH RFC 01/13] vhost: option to fetch descriptors through an independent struct
On 2020/6/3 下午5:48, Michael S. Tsirkin wrote:
On Wed, Jun 03, 2020 at 03:13:56PM +0800, Jason Wang wrote:
On 2020/6/2 下午9:05, Michael S. Tsirkin wrote:
[...]
+
+static int fetch_indirect_descs(struct vhost_virtqueue *vq,
+ struct vhost_desc *indirect,
+ u16 head)
+{
+ struct vring_desc desc;
+ unsigned int i = 0, count, found = 0;
+ u32 len = indirect->len;
+ struct iov_iter from;
+ int ret;
+
+ /* Sanity check */
+ if (unlikely(len % sizeof desc)) {
+ vq_err(vq, "Invalid length in indirect descriptor: "
+ "len 0x%llx not multiple of 0x%zx\n",
+ (unsigned long long)len,
+ sizeof desc);
+ return -EINVAL;
+ }
+
+ ret = translate_desc(vq, indirect->addr, len, vq->indirect,
+UIO_MAXIOV, VHOST_ACCESS_RO);
+ if (unlikely(ret < 0)) {
+ if (ret != -EAGAIN)
+ vq_err(vq, "Translation failure %d in indirect.\n",
ret);
+ return ret;
+ }
+ iov_iter_init(, READ, vq->indirect, ret, len);
+
+ /* We will use the result as an address to read from, so most
+* architectures only need a compiler barrier here. */
+ read_barrier_depends();
+
+ count = len / sizeof desc;
+ /* Buffers are chained via a 16 bit next field, so
+* we can have at most 2^16 of these. */
+ if (unlikely(count > USHRT_MAX + 1)) {
+ vq_err(vq, "Indirect buffer length too big: %d\n",
+ indirect->len);
+ return -E2BIG;
+ }
+ if (unlikely(vq->ndescs + count > vq->max_descs)) {
+ vq_err(vq, "Too many indirect + direct descs: %d + %d\n",
+ vq->ndescs, indirect->len);
+ return -E2BIG;
+ }
+
+ do {
+ if (unlikely(++found > count)) {
+ vq_err(vq, "Loop detected: last one at %u "
+ "indirect size %u\n",
+ i, count);
+ return -EINVAL;
+ }
+ if (unlikely(!copy_from_iter_full(, sizeof(desc), )))
{
+ vq_err(vq, "Failed indirect descriptor: idx %d, %zx\n",
+ i, (size_t)indirect->addr + i * sizeof desc);
+ return -EINVAL;
+ }
+ if (unlikely(desc.flags & cpu_to_vhost16(vq,
VRING_DESC_F_INDIRECT))) {
+ vq_err(vq, "Nested indirect descriptor: idx %d, %zx\n",
+ i, (size_t)indirect->addr + i * sizeof desc);
+ return -EINVAL;
+ }
+
+ push_split_desc(vq, , head);
The error is ignored.
See above:
if (unlikely(vq->ndescs + count > vq->max_descs))
So it can't fail here, we never fetch unless there's space.
I guess we can add a WARN_ON here.
Yes.
+ } while ((i = next_desc(vq, )) != -1);
+ return 0;
+}
+
+static int fetch_descs(struct vhost_virtqueue *vq)
+{
+ unsigned int i, head, found = 0;
+ struct vhost_desc *last;
+ struct vring_desc desc;
+ __virtio16 avail_idx;
+ __virtio16 ring_head;
+ u16 last_avail_idx;
+ int ret;
+
+ /* Check it isn't doing very strange things with descriptor numbers. */
+ last_avail_idx = vq->last_avail_idx;
+
+ if (vq->avail_idx == vq->last_avail_idx) {
+ if (unlikely(vhost_get_avail_idx(vq, _idx))) {
+ vq_err(vq, "Failed to access avail idx at %p\n",
+ >avail->idx);
+ return -EFAULT;
+ }
+ vq->avail_idx = vhost16_to_cpu(vq, avail_idx);
+
+ if (unlikely((u16)(vq->avail_idx - last_avail_idx) > vq->num)) {
+ vq_err(vq, "Guest moved used index from %u to %u",
+ last_avail_idx, vq->avail_idx);
+ return -EFAULT;
+ }
+
+ /* If there's nothing new since last we looked, return
+* invalid.
+*/
+ if (vq->avail_idx == last_avail_idx)
+ return vq->num;
+
+ /* Only get avail ring entries after they have been
+* exposed by guest.
+*/
+ smp_rmb();
+ }
+
+ /* Grab the next descriptor number they're advertising */
+ if (unlikely(vhost_get_avail_head(vq, _head, last_avail_idx))) {
+ vq_err(vq, "Failed to read head: idx %d address %p\n",
+ last_avail_idx,
+ >avail->ring[last_avail_idx % vq->num]);
+ return -EFAULT;
+ }
+
+ head = vhost16_to_cpu(vq, ring_head);
+
+ /* If their number is silly, that's an error.
Re: [PATCH 1/4] sched/pelt: Remove redundant cap_scale() definition
On Wed, 3 Jun 2020 at 10:03, Dietmar Eggemann wrote: > > Besides in PELT cap_scale() is used in the Deadline scheduler class for > scale-invariant bandwidth enforcement. > Remove the cap_scale() definition in kernel/sched/pelt.c and keep the > one in kernel/sched/sched.h. > > Signed-off-by: Dietmar Eggemann Reviewed-by: Vincent Guittot > --- > kernel/sched/pelt.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/kernel/sched/pelt.c b/kernel/sched/pelt.c > index b4b1ff96642f..dea5567e4f72 100644 > --- a/kernel/sched/pelt.c > +++ b/kernel/sched/pelt.c > @@ -83,8 +83,6 @@ static u32 __accumulate_pelt_segments(u64 periods, u32 d1, > u32 d3) > return c1 + c2 + c3; > } > > -#define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT) > - > /* > * Accumulate the three separate parts of the sum; d1 the remainder > * of the last (incomplete) period, d2 the span of full periods and d3 > -- > 2.17.1 >
Re: [PATCH] sched/debug: Add new tracepoints to track util_est
On 27/05/20 17:39, vincent.donnef...@arm.com wrote: > From: Vincent Donnefort > > The util_est signals are key elements for EAS task placement and > frequency selection. Having tracepoints to track these signals enables > load-tracking and schedutil testing and/or debugging by a toolkit. > > Signed-off-by: Vincent Donnefort > To put it more bluntly, we can't really do task placement / load tracking testing if util_est is enabled (which reminds me we may want to get rid of the SCHED_FEAT at some point, it's been default on since ~v4.17), since there can be noticeable gaps between util_avg and util_est. Reviewed-by: Valentin Schneider
Linux 5.4.44
I'm announcing the release of the 5.4.44 kernel. All users of the 5.4 kernel series must upgrade. The updated 5.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.4.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm/boot/compressed/vmlinux.lds.S |2 arch/arm/boot/dts/bcm-hr2.dtsi |6 arch/arm/boot/dts/bcm2835-rpi-zero-w.dts|2 arch/arm/boot/dts/imx6q-b450v3.dts |7 arch/arm/boot/dts/imx6q-b650v3.dts |7 arch/arm/boot/dts/imx6q-b850v3.dts | 11 - arch/arm/boot/dts/imx6q-bx50v3.dtsi | 15 ++ arch/arm/boot/dts/rk3036.dtsi |2 arch/arm/boot/dts/rk3228-evb.dts|2 arch/arm/boot/dts/rk3229-xms6.dts |2 arch/arm/boot/dts/rk322x.dtsi |6 arch/arm/boot/dts/rk3xxx.dtsi |2 arch/arm/include/asm/assembler.h| 75 -- arch/arm/include/asm/uaccess-asm.h | 117 arch/arm/kernel/entry-armv.S| 11 - arch/arm/kernel/entry-header.S |9 - arch/arm64/boot/dts/mediatek/mt8173.dtsi|4 arch/arm64/boot/dts/rockchip/rk3328-evb.dts |2 arch/arm64/boot/dts/rockchip/rk3399.dtsi|8 - arch/csky/abiv1/inc/abi/entry.h |4 arch/csky/abiv2/inc/abi/entry.h |4 arch/csky/include/asm/uaccess.h | 49 +++--- arch/csky/kernel/entry.S|2 arch/csky/kernel/perf_callchain.c |9 - arch/csky/lib/usercopy.c|8 - arch/parisc/mm/init.c |2 arch/riscv/kernel/stacktrace.c |2 arch/x86/include/asm/dma.h |2 arch/x86/include/uapi/asm/unistd.h | 11 + arch/x86/kernel/fpu/xstate.c| 86 ++- block/blk-core.c| 11 - drivers/clk/qcom/gcc-sm8150.c |3 drivers/clk/ti/clk-33xx.c |2 drivers/crypto/chelsio/chtls/chtls_io.c |2 drivers/gpio/gpio-bcm-kona.c|2 drivers/gpio/gpio-exar.c|7 drivers/gpio/gpio-pxa.c |4 drivers/gpio/gpio-tegra.c |1 drivers/gpio/gpiolib.c | 11 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c|5 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |6 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 12 - drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |7 drivers/gpu/drm/amd/powerplay/amd_powerplay.c |6 drivers/gpu/drm/amd/powerplay/amdgpu_smu.c |6 drivers/gpu/drm/ingenic/ingenic-drm.c |2 drivers/hwmon/nct7904.c |4 drivers/infiniband/core/rdma_core.c | 20 +- drivers/infiniband/hw/i40iw/i40iw_cm.c |8 - drivers/infiniband/hw/qib/qib_sysfs.c |9 - drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c |2 drivers/infiniband/ulp/ipoib/ipoib.h|4 drivers/infiniband/ulp/ipoib/ipoib_cm.c | 15 +- drivers/infiniband/ulp/ipoib/ipoib_ib.c |9 - drivers/infiniband/ulp/ipoib/ipoib_main.c | 10 - drivers/input/evdev.c | 19 -- drivers/input/joystick/xpad.c | 12 + drivers/input/keyboard/dlink-dir685-touchkeys.c |2 drivers/input/rmi4/rmi_driver.c |5 drivers/input/serio/i8042-x86ia64io.h |7 drivers/input/touchscreen/usbtouchscreen.c |1 drivers/iommu/iommu.c |2 drivers/mmc/core/block.c|2 drivers/net/bonding/bond_sysfs_slave.c |4 drivers/net/dsa/mt7530.c|9 - drivers/net/dsa/mt7530.h|1 drivers/net/ethernet/broadcom/bnxt/bnxt.c |2 drivers/net/ethernet/freescale/Kconfig |2
Linux 5.6.16
I'm announcing the release of the 5.6.16 kernel. All users of the 5.6 kernel series must upgrade. The updated 5.6.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.6.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm/boot/compressed/vmlinux.lds.S |2 arch/arm/boot/dts/bcm-hr2.dtsi |6 arch/arm/boot/dts/bcm2835-rpi-zero-w.dts|2 arch/arm/boot/dts/imx6q-b450v3.dts |7 arch/arm/boot/dts/imx6q-b650v3.dts |7 arch/arm/boot/dts/imx6q-b850v3.dts | 11 arch/arm/boot/dts/imx6q-bx50v3.dtsi | 15 + arch/arm/boot/dts/mmp3-dell-ariel.dts | 12 arch/arm/boot/dts/mmp3.dtsi |8 arch/arm/boot/dts/motorola-mapphone-common.dtsi | 43 +++ arch/arm/boot/dts/rk3036.dtsi |2 arch/arm/boot/dts/rk3228-evb.dts|2 arch/arm/boot/dts/rk3229-xms6.dts |2 arch/arm/boot/dts/rk322x.dtsi |6 arch/arm/boot/dts/rk3xxx.dtsi |2 arch/arm/include/asm/assembler.h| 75 -- arch/arm/include/asm/uaccess-asm.h | 117 + arch/arm/kernel/entry-armv.S| 11 arch/arm/kernel/entry-header.S |9 arch/arm64/boot/dts/mediatek/mt8173.dtsi|4 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi| 19 + arch/arm64/boot/dts/qcom/msm8996.dtsi |2 arch/arm64/boot/dts/rockchip/rk3328-evb.dts |2 arch/arm64/boot/dts/rockchip/rk3399.dtsi|8 arch/csky/abiv1/inc/abi/entry.h |4 arch/csky/abiv2/inc/abi/entry.h |4 arch/csky/include/asm/uaccess.h | 49 ++- arch/csky/kernel/entry.S|2 arch/csky/kernel/perf_callchain.c |9 arch/csky/lib/usercopy.c|8 arch/parisc/mm/init.c |2 arch/powerpc/Kconfig|1 arch/riscv/Kconfig.socs | 17 - arch/riscv/include/asm/mmio.h |2 arch/riscv/include/asm/pgtable.h|3 arch/riscv/kernel/stacktrace.c |2 arch/x86/include/asm/dma.h |2 arch/x86/include/asm/io_bitmap.h|4 arch/x86/kernel/fpu/xstate.c| 86 +++--- arch/x86/kernel/ioport.c| 22 - arch/x86/kernel/process.c |4 block/blk-core.c| 11 drivers/clk/qcom/gcc-sm8150.c |3 drivers/clk/ti/clk-33xx.c |2 drivers/crypto/chelsio/chtls/chtls_io.c |2 drivers/gpio/gpio-bcm-kona.c|2 drivers/gpio/gpio-exar.c|7 drivers/gpio/gpio-mvebu.c | 15 - drivers/gpio/gpio-pxa.c |4 drivers/gpio/gpio-tegra.c |1 drivers/gpio/gpiolib.c | 11 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c|5 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |6 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 12 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |7 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 10 drivers/gpu/drm/amd/display/dc/core/dc.c| 124 +++--- drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 40 --- drivers/gpu/drm/amd/display/dc/dc_stream.h |1 drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 30 -- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 148 +--- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.h | 13 + drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c |4 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c| 15 +
Re: Linux 4.14.183
diff --git a/Makefile b/Makefile
index 591582e26a57..aa9d8c79bff0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 182
+SUBLEVEL = 183
EXTRAVERSION =
NAME = Petit Gorille
diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
index e5f2cca86f04..120776d45441 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
@@ -25,7 +25,7 @@
leds {
act {
- gpios = < 47 GPIO_ACTIVE_HIGH>;
+ gpios = < 47 GPIO_ACTIVE_LOW>;
};
};
diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts
b/arch/arm/boot/dts/imx6q-b450v3.dts
index 404a93d9596b..dc7d65da7d01 100644
--- a/arch/arm/boot/dts/imx6q-b450v3.dts
+++ b/arch/arm/boot/dts/imx6q-b450v3.dts
@@ -65,13 +65,6 @@
};
};
- {
- assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
- < IMX6QDL_CLK_LDB_DI1_SEL>;
- assigned-clock-parents = < IMX6QDL_CLK_PLL3_USB_OTG>,
-< IMX6QDL_CLK_PLL3_USB_OTG>;
-};
-
{
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts
b/arch/arm/boot/dts/imx6q-b650v3.dts
index 7f9f176901d4..101d61f93070 100644
--- a/arch/arm/boot/dts/imx6q-b650v3.dts
+++ b/arch/arm/boot/dts/imx6q-b650v3.dts
@@ -65,13 +65,6 @@
};
};
- {
- assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
- < IMX6QDL_CLK_LDB_DI1_SEL>;
- assigned-clock-parents = < IMX6QDL_CLK_PLL3_USB_OTG>,
-< IMX6QDL_CLK_PLL3_USB_OTG>;
-};
-
{
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts
b/arch/arm/boot/dts/imx6q-b850v3.dts
index 46bdc6722715..8fc831dc3156 100644
--- a/arch/arm/boot/dts/imx6q-b850v3.dts
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -53,17 +53,6 @@
};
};
- {
- assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
- < IMX6QDL_CLK_LDB_DI1_SEL>,
- < IMX6QDL_CLK_IPU1_DI0_PRE_SEL>,
- < IMX6QDL_CLK_IPU2_DI0_PRE_SEL>;
- assigned-clock-parents = < IMX6QDL_CLK_PLL5_VIDEO_DIV>,
-< IMX6QDL_CLK_PLL5_VIDEO_DIV>,
-< IMX6QDL_CLK_PLL2_PFD2_396M>,
-< IMX6QDL_CLK_PLL2_PFD2_396M>;
-};
-
{
fsl,dual-channel;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
index 1015e55ca8f7..f3c2c5587616 100644
--- a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -92,6 +92,56 @@
mux-int-port = <1>;
mux-ext-port = <4>;
};
+
+ aliases {
+ mdio-gpio0 =
+ };
+
+ mdio0: mdio-gpio {
+ compatible = "virtual,mdio-gpio";
+ gpios = < 5 GPIO_ACTIVE_HIGH>, /* mdc */
+ < 7 GPIO_ACTIVE_HIGH>; /* mdio */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@0 {
+ compatible = "marvell,mv88e6085"; /* 88e6240*/
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ switch_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switchphy0: switchphy@0 {
+ reg = <0>;
+ };
+
+ switchphy1: switchphy@1 {
+ reg = <1>;
+ };
+
+ switchphy2: switchphy@2 {
+ reg = <2>;
+ };
+
+ switchphy3: switchphy@3 {
+ reg = <3>;
+ };
+
+ switchphy4: switchphy@4 {
+ reg = <4>;
+ };
+ };
+ };
+ };
};
{
@@ -326,3 +376,30 @@
tcxo-clock-frequency = <2600>;
};
};
+
+ {
+ /* Synopsys, Inc. Device */
+ pci_root: root@0,0 {
+ compatible = "pci16c3,abcd";
+ reg = <0x 0 0 0 0>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ };
+};
+
+ {
+ assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
+ < IMX6QDL_CLK_LDB_DI1_SEL>,
+
Re: [PATCH] tcp: fix TCP socks unreleased in BBR mode
On Wed, Jun 3, 2020 at 1:44 AM Eric Dumazet wrote: > > On Tue, Jun 2, 2020 at 10:05 PM Jason Xing wrote: > > > > Hi Eric, > > > > I'm still trying to understand what you're saying before. Would this > > be better as following: > > 1) discard the tcp_internal_pacing() function. > > 2) remove where the tcp_internal_pacing() is called in the > > __tcp_transmit_skb() function. > > > > If we do so, we could avoid 'too late to give up pacing'. Meanwhile, > > should we introduce the tcp_wstamp_ns socket field as commit > > (864e5c090749) does? > > > > Please do not top-post on netdev mailing list. > > > I basically suggested double-checking which point in TCP could end up > calling tcp_internal_pacing() > while the timer was already armed. > > I guess this is mtu probing. Perhaps this could also happen from some of the retransmission code paths that don't use tcp_xmit_retransmit_queue()? Perhaps tcp_retransmit_timer() (RTO) and tcp_send_loss_probe() TLP? It seems they could indirectly cause a call to __tcp_transmit_skb() and thus tcp_internal_pacing() without first checking if the pacing timer was already armed? neal
Re: Linux 4.19.126
diff --git a/Makefile b/Makefile
index 93c63bda7115..f8da10c40271 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 19
-SUBLEVEL = 125
+SUBLEVEL = 126
EXTRAVERSION =
NAME = "People's Front"
diff --git a/arch/arm/boot/compressed/vmlinux.lds.S
b/arch/arm/boot/compressed/vmlinux.lds.S
index 2b963d8e76dd..89a8f7588c78 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -46,7 +46,7 @@ SECTIONS
}
.table : ALIGN(4) {
_table_start = .;
-LONG(ZIMAGE_MAGIC(2))
+LONG(ZIMAGE_MAGIC(4))
LONG(ZIMAGE_MAGIC(0x5a534c4b))
LONG(ZIMAGE_MAGIC(__piggy_size_addr - _start))
LONG(ZIMAGE_MAGIC(_kernel_bss_size))
diff --git a/arch/arm/boot/dts/bcm-hr2.dtsi b/arch/arm/boot/dts/bcm-hr2.dtsi
index e4d49731287f..e35398cc60a0 100644
--- a/arch/arm/boot/dts/bcm-hr2.dtsi
+++ b/arch/arm/boot/dts/bcm-hr2.dtsi
@@ -75,7 +75,7 @@
timer@20200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x20200 0x100>;
- interrupts = ;
+ interrupts = ;
clocks = <_clk>;
};
@@ -83,7 +83,7 @@
compatible = "arm,cortex-a9-twd-timer";
reg = <0x20600 0x20>;
interrupts = ;
+ IRQ_TYPE_EDGE_RISING)>;
clocks = <_clk>;
};
@@ -91,7 +91,7 @@
compatible = "arm,cortex-a9-twd-wdt";
reg = <0x20620 0x20>;
interrupts = ;
+ IRQ_TYPE_EDGE_RISING)>;
clocks = <_clk>;
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
index 5fcadb9cf992..9f7145b1cc5e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
@@ -25,7 +25,7 @@
leds {
act {
- gpios = < 47 GPIO_ACTIVE_HIGH>;
+ gpios = < 47 GPIO_ACTIVE_LOW>;
};
};
diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts
b/arch/arm/boot/dts/imx6q-b450v3.dts
index 3ec58500e9c2..25bf45659737 100644
--- a/arch/arm/boot/dts/imx6q-b450v3.dts
+++ b/arch/arm/boot/dts/imx6q-b450v3.dts
@@ -65,13 +65,6 @@
};
};
- {
- assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
- < IMX6QDL_CLK_LDB_DI1_SEL>;
- assigned-clock-parents = < IMX6QDL_CLK_PLL3_USB_OTG>,
-< IMX6QDL_CLK_PLL3_USB_OTG>;
-};
-
{
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts
b/arch/arm/boot/dts/imx6q-b650v3.dts
index 5650a9b11091..0326711a8700 100644
--- a/arch/arm/boot/dts/imx6q-b650v3.dts
+++ b/arch/arm/boot/dts/imx6q-b650v3.dts
@@ -65,13 +65,6 @@
};
};
- {
- assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
- < IMX6QDL_CLK_LDB_DI1_SEL>;
- assigned-clock-parents = < IMX6QDL_CLK_PLL3_USB_OTG>,
-< IMX6QDL_CLK_PLL3_USB_OTG>;
-};
-
{
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts
b/arch/arm/boot/dts/imx6q-b850v3.dts
index 044a5bebe1c5..612f782ddaaa 100644
--- a/arch/arm/boot/dts/imx6q-b850v3.dts
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -53,17 +53,6 @@
};
};
- {
- assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
- < IMX6QDL_CLK_LDB_DI1_SEL>,
- < IMX6QDL_CLK_IPU1_DI0_PRE_SEL>,
- < IMX6QDL_CLK_IPU2_DI0_PRE_SEL>;
- assigned-clock-parents = < IMX6QDL_CLK_PLL5_VIDEO_DIV>,
-< IMX6QDL_CLK_PLL5_VIDEO_DIV>,
-< IMX6QDL_CLK_PLL2_PFD2_396M>,
-< IMX6QDL_CLK_PLL2_PFD2_396M>;
-};
-
{
fsl,dual-channel;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
index d3cba09be0cb..c1f554348187 100644
--- a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -391,3 +391,18 @@
#interrupt-cells = <1>;
};
};
+
+ {
+ assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
+ < IMX6QDL_CLK_LDB_DI1_SEL>,
+ < IMX6QDL_CLK_IPU1_DI0_PRE_SEL>,
+ < IMX6QDL_CLK_IPU1_DI1_PRE_SEL>,
+ < IMX6QDL_CLK_IPU2_DI0_PRE_SEL>,
+ < IMX6QDL_CLK_IPU2_DI1_PRE_SEL>;
+ assigned-clock-parents = < IMX6QDL_CLK_PLL5_VIDEO_DIV>,
+< IMX6QDL_CLK_PLL5_VIDEO_DIV>,
+< IMX6QDL_CLK_PLL2_PFD0_352M>,
+< IMX6QDL_CLK_PLL2_PFD0_352M>,
+
Linux 4.14.183
I'm announcing the release of the 4.14.183 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm/boot/dts/bcm2835-rpi-zero-w.dts|2 arch/arm/boot/dts/imx6q-b450v3.dts |7 - arch/arm/boot/dts/imx6q-b650v3.dts |7 - arch/arm/boot/dts/imx6q-b850v3.dts | 11 - arch/arm/boot/dts/imx6q-bx50v3.dtsi | 77 + arch/arm/boot/dts/rk3228-evb.dts|2 arch/arm/boot/dts/rk322x.dtsi |4 arch/arm/include/asm/assembler.h| 83 -- arch/arm/include/asm/uaccess-asm.h | 117 arch/arm/include/asm/vfpmacros.h|8 - arch/arm/kernel/entry-armv.S| 11 - arch/arm/kernel/entry-header.S |9 - arch/arm/lib/bitops.h |8 - arch/arm64/boot/dts/rockchip/rk3399.dtsi|8 - arch/parisc/mm/init.c |2 arch/x86/include/asm/dma.h |2 arch/x86/kernel/fpu/xstate.c| 86 -- arch/x86/kvm/vmx.c |7 - drivers/gpio/gpio-exar.c|7 - drivers/gpio/gpio-tegra.c |1 drivers/infiniband/hw/qib/qib_sysfs.c |9 - drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c |2 drivers/input/evdev.c | 19 --- drivers/input/joystick/xpad.c | 12 ++ drivers/input/keyboard/dlink-dir685-touchkeys.c |2 drivers/input/rmi4/rmi_driver.c |5 drivers/input/serio/i8042-x86ia64io.h |7 + drivers/input/touchscreen/usbtouchscreen.c |1 drivers/iommu/iommu.c |2 drivers/mmc/core/block.c|2 drivers/net/bonding/bond_sysfs_slave.c |4 drivers/net/ethernet/freescale/Kconfig |2 drivers/net/ethernet/freescale/dpaa/Kconfig |1 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c |5 drivers/net/ethernet/mellanox/mlx4/fw.c |2 drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 14 ++ drivers/net/ethernet/mellanox/mlx5/core/en_tx.c |6 - drivers/net/ethernet/microchip/encx24j600.c |5 drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c |4 drivers/net/ethernet/sun/cassini.c |3 drivers/net/usb/cdc_ether.c | 11 + drivers/net/usb/r8152.c |1 drivers/s390/scsi/zfcp_fsf.c| 10 + drivers/tty/serial/sc16is7xx.c |2 drivers/usb/gadget/legacy/inode.c |3 fs/binfmt_elf.c |2 fs/cachefiles/rdwr.c|2 fs/cifs/file.c |2 fs/gfs2/quota.c |3 fs/gfs2/quota.h |3 include/asm-generic/topology.h |2 include/linux/mlx5/driver.h |1 include/linux/mm.h | 15 ++ include/linux/netfilter/nf_conntrack_pptp.h |2 include/net/act_api.h |3 include/uapi/linux/xfrm.h |2 kernel/irq/migration.c | 26 +++- mm/vmalloc.c|2 net/ax25/af_ax25.c |6 - net/bridge/netfilter/nft_reject_bridge.c|6 + net/ceph/osd_client.c |4 net/ipv4/ip_vti.c | 75 ++-- net/ipv4/ipip.c |2 net/ipv4/netfilter/nf_nat_pptp.c|7 - net/ipv4/route.c| 14 +- net/ipv6/esp6_offload.c |9 + net/mac80211/mesh_hwmp.c|7 + net/netfilter/ipset/ip_set_list_set.c |2 net/netfilter/nf_conntrack_pptp.c | 62 +- net/netfilter/nfnetlink_cthelper.c |3 net/qrtr/qrtr.c |2 net/rxrpc/local_object.c| 23 ++-
[RELEASE] LTTng-modules 2.12.1 and 2.11.4 (Linux kernel tracer)
Hi,
This is a release announcement of the LTTng kernel tracer for both
maintained LTTng stable branches. The main change integrated within
the new versions 2.12.1 and 2.11.4 is support for the newly released
5.7 Linux kernel.
If you followed the news lately [1], you will notice that LTTng had to
work-around a change which un-exports kallsyms symbols, making those
inaccessible to GPL modules, which was integrated within Linux 5.7. As a
matter of fact, LTTng happens to use kallsyms in some cases to access
symbols otherwise not visible to GPL kernel modules.
Just to underline the amount of effort that was put into trying to do
the right thing, here is an explanation of the alternative approaches
that were attempted before going for a work-around using kprobes
(taken from commit message of lttng-modules
commit a65765406b0 "Unbreak LTTng for kernel 5.7"):
Linux commit 0bd476e6c67190b5eb7b6e105c8db8ff61103281 ("kallsyms:
unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()") breaks
LTTng-modules by removing symbols used by the LTTng-modules out-of-tree
tracer.
I pointed this out when the change was originally considered before the
5.7 merge window. This generated some discussion but it did not lead to
any concrete proposal to fix the issue. [2]
The commit has been merged in the 5.7 merge window. At that point, as
maintainer of LTTng, I immediately raised a flag about this issue,
proposing an alternative approach to solve this: expose the few symbols
needed by LTTng to GPL modules. This was NACKed on the ground that the
Linux kernel cannot export GPL symbols when there are no in-tree
users. [3]
Steven Rostedt has shown interest in merging LTTng-modules upstream.
LTTng-modules being LGPL, this is very much doable. I have prepared a
tree of LTTng-modules "for upstreaming" and sent it to him privately so
he can review it. Even if in an ideal scenario LTTng-modules is merged
for the following merge window, it leaves LTTng-modules broken on the
5.7 kernel.
In order to ensure that the LTTng-modules kernel tracer continues working
for my end users on kernels 5.7 onwards, as a very last resort, this is
with great reluctance that I created this fix for LTTng modules. It
basically uses kprobes to lookup the kallsyms_lookup_name symbol, and
continues using kallsyms_lookup_name as before.
Steven Rostedt has started looking into lttng-modules, but currently lacks time
to look into it further. Understandably, this 15 years old project is larger
than
he initially expected. Let's hope we receive concrete feedback on how we can
improve LTTng to make it acceptable for integration into Linux.
Thanks,
Mathieu
[1] https://lwn.net/Articles/817988/
[2] https://lore.kernel.org/r/20200302192811.n6o5645rsib44vco@localhost
[3]
https://lore.kernel.org/r/20200409193543.18115-1-mathieu.desnoy...@efficios.com
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Linux 4.19.126
I'm announcing the release of the 4.19.126 kernel. All users of the 4.19 kernel series must upgrade. The updated 4.19.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm/boot/compressed/vmlinux.lds.S |2 arch/arm/boot/dts/bcm-hr2.dtsi |6 - arch/arm/boot/dts/bcm2835-rpi-zero-w.dts|2 arch/arm/boot/dts/imx6q-b450v3.dts |7 - arch/arm/boot/dts/imx6q-b650v3.dts |7 - arch/arm/boot/dts/imx6q-b850v3.dts | 11 - arch/arm/boot/dts/imx6q-bx50v3.dtsi | 15 ++ arch/arm/boot/dts/rk3036.dtsi |2 arch/arm/boot/dts/rk3228-evb.dts|2 arch/arm/boot/dts/rk322x.dtsi |6 - arch/arm/boot/dts/rk3xxx.dtsi |2 arch/arm/include/asm/assembler.h| 83 -- arch/arm/include/asm/uaccess-asm.h | 117 arch/arm/include/asm/vfpmacros.h|8 - arch/arm/kernel/entry-armv.S| 11 - arch/arm/kernel/entry-header.S |9 - arch/arm/lib/bitops.h |8 - arch/arm64/boot/dts/rockchip/rk3328-evb.dts |2 arch/arm64/boot/dts/rockchip/rk3399.dtsi|8 - arch/parisc/mm/init.c |2 arch/riscv/kernel/stacktrace.c |2 arch/x86/include/asm/dma.h |2 arch/x86/kernel/fpu/xstate.c| 86 -- drivers/crypto/chelsio/chtls/chtls_io.c |2 drivers/gpio/gpio-exar.c|7 - drivers/gpio/gpio-tegra.c |1 drivers/infiniband/core/rdma_core.c | 19 ++- drivers/infiniband/hw/i40iw/i40iw_cm.c |8 - drivers/infiniband/hw/qib/qib_sysfs.c |9 - drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c |2 drivers/infiniband/ulp/ipoib/ipoib.h|4 drivers/infiniband/ulp/ipoib/ipoib_cm.c | 15 +- drivers/infiniband/ulp/ipoib/ipoib_ib.c |9 + drivers/infiniband/ulp/ipoib/ipoib_main.c | 10 + drivers/input/evdev.c | 19 --- drivers/input/joystick/xpad.c | 12 ++ drivers/input/keyboard/dlink-dir685-touchkeys.c |2 drivers/input/rmi4/rmi_driver.c |5 drivers/input/serio/i8042-x86ia64io.h |7 + drivers/input/touchscreen/usbtouchscreen.c |1 drivers/iommu/iommu.c |2 drivers/mmc/core/block.c|2 drivers/mmc/core/queue.c| 13 -- drivers/net/bonding/bond_sysfs_slave.c |4 drivers/net/dsa/mt7530.c|9 - drivers/net/dsa/mt7530.h|1 drivers/net/ethernet/broadcom/bnxt/bnxt.c |2 drivers/net/ethernet/freescale/Kconfig |2 drivers/net/ethernet/freescale/dpaa/Kconfig |1 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c |2 drivers/net/ethernet/mellanox/mlx4/fw.c |2 drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 14 ++ drivers/net/ethernet/mellanox/mlx5/core/en_tx.c |6 - drivers/net/ethernet/mellanox/mlx5/core/fs_core.c |6 + drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 14 ++ drivers/net/ethernet/mellanox/mlxsw/switchx2.c |8 + drivers/net/ethernet/microchip/encx24j600.c |5 drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c |4 drivers/net/ethernet/sun/cassini.c |3 drivers/net/usb/cdc_ether.c | 11 + drivers/net/usb/r8152.c |1 drivers/usb/dwc3/dwc3-pci.c |1 drivers/usb/gadget/legacy/inode.c |3 fs/binfmt_elf.c |2 fs/cachefiles/rdwr.c|2 fs/cifs/file.c |2 fs/gfs2/quota.c |3 fs/gfs2/quota.h |3 include/asm-generic/topology.h |2 include/linux/mlx5/driver.h |1 include/linux/mm.h | 15 ++ include/linux/netfilter/nf_conntrack_pptp.h |2 include/net/act_api.h
Re: [PATCH v8 04/10] drm: bridge: dw_mipi_dsi: allow bridge daisy chaining
On Wed, 03 Jun 2020, Laurent Pinchart
wrote:
Hi Adrian,
Hi Laurent,
Thank you for the patch.
On Mon, Apr 27, 2020 at 11:19:46AM +0300, Adrian Ratiu wrote:
Up until now the assumption was that the synopsis dsi bridge
will directly connect to an encoder provided by the platform
driver, but the current practice for drivers is to leave the
encoder empty via the simple encoder API and add their logic to
their own drm_bridge. Thus we need an ablility to connect the
DSI bridge to another bridge provided by the platform driver,
so we extend the dw_mipi_dsi bind() API with a new "previous
bridge" arg instead of just hardcoding NULL. Cc: Laurent
Pinchart Signed-off-by:
Adrian Ratiu --- New in v8. ---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 --
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 2 +-
include/drm/bridge/dw_mipi_dsi.h| 5 - 3
files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
16fd87055e7b7..140ff40fa1b62 100644 ---
a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -1456,11
+1456,13 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
/*
* Bind/unbind API, used from platforms based on the component
framework. */
-int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct
drm_encoder *encoder) +int dw_mipi_dsi_bind(struct dw_mipi_dsi
*dsi, + struct drm_encoder *encoder, +
struct drm_bridge *prev_bridge)
{ int ret;
- ret = drm_bridge_attach(encoder, >bridge, NULL, 0); +
ret = drm_bridge_attach(encoder, >bridge, prev_bridge, 0);
Please note that chaining of bridges doesn't work well if
multiple bridges in the chain try to create a connector. This is
why a DRM_BRIDGE_ATTACH_NO_CONNECTOR flag has been added, with a
helper to create a connector for a chain of bridges
(drm_bridge_connector_init()). This won't play well with the
component framework. I would recommend using the
of_drm_find_bridge() instead in the rockchip driver, and
deprecating dw_mipi_dsi_bind().
Thank you for this insight, indeed the bridge dw_mipi_dsi_bind()
is clunky and we're making it even more so by possibly
re-inventing drm_bridge_connector_init() with it in a way which
can't work (well it does work but can lead to those nasty
multiple-encoder corner-cases you mention).
I'll address this before posting v9, to try to move to
of_drm_find_bridge() and remove dw_mipi_dsi_bind().
if (ret) {
DRM_ERROR("Failed to initialize bridge with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 3feff0c45b3f7..83ef43be78135 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -929,7 +929,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
return ret;
}
- ret = dw_mipi_dsi_bind(dsi->dmd, >encoder);
+ ret = dw_mipi_dsi_bind(dsi->dmd, >encoder, NULL);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
return ret;
diff --git a/include/drm/bridge/dw_mipi_dsi.h b/include/drm/bridge/dw_mipi_dsi.h
index b0e390b3288e8..699b3531f5b36 100644
--- a/include/drm/bridge/dw_mipi_dsi.h
+++ b/include/drm/bridge/dw_mipi_dsi.h
@@ -14,6 +14,7 @@
#include
struct drm_display_mode;
+struct drm_bridge;
struct drm_encoder;
struct dw_mipi_dsi;
struct mipi_dsi_device;
@@ -62,7 +63,9 @@ struct dw_mipi_dsi *dw_mipi_dsi_probe(struct platform_device
*pdev,
const struct dw_mipi_dsi_plat_data
*plat_data);
void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi);
-int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct drm_encoder *encoder);
+int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi,
+struct drm_encoder *encoder,
+struct drm_bridge *prev_bridge);
void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi);
void dw_mipi_dsi_set_slave(struct dw_mipi_dsi *dsi, struct dw_mipi_dsi *slave);
--
Regards,
Laurent Pinchart
Linux 4.4.226
I'm announcing the release of the 4.4.226 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/parisc/mm/init.c |2 arch/x86/include/asm/dma.h |2 drivers/gpu/drm/drm_fb_helper.c |2 drivers/gpu/drm/msm/msm_gem.c | 20 ++--- drivers/infiniband/hw/qib/qib_sysfs.c |9 +- drivers/input/evdev.c | 19 + drivers/input/joystick/xpad.c | 12 +++ drivers/input/serio/i8042-x86ia64io.h |7 + drivers/input/touchscreen/usbtouchscreen.c |1 drivers/iommu/iommu.c |2 drivers/net/bonding/bond_sysfs_slave.c |4 - drivers/net/ethernet/mellanox/mlx4/fw.c |2 drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 15 drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c |4 - drivers/net/ethernet/sun/cassini.c |3 drivers/s390/scsi/zfcp_fsf.c| 10 ++ drivers/tty/serial/sc16is7xx.c |2 drivers/usb/gadget/legacy/inode.c |3 drivers/usb/renesas_usbhs/mod_gadget.c |2 fs/binfmt_elf.c |2 fs/cachefiles/rdwr.c|2 fs/cifs/file.c |2 include/asm-generic/asm-prototypes.h|6 + include/asm-generic/topology.h |2 include/linux/mlx5/driver.h |1 include/linux/mm.h |1 include/linux/netfilter/nf_conntrack_pptp.h |2 include/linux/printk.h | 12 +-- include/rdma/ib_addr.h |6 + include/uapi/linux/l2tp.h |7 - kernel/irq/migration.c | 26 +- mm/vmalloc.c|2 net/ax25/af_ax25.c |6 + net/bridge/netfilter/nft_reject_bridge.c|6 + net/core/rtnetlink.c|2 net/ipv4/ip_vti.c | 75 ++-- net/ipv4/netfilter/nf_nat_pptp.c|7 - net/ipv4/route.c| 14 +-- net/mac80211/sta_info.c |1 net/netfilter/ipset/ip_set_list_set.c |2 net/netfilter/nf_conntrack_pptp.c | 62 +--- net/sctp/sm_statefuns.c |9 +- net/xfrm/xfrm_input.c |2 net/xfrm/xfrm_output.c |3 net/xfrm/xfrm_policy.c |7 - security/commoncap.c|1 sound/core/hwdep.c |4 - sound/usb/mixer.c |8 ++ 49 files changed, 241 insertions(+), 162 deletions(-) Aaron Conole (1): printk: help pr_debug and pr_devel to optimize out arguments Alexander Dahl (1): x86/dma: Fix max PFN arithmetic overflow on 32 bit systems Alexander Potapenko (1): fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() Arnd Bergmann (1): include/asm-generic/topology.h: guard cpumask_of_node() macro argument Ben Hutchings (1): drm/msm: Fix possible null dereference on failure of get_pages() Benjamin Block (1): scsi: zfcp: fix request object use-after-free in send path causing wrong traces Brendan Shanks (1): Input: evdev - call input_flush_device() on release(), not flush() Changming Liu (1): ALSA: hwdep: fix a left shifting 1 by 31 UB bug Chris Chiu (1): ALSA: usb-audio: mixer: volume quirk for ESS Technology Asus USB DAC Dmitry V. Levin (1): uapi: fix linux/if_pppol2tp.h userspace compilation errors Eric Dumazet (1): ax25: fix setsockopt(SO_BINDTODEVICE) Eric W. Biederman (1): exec: Always set cap_ambient in cap_bprm_set_creds Greg Kroah-Hartman (1): Linux 4.4.226 Guoqing Jiang (1): sc16is7xx: move label 'err_spi' to correct section Helge Deller (1): parisc: Fix kernel panic in mem_init() James Hilliard (1): Input: usbtouchscreen - add support for BonXeon TP Jere Leppänen (1): sctp: Start shutdown on association restart if in SHUTDOWN-SENT state and socket is closed Jeremy
Linux 4.9.226
I'm announcing the release of the 4.9.226 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|2 arch/arm/boot/dts/imx6q-b450v3.dts |7 - arch/arm/boot/dts/imx6q-b650v3.dts |7 - arch/arm/boot/dts/imx6q-b850v3.dts | 11 -- arch/arm/boot/dts/imx6q-bx50v3.dtsi | 77 arch/parisc/mm/init.c |2 arch/x86/include/asm/dma.h |2 drivers/gpio/gpio-tegra.c |1 drivers/infiniband/hw/qib/qib_sysfs.c |9 +- drivers/input/evdev.c | 19 +--- drivers/input/joystick/xpad.c | 12 +++ drivers/input/rmi4/rmi_driver.c |3 drivers/input/serio/i8042-x86ia64io.h |7 + drivers/input/touchscreen/usbtouchscreen.c |1 drivers/iommu/iommu.c |2 drivers/net/bonding/bond_sysfs_slave.c |4 - drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c |3 drivers/net/ethernet/mellanox/mlx4/fw.c |2 drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 15 +++ drivers/net/ethernet/mellanox/mlx5/core/en_tx.c |6 + drivers/net/ethernet/microchip/encx24j600.c |5 + drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c |4 - drivers/net/ethernet/sun/cassini.c |3 drivers/s390/scsi/zfcp_fsf.c| 10 ++ drivers/tty/serial/sc16is7xx.c |2 drivers/usb/gadget/legacy/inode.c |3 fs/binfmt_elf.c |2 fs/cachefiles/rdwr.c|2 fs/cifs/file.c |2 fs/gfs2/quota.c |3 fs/gfs2/quota.h |3 include/asm-generic/topology.h |2 include/linux/mlx5/driver.h |1 include/linux/mm.h | 15 +++ include/linux/netfilter/nf_conntrack_pptp.h |2 include/net/act_api.h |3 include/rdma/ib_addr.h |6 + include/uapi/linux/l2tp.h |7 - kernel/irq/migration.c | 26 -- mm/vmalloc.c|2 net/ax25/af_ax25.c |6 + net/bridge/netfilter/nft_reject_bridge.c|6 + net/ceph/osd_client.c |4 - net/core/rtnetlink.c|2 net/ipv4/ip_vti.c | 75 ++- net/ipv4/ipip.c |2 net/ipv4/netfilter/nf_nat_pptp.c|7 - net/ipv4/route.c| 14 +-- net/mac80211/mesh_hwmp.c|7 + net/netfilter/ipset/ip_set_list_set.c |2 net/netfilter/nf_conntrack_pptp.c | 62 +--- net/qrtr/qrtr.c |2 net/sctp/sm_statefuns.c |9 +- net/xfrm/xfrm_input.c |2 net/xfrm/xfrm_output.c |3 net/xfrm/xfrm_policy.c |7 - security/commoncap.c|1 sound/core/hwdep.c |4 - sound/usb/mixer.c |8 ++ 59 files changed, 337 insertions(+), 181 deletions(-) Alexander Dahl (1): x86/dma: Fix max PFN arithmetic overflow on 32 bit systems Alexander Potapenko (1): fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() Arnd Bergmann (1): include/asm-generic/topology.h: guard cpumask_of_node() macro argument Benjamin Block (1): scsi: zfcp: fix request object use-after-free in send path causing wrong traces Bob Peterson (1): gfs2: move privileged user check to gfs2_quota_lock_check Brendan Shanks (1): Input: evdev - call input_flush_device() on release(), not flush() Changming Liu (1): ALSA: hwdep: fix a left shifting 1 by 31 UB bug Chris Chiu (1): ALSA: usb-audio: mixer: volume quirk for ESS Technology Asus USB DAC Chuhong Yuan (1): net: microchip: encx24j600: add missed kthread_stop Dmitry
Re: [PATCH v6 01/13] tools/libperf: introduce notion of static polled file descriptors
Hi, On 03.06.2020 14:38, Adrian Hunter wrote: > On 1/06/20 11:05 pm, Alexey Budankov wrote: >> >> Implement adding of file descriptors by fdarray__add_stat() to >> fix-sized (currently 1) stat_entries array located at struct fdarray. >> Append added file descriptors to the array used by poll() syscall >> during fdarray__poll() call. Copy poll() result of the added >> descriptors from the array back to the storage for separate analysis. > > Why not instead call evlist__add_pollfd() before other fds are added, so > the fda->entries[] position is always fixed. Then this patch is not needed. It then will block event consumption loop, at least in record mode, due to change sin initial assumptions behind fdarray__filter(). So extension of the API with 'static' fds looks safer w.r.t. possible functional regressions at the same time extending the API with ability to atomically wait for (poll()) not only event fds but also any other fds during monitoring. Feel free to ask more. ~Alexey
Re: Linux 4.4.226
diff --git a/Makefile b/Makefile
index 4e5362707405..1b8bc1f294db 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 225
+SUBLEVEL = 226
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 63741f2e8d01..d72f00310683 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -604,7 +604,7 @@ void __init mem_init(void)
> BITS_PER_LONG);
high_memory = __va((max_pfn << PAGE_SHIFT));
- set_max_mapnr(page_to_pfn(virt_to_page(high_memory - 1)) + 1);
+ set_max_mapnr(max_low_pfn);
free_all_bootmem();
#ifdef CONFIG_PA11
diff --git a/arch/x86/include/asm/dma.h b/arch/x86/include/asm/dma.h
index fe884e18fa6e..c7854a098b6b 100644
--- a/arch/x86/include/asm/dma.h
+++ b/arch/x86/include/asm/dma.h
@@ -73,7 +73,7 @@
#define MAX_DMA_PFN ((16UL * 1024 * 1024) >> PAGE_SHIFT)
/* 4GB broken PCI/AGP hardware bus master zone */
-#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT)
+#define MAX_DMA32_PFN (1UL << (32 - PAGE_SHIFT))
#ifdef CONFIG_X86_32
/* The maximum address that we can perform a DMA transfer to on this platform
*/
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e449f22c8f29..edec88b21ff1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1256,7 +1256,7 @@ retry:
goto fail;
plane = mode_set->crtc->primary;
- plane_mask |= drm_plane_index(plane);
+ plane_mask |= (1 << drm_plane_index(plane));
plane->old_fb = plane->fb;
}
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 644faf3ae93a..245070950e87 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -116,17 +116,19 @@ static void put_pages(struct drm_gem_object *obj)
struct msm_gem_object *msm_obj = to_msm_bo(obj);
if (msm_obj->pages) {
- /* For non-cached buffers, ensure the new pages are clean
-* because display controller, GPU, etc. are not coherent:
-*/
- if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
- dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
- msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
+ if (msm_obj->sgt) {
+ /* For non-cached buffers, ensure the new
+* pages are clean because display controller,
+* GPU, etc. are not coherent:
+*/
+ if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
+ dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl,
+msm_obj->sgt->nents,
+DMA_BIDIRECTIONAL);
- if (msm_obj->sgt)
sg_free_table(msm_obj->sgt);
-
- kfree(msm_obj->sgt);
+ kfree(msm_obj->sgt);
+ }
if (use_pages(obj))
drm_gem_put_pages(obj, msm_obj->pages, true, false);
diff --git a/drivers/infiniband/hw/qib/qib_sysfs.c
b/drivers/infiniband/hw/qib/qib_sysfs.c
index 3ae82202cdb5..b33565f4409f 100644
--- a/drivers/infiniband/hw/qib/qib_sysfs.c
+++ b/drivers/infiniband/hw/qib/qib_sysfs.c
@@ -703,7 +703,7 @@ int qib_create_port_files(struct ib_device *ibdev, u8
port_num,
qib_dev_err(dd,
"Skipping linkcontrol sysfs info, (err %d) port %u\n",
ret, port_num);
- goto bail;
+ goto bail_link;
}
kobject_uevent(>pport_kobj, KOBJ_ADD);
@@ -713,7 +713,7 @@ int qib_create_port_files(struct ib_device *ibdev, u8
port_num,
qib_dev_err(dd,
"Skipping sl2vl sysfs info, (err %d) port %u\n",
ret, port_num);
- goto bail_link;
+ goto bail_sl;
}
kobject_uevent(>sl2vl_kobj, KOBJ_ADD);
@@ -723,7 +723,7 @@ int qib_create_port_files(struct ib_device *ibdev, u8
port_num,
qib_dev_err(dd,
"Skipping diag_counters sysfs info, (err %d) port %u\n",
ret, port_num);
- goto bail_sl;
+ goto bail_diagc;
}
kobject_uevent(>diagc_kobj, KOBJ_ADD);
@@ -736,7 +736,7 @@ int qib_create_port_files(struct ib_device *ibdev, u8
port_num,
qib_dev_err(dd,
"Skipping Congestion Control sysfs info, (err %d) port %u\n",
ret, port_num);
- goto bail_diagc;
+ goto bail_cc;
}
kobject_uevent(>pport_cc_kobj, KOBJ_ADD);
@@ -818,6 +818,7 @@ void qib_verbs_unregister_sysfs(struct qib_devdata *dd)
Re: Linux 4.9.226
diff --git a/Makefile b/Makefile
index d17a2ad3cc4d..b0e1162fddfa 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 225
+SUBLEVEL = 226
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts
b/arch/arm/boot/dts/imx6q-b450v3.dts
index 78bfc1a307d6..ebc6e10f8624 100644
--- a/arch/arm/boot/dts/imx6q-b450v3.dts
+++ b/arch/arm/boot/dts/imx6q-b450v3.dts
@@ -65,13 +65,6 @@
};
};
- {
- assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
- < IMX6QDL_CLK_LDB_DI1_SEL>;
- assigned-clock-parents = < IMX6QDL_CLK_PLL3_USB_OTG>,
-< IMX6QDL_CLK_PLL3_USB_OTG>;
-};
-
{
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts
b/arch/arm/boot/dts/imx6q-b650v3.dts
index d85388725426..681aa612e07f 100644
--- a/arch/arm/boot/dts/imx6q-b650v3.dts
+++ b/arch/arm/boot/dts/imx6q-b650v3.dts
@@ -65,13 +65,6 @@
};
};
- {
- assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
- < IMX6QDL_CLK_LDB_DI1_SEL>;
- assigned-clock-parents = < IMX6QDL_CLK_PLL3_USB_OTG>,
-< IMX6QDL_CLK_PLL3_USB_OTG>;
-};
-
{
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts
b/arch/arm/boot/dts/imx6q-b850v3.dts
index 167f7446722a..8596df4078e9 100644
--- a/arch/arm/boot/dts/imx6q-b850v3.dts
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -53,17 +53,6 @@
};
};
- {
- assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
- < IMX6QDL_CLK_LDB_DI1_SEL>,
- < IMX6QDL_CLK_IPU1_DI0_PRE_SEL>,
- < IMX6QDL_CLK_IPU1_DI1_PRE_SEL>;
- assigned-clock-parents = < IMX6QDL_CLK_PLL5_VIDEO_DIV>,
-< IMX6QDL_CLK_PLL5_VIDEO_DIV>,
-< IMX6QDL_CLK_PLL2_PFD2_396M>,
-< IMX6QDL_CLK_PLL2_PFD2_396M>;
-};
-
{
fsl,dual-channel;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
index e4a415fd899b..cee0e19f180f 100644
--- a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -92,6 +92,56 @@
mux-int-port = <1>;
mux-ext-port = <4>;
};
+
+ aliases {
+ mdio-gpio0 =
+ };
+
+ mdio0: mdio-gpio {
+ compatible = "virtual,mdio-gpio";
+ gpios = < 5 GPIO_ACTIVE_HIGH>, /* mdc */
+ < 7 GPIO_ACTIVE_HIGH>; /* mdio */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@0 {
+ compatible = "marvell,mv88e6085"; /* 88e6240*/
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ switch_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switchphy0: switchphy@0 {
+ reg = <0>;
+ };
+
+ switchphy1: switchphy@1 {
+ reg = <1>;
+ };
+
+ switchphy2: switchphy@2 {
+ reg = <2>;
+ };
+
+ switchphy3: switchphy@3 {
+ reg = <3>;
+ };
+
+ switchphy4: switchphy@4 {
+ reg = <4>;
+ };
+ };
+ };
+ };
};
{
@@ -299,3 +349,30 @@
tcxo-clock-frequency = <2600>;
};
};
+
+ {
+ /* Synopsys, Inc. Device */
+ pci_root: root@0,0 {
+ compatible = "pci16c3,abcd";
+ reg = <0x 0 0 0 0>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ };
+};
+
+ {
+ assigned-clocks = < IMX6QDL_CLK_LDB_DI0_SEL>,
+ < IMX6QDL_CLK_LDB_DI1_SEL>,
+ < IMX6QDL_CLK_IPU1_DI0_PRE_SEL>,
+ < IMX6QDL_CLK_IPU1_DI1_PRE_SEL>,
+ < IMX6QDL_CLK_IPU2_DI0_PRE_SEL>,
+ < IMX6QDL_CLK_IPU2_DI1_PRE_SEL>;
+ assigned-clock-parents = < IMX6QDL_CLK_PLL5_VIDEO_DIV>,
+< IMX6QDL_CLK_PLL5_VIDEO_DIV>,
+< IMX6QDL_CLK_PLL2_PFD0_352M>,
+<
Re: [PATCH] kgdb: Avoid suspicious RCU usage warning
On Tue, Jun 02, 2020 at 03:56:33PM -0700, Doug Anderson wrote: > > > 2. Perhaps remove the whole irq saving / restoring in kgdb_cpu_enter(). > > > > Are you feeling lucky? > > > > I think there will come a time when bravery is called for but I'd rather > > see this as part of a bigger rewrite instead of a single high risk > > change. > > Hrm, maybe. I guess it depends on whether we want to take baby steps > there or try to do it all at once. If we take baby steps we will > occasionally fall down but we'll slowly start getting things cleaned > up. If we wait for a full rewrite then we might be waiting for a long > time. It'll also be harder to figure out which of the big changes in > the major rewrite broken someone. ...or if the major rewrite comes in > 20 small/bisectable patches it may be hard to revert patch 2 out of 20 > if the future patches all build upon it. If we do one small high-risk > change and then wait before building upon it then it'll be easy for > someone to bisect and then yell for a revert. My views are a bit too nuanced for me to agree or disagree with this. I'm not against baby steps and I definitely *don't* want kgdb to continue to be preserved in aspic. However I'm still reluctant to start our baby steps with a "let's see if this breaks something" patch given we know it could be a very large number of kernel cycles before we get an answer. I would be much happier if those baby steps started, for example, with refactoring to decompose the beast into clearer (and dare I say better documented) functions. Or put another way, even if someone sent me 20 small bisectable patches in a single kernel cycle I'd still want the high risk bits to be towards the end of the patch set. Daniel.
Re: [PATCH 2/2] coresight: tmc: Add shutdown callback for TMC ETR/ETF
Hi Robin, Mathieu On 2020-06-03 17:07, Robin Murphy wrote: On 2020-06-01 22:28, Mathieu Poirier wrote: That being said I'm sure that dependencies on an IOMMU isn't a problem confined to coresight. I am adding Robin Murphy, who added this commit [1], to the thread in the hope that he can provide guidance on the right way to do this. Right, it's not specific to CoreSight, and it's not even specific to IOMMUs really. In short, blame kexec ;) Yes it is not specific to coresight, we are targeting this for all consumers/clients of SMMU(atleast on SC7180 SoC). We have display throwing NoC/interconnect errors[1] during reboot after SMMU is disabled. This is also not specific to kexec either as you explained here [2] about a case with display which is exacly what is happening in our system [1]. [1] https://lore.kernel.org/lkml/1591009402-681-1-git-send-email-mkri...@codeaurora.org/ [2] https://lore.kernel.org/lkml/5858bdac-b7f9-ac26-0c0d-c9653cef8...@arm.com/ The fundamental thing is that devices should stop any DMA activity at shutdown. For a normal poweroff you can typically get away without doing so, but over kexec, ongoing DMA traffic may corrupt memory in the new kernel (at worst, I think even DMA reads could potentially cause unexpected cache behaviour that might lead to mishaps, given the right combination of memory attributes). IOMMUs merely help to make the situation more serious. For similar kexec reasons, they need to disable any existing translations at shutdown (imagine if the second kernel didn't have an IOMMU driver). And at that point, even the normal poweroff case becomes problematic, because any device DMA that hasn't been shut down beforehand is now not necessarily going benignly to memory as it would in the no-IOMMU case above, but potentially to random physical addresses, with all the hilarity ensuing that you would expect from that. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 1/1] blk-mq: get ctx in order to handle BLK_MQ_S_INACTIVE in blk_mq_get_tag()
On 02/06/2020 07:17, Dongli Zhang wrote:
When scheduler is set, we hit below page fault when we offline cpu.
[ 1061.007725] BUG: kernel NULL pointer dereference, address: 0040
[ 1061.008710] #PF: supervisor read access in kernel mode
[ 1061.009492] #PF: error_code(0x) - not-present page
[ 1061.010241] PGD 0 P4D 0
[ 1061.010614] Oops: [#1] SMP PTI
[ 1061.011130] CPU: 0 PID: 122 Comm: kworker/0:1H Not tainted 5.7.0-rc7+ #2'
... ...
[ 1061.013760] Workqueue: kblockd blk_mq_run_work_fn
[ 1061.014446] RIP: 0010:blk_mq_put_tag+0xf/0x30
... ...
[ 1061.017726] RSP: 0018:a5c18037fc70 EFLAGS: 00010287
[ 1061.018475] RAX: RBX: a5c18037fcf0 RCX: 0004
[ 1061.019507] RDX: RSI: RDI: 911535dc1180
... ...
[ 1061.028454] Call Trace:
[ 1061.029307] blk_mq_get_tag+0x26e/0x280
[ 1061.029866] ? wait_woken+0x80/0x80
[ 1061.030378] blk_mq_get_driver_tag+0x99/0x110
[ 1061.031009] blk_mq_dispatch_rq_list+0x107/0x5e0
[ 1061.031672] ? elv_rb_del+0x1a/0x30
[ 1061.032178] blk_mq_do_dispatch_sched+0xe2/0x130
[ 1061.032844] __blk_mq_sched_dispatch_requests+0xcc/0x150
[ 1061.033638] blk_mq_sched_dispatch_requests+0x2b/0x50
[ 1061.034239] __blk_mq_run_hw_queue+0x75/0x110
[ 1061.034867] process_one_work+0x15c/0x370
[ 1061.035450] worker_thread+0x44/0x3d0
[ 1061.035980] kthread+0xf3/0x130
[ 1061.036440] ? max_active_store+0x80/0x80
[ 1061.037018] ? kthread_bind+0x10/0x10
[ 1061.037554] ret_from_fork+0x35/0x40
[ 1061.038073] Modules linked in:
[ 1061.038543] CR2: 0040
[ 1061.038962] ---[ end trace d20e1df7d028e69f ]---
This is because blk_mq_get_driver_tag() would be used to allocate tag once
scheduler (e.g., mq-deadline) is set.
I tried mq-deadline and I did not see this. Anyway else special or
specific about your test?
However, I see other issues for that (setting the scheduler), that being
scsi timeouts when I start running IO and hotplugging CPUs. I should
have tested the scheduler != none previously for "blk-mq: improvement
CPU hotplug (simplified version) " series ...
I'll check Ming's patch "[PATCH] blk-mq: don't fail driver tag
allocation because of inactive hctx" for that.
Thanks,
John
However, in order to handle
BLK_MQ_S_INACTIVE in blk_mq_get_tag(), we need to set data->ctx for
blk_mq_put_tag().
Fixes: bf0beec0607db3c6 ("blk-mq: drain I/O when all CPUs in a hctx are
offline")
Signed-off-by: Dongli Zhang
---
This is based on for-next because currently the pull request for v5.8 is
not picked by mainline.
block/blk-mq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 9a36ac1c1fa1..8bf6c06a86c1 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1056,6 +1056,7 @@ bool blk_mq_get_driver_tag(struct request *rq)
{
struct blk_mq_alloc_data data = {
.q = rq->q,
+ .ctx = rq->mq_ctx,
.hctx = rq->mq_hctx,
.flags = BLK_MQ_REQ_NOWAIT,
.cmd_flags = rq->cmd_flags,
Re: [PATCH 0/9] x86/entry fixes
On Wed, Jun 03, 2020 at 01:40:14PM +0200, Peter Zijlstra wrote: > The first patch is a fix for x86/entry, I'm quicky runing out of brown paper > bags again :/ > > The rest goes on top of these: > > https://lkml.kernel.org/r/20200602173103.931412...@infradead.org > https://lkml.kernel.org/r/20200602184409.22142-1-el...@google.com > > patches from myself and Marco that enable *SAN builds. So far GCC-KASAN seen > to > behave quite well, I've yet to try UBSAN. GCC10 + UBSAN: vmlinux.o: warning: objtool: match_held_lock()+0x1b2: call to __ubsan_handle_type_mismatch_v1() leaves .noinstr.text section vmlinux.o: warning: objtool: rcu_nmi_enter()+0x234: call to __ubsan_handle_out_of_bounds() leaves .noinstr.text section vmlinux.o: warning: objtool: __rcu_is_watching()+0x59: call to __ubsan_handle_out_of_bounds() leaves .noinstr.text section All of them are marked noinstr. So I suppose UBSAN is just buggered in GCC :-/
Re: [PATCH v5 4/4] kdb: Switch to use safer dbg_io_ops over console APIs
On Wed 2020-06-03 10:18:30, Daniel Thompson wrote:
> On Wed, Jun 03, 2020 at 10:25:04AM +0200, Petr Mladek wrote:
> > On Wed 2020-06-03 12:52:15, Sumit Garg wrote:
> > > In kgdb context, calling console handlers aren't safe due to locks used
> > > in those handlers which could in turn lead to a deadlock. Although, using
> > > oops_in_progress increases the chance to bypass locks in most console
> > > handlers but it might not be sufficient enough in case a console uses
> > > more locks (VT/TTY is good example).
> > >
> > > Currently when a driver provides both polling I/O and a console then kdb
> > > will output using the console. We can increase robustness by using the
> > > currently active polling I/O driver (which should be lockless) instead
> > > of the corresponding console. For several common cases (e.g. an
> > > embedded system with a single serial port that is used both for console
> > > output and debugger I/O) this will result in no console handler being
> > > used.
> > >
> > > In order to achieve this we need to reverse the order of preference to
> > > use dbg_io_ops (uses polling I/O mode) over console APIs. So we just
> > > store "struct console" that represents debugger I/O in dbg_io_ops and
> > > while emitting kdb messages, skip console that matches dbg_io_ops
> > > console in order to avoid duplicate messages. After this change,
> > > "is_console" param becomes redundant and hence removed.
> > >
> > > diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c
> > > index 4139698..6e182aa 100644
> > > --- a/drivers/tty/serial/kgdboc.c
> > > +++ b/drivers/tty/serial/kgdboc.c
> > > @@ -558,6 +557,7 @@ static int __init kgdboc_earlycon_init(char *opt)
> > > }
> > >
> > > earlycon = con;
> > > + kgdboc_earlycon_io_ops.cons = con;
> > > pr_info("Going to register kgdb with earlycon '%s'\n", con->name);
> > > if (kgdb_register_io_module(_earlycon_io_ops) != 0) {
> > > earlycon = NULL;
> >
> > Should we clear kgdboc_earlycon_io_ops.cons here when
> > kgdb_register_io_module() failed?
> >
> > > diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
> > > index c62d764..529116b 100644
> > > --- a/include/linux/kgdb.h
> > > +++ b/include/linux/kgdb.h
> > > @@ -276,8 +276,7 @@ struct kgdb_arch {
> > > * the I/O driver.
> > > * @post_exception: Pointer to a function that will do any cleanup work
> > > * for the I/O driver.
> > > - * @is_console: 1 if the end device is a console 0 if the I/O device is
> > > - * not a console
> > > + * @cons: valid if the I/O device is a console; else NULL.
> > > */
> > > struct kgdb_io {
> > > const char *name;
> > > @@ -288,7 +287,7 @@ struct kgdb_io {
> > > void(*deinit) (void);
> > > void(*pre_exception) (void);
> > > void(*post_exception) (void);
> > > - int is_console;
> > > + struct console *cons;
> >
> > Nit: I would call it "con". The trailing 's' makes me feel that that the
> > variable points to an array or list of consoles.
>
> How strongly do you feel about it?
I do not have strong opinion about it.
> I'd probably agree with you except that the uart subsystem, which is by
> far the most prolific supplier of consoles for kgdb to use, calls
> pointers to single consoles "cons" so I'd prefer to be aligned on
> terminology.
You made me curious ;-) I tried to find what names are used for
struct console variables.
$linux> git grep "struct console \*c" | sed -e "s/^.*\(struct
console[[:blank:]]*\*c[a-z]*\).*$/\1/" | sort | uniq -c
26 struct console *c
181 struct console *co
68 struct console *con
7 struct console *cons
28 struct console *console
1 struct console *cs
and from tty subdirectory:
linux/drivers/tty> git grep "struct console \*c" | sed -e "s/^.*\(struct
console[[:blank:]]*\*c[a-z]*\).*$/\1/" | sort | uniq -c
8 struct console *c
136 struct console *co
35 struct console *con
4 struct console *cons
10 struct console *console
1 struct console *cs
Anyway, feel free to use whatever you want. I prefer "con".
But "cons" still looks better than "co" ;-)
Best Regards,
Petr
[PATCH] dt-bindings: rtc: Convert imxdi rtc to json-schema
Convert the i.MXDI RTC binding to DT schema format using json-schema
Signed-off-by: Anson Huang
---
.../devicetree/bindings/rtc/imxdi-rtc.txt | 20 ---
.../devicetree/bindings/rtc/imxdi-rtc.yaml | 42 ++
2 files changed, 42 insertions(+), 20 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rtc/imxdi-rtc.txt
create mode 100644 Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml
diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt
b/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt
deleted file mode 100644
index c797bc9..000
--- a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* i.MX25 Real Time Clock controller
-
-Required properties:
-- compatible: should be: "fsl,imx25-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- clocks: should contain the phandle for the rtc clock
-- interrupts: rtc alarm interrupt
-
-Optional properties:
-- interrupts: dryice security violation interrupt (second entry)
-
-Example:
-
-rtc@53ffc000 {
- compatible = "fsl,imx25-rtc";
- reg = <0x53ffc000 0x4000>;
- clocks = < 81>;
- interrupts = <25 56>;
-};
diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml
b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml
new file mode 100644
index 000..6e43926
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/imxdi-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX25 Real Time Clock controller
+
+maintainers:
+ - Roland Stigge
+
+properties:
+ compatible:
+const: fsl,imx25-rtc
+
+ reg:
+maxItems: 1
+
+ interrupts:
+items:
+ - description: rtc alarm interrupt
+ - description: dryice security violation interrupt
+minItems: 1
+maxItems: 2
+
+ clocks:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+examples:
+ - |
+rtc@53ffc000 {
+compatible = "fsl,imx25-rtc";
+reg = <0x53ffc000 0x4000>;
+clocks = < 81>;
+interrupts = <25>, <56>;
+};
--
2.7.4
Re: [PATCH] cxl: Fix kobject memleak
在 2020/6/3 19:33, Andrew Donnellan 写道:
On 2/6/20 10:07 pm, Wang Hai wrote:
Currently the error return path from kobject_init_and_add() is not
followed by a call to kobject_put() - which means we are leaking
the kobject.
Fix it by adding a call to kobject_put() in the error path of
kobject_init_and_add().
Fixes: b087e6190ddc ("cxl: Export optional AFU configuration record
in sysfs")
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
Thanks for the fix!
I note that the err1 label returns without calling kfree(cr) and I
can't see a reason why we do that - so perhaps we should remove the
return statement in err1: so it falls through?
kfree(cr) can be called when
kobject_put()-->kobject_release()-->kobject_cleanup()-->kobj_type->release()
is called. The kobj_type here is afu_config_record_type
Thanks,
Wang Hai
[PATCH] media: omap3isp: Add missed v4l2_ctrl_handler_free() for preview_init_entities()
preview_init_entities() does not call v4l2_ctrl_handler_free() when
it fails.
Add the missed function to fix it.
Fixes: de1135d44f4f ("[media] omap3isp: CCDC, preview engine and resizer]")
Signed-off-by: Chuhong Yuan
---
drivers/media/platform/omap3isp/isppreview.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/omap3isp/isppreview.c
b/drivers/media/platform/omap3isp/isppreview.c
index 4dbdf3180d10..38b93ec60536 100644
--- a/drivers/media/platform/omap3isp/isppreview.c
+++ b/drivers/media/platform/omap3isp/isppreview.c
@@ -2287,7 +2287,7 @@ static int preview_init_entities(struct isp_prev_device
*prev)
me->ops = _media_ops;
ret = media_entity_pads_init(me, PREV_PADS_NUM, pads);
if (ret < 0)
- return ret;
+ goto err_handler_free;
preview_init_formats(sd, NULL);
@@ -2320,6 +2320,8 @@ static int preview_init_entities(struct isp_prev_device
*prev)
omap3isp_video_cleanup(>video_in);
error_video_in:
media_entity_cleanup(>subdev.entity);
+error_handler_free:
+ v4l2_ctrl_handler_free(>ctrls);
return ret;
}
--
2.26.2
[PATCH] media: marvell-ccic: Add missed v4l2_async_notifier_cleanup()
mccic_register() forgets to cleanup the notifier in its error handler.
Add the missed call to fix it.
Fixes: 3eefe36cc00c ("media: marvell-ccic: use async notifier to get the
sensor")
Signed-off-by: Chuhong Yuan
---
drivers/media/platform/marvell-ccic/mcam-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 09775b6624c6..cf2a0119e679 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -1940,6 +1940,7 @@ int mccic_register(struct mcam_camera *cam)
out:
v4l2_async_notifier_unregister(>notifier);
v4l2_device_unregister(>v4l2_dev);
+ v4l2_async_notifier_cleanup(>notifier);
return ret;
}
EXPORT_SYMBOL_GPL(mccic_register);
--
2.26.2
RE: [PATCH v2 06/15] dmaengine: dw-edma: Use PCI_IRQ_MSI_TYPES where appropriate
On Wed, Jun 3, 2020 at 12:47:42, Piotr Stankiewicz
wrote:
> Seeing as there is shorthand available to use when asking for any type
> of interrupt, or any type of message signalled interrupt, leverage it.
>
> Signed-off-by: Piotr Stankiewicz
> Reviewed-by: Andy Shevchenko
> ---
> drivers/dma/dw-edma/dw-edma-pcie.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c
> b/drivers/dma/dw-edma/dw-edma-pcie.c
> index dc85f55e1bb8..46defe30ac25 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> @@ -117,7 +117,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>
> /* IRQs allocation */
> nr_irqs = pci_alloc_irq_vectors(pdev, 1, pdata->irqs,
> - PCI_IRQ_MSI | PCI_IRQ_MSIX);
> + PCI_IRQ_MSI_TYPES);
> if (nr_irqs < 1) {
> pci_err(pdev, "fail to alloc IRQ vector (number of IRQs=%u)\n",
> nr_irqs);
> --
> 2.17.2
Acked-by: Gustavo Pimentel
Re: [PATCH 0/4] sched: Remove some redundancy
On Wed, Jun 03, 2020 at 10:03:00AM +0200, Dietmar Eggemann wrote: > Remove redundant functions, parameters and macros from the task > scheduler code. > > Dietmar Eggemann (4): > sched/pelt: Remove redundant cap_scale() definition > sched/core: Remove redundant 'preempt' param from > sched_class->yield_to_task() > sched/idle,stop: Remove .get_rr_interval from sched_class > sched/fair: Remove unused 'sd' parameter from scale_rt_capacity() Thanks!
Re: [PATCH V1 1/2] mmc: sdhci-msm: Add interconnect bandwidth scaling support
Hey Pradeep,
Thanks for the patch.
On 2020-06-03 14:39, Pradeep P V K wrote:
Interconnect bandwidth scaling support is now added as a
part of OPP [1]. So, make sure interconnect driver is ready
before handling interconnect scaling.
This change is based on
[1] [Patch v8] Introduce OPP bandwidth bindings
(https://lkml.org/lkml/2020/5/12/493)
[2] [Patch v3] mmc: sdhci-msm: Fix error handling
for dev_pm_opp_of_add_table()
(https://lkml.org/lkml/2020/5/5/491)
Signed-off-by: Pradeep P V K
---
drivers/mmc/host/sdhci-msm.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/mmc/host/sdhci-msm.c
b/drivers/mmc/host/sdhci-msm.c
index b277dd7..bf95484 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "sdhci-pltfm.h"
#include "cqhci.h"
@@ -1999,6 +2000,7 @@ static int sdhci_msm_probe(struct platform_device
*pdev)
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_msm_host *msm_host;
struct clk *clk;
+ struct icc_path *sdhc_path;
int ret;
u16 host_version, core_minor;
u32 core_version, config;
@@ -2070,6 +2072,20 @@ static int sdhci_msm_probe(struct
platform_device *pdev)
}
msm_host->bulk_clks[0].clk = clk;
+ /* Make sure that ICC driver is ready for interconnect bandwdith
+* scaling before registering the device for OPP.
+*/
+ sdhc_path = of_icc_get(>dev, NULL);
+ ret = PTR_ERR_OR_ZERO(sdhc_path);
+ if (ret) {
+ if (ret == -EPROBE_DEFER)
+ dev_info(>dev, "defer icc path: %d\n", ret);
+ else
+ dev_err(>dev, "failed to get icc path:%d\n", ret);
+ goto bus_clk_disable;
+ }
+ icc_put(sdhc_path);
ret = dev_pm_opp_of_find_icc_paths(>dev, NULL);
since there are multiple paths
described in the bindings you
should use ^^ instead and you
can drop temporary path as well.
+
msm_host->opp_table = dev_pm_opp_set_clkname(>dev, "core");
if (IS_ERR(msm_host->opp_table)) {
ret = PTR_ERR(msm_host->opp_table);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers
Hello, > > > Thanks for the pointer! I'm still looking at the details yet, but a > > quick look (usb_dev_authorized()) seems to suggest that this API is > > "device based". The multiple levels of "authorized" seem to take shape > > from either how it is wired or from userspace choice. Once authorized, > > USB device or interface is authorized to be used by *anyone* (can be > > attached to any drivers). Do I understand it right that it does not > > differentiate between drivers? > > Yes, and that is what you should do, don't fixate on drivers. Users > know how to control and manage devices. Us kernel developers are > responsible for writing solid drivers and getting them merged into the > kernel tree and maintaining them over time. Drivers in the kernel > should always be trusted, ... 1) Yes, I agree that this would be ideal, and this should be our mission. I should clarify that I may have used the wrong term "Trusted/Certified drivers". I didn't really mean that the drivers may be malicious by intent. What I really meant is that a driver may have an attack surface, which is a vulnerability that may be exploited. Realistically speaking, finding vulnerabilities in drivers, creating attacks to exploit them, and fixing them is a never ending cat and mouse game. At Least "identifying the vulnerabilities" part is better performed by security folks rather than driver writers. Earlier in the thread I had mentioned certain studies/projects that identified and exploited such vulnerabilities in the drivers. I should have used the term "Vetted Drivers" maybe to convey the intent better - drivers that have been vetted by a security focussed team (admin). What I'm advocating here is an administrator's right to control the drivers that he wants to allow for external ports on his systems. 2) In addition to the problem of driver negligences / vulnerabilities to be exploited, we ran into another problem with the "whitelist devices only" approach. We did start with the "device based" approach only initially - but quickly realized that anything we use to whitelist an external device can only be based on the info provided by *that device* itself. So until we have devices that exchange certificates with kernel [1], it is easy for a malicious device to spoof a whitelisted device (by presenting the same VID:DID or any other data that is used by us to whitelist it). [1] https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-security-enhancements-spec.html I hope that helps somewhat clarify how / why we reached here? Thanks & Best Regards, Rajat > thanks, > > greg k-h
Re: [PATCH v4 3/4] mm/util.c: remove the VM_WARN_ONCE for vm_committed_as underflow check
> On Jun 3, 2020, at 5:48 AM, Feng Tang wrote:
>
> This check was added by 82f71ae4a2b8 ("mm: catch memory commitment underflow")
> in 2014 to have a safety check for issues which have been fixed.
> And there has been few report caught by it, as described in its
> commit log:
>
> : This shouldn't happen any more - the previous two patches fixed
> : the committed_as underflow issues.
>
> But it was really found by Qian Cai when he used the LTP memory
> stress suite to test a RFC patchset, which tries to improve scalability
> of per-cpu counter 'vm_committed_as', by chosing a bigger 'batch' number
> for loose overcommit policies (OVERCOMMIT_ALWAYS and OVERCOMMIT_GUESS),
> while keeping current number for OVERCOMMIT_NEVER.
>
> With that patchset, when system firstly uses a loose policy, the
> 'vm_committed_as' count could be a big negative value, as its big 'batch'
> number allows a big deviation, then when the policy is changed to
> OVERCOMMIT_NEVER, the 'batch' will be decreased to a much smaller value,
> thus hits this WARN check.
>
> To mitigate this, one proposed solution is to queue work on all online
> CPUs to do a local sync for 'vm_committed_as' when changing policy to
> OVERCOMMIT_NEVER, plus some global syncing to garante the case won't
> be hit.
>
> But this solution is costy and slow, given this check hasn't shown real
> trouble or benefit, simply drop it from one hot path of MM. And perf
> stats does show some tiny saving for removing it.
The text looks more reasonable than the previous one.
Reviewed-by: Qian Cai
Re: sys/sysinfo.h clash with linux/kernel.h
i think the linux-api list is the right place for this so adding it on cc. * Rich Felker [2020-06-02 17:37:05 -0400]: > linux/kernel.h is a uapi header that does almost nothing but define > some internal-use alignment macros and -- oddly -- include > linux/sysinfo.h to provide a definition of struct sysinfo. It's > included only from 6 places in the kernel uapi headers: > > include/uapi/linux/lightnvm.h > include/uapi/linux/ethtool.h > include/uapi/linux/sysctl.h > include/uapi/linux/netlink.h > include/uapi/linux/netfilter/x_tables.h > include/uapi/linux/mroute6.h > > However, it's also included from glibc's sys/sysinfo.h to provide > struct sysinfo (glibc depends on the kernel for the definition). On > musl, this produces a conflicting definition if both sys/sysinfo.h and > any of the above 6 headers are included in the same file. > > I think the underlying problem here is that the same header is used > for two very disjoint purposes: by glibc as the provider of struct > sysinfo, and by other kernel headers as provider of the alignment > macros. > > The glibc use is effectively a permanent contract that can't be > changed, so what I'd like to do is move the macros out to a separate > header (maybe linux/something_macros.h?) and have linux/kernel.h and > the above 6 uapi headers all include that. Then nothing but > linux/kernel.h would pull in linux/sysinfo.h. i think providing a patch would make this happen faster. ideally uapi would be reorganized such that it's clear what headers are supposed to be compatible with inclusion together with libc headers and what headers may conflict. > > Note that in practice this is a rather hard issue to hit since almost > nothing needs sysinfo() at the same time as the above uapi interfaces. > However it did come up in toybox, which is how I first (just today) > learned about the conflict, so it seems like something that should be > fixed. > > Rich
Re: [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc family
On Wed, 2020-06-03 at 09:50 +, Robin Gong wrote: > On 2020/06/03 Matthias Schiffer > wrote: > > On Thu, 2020-05-21 at 04:34 +0800, Robin Gong wrote: > > > There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO > > > transfer to be send twice in DMA mode. Please get more > > > information > > > from: > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > . > > > > > > > nxp.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdfdata=02%7C01%7C > > yibin.g > > > > > > > ong%40nxp.com%7C4621358b9be04a79d2d508d80798835b%7C686ea1d3bc2b > > 4c6fa92 > > > > > > > cd99c5c301635%7C0%7C1%7C637267698912634476sdata=hR66H1hP% > > 2Fqb6OXe > > > w9wpXizY8DiNfZZ1KLwu3Kty87jc%3Dreserved=0. The workaround is > > > adding new sdma ram script which works in XCH mode as PIO inside > > > sdma > > > instead of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0. The > > > issue > > > > should be exist on all legacy i.mx6/7 soc family before i.mx6ul. > > > NXP fix this design issue from i.mx6ul, so newer chips including > > > i.mx6ul/ 6ull/6sll do not need this workaroud anymore. All other > > > i.mx6/7/8 chips still need this workaroud. This patch set add new > > > 'fsl,imx6ul-ecspi' > > > for ecspi driver and 'ecspi_fixed' in sdma driver to choose if > > > need > > > errata or not. > > > The first two reverted patches should be the same issue, though, > > > it > > > seems 'fixed' by changing to other shp script. Hope Sean or > > > Sascha > > > could have the chance to test this patch set if could fix their > > > issues. > > > Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not > > > work > > > on i.mx8mm because the event id is zero. > > > > > > PS: > > >Please get sdma firmware from below linux-firmware and copy it > > > to > > > your local rootfs /lib/firmware/imx/sdma. > > > > > > Hello Robin, > > > > we have tried out this series, and there seems to be an issue with > > the > > PIO fallback. We are testing on an i.MX6Q board, and our kernel is > > a > > mostly-unmodified 5.4, on which we backported all SDMA patches from > > next-20200602 (imx-sdma.c is identical to next-20200602 version), > > and > > then applied this whole series. > > > > We build the SDMA driver as a kernel module, which is loaded by > > udev, > > so the root filesystem is ready and the SDMA firmware can be > > loaded. > > The behaviour we're seeing is the following: > > > > 1. As long as the SDMA driver is not loaded, initializing spi_imx > > will > > be deferred > > 2. imx_sdma is loaded. The SDMA firmware is not yet loaded at this > > point > > 3. spi_imx is initialized and an SPI-NOR flash is probed. To load > > the > > BFPT, the driver will attempt to use DMA; this will fail with > > EINVAL as > > long as the SDMA firmware is not ready, so the fallback to PIO > > happens > > (4. SDMA firmware is ready, subsequent SPI transfers use DMA) > > > > The problem happens in step 3: Whenever the driver falls back to > > PIO, > > the received data is corrupt. The behaviour is specific to the > > fallback: When I disable DMA completely via spi_imx.use_dma, or > > when > > the timing is lucky and the SDMA firmware gets loaded before the > > flash > > is probed, no corruption can be observed. > > Thanks Matthias, would you like post log? > I have attached the following log files: - pio.log: DMA disabled via module parameter - dma.log: "lucky" timing, SDMA firmware loaded before SPI-NOR probe - fallback.log: DMA->PIO fallback The logs include some additional log messages: - Return value of spi_imx_dma_transfer() before PIO fallback - SPI-NOR SFPT dump It can be seen that the BFPT data is identical in pio.log and dma.log, and differs almost completely in fallback.log. The corrupted data seems to be random, or uninitialized memory; it differs with every boot. Kind regards, Matthias [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 5.4.39 (oe-user@oe-host) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT Wed Jun 3 11:14:56 UTC 2020 [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: TQ TQMa6Q on MBa6x [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 160 MiB at 0x4600 [0.00] On node 0 totalpages: 262144 [0.00] Normal zone: 2048 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 262144 pages, LIFO batch:63 [0.00] percpu: Embedded 20 pages/cpu s50664 r8192 d23064 u81920 [0.00] pcpu-alloc: s50664 r8192 d23064 u81920 alloc=20*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 260096 [0.00] Kernel command line: root=/dev/mmcblk1p2 ro rootwait console=ttymxc1,115200 spi_imx.dyndbg=+p consoleblank=0 cma=160M [0.00] Dentry cache hash
[PATCH v2 13/15] aquantia: atlantic: Use PCI_IRQ_ALL_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type of interrupt, or any type of message signalled interrupt, leverage it. Signed-off-by: Piotr Stankiewicz Reviewed-by: Andy Shevchenko --- drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c b/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c index 8a70ffe1d326..2a0ebf296478 100644 --- a/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c +++ b/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c @@ -277,9 +277,7 @@ static int aq_pci_probe(struct pci_dev *pdev, numvecs += AQ_HW_SERVICE_IRQS; /*enable interrupts */ #if !AQ_CFG_FORCE_LEGACY_INT - err = pci_alloc_irq_vectors(self->pdev, 1, numvecs, - PCI_IRQ_MSIX | PCI_IRQ_MSI | - PCI_IRQ_LEGACY); + err = pci_alloc_irq_vectors(self->pdev, 1, numvecs, PCI_IRQ_ALL_TYPES); if (err < 0) goto err_hwinit; -- 2.17.2
[PATCH v2 15/15] scsi: Use PCI_IRQ_MSI_TYPES and PCI_IRQ_ALL_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/scsi/ipr.c| 5 +++--
drivers/scsi/vmw_pvscsi.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index d48a8fa997b9..8e8d66daabea 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -10273,9 +10273,10 @@ static int ipr_probe_ioa(struct pci_dev *pdev,
ipr_number_of_msix = IPR_MAX_MSIX_VECTORS;
}
- irq_flag = PCI_IRQ_LEGACY;
if (ioa_cfg->ipr_chip->has_msi)
- irq_flag |= PCI_IRQ_MSI | PCI_IRQ_MSIX;
+ irq_flag = PCI_IRQ_ALL_TYPES;
+ else
+ irq_flag = PCI_IRQ_LEGACY;
rc = pci_alloc_irq_vectors(pdev, 1, ipr_number_of_msix, irq_flag);
if (rc < 0) {
ipr_wait_for_pci_err_recovery(ioa_cfg);
diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c
index c3f010df641e..825b7db9c713 100644
--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -1347,7 +1347,7 @@ static u32 pvscsi_get_max_targets(struct pvscsi_adapter
*adapter)
static int pvscsi_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
- unsigned int irq_flag = PCI_IRQ_MSIX | PCI_IRQ_MSI | PCI_IRQ_LEGACY;
+ unsigned int irq_flag = PCI_IRQ_ALL_TYPES;
struct pvscsi_adapter *adapter;
struct pvscsi_adapter adapter_temp;
struct Scsi_Host *host = NULL;
--
2.17.2
[PATCH v2 14/15] net: hns3: Use PCI_IRQ_MSI_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 +--
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index a758f9ae32be..c49313e87170 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2334,8 +2334,7 @@ static int hclge_init_msi(struct hclge_dev *hdev)
int i;
vectors = pci_alloc_irq_vectors(pdev, HNAE3_MIN_VECTOR_NUM,
- hdev->num_msi,
- PCI_IRQ_MSI | PCI_IRQ_MSIX);
+ hdev->num_msi, PCI_IRQ_MSI_TYPES);
if (vectors < 0) {
dev_err(>dev,
"failed(%d) to allocate MSI/MSI-X vectors\n",
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index e02d427131ee..2b02024bd00a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -2341,8 +2341,7 @@ static int hclgevf_init_msi(struct hclgevf_dev *hdev)
PCI_IRQ_MSIX);
else
vectors = pci_alloc_irq_vectors(pdev, HNAE3_MIN_VECTOR_NUM,
- hdev->num_msi,
- PCI_IRQ_MSI | PCI_IRQ_MSIX);
+ hdev->num_msi,
PCI_IRQ_MSI_TYPES);
if (vectors < 0) {
dev_err(>dev,
--
2.17.2
[PATCH v2 12/15] amd-xgbe: Use PCI_IRQ_MSI_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
index 7b86240ecd5f..903bc5ef2518 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
@@ -133,7 +133,7 @@ static int xgbe_config_multi_msi(struct xgbe_prv_data
*pdata)
pdata->tx_ring_count);
ret = pci_alloc_irq_vectors(pdata->pcidev, XGBE_MSI_MIN_COUNT,
- vector_count, PCI_IRQ_MSI | PCI_IRQ_MSIX);
+ vector_count, PCI_IRQ_MSI_TYPES);
if (ret < 0) {
dev_info(pdata->dev, "multi MSI/MSI-X enablement failed\n");
return ret;
--
2.17.2
[PATCH v2 10/15] vmw_vmci: Use PCI_IRQ_ALL_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/misc/vmw_vmci/vmci_guest.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
index cc8eeb361fcd..ea300573f652 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -584,8 +584,7 @@ static int vmci_guest_probe_device(struct pci_dev *pdev,
error = pci_alloc_irq_vectors(pdev, VMCI_MAX_INTRS, VMCI_MAX_INTRS,
PCI_IRQ_MSIX);
if (error < 0) {
- error = pci_alloc_irq_vectors(pdev, 1, 1,
- PCI_IRQ_MSIX | PCI_IRQ_MSI | PCI_IRQ_LEGACY);
+ error = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
if (error < 0)
goto err_remove_bitmap;
} else {
--
2.17.2
[PATCH v2 11/15] mmc: sdhci: Use PCI_IRQ_MSI_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
Acked-by: Ulf Hansson
Acked-by: Adrian Hunter
---
drivers/mmc/host/sdhci-pci-gli.c | 3 +--
drivers/mmc/host/sdhci-pci-o2micro.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pci-gli.c b/drivers/mmc/host/sdhci-pci-gli.c
index fd76aa672e02..d14997f9cbf9 100644
--- a/drivers/mmc/host/sdhci-pci-gli.c
+++ b/drivers/mmc/host/sdhci-pci-gli.c
@@ -271,8 +271,7 @@ static void gli_pcie_enable_msi(struct sdhci_pci_slot *slot)
{
int ret;
- ret = pci_alloc_irq_vectors(slot->chip->pdev, 1, 1,
- PCI_IRQ_MSI | PCI_IRQ_MSIX);
+ ret = pci_alloc_irq_vectors(slot->chip->pdev, 1, 1, PCI_IRQ_MSI_TYPES);
if (ret < 0) {
pr_warn("%s: enable PCI MSI failed, error=%d\n",
mmc_hostname(slot->host->mmc), ret);
diff --git a/drivers/mmc/host/sdhci-pci-o2micro.c
b/drivers/mmc/host/sdhci-pci-o2micro.c
index fa8105087d68..498c51207bfb 100644
--- a/drivers/mmc/host/sdhci-pci-o2micro.c
+++ b/drivers/mmc/host/sdhci-pci-o2micro.c
@@ -470,8 +470,7 @@ static void sdhci_pci_o2_enable_msi(struct sdhci_pci_chip
*chip,
return;
}
- ret = pci_alloc_irq_vectors(chip->pdev, 1, 1,
- PCI_IRQ_MSI | PCI_IRQ_MSIX);
+ ret = pci_alloc_irq_vectors(chip->pdev, 1, 1, PCI_IRQ_MSI_TYPES);
if (ret < 0) {
pr_err("%s: enable PCI MSI failed, err=%d\n",
mmc_hostname(host->mmc), ret);
--
2.17.2
[GIT PULL REQUEST] watchdog - v5.8 Merge window
Hi Linus, Please pull the watchdog changes for the v5.8 release cycle. This series contains: * Add new arm_smc_wdt watchdog driver * da9062 and da9063 improvements * Clarify documentation about stop() that became optional * Document r8a7742 support * some overall fixes and improvements Please also note that Stephen Rothwell reported a conflict between the device tree and the watchdog tree on Tue, 26 May 2020 15:20:15 +1000. He fixed it with the following patch: diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml index 27e8c4accd67..572f4c912fef 100644 --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml @@ -24,6 +24,7 @@ properties: - items: - enum: + - renesas,r8a7742-wdt # RZ/G1H - renesas,r8a7743-wdt # RZ/G1M - renesas,r8a7744-wdt # RZ/G1N - renesas,r8a7745-wdt # RZ/G1E --- The output from git request-pull: The following changes since commit 9cb1fd0efd195590b828b9b865421ad345a4a145: Linux 5.7-rc7 (2020-05-24 15:32:54 -0700) are available in the git repository at: git://www.linux-watchdog.org/linux-watchdog.git tags/linux-watchdog-5.8-rc1 for you to fetch changes up to 072cb8b628d312f5785ffdf324286a0519aed910: watchdog: m54xx: Add missing include (2020-05-25 08:55:47 +0200) linux-watchdog 5.8-rc1 tag Arnd Bergmann (1): watchdog: iTCO: fix link error Bumsik Kim (1): watchdog: clarify that stop() is optional Dinghao Liu (1): watchdog: Fix runtime PM imbalance on error Evan Benn (1): dt-bindings: watchdog: Add ARM smc wdt for mt8173 watchdog Fabio Estevam (1): watchdog: imx_sc_wdt: Fix reboot on crash Jason Yan (1): watchdog: riowd: remove unneeded semicolon Julius Werner (1): watchdog: Add new arm_smc_wdt watchdog driver Lad Prabhakar (1): dt-bindings: watchdog: renesas,wdt: Document r8a7742 support Shyam Saini (1): watchdog: ts72xx_wdt: fix build error Stefan Riedmueller (3): watchdog: da9062: Initialize timeout during probe watchdog: da9063: Make use of pre-configured timeout during probe watchdog: da9062: No need to ping manually before setting timeout Thomas Gleixner (1): watchdog: m54xx: Add missing include Wolfram Sang (1): watchdog: imx2_wdt: update contact email .../devicetree/bindings/watchdog/arm-smc-wdt.yaml | 37 .../devicetree/bindings/watchdog/renesas,wdt.txt | 1 + .../watchdog/convert_drivers_to_kernel_api.rst | 2 +- Documentation/watchdog/watchdog-kernel-api.rst | 2 +- MAINTAINERS| 7 + arch/arm64/configs/defconfig | 1 + drivers/watchdog/Kconfig | 15 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/arm_smc_wdt.c | 188 + drivers/watchdog/da9062_wdt.c | 32 ++-- drivers/watchdog/da9063_wdt.c | 20 ++- drivers/watchdog/imx2_wdt.c| 2 +- drivers/watchdog/imx_sc_wdt.c | 5 + drivers/watchdog/m54xx_wdt.c | 1 + drivers/watchdog/omap_wdt.c| 1 + drivers/watchdog/riowd.c | 2 +- include/linux/watchdog.h | 4 +- 17 files changed, 299 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml create mode 100644 drivers/watchdog/arm_smc_wdt.c Kind regards, Wim.
[PATCH v2 09/15] media: ddbridge: Use PCI_IRQ_MSI_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/media/pci/ddbridge/ddbridge-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/ddbridge/ddbridge-main.c
b/drivers/media/pci/ddbridge/ddbridge-main.c
index 03dc9924fa2c..ff5c33d7a736 100644
--- a/drivers/media/pci/ddbridge/ddbridge-main.c
+++ b/drivers/media/pci/ddbridge/ddbridge-main.c
@@ -106,7 +106,7 @@ static void ddb_irq_msi(struct ddb *dev, int nr)
if (msi && pci_msi_enabled()) {
stat = pci_alloc_irq_vectors(dev->pdev, 1, nr,
-PCI_IRQ_MSI | PCI_IRQ_MSIX);
+PCI_IRQ_MSI_TYPES);
if (stat >= 1) {
dev->msi = stat;
dev_info(dev->dev, "using %d MSI interrupt(s)\n",
--
2.17.2
[PATCH v2 07/15] drm/amdgpu: Use PCI_IRQ_MSI_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 5ed4227f304b..2588dd1015db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -249,15 +249,10 @@ int amdgpu_irq_init(struct amdgpu_device *adev)
if (amdgpu_msi_ok(adev)) {
int nvec = pci_msix_vec_count(adev->pdev);
- unsigned int flags;
- if (nvec <= 0) {
- flags = PCI_IRQ_MSI;
- } else {
- flags = PCI_IRQ_MSI | PCI_IRQ_MSIX;
- }
/* we only need one vector */
- nvec = pci_alloc_irq_vectors(adev->pdev, 1, 1, flags);
+ nvec = pci_alloc_irq_vectors(adev->pdev, 1, 1,
+PCI_IRQ_MSI_TYPES);
if (nvec > 0) {
adev->irq.msi_enabled = true;
dev_dbg(adev->dev, "amdgpu: using MSI/MSI-X.\n");
--
2.17.2
[PATCH v2 08/15] IB/qib: Use PCI_IRQ_MSI_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/infiniband/hw/qib/qib_pcie.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib_pcie.c
b/drivers/infiniband/hw/qib/qib_pcie.c
index 3dc6ce033319..caff44d2c12c 100644
--- a/drivers/infiniband/hw/qib/qib_pcie.c
+++ b/drivers/infiniband/hw/qib/qib_pcie.c
@@ -213,7 +213,7 @@ int qib_pcie_params(struct qib_devdata *dd, u32 minw, u32
*nent)
u16 linkstat, speed;
int nvec;
int maxvec;
- unsigned int flags = PCI_IRQ_MSIX | PCI_IRQ_MSI;
+ unsigned int flags;
if (!pci_is_pcie(dd->pcidev)) {
qib_dev_err(dd, "Can't find PCI Express capability!\n");
@@ -225,7 +225,9 @@ int qib_pcie_params(struct qib_devdata *dd, u32 minw, u32
*nent)
}
if (dd->flags & QIB_HAS_INTX)
- flags |= PCI_IRQ_LEGACY;
+ flags = PCI_IRQ_ALL_TYPES;
+ else
+ flags = PCI_IRQ_MSI_TYPES;
maxvec = (nent && *nent) ? *nent : 1;
nvec = pci_alloc_irq_vectors(dd->pcidev, 1, maxvec, flags);
if (nvec < 0)
--
2.17.2
Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
Hi Chen, On Tue, Jun 2, 2020 at 8:12 PM John Donnelly wrote: > > > > > On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha > > wrote: > > > > On Tue, Jun 2, 2020 at 3:29 AM John Donnelly > > wrote: > >> > >> Hi . See below ! > >> > >>> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma wrote: > >>> > >>> Hi John, > >>> > >>> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly > >>> wrote: > > Hi, > > > On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote: > > Hi Chen, > > > > On Thu, May 21, 2020 at 3:05 PM Chen Zhou wrote: > >> This patch series enable reserving crashkernel above 4G in arm64. > >> > >> There are following issues in arm64 kdump: > >> 1. We use crashkernel=X to reserve crashkernel below 4G, which will > >> fail > >> when there is no enough low memory. > >> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above > >> 4G, > >> in this case, if swiotlb or DMA buffers are required, crash dump kernel > >> will boot failure because there is no low memory available for > >> allocation. > >> > >> To solve these issues, introduce crashkernel=X,low to reserve specified > >> size low memory. > >> Crashkernel=X tries to reserve memory for the crash dump kernel under > >> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified > >> size low memory for crash kdump kernel devices firstly and then reserve > >> memory above 4G. > >> > >> When crashkernel is reserved above 4G in memory, that is, > >> crashkernel=X,low > >> is specified simultaneously, kernel should reserve specified size low > >> memory > >> for crash dump kernel devices. So there may be two crash kernel > >> regions, one > >> is below 4G, the other is above 4G. > >> In order to distinct from the high region and make no effect to the > >> use of > >> kexec-tools, rename the low region as "Crash kernel (low)", and add DT > >> property > >> "linux,low-memory-range" to crash dump kernel's dtb to pass the low > >> region. > >> > >> Besides, we need to modify kexec-tools: > >> arm64: kdump: add another DT property to crash dump kernel's dtb(see > >> [1]) > >> > >> The previous changes and discussions can be retrieved from: > >> > >> Changes since [v7] > >> - Move x86 CRASH_ALIGN to 2M > >> Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M. > >> - Update Documentation/devicetree/bindings/chosen.txt > >> Add corresponding documentation to > >> Documentation/devicetree/bindings/chosen.txt suggested by Arnd. > >> - Add Tested-by from Jhon and pk > >> > >> Changes since [v6] > >> - Fix build errors reported by kbuild test robot. > >> > >> Changes since [v5] > >> - Move reserve_crashkernel_low() into kernel/crash_core.c. > >> - Delete crashkernel=X,high. > >> - Modify crashkernel=X,low. > >> If crashkernel=X,low is specified simultaneously, reserve spcified > >> size low > >> memory for crash kdump kernel devices firstly and then reserve memory > >> above 4G. > >> In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, > >> and then > >> pass to crash dump kernel by DT property "linux,low-memory-range". > >> - Update Documentation/admin-guide/kdump/kdump.rst. > >> > >> Changes since [v4] > >> - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike. > >> > >> Changes since [v3] > >> - Add memblock_cap_memory_ranges back for multiple ranges. > >> - Fix some compiling warnings. > >> > >> Changes since [v2] > >> - Split patch "arm64: kdump: support reserving crashkernel above 4G" as > >> two. Put "move reserve_crashkernel_low() into kexec_core.c" in a > >> separate > >> patch. > >> > >> Changes since [v1]: > >> - Move common reserve_crashkernel_low() code into kernel/kexec_core.c. > >> - Remove memblock_cap_memory_ranges() i added in v1 and implement that > >> in fdt_enforce_memory_region(). > >> There are at most two crash kernel regions, for two crash kernel > >> regions > >> case, we cap the memory range [min(regs[*].start), max(regs[*].end)] > >> and then remove the memory range in the middle. > >> > >> [1]: > >> https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$ > >> [v1]: > >> https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$ > >> [v2]: > >> https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$ > >> [v3]: > >>
[PATCH v2 06/15] dmaengine: dw-edma: Use PCI_IRQ_MSI_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/dma/dw-edma/dw-edma-pcie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c
b/drivers/dma/dw-edma/dw-edma-pcie.c
index dc85f55e1bb8..46defe30ac25 100644
--- a/drivers/dma/dw-edma/dw-edma-pcie.c
+++ b/drivers/dma/dw-edma/dw-edma-pcie.c
@@ -117,7 +117,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
/* IRQs allocation */
nr_irqs = pci_alloc_irq_vectors(pdev, 1, pdata->irqs,
- PCI_IRQ_MSI | PCI_IRQ_MSIX);
+ PCI_IRQ_MSI_TYPES);
if (nr_irqs < 1) {
pci_err(pdev, "fail to alloc IRQ vector (number of IRQs=%u)\n",
nr_irqs);
--
2.17.2
[PATCH v2 03/15] PCI: Use PCI_IRQ_MSI_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type of interrupt, or any type of message signalled interrupt, leverage it. Signed-off-by: Piotr Stankiewicz Reviewed-by: Andy Shevchenko Reviewed-by: Logan Gunthorpe --- drivers/pci/msi.c | 3 +-- drivers/pci/pcie/portdrv_core.c | 4 ++-- drivers/pci/switch/switchtec.c | 3 +-- 3 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index 443cc324b196..9db9ce5dddb3 100644 --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -1231,8 +1231,7 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs, } } - if (msix_vecs == -ENOSPC || - (flags & (PCI_IRQ_MSI | PCI_IRQ_MSIX)) == PCI_IRQ_MSIX) + if (msix_vecs == -ENOSPC || (flags & PCI_IRQ_MSI_TYPES) == PCI_IRQ_MSIX) return msix_vecs; return msi_vecs; } diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c index 50a9522ab07d..2a38a918ba12 100644 --- a/drivers/pci/pcie/portdrv_core.c +++ b/drivers/pci/pcie/portdrv_core.c @@ -105,7 +105,7 @@ static int pcie_port_enable_irq_vec(struct pci_dev *dev, int *irqs, int mask) /* Allocate the maximum possible number of MSI/MSI-X vectors */ nr_entries = pci_alloc_irq_vectors(dev, 1, PCIE_PORT_MAX_MSI_ENTRIES, - PCI_IRQ_MSIX | PCI_IRQ_MSI); + PCI_IRQ_MSI_TYPES); if (nr_entries < 0) return nr_entries; @@ -131,7 +131,7 @@ static int pcie_port_enable_irq_vec(struct pci_dev *dev, int *irqs, int mask) pci_free_irq_vectors(dev); nr_entries = pci_alloc_irq_vectors(dev, nvec, nvec, - PCI_IRQ_MSIX | PCI_IRQ_MSI); + PCI_IRQ_MSI_TYPES); if (nr_entries < 0) return nr_entries; } diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c index e69cac84b605..11fbe9c6b201 100644 --- a/drivers/pci/switch/switchtec.c +++ b/drivers/pci/switch/switchtec.c @@ -1442,8 +1442,7 @@ static int switchtec_init_isr(struct switchtec_dev *stdev) nirqs = 4; nvecs = pci_alloc_irq_vectors(stdev->pdev, 1, nirqs, - PCI_IRQ_MSIX | PCI_IRQ_MSI | - PCI_IRQ_VIRTUAL); + PCI_IRQ_MSI_TYPES | PCI_IRQ_VIRTUAL); if (nvecs < 0) return nvecs; -- 2.17.2
[PATCH v2 05/15] crypto: inside-secure - Use PCI_IRQ_MSI_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
Reviewed-by: Antoine Tenart
Acked-by: Herbert Xu
---
drivers/crypto/inside-secure/safexcel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/inside-secure/safexcel.c
b/drivers/crypto/inside-secure/safexcel.c
index 2cb53fbae841..1b2faa2a6ab0 100644
--- a/drivers/crypto/inside-secure/safexcel.c
+++ b/drivers/crypto/inside-secure/safexcel.c
@@ -1567,7 +1567,7 @@ static int safexcel_probe_generic(void *pdev,
ret = pci_alloc_irq_vectors(pci_pdev,
priv->config.rings + 1,
priv->config.rings + 1,
- PCI_IRQ_MSI | PCI_IRQ_MSIX);
+ PCI_IRQ_MSI_TYPES);
if (ret < 0) {
dev_err(dev, "Failed to allocate PCI MSI interrupts\n");
return ret;
--
2.17.2
[PATCH v2 04/15] ahci: Use PCI_IRQ_MSI_TYPES where appropriate
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/ata/ahci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 0c0a736eb861..ca1bf4ef0f17 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1556,7 +1556,7 @@ static int ahci_init_msi(struct pci_dev *pdev, unsigned
int n_ports,
*/
if (n_ports > 1) {
nvec = pci_alloc_irq_vectors(pdev, n_ports, INT_MAX,
- PCI_IRQ_MSIX | PCI_IRQ_MSI);
+ PCI_IRQ_MSI_TYPES);
if (nvec > 0) {
if (!(readl(hpriv->mmio + HOST_CTL) & HOST_MRSM)) {
hpriv->get_irq_vector = ahci_get_irq_vector;
--
2.17.2
arm64 build issue and mainline crash (was Re: linux-next: Tree for Jun 3)
On 03/06/2020 12:06, Stephen Rothwell wrote:
JFYI, I am finding the vanilla defconfig build broken for arm64:
LD vmlinux.o
/home/john/gcc-linaro-7.5.0-2019.12-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-ld:
cannot find ./drivers/firmware/efi/libstub/lib.abuilt-in.a: No such file
or directory
make[1]: *** [vmlinux] Error 1
make: *** [__sub-make] Error 2
john@htsatcamb-server:~/linux-next$
In addition, the reason I was testing this was because Linus' master
(d6f9469a03d8 Merge tag 'erofs-for-5.8-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs) was crashing:
[ 5.368948] loop: module loaded
[ 5.372113] Unable to handle kernel paging request at virtual address
f9ffcfec4000
[ 5.380067] Mem abort info:
[ 5.382865]ESR = 0x9644
[ 5.385927]EC = 0x25: DABT (current EL), IL = 32 bits
[ 5.391260]SET = 0, FnV = 0
[ 5.394319]EA = 0, S1PTW = 0
[ 5.397467] Data abort info:
[ 5.400354]ISV = 0, ISS = 0x0044
[ 5.404203]CM = 0, WnR = 1
[ 5.407178] swapper pgtable: 4k pages, 48-bit VAs, pgdp=2f3f1000
[ 5.413909] [f9ffcfec4000] pgd=
[ 5.418807] Internal error: Oops: 9644 [#1] PREEMPT SMP
[ 5.424399] Modules linked in:
[ 5.427462] CPU: 11 PID: 1 Comm: swapper/0 Not tainted
5.7.0-05047-gd6f9469a03d8 #388
[ 5.435325] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05
IT21 Nemo 2.0 RC0 04/18/2018
[ 5.99] pstate: 4005 (nZcv daif -PAN -UAO BTYPE=--)
[ 5.450098] pc : __memset+0x16c/0x1c0
[ 5.453770] lr : pcpu_alloc+0x1a0/0x668
[ 5.457615] sp : 800011d3bbd0
[ 5.460936] x29: 800011d3bbd0 x28: 001fb5495180
[ 5.466267] x27: 0001 x26: 0100
[ 5.471597] x25: 0001 x24: 0001
[ 5.476928] x23: 80001135e9a0 x22: 80001196a200
[ 5.482259] x21: 80001196a360 x20:
[ 5.487590] x19: x18: fe107e6fdb08
[ 5.492920] x17: 003f x16:
[ 5.498251] x15: 001ffbffee00 x14: 0002
[ 5.503581] x13: x12: 003f
[ 5.508912] x11: 0040 x10: 0040
[ 5.514243] x9 : x8 : f9ffcfec4000
[ 5.519573] x7 : x6 : 003f
[ 5.524904] x5 : 0040 x4 :
[ 5.530234] x3 : 0004 x2 : 00c0
[ 5.535565] x1 : x0 : f9ffcfec4000
[ 5.540896] Call trace:
[ 5.543344] __memset+0x16c/0x1c0
[ 5.54] __alloc_percpu+0x14/0x1c
[ 5.550338] alloc_workqueue+0x164/0x42c
[ 5.554273] init+0x24/0xa4
[ 5.557071] do_one_initcall+0x50/0x194
[ 5.560917] kernel_init_freeable+0x1e4/0x250
[ 5.565288] kernel_init+0x10/0x104
[ 5.568785] ret_from_fork+0x10/0x18
[ 5.572372] Code: 91010108 544a 8b040108 cb050042 (d50b7428)
[ 5.578568] ---[ end trace 63c299bbe9b8ea9e ]---
[ 5.583205] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[ 5.590903] SMP: stopping secondary CPUs
[ 5.594846] Kernel Offset: 0xf from 0x80001000
[ 5.600350] PHYS_OFFSET: 0x0
[ 5.603235] CPU features: 0x240022,20806008
[ 5.607430] Memory Limit: none
[ 5.610500] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b ]---
I'll check that when I get a chance. Maybe all just transient.
Thanks
Hi all,
News: The merge window has opened, so please do *not* add v5.9 material
to your linux-next included branches until after v5.8-rc1 has been
released.
Changes since 20200602:
New tree: sh-rf
My fixes tree contains:
4cb4bfffe2c1 ("device_cgroup: Fix RCU list debugging warning")
The drm-intel-fixes tree gained a conflict against Linus' tree.
The overlayfs tree gained a build failure for which I applied a patch.
The v4l-dvb-next tree gained a conflict against the v4l-dvb tree and a
build failure so I used the version from next-20200602.
The drm-msm tree lost its build failure.
The akpm-current tree gained a conflict against Linus' tree.
The akpm tree lost its build failure and gained conflicts against the
kselftest and powerpc trees.
Non-merge commits (relative to Linus' tree): 10845
11211 files changed, 689281 insertions(+), 199935 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of
Re: [PATCH v5 0/4] Introduce TEE based Trusted Keys support
On Wed, 3 Jun 2020 at 14:20, Luke Hinds wrote: > > > > On Wed, Jun 3, 2020 at 9:08 AM Sumit Garg wrote: >> >> On Tue, 2 Jun 2020 at 20:14, James Bottomley wrote: >> > >> > On Tue, 2020-06-02 at 19:48 +0530, Sumit Garg wrote: >> > > Add support for TEE based trusted keys where TEE provides the >> > > functionality to seal and unseal trusted keys using hardware unique >> > > key. Also, this is an alternative in case platform doesn't possess a >> > > TPM device. >> > >> > So here's a meta problem: in the case when the platform possesses both >> > TEE and TPM what should it do? >> >> IMO, trust source (either a TPM or a TEE) should be unique and >> carefully chosen as per platform security policy corresponding to a >> particular threat model. >> >> And moreover TEEs have been mostly used in the embedded world where >> having a hardware TPM is cumbersome given constraints regarding BoM >> cost and hardware resources. >> >> > Things like this: >> > >> > > --- a/security/keys/trusted-keys/trusted_core.c >> > > +++ b/security/keys/trusted-keys/trusted_core.c >> > > @@ -25,6 +25,8 @@ >> > > >> > > #if defined(CONFIG_TRUSTED_TPM) >> > > static struct trusted_key_ops *trusted_key_ops = >> > > _trusted_key_ops; >> > > +#elif defined(CONFIG_TRUSTED_TEE) >> > > +static struct trusted_key_ops *trusted_key_ops = >> > > _trusted_key_ops; >> > > #else >> > >> > Say it's either/or at a Kconfig level: so if you select both TEE and >> > TPM based trusted keys at compile time, we intall the TPM ops and >> > ignore the TEE ops, is that right? Surely this should be runtime >> > selectable based on what the platform has ... >> >> This dynamic selection was already part of v4 patch-set but after >> objection from Jarrko here [1], I switched to compile time mode >> instead. >> >> [1] https://lkml.org/lkml/2020/6/2/139 > > > Unless I have misunderstood, my concerns about compile time are that > distributors will be cornered into releasing kernels with an opinionated > selection of either TEE or TPM and any users needing the non default will > need to compile their own kernel. > I echo with your concerns. Jarrko, If it's fine with you then I can switch back to dynamic approach again in the next version. -Sumit >> >> >> > perhaps it should even be >> > selectable per key? >> > >> > Once it is runtime selectable, what should be selected in the both >> > case? Or should we allow the user to decide, if so, how? >> > >> > when you pipe a trusted key, I think the subtype (TEE or TPM) should be >> > part of the piped information, so it loads again seamlessly. This >> > would actually be fixed by something like the ASN.1 scheme I'm trying >> > to upstream, at least for TPM keys, but do TEE keys have a recognized >> > ASN.1 format? >> > >> >> I guess this is something which we can refine later if there are real >> platforms that have a particular security requirement to support both >> TPM and a TEE. >> >> -Sumit >> >> > James >> > >> >
[PATCH v2 01/15] PCI/MSI: Forward MSI-X vector enable error code in pci_alloc_irq_vectors_affinity()
When debugging an issue where I was asking the PCI machinery to enable a set of MSI-X vectors, without falling back on MSI, I ran across a behaviour which seems odd. The pci_alloc_irq_vectors_affinity() will always return -ENOSPC on failure, when allocating MSI-X vectors only, whereas with MSI fallback it will forward any error returned by __pci_enable_msi_range(). This is a confusing behaviour, so have the pci_alloc_irq_vectors_affinity() forward the error code from __pci_enable_msix_range() when appropriate. Signed-off-by: Piotr Stankiewicz Reviewed-by: Andy Shevchenko --- drivers/pci/msi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index 6b43a5455c7a..443cc324b196 100644 --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -1231,8 +1231,9 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs, } } - if (msix_vecs == -ENOSPC) - return -ENOSPC; + if (msix_vecs == -ENOSPC || + (flags & (PCI_IRQ_MSI | PCI_IRQ_MSIX)) == PCI_IRQ_MSIX) + return msix_vecs; return msi_vecs; } EXPORT_SYMBOL(pci_alloc_irq_vectors_affinity); -- 2.17.2
Re: [PATCH] usb: host: xhci-mtk: avoid runtime suspend when removing hcd
On 29.5.2020 7.29, Macpaul Lin wrote: > When runtime suspend was enabled, runtime suspend might happened > when xhci is removing hcd. This might cause kernel panic when hcd > has been freed but runtime pm suspend related handle need to > reference it. > > Change-Id: I70a5dc8006207caeecbac6955ce8e5345dcc70e6 > Signed-off-by: Macpaul Lin > --- > drivers/usb/host/xhci-mtk.c |5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c > index bfbdb3c..641d24e 100644 > --- a/drivers/usb/host/xhci-mtk.c > +++ b/drivers/usb/host/xhci-mtk.c > @@ -587,6 +587,9 @@ static int xhci_mtk_remove(struct platform_device *dev) > struct xhci_hcd *xhci = hcd_to_xhci(hcd); > struct usb_hcd *shared_hcd = xhci->shared_hcd; > > + pm_runtime_put_sync(>dev); Might runtime suspend here. It's a lot better than before, no panic as hcd isn't released, but a bit unnecessary. how about this sequence instead: pm_runtime_disable() pm_runtime_put_noidle() > + pm_runtime_disable(>dev); > + -Mathias
Re: [PATCH] ASoC: max98390: Fix potential crash during param fw loading
On Wed, Jun 03, 2020 at 11:37:44AM +, Steve Lee wrote:
> > This is now reading the size out of the header of the file which is good
> > but it
> > should also validate that the file is big enough to have this much data in
> > it,
> > otherwise it's possible to read beyond the end of the firmware file (eg, if
> > it got
> > truncated somehow). Previously the code used the size of the file read
> > from disk
> > so that wasn't an issue.
> Thanks for quick comment. Can this case cover by below line?
> + if (fw->size < MAX98390_DSM_PARAM_MIN_SIZE) {
> + dev_err(component->dev,
> + "param fw is invalid.\n");
> + goto err_alloc;
> + }
No, that doesn't cover all of it - the case I'm concerned about is the
case where we've got enough data for the header but the payload is
truncated. You need a check that param_size + _PAYLOAD_OFFSET is less
than fw->size as well.
signature.asc
Description: PGP signature
[PATCH 9/9] x86/entry, cpumask: Provide non-instrumented variant of cpu_is_offline()
vmlinux.o: warning: objtool: exc_nmi()+0x12: call to
cpumask_test_cpu.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: mce_check_crashing_cpu()+0x12: call to
cpumask_test_cpu.constprop.0()leaves .noinstr.text section
cpumask_test_cpu()
test_bit()
instrument_atomic_read()
arch_test_bit()
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/kernel/cpu/mce/core.c |2 +-
arch/x86/kernel/nmi.c |2 +-
include/linux/cpumask.h| 15 ++-
3 files changed, 16 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1083,7 +1083,7 @@ static noinstr bool mce_check_crashing_c
{
unsigned int cpu = smp_processor_id();
- if (cpu_is_offline(cpu) ||
+ if (arch_cpu_is_offline(cpu) ||
(crashing_cpu != -1 && crashing_cpu != cpu)) {
u64 mcgstatus;
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -478,7 +478,7 @@ static DEFINE_PER_CPU(unsigned long, nmi
DEFINE_IDTENTRY_NMI(exc_nmi)
{
- if (IS_ENABLED(CONFIG_SMP) && cpu_is_offline(smp_processor_id()))
+ if (IS_ENABLED(CONFIG_SMP) && arch_cpu_is_offline(smp_processor_id()))
return;
if (this_cpu_read(nmi_state) != NMI_NOT_RUNNING) {
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -888,7 +888,20 @@ static inline const struct cpumask *get_
return to_cpumask(p);
}
-#define cpu_is_offline(cpu)unlikely(!cpu_online(cpu))
+#if NR_CPUS > 1
+static __always_inline bool arch_cpu_online(int cpu)
+{
+ return arch_test_bit(cpu, cpumask_bits(cpu_online_mask));
+}
+#else
+static __always_inline bool arch_cpu_online(int cpu)
+{
+ return cpu == 0;
+}
+#endif
+
+#define arch_cpu_is_offline(cpu) unlikely(!arch_cpu_online(cpu))
+#define cpu_is_offline(cpu)unlikely(!cpu_online(cpu))
#if NR_CPUS <= BITS_PER_LONG
#define CPU_BITS_ALL \
