Re: [PATCH 1/2] dccp: ccid: move timers to struct dccp_sock
On 13/10/2020 19:18, Kleber Sacilotto de Souza wrote: > From: Thadeu Lima de Souza Cascardo > > When dccps_hc_tx_ccid is freed, ccid timers may still trigger. The reason > del_timer_sync can't be used is because this relies on keeping a reference > to struct sock. But as we keep a pointer to dccps_hc_tx_ccid and free that > during disconnect, the timer should really belong to struct dccp_sock. > > This addresses CVE-2020-16119. > > Fixes: 839a6094140a (net: dccp: Convert timers to use timer_setup()) > Signed-off-by: Thadeu Lima de Souza Cascardo > Signed-off-by: Kleber Sacilotto de Souza Acked-bd: Richard Sailer Implementation and concept looks fine to me signature.asc Description: OpenPGP digital signature
Re: [PATCH RFC V3 9/9] x86/pks: Add PKS test code
On 10/9/20 12:42 PM, ira.we...@intel.com wrote:
> #ifdef CONFIG_X86_32
> /*
>* We can fault-in kernel-space virtual memory on-demand. The
> diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h
> index cc3510cde64e..f9552bd9341f 100644
> --- a/include/linux/pkeys.h
> +++ b/include/linux/pkeys.h
> @@ -47,7 +47,6 @@ static inline bool arch_pkeys_enabled(void)
> static inline void copy_init_pkru_to_fpregs(void)
> {
> }
> -
> #endif /* ! CONFIG_ARCH_HAS_PKEYS */
^ Whitespace damage
> #ifndef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 0c781f912f9f..f015c09ba5a1 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -2400,6 +2400,18 @@ config HYPERV_TESTING
> help
> Select this option to enable Hyper-V vmbus testing.
>
> +config PKS_TESTING
> + bool "PKey(S)upervisor testing"
Seems like we need a space in there somewhere.
> + pid = fork();
> + if (pid == 0) {
> + fd = open("/sys/kernel/debug/x86/run_pks", O_RDWR);
> + if (fd < 0) {
> + printf("cannot open file\n");
> + return -1;
> + }
> +
Will this return code make anybody mad? Should we have a nicer return
code for when this is running on non-PKS hardware?
I'm not going to be too picky about this. I'll just ask one question:
Has this found real bugs for you?
Reviewed-by: Dave Hansen
Re: [PATCH 2/2] Revert "dccp: don't free ccid2_hc_tx_sock struct in dccp_disconnect()"
On 13/10/2020 19:18, Kleber Sacilotto de Souza wrote: > rom: Thadeu Lima de Souza Cascardo > > This reverts commit 2677d20677314101293e6da0094ede7b5526d2b1. > > This fixes an issue that after disconnect, dccps_hc_tx_ccid will still be > kept, allowing the socket to be reused as a listener socket, and the cloned > socket will free its dccps_hc_tx_ccid, leading to a later use after free, > when the listener socket is closed. > > This addresses CVE-2020-16119. > > Fixes: 2677d2067731 (dccp: don't free ccid2_hc_tx_sock struct in > dccp_disconnect()) > Reported-by: Hadar Manor > Signed-off-by: Thadeu Lima de Souza Cascardo > Signed-off-by: Kleber Sacilotto de Souza > --- Acked-by: Richard Sailer signature.asc Description: OpenPGP digital signature
Re: Unbreakable loop in fuse_fill_write_pages()
On Tue, Oct 13, 2020 at 02:40:26PM -0400, Vivek Goyal wrote: > On Tue, Oct 13, 2020 at 01:11:05PM -0400, Qian Cai wrote: > > Running some fuzzing on virtiofs with an unprivileged user on today's > > linux-next > > could trigger soft-lockups below. > > > > # virtiofsd --socket-path=/tmp/vhostqemu -o source=$TESTDIR -o cache=always > > -o no_posix_lock > > > > Basically, everything was blocking on inode_lock(inode) because one thread > > (trinity-c33) was holding it but stuck in the loop in > > fuse_fill_write_pages() > > and unable to exit for more than 10 minutes before I executed sysrq-t. > > Afterwards, the systems was totally unresponsive: > > > > kernel:NMI watchdog: Watchdog detected hard LOCKUP on cpu 8 > > > > To exit the loop, it needs, > > > > iov_iter_advance(ii, tmp) to set "tmp" to non-zero for each iteration. > > > > and > > > > } while (iov_iter_count(ii) && count < fc->max_write && > > ap->num_pages < max_pages && offset == 0); > > > > == the thread is stuck in the loop == > > [10813.290694] task:trinity-c33 state:D stack:25888 pid:254219 ppid: > > 87180 > > flags:0x4004 > > [10813.292671] Call Trace: > > [10813.293379] __schedule+0x71d/0x1b50 > > [10813.294182] ? __sched_text_start+0x8/0x8 > > [10813.295146] ? mark_held_locks+0xb0/0x110 > > [10813.296117] schedule+0xbf/0x270 > > [10813.296782] ? __lock_page_killable+0x276/0x830 > > [10813.297867] io_schedule+0x17/0x60 > > [10813.298772] __lock_page_killable+0x33b/0x830 > > This seems to suggest that filemap_fault() is blocked on page lock and > is sleeping. For some reason it never wakes up. Not sure why. > > And this will be called from. > > fuse_fill_write_pages() >iov_iter_fault_in_readable() > > So fuse code will take inode_lock() and then looks like same process > is sleeping waiting on page lock. And rest of the processes get blocked > behind inode lock. > > If we are woken up (while waiting on page lock), we should make forward > progress. Question is what page it is and why the entity which is > holding lock is not releasing lock. I am wondering if virtiofsd still alive and responding to requests? I see another task which is blocked on getdents() for more than 120s. [10580.142571][ T348] INFO: task trinity-c36:254165 blocked for more than 123 +seconds. [10580.143924][ T348] Tainted: G O 5.9.0-next-20201013+ #2 [10580.145158][ T348] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" +disables this message. [10580.146636][ T348] task:trinity-c36 state:D stack:26704 pid:254165 ppid: +87180 flags:0x0004 [10580.148260][ T348] Call Trace: [10580.148789][ T348] __schedule+0x71d/0x1b50 [10580.149532][ T348] ? __sched_text_start+0x8/0x8 [10580.150343][ T348] schedule+0xbf/0x270 [10580.151044][ T348] schedule_preempt_disabled+0xc/0x20 [10580.152006][ T348] __mutex_lock+0x9f1/0x1360 [10580.152777][ T348] ? __fdget_pos+0x9c/0xb0 [10580.153484][ T348] ? mutex_lock_io_nested+0x1240/0x1240 [10580.154432][ T348] ? find_held_lock+0x33/0x1c0 [10580.155220][ T348] ? __fdget_pos+0x9c/0xb0 [10580.155934][ T348] __fdget_pos+0x9c/0xb0 [10580.156660][ T348] __x64_sys_getdents+0xff/0x230 May be virtiofsd crashed and hence no requests are completing leading to a hard lockup? Vivek
Re: [PATCH v5 4/5] docs: counter: Document character device interface
On Mon, Oct 12, 2020 at 12:04:10PM -0500, David Lechner wrote:
> On 10/8/20 7:28 AM, William Breathitt Gray wrote:
> > On Thu, Oct 08, 2020 at 10:09:09AM +0200, Pavel Machek wrote:
> >> Hi!
> >>
> >>> +int main(void)
> >>> +{
> >>> +struct pollfd pfd = { .events = POLLIN };
> >>> +struct counter_event event_data[2];
> >>> +
> >>> +pfd.fd = open("/dev/counter0", O_RDWR);
> >>> +
> >>> +ioctl(pfd.fd, COUNTER_SET_WATCH_IOCTL, watches);
> >>> +ioctl(pfd.fd, COUNTER_SET_WATCH_IOCTL, watches + 1);
> >>> +ioctl(pfd.fd, COUNTER_LOAD_WATCHES_IOCTL);
> >>> +
> >>> +for (;;) {
> >>> +poll(, 1, -1);
> >>
> >> Why do poll, when you are doing blocking read?
> >>
> >>> +read(pfd.fd, event_data, sizeof(event_data));
> >>
> >> Does your new chrdev always guarantee returning complete buffer?
> >>
> >> If so, should it behave like that?
> >>
> >> Best regards,
> >>Pavel
> >> --
> >> (english) http://www.livejournal.com/~pavelmachek
> >> (cesky, pictures)
> >> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> >
> > I suppose you're right: a poll() should be redundant now with this
> > version of the character device implementation because buffers will
> > always return complete; so a blocking read() should achieve the same
> > behavior that a poll() with read() would.
> >
> > I'll give some more time for additional feedback to come in for this
> > version of the patchset, and then likely remove support for poll() in
> > the v6 submission.
> >
> > William Breathitt Gray
> >
>
> I hope that you mean that you will just remove it from the example
> and not from the chardev. Otherwise it won't be possible to
> integrate this with an event loop.
Would you elaborate a bit further on this? My thought process is that
because users must set the Counter Events they want to watch, and only
those Counter Events show up in the character device node, a blocking
read() would effectively behave the same as poll() with read(); if none
of the Counter Events occur, the read() just blocks until one does, thus
making the use of a poll() call redundant.
William Breathitt Gray
signature.asc
Description: PGP signature
Re: [PATCH RFC V3 8/9] x86/fault: Report the PKRS state on fault
> @@ -548,6 +549,11 @@ show_fault_oops(struct pt_regs *regs, unsigned long
> error_code, unsigned long ad
>(error_code & X86_PF_PK)? "protection keys violation" :
> "permissions violation");
>
> +#ifdef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS
> + if (irq_state && (error_code & X86_PF_PK))
> + pr_alert("PKRS: 0x%x\n", irq_state->pkrs);
> +#endif
This means everyone will see 'PKRS: 0x0', even if they're on non-PKS
hardware. I think I'd rather have this only show PKRS when we're on
cpu_feature_enabled(PKS) hardware.
...
> @@ -1148,14 +1156,15 @@ static int fault_in_kernel_space(unsigned long
> address)
> */
> static void
> do_kern_addr_fault(struct pt_regs *regs, unsigned long hw_error_code,
> -unsigned long address)
> +unsigned long address, irqentry_state_t *irq_state)
> {
> /*
> - * Protection keys exceptions only happen on user pages. We
> - * have no user pages in the kernel portion of the address
> - * space, so do not expect them here.
> + * If protection keys are not enabled for kernel space
> + * do not expect Pkey errors here.
>*/
Let's fix the double-negative:
/*
* PF_PK is only expected on kernel addresses whenn
* supervisor pkeys are enabled:
*/
> - WARN_ON_ONCE(hw_error_code & X86_PF_PK);
> + if (!IS_ENABLED(CONFIG_ARCH_HAS_SUPERVISOR_PKEYS) ||
> + !cpu_feature_enabled(X86_FEATURE_PKS))
> + WARN_ON_ONCE(hw_error_code & X86_PF_PK);
Yeah, please stick X86_FEATURE_PKS in disabled-features so you can use
cpu_feature_enabled(X86_FEATURE_PKS) by itself here..
Re: ACPI _CST introduced performance regresions on Haswll
On 10/8/2020 7:34 PM, Mel Gorman wrote: On Thu, Oct 08, 2020 at 07:15:46PM +0200, Rafael J. Wysocki wrote: Force enabling C6 ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state0/disable:0 ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state1/disable:0 ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state2/disable:0 ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state3/disable:1 ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state4/disable:0 ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state0/default_status:enabled ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state1/default_status:enabled ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state2/default_status:enabled ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state3/default_status:disabled ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state4/default_status:enabled Note that as expected, C3 remains disabled when only C6 is forced (state3 == c3, state4 == c6). While this particular workload does not appear to care as it does not remain idle for long, the exit latency difference between c3 and c6 is large so potentially a workload that idles for short durations that are somewhere between c1e and c3 exit latency might take a larger penalty exiting from c6 state if the deeper c-state is selected for idling. ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state0/residency:0 ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state1/residency:2 ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state2/residency:20 ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state3/residency:100 ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state4/residency:400 If you are worried that C6 might be used instead of C3 in some cases, this is not going to happen. Ok, so it goes in the C1E direction instead. I lost track of how C-state is selected based on predictions about the future. It's changed a bit over time. I all cases in which C3 would have been used had it not been disabled, C1E will be used instead. Which BTW indicates that using C1E more often adds a lot of latency to the workload (if C3 and C6 are both disabled, C1E is used in all cases in which one of them would have been used). Which is weird. From the exit latency alone, I'd think it would be faster to use C1E instead of C3. It implies that using C1E instead of C3/C6 has some other side-effect on Haswell. At one point, there was plenty of advice on disabling C1E but very little concrete information on what impact it has exactly and why it might cause problems that other c-states avoid. With C6 enabled, that state is used at least sometimes (so C1E is used less often), but PC6 doesn't seem to be really used - it looks like core C6 only is entered and which may be why C6 adds less latency than C1E (and analogously for C3). At the moment, I'm happy with either solution but mostly because I can't tell what other trade-offs should be considered :/ I talked to Len and Srinivas about this and my theory above didn't survive. The most likely reason why you see a performance drop after enabling the ACPI support (which effectively causes C3 and C6 to be disabled by default on the affected machines) is because the benchmarks in question require sufficiently high one-CPU performance and the CPUs cannot reach high enough one-core turbo P-states without the other CPUs going into C6. Inspection of the ACPI tables you sent me indicates that there is a BIOS switch in that system allowing C6 to be enabled. Would it be possible to check whether or not there is a BIOS setup option to change that setting? Also, I need to know what happens if that system is started with intel_idle disabled. That is, what idle states are visible in sysfs in that configuration (what their names and descriptions are in particular) and whether or not the issue is still present then. In addition to that, can you please run the benchmark on that system under turbostat both with unmodified intel_idle and with intel_idle disabled and post the turbostat output in each of those cases? Cheers!
Re: [PATCH RFC V3 7/9] x86/entry: Preserve PKRS MSR across exceptions
On 10/9/20 12:42 PM, ira.we...@intel.com wrote:
> @@ -341,6 +341,9 @@ noinstr void irqentry_enter(struct pt_regs *regs,
> irqentry_state_t *state)
> /* Use the combo lockdep/tracing function */
> trace_hardirqs_off();
> instrumentation_end();
> +
> +done:
> + irq_save_pkrs(state);
> }
One nit: This saves *and* sets PKRS. It's not obvious from the call
here that PKRS is altered at this site. Seems like there could be a
better name.
Even if we did:
irq_save_set_pkrs(state, INIT_VAL);
It would probably compile down to the same thing, but be *really*
obvious what's going on.
> void irqentry_exit_cond_resched(void)
> @@ -362,7 +365,12 @@ noinstr void irqentry_exit(struct pt_regs *regs,
> irqentry_state_t *state)
> /* Check whether this returns to user mode */
> if (user_mode(regs)) {
> irqentry_exit_to_user_mode(regs);
> - } else if (!regs_irqs_disabled(regs)) {
> + return;
> + }
> +
> + irq_restore_pkrs(state);
> +
> + if (!regs_irqs_disabled(regs)) {
> /*
>* If RCU was not watching on entry this needs to be done
>* carefully and needs the same ordering of lockdep/tracing
>
Re: [PATCH v4 3/6] drivers: hwmon: Add the iEi WT61P803 PUZZLE HWMON driver
On 10/13/20 11:09 AM, Luka Kovacic wrote:
> Hello Guenter,
>
> On Sun, Oct 11, 2020 at 11:26 PM Guenter Roeck wrote:
>>
>> On Wed, Oct 07, 2020 at 02:48:58AM +0200, Luka Kovacic wrote:
>>> Add the iEi WT61P803 PUZZLE HWMON driver, that handles the fan speed
>>> control via PWM, reading fan speed and reading on-board temperature
>>> sensors.
>>>
>>> The driver registers a HWMON device and a simple thermal cooling device to
>>> enable in-kernel fan management.
>>>
>>> This driver depends on the iEi WT61P803 PUZZLE MFD driver.
>>>
>>> Signed-off-by: Luka Kovacic
>>> Cc: Luka Perkov
>>> Cc: Robert Marko
>>> ---
>>> drivers/hwmon/Kconfig | 8 +
>>> drivers/hwmon/Makefile| 1 +
>>> drivers/hwmon/iei-wt61p803-puzzle-hwmon.c | 457 ++
>>> 3 files changed, 466 insertions(+)
>>> create mode 100644 drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
>>>
>>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>>> index 8dc28b26916e..ff279df9bf40 100644
>>> --- a/drivers/hwmon/Kconfig
>>> +++ b/drivers/hwmon/Kconfig
>>> @@ -722,6 +722,14 @@ config SENSORS_IBMPOWERNV
>>> This driver can also be built as a module. If so, the module
>>> will be called ibmpowernv.
>>>
>>> +config SENSORS_IEI_WT61P803_PUZZLE_HWMON
>>> + tristate "iEi WT61P803 PUZZLE MFD HWMON Driver"
>>> + depends on MFD_IEI_WT61P803_PUZZLE
>>> + help
>>> + The iEi WT61P803 PUZZLE MFD HWMON Driver handles reading fan speed
>>> + and writing fan PWM values. It also supports reading on-board
>>> + temperature sensors.
>>> +
>>> config SENSORS_IIO_HWMON
>>> tristate "Hwmon driver that uses channels specified via iio maps"
>>> depends on IIO
>>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>>> index a8f4b35b136b..b0afb2d6896f 100644
>>> --- a/drivers/hwmon/Makefile
>>> +++ b/drivers/hwmon/Makefile
>>> @@ -83,6 +83,7 @@ obj-$(CONFIG_SENSORS_HIH6130) += hih6130.o
>>> obj-$(CONFIG_SENSORS_ULTRA45)+= ultra45_env.o
>>> obj-$(CONFIG_SENSORS_I5500) += i5500_temp.o
>>> obj-$(CONFIG_SENSORS_I5K_AMB)+= i5k_amb.o
>>> +obj-$(CONFIG_SENSORS_IEI_WT61P803_PUZZLE_HWMON) +=
>>> iei-wt61p803-puzzle-hwmon.o
>>> obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o
>>> obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o
>>> obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
>>> diff --git a/drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
>>> b/drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
>>> new file mode 100644
>>> index ..be7b019d126c
>>> --- /dev/null
>>> +++ b/drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
>>> @@ -0,0 +1,457 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +/* iEi WT61P803 PUZZLE MCU HWMON Driver
>>> + *
>>> + * Copyright (C) 2020 Sartura Ltd.
>>> + * Author: Luka Kovacic
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#define IEI_WT61P803_PUZZLE_HWMON_MAX_TEMP_NUM 2
>>> +#define IEI_WT61P803_PUZZLE_HWMON_MAX_FAN_NUM 5
>>> +#define IEI_WT61P803_PUZZLE_HWMON_MAX_PWM_NUM 2
>>> +#define IEI_WT61P803_PUZZLE_HWMON_MAX_PWM_VAL 255
>>> +
>>> +/**
>>> + * struct iei_wt61p803_puzzle_thermal_cooling_device - Thermal cooling
>>> device instance
>>> + *
>>> + * @mcu_hwmon: MCU HWMON struct pointer
>>> + * @tcdev: Thermal cooling device pointer
>>> + * @name:Thermal cooling device name
>>> + * @pwm_channel: PWM channel (0 or 1)
>>> + * @cooling_levels: Thermal cooling device cooling levels
>>> + */
>>> +struct iei_wt61p803_puzzle_thermal_cooling_device {
>>> + struct iei_wt61p803_puzzle_hwmon *mcu_hwmon;
>>> + struct thermal_cooling_device *tcdev;
>>> + char name[THERMAL_NAME_LENGTH];
>>> + int pwm_channel;
>>> + u8 *cooling_levels;
>>> +};
>>> +
>>> +/**
>>> + * struct iei_wt61p803_puzzle_hwmon - MCU HWMON Driver
>>> + *
>>> + * @mcu: MCU struct pointer
>>> + * @response_buffer Global MCU response buffer allocation
>>> + * @thermal_cooling_dev_present: Per-channel thermal cooling device
>>> control
>>> + * @cdev:Per-channel thermal cooling device
>>> private structure
>>> + */
>>> +struct iei_wt61p803_puzzle_hwmon {
>>> + struct iei_wt61p803_puzzle *mcu;
>>> + unsigned char *response_buffer;
>>> + bool
>>> thermal_cooling_dev_present[IEI_WT61P803_PUZZLE_HWMON_MAX_PWM_NUM];
>>> + struct iei_wt61p803_puzzle_thermal_cooling_device
>>> + *cdev[IEI_WT61P803_PUZZLE_HWMON_MAX_PWM_NUM];
>>> +};
>>> +
>>> +#define raw_temp_to_milidegree_celsius(x) ((int)(((x) - 0x80) * 1000))
>>> +static int iei_wt61p803_puzzle_read_temp_sensor(struct
>>> iei_wt61p803_puzzle_hwmon *mcu_hwmon,
>>> + int channel, int *value)
>>> +{
>>> + unsigned char *resp_buf =
Re: [PATCH v6 68/80] nl80211: docs: add a description for s1g_cap parameter
Thanks Mauro.
On Tue, 2020-10-13 at 13:54 +0200, Mauro Carvalho Chehab wrote:
> Changeset df78a0c0b67d ("nl80211: S1G band and channel definitions")
> added a new parameter, but didn't add the corresponding kernel-doc
> markup, as repoted when doing "make htmldocs":
>
> ./include/net/cfg80211.h:471: warning: Function parameter or member
> 's1g_cap' not described in 'ieee80211_supported_band'
>
> Add a documentation for it.
Should I take this through my tree, or is that part of a larger set
that'll go somewhere else?
johannes
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Fri, Oct 9, 2020 at 12:52 PM wrote:
>
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
> ---
> fs/cramfs/inode.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 912308600d39..003c014a42ed 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block *sb,
> unsigned int offset,
> struct page *page = pages[i];
>
> if (page) {
> - memcpy(data, kmap(page), PAGE_SIZE);
> - kunmap(page);
> + memcpy(data, kmap_thread(page), PAGE_SIZE);
> + kunmap_thread(page);
Why does this need a sleepable kmap? This looks like a textbook
kmap_atomic() use case.
Re: [PATCH RFC V3 5/9] x86/pks: Add PKS kernel API
> +static inline void pks_update_protection(int pkey, unsigned long protection)
> +{
> + current->thread.saved_pkrs = update_pkey_val(current->thread.saved_pkrs,
> + pkey, protection);
> + preempt_disable();
> + write_pkrs(current->thread.saved_pkrs);
> + preempt_enable();
> +}
Why does this need preempt count manipulation in addition to the
get/put_cpu_var() inside of write_pkrs()?
> +/**
> + * PKS access control functions
> + *
> + * Change the access of the domain specified by the pkey. These are global
> + * updates. They only affects the current running thread. It is undefined
> and
> + * a bug for users to call this without having allocated a pkey and using it
> as
> + * pkey here.
> + *
> + * pks_mknoaccess()
> + * Disable all access to the domain
> + * pks_mkread()
> + * Make the domain Read only
> + * pks_mkrdwr()
> + * Make the domain Read/Write
> + *
> + * @pkey the pkey for which the access should change.
> + *
> + */
> +void pks_mknoaccess(int pkey)
> +{
> + pks_update_protection(pkey, PKEY_DISABLE_ACCESS);
> +}
> +EXPORT_SYMBOL_GPL(pks_mknoaccess);
These are named like PTE manipulation functions, which is kinda weird.
What's wrong with: pks_disable_access(pkey) ?
> +void pks_mkread(int pkey)
> +{
> + pks_update_protection(pkey, PKEY_DISABLE_WRITE);
> +}
> +EXPORT_SYMBOL_GPL(pks_mkread);
I really don't like this name. It doesn't make readable, or even
read-only, *especially* if it was already access-disabled.
> +static const char pks_key_user0[] = "kernel";
> +
> +/* Store names of allocated keys for debug. Key 0 is reserved for the
> kernel. */
> +static const char *pks_key_users[PKS_NUM_KEYS] = {
> + pks_key_user0
> +};
> +
> +/*
> + * Each key is represented by a bit. Bit 0 is set for key 0 and reserved for
> + * its use. We use ulong for the bit operations but only 16 bits are used.
> + */
> +static unsigned long pks_key_allocation_map = 1 << PKS_KERN_DEFAULT_KEY;
> +
> +/*
> + * pks_key_alloc - Allocate a PKS key
> + *
> + * @pkey_user: String stored for debugging of key exhaustion. The caller is
> + * responsible to maintain this memory until pks_key_free().
> + */
> +int pks_key_alloc(const char * const pkey_user)
> +{
> + int nr;
> +
> + if (!cpu_feature_enabled(X86_FEATURE_PKS))
> + return -EINVAL;
I'm not sure I like -EINVAL for this. I thought we returned -ENOSPC for
this case for user pkeys.
> + while (1) {
> + nr = find_first_zero_bit(_key_allocation_map, PKS_NUM_KEYS);
> + if (nr >= PKS_NUM_KEYS) {
> + pr_info("Cannot allocate supervisor key for %s.\n",
> + pkey_user);
> + return -ENOSPC;
> + }
> + if (!test_and_set_bit_lock(nr, _key_allocation_map))
> + break;
> + }
> +
> + /* for debugging key exhaustion */
> + pks_key_users[nr] = pkey_user;
> +
> + return nr;
> +}
> +EXPORT_SYMBOL_GPL(pks_key_alloc);
> +
> +/*
> + * pks_key_free - Free a previously allocate PKS key
> + *
> + * @pkey: Key to be free'ed
> + */
> +void pks_key_free(int pkey)
> +{
> + if (!cpu_feature_enabled(X86_FEATURE_PKS))
> + return;
> +
> + if (pkey >= PKS_NUM_KEYS || pkey <= PKS_KERN_DEFAULT_KEY)
> + return;
This seems worthy of a WARN_ON_ONCE() at least. It's essentially
corrupt data coming into a kernel API.
Re: [PATCH RFC PKS/PMEM 33/58] fs/cramfs: Utilize new kmap_thread()
On Fri, 9 Oct 2020, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
Acked-by: Nicolas Pitre
> fs/cramfs/inode.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 912308600d39..003c014a42ed 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -247,8 +247,8 @@ static void *cramfs_blkdev_read(struct super_block *sb,
> unsigned int offset,
> struct page *page = pages[i];
>
> if (page) {
> - memcpy(data, kmap(page), PAGE_SIZE);
> - kunmap(page);
> + memcpy(data, kmap_thread(page), PAGE_SIZE);
> + kunmap_thread(page);
> put_page(page);
> } else
> memset(data, 0, PAGE_SIZE);
> @@ -826,7 +826,7 @@ static int cramfs_readpage(struct file *file, struct page
> *page)
>
> maxblock = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> bytes_filled = 0;
> - pgdata = kmap(page);
> + pgdata = kmap_thread(page);
>
> if (page->index < maxblock) {
> struct super_block *sb = inode->i_sb;
> @@ -914,13 +914,13 @@ static int cramfs_readpage(struct file *file, struct
> page *page)
>
> memset(pgdata + bytes_filled, 0, PAGE_SIZE - bytes_filled);
> flush_dcache_page(page);
> - kunmap(page);
> + kunmap_thread(page);
> SetPageUptodate(page);
> unlock_page(page);
> return 0;
>
> err:
> - kunmap(page);
> + kunmap_thread(page);
> ClearPageUptodate(page);
> SetPageError(page);
> unlock_page(page);
> --
> 2.28.0.rc0.12.gb6a658bd00c9
>
>
Re: Unbreakable loop in fuse_fill_write_pages()
On Tue, Oct 13, 2020 at 01:11:05PM -0400, Qian Cai wrote: > Running some fuzzing on virtiofs with an unprivileged user on today's > linux-next > could trigger soft-lockups below. > > # virtiofsd --socket-path=/tmp/vhostqemu -o source=$TESTDIR -o cache=always > -o no_posix_lock > > Basically, everything was blocking on inode_lock(inode) because one thread > (trinity-c33) was holding it but stuck in the loop in fuse_fill_write_pages() > and unable to exit for more than 10 minutes before I executed sysrq-t. > Afterwards, the systems was totally unresponsive: > > kernel:NMI watchdog: Watchdog detected hard LOCKUP on cpu 8 > > To exit the loop, it needs, > > iov_iter_advance(ii, tmp) to set "tmp" to non-zero for each iteration. > > and > > } while (iov_iter_count(ii) && count < fc->max_write && >ap->num_pages < max_pages && offset == 0); > > == the thread is stuck in the loop == > [10813.290694] task:trinity-c33 state:D stack:25888 pid:254219 ppid: 87180 > flags:0x4004 > [10813.292671] Call Trace: > [10813.293379] __schedule+0x71d/0x1b50 > [10813.294182] ? __sched_text_start+0x8/0x8 > [10813.295146] ? mark_held_locks+0xb0/0x110 > [10813.296117] schedule+0xbf/0x270 > [10813.296782] ? __lock_page_killable+0x276/0x830 > [10813.297867] io_schedule+0x17/0x60 > [10813.298772] __lock_page_killable+0x33b/0x830 This seems to suggest that filemap_fault() is blocked on page lock and is sleeping. For some reason it never wakes up. Not sure why. And this will be called from. fuse_fill_write_pages() iov_iter_fault_in_readable() So fuse code will take inode_lock() and then looks like same process is sleeping waiting on page lock. And rest of the processes get blocked behind inode lock. If we are woken up (while waiting on page lock), we should make forward progress. Question is what page it is and why the entity which is holding lock is not releasing lock. Thanks Vivek > [10813.299695] ? wait_on_page_bit+0x710/0x710 > [10813.300609] ? __lock_page_or_retry+0x3c0/0x3c0 > [10813.301894] ? up_read+0x1a3/0x730 > [10813.302791] ? page_cache_free_page.isra.45+0x390/0x390 > [10813.304077] filemap_fault+0x2bd/0x2040 > [10813.305019] ? read_cache_page_gfp+0x10/0x10 > [10813.306041] ? lock_downgrade+0x700/0x700 > [10813.306958] ? replace_page_cache_page+0x1130/0x1130 > [10813.308124] __do_fault+0xf5/0x530 > [10813.308968] handle_mm_fault+0x1c0e/0x25b0 > [10813.309955] ? copy_page_range+0xfe0/0xfe0 > [10813.310895] do_user_addr_fault+0x383/0x820 > [10813.312084] exc_page_fault+0x56/0xb0 > [10813.312979] asm_exc_page_fault+0x1e/0x30 > [10813.313978] RIP: 0010:iov_iter_fault_in_readable+0x271/0x350 > fault_in_pages_readable at include/linux/pagemap.h:745 > (inlined by) iov_iter_fault_in_readable at lib/iov_iter.c:438 > [10813.315293] Code: 48 39 d7 0f 82 1a ff ff ff 0f 01 cb 0f ae e8 44 89 c0 8a > 0a > 0f 01 ca 88 4c 24 70 85 c0 74 da e9 f8 fe ff ff 0f 01 cb 0f ae e8 <8a> 11 0f > 01 > ca 88 54 24 30 85 c0 0f 85 04 ff ff ff 48 29 ee e9 > 45 > [10813.319196] RSP: 0018:c90017ccf830 EFLAGS: 00050246 > [10813.320446] RAX: RBX: 192002f99f08 RCX: > 7fe284f1004c > [10813.322202] RDX: 0001 RSI: 1000 RDI: > 8887a7664000 > [10813.323729] RBP: 1000 R08: R09: > > [10813.325282] R10: c90017ccfd48 R11: ed102789d5ff R12: > 8887a7664020 > [10813.326898] R13: c90017ccfd40 R14: dc00 R15: > 00e0df6a > [10813.328456] ? iov_iter_revert+0x8e0/0x8e0 > [10813.329404] ? copyin+0x96/0xc0 > [10813.330230] ? iov_iter_copy_from_user_atomic+0x1f0/0xa40 > [10813.331742] fuse_perform_write+0x3eb/0xf20 [fuse] > fuse_fill_write_pages at fs/fuse/file.c:1150 > (inlined by) fuse_perform_write at fs/fuse/file.c:1226 > [10813.332880] ? fuse_file_fallocate+0x5f0/0x5f0 [fuse] > [10813.334090] fuse_file_write_iter+0x6b7/0x900 [fuse] > [10813.335191] do_iter_readv_writev+0x42b/0x6d0 > [10813.336161] ? new_sync_write+0x610/0x610 > [10813.337194] do_iter_write+0x11f/0x5b0 > [10813.338177] ? __sb_start_write+0x229/0x2d0 > [10813.339169] vfs_writev+0x16d/0x2d0 > [10813.339973] ? vfs_iter_write+0xb0/0xb0 > [10813.340950] ? __fdget_pos+0x9c/0xb0 > [10813.342039] ? rcu_read_lock_sched_held+0x9c/0xd0 > [10813.343120] ? rcu_read_lock_bh_held+0xb0/0xb0 > [10813.344104] ? find_held_lock+0x33/0x1c0 > [10813.345050] do_writev+0xfb/0x1e0 > [10813.345920] ? vfs_writev+0x2d0/0x2d0 > [10813.346802] ? lockdep_hardirqs_on_prepare+0x27c/0x3d0 > [10813.348026] ? syscall_enter_from_user_mode+0x1c/0x50 > [10813.349197] do_syscall_64+0x33/0x40 > [10813.350026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >
Re: [PATCH v1 06/10] bus: mhi: core: Improve shutdown handling after link down detection
On 2020-10-09 09:19, Manivannan Sadhasivam wrote:
On Fri, Sep 18, 2020 at 07:02:31PM -0700, Bhaumik Bhatt wrote:
If MHI were to attempt a device shutdown following an assumption
MHI host? And is this really an assumption or it is definite that the
link is inaccessible. Please clarify!
Will update it to MHI host.
I say assumption because we act based on the "graceful" flag passed by
the MHI controller driver. Link may be accessible but the controller has
instructed MHI not to do any further accesses. They may decide to set
the
flag as "false" if they see any read/access issues, an actual link down
interrupt from the bus driver or a sideband GPIO signal declaring that a
software assert occurred on the device.
MHI host sees that power down attempt as ungraceful and assumes that the
controller has decided that it's either a link down or a fatal error.
Once an "ungraceful" power down attempt is made, MHI host moves to the
LD_ERR_FATAL_DETECT pm_state and without this patch, it moved from an
LD_ERR_FATAL_DETECT to SHUTDOWN_PROCESS state, where SHUTDOWN_PROCESS
is defined as a register accessible state by the MHI_REG_ACCESS_VALID()
macro.
If someone were to do a call that needed a register access from their
.remove() callback, for example, we could see a bus error.
Moves from MHI_PM_M3 to SHUTDOWN_PROCESS and LD_ERR_FATAL_DETECT to
SHUTDOWN_PROCESS are not allowed by use of this patch.
I'll add better wording and explanation.
that the device is inaccessible, the host currently moves to a state
where device register accesses are allowed when they should not be.
This would end up allowing accesses to the device register space when
the link is inaccessible and can result in bus errors observed on the
host. Improve shutdown handling to prevent these outcomes and do not
move the MHI PM state to a register accessible state after device is
assumed to be inaccessible.
Apparently you are introducing a new device transition state but your
commit description doesn't state that :/
Thanks,
Mani
Sure. I will add that.
Signed-off-by: Bhaumik Bhatt
---
drivers/bus/mhi/core/init.c | 1 +
drivers/bus/mhi/core/internal.h | 1 +
drivers/bus/mhi/core/pm.c | 18 +-
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 9ae4c19..fa33dde 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -37,6 +37,7 @@ const char * const
dev_state_tran_str[DEV_ST_TRANSITION_MAX] = {
[DEV_ST_TRANSITION_MISSION_MODE] = "MISSION_MODE",
[DEV_ST_TRANSITION_SYS_ERR] = "SYS_ERR",
[DEV_ST_TRANSITION_DISABLE] = "DISABLE",
+ [DEV_ST_TRANSITION_FATAL] = "FATAL SHUTDOWN",
};
const char * const mhi_state_str[MHI_STATE_MAX] = {
diff --git a/drivers/bus/mhi/core/internal.h
b/drivers/bus/mhi/core/internal.h
index 7989269..f3b9e5a 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -388,6 +388,7 @@ enum dev_st_transition {
DEV_ST_TRANSITION_MISSION_MODE,
DEV_ST_TRANSITION_SYS_ERR,
DEV_ST_TRANSITION_DISABLE,
+ DEV_ST_TRANSITION_FATAL,
DEV_ST_TRANSITION_MAX,
};
diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
index 3462d82..bce1f62 100644
--- a/drivers/bus/mhi/core/pm.c
+++ b/drivers/bus/mhi/core/pm.c
@@ -37,9 +37,10 @@
* M0 -> FW_DL_ERR
* M0 -> M3_ENTER -> M3 -> M3_EXIT --> M0
* L1: SYS_ERR_DETECT -> SYS_ERR_PROCESS --> POR
- * L2: SHUTDOWN_PROCESS -> DISABLE
+ * L2: SHUTDOWN_PROCESS -> LD_ERR_FATAL_DETECT
+ * SHUTDOWN_PROCESS -> DISABLE
* L3: LD_ERR_FATAL_DETECT <--> LD_ERR_FATAL_DETECT
- * LD_ERR_FATAL_DETECT -> SHUTDOWN_PROCESS
+ * LD_ERR_FATAL_DETECT -> DISABLE
*/
static struct mhi_pm_transitions const dev_state_transitions[] = {
/* L0 States */
@@ -72,7 +73,7 @@ static struct mhi_pm_transitions const
dev_state_transitions[] = {
{
MHI_PM_M3,
MHI_PM_M3_EXIT | MHI_PM_SYS_ERR_DETECT |
- MHI_PM_SHUTDOWN_PROCESS | MHI_PM_LD_ERR_FATAL_DETECT
+ MHI_PM_LD_ERR_FATAL_DETECT
},
{
MHI_PM_M3_EXIT,
@@ -103,7 +104,7 @@ static struct mhi_pm_transitions const
dev_state_transitions[] = {
/* L3 States */
{
MHI_PM_LD_ERR_FATAL_DETECT,
- MHI_PM_LD_ERR_FATAL_DETECT | MHI_PM_SHUTDOWN_PROCESS
+ MHI_PM_LD_ERR_FATAL_DETECT | MHI_PM_DISABLE
},
};
@@ -670,6 +671,10 @@ void mhi_pm_st_worker(struct work_struct *work)
mhi_pm_disable_transition
(mhi_cntrl, MHI_PM_SHUTDOWN_PROCESS);
break;
+ case DEV_ST_TRANSITION_FATAL:
+ mhi_pm_disable_transition
+ (mhi_cntrl, MHI_PM_LD_ERR_FATAL_DETECT);
+ break;
default:
[PATCH 1/2] kbuild: deb-pkg: do not build linux-headers package if CONFIG_MODULES=n
Since commit 269a535ca931 ("modpost: generate vmlinux.symvers and
reuse it for the second modpost"), with CONFIG_MODULES disabled,
"make deb-pkg" (or "make bindeb-pkg") fails with:
find: ‘Module.symvers’: No such file or directory
If CONFIG_MODULES is disabled, it doesn't really make sense to build
the linux-headers package.
Fixes: 269a535ca931 ("modpost: generate vmlinux.symvers and reuse it for the
second modpost")
Reported-by: Josh Triplett
Signed-off-by: Masahiro Yamada
---
scripts/package/builddeb | 6 --
scripts/package/mkdebian | 19 ---
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 6474084c32a4..1b11f8993629 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -207,8 +207,10 @@ EOF
done
if [ "$ARCH" != "um" ]; then
- deploy_kernel_headers debian/linux-headers
- create_package linux-headers-$version debian/linux-headers
+ if is_enabled CONFIG_MODULES; then
+ deploy_kernel_headers debian/linux-headers
+ create_package linux-headers-$version debian/linux-headers
+ fi
deploy_libc_headers debian/linux-libc-dev
create_package linux-libc-dev debian/linux-libc-dev
diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
index 3a13b834f281..273fd6ed790e 100755
--- a/scripts/package/mkdebian
+++ b/scripts/package/mkdebian
@@ -184,13 +184,6 @@ Description: Linux kernel, version $version
This package contains the Linux kernel, modules and corresponding other
files, version: $version.
-Package: $kernel_headers_packagename
-Architecture: $debarch
-Description: Linux kernel headers for $version on $debarch
- This package provides kernel header files for $version on $debarch
- .
- This is useful for people who need to build external modules
-
Package: linux-libc-dev
Section: devel
Provides: linux-kernel-headers
@@ -201,6 +194,18 @@ Description: Linux support headers for userspace
development
Multi-Arch: same
EOF
+if is_enabled CONFIG_MODULES; then
+cat <> debian/control
+
+Package: $kernel_headers_packagename
+Architecture: $debarch
+Description: Linux kernel headers for $version on $debarch
+ This package provides kernel header files for $version on $debarch
+ .
+ This is useful for people who need to build external modules
+EOF
+fi
+
if is_enabled CONFIG_DEBUG_INFO; then
cat <> debian/control
--
2.25.1
[PATCH 2/2] kbuild: deb-pkg: clean up package name variables
Hard-code the names of linux-headers and debug packages in the
control file.
The kernel package is different for ARCH=um. Change the code
for better readability.
Signed-off-by: Masahiro Yamada
---
scripts/package/mkdebian | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
index 273fd6ed790e..60a2a63a5e90 100755
--- a/scripts/package/mkdebian
+++ b/scripts/package/mkdebian
@@ -94,16 +94,16 @@ else
packageversion=$version-$revision
fi
sourcename=$KDEB_SOURCENAME
-packagename=linux-image-$version
-kernel_headers_packagename=linux-headers-$version
-dbg_packagename=$packagename-dbg
-debarch=
-set_debarch
if [ "$ARCH" = "um" ] ; then
- packagename=user-mode-linux-$version
+ packagename=user-mode-linux
+else
+ packagename=linux-image
fi
+debarch=
+set_debarch
+
email=${DEBEMAIL-$EMAIL}
# use email string directly if it contains
@@ -178,7 +178,7 @@ Rules-Requires-Root: no
Build-Depends: bc, rsync, kmod, cpio, bison, flex | flex:native
$extra_build_depends
Homepage: https://www.kernel.org/
-Package: $packagename
+Package: $packagename-$version
Architecture: $debarch
Description: Linux kernel, version $version
This package contains the Linux kernel, modules and corresponding other
@@ -197,7 +197,7 @@ EOF
if is_enabled CONFIG_MODULES; then
cat <> debian/control
-Package: $kernel_headers_packagename
+Package: linux-headers-$version
Architecture: $debarch
Description: Linux kernel headers for $version on $debarch
This package provides kernel header files for $version on $debarch
@@ -209,7 +209,7 @@ fi
if is_enabled CONFIG_DEBUG_INFO; then
cat <> debian/control
-Package: $dbg_packagename
+Package: linux-image-$version-dbg
Section: debug
Architecture: $debarch
Description: Linux kernel debugging symbols for $version
--
2.25.1
Re: [PATCH] hwmon: (pmbus/isl68137) remove READ_TEMPERATURE_1 telemetry for RAA228228
On 10/13/20 11:18 AM, Alex Qiu wrote:
> (Intercepting the email thread...)
>
> Hi Grant,
>
> Looks like you made a typo in your patch:
>
>> + case raa_dmpvr2_2rail_nontc:
>> + info->func[0] &= ~PMBUS_HAVE_TEMP;
>> + info->func[1] &= ~PMBUS_HAVE_TEMP;
>> + fallthrough;
>
> Did you mean "/* fallthrough */" instead of "fallthrough;"?
>
No, that is the fancy new way to indicate fallthrough in the kernel.
It is converted to either
__attribute__((__fallthrough__))
or to
do {} while (0)
in include/linux/compiler_attributes.h.
Guenter
[PATCH v0] clk: qcom: lpasscc: Re-configure the PLL in case lost
In the case where the PLL configuration is lost, then the pm runtime
resume will reconfigure before usage.
Fixes: edab812d802d ("clk: qcom: lpass: Add support for LPASS clock controller
for SC7180")
Signed-off-by: Taniya Das
---
drivers/clk/qcom/lpasscorecc-sc7180.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/clk/qcom/lpasscorecc-sc7180.c
b/drivers/clk/qcom/lpasscorecc-sc7180.c
index 228d08f..5804a93 100644
--- a/drivers/clk/qcom/lpasscorecc-sc7180.c
+++ b/drivers/clk/qcom/lpasscorecc-sc7180.c
@@ -356,6 +356,25 @@ static const struct qcom_cc_desc
lpass_audio_hm_sc7180_desc = {
.num_gdscs = ARRAY_SIZE(lpass_audio_hm_sc7180_gdscs),
};
+static int lpass_core_cc_pm_clk_resume(struct device *dev)
+{
+ struct regmap *regmap = dev_get_drvdata(dev);
+ int l_val;
+
+ pm_clk_resume(dev);
+
+ /* Read PLL_L_VAL */
+ regmap_read(regmap, 0x1004, _val);
+ if (!l_val)
+ clk_fabia_pll_configure(_lpaaudio_dig_pll, regmap,
+ _lpaaudio_dig_pll_config);
+ return 0;
+}
+
+static const struct dev_pm_ops lpass_core_pm_ops = {
+ SET_RUNTIME_PM_OPS(pm_clk_suspend, lpass_core_cc_pm_clk_resume, NULL)
+};
+
static int lpass_core_cc_sc7180_probe(struct platform_device *pdev)
{
const struct qcom_cc_desc *desc;
@@ -386,6 +405,9 @@ static int lpass_core_cc_sc7180_probe(struct
platform_device *pdev)
clk_fabia_pll_configure(_lpaaudio_dig_pll, regmap,
_lpaaudio_dig_pll_config);
+ pdev->dev.driver->pm = _core_pm_ops;
+ dev_set_drvdata(>dev, regmap);
+
return qcom_cc_really_probe(pdev, _core_cc_sc7180_desc, regmap);
}
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
[PATCH v0] LPASSCC: Configure the PLL in case lost for SC7180
In the case where the LPASSCC PLL loses the PLL configuration it would fail to lock. Thus allow reconfigure the PLL from pm_resume. Taniya Das (1): clk: qcom: lpasscc: Re-configure the PLL in case lost drivers/clk/qcom/lpasscorecc-sc7180.c | 22 ++ 1 file changed, 22 insertions(+) -- Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member of the Code Aurora Forum, hosted by the Linux Foundation.
Re: [PATCH v2] media: uapi: h264: Add documentation to the interface header
Le lundi 28 septembre 2020 à 17:14 -0300, Ezequiel Garcia a écrit :
> In preparation for making the interface public,
> document all the structures. Special care is taken to
> annotate those fields that depart from the H264 syntax.
>
> This commit only adds documentation and doesn't affect
> functionality in any way.
>
> Signed-off-by: Ezequiel Garcia
> ---
> v2:
> * Address the feedback, commenting every field, including
> reserved and flags.
> * Clarify scaling list ordering.
> ---
> include/media/h264-ctrls.h | 195 +++--
> 1 file changed, 185 insertions(+), 10 deletions(-)
>
> diff --git a/include/media/h264-ctrls.h b/include/media/h264-ctrls.h
> index ec4799154438..893e21354a9b 100644
> --- a/include/media/h264-ctrls.h
> +++ b/include/media/h264-ctrls.h
> @@ -46,11 +46,38 @@
> #define V4L2_CTRL_TYPE_H264_DECODE_PARAMS0x0114
> #define V4L2_CTRL_TYPE_H264_PRED_WEIGHTS 0x0115
>
> +/**
> + * enum v4l2_mpeg_video_h264_decode_mode - Decoding mode
> + *
> + * @V4L2_MPEG_VIDEO_H264_DECODE_MODE_SLICE_BASED: indicates that decoding
> + * is performed one slice at a time. In this mode,
> + * V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS must contain the parsed slice
> + * parameters and the OUTPUT buffer must contain a single slice.
> + * V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF feature is used
> + * in order to support multislice frames.
multi-slice or multiple slice per ?
> + * @V4L2_MPEG_VIDEO_H264_DECODE_MODE_FRAME_BASED: indicates that
> + * decoding is performed per frame. The OUTPUT buffer must contain
> + * all slices and also both fields. This mode is typically supported
I'm surprised that this must contain both fields without distinction of
MBAFF or alternate. We have a pretty limited interlacing coverage atm,
are we certain this is correct ? I'm fine with that, as long as it
matches the HW.
> + * by device drivers that are able to parse the slice(s) header(s)
> + * in hardware. When this mode is selected,
> + * V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS is not used.
> + */
> enum v4l2_mpeg_video_h264_decode_mode {
> V4L2_MPEG_VIDEO_H264_DECODE_MODE_SLICE_BASED,
> V4L2_MPEG_VIDEO_H264_DECODE_MODE_FRAME_BASED,
> };
>
> +/**
> + * enum v4l2_mpeg_video_h264_start_code - Start code
> + *
> + * @V4L2_MPEG_VIDEO_H264_START_CODE_NONE: slices are passed
> + * to the driver without any start code.
> + * @V4L2_MPEG_VIDEO_H264_START_CODE_ANNEX_B: slices are passed
> + * to the driver with an Annex B start code prefix
> + * (legal start codes can be 3-bytes 0x01 or 4-bytes 0x0001).
> + * This mode is typically supported by device drivers that parse
> + * the start code in hardware.
> + */
Do we need to mention that not all combinations are possible ? An
example, having START_CODE_NONE with FRAME_BASED would simply not work,
since it's impossible to find the start/end of NAL.
> enum v4l2_mpeg_video_h264_start_code {
> V4L2_MPEG_VIDEO_H264_START_CODE_NONE,
> V4L2_MPEG_VIDEO_H264_START_CODE_ANNEX_B,
> @@ -71,6 +98,31 @@ enum v4l2_mpeg_video_h264_start_code {
> #define V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD 0x20
> #define V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE 0x40
>
> +/**
> + * struct v4l2_ctrl_h264_sps - H264 sequence parameter set
> + *
> + * All the members on this sequence parameter set structure match the
> + * sequence parameter set syntax as specified by the H264 specification.
> + *
> + * @profile_idc: see H264 specification.
> + * @constraint_set_flags: see H264 specification.
> + * @level_idc: see H264 specification.
> + * @seq_parameter_set_id: see H264 specification.
> + * @chroma_format_idc: see H264 specification.
> + * @bit_depth_luma_minus8: see H264 specification.
> + * @bit_depth_chroma_minus8: see H264 specification.
> + * @log2_max_frame_num_minus4: see H264 specification.
> + * @pic_order_cnt_type: see H264 specification.
> + * @log2_max_pic_order_cnt_lsb_minus4: see H264 specification.
> + * @max_num_ref_frames: see H264 specification.
> + * @num_ref_frames_in_pic_order_cnt_cycle: see H264 specification.
> + * @offset_for_ref_frame: see H264 specification.
> + * @offset_for_non_ref_pic: see H264 specification.
> + * @offset_for_top_to_bottom_field: see H264 specification.
> + * @pic_width_in_mbs_minus1: see H264 specification.
> + * @pic_height_in_map_units_minus1: see H264 specification.
> + * @flags: see V4L2_H264_SPS_FLAG_{}.
> + */
> struct v4l2_ctrl_h264_sps {
> __u8 profile_idc;
> __u8 constraint_set_flags;
> @@ -101,6 +153,31 @@ struct v4l2_ctrl_h264_sps {
> #define V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE
> 0x0040
> #define V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT0x0080
>
> +/**
> + * struct v4l2_ctrl_h264_pps - H264 picture parameter set
> + *
> + * Except where noted, all the members on this picture parameter set
> + * structure match the sequence parameter set syntax as
Re: [PATCH RFC V3 4/9] x86/pks: Preserve the PKRS MSR on context switch
On 10/9/20 12:42 PM, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The PKRS MSR is defined as a per-logical-processor register. This
> isolates memory access by logical CPU. Unfortunately, the MSR is not
> managed by XSAVE. Therefore, tasks must save/restore the MSR value on
> context switch.
>
> Define a saved PKRS value in the task struct, as well as a cached
> per-logical-processor MSR value which mirrors the MSR value of the
> current CPU. Initialize all tasks with the default MSR value. Then, on
> schedule in, check the saved task MSR vs the per-cpu value. If
> different proceed to write the MSR. If not avoid the overhead of the
> MSR write and continue.
It's probably nice to note how the WRMSR is special here, in addition to
the comments below.
> #endif /*_ASM_X86_PKEYS_INTERNAL_H */
> diff --git a/arch/x86/include/asm/processor.h
> b/arch/x86/include/asm/processor.h
> index 97143d87994c..da2381136b2d 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -18,6 +18,7 @@ struct vm86;
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -542,6 +543,11 @@ struct thread_struct {
>
> unsigned intsig_on_uaccess_err:1;
>
> +#ifdef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS
> + /* Saved Protection key register for supervisor mappings */
> + u32 saved_pkrs;
> +#endif
Could you take a look around thread_struct and see if there are some
other MSRs near which you can stash this? This seems like a bit of a
lonely place.
...
> void flush_thread(void)
> {
> struct task_struct *tsk = current;
> @@ -195,6 +212,8 @@ void flush_thread(void)
> memset(tsk->thread.tls_array, 0, sizeof(tsk->thread.tls_array));
>
> fpu__clear_all(>thread.fpu);
> +
> + pks_init_task(tsk);
> }
>
> void disable_TSC(void)
> @@ -644,6 +663,8 @@ void __switch_to_xtra(struct task_struct *prev_p, struct
> task_struct *next_p)
>
> if ((tifp ^ tifn) & _TIF_SLD)
> switch_to_sld(tifn);
> +
> + pks_sched_in();
> }
>
> /*
> diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
> index 3cf8f775f36d..30f65dd3d0c5 100644
> --- a/arch/x86/mm/pkeys.c
> +++ b/arch/x86/mm/pkeys.c
> @@ -229,3 +229,31 @@ u32 update_pkey_val(u32 pk_reg, int pkey, unsigned int
> flags)
>
> return pk_reg;
> }
> +
> +DEFINE_PER_CPU(u32, pkrs_cache);
> +
> +/**
> + * It should also be noted that the underlying WRMSR(MSR_IA32_PKRS) is not
> + * serializing but still maintains ordering properties similar to WRPKRU.
> + * The current SDM section on PKRS needs updating but should be the same as
> + * that of WRPKRU. So to quote from the WRPKRU text:
> + *
> + * WRPKRU will never execute transiently. Memory accesses
> + * affected by PKRU register will not execute (even transiently)
> + * until all prior executions of WRPKRU have completed execution
> + * and updated the PKRU register.
> + */
> +void write_pkrs(u32 new_pkrs)
> +{
> + u32 *pkrs;
> +
> + if (!static_cpu_has(X86_FEATURE_PKS))
> + return;
> +
> + pkrs = get_cpu_ptr(_cache);
> + if (*pkrs != new_pkrs) {
> + *pkrs = new_pkrs;
> + wrmsrl(MSR_IA32_PKRS, new_pkrs);
> + }
> + put_cpu_ptr(pkrs);
> +}
>
It bugs me a *bit* that this is being called in a preempt-disabled
region, but we still bother with the get/put_cpu jazz. Are there other
future call-sites for this that aren't in preempt-disabled regions?
Re: [GIT PULL] regulator updates for v5.10
The pull request you sent on Mon, 12 Oct 2020 14:09:08 +0100: > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git > tags/regulator-v5.10 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1724e02e024adf5a17da12fad6819e30d304da7d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL for v5.10-rc1] media updates
The pull request you sent on Mon, 12 Oct 2020 13:41:39 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > tags/media/v5.10-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fd5c32d80884268a381ed0e67cccef0b3d37750b Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] MMC updates for v5.10
The pull request you sent on Mon, 12 Oct 2020 12:01:27 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.10 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/647412daeb454b6dad12a6c6961ab90aac9e5d29 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] SPI updates for v5.10
The pull request you sent on Mon, 12 Oct 2020 14:09:27 +0100: > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v5.10 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a996b9c61729cd1507e48303c214dc317df890e2 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] GPIO bulk changes for the v5.10 kernel series
The pull request you sent on Tue, 13 Oct 2020 11:49:35 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git > tags/gpio-v5.10-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0486beaf88d2460e9dbcbba281dab683a838f0c6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] hwmon updates for v5.10
The pull request you sent on Mon, 12 Oct 2020 07:28:32 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git > hwmon-for-v5.10 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c4439713e82a0d746e533ae5ddd7dfa832e2a486 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] regmap updates for v5.10
The pull request you sent on Mon, 12 Oct 2020 14:08:49 +0100: > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git > tags/regmap-v5.10 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/57218d7f2e87069f73c7a841b6ed6c1cc7acf616 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH RFC V3 3/9] x86/pks: Enable Protection Keys Supervisor (PKS)
On 10/9/20 12:42 PM, ira.we...@intel.com wrote:
> +/*
> + * PKS is independent of PKU and either or both may be supported on a CPU.
> + * Configure PKS if the cpu supports the feature.
> + */
Let's at least be consistent about CPU vs. cpu in a single comment. :)
> +static void setup_pks(void)
> +{
> + if (!IS_ENABLED(CONFIG_ARCH_HAS_SUPERVISOR_PKEYS))
> + return;
> + if (!cpu_feature_enabled(X86_FEATURE_PKS))
> + return;
If you put X86_FEATURE_PKS in disabled-features.h, you can get rid of
the explicit CONFIG_ check.
> + cr4_set_bits(X86_CR4_PKS);
> +}
> +
> /*
> * This does the hard work of actually picking apart the CPU stuff...
> */
> @@ -1544,6 +1558,7 @@ static void identify_cpu(struct cpuinfo_x86 *c)
>
> x86_init_rdrand(c);
> setup_pku(c);
> + setup_pks();
>
> /*
>* Clear/Set all flags overridden by options, need do it
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 6c974888f86f..1b9bc004d9bc 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -822,6 +822,8 @@ config ARCH_USES_HIGH_VMA_FLAGS
> bool
> config ARCH_HAS_PKEYS
> bool
> +config ARCH_HAS_SUPERVISOR_PKEYS
> + bool
>
> config PERCPU_STATS
> bool "Collect percpu memory statistics"
>
Re: [PATCH] hwmon: (pmbus/isl68137) remove READ_TEMPERATURE_1 telemetry for RAA228228
Jason pointed me to the patch https://github.com/torvalds/linux/commit/294f69e662d1570703e9b56e95be37a9fd3afba5. Nvm... - Alex Qiu On Tue, Oct 13, 2020 at 11:18 AM Alex Qiu wrote: > > (Intercepting the email thread...) > > Hi Grant, > > Looks like you made a typo in your patch: > > > + case raa_dmpvr2_2rail_nontc: > > + info->func[0] &= ~PMBUS_HAVE_TEMP; > > + info->func[1] &= ~PMBUS_HAVE_TEMP; > > + fallthrough; > > Did you mean "/* fallthrough */" instead of "fallthrough;"? > > - Alex Qiu
Re: [patch 2/4] media: omap3isp: Remove misleading comment
Hi Thomas, Thank you for the patch. On Tue, Oct 13, 2020 at 04:26:18PM +0200, Thomas Gleixner wrote: > in_interrupt() covers hard and soft interrupt servicing and bottom half > disabled contexts, which is semantically ill defined. > > The comment for __ccdc_lsc_configure() "Context: in_interrupt()" is > therefore as useful as "Context: unknown'. Remove it. > > Signed-off-by: Thomas Gleixner > Cc: Mauro Carvalho Chehab > Cc: Laurent Pinchart > Cc: linux-me...@vger.kernel.org Reviewed-by: Laurent Pinchart > --- > drivers/media/platform/omap3isp/ispccdc.c |5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > --- a/drivers/media/platform/omap3isp/ispccdc.c > +++ b/drivers/media/platform/omap3isp/ispccdc.c > @@ -299,11 +299,10 @@ static int ccdc_lsc_busy(struct isp_ccdc >ISPCCDC_LSC_BUSY; > } > > -/* __ccdc_lsc_configure - Apply a new configuration to the LSC engine > +/* > + * __ccdc_lsc_configure - Apply a new configuration to the LSC engine > * @ccdc: Pointer to ISP CCDC device > * @req: New configuration request > - * > - * context: in_interrupt() > */ > static int __ccdc_lsc_configure(struct isp_ccdc_device *ccdc, > struct ispccdc_lsc_config_req *req) > -- Regards, Laurent Pinchart
[PATCH v2 2/2] drm/mediatek: mtk_hdmi: add MT8167 support for HDMI
Add support for HDMI on MT8167. HDMI on MT8167 is similar to
MT8173/MT2701 execpt for the two registers: SYS_CFG1C and SYS_CFG20
Signed-off-by: Fabien Parent
---
Changelog:
v2: fix name of pdata structure
drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +++
drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 57370c036497..484ea9cd654a 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1835,9 +1835,16 @@ static struct mtk_hdmi_data mt8173_hdmi_driver_data = {
.sys_cfg20 = HDMI_SYS_CFG20,
};
+static struct mtk_hdmi_data mt8167_hdmi_driver_data = {
+ .sys_cfg1c = MT8167_HDMI_SYS_CFG1C,
+ .sys_cfg20 = MT8167_HDMI_SYS_CFG20,
+};
+
static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
{ .compatible = "mediatek,mt8173-hdmi",
.data = _hdmi_driver_data },
+ { .compatible = "mediatek,mt8167-hdmi",
+ .data = _hdmi_driver_data },
{}
};
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
index 2050ba45b23a..a0f9c367d7aa 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
@@ -195,6 +195,7 @@
#define GEN_RGB(0 << 7)
#define HDMI_SYS_CFG1C 0x000
+#define MT8167_HDMI_SYS_CFG1C 0x800
#define HDMI_ONBIT(0)
#define HDMI_RST BIT(1)
#define ANLG_ONBIT(2)
@@ -211,6 +212,7 @@
#define HTPLG_PIN_SEL_OFF BIT(30)
#define AES_EFUSE_ENABLE BIT(31)
#define HDMI_SYS_CFG20 0x004
+#define MT8167_HDMI_SYS_CFG20 0x804
#define DEEP_COLOR_MODE_MASK (3 << 1)
#define COLOR_8BIT_MODE(0 << 1)
#define COLOR_10BIT_MODE (1 << 1)
--
2.28.0
[PATCH v2 1/2] drm/mediatek: mtk_hdmi: move 2 registers address into of_data
On MT8167, the two registers SYS_CFG1C and SYS_CFG20 don't have the
same address as on MT8173. Add OF data in order to store the address
of these two registers.
Signed-off-by: Fabien Parent
---
Changelog:
v2: no changes
drivers/gpu/drm/mediatek/mtk_hdmi.c | 45 ++---
1 file changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index a97725680d4e..57370c036497 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -36,6 +36,11 @@
#define NCTS_BYTES 7
+struct mtk_hdmi_data {
+ uint32_t sys_cfg1c;
+ uint32_t sys_cfg20;
+};
+
enum mtk_hdmi_clk_id {
MTK_HDMI_CLK_HDMI_PIXEL,
MTK_HDMI_CLK_HDMI_PLL,
@@ -146,6 +151,7 @@ struct hdmi_audio_param {
};
struct mtk_hdmi {
+ const struct mtk_hdmi_data *data;
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
struct drm_connector conn;
@@ -244,21 +250,24 @@ static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi
*hdmi, bool enable)
*/
if (hdmi_phy->conf && hdmi_phy->conf->tz_disabled)
regmap_update_bits(hdmi->sys_regmap,
- hdmi->sys_offset + HDMI_SYS_CFG20,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
0x80008005, enable ? 0x8005 : 0x8000);
else
arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904,
0x8000, 0, 0, 0, 0, 0, );
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_ON | ANLG_ON, enable ? (HDMI_ON | ANLG_ON) : 0);
}
static void mtk_hdmi_hw_1p4_version_enable(struct mtk_hdmi *hdmi, bool enable)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI2P0_EN, enable ? 0 : HDMI2P0_EN);
}
@@ -274,12 +283,15 @@ static void mtk_hdmi_hw_aud_unmute(struct mtk_hdmi *hdmi)
static void mtk_hdmi_hw_reset(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_RST, HDMI_RST);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_RST, 0);
mtk_hdmi_clear_bits(hdmi, GRL_CFG3, CFG3_CONTROL_PACKET_DELAY);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
ANLG_ON, ANLG_ON);
}
@@ -362,16 +374,19 @@ static void mtk_hdmi_hw_send_aud_packet(struct mtk_hdmi
*hdmi, bool enable)
static void mtk_hdmi_hw_config_sys(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_OUT_FIFO_EN | MHL_MODE_ON, 0);
usleep_range(2000, 4000);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_OUT_FIFO_EN | MHL_MODE_ON, HDMI_OUT_FIFO_EN);
}
static void mtk_hdmi_hw_set_deep_color_mode(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
DEEP_COLOR_MODE_MASK | DEEP_COLOR_EN,
COLOR_8BIT_MODE);
}
@@ -1733,6 +1748,7 @@ static int mtk_drm_hdmi_probe(struct platform_device
*pdev)
return -ENOMEM;
hdmi->dev = dev;
+ hdmi->data = of_device_get_match_data(dev);
ret = mtk_hdmi_dt_parse_pdata(hdmi, pdev);
if (ret)
@@ -1813,8 +1829,15 @@ static int mtk_hdmi_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_hdmi_pm_ops,
mtk_hdmi_suspend, mtk_hdmi_resume);
+
RE: [PATCH] hwmon: (pmbus/isl68137) remove READ_TEMPERATURE_1 telemetry for RAA228228
(Intercepting the email thread...) Hi Grant, Looks like you made a typo in your patch: > + case raa_dmpvr2_2rail_nontc: > + info->func[0] &= ~PMBUS_HAVE_TEMP; > + info->func[1] &= ~PMBUS_HAVE_TEMP; > + fallthrough; Did you mean "/* fallthrough */" instead of "fallthrough;"? - Alex Qiu
Re: [PATCH 4.19 00/49] 4.19.151-rc1 review
Hi! > This is the start of the stable review cycle for the 4.19.151 release. > There are 49 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 14 Oct 2020 13:26:14 +. > Anything received after that time might be too late. Tested-by: Pavel Machek (CIP) -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany signature.asc Description: Digital signature
Re: [PATCH 4.4 00/39] 4.4.239-rc1 review
On Mon 2020-10-12 15:26:30, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.239 release. > There are 39 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 14 Oct 2020 13:26:14 +. > Anything received after that time might be too late. Tested-by: Pavel Machek (CIP) -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany signature.asc Description: Digital signature
Re: [PATCH 2/2] drm/mediatek: mtk_hdmi: add MT8167 support for HDMI
On Tue, Oct 13, 2020 at 7:28 PM Fabien Parent wrote:
>
> Add support for HDMI on MT8167. HDMI on MT8167 is similar to
> MT8173/MT2701 execpt for the two registers: SYS_CFG1C and SYS_CFG20
>
> Signed-off-by: Fabien Parent
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +++
> drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index c70f195c21be..7762be5cb446 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1835,9 +1835,16 @@ static struct mtk_hdmi_data mt8173_hdmi_driver_data = {
> .sys_cfg20 = HDMI_SYS_CFG20,
> };
>
> +static struct mtk_hdmi_conf mt8167_hdmi_driver_data = {
Sent the wrong patch. Sending v2 soon.
> + .sys_cfg1c = MT8167_HDMI_SYS_CFG1C,
> + .sys_cfg20 = MT8167_HDMI_SYS_CFG20,
> +};
> +
> static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
> { .compatible = "mediatek,mt8173-hdmi",
> .data = _hdmi_driver_data },
> + { .compatible = "mediatek,mt8167-hdmi",
> + .data = _hdmi_driver_data },
> {}
> };
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> index 2050ba45b23a..a0f9c367d7aa 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> @@ -195,6 +195,7 @@
> #define GEN_RGB(0 << 7)
>
> #define HDMI_SYS_CFG1C 0x000
> +#define MT8167_HDMI_SYS_CFG1C 0x800
> #define HDMI_ONBIT(0)
> #define HDMI_RST BIT(1)
> #define ANLG_ONBIT(2)
> @@ -211,6 +212,7 @@
> #define HTPLG_PIN_SEL_OFF BIT(30)
> #define AES_EFUSE_ENABLE BIT(31)
> #define HDMI_SYS_CFG20 0x004
> +#define MT8167_HDMI_SYS_CFG20 0x804
> #define DEEP_COLOR_MODE_MASK (3 << 1)
> #define COLOR_8BIT_MODE(0 << 1)
> #define COLOR_10BIT_MODE (1 << 1)
> --
> 2.28.0
>
Re: [PATCH v4 3/6] drivers: hwmon: Add the iEi WT61P803 PUZZLE HWMON driver
Hello Guenter,
On Sun, Oct 11, 2020 at 11:26 PM Guenter Roeck wrote:
>
> On Wed, Oct 07, 2020 at 02:48:58AM +0200, Luka Kovacic wrote:
> > Add the iEi WT61P803 PUZZLE HWMON driver, that handles the fan speed
> > control via PWM, reading fan speed and reading on-board temperature
> > sensors.
> >
> > The driver registers a HWMON device and a simple thermal cooling device to
> > enable in-kernel fan management.
> >
> > This driver depends on the iEi WT61P803 PUZZLE MFD driver.
> >
> > Signed-off-by: Luka Kovacic
> > Cc: Luka Perkov
> > Cc: Robert Marko
> > ---
> > drivers/hwmon/Kconfig | 8 +
> > drivers/hwmon/Makefile| 1 +
> > drivers/hwmon/iei-wt61p803-puzzle-hwmon.c | 457 ++
> > 3 files changed, 466 insertions(+)
> > create mode 100644 drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
> >
> > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > index 8dc28b26916e..ff279df9bf40 100644
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -722,6 +722,14 @@ config SENSORS_IBMPOWERNV
> > This driver can also be built as a module. If so, the module
> > will be called ibmpowernv.
> >
> > +config SENSORS_IEI_WT61P803_PUZZLE_HWMON
> > + tristate "iEi WT61P803 PUZZLE MFD HWMON Driver"
> > + depends on MFD_IEI_WT61P803_PUZZLE
> > + help
> > + The iEi WT61P803 PUZZLE MFD HWMON Driver handles reading fan speed
> > + and writing fan PWM values. It also supports reading on-board
> > + temperature sensors.
> > +
> > config SENSORS_IIO_HWMON
> > tristate "Hwmon driver that uses channels specified via iio maps"
> > depends on IIO
> > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> > index a8f4b35b136b..b0afb2d6896f 100644
> > --- a/drivers/hwmon/Makefile
> > +++ b/drivers/hwmon/Makefile
> > @@ -83,6 +83,7 @@ obj-$(CONFIG_SENSORS_HIH6130) += hih6130.o
> > obj-$(CONFIG_SENSORS_ULTRA45)+= ultra45_env.o
> > obj-$(CONFIG_SENSORS_I5500) += i5500_temp.o
> > obj-$(CONFIG_SENSORS_I5K_AMB)+= i5k_amb.o
> > +obj-$(CONFIG_SENSORS_IEI_WT61P803_PUZZLE_HWMON) +=
> > iei-wt61p803-puzzle-hwmon.o
> > obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o
> > obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o
> > obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
> > diff --git a/drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
> > b/drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
> > new file mode 100644
> > index ..be7b019d126c
> > --- /dev/null
> > +++ b/drivers/hwmon/iei-wt61p803-puzzle-hwmon.c
> > @@ -0,0 +1,457 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/* iEi WT61P803 PUZZLE MCU HWMON Driver
> > + *
> > + * Copyright (C) 2020 Sartura Ltd.
> > + * Author: Luka Kovacic
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define IEI_WT61P803_PUZZLE_HWMON_MAX_TEMP_NUM 2
> > +#define IEI_WT61P803_PUZZLE_HWMON_MAX_FAN_NUM 5
> > +#define IEI_WT61P803_PUZZLE_HWMON_MAX_PWM_NUM 2
> > +#define IEI_WT61P803_PUZZLE_HWMON_MAX_PWM_VAL 255
> > +
> > +/**
> > + * struct iei_wt61p803_puzzle_thermal_cooling_device - Thermal cooling
> > device instance
> > + *
> > + * @mcu_hwmon: MCU HWMON struct pointer
> > + * @tcdev: Thermal cooling device pointer
> > + * @name:Thermal cooling device name
> > + * @pwm_channel: PWM channel (0 or 1)
> > + * @cooling_levels: Thermal cooling device cooling levels
> > + */
> > +struct iei_wt61p803_puzzle_thermal_cooling_device {
> > + struct iei_wt61p803_puzzle_hwmon *mcu_hwmon;
> > + struct thermal_cooling_device *tcdev;
> > + char name[THERMAL_NAME_LENGTH];
> > + int pwm_channel;
> > + u8 *cooling_levels;
> > +};
> > +
> > +/**
> > + * struct iei_wt61p803_puzzle_hwmon - MCU HWMON Driver
> > + *
> > + * @mcu: MCU struct pointer
> > + * @response_buffer Global MCU response buffer allocation
> > + * @thermal_cooling_dev_present: Per-channel thermal cooling device
> > control
> > + * @cdev:Per-channel thermal cooling device
> > private structure
> > + */
> > +struct iei_wt61p803_puzzle_hwmon {
> > + struct iei_wt61p803_puzzle *mcu;
> > + unsigned char *response_buffer;
> > + bool
> > thermal_cooling_dev_present[IEI_WT61P803_PUZZLE_HWMON_MAX_PWM_NUM];
> > + struct iei_wt61p803_puzzle_thermal_cooling_device
> > + *cdev[IEI_WT61P803_PUZZLE_HWMON_MAX_PWM_NUM];
> > +};
> > +
> > +#define raw_temp_to_milidegree_celsius(x) ((int)(((x) - 0x80) * 1000))
> > +static int iei_wt61p803_puzzle_read_temp_sensor(struct
> > iei_wt61p803_puzzle_hwmon *mcu_hwmon,
> > + int channel, int *value)
> > +{
> > + unsigned char *resp_buf = mcu_hwmon->response_buffer;
> > + unsigned char
Re: [PATCH 3/3] interconnect: qcom: sc7180: Init BCMs before creating the nodes
On Tue, Oct 13, 2020 at 6:59 AM Georgi Djakov wrote:
>
> Currently if we use sync_state, by default the bandwidth is maxed out,
> but in order to set this in hardware, the BCMs (Bus Clock Managers) need
> to be initialized first. Move the BCM initialization before creating the
> nodes to fix this.
>
> Fixes: 7d3b0b0d8184 ("interconnect: qcom: Use icc_sync_state")
> Signed-off-by: Georgi Djakov
> ---
> drivers/interconnect/qcom/sc7180.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/interconnect/qcom/sc7180.c
> b/drivers/interconnect/qcom/sc7180.c
> index bf11b82ed55c..8d9044ed18ab 100644
> --- a/drivers/interconnect/qcom/sc7180.c
> +++ b/drivers/interconnect/qcom/sc7180.c
> @@ -553,6 +553,9 @@ static int qnoc_probe(struct platform_device *pdev)
> return ret;
> }
>
> + for (i = 0; i < qp->num_bcms; i++)
> + qcom_icc_bcm_init(qp->bcms[i], >dev);
> +
> for (i = 0; i < num_nodes; i++) {
> size_t j;
>
> @@ -576,9 +579,6 @@ static int qnoc_probe(struct platform_device *pdev)
> }
> data->num_nodes = num_nodes;
>
> - for (i = 0; i < qp->num_bcms; i++)
> - qcom_icc_bcm_init(qp->bcms[i], >dev);
> -
> platform_set_drvdata(pdev, qp);
>
> return 0;
Acked-by: Saravana Kannan
-Saravana
Re: [PATCH 2/3] interconnect: qcom: sdm845: Init BCMs before creating the nodes
On Tue, Oct 13, 2020 at 6:59 AM Georgi Djakov wrote:
>
> Currently if we use sync_state, by default the bandwidth is maxed out,
> but in order to set this in hardware, the BCMs (Bus Clock Managers) need
> to be initialized first. Move the BCM initialization before creating the
> nodes to fix this.
>
> Fixes: 7d3b0b0d8184 ("interconnect: qcom: Use icc_sync_state")
> Signed-off-by: Georgi Djakov
> ---
> drivers/interconnect/qcom/sdm845.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/interconnect/qcom/sdm845.c
> b/drivers/interconnect/qcom/sdm845.c
> index d79e3163e2c3..47556dc12ec0 100644
> --- a/drivers/interconnect/qcom/sdm845.c
> +++ b/drivers/interconnect/qcom/sdm845.c
> @@ -489,6 +489,9 @@ static int qnoc_probe(struct platform_device *pdev)
> return ret;
> }
>
> + for (i = 0; i < qp->num_bcms; i++)
> + qcom_icc_bcm_init(qp->bcms[i], >dev);
> +
> for (i = 0; i < num_nodes; i++) {
> size_t j;
>
> @@ -512,9 +515,6 @@ static int qnoc_probe(struct platform_device *pdev)
> }
> data->num_nodes = num_nodes;
>
> - for (i = 0; i < qp->num_bcms; i++)
> - qcom_icc_bcm_init(qp->bcms[i], >dev);
> -
> platform_set_drvdata(pdev, qp);
>
> return 0;
Acked-by: Saravana Kannan
-Saravana
Re: [PATCH 1/3] interconnect: Aggregate before setting initial bandwidth
On Tue, Oct 13, 2020 at 6:59 AM Georgi Djakov wrote:
>
> When setting the initial bandwidth, make sure to call the aggregate()
> function (if such is implemented for the current provider), to handle
> cases when data needs to be aggregated first.
>
> Fixes: b1d681d8d324 ("interconnect: Add sync state support")
> Signed-off-by: Georgi Djakov
> ---
> drivers/interconnect/core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index eea47b4c84aa..974a66725d09 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -971,6 +971,9 @@ void icc_node_add(struct icc_node *node, struct
> icc_provider *provider)
> }
> node->avg_bw = node->init_avg;
> node->peak_bw = node->init_peak;
> + if (provider->aggregate)
> + provider->aggregate(node, 0, node->init_avg, node->init_peak,
> + >avg_bw, >peak_bw);
> provider->set(node, node);
> node->avg_bw = 0;
> node->peak_bw = 0;
Acked-by: Saravana Kannan
-Saravana
Re: [PATCH] power: supply: bq25980: Fix uninitialized wd_reg_val and overrun
Sebastian On 10/9/20 7:12 AM, Dan Murphy wrote: Fix the issue when 'i' is equal to array size then array index over runs the array when checking for the watch dog value. This also fixes the uninitialized wd_reg_val if the for..loop was not successful in finding an appropriate match. Might want to pull this into next as well this is a 0-day bug fix Dan
Re: [PATCH v4 1/2] dt-bindings: power: Add the bq25790 dt bindings
Sebastian On 10/9/20 9:41 AM, Dan Murphy wrote: Add the bindings for the bq25790. Also any updates on this series? Dan
Re: [PATCH] kbuild: doc: describe proper script invocation
On Tue, Oct 13, 2020 at 11:31 PM Masahiro Yamada wrote: > > On Thu, Oct 1, 2020 at 4:57 PM Lukas Bulwahn wrote: > > > > During an investigation to fix up the execute bits of scripts in the kernel > > repository, Andrew Morton and Kees Cook pointed out that the execute bit > > should not matter, and that build scripts cannot rely on that. Kees could > > not point to any documentation, though. > > > > Masahiro Yamada explained the convention of setting execute bits to make it > > easier for manual script invocation. > > > > Provide some basic documentation how the build shall invoke scripts, such > > that the execute bits do not matter, and acknowledge that execute bits > > are useful nonetheless. > > > > This serves as reference for further clean-up patches in the future. > > > > Link: > > https://lore.kernel.org/lkml/20200830174409.c24c3f67addcce0cea9a9...@linux-foundation.org/ > > Link: https://lore.kernel.org/lkml/202008271102.FEB906C88@keescook/ > > Link: > > https://lore.kernel.org/linux-kbuild/CAK7LNAQdrvMkDA6ApDJCGr+5db8SiPo=g+p8eiovnngven8...@mail.gmail.com/ > > > > Suggested-by: Andrew Morton > > Suggested-by: Kees Cook > > Signed-off-by: Lukas Bulwahn > > > Applied to linux-kbuild. > Thanks. > No, not really. I will re-think if this is the right thing to do. -- Best Regards Masahiro Yamada
Re: [PATCH 2/6] dt-bindings: mfd: google,cros-ec: explicitly allow additional properties
Zhen On 10/13/20 11:08 AM, Zhen Lei wrote: There are so many properties have not been described in this yaml file, and a lot of errors will be reported. Especially, some yaml files such as google,cros-ec-typec.yaml, extcon-usbc-cros-ec.yaml can not pass the self-check, because of the examples. So temporarily allow additional properties to keep the comprehensive dt_binding_check result clean. My preference is to fix the binding to pass the checks and not just work around the issues. Working around the issues may mean the issues never get fixed. Dan
ERROR: "spurious_interrupt" undefined!
Hi Thomas, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 865c50e1d279671728c2936cb7680eb89355eeea commit: 0ce5ebd24d25f02c73940f047b12733d84b125e8 mfd: ioc3: Add driver for SGI IOC3 chip date: 9 months ago config: mips-randconfig-s032-20201013 (attached as .config) compiler: mips64el-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-rc1-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ce5ebd24d25f02c73940f047b12733d84b125e8 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 0ce5ebd24d25f02c73940f047b12733d84b125e8 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> ERROR: "spurious_interrupt" [drivers/mfd/ioc3.ko] undefined! >> ERROR: "pci_find_host_bridge" [drivers/mfd/ioc3.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] dt-bindings: leds: Update devicetree documents for ID_RGB
Update the leds/common.yaml to indicate that the max color ID is 9. Reflect the same change in the leds-class-multicolor.yaml Reported-by: Zhen Lei Signed-off-by: Dan Murphy --- Documentation/devicetree/bindings/leds/common.yaml | 2 +- .../devicetree/bindings/leds/leds-class-multicolor.yaml | 9 + 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index a2a541bca73c..0c9f912dfee6 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -43,7 +43,7 @@ properties: LED_COLOR_ID available, add a new one. $ref: /schemas/types.yaml#definitions/uint32 minimum: 0 -maximum: 8 +maximum: 9 function-enumerator: description: diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml index b55e1f1308a4..f8032e863ecb 100644 --- a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml +++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml @@ -16,7 +16,7 @@ description: | modules. This is achieved by adding multi-led nodes layer to the monochrome LED bindings. The nodes and properties defined in this document are unique to the multicolor - LED class. Common LED nodes and properties are inherited from the common.txt + LED class. Common LED nodes and properties are inherited from the common.yaml within this documentation directory. patternProperties: @@ -25,10 +25,11 @@ patternProperties: description: Represents the LEDs that are to be grouped. properties: color: -const: 8 # LED_COLOR_ID_MULTI +const: 9 # LED_COLOR_ID_RGB description: | - For multicolor LED support this property should be defined as - LED_COLOR_ID_MULTI which can be found in include/linux/leds/common.h. + For multicolor LED support this property should be defined as either + LED_COLOR_ID_RGB or LED_COLOR_ID_MULTI which can be found in + include/linux/leds/common.h. $ref: "common.yaml#" -- 2.28.0.585.ge1cfff676549
Re: [PATCH RFC V3 2/9] x86/fpu: Refactor arch_set_user_pkey_access() for PKS support
On 10/9/20 12:42 PM, ira.we...@intel.com wrote:
> +/*
> + * Update the pk_reg value and return it.
How about:
Replace disable bits for @pkey with values from @flags.
> + * Kernel users use the same flags as user space:
> + * PKEY_DISABLE_ACCESS
> + * PKEY_DISABLE_WRITE
> + */
> +u32 update_pkey_val(u32 pk_reg, int pkey, unsigned int flags)
> +{
> + int pkey_shift = pkey * PKR_BITS_PER_PKEY;
> +
> + pk_reg &= ~(((1 << PKR_BITS_PER_PKEY) - 1) << pkey_shift);
> +
> + if (flags & PKEY_DISABLE_ACCESS)
> + pk_reg |= PKR_AD_BIT << pkey_shift;
> + if (flags & PKEY_DISABLE_WRITE)
> + pk_reg |= PKR_WD_BIT << pkey_shift;
I still think this deserves two lines of comments:
/* Mask out old bit values */
/* Or in new values */
Re: [PATCH RFC V3 1/9] x86/pkeys: Create pkeys_common.h
On 10/9/20 12:42 PM, ira.we...@intel.com wrote: > Protection Keys User (PKU) and Protection Keys Supervisor (PKS) work > in similar fashions and can share common defines. Could we be a bit less abstract? PKS and PKU each have: 1. A single control register 2. The same number of keys 3. The same number of bits in the register per key 4. Access and Write disable in the same bit locations That means that we can share all the macros that synthesize and manipulate register values between the two features. > +++ b/arch/x86/include/asm/pkeys_common.h > @@ -0,0 +1,11 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef _ASM_X86_PKEYS_INTERNAL_H > +#define _ASM_X86_PKEYS_INTERNAL_H > + > +#define PKR_AD_BIT 0x1 > +#define PKR_WD_BIT 0x2 > +#define PKR_BITS_PER_PKEY 2 > + > +#define PKR_AD_KEY(pkey) (PKR_AD_BIT << ((pkey) * PKR_BITS_PER_PKEY)) Now that this has moved away from its use-site, it's a bit less self-documenting. Let's add a comment: /* * Generate an Access-Disable mask for the given pkey. Several of these * can be OR'd together to generate pkey register values. */ Once that's in place, along with the updated changelog: Reviewed-by: Dave Hansen
[tip: x86/urgent] x86/traps: Fix #DE Oops message regression
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 5f1ec1fd32252af5130dac23b5542e8e66fe0bcb
Gitweb:
https://git.kernel.org/tip/5f1ec1fd32252af5130dac23b5542e8e66fe0bcb
Author:Thomas Gleixner
AuthorDate:Mon, 12 Oct 2020 15:11:47 +02:00
Committer: Borislav Petkov
CommitterDate: Tue, 13 Oct 2020 19:17:33 +02:00
x86/traps: Fix #DE Oops message regression
The conversion of #DE to the idtentry mechanism introduced a change in the
Ooops message which confuses tools which parse crash information in dmesg.
Remove the underscore from 'divide_error' to restore previous behaviour.
Fixes: 9d06c4027f21 ("x86/entry: Convert Divide Error to IDTENTRY")
Reported-by: Dmitry Vyukov
Signed-off-by: Thomas Gleixner
Cc: sta...@vger.kernel.org
Link:
https://lore.kernel.org/r/cact4y+btzfkuzd7+bparowov-7die+wzpfowneo_wgs3u59...@mail.gmail.com
---
arch/x86/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 81a2fb7..316ce1c 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -195,7 +195,7 @@ static __always_inline void __user
*error_get_trap_addr(struct pt_regs *regs)
DEFINE_IDTENTRY(exc_divide_error)
{
- do_error_trap(regs, 0, "divide_error", X86_TRAP_DE, SIGFPE,
+ do_error_trap(regs, 0, "divide error", X86_TRAP_DE, SIGFPE,
FPE_INTDIV, error_get_trap_addr(regs));
}
[tip: x86/urgent] x86/platform/uv: Remove unused variable in UV5 NMI handler
The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 081dd68c89061077930ec7776d98837cb64b0405 Gitweb: https://git.kernel.org/tip/081dd68c89061077930ec7776d98837cb64b0405 Author:Mike Travis AuthorDate:Tue, 13 Oct 2020 10:47:31 -05:00 Committer: Borislav Petkov CommitterDate: Tue, 13 Oct 2020 19:21:13 +02:00 x86/platform/uv: Remove unused variable in UV5 NMI handler Remove an unused variable. Signed-off-by: Mike Travis Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20201013154731.132565-1-mike.tra...@hpe.com --- arch/x86/platform/uv/uv_nmi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c index 0f5cbcf..eafc530 100644 --- a/arch/x86/platform/uv/uv_nmi.c +++ b/arch/x86/platform/uv/uv_nmi.c @@ -59,7 +59,6 @@ DEFINE_PER_CPU(struct uv_cpu_nmi_s, uv_cpu_nmi); static unsigned long uvh_nmi_mmrx; /* UVH_EVENT_OCCURRED0/1 */ static unsigned long uvh_nmi_mmrx_clear; /* UVH_EVENT_OCCURRED0/1_ALIAS */ static int uvh_nmi_mmrx_shift; /* UVH_EVENT_OCCURRED0/1_EXTIO_INT0_SHFT */ -static int uvh_nmi_mmrx_mask; /* UVH_EVENT_OCCURRED0/1_EXTIO_INT0_MASK */ static char *uvh_nmi_mmrx_type;/* "EXTIO_INT0" */ /* Non-zero indicates newer SMM NMI handler present */ @@ -247,7 +246,6 @@ static void uv_nmi_setup_mmrs(void) uvh_nmi_mmrx = UVH_EVENT_OCCURRED0; uvh_nmi_mmrx_clear = UVH_EVENT_OCCURRED0_ALIAS; uvh_nmi_mmrx_shift = UVH_EVENT_OCCURRED0_EXTIO_INT0_SHFT; - uvh_nmi_mmrx_mask = UVH_EVENT_OCCURRED0_EXTIO_INT0_MASK; uvh_nmi_mmrx_type = "OCRD0-EXTIO_INT0"; uvh_nmi_mmrx_supported = UVH_EXTIO_INT0_BROADCAST; @@ -258,7 +256,6 @@ static void uv_nmi_setup_mmrs(void) uvh_nmi_mmrx = UVH_EVENT_OCCURRED1; uvh_nmi_mmrx_clear = UVH_EVENT_OCCURRED1_ALIAS; uvh_nmi_mmrx_shift = UVH_EVENT_OCCURRED1_EXTIO_INT0_SHFT; - uvh_nmi_mmrx_mask = UVH_EVENT_OCCURRED1_EXTIO_INT0_MASK; uvh_nmi_mmrx_type = "OCRD1-EXTIO_INT0"; uvh_nmi_mmrx_supported = UVH_EXTIO_INT0_BROADCAST;
Re: [2/2] drm/msm: Add support for GPU cooling
On Tue, Oct 13, 2020 at 07:23:34PM +0530, Akhil P Oommen wrote:
> On 10/12/2020 11:10 PM, m...@chromium.org wrote:
> > On Mon, Oct 12, 2020 at 07:03:51PM +0530, Akhil P Oommen wrote:
> > > On 10/10/2020 12:06 AM, m...@chromium.org wrote:
> > > > Hi Akhil,
> > > >
> > > > On Thu, Oct 08, 2020 at 10:39:07PM +0530, Akhil P Oommen wrote:
> > > > > Register GPU as a devfreq cooling device so that it can be passively
> > > > > cooled by the thermal framework.
> > > > >
> > > > > Signed-off-by: Akhil P Oommen
> > > > > ---
> > > > >drivers/gpu/drm/msm/msm_gpu.c | 13 -
> > > > >drivers/gpu/drm/msm/msm_gpu.h | 2 ++
> > > > >2 files changed, 14 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/msm_gpu.c
> > > > > b/drivers/gpu/drm/msm/msm_gpu.c
> > > > > index 55d1648..93ffd66 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > > > > @@ -14,6 +14,7 @@
> > > > >#include
> > > > >#include
> > > > >#include
> > > > > +#include
> > > > >#include
> > > > >#include
> > > > > @@ -107,9 +108,18 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
> > > > > if (IS_ERR(gpu->devfreq.devfreq)) {
> > > > > DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
> > > > > devfreq\n");
> > > > > gpu->devfreq.devfreq = NULL;
> > > > > + return;
> > > > > }
> > > > > devfreq_suspend_device(gpu->devfreq.devfreq);
> > > > > +
> > > > > + gpu->cooling =
> > > > > of_devfreq_cooling_register(gpu->pdev->dev.of_node,
> > > > > + gpu->devfreq.devfreq);
> > > > > + if (IS_ERR(gpu->cooling)) {
> > > > > + DRM_DEV_ERROR(>pdev->dev,
> > > > > + "Couldn't register GPU cooling
> > > > > device\n");
> > > > > + gpu->cooling = NULL;
> > > > > + }
> > > > >}
> > > > >static int enable_pwrrail(struct msm_gpu *gpu)
> > > > > @@ -926,7 +936,6 @@ int msm_gpu_init(struct drm_device *drm, struct
> > > > > platform_device *pdev,
> > > > > msm_devfreq_init(gpu);
> > > > > -
> Will remove this unintended change.
> > > > > gpu->aspace = gpu->funcs->create_address_space(gpu, pdev);
> > > > > if (gpu->aspace == NULL)
> > > > > @@ -1005,4 +1014,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
> > > > > gpu->aspace->mmu->funcs->detach(gpu->aspace->mmu);
> > > > > msm_gem_address_space_put(gpu->aspace);
> > > > > }
> > > > > +
> > > > > + devfreq_cooling_unregister(gpu->cooling);
> > > >
> > > > Resources should be released in reverse order, otherwise the cooling
> > > > device
> > > > could use resources that have already been freed.
> > > > Why do you think this is not the correct order? If you are thinking
> > > about devfreq struct, it is managed device resource.
> >
> > I did not check specifically if changing the frequency really uses any of
> > the
> > resources that are released previously, In any case it's not a good idea to
> > allow other parts of the kernel to use a half initialized/torn down device.
> > Even if it isn't a problem today someone could change the driver to use any
> > of these resources (or add a new one) in a frequency change, without even
> > thinking about the cooling device, just (rightfully) asuming that things are
> > set up and torn down in a sane order.
> 'sane order' relative to what specifically here? Should we worry about freq
> change at this point because we have already disabled gpu runtime pm and
> devfreq?
GPU runtime PM and the devfreq being disabled is not evident from the context
of the function. You are probably right that it's not a problem in practice,
but why give reason for doubts in the first place if this could be avoided
by following a common practice?
[GIT PULL] x86/urgent for v5.10-rc1
Hi Linus, here's the clang build warning fix from yesterday which is finally ready. I've added a second one from the tip's urgent queue which could go in now too. Please pull, thx. --- The following changes since commit 8b6591fd0ac8b7e8b2873703bc24b71a6f3d2d3e: Merge tag 'x86_platform_for_v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2020-10-12 10:31:18 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_urgent_for_v5.10-rc1 for you to fetch changes up to 081dd68c89061077930ec7776d98837cb64b0405: x86/platform/uv: Remove unused variable in UV5 NMI handler (2020-10-13 19:21:13 +0200) - Fix the #DE oops message string format which confused tools parsing crash information. (Thomas Gleixner) - Remove an unused variable in the UV5 code which was triggering a build warning with clang. (Mike Travis) Mike Travis (1): x86/platform/uv: Remove unused variable in UV5 NMI handler Thomas Gleixner (1): x86/traps: Fix #DE Oops message regression arch/x86/kernel/traps.c | 2 +- arch/x86/platform/uv/uv_nmi.c | 3 --- 2 files changed, 1 insertion(+), 4 deletions(-) -- Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
[GIT PULL] PNP updates for v5.10-rc1
Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pnp-5.10-rc1 with top-most commit 2ef0342530b0f487a65b5f6c94c85dce5f9b53b5 PNP: remove the now unused pnp_find_card() function on top of commit ba4f184e126b751d1bffad5897f263108befc780 Linux 5.9-rc6 to receive PNP updates for 5.10-rc1. These clean the PNP code somewhat: - Remove the now unused pnp_find_card() function (Christoph Hellwig). - Drop duplicate pci.h include from the quirks code and add an "internal.h" include to acpi_pnp.c to fix a compiler warning (Tian Tao). Thanks! --- Christoph Hellwig (1): PNP: remove the now unused pnp_find_card() function Tian Tao (2): PNP: quirks: Fix duplicate included pci.h PNP: ACPI: Fix missing-prototypes in acpi_pnp.c --- Documentation/admin-guide/pnp.rst | 4 drivers/acpi/acpi_pnp.c | 2 ++ drivers/pnp/isapnp/compat.c | 23 --- drivers/pnp/quirks.c | 2 -- include/linux/isapnp.h| 6 -- 5 files changed, 2 insertions(+), 35 deletions(-)
Re: [PATCH v3 2/2] arm64: dts: rockchip: Add basic support for Kobol's Helios64
Hi Uwe,
Part 1 of 2 missing here.
Submit all patches to all maintainers and mail lists.
Don't forget robh+dt !
./scripts/get_maintainer.pl --noroles --norolestats --nogit-fallback
--nogit
git send-email --suppress-cc all --annotate --to <..> --cc <..>
On 10/13/20 6:13 PM, Uwe Kleine-König wrote:
> The hardware is described in detail on Kobol's wiki at
> https://wiki.kobol.io/helios64/intro/.
>
> Up to now the following peripherals are working:
>
> - UART
> - Micro-SD card
> - eMMC
> - ethernet port 1
> - status LED
> - temperature sensor on i2c bus 2
>
> Signed-off-by: Uwe Kleine-König
> ---
Add a little change log here.
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../dts/rockchip/rk3399-kobol-helios64.dts| 378 ++
> 2 files changed, 379 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> b/arch/arm64/boot/dts/rockchip/Makefile
> index b87b1f773083..ddf07c5e5f7c 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -24,6 +24,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-hugsun-x99.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-kobol-helios64.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
> new file mode 100644
> index ..98a2bbed8c14
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
> @@ -0,0 +1,378 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2020 Aditya Prayoga
> + */
> +
> +/*
> + * The Kobol Helios64 is a board designed to operate as a NAS and optionally
> + * ships with an enclosing that can host five 2.5" hard disks.
> + *
> + * See https://wiki.kobol.io/helios64/intro/ for further details.
> + */
> +
> +/dts-v1/;
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Kobol Helios64";
> + compatible = "kobol,helios64", "rockchip,rk3399";
> +
> + avdd_1v8_s0: avdd-1v8-s0 {
> + compatible = "regulator-fixed";
> + regulator-name = "avdd_1v8_s0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + vin-supply = <_sys_s3>;
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <12500>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_led _led>;
sort
> +
> + fault-led {
fault_led: led-0 {}
My fault.
Change ones more...
# The first form is preferred, but fall back to just 'led' anywhere in the
# node name to at least catch some child nodes.
"(^led-[0-9a-f]$|led)":
> + label = "helios64:red:fault";
> + gpios = < RK_PB5 GPIO_ACTIVE_HIGH>;
> + default-state = "keep";
> + };
> +
> + status-led {
status_led: led-1 {}
> + label = "helios64:green:status";
> + gpios = < RK_PB4 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "none";
Don't use 'none' for mainline.
> + default-state = "on";
> + };
> + };
> +
> + vcc1v8_sys_s0: vcc1v8-sys-s0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc1v8_sys_s0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + vin-supply = <_sys_s3>;
> + };
> +
> + vcc3v0_sd: vcc3v0-sd {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v0_sd";
Doesn't a sd card need a on/off gpio?
Could you check the schematics?
> + regulator-boot-on;
> + regulator-min-microvolt = <300>;
> + regulator-max-microvolt = <300>;
> + vin-supply = <_sys_s3>;
> + };
> +
> + vcc3v3_sys_s3: vcc_lan: vcc3v3-sys-s3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_sys_s3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <330>;
> +
[GIT PULL] ACPI updates for v5.10-rc1
Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-5.10-rc1 with top-most commit 8be2362d10e8b0ea9844706d8c388480d37226d2 Merge branches 'acpi-extlog', 'acpi-memhotplug', 'acpi-button', 'acpi-tools' and 'acpi-pci' on top of commit 549738f15da0e5a00275977623be199fbbf7df50 Linux 5.9-rc8 to receive ACPI updates for 5.10-rc1. These add support for generic initiator-only proximity domains to the ACPI NUMA code and the architectures using it, clean up some non-ACPICA code referring to debug facilities from ACPICA, reduce the overhead related to accessing GPE registers, add a new DPTF (Dynamic Power and Thermal Framework) participant driver, update the ACPICA code in the kernel to upstream revision 20200925, add a new ACPI backlight whitelist entry, fix a few assorted issues and clean up some code. Specifics: - Add support for generic initiator-only proximity domains to the ACPI NUMA code and the architectures using it (Jonathan Cameron). - Clean up some non-ACPICA code referring to debug facilities from ACPICA that are not actually used in there (Hanjun Guo). - Add new DPTF driver for the PCH FIVR participant (Srinivas Pandruvada). - Reduce overhead related to accessing GPE registers in ACPICA and the OS interface layer and make it possible to access GPE registers using logical addresses if they are memory-mapped (Rafael Wysocki). - Update the ACPICA code in the kernel to upstream revision 20200925 including changes as follows: * Add predefined names from the SMBus specification (Bob Moore). * Update acpi_help UUID list (Bob Moore). * Return exceptions for string-to-integer conversions in iASL (Bob Moore). * Add a new "ALL " debugger command (Bob Moore). * Add support for 64 bit risc-v compilation (Colin Ian King). * Do assorted cleanups (Bob Moore, Colin Ian King, Randy Dunlap). - Add new ACPI backlight whitelist entry for HP 635 Notebook (Alex Hung). - Move TPS68470 OpRegion driver to drivers/acpi/pmic/ and split out Kconfig and Makefile specific for ACPI PMIC (Andy Shevchenko). - Clean up the ACPI SoC driver for AMD SoCs (Hanjun Guo). - Add missing config_item_put() to fix refcount leak (Hanjun Guo). - Drop leftover field from struct acpi_memory_device (Hanjun Guo). - Make the ACPI extlog driver check for RDMSR failures (Ben Hutchings). - Fix handling of lid state changes in the ACPI button driver when input device is closed (Dmitry Torokhov). - Fix several assorted build issues (Barnabás Pőcze, John Garry, Nathan Chancellor, Tian Tao). - Drop unused inline functions and reduce code duplication by using kobj_to_dev() in the NFIT parsing code (YueHaibing, Wang Qing). - Serialize tools/power/acpi Makefile (Thomas Renninger). Thanks! --- Alex Hung (1): ACPI: video: use ACPI backlight for HP 635 Notebook Andy Shevchenko (3): ACPI / PMIC: Split out Kconfig and Makefile specific for ACPI PMIC ACPI / PMIC: Move TPS68470 OpRegion driver to drivers/acpi/pmic/ MAINTAINERS: Use my kernel.org address for Intel PMIC work Barnabás Pőcze (1): ACPI: battery: include linux/power_supply.h Ben Hutchings (1): ACPI / extlog: Check for RDMSR failure Bob Moore (6): ACPICA: Add predefined names found in the SMBus sepcification ACPICA: acpi_help: Update UUID list ACPICA: iASL: Return exceptions for string-to-integer conversions ACPICA: Debugger: Add a new command: "ALL " ACPICA: Remove unnecessary semicolon ACPICA: Update version to 20200925 Version 20200925 Colin Ian King (2): ACPICA: Add support for 64 bit risc-v compilation ACPICA: Tree-wide: fix various typos and spelling mistakes Dmitry Torokhov (1): ACPI: button: fix handling lid state changes when input device closed Hanjun Guo (22): ACPI: APD: Add kerneldoc for properties in struct apd_device_desc ACPI: APD: Remove flags from struct apd_device_desc ACPI: APD: Remove ACPI_MODULE_NAME() ACPI: APD: Remove unnecessary APD_ADDR() macro stub ACPI: APD: Clean up header file include statements ACPI: configfs: Add missing config_item_put() to fix refcount leak ACPI: cmos_rtc: Remove leftover ACPI_MODULE_NAME() ACPI: LPSS: Remove ACPI_MODULE_NAME() ACPI: memhotplug: Remove leftover ACPICA debug functionality ACPI: platform: Remove ACPI_MODULE_NAME() ACPI: container: Remove leftover ACPICA debug functionality ACPI: custom_method: Remove dead ACPICA debug code ACPI: debugfs: Remove dead ACPICA debug code ACPI: dock: Remove dead ACPICA debug code ACPI: event: Remove leftover ACPICA debug code ACPI: PCI: Remove unused ACPICA debug code ACPI: proc: Remove dead ACPICA debug code ACPI: processor: Remove dead ACPICA debug code ACPI: tiny-power-button: Remove dead ACPICA debug code ACPI: video: Remove
Re: [PATCH 6/6] dt-bindings: misc: correct the property name cmd-gpios to cmd-gpio
Zhen On 10/13/20 11:08 AM, Zhen Lei wrote: The property name used in arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts is cmd-gpio. arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:235: cmd-gpio = < 155 GPIO_ACTIVE_HIGH>; Signed-off-by: Zhen Lei --- Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml index b3c45c046ba5e37..c7a06a9650db2ed 100644 --- a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml +++ b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml @@ -24,7 +24,7 @@ properties: compatible: const: olpc,xo1.75-ec - cmd-gpios: + cmd-gpio: Preference is gpios not gpio. But Rob H accept or reject Dan
[GIT PULL] Power management updates for v5.10-rc1
Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-5.10-rc1 with top-most commit 16641d81f9ff5f902d084754c84b2bde3a60bc6e Merge branches 'pm-avs' and 'powercap' on top of commit 549738f15da0e5a00275977623be199fbbf7df50 Linux 5.9-rc8 to receive power management updates for 5.10-rc1. These rework the collection of cpufreq statistics to allow it to take place if fast frequency switching is enabled in the governor, rework the frequency invariance handling in the cpufreq core and drivers, add new hardware support to a couple of cpufreq drivers, fix a number of assorted issues and clean up the code all over. Specifics: - Rework cpufreq statistics collection to allow it to take place when fast frequency switching is enabled in the governor (Viresh Kumar). - Make the cpufreq core set the frequency scale on behalf of the driver and update several cpufreq drivers accordingly (Ionela Voinescu, Valentin Schneider). - Add new hardware support to the STI and qcom cpufreq drivers and improve them (Alain Volmat, Manivannan Sadhasivam). - Fix multiple assorted issues in cpufreq drivers (Jon Hunter, Krzysztof Kozlowski, Matthias Kaehlcke, Pali Rohár, Stephan Gerhold, Viresh Kumar). - Fix several assorted issues in the operating performance points (OPP) framework (Stephan Gerhold, Viresh Kumar). - Allow devfreq drivers to fetch devfreq instances by DT enumeration instead of using explicit phandles and modify the devfreq core code to support driver-specific devfreq DT bindings (Leonard Crestez, Chanwoo Choi). - Improve initial hardware resetting in the tegra30 devfreq driver and clean up the tegra cpuidle driver (Dmitry Osipenko). - Update the cpuidle core to collect state entry rejection statistics and expose them via sysfs (Lina Iyer). - Improve the ACPI _CST code handling diagnostics (Chen Yu). - Update the PSCI cpuidle driver to allow the PM domain initialization to occur in the OSI mode as well as in the PC mode (Ulf Hansson). - Rework the generic power domains (genpd) core code to allow domain power off transition to be aborted in the absence of the "power off" domain callback (Ulf Hansson). - Fix two suspend-to-idle issues in the ACPI EC driver (Rafael Wysocki). - Fix the handling of timer_expires in the PM-runtime framework on 32-bit systems and the handling of device links in it (Grygorii Strashko, Xiang Chen). - Add IO requests batching support to the hibernate image saving and reading code and drop a bogus get_gendisk() from there (Xiaoyi Chen, Christoph Hellwig). - Allow PCIe ports to be put into the D3cold power state if they are power-manageable via ACPI (Lukas Wunner). - Add missing header file include to a power capping driver (Pujin Shi). - Clean up the qcom-cpr AVS driver a bit (Liu Shixin). - Kevin Hilman steps down as designated reviewer of adaptive voltage scaling (AVS) drivers (Kevin Hilman). Note that because of the Kevin Hilman's resignation (so long, and thanks for all the fish Kevin!), the maintenance of AVS drivers is expected to be transferred to arm-soc. Thanks! --- Alain Volmat (3): cpufreq: sti-cpufreq: add stih418 support cpufreq: dt-platdev: Blacklist st,stih418 SoC cpufreq: arm: Kconfig: add CPUFREQ_DT depend for STI CPUFREQ Chanwoo Choi (2): PM / devfreq: Change prototype of devfreq_get_devfreq_by_phandle function PM / devfreq: event: Change prototype of devfreq_event_get_edev_by_phandle function Chen Yu (1): ACPI: processor: Print more information when acpi_processor_evaluate_cst() fails Christoph Hellwig (1): PM: hibernate: remove the bogus call to get_gendisk() in software_resume() Dmitry Osipenko (2): cpuidle: tegra: Correctly handle result of arm_cpuidle_simple_enter() PM / devfreq: tegra30: Improve initial hardware resetting Grygorii Strashko (1): PM: runtime: Fix timer_expires data type on 32-bit arches Ionela Voinescu (5): arch_topology: validate input frequencies to arch_set_freq_scale() cpufreq: move invariance setter calls in cpufreq core cpufreq: report whether cpufreq supports Frequency Invariance (FI) cpufreq,arm,arm64: restructure definitions of arch_set_freq_scale() arm: disable frequency invariance for CONFIG_BL_SWITCHER Jon Hunter (1): cpufreq: tegra186: Fix initial frequency Kevin Hilman (1): MAINTAINERS: drop myself from PM AVS drivers Krzysztof Kozlowski (2): cpufreq: s5pv210: Simplify with dev_err_probe() cpufreq: s5pv210: Use dev_err instead of pr_err in probe Leonard Crestez (1): PM / devfreq: Add devfreq_get_devfreq_by_node function Lina Iyer (1): cpuidle: record state entry rejection statistics Liu Shixin (1): PM: AVS: qcom-cpr: simplify the return expression of cpr_disable() Lukas Wunner (1): PCI/ACPI: Whitelist hotplug
[PATCH 2/2] drm/mediatek: mtk_hdmi: add MT8167 support for HDMI
Add support for HDMI on MT8167. HDMI on MT8167 is similar to
MT8173/MT2701 execpt for the two registers: SYS_CFG1C and SYS_CFG20
Signed-off-by: Fabien Parent
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +++
drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index c70f195c21be..7762be5cb446 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1835,9 +1835,16 @@ static struct mtk_hdmi_data mt8173_hdmi_driver_data = {
.sys_cfg20 = HDMI_SYS_CFG20,
};
+static struct mtk_hdmi_conf mt8167_hdmi_driver_data = {
+ .sys_cfg1c = MT8167_HDMI_SYS_CFG1C,
+ .sys_cfg20 = MT8167_HDMI_SYS_CFG20,
+};
+
static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
{ .compatible = "mediatek,mt8173-hdmi",
.data = _hdmi_driver_data },
+ { .compatible = "mediatek,mt8167-hdmi",
+ .data = _hdmi_driver_data },
{}
};
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
index 2050ba45b23a..a0f9c367d7aa 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
@@ -195,6 +195,7 @@
#define GEN_RGB(0 << 7)
#define HDMI_SYS_CFG1C 0x000
+#define MT8167_HDMI_SYS_CFG1C 0x800
#define HDMI_ONBIT(0)
#define HDMI_RST BIT(1)
#define ANLG_ONBIT(2)
@@ -211,6 +212,7 @@
#define HTPLG_PIN_SEL_OFF BIT(30)
#define AES_EFUSE_ENABLE BIT(31)
#define HDMI_SYS_CFG20 0x004
+#define MT8167_HDMI_SYS_CFG20 0x804
#define DEEP_COLOR_MODE_MASK (3 << 1)
#define COLOR_8BIT_MODE(0 << 1)
#define COLOR_10BIT_MODE (1 << 1)
--
2.28.0
[PATCH 1/2] drm/mediatek: mtk_hdmi: move 2 registers address into of_data
On MT8167, the two registers SYS_CFG1C and SYS_CFG20 don't have the
same address as on MT8173. Add OF data in order to store the address
of these two registers.
Signed-off-by: Fabien Parent
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 45 ++---
1 file changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index a97725680d4e..c70f195c21be 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -36,6 +36,11 @@
#define NCTS_BYTES 7
+struct mtk_hdmi_data {
+ uint32_t sys_cfg1c;
+ uint32_t sys_cfg20;
+};
+
enum mtk_hdmi_clk_id {
MTK_HDMI_CLK_HDMI_PIXEL,
MTK_HDMI_CLK_HDMI_PLL,
@@ -146,6 +151,7 @@ struct hdmi_audio_param {
};
struct mtk_hdmi {
+ const struct mtk_hdmi_data *data;
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
struct drm_connector conn;
@@ -244,21 +250,24 @@ static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi
*hdmi, bool enable)
*/
if (hdmi_phy->conf && hdmi_phy->conf->tz_disabled)
regmap_update_bits(hdmi->sys_regmap,
- hdmi->sys_offset + HDMI_SYS_CFG20,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
0x80008005, enable ? 0x8005 : 0x8000);
else
arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904,
0x8000, 0, 0, 0, 0, 0, );
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_ON | ANLG_ON, enable ? (HDMI_ON | ANLG_ON) : 0);
}
static void mtk_hdmi_hw_1p4_version_enable(struct mtk_hdmi *hdmi, bool enable)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI2P0_EN, enable ? 0 : HDMI2P0_EN);
}
@@ -274,12 +283,15 @@ static void mtk_hdmi_hw_aud_unmute(struct mtk_hdmi *hdmi)
static void mtk_hdmi_hw_reset(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_RST, HDMI_RST);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
HDMI_RST, 0);
mtk_hdmi_clear_bits(hdmi, GRL_CFG3, CFG3_CONTROL_PACKET_DELAY);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg1c,
ANLG_ON, ANLG_ON);
}
@@ -362,16 +374,19 @@ static void mtk_hdmi_hw_send_aud_packet(struct mtk_hdmi
*hdmi, bool enable)
static void mtk_hdmi_hw_config_sys(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_OUT_FIFO_EN | MHL_MODE_ON, 0);
usleep_range(2000, 4000);
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
HDMI_OUT_FIFO_EN | MHL_MODE_ON, HDMI_OUT_FIFO_EN);
}
static void mtk_hdmi_hw_set_deep_color_mode(struct mtk_hdmi *hdmi)
{
- regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + hdmi->data->sys_cfg20,
DEEP_COLOR_MODE_MASK | DEEP_COLOR_EN,
COLOR_8BIT_MODE);
}
@@ -1733,6 +1748,7 @@ static int mtk_drm_hdmi_probe(struct platform_device
*pdev)
return -ENOMEM;
hdmi->dev = dev;
+ hdmi->conf = of_device_get_match_data(dev);
ret = mtk_hdmi_dt_parse_pdata(hdmi, pdev);
if (ret)
@@ -1813,8 +1829,15 @@ static int mtk_hdmi_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_hdmi_pm_ops,
mtk_hdmi_suspend, mtk_hdmi_resume);
+
+static struct mtk_hdmi_data
Re: [PATCH v2] kcov, usbip: collect coverage from vhci_rx_loop
On 10/12/20 11:10 AM, Andrey Konovalov wrote:
From: Nazime Hande Harputluoglu
Add kcov_remote_start()/kcov_remote_stop() annotations to the
vhci_rx_loop() function, which is responsible for parsing USB/IP packets
coming into USB/IP client.
Since vhci_rx_loop() threads are spawned per vhci_hcd device instance, the
common kcov handle is used for kcov_remote_start()/stop() annotations
(see Documentation/dev-tools/kcov.rst for details). As the result kcov
can now be used to collect coverage from vhci_rx_loop() threads.
Signed-off-by: Nazime Hande Harputluoglu
---
Changes v1->v2:
- Fix spacing issues.
- Add ifdef CONFIG_KCOV around kcov_handle in usbip_device struct.
Does this compile without CONFIG_KCOV?
---
drivers/usb/usbip/usbip_common.h | 4
drivers/usb/usbip/vhci_rx.c | 3 +++
drivers/usb/usbip/vhci_sysfs.c | 12 +++-
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/usbip/usbip_common.h b/drivers/usb/usbip/usbip_common.h
index 8be857a4fa13..0906182011d6 100644
--- a/drivers/usb/usbip/usbip_common.h
+++ b/drivers/usb/usbip/usbip_common.h
@@ -277,6 +277,10 @@ struct usbip_device {
void (*reset)(struct usbip_device *);
void (*unusable)(struct usbip_device *);
} eh_ops;
+
+#ifdef CONFIG_KCOV
+ u64 kcov_handle;
+#endif
};
#define kthread_get_run(threadfn, data, namefmt, ...) \
diff --git a/drivers/usb/usbip/vhci_rx.c b/drivers/usb/usbip/vhci_rx.c
index 266024cbb64f..473f14587bd5 100644
--- a/drivers/usb/usbip/vhci_rx.c
+++ b/drivers/usb/usbip/vhci_rx.c
@@ -3,6 +3,7 @@
* Copyright (C) 2003-2008 Takahiro Hirofuchi
*/
+#include
#include
#include
@@ -261,7 +262,9 @@ int vhci_rx_loop(void *data)
if (usbip_event_happened(ud))
break;
+ kcov_remote_start_common(ud->kcov_handle);
You are referencing kcov_handle defined in CONFIG_KCOV scope
here. Does this compile for you without CONFIG_KCOV?
vhci_rx_pdu(ud);
+ kcov_remote_stop();
}
return 0;
diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
index be37aec250c2..966f1f5cafb1 100644
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -4,6 +4,7 @@
* Copyright (C) 2015-2016 Nobuo Iwata
*/
+#include
#include
#include
#include
@@ -378,11 +379,12 @@ static ssize_t attach_store(struct device *dev, struct
device_attribute *attr,
dev_info(dev, "devid(%u) speed(%u) speed_str(%s)\n",
devid, speed, usb_speed_string(speed));
- vdev->devid = devid;
- vdev->speed = speed;
- vdev->ud.sockfd = sockfd;
- vdev->ud.tcp_socket = socket;
- vdev->ud.status = VDEV_ST_NOTASSIGNED;
+ vdev->devid = devid;
+ vdev->speed = speed;
+ vdev->ud.sockfd = sockfd;
+ vdev->ud.tcp_socket = socket;
+ vdev->ud.status = VDEV_ST_NOTASSIGNED;
+ vdev->ud.kcov_handle = kcov_common_handle();
Don't change spacing for other variables. Add just the new
code. Don't you need CONFIG_KCOV around this new code?
spin_unlock(>ud.lock);
spin_unlock_irqrestore(>lock, flags);
thanks,
-- Shuah
Re: [PATCH v6 35/80] docs: fs: fscrypt.rst: get rid of :c:type: tags
On Tue, Oct 13, 2020 at 01:53:50PM +0200, Mauro Carvalho Chehab wrote: > The :c:type: tag has problems with Sphinx 3.x, as structs > there should be declared with c:struct. > > So, remove them, relying at automarkup.py extension to > convert them into cross-references. > > Signed-off-by: Mauro Carvalho Chehab I left some comments on v5 which weren't addressed. - Eric
Re: [PATCH 1/2] dt-bindings: iio: adc: auxadc: add doc for MT8516 SoC
On Mon, 12 Oct 2020 22:52:17 +0200, Fabien Parent wrote: > Add documentation for the auxadc binding for MT8516 SoC. > > Signed-off-by: Fabien Parent > --- > Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
[PATCH] f2fs_io: add erase option
f2fs_io erase [block_device_path]
Signed-off-by: Ocean Chen
---
tools/f2fs_io/f2fs_io.c | 53 -
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/tools/f2fs_io/f2fs_io.c b/tools/f2fs_io/f2fs_io.c
index 1ca82f1..cef32b1 100644
--- a/tools/f2fs_io/f2fs_io.c
+++ b/tools/f2fs_io/f2fs_io.c
@@ -24,13 +24,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
#include
-#include
#include
#include
#include
@@ -432,6 +432,56 @@ static void do_fallocate(int argc, char **argv, const
struct cmd_desc *cmd)
exit(0);
}
+#define erase_desc "erase a block device"
+#define erase_help \
+"f2fs_io erase [block_device_path]\n\n"\
+"Send DISCARD | BLKSECDISCARD comamnd to" \
+"block device in block_device_path\n" \
+
+static void do_erase(int argc, char **argv, const struct cmd_desc *cmd)
+{
+ int fd, ret;
+ struct stat st;
+ u64 range[2];
+
+ if (argc != 2) {
+ fputs("Excess arguments\n\n", stderr);
+ fputs(cmd->cmd_help, stderr);
+ exit(1);
+ }
+
+ if (stat(argv[1], ) != 0) {
+ fputs("stat error\n", stderr);
+ exit(1);
+ }
+
+ if (!S_ISBLK(st.st_mode)) {
+ fputs(argv[1], stderr);
+ fputs(" is not a block device\n", stderr);
+ exit(1);
+ }
+
+ fd = xopen(argv[1], O_WRONLY, 0);
+
+ range[0] = 0;
+ ret = ioctl(fd, BLKGETSIZE64, [1]);
+ if (ret < 0) {
+ fputs("get size failed\n", stderr);
+ exit(1);
+ }
+
+ ret = ioctl(fd, BLKSECDISCARD, );
+ if (ret < 0) {
+ ret = ioctl(fd, BLKDISCARD, );
+ if (ret < 0) {
+ fputs("Discard failed\n", stderr);
+ exit(1);
+ }
+ }
+
+ exit(0);
+}
+
#define write_desc "write data into file"
#define write_help \
"f2fs_io write [chunk_size in 4kb] [offset in chunk_size] [count] [pattern]
[IO] [file_path]\n\n" \
@@ -951,6 +1001,7 @@ const struct cmd_desc cmd_list[] = {
CMD(shutdown),
CMD(pinfile),
CMD(fallocate),
+ CMD(erase),
CMD(write),
CMD(read),
CMD(randread),
--
2.28.0.1011.ga647a8990f-goog
Re: [PATCH 1/3] dt-bindings: qcom_nandc: IPQ6018 QPIC NAND documentation
On Tue, 13 Oct 2020 10:45:22 +0530, Kathiravan T wrote: > Add the binding for the QPIC NAND used on IPQ6018 SoC. > > Signed-off-by: Kathiravan T > --- > Documentation/devicetree/bindings/mtd/qcom_nandc.txt | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
[PATCH] interconnect: qcom: Simplify the vcd compare function
Let's simplify the cmp_vcd() function and replace the conditionals
with just a single statement, which also improves readability.
Signed-off-by: Georgi Djakov
---
drivers/interconnect/qcom/bcm-voter.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/interconnect/qcom/bcm-voter.c
b/drivers/interconnect/qcom/bcm-voter.c
index 887d13721e52..1cc565bce2f4 100644
--- a/drivers/interconnect/qcom/bcm-voter.c
+++ b/drivers/interconnect/qcom/bcm-voter.c
@@ -41,17 +41,10 @@ struct bcm_voter {
static int cmp_vcd(void *priv, struct list_head *a, struct list_head *b)
{
- const struct qcom_icc_bcm *bcm_a =
- list_entry(a, struct qcom_icc_bcm, list);
- const struct qcom_icc_bcm *bcm_b =
- list_entry(b, struct qcom_icc_bcm, list);
-
- if (bcm_a->aux_data.vcd < bcm_b->aux_data.vcd)
- return -1;
- else if (bcm_a->aux_data.vcd == bcm_b->aux_data.vcd)
- return 0;
- else
- return 1;
+ const struct qcom_icc_bcm *bcm_a = list_entry(a, struct qcom_icc_bcm,
list);
+ const struct qcom_icc_bcm *bcm_b = list_entry(b, struct qcom_icc_bcm,
list);
+
+ return bcm_a->aux_data.vcd - bcm_b->aux_data.vcd;
}
static u64 bcm_div(u64 num, u32 base)
[PATCH 2/2] Revert "dccp: don't free ccid2_hc_tx_sock struct in dccp_disconnect()"
From: Thadeu Lima de Souza Cascardo This reverts commit 2677d20677314101293e6da0094ede7b5526d2b1. This fixes an issue that after disconnect, dccps_hc_tx_ccid will still be kept, allowing the socket to be reused as a listener socket, and the cloned socket will free its dccps_hc_tx_ccid, leading to a later use after free, when the listener socket is closed. This addresses CVE-2020-16119. Fixes: 2677d2067731 (dccp: don't free ccid2_hc_tx_sock struct in dccp_disconnect()) Reported-by: Hadar Manor Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Kleber Sacilotto de Souza --- net/dccp/proto.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/dccp/proto.c b/net/dccp/proto.c index 6d705d90c614..359e848dba6c 100644 --- a/net/dccp/proto.c +++ b/net/dccp/proto.c @@ -279,7 +279,9 @@ int dccp_disconnect(struct sock *sk, int flags) dccp_clear_xmit_timers(sk); ccid_hc_rx_delete(dp->dccps_hc_rx_ccid, sk); + ccid_hc_tx_delete(dp->dccps_hc_tx_ccid, sk); dp->dccps_hc_rx_ccid = NULL; + dp->dccps_hc_tx_ccid = NULL; __skb_queue_purge(>sk_receive_queue); __skb_queue_purge(>sk_write_queue); -- 2.25.1
[PATCH 1/2] dccp: ccid: move timers to struct dccp_sock
From: Thadeu Lima de Souza Cascardo
When dccps_hc_tx_ccid is freed, ccid timers may still trigger. The reason
del_timer_sync can't be used is because this relies on keeping a reference
to struct sock. But as we keep a pointer to dccps_hc_tx_ccid and free that
during disconnect, the timer should really belong to struct dccp_sock.
This addresses CVE-2020-16119.
Fixes: 839a6094140a (net: dccp: Convert timers to use timer_setup())
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Kleber Sacilotto de Souza
---
include/linux/dccp.h | 2 ++
net/dccp/ccids/ccid2.c | 32 +++-
net/dccp/ccids/ccid3.c | 30 --
3 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/include/linux/dccp.h b/include/linux/dccp.h
index 07e547c02fd8..504afa1a4be6 100644
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -259,6 +259,7 @@ struct dccp_ackvec;
* @dccps_sync_scheduled - flag which signals "send out-of-band message soon"
* @dccps_xmitlet - tasklet scheduled by the TX CCID to dequeue data packets
* @dccps_xmit_timer - used by the TX CCID to delay sending (rate-based pacing)
+ * @dccps_ccid_timer - used by the CCIDs
* @dccps_syn_rtt - RTT sample from Request/Response exchange (in usecs)
*/
struct dccp_sock {
@@ -303,6 +304,7 @@ struct dccp_sock {
__u8dccps_sync_scheduled:1;
struct tasklet_struct dccps_xmitlet;
struct timer_list dccps_xmit_timer;
+ struct timer_list dccps_ccid_timer;
};
static inline struct dccp_sock *dccp_sk(const struct sock *sk)
diff --git a/net/dccp/ccids/ccid2.c b/net/dccp/ccids/ccid2.c
index 3da1f77bd039..dbca1f1e2449 100644
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids/ccid2.c
@@ -126,21 +126,26 @@ static void dccp_tasklet_schedule(struct sock *sk)
static void ccid2_hc_tx_rto_expire(struct timer_list *t)
{
- struct ccid2_hc_tx_sock *hc = from_timer(hc, t, tx_rtotimer);
- struct sock *sk = hc->sk;
- const bool sender_was_blocked = ccid2_cwnd_network_limited(hc);
+ struct dccp_sock *dp = from_timer(dp, t, dccps_ccid_timer);
+ struct sock *sk = (struct sock *)dp;
+ struct ccid2_hc_tx_sock *hc;
+ bool sender_was_blocked;
bh_lock_sock(sk);
+
+ if (inet_sk_state_load(sk) == DCCP_CLOSED)
+ goto out;
+
+ hc = ccid_priv(dp->dccps_hc_tx_ccid);
+ sender_was_blocked = ccid2_cwnd_network_limited(hc);
+
if (sock_owned_by_user(sk)) {
- sk_reset_timer(sk, >tx_rtotimer, jiffies + HZ / 5);
+ sk_reset_timer(sk, >dccps_ccid_timer, jiffies + HZ / 5);
goto out;
}
ccid2_pr_debug("RTO_EXPIRE\n");
- if (sk->sk_state == DCCP_CLOSED)
- goto out;
-
/* back-off timer */
hc->tx_rto <<= 1;
if (hc->tx_rto > DCCP_RTO_MAX)
@@ -166,7 +171,7 @@ static void ccid2_hc_tx_rto_expire(struct timer_list *t)
if (sender_was_blocked)
dccp_tasklet_schedule(sk);
/* restart backed-off timer */
- sk_reset_timer(sk, >tx_rtotimer, jiffies + hc->tx_rto);
+ sk_reset_timer(sk, >dccps_ccid_timer, jiffies + hc->tx_rto);
out:
bh_unlock_sock(sk);
sock_put(sk);
@@ -330,7 +335,7 @@ static void ccid2_hc_tx_packet_sent(struct sock *sk,
unsigned int len)
}
#endif
- sk_reset_timer(sk, >tx_rtotimer, jiffies + hc->tx_rto);
+ sk_reset_timer(sk, >dccps_ccid_timer, jiffies + hc->tx_rto);
#ifdef CONFIG_IP_DCCP_CCID2_DEBUG
do {
@@ -700,9 +705,9 @@ static void ccid2_hc_tx_packet_recv(struct sock *sk, struct
sk_buff *skb)
/* restart RTO timer if not all outstanding data has been acked */
if (hc->tx_pipe == 0)
- sk_stop_timer(sk, >tx_rtotimer);
+ sk_stop_timer(sk, >dccps_ccid_timer);
else
- sk_reset_timer(sk, >tx_rtotimer, jiffies + hc->tx_rto);
+ sk_reset_timer(sk, >dccps_ccid_timer, jiffies + hc->tx_rto);
done:
/* check if incoming Acks allow pending packets to be sent */
if (sender_was_blocked && !ccid2_cwnd_network_limited(hc))
@@ -737,17 +742,18 @@ static int ccid2_hc_tx_init(struct ccid *ccid, struct
sock *sk)
hc->tx_last_cong = hc->tx_lsndtime = hc->tx_cwnd_stamp =
ccid2_jiffies32;
hc->tx_cwnd_used = 0;
hc->sk = sk;
- timer_setup(>tx_rtotimer, ccid2_hc_tx_rto_expire, 0);
+ timer_setup(>dccps_ccid_timer, ccid2_hc_tx_rto_expire, 0);
INIT_LIST_HEAD(>tx_av_chunks);
return 0;
}
static void ccid2_hc_tx_exit(struct sock *sk)
{
+ struct dccp_sock *dp = dccp_sk(sk);
struct ccid2_hc_tx_sock *hc = ccid2_hc_tx_sk(sk);
int i;
- sk_stop_timer(sk, >tx_rtotimer);
+ sk_stop_timer(sk, >dccps_ccid_timer);
for (i = 0; i < hc->tx_seqbufc; i++)
kfree(hc->tx_seqbuf[i]);
diff
[PATCH 0/2] net: dccp: fix structure use-after-free
This patchset addresses the following CVE: CVE-2020-16119 - DCCP CCID structure use-after-free Hadar Manor reported that by reusing a socket with an attached dccps_hc_tx_ccid as a listener, it will be used after being released, leading to DoS and potentially code execution. The first patch moves the ccid timers to struct dccp_sock to avoid its use-after-free, the second patch reverts 2677d2067731 "dccp: don't free ccid2_hc_tx_sock struct in dccp_disconnect()" that's not needed anymore and would cause another use-after-free. Thadeu Lima de Souza Cascardo (2): dccp: ccid: move timers to struct dccp_sock Revert "dccp: don't free ccid2_hc_tx_sock struct in dccp_disconnect()" include/linux/dccp.h | 2 ++ net/dccp/ccids/ccid2.c | 32 +++- net/dccp/ccids/ccid3.c | 30 -- net/dccp/proto.c | 2 ++ 4 files changed, 43 insertions(+), 23 deletions(-) -- 2.25.1
Re: sysfs filenames with spaces
On Mon 2020-10-05 19:41:15, Joe Perches wrote: > This doesn't seem like a great idea to me. > > For my system I've got: > > /sys/devices/platform/Fixed MDIO bus.0/ > /sys/bus/platform/drivers/int3401 thermal/ > /sys/bus/platform/drivers/int3403 thermal/ > /sys/bus/platform/drivers/int3400 thermal/ > /sys/bus/mdio_bus/drivers/Generic PHY/ > /sys/bus/mdio_bus/drivers/Generic Clause 45 PHY/ > /sys/bus/pnp/drivers/i8042 aux/ > /sys/bus/pnp/drivers/i8042 kbd/ > /sys/bus/i2c/drivers/CHT Whiskey Cove PMIC/ > > Could these filenames be avoided in the future or > even renamed today? Does not look like great idea to me, either. Hmm. Is there filename with "/" in it? :-) But I guess you'd need to cc relevant maintainers and that this is going to be a bit of whack-a-mole. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: PGP signature
Re: [PATCH v2] dt-bindings: cpufreq: cpufreq-qcom-hw: Convert to YAML bindings
On Mon, Oct 12, 2020 at 09:20:12PM +0530, Manivannan Sadhasivam wrote: > Convert Qualcomm cpufreq devicetree binding to YAML. > > Signed-off-by: Manivannan Sadhasivam > --- > > Changes in v2: > > * Removed qcom,freq-domain property which doesn't belong to this binding It needs to be defined *somewhere*. As I said before, you need a separate schema for it. > > .../bindings/cpufreq/cpufreq-qcom-hw.txt | 172 --- > .../bindings/cpufreq/cpufreq-qcom-hw.yaml | 204 ++ > 2 files changed, 204 insertions(+), 172 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > create mode 100644 > Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
Re: [PATCH v2 2/2] dt-bindings: extcon: add binding for TUSB320
On Mon, 12 Oct 2020 09:47:53 -0500, Michael Auchter wrote: > Add a device tree binding for the TI TUSB320. > > Signed-off-by: Michael Auchter > --- > Changes since v1: > - use tusb320 instead of extcon in the unit name > > .../bindings/extcon/extcon-usbc-tusb320.yaml | 41 +++ > 1 file changed, 41 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml > Reviewed-by: Rob Herring
Re: [GIT PULL] cpupower update for Linux 5.10-rc1
On 10/13/20 11:13 AM, Shuah Khan wrote:
Hi Rafael,
Please pull the following cpupower update for Linux 5.10-rc1 or for
a later rc.
This cpupower update for Linux 5.10-rc1 consists of minor fixes for
spelling and speeding up generating git version string which will
in turn speedup compiles.
diff is attached.
Sorry. Here is the diff.
thanks,
-- Shuah
diff --git a/tools/power/cpupower/Makefile b/tools/power/cpupower/Makefile
index c8622497ef23..c7bcddbd486d 100644
--- a/tools/power/cpupower/Makefile
+++ b/tools/power/cpupower/Makefile
@@ -51,7 +51,7 @@ DESTDIR ?=
# Package-related definitions. Distributions can modify the version
# and _should_ modify the PACKAGE_BUGREPORT definition
-VERSION= $(shell ./utils/version-gen.sh)
+VERSION:= $(shell ./utils/version-gen.sh)
LIB_MAJ= 0.0.1
LIB_MIN= 0
diff --git a/tools/power/cpupower/debug/i386/intel_gsic.c b/tools/power/cpupower/debug/i386/intel_gsic.c
index e5e926f46d6b..befd837f07f8 100644
--- a/tools/power/cpupower/debug/i386/intel_gsic.c
+++ b/tools/power/cpupower/debug/i386/intel_gsic.c
@@ -71,7 +71,7 @@ int main (void)
printf("\tsmi_cmd=0x?? smi_port=0x?? smi_sig=1\n");
printf("\nUnfortunately, you have to know what exactly are "
"smi_cmd and smi_port, and this\nis system "
- "dependant.\n");
+ "dependent.\n");
}
return 1;
}
Re: [patch 1/2] nohz: only wakeup a single target cpu when kicking a task
On Thu, Oct 08, 2020 at 09:54:44PM +0200, Frederic Weisbecker wrote:
> On Thu, Oct 08, 2020 at 02:54:09PM -0300, Marcelo Tosatti wrote:
> > On Thu, Oct 08, 2020 at 02:22:56PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 07, 2020 at 03:01:52PM -0300, Marcelo Tosatti wrote:
> > > > When adding a tick dependency to a task, its necessary to
> > > > wakeup the CPU where the task resides to reevaluate tick
> > > > dependencies on that CPU.
> > > >
> > > > However the current code wakes up all nohz_full CPUs, which
> > > > is unnecessary.
> > > >
> > > > Switch to waking up a single CPU, by using ordering of writes
> > > > to task->cpu and task->tick_dep_mask.
> > > >
> > > > From: Frederic Weisbecker
> > > > Suggested-by: Peter Zijlstra
> > > > Signed-off-by: Frederic Weisbecker
> > > > Signed-off-by: Marcelo Tosatti
> > > >
> > > > Index: linux-2.6/kernel/time/tick-sched.c
> > > > ===
> > > > --- linux-2.6.orig/kernel/time/tick-sched.c
> > > > +++ linux-2.6/kernel/time/tick-sched.c
> > > > @@ -274,6 +274,31 @@ void tick_nohz_full_kick_cpu(int cpu)
> > > > irq_work_queue_on(_cpu(nohz_full_kick_work, cpu), cpu);
> > > > }
> > > >
> > > > +static void tick_nohz_kick_task(struct task_struct *tsk)
> > > > +{
> > > > + int cpu = task_cpu(tsk);
> > > > +
> > > > + /*
> > > > +* If the task concurrently migrates to another cpu,
> > > > +* we guarantee it sees the new tick dependency upon
> > > > +* schedule.
> > > > +*
> > > > +*
> > > > +* set_task_cpu(p, cpu);
> > > > +* STORE p->cpu = @cpu
> > > > +* __schedule() (switch to task 'p')
> > > > +* LOCK rq->lock
> > > > +* smp_mb__after_spin_lock() STORE p->tick_dep_mask
> > > > +* tick_nohz_task_switch()smp_mb()
> > > > (atomic_fetch_or())
> > > > +* LOAD p->tick_dep_mask LOAD p->cpu
> > > > +*/
> > > > +
> > > > + preempt_disable();
> > > > + if (cpu_online(cpu))
> > > > + tick_nohz_full_kick_cpu(cpu);
> > > > + preempt_enable();
> > > > +}
> > >
> > > So we need to kick the CPU unconditionally, or only when the task is
> > > actually running? AFAICT we only care about current->tick_dep_mask.
> >
> > tick is necessary to execute run_posix_cpu_timers, from tick interrupt,
> > even if task is not running.
>
> Yes but if the task isn't running, run_posix_cpu_timers() doesn't have
> anything to elapse. So indeed we can spare the IPI if the task is not
> running. Provided ordering makes sure that the task sees the new dependency
> when it schedules in of course.
True.
* p->on_cpu <- { 0, 1 }:
*
* is set by prepare_task() and cleared by finish_task() such that it will be
* set before p is scheduled-in and cleared after p is scheduled-out, both
* under rq->lock. Non-zero indicates the task is running on its CPU.
CPU-0 (tick_set_dep)CPU-1 (task switch)
STORE p->tick_dep_mask
smp_mb() (atomic_fetch_or())
LOAD p->on_cpu
context_switch(prev, next)
STORE next->on_cpu = 1
... [*]
LOAD current->tick_dep_mask
Don't see any explicit memory barrier in the [*] section?
[GIT PULL] cpupower update for Linux 5.10-rc1
Hi Rafael, Please pull the following cpupower update for Linux 5.10-rc1 or for a later rc. This cpupower update for Linux 5.10-rc1 consists of minor fixes for spelling and speeding up generating git version string which will in turn speedup compiles. diff is attached. thanks, -- Shuah The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux tags/linux-cpupower-5.10-rc1 for you to fetch changes up to 527b7779e5ecabb057089b760140309bdcacc16a: cpupower: speed up generating git version string (2020-08-20 13:04:47 -0600) linux-cpupower-5.10-rc1 This cpupower update for Linux 5.10-rc1 consists of minor fixes for spelling and speeding up generating git version string which will in turn speedup compiles. Colin Ian King (1): cpupowerutils: fix spelling mistake "dependant" -> "dependent" Martin Kaistra (1): cpupower: speed up generating git version string tools/power/cpupower/Makefile| 2 +- tools/power/cpupower/debug/i386/intel_gsic.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux tags/linux-cpupower-5.10-rc1 for you to fetch changes up to 527b7779e5ecabb057089b760140309bdcacc16a: cpupower: speed up generating git version string (2020-08-20 13:04:47 -0600) linux-cpupower-5.10-rc1 This cpupower update for Linux 5.10-rc1 consists of minor fixes for spelling and speeding up generating git version string which will in turn speedup compiles. Colin Ian King (1): cpupowerutils: fix spelling mistake "dependant" -> "dependent" Martin Kaistra (1): cpupower: speed up generating git version string tools/power/cpupower/Makefile| 2 +- tools/power/cpupower/debug/i386/intel_gsic.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
[PATCH v2 3/3] clk: qcom: camcc: Add camera clock controller driver for SC7180
Add support for the camera clock controller found on SC7180 based devices.
This would allow camera drivers to probe and control their clocks.
Signed-off-by: Taniya Das
---
drivers/clk/qcom/Kconfig|9 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/camcc-sc7180.c | 1737 +++
3 files changed, 1747 insertions(+)
create mode 100644 drivers/clk/qcom/camcc-sc7180.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 0583273..7aeebe6 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -290,6 +290,15 @@ config QCS_GCC_404
Say Y if you want to use multimedia devices or peripheral
devices such as UART, SPI, I2C, USB, SD/eMMC, PCIe etc.
+config SC_CAMCC_7180
+ tristate "SC7180 Camera Clock Controller"
+ select SC_GCC_7180
+ help
+ Support for the camera clock controller on Qualcomm Technologies, Inc
+ SC7180 devices.
+ Say Y if you want to support camera devices and functionality such as
+ capturing pictures.
+
config SC_DISPCC_7180
tristate "SC7180 Display Clock Controller"
select SC_GCC_7180
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 9677e76..8e0579f 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
obj-$(CONFIG_QCS_GCC_404) += gcc-qcs404.o
obj-$(CONFIG_QCS_Q6SSTOP_404) += q6sstop-qcs404.o
obj-$(CONFIG_QCS_TURING_404) += turingcc-qcs404.o
+obj-$(CONFIG_SC_CAMCC_7180) += camcc-sc7180.o
obj-$(CONFIG_SC_DISPCC_7180) += dispcc-sc7180.o
obj-$(CONFIG_SC_GCC_7180) += gcc-sc7180.o
obj-$(CONFIG_SC_GPUCC_7180) += gpucc-sc7180.o
diff --git a/drivers/clk/qcom/camcc-sc7180.c b/drivers/clk/qcom/camcc-sc7180.c
new file mode 100644
index 000..e954d21
--- /dev/null
+++ b/drivers/clk/qcom/camcc-sc7180.c
@@ -0,0 +1,1737 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "common.h"
+#include "gdsc.h"
+#include "reset.h"
+
+enum {
+ P_BI_TCXO,
+ P_CAM_CC_PLL0_OUT_EVEN,
+ P_CAM_CC_PLL1_OUT_EVEN,
+ P_CAM_CC_PLL2_OUT_AUX,
+ P_CAM_CC_PLL2_OUT_EARLY,
+ P_CAM_CC_PLL3_OUT_MAIN,
+ P_CORE_BI_PLL_TEST_SE,
+};
+
+static struct pll_vco agera_vco[] = {
+ { 6, 33, 0 },
+};
+
+static struct pll_vco fabia_vco[] = {
+ { 24960, 20, 0 },
+};
+
+/* 600MHz configuration */
+static const struct alpha_pll_config cam_cc_pll0_config = {
+ .l = 0x1F,
+ .alpha = 0x4000,
+ .config_ctl_val = 0x20485699,
+ .config_ctl_hi_val = 0x2067,
+ .test_ctl_val = 0x4000,
+ .user_ctl_hi_val = 0x4805,
+ .user_ctl_val = 0x0001,
+};
+
+static struct clk_alpha_pll cam_cc_pll0 = {
+ .offset = 0x0,
+ .vco_table = fabia_vco,
+ .num_vco = ARRAY_SIZE(fabia_vco),
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
+ .clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "cam_cc_pll0",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "bi_tcxo",
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_fabia_ops,
+ },
+ },
+};
+
+/* 860MHz configuration */
+static const struct alpha_pll_config cam_cc_pll1_config = {
+ .l = 0x2A,
+ .alpha = 0x1555,
+ .config_ctl_val = 0x20485699,
+ .config_ctl_hi_val = 0x2067,
+ .test_ctl_val = 0x4000,
+ .user_ctl_hi_val = 0x4805,
+};
+
+static struct clk_alpha_pll cam_cc_pll1 = {
+ .offset = 0x1000,
+ .vco_table = fabia_vco,
+ .num_vco = ARRAY_SIZE(fabia_vco),
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
+ .clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "cam_cc_pll1",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "bi_tcxo",
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_fabia_ops,
+ },
+ },
+};
+
+/* 1920MHz configuration */
+static const struct alpha_pll_config cam_cc_pll2_config = {
+ .l = 0x64,
+ .config_ctl_val = 0x2800,
+ .config_ctl_hi_val = 0x43D2,
+ .test_ctl_val = 0x04000400,
+ .test_ctl_hi_val = 0x4000,
+ .user_ctl_val = 0x030F,
+};
+
+static struct clk_alpha_pll cam_cc_pll2 = {
+ .offset = 0x2000,
+ .vco_table = agera_vco,
+ .num_vco =
[PATCH v2 1/3] clk: qcom: clk-alpha-pll: Add support for controlling Agera PLLs
Add programming sequence support for managing the Agera PLLs.
Signed-off-by: Taniya Das
---
drivers/clk/qcom/clk-alpha-pll.c | 80
drivers/clk/qcom/clk-alpha-pll.h | 4 ++
2 files changed, 84 insertions(+)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 26139ef..17e1fc0 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -116,6 +116,16 @@ const u8 clk_alpha_pll_regs[][PLL_OFF_MAX_REGS] = {
[PLL_OFF_OPMODE] = 0x38,
[PLL_OFF_ALPHA_VAL] = 0x40,
},
+ [CLK_ALPHA_PLL_TYPE_AGERA] = {
+ [PLL_OFF_L_VAL] = 0x04,
+ [PLL_OFF_ALPHA_VAL] = 0x08,
+ [PLL_OFF_USER_CTL] = 0x0c,
+ [PLL_OFF_CONFIG_CTL] = 0x10,
+ [PLL_OFF_CONFIG_CTL_U] = 0x14,
+ [PLL_OFF_TEST_CTL] = 0x18,
+ [PLL_OFF_TEST_CTL_U] = 0x1c,
+ [PLL_OFF_STATUS] = 0x2c,
+ },
};
EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
@@ -1561,3 +1571,73 @@ const struct clk_ops clk_alpha_pll_postdiv_lucid_ops = {
.set_rate = clk_alpha_pll_postdiv_fabia_set_rate,
};
EXPORT_SYMBOL_GPL(clk_alpha_pll_postdiv_lucid_ops);
+
+void clk_agera_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
+ const struct alpha_pll_config *config)
+{
+ if (config->l)
+ regmap_write(regmap, PLL_L_VAL(pll), config->l);
+
+ if (config->alpha)
+ regmap_write(regmap, PLL_ALPHA_VAL(pll), config->alpha);
+
+ if (config->user_ctl_val)
+ regmap_write(regmap, PLL_USER_CTL(pll), config->user_ctl_val);
+
+ if (config->config_ctl_val)
+ regmap_write(regmap, PLL_CONFIG_CTL(pll),
+ config->config_ctl_val);
+
+ if (config->config_ctl_hi_val)
+ regmap_write(regmap, PLL_CONFIG_CTL_U(pll),
+ config->config_ctl_hi_val);
+
+ if (config->test_ctl_val)
+ regmap_write(regmap, PLL_TEST_CTL(pll),
+ config->test_ctl_val);
+
+ if (config->test_ctl_hi_val)
+ regmap_write(regmap, PLL_TEST_CTL_U(pll),
+ config->test_ctl_hi_val);
+}
+EXPORT_SYMBOL_GPL(clk_agera_pll_configure);
+
+static int clk_alpha_pll_agera_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long prate)
+{
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+ u32 l, alpha_width = pll_alpha_width(pll);
+ unsigned long rrate, max = rate + PLL_RATE_MARGIN;
+ u64 a;
+
+ rrate = alpha_pll_round_rate(rate, prate, , , alpha_width);
+
+ /*
+* Due to limited number of bits for fractional rate programming, the
+* rounded up rate could be marginally higher than the requested rate.
+*/
+ if (rrate > (rate + PLL_RATE_MARGIN) || rrate < rate) {
+ pr_err("%s: Rounded rate %lu not within range [%lu, %lu)\n",
+ clk_hw_get_name(hw), rrate, rate, max);
+ return -EINVAL;
+ }
+
+ /* change L_VAL without having to go through the power on sequence */
+ regmap_write(pll->clkr.regmap, PLL_L_VAL(pll), l);
+ regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL(pll), a);
+
+ if (clk_hw_is_enabled(hw))
+ return wait_for_pll_enable_lock(pll);
+
+ return 0;
+}
+
+const struct clk_ops clk_alpha_pll_agera_ops = {
+ .enable = clk_alpha_pll_enable,
+ .disable = clk_alpha_pll_disable,
+ .is_enabled = clk_alpha_pll_is_enabled,
+ .recalc_rate = alpha_pll_fabia_recalc_rate,
+ .round_rate = clk_alpha_pll_round_rate,
+ .set_rate = clk_alpha_pll_agera_set_rate,
+};
+EXPORT_SYMBOL_GPL(clk_alpha_pll_agera_ops);
diff --git a/drivers/clk/qcom/clk-alpha-pll.h b/drivers/clk/qcom/clk-alpha-pll.h
index d3201b8..0ea30d2 100644
--- a/drivers/clk/qcom/clk-alpha-pll.h
+++ b/drivers/clk/qcom/clk-alpha-pll.h
@@ -15,6 +15,7 @@ enum {
CLK_ALPHA_PLL_TYPE_FABIA,
CLK_ALPHA_PLL_TYPE_TRION,
CLK_ALPHA_PLL_TYPE_LUCID = CLK_ALPHA_PLL_TYPE_TRION,
+ CLK_ALPHA_PLL_TYPE_AGERA,
CLK_ALPHA_PLL_TYPE_MAX,
};
@@ -141,6 +142,7 @@ extern const struct clk_ops clk_alpha_pll_postdiv_trion_ops;
extern const struct clk_ops clk_alpha_pll_lucid_ops;
#define clk_alpha_pll_fixed_lucid_ops clk_alpha_pll_fixed_trion_ops
extern const struct clk_ops clk_alpha_pll_postdiv_lucid_ops;
+extern const struct clk_ops clk_alpha_pll_agera_ops;
void clk_alpha_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
const struct alpha_pll_config *config);
@@ -148,6 +150,8 @@ void clk_fabia_pll_configure(struct clk_alpha_pll *pll,
struct regmap *regmap,
const
[PATCH v2 2/3] dt-bindings: clock: Add YAML schemas for the QCOM Camera clock bindings.
The Camera Subsystem clock provider have a bunch of generic properties
that are needed in a device tree. Add a YAML schemas for those.
Add clock ids for camera clocks which are required to bring the camera
subsystem out of reset.
Signed-off-by: Taniya Das
---
.../bindings/clock/qcom,sc7180-camcc.yaml | 73 +
include/dt-bindings/clock/qcom,camcc-sc7180.h | 121 +
2 files changed, 194 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
create mode 100644 include/dt-bindings/clock/qcom,camcc-sc7180.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
new file mode 100644
index 000..07bd38e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sc7180-camcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Camera Clock & Reset Controller Binding for SC7180
+
+maintainers:
+ - Taniya Das
+
+description: |
+ Qualcomm camera clock control module which supports the clocks, resets and
+ power domains on SC7180.
+
+ See also:
+ - dt-bindings/clock/qcom,camcc-sc7180.h.
+
+properties:
+ compatible:
+const: qcom,sc7180-camcc
+
+ clocks:
+items:
+ - description: Board XO source
+ - description: Camera_ahb clock from GCC
+ - description: Camera XO clock from GCC
+
+ clock-names:
+items:
+ - const: bi_tcxo
+ - const: iface
+ - const: xo
+
+ '#clock-cells':
+const: 1
+
+ '#reset-cells':
+const: 1
+
+ '#power-domain-cells':
+const: 1
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#reset-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+clock-controller@ad0 {
+ compatible = "qcom,sc7180-camcc";
+ reg = <0x0ad0 0x1>;
+ clocks = < RPMH_CXO_CLK>,
+ < GCC_CAMERA_AHB_CLK>,
+ < GCC_CAMERA_XO_CLK>;
+ clock-names = "bi_tcxo", "iface", "xo";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+};
+...
diff --git a/include/dt-bindings/clock/qcom,camcc-sc7180.h
b/include/dt-bindings/clock/qcom,camcc-sc7180.h
new file mode 100644
index 000..ef7d3a0
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,camcc-sc7180.h
@@ -0,0 +1,121 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_CAM_CC_SC7180_H
+#define _DT_BINDINGS_CLK_QCOM_CAM_CC_SC7180_H
+
+/* CAM_CC clocks */
+#define CAM_CC_PLL2_OUT_EARLY 0
+#define CAM_CC_PLL01
+#define CAM_CC_PLL12
+#define CAM_CC_PLL23
+#define CAM_CC_PLL2_OUT_AUX4
+#define CAM_CC_PLL35
+#define CAM_CC_CAMNOC_AXI_CLK 6
+#define CAM_CC_CCI_0_CLK 7
+#define CAM_CC_CCI_0_CLK_SRC 8
+#define CAM_CC_CCI_1_CLK 9
+#define CAM_CC_CCI_1_CLK_SRC 10
+#define CAM_CC_CORE_AHB_CLK11
+#define CAM_CC_CPAS_AHB_CLK12
+#define CAM_CC_CPHY_RX_CLK_SRC 13
+#define CAM_CC_CSI0PHYTIMER_CLK14
+#define CAM_CC_CSI0PHYTIMER_CLK_SRC15
+#define CAM_CC_CSI1PHYTIMER_CLK16
+#define CAM_CC_CSI1PHYTIMER_CLK_SRC17
+#define CAM_CC_CSI2PHYTIMER_CLK18
+#define CAM_CC_CSI2PHYTIMER_CLK_SRC19
+#define CAM_CC_CSI3PHYTIMER_CLK20
+#define CAM_CC_CSI3PHYTIMER_CLK_SRC21
+#define CAM_CC_CSIPHY0_CLK 22
+#define CAM_CC_CSIPHY1_CLK 23
+#define CAM_CC_CSIPHY2_CLK 24
+#define CAM_CC_CSIPHY3_CLK 25
+#define CAM_CC_FAST_AHB_CLK_SRC26
+#define CAM_CC_ICP_APB_CLK 27
+#define CAM_CC_ICP_ATB_CLK 28
+#define CAM_CC_ICP_CLK 29
+#define CAM_CC_ICP_CLK_SRC 30
+#define
[PATCH v2 0/3] Add Camera clock controller driver for SC7180
[v2] * Update PLL set rate function : clk_alpha_pll_agera_set_rate * Remove mb() [v1] * Add support for Agera PLL which is used in the camera clock controller. * Add driver support for camera clock controller for SC7180 and also update device tree bindings for the various clocks supported in the clock controller. Taniya Das (3): clk: qcom: clk-alpha-pll: Add support for controlling Agera PLLs dt-bindings: clock: Add YAML schemas for the QCOM Camera clock bindings. clk: qcom: camcc: Add camera clock controller driver for SC7180 .../bindings/clock/qcom,sc7180-camcc.yaml | 73 + drivers/clk/qcom/Kconfig |9 + drivers/clk/qcom/Makefile |1 + drivers/clk/qcom/camcc-sc7180.c| 1737 drivers/clk/qcom/clk-alpha-pll.c | 80 + drivers/clk/qcom/clk-alpha-pll.h |4 + include/dt-bindings/clock/qcom,camcc-sc7180.h | 121 ++ 7 files changed, 2025 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml create mode 100644 drivers/clk/qcom/camcc-sc7180.c create mode 100644 include/dt-bindings/clock/qcom,camcc-sc7180.h -- Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member of the Code Aurora Forum, hosted by the Linux Foundation.
Unbreakable loop in fuse_fill_write_pages()
Running some fuzzing on virtiofs with an unprivileged user on today's linux-next could trigger soft-lockups below. # virtiofsd --socket-path=/tmp/vhostqemu -o source=$TESTDIR -o cache=always -o no_posix_lock Basically, everything was blocking on inode_lock(inode) because one thread (trinity-c33) was holding it but stuck in the loop in fuse_fill_write_pages() and unable to exit for more than 10 minutes before I executed sysrq-t. Afterwards, the systems was totally unresponsive: kernel:NMI watchdog: Watchdog detected hard LOCKUP on cpu 8 To exit the loop, it needs, iov_iter_advance(ii, tmp) to set "tmp" to non-zero for each iteration. and } while (iov_iter_count(ii) && count < fc->max_write && ap->num_pages < max_pages && offset == 0); == the thread is stuck in the loop == [10813.290694] task:trinity-c33 state:D stack:25888 pid:254219 ppid: 87180 flags:0x4004 [10813.292671] Call Trace: [10813.293379] __schedule+0x71d/0x1b50 [10813.294182] ? __sched_text_start+0x8/0x8 [10813.295146] ? mark_held_locks+0xb0/0x110 [10813.296117] schedule+0xbf/0x270 [10813.296782] ? __lock_page_killable+0x276/0x830 [10813.297867] io_schedule+0x17/0x60 [10813.298772] __lock_page_killable+0x33b/0x830 [10813.299695] ? wait_on_page_bit+0x710/0x710 [10813.300609] ? __lock_page_or_retry+0x3c0/0x3c0 [10813.301894] ? up_read+0x1a3/0x730 [10813.302791] ? page_cache_free_page.isra.45+0x390/0x390 [10813.304077] filemap_fault+0x2bd/0x2040 [10813.305019] ? read_cache_page_gfp+0x10/0x10 [10813.306041] ? lock_downgrade+0x700/0x700 [10813.306958] ? replace_page_cache_page+0x1130/0x1130 [10813.308124] __do_fault+0xf5/0x530 [10813.308968] handle_mm_fault+0x1c0e/0x25b0 [10813.309955] ? copy_page_range+0xfe0/0xfe0 [10813.310895] do_user_addr_fault+0x383/0x820 [10813.312084] exc_page_fault+0x56/0xb0 [10813.312979] asm_exc_page_fault+0x1e/0x30 [10813.313978] RIP: 0010:iov_iter_fault_in_readable+0x271/0x350 fault_in_pages_readable at include/linux/pagemap.h:745 (inlined by) iov_iter_fault_in_readable at lib/iov_iter.c:438 [10813.315293] Code: 48 39 d7 0f 82 1a ff ff ff 0f 01 cb 0f ae e8 44 89 c0 8a 0a 0f 01 ca 88 4c 24 70 85 c0 74 da e9 f8 fe ff ff 0f 01 cb 0f ae e8 <8a> 11 0f 01 ca 88 54 24 30 85 c0 0f 85 04 ff ff ff 48 29 ee e9 45 [10813.319196] RSP: 0018:c90017ccf830 EFLAGS: 00050246 [10813.320446] RAX: RBX: 192002f99f08 RCX: 7fe284f1004c [10813.322202] RDX: 0001 RSI: 1000 RDI: 8887a7664000 [10813.323729] RBP: 1000 R08: R09: [10813.325282] R10: c90017ccfd48 R11: ed102789d5ff R12: 8887a7664020 [10813.326898] R13: c90017ccfd40 R14: dc00 R15: 00e0df6a [10813.328456] ? iov_iter_revert+0x8e0/0x8e0 [10813.329404] ? copyin+0x96/0xc0 [10813.330230] ? iov_iter_copy_from_user_atomic+0x1f0/0xa40 [10813.331742] fuse_perform_write+0x3eb/0xf20 [fuse] fuse_fill_write_pages at fs/fuse/file.c:1150 (inlined by) fuse_perform_write at fs/fuse/file.c:1226 [10813.332880] ? fuse_file_fallocate+0x5f0/0x5f0 [fuse] [10813.334090] fuse_file_write_iter+0x6b7/0x900 [fuse] [10813.335191] do_iter_readv_writev+0x42b/0x6d0 [10813.336161] ? new_sync_write+0x610/0x610 [10813.337194] do_iter_write+0x11f/0x5b0 [10813.338177] ? __sb_start_write+0x229/0x2d0 [10813.339169] vfs_writev+0x16d/0x2d0 [10813.339973] ? vfs_iter_write+0xb0/0xb0 [10813.340950] ? __fdget_pos+0x9c/0xb0 [10813.342039] ? rcu_read_lock_sched_held+0x9c/0xd0 [10813.343120] ? rcu_read_lock_bh_held+0xb0/0xb0 [10813.344104] ? find_held_lock+0x33/0x1c0 [10813.345050] do_writev+0xfb/0x1e0 [10813.345920] ? vfs_writev+0x2d0/0x2d0 [10813.346802] ? lockdep_hardirqs_on_prepare+0x27c/0x3d0 [10813.348026] ? syscall_enter_from_user_mode+0x1c/0x50 [10813.349197] do_syscall_64+0x33/0x40 [10813.350026] entry_SYSCALL_64_after_hwframe+0x44/0xa9 == soft-lockups == [10579.953730][ T348] Tainted: G O 5.9.0-next-20201013+ #2 [10579.955016][ T348] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [10579.956467][ T348] task:trinity-c25 state:D stack:26704 pid:253906 ppid: 87180 flags:0x4002 [10579.958028][ T348] Call Trace: [10579.958609][ T348] __schedule+0x71d/0x1b50 [10579.959309][ T348] ? __sched_text_start+0x8/0x8 [10579.960144][ T348] schedule+0xbf/0x270 [10579.960774][ T348] rwsem_down_write_slowpath+0x8ea/0xf30 [10579.961828][ T348] ? rwsem_mark_wake+0x8d0/0x8d0 [10579.962675][ T348] ? lockdep_hardirqs_on_prepare+0x3d0/0x3d0 [10579.963721][ T348] ? rcu_read_lock_sched_held+0x9c/0xd0 [10579.964658][ T348] ? lock_acquire+0x1c8/0x820 [10579.965453][ T348] ? down_write+0x138/0x150 [10579.966237][ T348] ? down_write+0xb3/0x150 [10579.966994][ T348] down_write+0x138/0x150 [10579.967787][ T348] ? down_write_killable_nested+0x170/0x170 [10579.968844][ T348] fuse_flush+
Re: [PATCH v1 1/3] clk: qcom: clk-alpha-pll: Add support for controlling Agera PLLs
Thanks for the review Stephen.
On 9/15/2020 5:43 AM, Stephen Boyd wrote:
Quoting Taniya Das (2020-09-08 10:07:26)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 26139ef..fb27fcf 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -1561,3 +1571,75 @@ const struct clk_ops clk_alpha_pll_postdiv_lucid_ops = {
.set_rate = clk_alpha_pll_postdiv_fabia_set_rate,
};
EXPORT_SYMBOL_GPL(clk_alpha_pll_postdiv_lucid_ops);
+
+void clk_agera_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
+ const struct alpha_pll_config *config)
+{
+ if (config->l)
+ regmap_write(regmap, PLL_L_VAL(pll), config->l);
+
+ if (config->alpha)
+ regmap_write(regmap, PLL_ALPHA_VAL(pll), config->alpha);
+
+ if (config->user_ctl_val)
+ regmap_write(regmap, PLL_USER_CTL(pll), config->user_ctl_val);
+
+ if (config->config_ctl_val)
+ regmap_write(regmap, PLL_CONFIG_CTL(pll),
+ config->config_ctl_val);
+
+ if (config->config_ctl_hi_val)
+ regmap_write(regmap, PLL_CONFIG_CTL_U(pll),
+ config->config_ctl_hi_val);
+
+ if (config->test_ctl_val)
+ regmap_write(regmap, PLL_TEST_CTL(pll),
+ config->test_ctl_val);
+
+ if (config->test_ctl_hi_val)
+ regmap_write(regmap, PLL_TEST_CTL_U(pll),
+ config->test_ctl_hi_val);
+}
+EXPORT_SYMBOL_GPL(clk_agera_pll_configure);
+
+static int alpha_pll_agera_set_rate(struct clk_hw *hw, unsigned long rate,
Why not clk_alpha_pll prefix? We should prefix the other PLL functions
in here with clk_alpha_ like trion and fabia
Yes, I will update this in the next patch.
+ unsigned long prate)
+{
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+ u32 l, alpha_width = pll_alpha_width(pll);
+ unsigned long rrate;
+ u64 a;
+
+ rrate = alpha_pll_round_rate(rate, prate, , , alpha_width);
+
+ /*
+* Due to limited number of bits for fractional rate programming, the
+* rounded up rate could be marginally higher than the requested rate.
+*/
+ if (rrate > (rate + PLL_RATE_MARGIN) || rrate < rate) {
+ pr_err("Call set rate on the PLL with rounded rates!\n");
+ return -EINVAL;
+ }
See commit f78f29079327 ("clk: qcom: alpha-pll: Make error prints more
informative") where I tried to make this better. Can you extract this
check into a function that helps us understand the error better?
Updated to follow the same.
+
+ /* change L_VAL without having to go through the power on sequence */
+ regmap_write(pll->clkr.regmap, PLL_L_VAL(pll), l);
+ regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL(pll), a);
+
+ /* Ensure that the write above goes through before proceeding. */
+ mb();
regmap has an mb() in it. Remove this?
Yes, will remove it.
+
+ if (clk_hw_is_enabled(hw))
+ return wait_for_pll_enable_lock(pll);
+
+ return 0;
+}
+
+const struct clk_ops clk_alpha_pll_agera_ops = {
+ .enable = clk_alpha_pll_enable,
+ .disable = clk_alpha_pll_disable,
+ .is_enabled = clk_alpha_pll_is_enabled,
+ .recalc_rate = alpha_pll_fabia_recalc_rate,
+ .round_rate = clk_alpha_pll_round_rate,
+ .set_rate = alpha_pll_agera_set_rate,
+};
+EXPORT_SYMBOL_GPL(clk_alpha_pll_agera_ops);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
Re: [PATCH 1/6] dt-bindings: leds: choose correct color value of multi-led
Hi! > > --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml > > +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml > > @@ -197,7 +197,7 @@ examples: > > #address-cells = <1>; > > #size-cells = <0>; > > reg = <0x2>; > > - color = ; > > + color = ; > > function = LED_FUNCTION_STANDBY; > > linux,default-trigger = "heartbeat"; > > This is not correct. ID_RGB is the correct variable here. > > https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/commit/?h=for-next=3d93edc77515c6f51fa9bbbe2185e2ec32bad024 > > Correct fix is to update the leds-class-multicolor.yaml Right. So lets not merge this one. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: PGP signature
WARNING in drop_nlink (2)
Hello, syzbot found the following issue on: HEAD commit:583090b1 Merge tag 'block5.9-2020-10-08' of git://git.kern.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1453138450 kernel config: https://syzkaller.appspot.com/x/.config?x=de7f697da23057c7 dashboard link: https://syzkaller.appspot.com/bug?extid=651ca866e5e2b4b5095b compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1112681790 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1705b5bf90 Bisection is inconclusive: the issue happens on the oldest tested release. bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=133e121050 final oops: https://syzkaller.appspot.com/x/report.txt?x=10be121050 console output: https://syzkaller.appspot.com/x/log.txt?x=173e121050 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+651ca866e5e2b4b50...@syzkaller.appspotmail.com MINIX-fs: mounting unchecked file system, running fsck is recommended [ cut here ] WARNING: CPU: 0 PID: 6857 at fs/inode.c:303 drop_nlink+0xb9/0x100 fs/inode.c:303 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 6857 Comm: syz-executor857 Not tainted 5.9.0-rc8-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d6/0x29e lib/dump_stack.c:118 panic+0x2c0/0x800 kernel/panic.c:231 __warn+0x227/0x250 kernel/panic.c:600 report_bug+0x1b1/0x2e0 lib/bug.c:198 handle_bug+0x42/0x80 arch/x86/kernel/traps.c:234 exc_invalid_op+0x16/0x40 arch/x86/kernel/traps.c:254 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536 RIP: 0010:drop_nlink+0xb9/0x100 fs/inode.c:303 Code: 49 8b 1e 48 8d bb b8 07 00 00 be 08 00 00 00 e8 9d 46 ef ff f0 48 ff 83 b8 07 00 00 5b 41 5c 41 5e 41 5f 5d c3 e8 87 92 af ff <0f> 0b eb 8a 44 89 e1 80 e1 07 80 c1 03 38 c1 0f 8c 63 ff ff ff 4c RSP: 0018:c900010d7c50 EFLAGS: 00010293 RAX: 81c56b69 RBX: 111010a15c21 RCX: 88809190c1c0 RDX: RSI: RDI: RBP: R08: 81c56aee R09: fbfff16c82b0 R10: fbfff16c82b0 R11: R12: 8880850ae108 R13: c900010d7ca8 R14: 8880850ae0c0 R15: dc00 inode_dec_link_count include/linux/fs.h:2190 [inline] minix_rename+0x42b/0x7f0 fs/minix/namei.c:226 vfs_rename+0xa5f/0x1500 fs/namei.c:4309 do_renameat2+0x84a/0x1070 fs/namei.c:4456 __do_sys_renameat fs/namei.c:4497 [inline] __se_sys_renameat fs/namei.c:4494 [inline] __x64_sys_renameat+0x9a/0xb0 fs/namei.c:4494 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x444729 Code: 8d d7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b d7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffefa186b68 EFLAGS: 0246 ORIG_RAX: 0108 RAX: ffda RBX: 004002e0 RCX: 00444729 RDX: 0009 RSI: 2500 RDI: 000a RBP: 006d0018 R08: 004002e0 R09: 004002e0 R10: 200017c0 R11: 0246 R12: 00402310 R13: 004023a0 R14: R15: Kernel Offset: disabled Rebooting in 86400 seconds.. --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH] IPv6: sr: Fix End.X nexthop to use oif.
On Tue, 13 Oct 2020 17:31:51 +0530 Reji Thomas wrote:
> Currently End.X action doesn't consider the outgoing interface
> while looking up the nexthop.This breaks packet path functionality
> specifically while using link local address as the End.X nexthop.
> The patch fixes this by enforcing End.X action to have both nh6 and
> oif and using oif in lookup.It seems this is a day one issue.
>
> Fixes: 140f04c33bbc ("implement several seg6local actions")
>
> Signed-off-by: Reji Thomas
You need to respin to add the missing 'static' kbuild bot pointed out.
When you do please also edit the fixes tag to include the full subject,
it should look like this:
Fixes: 140f04c33bbc ("ipv6: sr: implement several seg6local actions")
and remove the empty line between the fixes tag and your signoff.
> @@ -239,6 +249,8 @@ static int input_action_end(struct sk_buff *skb, struct
> seg6_local_lwt *slwt)
> static int input_action_end_x(struct sk_buff *skb, struct seg6_local_lwt
> *slwt)
> {
> struct ipv6_sr_hdr *srh;
> + struct net *net = dev_net(skb->dev);
> + struct net_device *odev;
Please sort the variable declarations longest to shortest.
Re: [PATCH v6 2/4] mmc: dt-bindings: add support for MT8192 SoC
On Mon, 12 Oct 2020 20:45:45 +0800, Wenbin Mei wrote: > MT8192 mmc host ip is compatible with MT8183. > Add support for this. > > Signed-off-by: Wenbin Mei > --- > Documentation/devicetree/bindings/mmc/mtk-sd.yaml | 15 +-- > 1 file changed, 13 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH v8 11/14] PCI/RCEC: Add RCiEP's linked RCEC to AER/ERR
On Mon, 2020-10-12 at 17:58 -0500, Bjorn Helgaas wrote: > On Fri, Oct 09, 2020 at 11:51:39PM +, Kelley, Sean V wrote: > > On Fri, 2020-10-09 at 15:07 -0700, Sean V Kelley wrote: > > So I tested the following out, including your moving flr to aer.c: > > > > - Renamed flr_on_rciep() to flr_on_rc() for RC devices (RC_END and > > RC_EC) > > > > - Moved check on dev->rcec into aer_root_reset() including the FLR. > > > > - Reworked pci_walk_bridge() to drop extra dev argument and check > > locally for the bridge->rcec. Maybe should also check on type when > > checking on bridge->rcec. > > > > Note I didn't use the check on aer_cap existence because I think > > you > > had added that for simply being able to skip over for the non- > > native > > case and I handle that with the single goto at the beginning which > > takes you to the FLR. > > Right. Well, my thinking was that "root" would be a device with the > AER Root Error Command and Root Error Status registers, i.e., a Root > Port or RCEC. IIUC that basically means the APEI case where firmware > gives us an error record. Got it. > > Isn't the existing v5.9 code buggy in that it unconditionally pokes > these registers? I think the APEI path can end up here, and firmware > probably has not granted us control over AER. Yes, APEI path can end up here even in the absence of AER control. > > Somewhat related question: I'm a little skeptical about the fact that > aer_root_reset() currently does: > > - clear ROOT_PORT_INTR_ON_MESG_MASK > - do reset > - clear PCI_ERR_ROOT_STATUS > - enable ROOT_PORT_INTR_ON_MESG_MASK It's a bit of a mix and growing with RC_END handling. > > In the APEI path all this AER register manipulation must be done by > firmware before passing the error record to the OS. So in the native > case where the OS does own the AER registers, why can't the OS do > that > manipulation in the same order, i.e., all before doing the reset? And you're right, the mix here imposes additional complexity for native versus non-native. If you're not actively engaged with the code, it's not obvious. So, yes moving it out would make more sense. > > > So this is rough, compiled, tested with AER injections but that's > > it... > > I couldn't actually apply the patch below because it seems to be > whitespace-damaged, but I think I like it. Yes, it was a quick copy-paste to an existing email. Will work with your branch. > > - It would be nice to be able to just call pcie_flr() and not have > to add flr_on_rc(). I can't remember why we need the > pcie_has_flr() / pcie_flr() dance. It seems racy and ugly, but I > have a vague recollection that there actually is some reason for > it. I'll have a look. > > - I would *rather* consolidate the AER register updates and test > for > the non-native case once instead of treating it like a completely > separate path with a "goto". But maybe not possible. Not a big > deal either way. Following your line of reasoning above, I think we can better consolidate the AER register updates. > > - Getting rid of the extra "dev" argument to pci_walk_bridge() is a > great side-effect. I didn't even notice that. > > - If we can simplify that "state == pci_channel_io_frozen" case as > this does, that is a *big* deal because there are other patches > just waiting to touch that reset and it will be much simpler if > there's only one reset_subordinate_devices() call there. Agreed. > > If you do work this up, I'd really appreciate it if you can start > with > my pci/err branch so I don't have to re-do all the tweaks I've > already > done: > > > https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/err > Will do. Thanks, Sean > Bjorn
Re: [PATCH v6 1/4] dt-bindings: mmc: Convert mtk-sd to json-schema
On Mon, Oct 12, 2020 at 08:45:44PM +0800, Wenbin Mei wrote:
> Convert the mtk-sd binding to DT schema format using json-schema.
>
> Signed-off-by: Wenbin Mei
> ---
> .../devicetree/bindings/mmc/mtk-sd.txt| 75
> .../devicetree/bindings/mmc/mtk-sd.yaml | 163 ++
> 2 files changed, 163 insertions(+), 75 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mmc/mtk-sd.txt
> create mode 100644 Documentation/devicetree/bindings/mmc/mtk-sd.yaml
>
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> deleted file mode 100644
> index 26a8f320a156..
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ /dev/null
> @@ -1,75 +0,0 @@
> -* MTK MMC controller
> -
> -The MTK MSDC can act as a MMC controller
> -to support MMC, SD, and SDIO types of memory cards.
> -
> -This file documents differences between the core properties in mmc.txt
> -and the properties used by the msdc driver.
> -
> -Required properties:
> -- compatible: value should be either of the following.
> - "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135
> - "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
> - "mediatek,mt8183-mmc": for mmc host ip compatible with mt8183
> - "mediatek,mt8516-mmc": for mmc host ip compatible with mt8516
> - "mediatek,mt6779-mmc": for mmc host ip compatible with mt6779
> - "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
> - "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
> - "mediatek,mt7622-mmc": for MT7622 SoC
> - "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC
> - "mediatek,mt7620-mmc", for MT7621 SoC (and others)
> -
> -- reg: physical base address of the controller and length
> -- interrupts: Should contain MSDC interrupt number
> -- clocks: Should contain phandle for the clock feeding the MMC controller
> -- clock-names: Should contain the following:
> - "source" - source clock (required)
> - "hclk" - HCLK which used for host (required)
> - "source_cg" - independent source clock gate (required for MT2712)
> - "bus_clk" - bus clock used for internal register access (required for
> MT2712 MSDC0/3)
> -- pinctrl-names: should be "default", "state_uhs"
> -- pinctrl-0: should contain default/high speed pin ctrl
> -- pinctrl-1: should contain uhs mode pin ctrl
> -- vmmc-supply: power to the Core
> -- vqmmc-supply: power to the IO
> -
> -Optional properties:
> -- assigned-clocks: PLL of the source clock
> -- assigned-clock-parents: parent of source clock, used for HS400 mode to get
> 400Mhz source clock
> -- hs400-ds-delay: HS400 DS delay setting
> -- mediatek,hs200-cmd-int-delay: HS200 command internal delay setting.
> - This field has total 32 stages.
> - The value is an integer from 0 to 31.
> -- mediatek,hs400-cmd-int-delay: HS400 command internal delay setting
> - This field has total 32 stages.
> - The value is an integer from 0 to 31.
> -- mediatek,hs400-cmd-resp-sel-rising: HS400 command response sample
> selection
> -If present,HS400 command responses are
> sampled on rising edges.
> -If not present,HS400 command responses
> are sampled on falling edges.
> -- mediatek,latch-ck: Some SoCs do not support enhance_rx, need set correct
> latch-ck to avoid data crc
> - error caused by stop clock(fifo full)
> - Valid range = [0:0x7]. if not present, default value is 0.
> - applied to compatible "mediatek,mt2701-mmc".
> -- resets: Phandle and reset specifier pair to softreset line of MSDC IP.
> -- reset-names: Should be "hrst".
> -
> -Examples:
> -mmc0: mmc@1123 {
> - compatible = "mediatek,mt8173-mmc", "mediatek,mt8135-mmc";
> - reg = <0 0x1123 0 0x108>;
> - interrupts = ;
> - vmmc-supply = <_vemc_3v3_reg>;
> - vqmmc-supply = <_vio18_reg>;
> - clocks = < CLK_PERI_MSDC30_0>,
> - < CLK_TOP_MSDC50_0_H_SEL>;
> - clock-names = "source", "hclk";
> - pinctrl-names = "default", "state_uhs";
> - pinctrl-0 = <_pins_default>;
> - pinctrl-1 = <_pins_uhs>;
> - assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
> - assigned-clock-parents = < CLK_TOP_MSDCPLL_D2>;
> - hs400-ds-delay = <0x14015>;
> - mediatek,hs200-cmd-int-delay = <26>;
> - mediatek,hs400-cmd-int-delay = <14>;
> - mediatek,hs400-cmd-resp-sel-rising;
> -};
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
> b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
> new file mode 100644
> index ..21a2fce5b7ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
> @@ -0,0 +1,163 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id:
[PATCH][V2] ima: Fix sizeof mismatches
From: Colin Ian King
An incorrect sizeof is being used, sizeof(*fields) is not correct,
it should be sizeof(**fields). This is not causing a problem since
the size of these is the same. Fix this.
Also replace kmalloc_array and memcpy with a kmemdup.
Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)")
Fixes: 1bd7face7439 ("ima: allocate field pointers array on demand in
template_desc_init_fields()")
Signed-off-by: Colin Ian King
---
V2: Replace kmalloc_array and memcpy with kmemdup as suggested by
Joe Perches.
---
security/integrity/ima/ima_template.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_template.c
b/security/integrity/ima/ima_template.c
index 1e89e2d3851f..83886e767678 100644
--- a/security/integrity/ima/ima_template.c
+++ b/security/integrity/ima/ima_template.c
@@ -216,11 +216,10 @@ int template_desc_init_fields(const char *template_fmt,
}
if (fields && num_fields) {
- *fields = kmalloc_array(i, sizeof(*fields), GFP_KERNEL);
+ *fields = kmemdup(found_fields, i * sizeof(**fields),
GFP_KERNEL);
if (*fields == NULL)
return -ENOMEM;
- memcpy(*fields, found_fields, i * sizeof(*fields));
*num_fields = i;
}
--
2.27.0
Re: [PATCH v2 1/1] sched/uclamp: add SCHED_FLAG_UTIL_CLAMP_RESET flag to reset uclamp
On Tue, Oct 13, 2020 at 15:32:46 +0200, Qais Yousef
wrote...
> On 10/13/20 13:46, Patrick Bellasi wrote:
>> > So IMO you just need a single SCHED_FLAG_UTIL_CLAMP_RESET that if set in
>> > the
>> > attr, you just execute that loop in __setscheduler_uclamp() + reset
>> > uc_se->user_defined.
>> >
>> > It should be invalid to pass the SCHED_FLAG_UTIL_CLAMP_RESET with
>> > SCHED_FLAG_UTIL_CLAMP_MIN/MAX. Both have contradictory meaning IMO.
>> > If user passes both we should return an EINVAL error.
>>
>> Passing in _CLAMP_RESET|_CLAMP_MIN will mean reset the min value while
>> keeping the max at whatever it is. I think there could be cases where
>> this support could be on hand.
>
> I am not convinced personally. I'm anxious about what this fine grained
> control
> means and how it should be used. I think less is more in this case and we can
> always relax the restriction (appropriately) later if it's *really* required.
>
> Particularly the fact that this user_defined is per uclamp_se and that it
> affects the cgroup behavior is implementation details this API shouldn't rely
> on.
The user_defined flag is an implementation details: true, but since the
beginning uclamp _always_ allowed a task to set only one of its clamp
values.
That's why we have UTIL_CLAMP_{MIN,MAX} as separate flags and all the
logic in place to set only one of the two.
> A generic RESET my uclamp settings makes more sense for me as a long term
> API to maintain.
>
> Actually maybe we should even go for a more explicit
> SCHED_FLAG_UTIL_CLAMP_INHERIT_CGROUP flag instead. If we decide to abandon the
> support for this feature in the future, at least we can make it return an
> error
> without affecting other functionality because of the implicit nature of
> SCHED_FLAG_UTIL_CLAMP_RESET means inherit cgroup value too.
That's not true and it's an even worst implementation detail what you
want to expose.
A task without a task specific clamp _always_ inherits the system
defaults. Resetting a task specific clamp already makes sense also
_without_ cgroups. It means: just do whatever the system allows you to
do.
Only if you are running with CGRoups enabled and the task happens to be
_not_ in the root group, the "CGroups inheritance" happens.
But that's exactly an internal detail a task should not care about.
> That being said, I am not strongly against the fine grained approach if that's
> what Yun wants now or what you both prefer.
It's not a fine grained approach, it's just adding a reset mechanism for
what uclamp already allows to do: setting min and max clamps
independently.
Regarding use cases, I also believe we have many more use cases of tasks
interested in setting/resetting just one clamp than tasks interested in
"fine grain" controlling both clamps at the same time.
> I just think the name of the flag needs to change to be more explicit
> too then.
I don't agree on that and, again, I see much more fine grained details and
internals exposure in what you propose compared to a single generic
_RESET flag.
> It'd be good to hear what others think.
I agree on that ;)
Re: [PATCH 1/2] net: store KCOV remote handle in sk_buff
On Tue, 13 Oct 2020 18:59:28 +0300 Aleksandr Nogikh wrote: > On Mon, 12 Oct 2020 at 09:04, Dmitry Vyukov wrote: > > > > On Sat, Oct 10, 2020 at 5:14 PM Jakub Kicinski wrote: > > > > > > On Sat, 10 Oct 2020 09:54:57 +0200 Dmitry Vyukov wrote: > > > > On Sat, Oct 10, 2020 at 1:16 AM Jakub Kicinski wrote: > > > > > [...] > > > > > Could you use skb_extensions for this? > > > > > > > > Why? If for space, this is already under a non-production ifdef. > > > > > > I understand, but the skb_ext infra is there for uncommon use cases > > > like this one. Any particular reason you don't want to use it? > > > The slight LoC increase? > > > > > > Is there any precedent for adding the kcov field to other performance > > > critical structures? > > It would be great to come to some conclusion on where exactly to store > kcov_handle. Technically, it is possible to use skb extensions for the > purpose, though it will indeed slightly increase the complexity. > > Jakub, you think that kcov_handle should be added as an skb extension, > right? That'd be preferable. I understand with current use cases it doesn't really matter, but history shows people come up with all sort of wonderful use cases down the line. And when they do they rarely go back and fix such fundamental minutiae. > Though I do not really object to moving the field, it still seems to > me that sk_buff itself is a better place. Right now skb extensions > store values that are local to specific protocols and that are only > meaningful in the context of these protocols (correct me if I'm > wrong). Although this patch only adds remote kcov coverage to the wifi > code, kcov_handle can be meaningful for other protocols as well - just > like the already existing sk_buff fields. So adding kcov_handle to skb > extensions will break this logical separation. It's not as much protocols as subsystems. The values are meaningful to a subsystem which inserts them, that doesn't mean single layer of the stack. If it was about storing layer's context we would just use skb->cb. So I think the kcov use matches pretty well. Florian, what's your take?
Re: [PATCH 3/3] pwm: Add Raspberry Pi Firmware based PWM bus
Hi Uwe,
On Tue, 2020-10-13 at 14:17 +0200, Uwe Kleine-König wrote:
> Hello Nicolas,
>
> On Tue, Oct 13, 2020 at 01:20:00PM +0200, Nicolas Saenz Julienne wrote:
> > On Mon, 2020-10-12 at 09:06 +0200, Uwe Kleine-König wrote:
> > > > + depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST &&
> > > > !RASPBERRYPI_FIRMWARE)
> > >
> > > This is more complicated than necessary.
> > >
> > > depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
> > >
> > > is logically equivalent.
> >
> > It's not exactly the same, see patch 7ed915059c300 ("gpio: raspberrypi-ext:
> > fix
> > firmware dependency ") which explains why this pattern is needed.
I'll add a comment.
> Hmm, this is strange, but if Arnd doesn't know a better solution, then
> be it so. Is this idiom usual enough to not justify a comment?
>
> > > What happens if duty_cycle happens to be bigger than RPI_PWM_MAX_DUTY?
> > >
> > > I think the right thing to do here is:
> > >
> > > if (state->period < RPI_PWM_PERIOD_NS ||
> >
> > Why not using state->period != RPI_PWM_PERIOD_NS here?
>
> From the consumer's point of view having to hit the only correct period
> is hard. So the usual convention is to provide the biggest period not
> bigger than the requested one. (The idea for the future is to provide a
> pwm_round_state() function which allows to find out the effect of
> pwm_apply_state() with the same arguments. This then allows to
> efficiently find the best setting for the consumer.)
Fair enough.
> > > Huh, why do you have to do this twice, just with different error
> > > messages? I assume you want to set RPI_PWM_DEF_DUTY_REG? What is the
> > > effect of writing this property?
> >
> > Obviously, I failed to change the register name.
> >
> > This is supposed to set the default duty cycle after resetting the board. I
> > added it so as to keep compatibility with the downstream version of this.
> >
> > I'll add a comment to explain this.
>
> fine.
>
> > > > + int ret;
> > > > +
> > > > + firmware_node = of_get_parent(dev->of_node);
> > > > + if (!firmware_node) {
> > > > + dev_err(dev, "Missing firmware node\n");
> > > > + return -ENOENT;
> > > > + }
> > > > +
> > > > + firmware = rpi_firmware_get(firmware_node);
> > > > + of_node_put(firmware_node);
> > > > + if (!firmware)
> > > > + return -EPROBE_DEFER;
> > >
> > > I don't see a mechanism that prevents the driver providing the firmware
> > > going away while the PWM is still in use.
> >
> > There isn't an explicit one. But since you depend on a symbol from the
> > firmware
> > driver you won't be able to remove the kernel module before removing the PMW
> > one.
>
> this prevents the that the module is unloaded, but not that the driver
> is unbound.
Yes, if you were to unbind the firmware device all devices that depend on it
(there are a bunch of them) would access freed memory. Yet again, there is no
hotplug functionality, so short of being useful for development it'd be very
rare for someone to unbind it. We've been living with it as such for a long
time. Not to say that is something not to fix, but from my perspective it's
just a corner-case.
We are using 'simple-mfd' in order to probe all devices under the
firmware interface, so my first intuition would be to add support for
automatically unbinding of consumer devices in of/platform.c. See:
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b557a0fcd4ba..d24f2412d518 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -390,7 +390,13 @@ static int of_platform_bus_create(struct device_node *bus,
}
dev = of_platform_device_create_pdata(bus, bus_id, platform_data,
parent);
- if (!dev || !of_match_node(matches, bus))
+ if (!dev)
+ return 0;
+
+ if (parent && of_device_is_compatible(parent->of_node, "simple-mfd"))
+ device_link_add(>dev, parent, DL_FLAG_AUTOREMOVE_CONSUMER);
+
+ if (!of_match_node(matches, bus))
return 0;
for_each_child_of_node(bus, child) {
If this is too much for OF maintainers, we could simply create the link upon
calling rpi_firmware_get().
This solves the problem of getting a kernel panic because of the use after
free, but you'll still get some warnings after unbinding from the GPIO
subsystem, for example, as we just removed a gpiochip that still has consumers
up. I guess device links only go so far.
Any ideas/comments?
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 01/23] dt-bindings: introduce silabs,wfx.yaml
On Mon, Oct 12, 2020 at 12:46:26PM +0200, Jerome Pouiller wrote: > From: Jérôme Pouiller > > Signed-off-by: Jérôme Pouiller > --- > .../bindings/net/wireless/silabs,wfx.yaml | 125 ++ > 1 file changed, 125 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml > > diff --git a/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml > b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml > new file mode 100644 > index ..43b5630c0407 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml > @@ -0,0 +1,125 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +# Copyright (c) 2020, Silicon Laboratories, Inc. > +%YAML 1.2 > +--- > + > +$id: http://devicetree.org/schemas/net/wireless/silabs,wfx.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Silicon Labs WFxxx devicetree bindings > + > +maintainers: > + - Jérôme Pouiller > + > +description: > + The WFxxx chip series can be connected via SPI or via SDIO. What does this chip do? WiFi or some other wireless? > + > + For SDIO':' > + > +The driver is able to detect a WFxxx chip on SDIO bus by matching its > Vendor > +ID and Product ID. However, driver will only provide limited features in > +this case. Thus declaring WFxxx chip in device tree is recommended (and > may > +become mandatory in the future). > + > +In addition, it is recommended to declare a mmc-pwrseq on SDIO host above > +WFx. Without it, you may encounter issues with warm boot. The mmc-pwrseq > +should be compatible with mmc-pwrseq-simple. Please consult > +Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt for more > +information. > + > + For SPI':' > + > +In add of the properties below, please consult > +Documentation/devicetree/bindings/spi/spi-controller.yaml for optional > SPI > +related properties. > + > + Note that in add of the properties below, the WFx driver also supports > + `mac-address` and `local-mac-address` as described in > + Documentation/devicetree/bindings/net/ethernet.txt Note what ethernet.txt contains... This should have a $ref to ethernet-controller.yaml to express the above. You can add 'mac-address: true' if you want to be explicit about what properties are used. > + > +properties: > + compatible: > +const: silabs,wf200 blank line between each DT property. > + reg: > +description: > + When used on SDIO bus, must be set to 1. When used on SPI bus, > it is > + the chip select address of the device as defined in the SPI devices > + bindings. > +maxItems: 1 > + spi-max-frequency: > +description: (SPI only) Maximum SPI clocking speed of device in Hz. No need to redefine a common property. > +maxItems: 1 Not an array. Just need: spi-max-frequency: true > + interrupts: > +description: The interrupt line. Triggers IRQ_TYPE_LEVEL_HIGH and > + IRQ_TYPE_EDGE_RISING are both supported by the chip and the driver. > When > + SPI is used, this property is required. When SDIO is used, the > "in-band" > + interrupt provided by the SDIO bus is used unless an interrupt is > defined > + in the Device Tree. > +maxItems: 1 > + reset-gpios: > +description: (SPI only) Phandle of gpio that will be used to reset chip > + during probe. Without this property, you may encounter issues with warm > + boot. (For legacy purpose, the gpio in inverted when compatible == > + "silabs,wfx-spi") > + > + For SDIO, the reset gpio should declared using a mmc-pwrseq. > +maxItems: 1 > + wakeup-gpios: > +description: Phandle of gpio that will be used to wake-up chip. Without > this > + property, driver will disable most of power saving features. > +maxItems: 1 > + config-file: > +description: Use an alternative file as PDS. Default is `wf200.pds`. Only > + necessary for development/debug purpose. 'firmware-name' is typically what we'd use here. Though if just for debug/dev, perhaps do a debugfs interface for this instead. As DT should come from the firmware/bootloader, requiring changing the DT for dev/debug is not the easiest workflow compared to doing something from userspace. > +maxItems: 1 Looks like a string, not an array. > + > +required: > + - compatible > + - reg Will need additionalProperties or unevaluatedProperties depending on whether you list out properties from ethernet-controller.yaml or not. Rob
Re: [PATCH v2 01/24] docs: hwmon: adm1266.rst: fix a broken reference
On Tue, Oct 13, 2020 at 02:14:28PM +0200, Mauro Carvalho Chehab wrote: > The reference was missing the extension, causing the > check script to complain. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Guenter Roeck > --- > Documentation/hwmon/adm1266.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/hwmon/adm1266.rst b/Documentation/hwmon/adm1266.rst > index 9257f8a48650..2b877011cfdf 100644 > --- a/Documentation/hwmon/adm1266.rst > +++ b/Documentation/hwmon/adm1266.rst > @@ -20,7 +20,7 @@ ADM1266 is a sequencer that features voltage readback from > 17 channels via an > integrated 12 bit SAR ADC, accessed using a PMBus interface. > > The driver is a client driver to the core PMBus driver. Please see > -Documentation/hwmon/pmbus for details on PMBus client drivers. > +Documentation/hwmon/pmbus.rst for details on PMBus client drivers. > > > Sysfs entries > -- > 2.26.2 >
Re: [PATCH v2 17/24] docs: hwmon: mp2975.rst: address some html build warnings
On Tue, Oct 13, 2020 at 02:14:44PM +0200, Mauro Carvalho Chehab wrote:
> .../Documentation/hwmon/mp2975.rst:25: WARNING: Unexpected indentation.
> .../Documentation/hwmon/mp2975.rst:27: WARNING: Block quote ends without
> a blank line; unexpected unindent.
> .../Documentation/hwmon/mp2975.rst:69: WARNING: Unexpected indentation.
> .../Documentation/hwmon/mp2975.rst:70: WARNING: Block quote ends without
> a blank line; unexpected unindent.
> .../Documentation/hwmon/mp2975.rst:72: WARNING: Bullet list ends without
> a blank line; unexpected unindent.
> .../Documentation/hwmon/mp2975.rst: WARNING: document isn't included in
> any toctree
>
> List blocks should have blank lines before and after them,
> in order to be properly parsed.
>
> Fixes: 4beb7a028e9f ("hwmon: (pmbus) Add support for MPS Multi-phase mp2975
> controller")
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Guenter Roeck
> ---
> Documentation/hwmon/index.rst | 1 +
> Documentation/hwmon/mp2975.rst | 14 +-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
> index e6b91ab12978..b797db738225 100644
> --- a/Documentation/hwmon/index.rst
> +++ b/Documentation/hwmon/index.rst
> @@ -132,6 +132,7 @@ Hardware Monitoring Kernel Drivers
> mcp3021
> menf21bmc
> mlxreg-fan
> + mp2975
> nct6683
> nct6775
> nct7802
> diff --git a/Documentation/hwmon/mp2975.rst b/Documentation/hwmon/mp2975.rst
> index 5b0609c62f48..81d816b71490 100644
> --- a/Documentation/hwmon/mp2975.rst
> +++ b/Documentation/hwmon/mp2975.rst
> @@ -20,6 +20,7 @@ This driver implements support for Monolithic Power
> Systems, Inc. (MPS)
> vendor dual-loop, digital, multi-phase controller MP2975.
>
> This device:
> +
> - Supports up to two power rail.
> - Provides 8 pulse-width modulations (PWMs), and can be configured up
>to 8-phase operation for rail 1 and up to 4-phase operation for rail
> @@ -32,10 +33,12 @@ This device:
>10-mV DAC, IMVP9 mode with 5-mV DAC.
>
> Device supports:
> +
> - SVID interface.
> - AVSBus interface.
>
> Device complaint with:
> +
> - PMBus rev 1.3 interface.
>
> Device supports direct format for reading output current, output voltage,
> @@ -45,11 +48,14 @@ Device supports VID and direct formats for reading output
> voltage.
> The below VID modes are supported: VR12, VR13, IMVP9.
>
> The driver provides the next attributes for the current:
> +
> - for current in: input, maximum alarm;
> - for current out input, maximum alarm and highest values;
> - for phase current: input and label.
> -attributes.
> + attributes.
> +
> The driver exports the following attributes via the 'sysfs' files, where
> +
> - 'n' is number of telemetry pages (from 1 to 2);
> - 'k' is number of configured phases (from 1 to 8);
> - indexes 1, 1*n for "iin";
> @@ -65,11 +71,14 @@ The driver exports the following attributes via the
> 'sysfs' files, where
> **curr[1-{2n+k}]_label**
>
> The driver provides the next attributes for the voltage:
> +
> - for voltage in: input, high critical threshold, high critical alarm, all
> only
>from page 0;
> - for voltage out: input, low and high critical thresholds, low and high
>critical alarms, from pages 0 and 1;
> +
> The driver exports the following attributes via the 'sysfs' files, where
> +
> - 'n' is number of telemetry pages (from 1 to 2);
> - indexes 1 for "iin";
> - indexes n+1, n+2 for "vout";
> @@ -87,9 +96,12 @@ The driver exports the following attributes via the
> 'sysfs' files, where
> **in[2-{n+1}1_lcrit_alarm**
>
> The driver provides the next attributes for the power:
> +
> - for power in alarm and input.
> - for power out: highest and input.
> +
> The driver exports the following attributes via the 'sysfs' files, where
> +
> - 'n' is number of telemetry pages (from 1 to 2);
> - indexes 1 for "pin";
> - indexes n+1, n+2 for "pout";
> --
> 2.26.2
>
Re: [PATCH v3 6/8] iommu/arm-smmu: Add impl hook for inherit boot mappings
On 2020-10-12 08:31, Bjorn Andersson wrote:
On Mon 21 Sep 23:08 CEST 2020, Will Deacon wrote:
On Sat, Sep 12, 2020 at 10:25:59PM -0500, Bjorn Andersson wrote:
On Fri 11 Sep 12:13 CDT 2020, Robin Murphy wrote:
On 2020-09-04 16:55, Bjorn Andersson wrote:
Add a new operation to allow platform implementations to inherit any
stream mappings from the boot loader.
Is there a reason we need an explicit step for this? The aim of the
cfg_probe hook is that the SMMU software state should all be set up by then,
and you can mess about with it however you like before arm_smmu_reset()
actually commits anything to hardware. I would have thought you could
permanently steal a context bank, configure it as your bypass hole, read out
the previous SME configuration and tweak smmu->smrs and smmu->s2crs
appropriately all together "invisibly" at that point.
I did this because as of 6a79a5a3842b ("iommu/arm-smmu: Call
configuration impl hook before consuming features") we no longer have
setup pgsize_bitmap as we hit cfg_probe, which means that I need to
replicate this logic to set up the iommu_domain.
If I avoid setting up an iommu_domain for the identity context, as you
request in patch 8, this shouldn't be needed anymore.
If that can't work, I'm very curious as to what I've overlooked.
I believe that will work, I will rework the patches and try it out.
Did you get a chance to rework this?
Finally got a chance to dig through this properly.
Initial results where positive and with an implementation of cfg_probe
in qcom_smmu_impl I'm able to probe the arm-smmu driver just fine - and
display (e.g. efifb) stays alive.
Unfortunately as the display driver (drivers/gpu/drm/msm) is about to
probe a new iommu domain is created, which due to its match against
qcom_smmu_client_of_match[] becomes of type IOMMU_DOMAIN_IDENTITY.
This results in a S2CR of BYPASS type, which the firmware intercepts and
turns the stream into a type FAULT.
So while the cfg_probe looks very reasonable we're still in need of a
mechanism to use the fake identity context for the iommu domain
associated with the display controller.
Yes, we'll still need some kind of hook somewhere to make identity
domains work at all - my point about cfg_probe was to keep the
reservation and configuration of the special identity context, plus the
handling of the initial SME state, simple and entirely internal to the
impl. In terms of where said hook should be, TBH it might actually work
out pretty clean to simply hook GR0 register accesses so you can rewrite
between S2CR bypass entries and translation entries targeting your
reserved context on-the-fly. Failing that, something to massage "type"
and "cbndx" in arm_smmu_domain_add_master() would be the next best
option, I think.
Robin.
The workings of the display driver is that it gets the iommu domain
setup for byass and then after that creates a translation context for
this same stream where it maps the framebuffer.
For testing purposes I made def_domain_type always return 0 in the qcom
impl and the result is that we get a few page faults while probing the
display driver, but these are handled somewhat gracefully and the
initialization did proceed and the system comes up nicely (but in the
case that the display driver would probe defer this leads to an storm of
faults as the screen continues to be refreshed).
TL;DR I think we still need to have a way to get the arm-smmu driver to
allow the qcom implementation to configure identity domains to use
translation - but we can make the setup of the identity context a detail
of the qcom driver.
Regards,
Bjorn
Re: [PATCH v6 68/80] nl80211: docs: add a description for s1g_cap parameter
On 2020-10-13 04:54, Mauro Carvalho Chehab wrote:
Changeset df78a0c0b67d ("nl80211: S1G band and channel definitions")
added a new parameter, but didn't add the corresponding kernel-doc
markup, as repoted when doing "make htmldocs":
./include/net/cfg80211.h:471: warning: Function parameter or member
's1g_cap' not described in 'ieee80211_supported_band'
Add a documentation for it.
Sorry about that. Patch looks good.
Fixes: df78a0c0b67d ("nl80211: S1G band and channel definitions")
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Thomas Pedersen
--
thomas
Re: [PATCH v2 3/3] mm/slub: Actually fix freelist pointer vs redzoning
On 10/9/20 9:54 PM, Kees Cook wrote:
It turns out that SLUB redzoning ("slub_debug=Z") checks from
s->object_size rather than from s->inuse (which is normally bumped to
make room for the freelist pointer), so a cache created with an object
size less than 24 would have their freelist pointer written beyond
s->object_size, causing the redzone to corrupt the freelist pointer.
Is this accurate? Seems to me that redzone is (re)initialized only when
freepointer is not active. So it is actually freelist pointer corrupting the
redzone...
This was very visible with "slub_debug=ZF":
... as this report shows :)
BUG test (Tainted: GB): Right Redzone overwritten
-
INFO: 0x957ead1c05de-0x957ead1c05df @offset=1502. First byte 0x1a
instead of 0xbb
INFO: Slab 0xef3950b47000 objects=170 used=170 fp=0x
flags=0x8200
INFO: Object 0x957ead1c05d8 @offset=1496 fp=0x957ead1c0620
Redzone (ptrval): bb bb bb bb bb bb bb bb
Object (ptrval): 00 00 00 00 00 f6 f4 a5
Redzone (ptrval): 40 1d e8 1a aa@
Padding (ptrval): 00 00 00 00 00 00 00 00
Adjust the offset to stay within s->object_size.
Reported-by: Marco Elver
Link:
https://lore.kernel.org/linux-mm/20200807160627.ga1420...@elver.google.com/
Fixes: 89b83f282d8b (slub: avoid redzone when choosing freepointer location)
Tested-by: Marco Elver
Link:
https://lore.kernel.org/lkml/canpmjnowz5vpkqn+sywovtkfb4vst-rpwyenbmak0dlcpqs...@mail.gmail.com
Signed-off-by: Kees Cook
Acked-by: Vlastimil Babka
This struggle to get it right perhaps calls for some selftests of all
combinations of flags that affect object layout, e.g. of
redzone/poison/store_user, on sizes from sizeof(void *) to e.g. 3*sizeof(void
*), with sanity_checks enabled. Shouldn't be too many tests...
---
mm/slub.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index 752fad36522c..6f115e56c5d0 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3637,7 +3637,6 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
{
slab_flags_t flags = s->flags;
unsigned int size = s->object_size;
- unsigned int freepointer_area;
unsigned int order;
/*
@@ -3646,13 +3645,6 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
* the possible location of the free pointer.
*/
size = ALIGN(size, sizeof(void *));
- /*
-* This is the area of the object where a freepointer can be
-* safely written. If redzoning adds more to the inuse size, we
-* can't use that portion for writing the freepointer, so
-* s->offset must be limited within this for the general case.
-*/
- freepointer_area = size;
#ifdef CONFIG_SLUB_DEBUG
/*
@@ -3678,7 +3670,7 @@ static int calculate_sizes(struct kmem_cache *s, int
forced_order)
/*
* With that we have determined the number of bytes in actual use
-* by the object. This is the potential offset to the free pointer.
+* by the object and redzoning.
*/
s->inuse = size;
@@ -3701,13 +3693,13 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
*/
s->offset = size;
size += sizeof(void *);
- } else if (freepointer_area > sizeof(void *)) {
+ } else {
/*
* Store freelist pointer near middle of object to keep
* it away from the edges of the object to avoid small
* sized over/underflows from neighboring allocations.
*/
- s->offset = ALIGN(freepointer_area / 2, sizeof(void *));
+ s->offset = ALIGN_DOWN(s->object_size / 2, sizeof(void *));
}
#ifdef CONFIG_SLUB_DEBUG
Re: [PATCH] can: Explain PDU in CAN_ISOTP help text
On 13.10.20 16:13, Geert Uytterhoeven wrote: The help text for the CAN_ISOTP config symbol uses the acronym "PDU". However, this acronym is not explained here, nor in Documentation/networking/can.rst. Expand the acronym to make it easier for users to decide if they need to enable the CAN_ISOTP option or not. Signed-off-by: Geert Uytterhoeven Acked-by: Oliver Hartkopp Yes, when you are so deep into it that PDU becomes a word like dog or cat ;-) Thanks, Oliver --- net/can/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/can/Kconfig b/net/can/Kconfig index 224e5e0283a986d9..7c9958df91d353c8 100644 --- a/net/can/Kconfig +++ b/net/can/Kconfig @@ -62,8 +62,9 @@ config CAN_ISOTP communication between CAN nodes via two defined CAN Identifiers. As CAN frames can only transport a small amount of data bytes (max. 8 bytes for 'classic' CAN and max. 64 bytes for CAN FD) this - segmentation is needed to transport longer PDUs as needed e.g. for - vehicle diagnosis (UDS, ISO 14229) or IP-over-CAN traffic. + segmentation is needed to transport longer Protocol Data Units (PDU) + as needed e.g. for vehicle diagnosis (UDS, ISO 14229) or IP-over-CAN + traffic. This protocol driver implements data transfers according to ISO 15765-2:2016 for 'classic' CAN and CAN FD frame types. If you want to perform automotive vehicle diagnostic services (UDS),
Re: [PATCH 5.8 000/124] 5.8.15-rc1 review
On Mon, Oct 12, 2020 at 03:30:04PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.8.15 release. > There are 124 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 14 Oct 2020 13:31:22 +. > Anything received after that time might be too late. > Build results: total: 154 pass: 154 fail: 0 Qemu test results: total: 430 pass: 430 fail: 0 Tested-by: Guenter Roeck Guenter
