Re: [tip: irq/core] genirq: Add IRQF_NO_AUTOEN for request_irq/nmi()
Dmitry, On Tue, Mar 23 2021 at 15:44, Dmitry Torokhov wrote: > On Thu, Mar 04, 2021 at 07:50:31PM +0100, Thomas Gleixner wrote: >> Please hold on: >> >> >> https://lkml.kernel.org/r/CAHk-=wgZjJ89jeH72TC3i6N%2Bz9WEY=3ysp8zr9narucsqca...@mail.gmail.com >> >> I'll recreate a tag for you once rc2 is out. > > It looks like the change has been picked up as > cbe16f35bee6880becca6f20d2ebf6b457148552i on top of -rc2, > but I don't think there is tag for it? Sorry, forgot about it. Here you go: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-no-autoen-2021-03-25 Thanks, tglx
[PATCH] include: linux: struct device is declared twice
struct device has been declared at 133rd line.
Remove the duplicate.
Signed-off-by: Wan Jiabing
---
include/linux/libnvdimm.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
index 01f251b6e36c..89b69e645ac7 100644
--- a/include/linux/libnvdimm.h
+++ b/include/linux/libnvdimm.h
@@ -141,7 +141,6 @@ static inline void __iomem *devm_nvdimm_ioremap(struct
device *dev,
struct nvdimm_bus;
struct module;
-struct device;
struct nd_blk_region;
struct nd_blk_region_desc {
int (*enable)(struct nvdimm_bus *nvdimm_bus, struct device *dev);
--
2.25.1
Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the first use of dynamic user state
On Mar 24, 2021, at 22:12, Liu, Jing2 wrote: > On 3/25/2021 5:09 AM, Len Brown wrote: >> >> For AMX, we must still reserve the space, but we are not going to write zeros >> for clean state. We so this in software by checking XINUSE=0, and clearing >> the xstate_bf for the XSAVE. As a result, for XINUSE=0, we can skip >> writing the zeros, even though we can't compress the space. > So my understanding is that clearing xstate_bv will not help prevent saving > zeros, but only not masking EDX:EAX, since the following logic. Not sure if > this is just what you mean. :) FWIW, PATCH21 [1] uses the instruction mask to skip writing zeros on sigframe. Then, XSAVE will clear the xstate_bv for the xtile data state bit. [1] https://lore.kernel.org/lkml/20210221185637.19281-22-chang.seok@intel.com/ Thanks, Chang
[PATCH] include: linux: struct path is declared twice
struct path has been declared at 85th line. Remove the duplicate. Signed-off-by: Wan Jiabing --- include/linux/mount.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/mount.h b/include/linux/mount.h index 5d92a7e1a742..30272f961af7 100644 --- a/include/linux/mount.h +++ b/include/linux/mount.h @@ -94,7 +94,6 @@ extern struct vfsmount *mnt_clone_internal(const struct path *path); extern bool __mnt_is_readonly(struct vfsmount *mnt); extern bool mnt_may_suid(struct vfsmount *mnt); -struct path; extern struct vfsmount *clone_private_mount(const struct path *path); extern int __mnt_want_write(struct vfsmount *); extern void __mnt_drop_write(struct vfsmount *); -- 2.25.1
Re: [mm] f3344adf38: fxmark.hdd_btrfs_DWAL_63_bufferedio.works/sec -52.4% regression
Hi Linus,
Some updates on this, we found the regression is related with the
percpu stuff change and BTRFS, though the exact relation is unknown yet.
Some details below.
+ Michal who helped providing useful links for checking it.
+ Josef Bacik, for this is BTRFS related
On Fri, Mar 19, 2021 at 11:21:44AM +0800, Feng Tang wrote:
> Hi Linus,
>
> On Mon, Mar 15, 2021 at 01:42:50PM -0700, Linus Torvalds wrote:
> > On Sun, Mar 14, 2021 at 11:30 PM kernel test robot
> > wrote:
> > > in testcase: fxmark
> > > on test machine: 288 threads Intel(R) Xeon Phi(TM) CPU 7295 @ 1.50GHz
> > > with 80G memory
> >
> > I think this must be some really random memory layout issue that
> > causes some false sharing or similar.
> >
> > And it's not even that some fundamental data structure gets a
> > different layout, it literally is just either:
> >
> > (a) the (now smaller) array is allocated from a differently chunk,
> > and that then causes random cache effects with something else
> >
> > (b) the (old, and bigger) array was more spread out, and as a result
> > had different fields in different cachelines and less false sharing
> >
> > Normally I'd say that (b) is the obvious case, except for the fact
> > that this is a __percpu array.
> >
> > So in the common case there shouldn't be any cache contention _within_
> > the array itself. Any cache contention should be with something else
> > very hot that the change now randomly makes be in the same cache way
> > or whatever.
> >
> > Afaik, only the flushing of the vmstats batches does access the percpu
> > arrays from other CPUs, so (b) is not _entirely_ impossible if
> > memcg_flush_percpu_vmstats() were to be very very very hot.
> >
> > But the profile data doesn't show anything remotely like that.
> >
> > In fact, the actual report seems to show things improving, ie things
> > like elapsed time going down:
> >
> > > 1361-9.5% 1232fxmark.time.elapsed_time
> > > 1361-9.5% 1232fxmark.time.elapsed_time.max
> > > 25.67+9.1% 28.00
> > > fxmark.time.percent_of_cpu_this_job_got
> > > 343.68-2.0% 336.76fxmark.time.system_time
> > > 23.66+2.5 26.12mpstat.cpu.all.sys%
> >
> > but I don't know what the benchmark actually does, so maybe it just
> > repeats things until it hits a certain confidence interval, and thus
> > "elapsed time" is immaterial.
>
> I just checked the benchmark, seems it benchmarks the filesystem's
> scalability by doing file/inode opertions with different task numbers
> (from 1 to nr_cpus).
>
> The benchmark has preparation and cleanup steps before/after every
> run, and for the 100 less seconds of 'fxmark.time.elapsed_time' you
> found, it is due to the newer kernel spends 100 seconds more in the
> cleanup step after run ( a point worth checking)
Yes, the longer running time is because the cleanup ('umount' specifically)
of older kernel takes longer time, as it complets more FS operations.
And perf-profile info in the original report was not accurate, as the
test tried 72/63/54/45/36/27/18/9/1 tasks, and perf data recorded may
not reflect the "63 tasks" subcase.
> > Honestly, normally if I were to get a report about "52% regression"
> > for a commit that is supposed to optimize something, I'd just revert
> > the commit as a case of "ok, that optimization clearly didn't work".
> >
> > But there is absolutely no sign that this commit is actually the
> > culprit, or explanation for why that should be, and what could be
> > going on.
> >
> > So I'm going to treat this as a "bisection failure, possibly due to
> > random code or data layout changes". Particularly since this seems to
> > be a 4-socket Xeon Phi machine, which I think is likely a very very
> > fragile system if there is some odd cache layout issue.
>
> Oliver retested it and made it run 12 times in total, and the data
> is consistent. We tried some other test:
> * run other sub cases of this 'fxmark' which sees no regression
> * change 'btrfs' to 'ext4' of this case, and no regression
> * test on Cascadelake platform, no regression
>
> So the bitsection seems to be stable, though can't be explained yet.
>
> We checked the System map of the 2 kernels, and didn't find obvious
> code/data alignment change, which is expected, as the commit changes
> data structure which is usually dynamically allocated.
We found with the commit some percpu related ops do have some change,
as shown in perf
old kernel
--
1.06% 0.69% [kernel.kallsyms] [k] __percpu_counter_sum
- -
1.06%
__percpu_counter_sum;need_preemptive_reclaim.part.0;__reserve_bytes;btrfs_reserve_metadata_bytes;btrfs_delalloc_reserve_metadata;btrfs_buffered_write;btrfs_file_write_iter;new_sync_write;vfs_write;ksys_write;do_syscall_64;entry_SYSCALL_64_after_hwframe;write
89.85%88.17% [kernel.kallsyms]
Re: [PATCH v2] editorconfig: Add automatic editor configuration file
On Wed, Mar 24, 2021 at 8:01 PM Rasmus Villemoes
wrote:
>
> On 03/07/2020 14.29, Jonathan Corbet wrote:
>
> [doing a bit of necromancy here]
>
> > On Fri, 3 Jul 2020 00:31:43 -0700
> > Danny Lin wrote:
> >
> >> EditorConfig is a standard for defining basic editor configuration in
> >> projects. There is support available for 47 code editors as of writing,
> >> including both built-in and extension support. Many notable projects
> >> have adopted the standard already, including zsh, htop, and qemu.
> >>
> >> While this isn't a full-fledged C code style specifier, it does set some
> >> basic ground rules that make it more convenient for contributors to use
> >> any editor of their choice and not have to worry about indentation, line
> >> endings, encoding, final newlines, etc. This should make it
> >> significantly easier to conform to the kernel's general code style when
> >> used in combination with clang-format.
> >>
> >> For more information, check the official EditorConfig website:
> >> https://editorconfig.org/
> >>
> >> Signed-off-by: Danny Lin
> >> ---
> >
> > So I worry a bit that not everybody will welcome the addition of a dotfile
> > that may be magically interpreted by their editor.
>
> I would suppose that one would have to enable editorconfig support
> explicitly in one's editor, so this would have no effect for people that
> haven't done so (though there are almost certainly exceptions).
>
> > I also worry that the
> > file itself could become a battleground for people wanting to argue about
> > style issues.
>
> I don't think so, not any more than the coding-style document is, and
> that seems to be pretty solid (but as doc maintainer, you'd know better).
>
> >
> > Perhaps I worry a bit too much...?
>
> As someone who regularly needs to submit patches to random upstream
> projects to fix bugs or implement minor features, I for one would really
> welcome more widespread use of editorconfig. While I mostly work with
> the linux kernel (and other projects using the same C style), so my
> default C style setting is "linux", even for the kernel this would be
> helpful to me when I poke around in none-C files (shell scripts, for
> example).
>
> Rasmus
Just from my curiosity, I just checked the behavior
when the language is specified by a shebang line.
For example, scripts/diffconfig has no file suffix,
but specifies '#!/usr/bin/env python3'
at the very top line.
This is sensible for tools that interface to users.
Users have no interest in which language is used
internally.
As far as I test this patch on Emacs, it follows the rule
of [*] rather than [*.{pl,pm,py,tc,json,tc}].
This is the correct behavior but not what we want in general.
I do not mean I am negative to this patch.
Rather, I very much like this patch, but I just
wondered how this case could be handled.
I found this:
https://github.com/editorconfig/editorconfig/issues/404
I did not read through it, though.
--
Best Regards
Masahiro Yamada
Re: [PATCH v3 07/11] perf: Add breakpoint information to siginfo on SIGTRAP
On Wed, 24 Mar 2021 at 15:15, Dmitry Vyukov wrote: > On Wed, Mar 24, 2021 at 3:12 PM Dmitry Vyukov wrote: > > > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra wrote: > > > > > > > > One last try, I'll leave it alone now, I promise :-) > > > > > > This looks like it does what you suggested, thanks! :-) > > > > > > I'll still need to think about it, because of the potential problem > > > with modify-signal-races and what the user's synchronization story > > > would look like then. > > > > I agree that this looks inherently racy. The attr can't be allocated > > on stack, user synchronization may be tricky and expensive. The API > > may provoke bugs and some users may not even realize the race problem. > > > > One potential alternative is use of an opaque u64 context (if we could > > shove it into the attr). A user can pass a pointer to the attr in > > there (makes it equivalent to this proposal), or bit-pack size/type > > (as we want), pass some sequence number or whatever. > > Just to clarify what I was thinking about, but did not really state: > perf_event_attr_t includes u64 ctx, and we return it back to the user > in siginfo_t. Kernel does not treat it in any way. This is a pretty > common API pattern in general. Ok, let's go for a new field in perf_event_attr which is copied to si_perf. This gives user space full flexibility to decide what to stick in it, and the kernel does not prescribe some weird encoding or synchronization that user space would have to live with. I'll probably call it perf_event_attr::sig_data, because all si_* things are macros. Thanks, -- Marco
[PATCH] include: net: struct sock is declared twice
struct sock has been declared. Remove the duplicate. Signed-off-by: Wan Jiabing --- include/net/bpf_sk_storage.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/net/bpf_sk_storage.h b/include/net/bpf_sk_storage.h index 0e85713f56df..2926f1f00d65 100644 --- a/include/net/bpf_sk_storage.h +++ b/include/net/bpf_sk_storage.h @@ -27,7 +27,6 @@ struct bpf_local_storage_elem; struct bpf_sk_storage_diag; struct sk_buff; struct nlattr; -struct sock; #ifdef CONFIG_BPF_SYSCALL int bpf_sk_storage_clone(const struct sock *sk, struct sock *newsk); -- 2.25.1
Re: [PATCH] fs: Improve eventpoll logging to stop indicting timerfd
Manish, On Wed, Mar 24 2021 at 22:18, Manish Varma wrote: > On Mon, Mar 22, 2021 at 2:40 PM Thomas Gleixner wrote: >> >> Not that I expect any real dependencies on it, but as always the devil >> is in the details. > > Right, there are some userspace which depends on "[timerfd]" string > https://codesearch.debian.net/search?q=%22%5Btimerfd%5D%22&literal=1 Details :) > So, modifying file descriptor names at-least for timerfd will definitely > break those. > > With that said, I am now thinking about leaving alone the file descriptor > names as is, and instead, adding those extra information about the > associated processes (i.e. process name or rather PID of the > process) along with token ID directly into wakesource name, at the > time of creating new wakesource i.e. in ep_create_wakeup_source(). > > So, the wakesource names, that currently named as "[timerfd]", will be > named something like: > "epollitem:.[timerfd]" > > Where N is the number of wakesource created since boot. Where N is a unique ID token. :) > This way we can still associate the process with the wakesource > name and also distinguish multiple instances of wakesources using > the integer identifier. If that solves your problem and does not make anything else breaks which relies on the exisitng epollitem naming convention, then I don't see a problem with that. Thanks, tglx
Re: [PATCH] drm/imx: fix memory leak when fails to init
On Wed, Jan 20, 2021 at 01:16:08AM -0800, Pan Bian wrote:
> Put DRM device on initialization failure path rather than directly
> return error code.
>
> Fixes: a67d5088ceb8 ("drm/imx: drop explicit drm_mode_config_cleanup")
> Signed-off-by: Pan Bian
Thank you, applied to imx-drm/fixes.
regards
Philipp
Re: [PATCH] drm/imx: imx-ldb: Register LDB channel1 when it is the only channel to be used
On Mon, Mar 22, 2021 at 10:56:40AM +0800, Liu Ying wrote: > LDB channel1 should be registered if it is the only channel to be used. > Without this patch, imx_ldb_bind() would skip registering LDB channel1 > if LDB channel0 is not used, no matter LDB channel1 needs to be used or > not. > > Fixes: 8767f4711b2b (drm/imx: imx-ldb: move initialization into probe) > Signed-off-by: Liu Ying Thank you, applied to imx-drm/fixes. regards Philipp
[PATCH] fddi: skfp: Rudimentary spello fixes
s/autohorized/authorized/
s/recsource/resource/
s/measuered/measured/
sauthoriziation/authorization/
Signed-off-by: Bhaskar Chowdhury
---
drivers/net/fddi/skfp/h/smt.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fddi/skfp/h/smt.h b/drivers/net/fddi/skfp/h/smt.h
index a0dbc0f57a55..8d104f13e2c3 100644
--- a/drivers/net/fddi/skfp/h/smt.h
+++ b/drivers/net/fddi/skfp/h/smt.h
@@ -411,7 +411,7 @@ struct smt_p_reason {
#define SMT_RDF_ILLEGAL 0x0005 /* read only (PMF) */
#define SMT_RDF_NOPARAM0x6 /* parameter not supported
(PMF) */
#define SMT_RDF_RANGE 0x8 /* out of range */
-#define SMT_RDF_AUTHOR 0x9 /* not autohorized */
+#define SMT_RDF_AUTHOR 0x9 /* not authorized */
#define SMT_RDF_LENGTH 0x0a/* length error */
#define SMT_RDF_TOOLONG0x0b/* length error */
#define SMT_RDF_SBA0x0d/* SBA denied */
@@ -450,7 +450,7 @@ struct smt_p_version {
struct smt_p_0015 {
struct smt_para para ; /* generic parameter header */
- u_int res_type ; /* recsource type */
+ u_int res_type ; /* resource type */
} ;
#defineSYNC_BW 0x0001L /* Synchronous Bandwidth */
@@ -489,7 +489,7 @@ struct smt_p_0017 {
struct smt_p_0018 {
struct smt_para para ; /* generic parameter header */
int sba_ov_req ;/* total sync bandwidth req for
overhead*/
-} ;/* measuered in bytes per T_Neg */
+} ;/* measured in bytes per T_Neg */
/*
* P19 : SBA Allocation Address
@@ -562,7 +562,7 @@ struct smt_p_fsc {
#define FSC_TYPE2 2 /* Special A/C indicator forwarding */
/*
- * P00 21 : user defined authoriziation (see pmf.c)
+ * P00 21 : user defined authorization (see pmf.c)
*/
#define SMT_P_AUTHOR 0x0021
--
2.30.1
Re: [PATCH] ALSA: usb-audio: Fix missing return assignment
On Thu, Mar 25, 2021 at 01:24:23AM +0500, Muhammad Usama Anjum wrote: > On Wed, 2021-03-24 at 21:50 +0300, Dan Carpenter wrote: > > > - usb_driver_claim_interface(driver, iface, (void *)-1L); > > > + err = usb_driver_claim_interface(driver, iface, (void > > > *)-1L); > > > > This is in a loop so only the last return value is used. Which seems > > sort of weird and pointless that the last value would matter more than > > the others. > > > Correct. Lets not store the return value. To stop the static analyzers > to report the missing return assignment, can we add (void) in start of > this function call? I've not seen use of (void) this way in the > kernel. Is there any other way used in the kernel? Don't add (void). Don't add any code just to help static checkers, only do it if it helps humans. The (void) stuff is ugly. We have a __must_check annotation for functions where it's a bug not to check the return and the usb_driver_claim_interface() is not a __must_check function. Just ignore the static checker when it's wrong. When I'm reviewing static checker warnings, I only look at the new ones. Then after I've looked at them, I mark them as old. I currently have 65k old ignored warnings. regards, dan carpenter
Re: [PATCH] [v3] drm/imx: imx-ldb: fix out of bounds array access warning
On Thu, Mar 25, 2021 at 10:03:23AM +0800, Liu Ying wrote: > On Wed, 2021-03-24 at 17:47 +0100, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > When CONFIG_OF is disabled, building with 'make W=1' produces warnings > > about out of bounds array access: > > > > drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop': > > drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below > > array bounds of 'struct clk *[4]' [-Werror=array-bounds] > > > > Add an error check before the index is used, which helps with the > > warning, as well as any possible other error condition that may be > > triggered at runtime. > > > > The warning could be fixed by adding a Kconfig depedency on CONFIG_OF, > > but Liu Ying points out that the driver may hit the out-of-bounds > > problem at runtime anyway. > > > > Signed-off-by: Arnd Bergmann > Reviewed-by: Liu Ying Thank you, applied to imx-drm/fixes. regards Philipp
[PATCH v2 0/1] leds: lgm: Address review concerns
Address below review concerns from Pavel: 1. Remove LEDS_BLINK Kconfig symbol. 2. Provide useful Kconfig help text for the driver. This patch is based on "for-next" branch of kernel from below git tree: git git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git for-next v2: - Fix few code quality related review concerns (Randy Dunlap). - Further improve Kconfig help text (Pavel). - Switch back to original copyright (pavel). v1: - Initial version. Rahul Tanwar (1): leds: lgm: Improve Kconfig help drivers/leds/Kconfig | 5 ++--- drivers/leds/Makefile | 2 +- drivers/leds/blink/Kconfig| 28 +--- drivers/leds/blink/Makefile | 2 +- drivers/leds/blink/leds-lgm-sso.c | 4 ++-- 5 files changed, 19 insertions(+), 22 deletions(-) -- 2.17.1 This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic mail or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply e-mail so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety.
[PATCH v2 1/1] leds: lgm: Improve Kconfig help
Remove unnecessary Kconfig symbol LEDS_BLINK Improve Kconfig help text to make it more useful. Signed-off-by: Rahul Tanwar --- drivers/leds/Kconfig | 5 ++--- drivers/leds/Makefile | 2 +- drivers/leds/blink/Kconfig| 28 +--- drivers/leds/blink/Makefile | 2 +- drivers/leds/blink/leds-lgm-sso.c | 4 ++-- 5 files changed, 19 insertions(+), 22 deletions(-) diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index b6742b4231bf..4ca8cd594518 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -928,13 +928,12 @@ config LEDS_ACER_A500 This option enables support for the Power Button LED of Acer Iconia Tab A500. +source "drivers/leds/blink/Kconfig" + comment "Flash and Torch LED drivers" source "drivers/leds/flash/Kconfig" comment "LED Triggers" source "drivers/leds/trigger/Kconfig" -comment "LED Blink" -source "drivers/leds/blink/Kconfig" - endif # NEW_LEDS diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index 2a698df9da57..7e604d3028c8 100644 --- a/drivers/leds/Makefile +++ b/drivers/leds/Makefile @@ -110,4 +110,4 @@ obj-$(CONFIG_LEDS_CLASS_FLASH) += flash/ obj-$(CONFIG_LEDS_TRIGGERS)+= trigger/ # LED Blink -obj-$(CONFIG_LEDS_BLINK)+= blink/ +obj-y += blink/ diff --git a/drivers/leds/blink/Kconfig b/drivers/leds/blink/Kconfig index 6dedc58c47b3..8a11f9acd1a7 100644 --- a/drivers/leds/blink/Kconfig +++ b/drivers/leds/blink/Kconfig @@ -1,21 +1,19 @@ -menuconfig LEDS_BLINK - bool "LED Blink support" - depends on LEDS_CLASS - help - This option enables blink support for the leds class. - If unsure, say Y. - -if LEDS_BLINK - -config LEDS_BLINK_LGM - tristate "LED support for Intel LGM SoC series" +config LEDS_LGM + tristate "LED support for LGM SoC series" depends on GPIOLIB depends on LEDS_CLASS depends on MFD_SYSCON depends on OF help - Parallel to serial conversion, which is also called SSO controller, - can drive external shift register for LED outputs. - This enables LED support for Serial Shift Output controller(SSO). + This option enables support for LEDs connected to GPIO lines on + Lightning Mountain (LGM) SoC. Lightning Mountain is a AnyWAN + gateway-on-a-chip SoC to be shipped on mid and high end home + gateways and routers. + + These LEDs are driven by a Serial Shift Output (SSO) controller. + The driver supports hardware blinking and the LEDs can be configured + to be triggered by software/CPU or by hardware. -endif # LEDS_BLINK + Say 'Y' here if you are working on LGM SoC based platform. Otherwise, + say 'N'. To compile this driver as a module, choose M here: the module + will be called leds-lgm-sso. diff --git a/drivers/leds/blink/Makefile b/drivers/leds/blink/Makefile index 2fa6c7b7b67e..fa5d04dccf13 100644 --- a/drivers/leds/blink/Makefile +++ b/drivers/leds/blink/Makefile @@ -1,2 +1,2 @@ # SPDX-License-Identifier: GPL-2.0 -obj-$(CONFIG_LEDS_BLINK_LGM) += leds-lgm-sso.o +obj-$(CONFIG_LEDS_LGM) += leds-lgm-sso.o diff --git a/drivers/leds/blink/leds-lgm-sso.c b/drivers/leds/blink/leds-lgm-sso.c index 7d5c9ca007d6..e78792c90117 100644 --- a/drivers/leds/blink/leds-lgm-sso.c +++ b/drivers/leds/blink/leds-lgm-sso.c @@ -1,8 +1,8 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Intel Lightning Mountain SoC LED Serial Shift Output Controller driver + * Lightning Mountain SoC LED Serial Shift Output Controller driver * - * Copyright (c) 2020 Intel Corporation. + * Copyright (c) 2021 Intel Corporation. */ #include -- 2.17.1 This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic mail or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply e-mail so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety.
Re: [V2][PATCH] cpufreq: dt: check the -EPROBE_DEFER error returned by dev_pm_opp_of_cpumask_add_table
On 25-03-21, 14:42, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang
Made some changes and applied this:
Author: Quanyang Wang
Date: Thu Mar 25 14:42:08 2021 +0800
cpufreq: dt: dev_pm_opp_of_cpumask_add_table() may return -EPROBE_DEFER
The function dev_pm_opp_of_cpumask_add_table() may return -EPROBE_DEFER,
which needs to be propagated to the caller to try probing the driver
later on.
Signed-off-by: Quanyang Wang
[ Viresh: Massage changelog/subject, improve code. ]
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq-dt.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index b1e1bdc63b01..ece52863ba62 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -255,10 +255,15 @@ static int dt_cpufreq_early_init(struct device *dev, int
cpu)
* before updating priv->cpus. Otherwise, we will end up creating
* duplicate OPPs for the CPUs.
*
-* OPPs might be populated at runtime, don't check for error here.
+* OPPs might be populated at runtime, don't fail for error here unless
+* it is -EPROBE_DEFER.
*/
- if (!dev_pm_opp_of_cpumask_add_table(priv->cpus))
+ ret = dev_pm_opp_of_cpumask_add_table(priv->cpus);
+ if (!ret) {
priv->have_static_opps = true;
+ } else if (ret == -EPROBE_DEFER) {
+ goto out;
+ }
/*
* The OPP table must be initialized, statically or dynamically, by this
--
viresh
Re: [PATCH] drivers: nvmem: Fix voltage settings for QTI qfprom-efuse
On 2/5/2021 8:25 PM, Doug Anderson wrote:
Hi,
On Fri, Feb 5, 2021 at 3:29 AM Ravi Kumar Bokka wrote:
QFPROM controller hardware requires 1.8V min for fuse blowing.
So, this change sets the voltage to 1.8V, required to blow the fuse
for qfprom-efuse controller.
To disable fuse blowing, we set the voltage to 0V since this may
be a shared rail and may be able to run at a lower rate when we're
not blowing fuses.
Fixes: 93b4e49f8c86 ("nvmem: qfprom: Add fuse blowing support")
Reported-by: Douglas Anderson
Suggested-by: Douglas Anderson
Signed-off-by: Ravi Kumar Bokka
---
drivers/nvmem/qfprom.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
index 6cace24..100d69d 100644
--- a/drivers/nvmem/qfprom.c
+++ b/drivers/nvmem/qfprom.c
@@ -127,6 +127,16 @@ static void qfprom_disable_fuse_blowing(const struct
qfprom_priv *priv,
{
int ret;
+ /*
+* This may be a shared rail and may be able to run at a lower rate
+* when we're not blowing fuses. At the moment, the regulator framework
+* applies voltage constraints even on disabled rails, so remove our
+* constraints and allow the rail to be adjusted by other users.
Some year maybe I'll try to fix the regulator framework to not count
voltage constraints for disbled rails, or perhaps have it be optional.
;-) In theory it should be much easier after the patches we already
landed not to count current requests for disabled rails...
+*/
+ ret = regulator_set_voltage(priv->vcc, 0, INT_MAX);
+ if (ret)
+ dev_warn(priv->dev, "Failed to set 0 voltage (ignoring)\n");
+
ret = regulator_disable(priv->vcc);
if (ret)
dev_warn(priv->dev, "Failed to disable regulator
(ignoring)\n");
@@ -172,6 +182,17 @@ static int qfprom_enable_fuse_blowing(const struct
qfprom_priv *priv,
goto err_clk_prepared;
}
+ /*
+* Hardware requires 1.8V min for fuse blowing; this may be
+* a rail shared do don't specify a max--regulator constraints
+* will handle.
+*/
+ ret = regulator_set_voltage(priv->vcc, 180, INT_MAX);
+ if (ret) {
+ dev_err(priv->dev, "Failed to set 1.8 voltage\n");
+ goto err_clk_rate_set;
+ }
+
Looks right to me. Assuming that this works.
Reviewed-by: Douglas Anderson
Srini, any plans to queue this up for merge?
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v5 02/13] dt-bindings: phy: mediatek: dsi-phy: modify compatible dependence
On 16-03-21, 17:22, Chunfeng Yun wrote: > mt7623-mipi-tx is compatible to mt2701-mipi-tx, and use > "mediatek,mt2701-mipi-tx" instead on MT7623, so modify > the compatible items to make dependence clear. Applied, thanks -- ~Vinod
Re: [PATCH 2/2] ALSA: usb-audio: Check connector value on resume
On Wed, 24 Mar 2021 18:14:08 +0100,
Kai-Heng Feng wrote:
>
> Rear Mic on Lenovo P620 cannot record after S3, despite that there's no
> error and the other two functions of the USB audio, Line In and Line
> Out, work just fine.
>
> The mic starts to work again after running userspace app like "alsactl
> store". Following the lead, the evidence shows that as soon as connector
> status is queried, the mic can work again.
>
> So also check connector value on resume to "wake up" the USB audio to
> make it functional.
>
> This can be device specific, however I think this generic approach may
> benefit more than one device.
>
> Signed-off-by: Kai-Heng Feng
Just to be sure: this workaround is always needed no matter whether
reset_resume is set or not? If so, it's better to change the resume
callback to take reset_resume argument and call it always. The
resume_connector() can be folded into there.
thanks,
Takashi
> ---
> sound/usb/mixer.c | 18 ++
> sound/usb/mixer.h | 1 +
> 2 files changed, 19 insertions(+)
>
> diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
> index 98f5417a70e4..6a553d891b0f 100644
> --- a/sound/usb/mixer.c
> +++ b/sound/usb/mixer.c
> @@ -3631,11 +3631,28 @@ static int restore_mixer_value(struct
> usb_mixer_elem_list *list)
> return 0;
> }
>
> +static int resume_connector(struct usb_mixer_elem_list *list)
> +{
> + struct usb_mixer_elem_info *cval = mixer_elem_list_to_info(list);
> +
> + if (cval->val_type != USB_MIXER_BOOLEAN || cval->channels != 1)
> + return 0;
> +
> + return get_connector_value(cval, NULL, NULL);
> +}
> +
> int snd_usb_mixer_resume(struct usb_mixer_interface *mixer, bool
> reset_resume)
> {
> struct usb_mixer_elem_list *list;
> int id, err;
>
> + for (id = 0; id < MAX_ID_ELEMS; id++) {
> + for_each_mixer_elem(list, mixer, id) {
> + if (list->resume_connector)
> + list->resume_connector(list);
> + }
> + }
> +
> if (reset_resume) {
> /* restore cached mixer values */
> for (id = 0; id < MAX_ID_ELEMS; id++) {
> @@ -3664,5 +3681,6 @@ void snd_usb_mixer_elem_init_std(struct
> usb_mixer_elem_list *list,
> list->dump = snd_usb_mixer_dump_cval;
> #ifdef CONFIG_PM
> list->resume = restore_mixer_value;
> + list->resume_connector = resume_connector;
> #endif
> }
> diff --git a/sound/usb/mixer.h b/sound/usb/mixer.h
> index c29e27ac43a7..843ccff0eea3 100644
> --- a/sound/usb/mixer.h
> +++ b/sound/usb/mixer.h
> @@ -69,6 +69,7 @@ struct usb_mixer_elem_list {
> bool is_std_info;
> usb_mixer_elem_dump_func_t dump;
> usb_mixer_elem_resume_func_t resume;
> + usb_mixer_elem_resume_func_t resume_connector;
> };
>
> /* iterate over mixer element list of the given unit id */
> --
> 2.30.2
>
Re: [PATCH v5 03/13] dt-bindings: phy: mediatek: hdmi-phy: modify compatible items
On 16-03-21, 17:22, Chunfeng Yun wrote: > mt7623-hdmi-tx is compatible to mt2701-hdmi-tx, and the compatible > "mediatek,mt7623-hdmi-tx" is not supported in driver, in fact uses > "mediatek,mt2701-hdmi-tx" instead on MT7623, so changes the > compatible items to make dependence clear. Applied, thanks -- ~Vinod
Re: [PATCH v5 04/13] dt-bindings: phy: mediatek: tphy: change patternProperties
On 16-03-21, 17:22, Chunfeng Yun wrote: > The phy may be named as pcie-phy when the T-PHY only supports > PCIe mode, it's also the similar case for SATA, named as > sata-phy. Applied, thanks -- ~Vinod
Re: [PATCH] lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS
Hi Julian,
On Thu, Mar 25, 2021 at 1:09 AM Julian Braha wrote:
> On Wednesday, March 24, 2021 4:12:34 AM EDT you wrote:
> > On Wed, Mar 24, 2021 at 7:48 AM Julian Braha wrote:
> > > On Monday, March 22, 2021 3:43:41 AM EDT you wrote:
> > > > On Sun, Mar 21, 2021 at 11:40 PM Julian Braha
> > > > wrote:
> > > > > On Sunday, March 21, 2021 2:28:43 PM EDT you wrote:
> > > > > > On Sat, Mar 20, 2021 at 1:17 AM Julian Braha
> > > > > > wrote:
> > > > > > > When LATENCYTOP is enabled and ARCH_WANT_FRAME_POINTERS
> > > > > > > is disabled, Kbuild gives the following warning:
> > > > > > >
> > > > > > > WARNING: unmet direct dependencies detected for FRAME_POINTER
> > > > > > > Depends on [n]: DEBUG_KERNEL [=y] && (M68K || UML || SUPERH) ||
> > > > > > > ARCH_WANT_FRAME_POINTERS [=n] || MCOUNT [=n]
> > > > > > > Selected by [y]:
> > > > > > > - LATENCYTOP [=y] && DEBUG_KERNEL [=y] && STACKTRACE_SUPPORT
> > > > > > > [=y] && PROC_FS [=y] && !MIPS && !PPC && !S390 && !MICROBLAZE &&
> > > > > > > !ARM && !ARC && !X86
> > > > > > >
> > > > > > > This is because LATENCYTOP selects FRAME_POINTER,
> > > > > > > without selecting or depending on ARCH_WANT_FRAME_POINTERS,
> > > > > > > despite FRAME_POINTER depending on ARCH_WANT_FRAME_POINTERS.
> > > > > > >
> > > > > > > Signed-off-by: Julian Braha
> > > > > >
> > > > > > Thanks for your patch!
> > > > > >
> > > > > > > --- a/lib/Kconfig.debug
> > > > > > > +++ b/lib/Kconfig.debug
> > > > > > > @@ -1675,6 +1675,7 @@ config LATENCYTOP
> > > > > > > depends on DEBUG_KERNEL
> > > > > > > depends on STACKTRACE_SUPPORT
> > > > > > > depends on PROC_FS
> > > > > > > + select ARCH_WANT_FRAME_POINTERS if !MIPS && !PPC && !S390
> > > > > > > && !MICROBLAZE && !ARM && !ARC && !X86
> > > > > >
> > > > > > ARCH_WANT_FRAME_POINTERS is a symbol that is only to be selected by
> > > > > > architecture-specific configuration, and must not be overridden:
> > > > > >
> > > > > > # Select this config option from the architecture Kconfig, if it
> > > > > > # is preferred to always offer frame pointers as a config
> > > > > > # option on the architecture (regardless of KERNEL_DEBUG):
> > > > > >
> > > > > > Probably this should be turned into a depends instead?
> > > > > >
> > > > > > > select FRAME_POINTER if !MIPS && !PPC && !S390 &&
> > > > > > > !MICROBLAZE && !ARM && !ARC && !X86
> > > > > > > select KALLSYMS
> > > > > > > select KALLSYMS_ALL
> > > >
> > > > > Making this a 'depends' causes a recursive dependency error.
> > > > > Any other ideas?
> > > >
> > > > What about
> > > >
> > > > -select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE &&
> > > > !ARM && !ARC && !X86
> > > > +depends on FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE
> > > > && !ARM && !ARC && !X86
> > > >
> > > > ?
> > >
> > > Sadly, this won't work either. In Kconfig, 'depends' cannot have an 'if'
> > > after it (only 'select' can.)
> > > Kbuild gives an error for this.
> >
> > Oops
> >
> > select FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM
> > || ARC || X86
> >
> > of course.
> I think it's a typo, but if you meant:
> select FRAME_POINTER if MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
> Then that works.
(Bummer, I shouldn't reply to emails before my morning coffee)
Yes, it is a typo. I meant:
depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE ||
ARM || ARC || X86
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2] uacce: delete not be needed variable initialization
delete not be needed variable initialization.
Signed-off-by: Kai Ye
---
drivers/misc/uacce/uacce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/uacce/uacce.c b/drivers/misc/uacce/uacce.c
index d07af4e..94843e0 100644
--- a/drivers/misc/uacce/uacce.c
+++ b/drivers/misc/uacce/uacce.c
@@ -126,7 +126,7 @@ static int uacce_fops_open(struct inode *inode, struct file
*filep)
{
struct uacce_device *uacce;
struct uacce_queue *q;
- int ret = 0;
+ int ret;
uacce = xa_load(&uacce_xa, iminor(inode));
if (!uacce)
--
2.8.1
Re: [PATCH 2/3] dt-bindings: phy: qcom,usb-snps-femto-v2: Add bindings for SC7280
On 17-03-21, 16:31, Sandeep Maheswaram wrote: > Add the compatible string for sc7280 SoC from Qualcomm Applied, thanks -- ~Vinod
Re: [PATCH V2] ALSA: pcm: Fix couple of typos
On Thu, 25 Mar 2021 02:36:31 +0100, Bhaskar Chowdhury wrote: > > > s/unconditonally/unconditionally/ > s/succesful/successful/ > > Signed-off-by: Bhaskar Chowdhury The patch isn't cleanly applicable, some space was put at the beginning of the line incorrectly. Possibly a MUA problem? Could you resubmit with git-send-email instead? thanks, Takashi > --- > Changes from V1: > Randy's finding incorporated ,plus the subject line adjusted. > > sound/core/pcm_native.c | 82 - > 1 file changed, 41 insertions(+), 41 deletions(-) > > diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c > index 17a85f4815d5..afb670d7fd53 100644 > --- a/sound/core/pcm_native.c > +++ b/sound/core/pcm_native.c > @@ -1425,7 +1425,7 @@ static int snd_pcm_do_stop(struct snd_pcm_substream > *substream, > substream->ops->trigger(substream, SNDRV_PCM_TRIGGER_STOP); > substream->runtime->stop_operating = true; > } > - return 0; /* unconditonally stop all substreams */ > + return 0; /* unconditionally stop all substreams */ > } > > static void snd_pcm_post_stop(struct snd_pcm_substream *substream, > @@ -1469,7 +1469,7 @@ EXPORT_SYMBOL(snd_pcm_stop); > * After stopping, the state is changed to SETUP. > * Unlike snd_pcm_stop(), this affects only the given stream. > * > - * Return: Zero if succesful, or a negative error code. > + * Return: Zero if successful, or a negative error code. > -- > 2.30.1 >
Re: [PATCH] phy: intel: Fix a typo
On 21-03-21, 02:10, Bhaskar Chowdhury wrote: > > s/subsytem/subsystem/ Applied, thanks -- ~Vinod
Re: [syzbot] WARNING: ODEBUG bug in netdev_run_todo
syzbot has found a reproducer for the following issue on: HEAD commit:4ee998b0 Merge tag 'clk-fixes-for-linus' of git://git.kern.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=100e7bb2d0 kernel config: https://syzkaller.appspot.com/x/.config?x=5a2f679991921995 dashboard link: https://syzkaller.appspot.com/bug?extid=f9484b345f41843fc9a9 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1192d621d0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1071301cd0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+f9484b345f41843fc...@syzkaller.appspotmail.com bond0 (unregistering): (slave bond_slave_1): Releasing backup interface bond0 (unregistering): (slave bond_slave_0): Releasing backup interface bond0 (unregistering): Released all slaves [ cut here ] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x90 kernel/workqueue.c:1601 WARNING: CPU: 0 PID: 25 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Modules linked in: CPU: 0 PID: 25 Comm: kworker/u4:1 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 60 97 c1 89 4c 89 ee 48 c7 c7 60 8b c1 89 e8 68 c4 f8 04 <0f> 0b 83 05 45 f1 f9 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP: 0018:c9e17898 EFLAGS: 00010086 RAX: RBX: 0003 RCX: RDX: 8880118b22c0 RSI: 815b80e5 RDI: f520001c2f05 RBP: 0001 R08: R09: R10: 815b0e4e R11: R12: 896d69a0 R13: 89c191a0 R14: 81621150 R15: dc00 FS: () GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 562596db1338 CR3: 0bc8e000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __debug_check_no_obj_freed lib/debugobjects.c:987 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1018 kfree+0xd1/0x2b0 mm/slab.c:3795 kvfree+0x42/0x50 mm/util.c:616 device_release+0x9f/0x240 drivers/base/core.c:2108 kobject_cleanup lib/kobject.c:705 [inline] kobject_release lib/kobject.c:736 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:753 netdev_run_todo+0x96a/0xdd0 net/core/dev.c:10475 default_device_exit_batch+0x2ff/0x3c0 net/core/dev.c:11426 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:178 cleanup_net+0x4ea/0xb10 net/core/net_namespace.c:595 process_one_work+0x98d/0x1600 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Re: [PATCH V8 1/8] PM / devfreq: Add cpu based scaling support to passive_governor
Hi,
You are missing to add these patches to linux-pm mailing list.
Need to send them to linu-pm ML.
Also, before received this series, I tried to clean-up these patches
on testing branch[1]. So that I add my comment with my clean-up case.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-passive-gov
On 3/23/21 8:33 PM, Andrew-sh.Cheng wrote:
> From: Saravana Kannan
>
> Many CPU architectures have caches that can scale independent of the
> CPUs. Frequency scaling of the caches is necessary to make sure that the
> cache is not a performance bottleneck that leads to poor performance and
> power. The same idea applies for RAM/DDR.
>
> To achieve this, this patch adds support for cpu based scaling to the
> passive governor. This is accomplished by taking the current frequency
> of each CPU frequency domain and then adjust the frequency of the cache
> (or any devfreq device) based on the frequency of the CPUs. It listens
> to CPU frequency transition notifiers to keep itself up to date on the
> current CPU frequency.
>
> To decide the frequency of the device, the governor does one of the
> following:
> * Derives the optimal devfreq device opp from required-opps property of
> the parent cpu opp_table.
>
> * Scales the device frequency in proportion to the CPU frequency. So, if
> the CPUs are running at their max frequency, the device runs at its
> max frequency. If the CPUs are running at their min frequency, the
> device runs at its min frequency. It is interpolated for frequencies
> in between.
>
> Andrew-sh.Cheng change
> dev_pm_opp_xlate_opp to dev_pm_opp_xlate_required_opp devfreq->max_freq
> to devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value
> after kernel-5.7
> Don't return -EINVAL in devfreq_passive_event_handler()
> since it doesn't handle DEVFREQ_GOV_SUSPEND DEVFREQ_GOV_RESUME cases.
>
> Signed-off-by: Saravana Kannan
> [Sibi: Integrated cpu-freqmap governor into passive_governor]
> Signed-off-by: Sibi Sankar
> Signed-off-by: Andrew-sh.Cheng
> ---
> drivers/devfreq/Kconfig| 2 +
> drivers/devfreq/governor_passive.c | 329
> +++--
> include/linux/devfreq.h| 29 +++-
> 3 files changed, 342 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 00704efe6398..f56132b0ae64 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -73,6 +73,8 @@ config DEVFREQ_GOV_PASSIVE
> device. This governor does not change the frequency by itself
> through sysfs entries. The passive governor recommends that
> devfreq device uses the OPP table to get the frequency/voltage.
> + Alternatively the governor can also be chosen to scale based on
> + the online CPUs current frequency.
>
> comment "DEVFREQ Drivers"
>
> diff --git a/drivers/devfreq/governor_passive.c
> b/drivers/devfreq/governor_passive.c
> index b094132bd20b..9cc57b083839 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -8,11 +8,103 @@
> */
>
> #include
> +#include
> +#include
> +#include
> #include
> #include
> +#include
> #include "governor.h"
>
> -static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
> +struct devfreq_cpu_state {
> + unsigned int curr_freq;
> + unsigned int min_freq;
> + unsigned int max_freq;
> + unsigned int first_cpu;
> + struct device *cpu_dev;
> + struct opp_table *opp_table;
> +};
As I knew, the previous version has the description of structure
as following: I wan to add the description like below.
And if you have no any objection, I'd like you to order
the variables as following and use 'dev' instead of 'cpu_dev'
because this patch use the 'cpu_state->cpu_dev' at the multiple points.
I think that 'cpu_state->dev' is better than 'cpu_state->cpu_dev'.
Also, I prefer to use 'cur_freq' instead of 'curr_freq'
because devfreq subsystem uses 'cur_freq' for expressing the 'current
frequency'.
/**
* struct devfreq_cpu_state - Hold the per-cpu data
* @dev:reference to cpu device.
* @first_cpu: the cpumask of the first cpu of a policy.
* @opp_table: reference to cpu opp table.
* @cur_freq: the current frequency of the cpu.
* @min_freq: the min frequency of the cpu.
* @max_freq: the max frequency of the cpu.
*
* This structure stores the required cpu_data of a cpu.
* This is auto-populated by the governor.
*/
Re: [PATCH] phy:qualcomm: remove duplicate argument
On 19-03-21, 04:36, menglong8.d...@gmail.com wrote: > From: Zhang Yunkai > > 'HSUSB_CTRL_DPSEHV_CLAMP' in 'val' is duplicated. Applied, thanks -- ~Vinod
[PATCH v2] ACPI / hotplug / PCI: fix memory leak in enable_slot()
From: Feilong Lin In enable_slot() in drivers/pci/hotplug/acpiphp_glue.c, if pci_get_slot() will return NULL, we will do not set SLOT_ENABLED flag of slot. if one device is found by calling pci_get_slot(), its reference count will be increased. In this case, we did not call pci_dev_put() to decrement the its reference count, the memory of the device (struct pci_dev type) will leak. Fix it by calling pci_dev_put() to decrement its reference count after that pci_get_slot() returns a PCI device. Signed-off-by: Feilong Lin Signed-off-by: Zhiqiang Liu -- v2: rewrite subject and commit log as suggested by Bjorn Helgaas. --- drivers/pci/hotplug/acpiphp_glue.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c index 3365c93abf0e..f031302ad401 100644 --- a/drivers/pci/hotplug/acpiphp_glue.c +++ b/drivers/pci/hotplug/acpiphp_glue.c @@ -533,6 +533,7 @@ static void enable_slot(struct acpiphp_slot *slot, bool bridge) slot->flags &= ~SLOT_ENABLED; continue; } + pci_dev_put(dev); } } -- 2.19.1
Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the first use of dynamic user state
For AMX, we must still reserve the space, but we are not going to write zeros for clean state. We so this in software by checking XINUSE=0, and clearing the xstate_bf for the XSAVE. As a result, for XINUSE=0, we can skip writing the zeros, even though we can't compress the space. So my understanding is that clearing xstate_bv will not help prevent saving zeros, but only not masking EDX:EAX, since the following logic. Not sure if this is just what you mean. :) FWIW, PATCH21 [1] uses the instruction mask to skip writing zeros on sigframe. Then, XSAVE will clear the xstate_bv for the xtile data state bit. [1] https://lore.kernel.org/lkml/20210221185637.19281-22-chang.seok@intel.com/ Yes, no mask in EDX:EAX works in such case. Thanks for pointing out the patch. BRs, Jing Thanks, Chang
[PATCH v3] PCI: dwc: move dw_pcie_msi_init() to dw_pcie_setup_rc()
If the host which makes use of IP's integrated MSI Receiver losts
power during suspend, we need to reinit the RC and MSI Receiver in
resume. But after we move dw_pcie_msi_init() into the core, we have no
API to do so. Usually the dwc users need to call dw_pcie_setup_rc() to
reinit the RC, we can solve this problem by moving dw_pcie_msi_init()
to dw_pcie_setup_rc().
Reviewed-by: Rob Herring
Signed-off-by: Jisheng Zhang
---
Since v2:
- rewrite the commit msg
Since v1:
- collect Reviewed-by tag
drivers/pci/controller/dwc/pcie-designware-host.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
b/drivers/pci/controller/dwc/pcie-designware-host.c
index 7e55b2b66182..e6c274f4485c 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -400,7 +400,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
}
dw_pcie_setup_rc(pp);
- dw_pcie_msi_init(pp);
if (!dw_pcie_link_up(pci) && pci->ops && pci->ops->start_link) {
ret = pci->ops->start_link(pci);
@@ -551,6 +550,8 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
}
}
+ dw_pcie_msi_init(pp);
+
/* Setup RC BARs */
dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 0x0004);
dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_1, 0x);
--
2.30.1
Re: [PATCH 2/2] ALSA: usb-audio: Check connector value on resume
On Thu, Mar 25, 2021 at 3:19 PM Takashi Iwai wrote:
>
> On Wed, 24 Mar 2021 18:14:08 +0100,
> Kai-Heng Feng wrote:
> >
> > Rear Mic on Lenovo P620 cannot record after S3, despite that there's no
> > error and the other two functions of the USB audio, Line In and Line
> > Out, work just fine.
> >
> > The mic starts to work again after running userspace app like "alsactl
> > store". Following the lead, the evidence shows that as soon as connector
> > status is queried, the mic can work again.
> >
> > So also check connector value on resume to "wake up" the USB audio to
> > make it functional.
> >
> > This can be device specific, however I think this generic approach may
> > benefit more than one device.
> >
> > Signed-off-by: Kai-Heng Feng
>
> Just to be sure: this workaround is always needed no matter whether
> reset_resume is set or not?
Yes, reset_resume is irrelevant for this issue. Getting connector
status is the key.
> If so, it's better to change the resume
> callback to take reset_resume argument and call it always. The
> resume_connector() can be folded into there.
OK, will send V2.
Kai-Heng
>
>
> thanks,
>
> Takashi
>
> > ---
> > sound/usb/mixer.c | 18 ++
> > sound/usb/mixer.h | 1 +
> > 2 files changed, 19 insertions(+)
> >
> > diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
> > index 98f5417a70e4..6a553d891b0f 100644
> > --- a/sound/usb/mixer.c
> > +++ b/sound/usb/mixer.c
> > @@ -3631,11 +3631,28 @@ static int restore_mixer_value(struct
> > usb_mixer_elem_list *list)
> > return 0;
> > }
> >
> > +static int resume_connector(struct usb_mixer_elem_list *list)
> > +{
> > + struct usb_mixer_elem_info *cval = mixer_elem_list_to_info(list);
> > +
> > + if (cval->val_type != USB_MIXER_BOOLEAN || cval->channels != 1)
> > + return 0;
> > +
> > + return get_connector_value(cval, NULL, NULL);
> > +}
> > +
> > int snd_usb_mixer_resume(struct usb_mixer_interface *mixer, bool
> > reset_resume)
> > {
> > struct usb_mixer_elem_list *list;
> > int id, err;
> >
> > + for (id = 0; id < MAX_ID_ELEMS; id++) {
> > + for_each_mixer_elem(list, mixer, id) {
> > + if (list->resume_connector)
> > + list->resume_connector(list);
> > + }
> > + }
> > +
> > if (reset_resume) {
> > /* restore cached mixer values */
> > for (id = 0; id < MAX_ID_ELEMS; id++) {
> > @@ -3664,5 +3681,6 @@ void snd_usb_mixer_elem_init_std(struct
> > usb_mixer_elem_list *list,
> > list->dump = snd_usb_mixer_dump_cval;
> > #ifdef CONFIG_PM
> > list->resume = restore_mixer_value;
> > + list->resume_connector = resume_connector;
> > #endif
> > }
> > diff --git a/sound/usb/mixer.h b/sound/usb/mixer.h
> > index c29e27ac43a7..843ccff0eea3 100644
> > --- a/sound/usb/mixer.h
> > +++ b/sound/usb/mixer.h
> > @@ -69,6 +69,7 @@ struct usb_mixer_elem_list {
> > bool is_std_info;
> > usb_mixer_elem_dump_func_t dump;
> > usb_mixer_elem_resume_func_t resume;
> > + usb_mixer_elem_resume_func_t resume_connector;
> > };
> >
> > /* iterate over mixer element list of the given unit id */
> > --
> > 2.30.2
> >
Re: [PATCH v2] uacce: delete not be needed variable initialization
On Thu, Mar 25, 2021 at 03:18:49PM +0800, Kai Ye wrote: > delete not be needed variable initialization. I am sorry, but I can not parse this sentence. Can you try resending this with a better description? > Signed-off-by: Kai Ye > --- > drivers/misc/uacce/uacce.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) If this is a v2, you have to list below the --- line what changed from previous versions, right? Please do so when you send a v3. thanks, greg k-h
Re: [PATCH v4 2/5] phy: Add LVDS configuration options
On 18-03-21, 10:22, Liu Ying wrote: > > Can we have these in kernel-doc style please, similar to style in > > linux/phy/phy.h > > I take this way of in-line member documentation comment for the below 3 > reasons: > > 1) Members of struct phy_configure_opts_mipi_dphy and > struct phy_configure_opts_dp use the same way of comment. > The structures are defined in linux/phy/phy-mipi-dphy.h and > linux/phy/phy-dp.h respectively. > Aligning to them makes a bit sense, IMHO. > > 2) In-line member documentation comments[1] are mentioned in kernel-doc > guide. It says 'The structure members may also be documented in-line > within the definition.'. > > 3) Even the 'configure' and 'validate' members of struct phy_ops use > the same way of comment. struct phy_ops is defined in linux/phy/phy.h. > > [1] > https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#in-line-member-documentation-comments It 'may be' but I would like all headers of a subsystem to display one style. As I said linux/phy/phy.h use a style which we should use everywhere. Thanks -- ~Vinod
Re: [PATCH] drivers: staging: _adapter is declared twice
On Thu, Mar 25, 2021 at 02:28:40PM +0800, Wan Jiabing wrote:
> struct _adapter has been declared at 23rd line.
> Remove the duplicate.
>
> Signed-off-by: Wan Jiabing
> ---
> drivers/staging/rtl8712/drv_types.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8712/drv_types.h
> b/drivers/staging/rtl8712/drv_types.h
> index 0c4325073c63..976d19cdcf87 100644
> --- a/drivers/staging/rtl8712/drv_types.h
> +++ b/drivers/staging/rtl8712/drv_types.h
> @@ -36,7 +36,6 @@ enum _NIC_VERSION {
> RTL8716_NIC
> };
>
> -struct _adapter;
>
> struct qos_priv{
You need to delete the blank line after it as well to avoid the
checkpatch warning about two blank lines in a row.
regards,
dan carpenter
Re: [PATCHv2 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific impl earlier
Hi Will,
On 2021-03-15 00:31, Sai Prakash Ranjan wrote:
On 2021-03-12 04:59, Bjorn Andersson wrote:
On Sat 27 Feb 07:53 CST 2021, Sai Prakash Ranjan wrote:
Hi Bjorn,
On 2021-02-27 00:44, Bjorn Andersson wrote:
> On Fri 26 Feb 12:23 CST 2021, Rob Clark wrote:
>
>
> The current logic picks one of:
> 1) is the compatible mentioned in qcom_smmu_impl_of_match[]
> 2) is the compatible an adreno
> 3) no quirks needed
>
> The change flips the order of these, so the only way I can see this
> change affecting things is if we expected a match on #2, but we got one
> on #1.
>
> Which implies that the instance that we want to act according to the
> adreno impl was listed in qcom_smmu_impl_of_match[] - which either is
> wrong, or there's a single instance that needs both behaviors.
>
> (And I believe Jordan's answer confirms the latter - there's a single
> SMMU instance that needs all them quirks at once)
>
Let me go through the problem statement in case my commit message
wasn't
clear. There are two SMMUs (APSS and GPU) on SC7280 and both are
SMMU500
(ARM SMMU IP).
APSS SMMU compatible - ("qcom,sc7280-smmu-500", "arm,mmu-500")
GPU SMMU compatible - ("qcom,sc7280-smmu-500", "qcom,adreno-smmu",
"arm,mmu-500")
Now if we take SC7180 as an example, GPU SMMU was QSMMU(QCOM SMMU IP)
and APSS SMMU was SMMU500(ARM SMMU IP).
APSS SMMU compatible - ("qcom,sc7180-smmu-500", "arm,mmu-500")
GPU SMMU compatible - ("qcom,sc7180-smmu-v2", "qcom,adreno-smmu",
"qcom,smmu-v2")
Current code sequence without this patch,
if (of_match_node(qcom_smmu_impl_of_match, np))
return qcom_smmu_create(smmu, &qcom_smmu_impl);
if (of_device_is_compatible(np, "qcom,adreno-smmu"))
return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);
Now if we look at the compatible for SC7180, there is no problem
because
the APSS SMMU will match the one in qcom_smmu_impl_of_match[] and GPU
SMMU
will match "qcom,adreno-smmu" because the compatible strings are
different.
But for SC7280, both the APSS SMMU and GPU SMMU
compatible("qcom,sc7280-smmu-500")
are same. So GPU SMMU will match with the one in
qcom_smmu_impl_of_match[]
i.e.., "qcom,sc7280-smmu-500" which functionally doesn't cause any
problem
but we will miss settings for split pagetables which are part of GPU
SMMU
specific implementation.
We can avoid this with yet another new compatible for GPU SMMU
something like
"qcom,sc7280-adreno-smmu-500" but since we can handle this easily in
the
driver and since the IPs are same, meaning if there was a hardware
quirk
required, then we would need to apply to both of them and would this
additional
compatible be of any help?
No, I think you're doing the right thing of having them both. I just
didn't remember us doing that.
Coming to the part of quirks now, you are right saying both SMMUs
will need
to have the same quirks in SC7280 and similar others where both are
based on
same IPs but those should probably be *hardware quirks* and if they
are
software based like the S2CR quirk depending on the firmware, then it
might
not be applicable to both. In case if it is applicable, then as
Jordan mentioned,
we can add the same quirks in GPU SMMU implementation.
I do suspect that at some point (probably sooner than later) we'd have
to support both inheriting of stream from the bootloader and the
Adreno
"quirks" in the same instance.
But for now this is okay to me.
Sure, let me know if you or anyone face any issues without it and I
will
add it. I will resend this series with the dt-bindings patch for sc7280
smmu
which wasn't cc'd to smmu folks by mistake.
I think there is consensus on this series. I can resend if required but
it
still applies cleanly, let me know if you have any comments?
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] usb: typec: Fix a typo
On Thu, Mar 25, 2021 at 10:40:23AM +0530, Bhaskar Chowdhury wrote: > > s/Acknowlege/Acknowledge/ > > Signed-off-by: Bhaskar Chowdhury Reviewed-by: Heikki Krogerus > --- > drivers/usb/typec/ucsi/ucsi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c > index 244270755ae6..282c3c825c13 100644 > --- a/drivers/usb/typec/ucsi/ucsi.c > +++ b/drivers/usb/typec/ucsi/ucsi.c > @@ -63,7 +63,7 @@ static int ucsi_read_error(struct ucsi *ucsi) > u16 error; > int ret; > > - /* Acknowlege the command that failed */ > + /* Acknowledge the command that failed */ > ret = ucsi_acknowledge_command(ucsi); > if (ret) > return ret; > -- > 2.30.1 -- heikki
Re: [PATCH] drivers: gpu: drm: xen_drm_front_drm_info is declared twice
Hi, On 3/25/21 8:19 AM, Wan Jiabing wrote: > struct xen_drm_front_drm_info has been declared. > Remove the duplicate. > > Signed-off-by: Wan Jiabing Thank you for the patch, Reviewed-by: Oleksandr Andrushchenko Will apply to drm-misc-next-fixes Thank you, Oleksandr > --- > drivers/gpu/drm/xen/xen_drm_front_conn.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.h > b/drivers/gpu/drm/xen/xen_drm_front_conn.h > index 3adacba9a23b..e5f4314899ee 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front_conn.h > +++ b/drivers/gpu/drm/xen/xen_drm_front_conn.h > @@ -16,7 +16,6 @@ > struct drm_connector; > struct xen_drm_front_drm_info; > > -struct xen_drm_front_drm_info; > > int xen_drm_front_conn_init(struct xen_drm_front_drm_info *drm_info, > struct drm_connector *connector);
Re: [PATCH 1/2] media: v4l2-core: ignore native time32 ioctls on 64-bit
On 21/03/2021 09:50, Hans Verkuil wrote:
> Hi Arnd,
>> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
>> b/drivers/media/v4l2-core/v4l2-subdev.c
>> index 336133dbc759..9f5573d3b857 100644
>> --- a/drivers/media/v4l2-core/v4l2-subdev.c
>> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
>> @@ -428,7 +428,7 @@ static long subdev_do_ioctl(struct file *file, unsigned
>> int cmd, void *arg)
>>
>> return v4l2_event_dequeue(vfh, arg, file->f_flags & O_NONBLOCK);
>>
>> -#ifdef CONFIG_COMPAT_32BIT_TIME
>> +#if !defined(CONFIG_64BIT) && defined(CONFIG_COMPAT_32BIT_TIME)
>> case VIDIOC_DQEVENT_TIME32: {
>> struct v4l2_event_time32 *ev32 = arg;
>> struct v4l2_event ev = { };
>>
>
> This chunk doesn't apply since there is no '#ifdef CONFIG_COMPAT_32BIT_TIME'
> in
> either the mainline kernel or the media_tree master branch.
>
> Are we missing a patch for v4l2-subdev.c?
Ping!
Hans
>
> Regards,
>
> Hans
>
[PATCH] [v2] drivers: staging: _adapter is declared twice
struct _adapter has been declared at 23rd line.
Remove the duplicate.
Signed-off-by: Wan Jiabing
---
drivers/staging/rtl8712/drv_types.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index 0c4325073c63..a44d04effc8b 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -36,8 +36,6 @@ enum _NIC_VERSION {
RTL8716_NIC
};
-struct _adapter;
-
struct qos_priv{
/* bit mask option: u-apsd, s-apsd, ts, block ack... */
unsigned int qos_option;
--
2.25.1
Re: [PATCH v3 05/10] dt-bindings: pinctrl: Add bindings for new Ingenic SoCs.
On 2021/3/23 上午2:01, Paul Cercueil wrote: Le mer. 17 mars 2021 à 17:57, 周琰杰 (Zhou Yanjie) a écrit : Add the pinctrl bindings for the JZ4730 SoC, the JZ4750 SoC, the JZ4755 SoC, the JZ4775 SoC and the X2000 SoC from Ingenic. Signed-off-by: 周琰杰 (Zhou Yanjie) --- Notes: v2: New patch. v2->v3: No change. .../bindings/pinctrl/ingenic,pinctrl.yaml | 23 ++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml index 44c04d1..60604fc 100644 --- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml @@ -17,10 +17,12 @@ description: > naming scheme "PxN" where x is a character identifying the GPIO port with which the pin is associated and N is an integer from 0 to 31 identifying the pin within that GPIO port. For example PA0 is the first pin in GPIO port A, - and PB31 is the last pin in GPIO port B. The JZ4740, the X1000 and the X1830 - contains 4 GPIO ports, PA to PD, for a total of 128 pins. The JZ4760, the - JZ4770 and the JZ4780 contains 6 GPIO ports, PA to PF, for a total of 192 - pins. + and PB31 is the last pin in GPIO port B. The JZ4730, the JZ4740, the X1000 + and the X1830 contains 4 GPIO ports, PA to PD, for a total of 128 pins. The + X2000 contains 5 GPIO ports, PA to PE, for a total of 160 pins. The JZ4750, + the JZ4755 the JZ4760, the JZ4770 and the JZ4780 contains 6 GPIO ports, PA + to PF, for a total of 192 pins. The JZ4775 contains 7 GPIO ports, PA to PG, + for a total of 224 pins. While we're at it, the JZ4725B has also 4 GPIO ports. OK, I will add it. maintainers: - Paul Cercueil @@ -32,20 +34,28 @@ properties: compatible: oneOf: - enum: + - ingenic,jz4730-pinctrl - ingenic,jz4740-pinctrl - ingenic,jz4725b-pinctrl + - ingenic,jz4750-pinctrl + - ingenic,jz4755-pinctrl - ingenic,jz4760-pinctrl - ingenic,jz4770-pinctrl + - ingenic,jz4775-pinctrl - ingenic,jz4780-pinctrl - ingenic,x1000-pinctrl - ingenic,x1500-pinctrl - ingenic,x1830-pinctrl + - ingenic,x2000-pinctrl - items: - const: ingenic,jz4760b-pinctrl - const: ingenic,jz4760-pinctrl - items: - const: ingenic,x1000e-pinctrl - const: ingenic,x1000-pinctrl + - items: + - const: ingenic,x2000e-pinctrl + - const: ingenic,x2000-pinctrl reg: maxItems: 1 @@ -62,14 +72,19 @@ patternProperties: properties: compatible: enum: + - ingenic,jz4730-gpio - ingenic,jz4740-gpio - ingenic,jz4725b-gpio + - ingenic,jz4750-gpio + - ingenic,jz4755-gpio - ingenic,jz4760-gpio - ingenic,jz4770-gpio + - ingenic,jz4775-gpio - ingenic,jz4780-gpio - ingenic,x1000-gpio - ingenic,x1500-gpio - ingenic,x1830-gpio + - ingenic,x2000-gpio reg: items: -- 2.7.4
Re: [PATCH] static_call: fix function type mismatch
On Thu, Mar 25, 2021 at 01:42:41AM +0100, Rasmus Villemoes wrote:
> > Actually, it looks like I can't select PREEMPT_DYNAMIC> and tweaking Kconfig
>
> Ah, there's no prompt on the "bool" line, so it doesn't show up. That
> seems to be a mistake, since there's an elaborate help text which says
>
> The runtime overhead is negligible with
> HAVE_STATIC_CALL_INLINE enabled
> but if runtime patching is not available for the specific
> architecture
> then the potential overhead should be considered.
>
> So it seems that it was meant to be "you can enable this if you really
> want".
>
> to force enable it on arm64 results in a build error
Right, PREEMPT_DYNAMIC really hard relies on HAVE_STATIC_CALL
There's an implicit dependency in the select:
config PREEMPT
...
select PREEMPT_DYNAMIC if HAVE_PREEMPT_DYNAMIC
> > ("implicit declaration of function 'static_call_mod'").
>
> Seems to be an omission in the last !HAVE_STATIC_CALL branch in
> static_call_types.h, and there's also no
> EXPORT_STATIC_CALL_TRAMP{,_GPL} in static_call.h for that case.
That interface doesn't make sense for !HAVE_STATIC_CALL. It's impossible
to not export the function pointer itself but still call it for
!HAVE_STATIC_CALL.
Re: [PATCH V8 4/8] devfreq: add mediatek cci devfreq
Hi,
On 3/23/21 8:33 PM, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng"
>
> This adds a devfreq driver for the Cache Coherent Interconnect (CCI)
> of the Mediatek MT8183.
>
> On the MT8183 the CCI is supplied by the same regulator as the LITTLE
> cores. The driver is notified when the regulator voltage changes
> (driven by cpufreq) and adjusts the CCI frequency to the maximum
> possible value.
>
> Signed-off-by: Andrew-sh.Cheng
> ---
> drivers/devfreq/Kconfig | 10 ++
> drivers/devfreq/Makefile | 1 +
> drivers/devfreq/mt8183-cci-devfreq.c | 198
> +++
> 3 files changed, 209 insertions(+)
> create mode 100644 drivers/devfreq/mt8183-cci-devfreq.c
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index f56132b0ae64..2538255ac2c1 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -111,6 +111,16 @@ config ARM_IMX8M_DDRC_DEVFREQ
> This adds the DEVFREQ driver for the i.MX8M DDR Controller. It allows
> adjusting DRAM frequency.
>
> +config ARM_MT8183_CCI_DEVFREQ
> + tristate "MT8183 CCI DEVFREQ Driver"
> + depends on ARM_MEDIATEK_CPUFREQ
> + help
> + This adds a devfreq driver for Cache Coherent Interconnect
> + of Mediatek MT8183, which is shared the same regulator
> + with cpu cluster.
> + It can track buck voltage and update a proper CCI frequency.
> + Use notification to get regulator status.
> +
> config ARM_TEGRA_DEVFREQ
> tristate "NVIDIA Tegra30/114/124/210 DEVFREQ Driver"
> depends on ARCH_TEGRA_3x_SOC || ARCH_TEGRA_114_SOC || \
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index a16333ea7034..991ef7740759 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
> obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
> obj-$(CONFIG_ARM_IMX_BUS_DEVFREQ)+= imx-bus.o
> obj-$(CONFIG_ARM_IMX8M_DDRC_DEVFREQ) += imx8m-ddrc.o
> +obj-$(CONFIG_ARM_MT8183_CCI_DEVFREQ) += mt8183-cci-devfreq.o
> obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
> obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra30-devfreq.o
>
> diff --git a/drivers/devfreq/mt8183-cci-devfreq.c
> b/drivers/devfreq/mt8183-cci-devfreq.c
> new file mode 100644
> index ..018543db7bae
> --- /dev/null
> +++ b/drivers/devfreq/mt8183-cci-devfreq.c
> @@ -0,0 +1,198 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2021 MediaTek Inc.
> +
> + * Author: Andrew-sh.Cheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX_VOLT_LIMIT (115)
> +
> +struct cci_devfreq {
> + struct devfreq *devfreq;
> + struct regulator *cpu_reg;
> + struct clk *cci_clk;
> + int old_vproc;
nitpick. how about using 'old_voltage'?
because 'vproc' is not easy for understanding.
> + unsigned long old_freq;
> +};
> +
> +static int mtk_cci_set_voltage(struct cci_devfreq *cci_df, int vproc)
nitpick: how about changing 'vproc -> voltage'?
> +{
> + int ret;
> +
> + ret = regulator_set_voltage(cci_df->cpu_reg, vproc,
> + MAX_VOLT_LIMIT);
> + if (!ret)
> + cci_df->old_vproc = vproc;
> + return ret;
> +}
> +
> +static int mtk_cci_devfreq_target(struct device *dev, unsigned long *freq,
> + u32 flags)
> +{
> + int ret;
> + struct cci_devfreq *cci_df = dev_get_drvdata(dev);
> + struct dev_pm_opp *opp;
> + unsigned long opp_rate, opp_voltage, old_voltage;
> +
> + if (!cci_df)
> + return -EINVAL;
> +
> + if (cci_df->old_freq == *freq)
> + return 0;
> +
> + opp_rate = *freq;
> + opp = devfreq_recommended_opp(dev, &opp_rate, 1);
> + opp_voltage = dev_pm_opp_get_voltage(opp);
> + dev_pm_opp_put(opp);
> +
> + old_voltage = cci_df->old_vproc;
> + if (old_voltage == 0)
> + old_voltage = regulator_get_voltage(cci_df->cpu_reg);
> +
> + // scale up: set voltage first then freq
> + if (opp_voltage > old_voltage) {
> + ret = mtk_cci_set_voltage(cci_df, opp_voltage);
> + if (ret) {
> + pr_err("cci: failed to scale up voltage\n");
> + return ret;
> + }
> + }
> +
> + ret = clk_set_rate(cci_df->cci_clk, *freq);
> + if (ret) {
> + pr_err("%s: failed cci to set rate: %d\n", __func__,
> +ret);
> + mtk_cci_set_voltage(cci_df, old_voltage);
> + return ret;
> + }
> +
> + // scale down: set freq first then voltage
> + if (opp_voltage < old_voltage) {
> + ret = mtk_cci_set_voltage(cci_df, opp_voltage);
> + if (ret) {
> + pr_err("cci: failed to scale down voltage\n"
Re: [PATCH 1/2] sched: stop using magic values in sched_dynamic_mode
On Thu, Mar 25, 2021 at 01:45:14AM +0100, Rasmus Villemoes wrote: > Use the enum names which are also what is used in the switch() in > sched_dynamic_update(). > > Signed-off-by: Rasmus Villemoes Thanks for both!
Re: Re: [PATCH] target: Fix a double put in transport_free_session
> -原始邮件-
> 发件人: michael.chris...@oracle.com
> 发送时间: 2021-03-24 00:28:35 (星期三)
> 收件人: "Lv Yunlong" , martin.peter...@oracle.com
> 抄送: linux-s...@vger.kernel.org, target-de...@vger.kernel.org,
> linux-kernel@vger.kernel.org
> 主题: Re: [PATCH] target: Fix a double put in transport_free_session
>
> On 3/22/21 9:58 PM, Lv Yunlong wrote:
> > In transport_free_session, se_nacl is got from se_sess
> > with the initial reference. If se_nacl->acl_sess_list is
> > empty, se_nacl->dynamic_stop is set to true. Then the first
> > target_put_nacl(se_nacl) will drop the initial reference
> > and free se_nacl. Later there is a second target_put_nacl()
> > to put se_nacl. It may cause error in race.
> >> My patch sets se_nacl->dynamic_stop to false to avoid the
> > double put.
> >
> > Signed-off-by: Lv Yunlong
> > ---
> > drivers/target/target_core_transport.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/target/target_core_transport.c
> > b/drivers/target/target_core_transport.c
> > index 5ecb9f18a53d..c266defe694f 100644
> > --- a/drivers/target/target_core_transport.c
> > +++ b/drivers/target/target_core_transport.c
> > @@ -584,8 +584,10 @@ void transport_free_session(struct se_session *se_sess)
> > }
> > mutex_unlock(&se_tpg->acl_node_mutex);
> >
> > - if (se_nacl->dynamic_stop)
> > + if (se_nacl->dynamic_stop) {
> > target_put_nacl(se_nacl);
> > + se_nacl->dynamic_stop = false;
> > + }
> >
> > target_put_nacl(se_nacl);
> Could you describe the race a little more?
>
> Is the race:
>
> 1. thread1 called core_tpg_check_initiator_node_acl and found the acl.
> sess->se_node_acl is set to the found acl.
> 2. thread2 is running transport_free_session. It now grabs the acl_node_mutex
> and sees se_nacl->acl_sess_list is empty.
> 3. thread2 does the dynamic_stop=true operations in transport_free_session.
> 4. thread1 now calls transport_register_session now adds the sess to acl's
> acl_sess_list.
>
> Later when the session that thread 1 created is deleted dynamic_stop is still
> set, so we do an extra target_put_nacl?
>
> I'm not sure your patch will handle this race. When we delete the session
> thread1
> created dynamic_node_acl is still set, so this:
>
> mutex_lock(&se_tpg->acl_node_mutex);
> if (se_nacl->dynamic_node_acl &&
> !se_tfo->tpg_check_demo_mode_cache(se_tpg)) {
> spin_lock_irqsave(&se_nacl->nacl_sess_lock, flags);
> if (list_empty(&se_nacl->acl_sess_list))
> se_nacl->dynamic_stop = true;
>
> can set dynamic_stop to true again and we can end up doing the extra put
> still.
>
> On top of the extra put we also do
>
> list_del(&se_nacl->acl_list);
>
> twice so we have to handle that as well.
>
> Is there also another bug in this code. If someone adds an acl while there is
> a
> dynamic acl in place core_tpg_add_initiator_node_acl will clear
> dynamic_node_acl
> but we leave the extra reference, so later when transport_free_session is
> called
> we will not do the extra put.
>
Ok, thanks for your answer. According the description above, i think it is a
false
positive now.
Thanks.
Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
On 3/25/21 12:14 AM, Jason Gunthorpe wrote: On Wed, Mar 24, 2021 at 09:07:53PM +0100, Thomas Hellström (Intel) wrote: On 3/24/21 7:31 PM, Christian König wrote: Am 24.03.21 um 17:38 schrieb Jason Gunthorpe: On Wed, Mar 24, 2021 at 04:50:14PM +0100, Thomas Hellström (Intel) wrote: On 3/24/21 2:48 PM, Jason Gunthorpe wrote: On Wed, Mar 24, 2021 at 02:35:38PM +0100, Thomas Hellström (Intel) wrote: In an ideal world the creation/destruction of page table levels would by dynamic at this point, like THP. Hmm, but I'm not sure what problem we're trying to solve by changing the interface in this way? We are trying to make a sensible driver API to deal with huge pages. Currently if the core vm requests a huge pud, we give it one, and if we can't or don't want to (because of dirty-tracking, for example, which is always done on 4K page-level) we just return VM_FAULT_FALLBACK, and the fault is retried at a lower level. Well, my thought would be to move the pte related stuff into vmf_insert_range instead of recursing back via VM_FAULT_FALLBACK. I don't know if the locking works out, but it feels cleaner that the driver tells the vmf how big a page it can stuff in, not the vm telling the driver to stuff in a certain size page which it might not want to do. Some devices want to work on a in-between page size like 64k so they can't form 2M pages but they can stuff 64k of 4K pages in a batch on every fault. Hmm, yes, but we would in that case be limited anyway to insert ranges smaller than and equal to the fault size to avoid extensive and possibly unnecessary checks for contigous memory. Why? The insert function is walking the page tables, it just updates things as they are. It learns the arragement for free while doing the walk. The device has to always provide consistent data, if it overlaps into pages that are already populated that is fine so long as it isn't changing their addresses. And then if we can't support the full fault size, we'd need to either presume a size and alignment of the next level or search for contigous memory in both directions around the fault address, perhaps unnecessarily as well. You don't really need to care about levels, the device should be faulting in the largest memory regions it can within its efficiency. If it works on 4M pages then it should be faulting 4M pages. The page size of the underlying CPU doesn't really matter much other than some tuning to impact how the device's allocator works. Yes, but then we'd be adding a lot of complexity into this function that is already provided by the current interface for DAX, for little or no gain, at least in the drm/ttm setting. Please think of the following situation: You get a fault, you do an extensive time-consuming scan of your VRAM buffer object into which the fault goes and determine you can fault 1GB. Now you hand it to vmf_insert_range() and because the user-space address is misaligned, or already partly populated because of a previous eviction, you can only fault single pages, and you end up faulting a full GB of single pages perhaps for a one-time small update. Why would "you can only fault single pages" ever be true? If you have 1GB of pages then the vmf_insert_range should allocate enough page table entries to consume it, regardless of alignment. Ah yes, What I meant was you can only insert PTE size entries, either because of misalignment or because the page-table is alredy pre-populated with pmd size page directories, which you can't remove with only the read side of the mmap lock held. And why shouldn't DAX switch to this kind of interface anyhow? It is basically exactly the same problem. The underlying filesystem block size is *not* necessarily aligned to the CPU page table sizes and DAX would benefit from better handling of this mismatch. First, I think we must sort out what "better handling" means. This is my takeout of the discussion so far: Claimed Pros: of vmf_insert_range() * We get an interface that doesn't require knowledge of CPU page table entry level sizes. * We get the best efficiency when we look at what the GPU driver provides. (I disagree on this one). Claimed Cons: * A new implementation that may get complicated particularly if it involves modifying all of the DAX code * The driver would have to know about those sizes anyway to get alignment right (Applies to DRM, because we mmap buffer objects, not physical address ranges. But not to DAX AFAICT), * We loose efficiency, because we are prepared to spend an extra effort for alignment- and continuity checks when we know we can insert a huge page table entry, but not if we know we can't * We loose efficiency because we might unnecessarily prefault a number of PTE size page-table entries (really a special case of the above one). Now in the context of quickly fixing a critical bug, the choice IMHO becomes easy. On top of this, unless we want to do the walk trying increasingly smaller sizes of vmf_insert_xxx(),
Re: [PATCH] [v2] drivers: staging: _adapter is declared twice
On Thu, Mar 25, 2021 at 03:41:47PM +0800, Wan Jiabing wrote: > struct _adapter has been declared at 23rd line. Trailing whitespace :( > Remove the duplicate. > > Signed-off-by: Wan Jiabing > --- > drivers/staging/rtl8712/drv_types.h | 2 -- > 1 file changed, 2 deletions(-) If this is a v2 patch, you need to list what you changed below the --- line as documented. Please fix up and resend a v3. thanks, greg k-h
Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
Am 25.03.21 um 00:14 schrieb Jason Gunthorpe: On Wed, Mar 24, 2021 at 09:07:53PM +0100, Thomas Hellström (Intel) wrote: On 3/24/21 7:31 PM, Christian König wrote: Am 24.03.21 um 17:38 schrieb Jason Gunthorpe: On Wed, Mar 24, 2021 at 04:50:14PM +0100, Thomas Hellström (Intel) wrote: On 3/24/21 2:48 PM, Jason Gunthorpe wrote: On Wed, Mar 24, 2021 at 02:35:38PM +0100, Thomas Hellström (Intel) wrote: In an ideal world the creation/destruction of page table levels would by dynamic at this point, like THP. Hmm, but I'm not sure what problem we're trying to solve by changing the interface in this way? We are trying to make a sensible driver API to deal with huge pages. Currently if the core vm requests a huge pud, we give it one, and if we can't or don't want to (because of dirty-tracking, for example, which is always done on 4K page-level) we just return VM_FAULT_FALLBACK, and the fault is retried at a lower level. Well, my thought would be to move the pte related stuff into vmf_insert_range instead of recursing back via VM_FAULT_FALLBACK. I don't know if the locking works out, but it feels cleaner that the driver tells the vmf how big a page it can stuff in, not the vm telling the driver to stuff in a certain size page which it might not want to do. Some devices want to work on a in-between page size like 64k so they can't form 2M pages but they can stuff 64k of 4K pages in a batch on every fault. Hmm, yes, but we would in that case be limited anyway to insert ranges smaller than and equal to the fault size to avoid extensive and possibly unnecessary checks for contigous memory. Why? The insert function is walking the page tables, it just updates things as they are. It learns the arragement for free while doing the walk. The device has to always provide consistent data, if it overlaps into pages that are already populated that is fine so long as it isn't changing their addresses. And then if we can't support the full fault size, we'd need to either presume a size and alignment of the next level or search for contigous memory in both directions around the fault address, perhaps unnecessarily as well. You don't really need to care about levels, the device should be faulting in the largest memory regions it can within its efficiency. If it works on 4M pages then it should be faulting 4M pages. The page size of the underlying CPU doesn't really matter much other than some tuning to impact how the device's allocator works. Yes, but then we'd be adding a lot of complexity into this function that is already provided by the current interface for DAX, for little or no gain, at least in the drm/ttm setting. Please think of the following situation: You get a fault, you do an extensive time-consuming scan of your VRAM buffer object into which the fault goes and determine you can fault 1GB. Now you hand it to vmf_insert_range() and because the user-space address is misaligned, or already partly populated because of a previous eviction, you can only fault single pages, and you end up faulting a full GB of single pages perhaps for a one-time small update. Why would "you can only fault single pages" ever be true? If you have 1GB of pages then the vmf_insert_range should allocate enough page table entries to consume it, regardless of alignment. Completely agree with Jason. Filling in the CPU page tables is relatively cheap if you fill in a large continuous range. In other words filling in 1GiB of a linear range is *much* less overhead than filling in 1<<18 4KiB faults. I would say that this is always preferable even if the CPU only wants to update a single byte. And why shouldn't DAX switch to this kind of interface anyhow? It is basically exactly the same problem. The underlying filesystem block size is *not* necessarily aligned to the CPU page table sizes and DAX would benefit from better handling of this mismatch. On top of this, unless we want to do the walk trying increasingly smaller sizes of vmf_insert_xxx(), we'd have to use apply_to_page_range() and teach it about transhuge page table entries, because pagewalk.c can't be used (It can't populate page tables). That also means apply_to_page_range() needs to be complicated with page table locks since transhuge pages aren't stable and can be zapped and refaulted under us while we do the walk. I didn't say it would be simple :) But we also need to stop hacking around the sides of all this huge page stuff and come up with sensible APIs that drivers can actually implement correctly. Exposing drivers to specific kinds of page levels really feels like the wrong level of abstraction. Once we start doing this we should do it everywhere, the io_remap_pfn stuff should be able to create huge special IO pages as well, for instance. Oh, yes please! We easily have 16GiB of VRAM which is linear mapped into the kernel space for each GPU instance. Doing that with 1GiB mapping instead of 4KiB would be quite a win. Regards, Christian. On t
[PATCH 1/4] PCI: acpi_pcihp: Correct acpi_pci_check_ejectable() function name in the header
Fixes the following W=1 kernel build warning(s): drivers/pci/hotplug/acpi_pcihp.c:167: warning: expecting prototype for acpi_pcihp_check_ejectable(). Prototype was for acpi_pci_check_ejectable() instead Reported-by: Hulk Robot Signed-off-by: Xiongfeng Wang --- drivers/pci/hotplug/acpi_pcihp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/hotplug/acpi_pcihp.c b/drivers/pci/hotplug/acpi_pcihp.c index 2750a64cecd3..4fedebf2f8c1 100644 --- a/drivers/pci/hotplug/acpi_pcihp.c +++ b/drivers/pci/hotplug/acpi_pcihp.c @@ -157,7 +157,7 @@ static int pcihp_is_ejectable(acpi_handle handle) } /** - * acpi_pcihp_check_ejectable - check if handle is ejectable ACPI PCI slot + * acpi_pci_check_ejectable - check if handle is ejectable ACPI PCI slot * @pbus: the PCI bus of the PCI slot corresponding to 'handle' * @handle: ACPI handle to check * -- 2.20.1
[PATCH 2/4] PCI/AER: Correct function names in the header
Fixes the following W=1 kernel build warning(s):
drivers/pci/pcie/aer.c:138: warning: expecting prototype for
enable_ercr_checking(). Prototype was for enable_ecrc_checking() instead
drivers/pci/pcie/aer.c:162: warning: expecting prototype for
disable_ercr_checking(). Prototype was for disable_ecrc_checking() instead
drivers/pci/pcie/aer.c:1450: warning: expecting prototype for
aer_service_init(). Prototype was for pcie_aer_init() instead
Reported-by: Hulk Robot
Signed-off-by: Xiongfeng Wang
---
drivers/pci/pcie/aer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index ba22388342d1..ec943cee5ecc 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -129,7 +129,7 @@ static const char * const ecrc_policy_str[] = {
};
/**
- * enable_ercr_checking - enable PCIe ECRC checking for a device
+ * enable_ecrc_checking - enable PCIe ECRC checking for a device
* @dev: the PCI device
*
* Returns 0 on success, or negative on failure.
@@ -153,7 +153,7 @@ static int enable_ecrc_checking(struct pci_dev *dev)
}
/**
- * disable_ercr_checking - disables PCIe ECRC checking for a device
+ * disable_ecrc_checking - disables PCIe ECRC checking for a device
* @dev: the PCI device
*
* Returns 0 on success, or negative on failure.
@@ -1442,7 +1442,7 @@ static struct pcie_port_service_driver aerdriver = {
};
/**
- * aer_service_init - register AER root service driver
+ * pcie_aer_init - register AER root service driver
*
* Invoked when AER root service driver is loaded.
*/
--
2.20.1
[PATCH 0/4] PCI: Correct function names in the header
Xiongfeng Wang (4): PCI: acpi_pcihp: Correct acpi_pci_check_ejectable() function name in the header PCI/AER: Correct function names in the header PCI/PME: Correct pcie_pme_init() function name in the header PCI/ATS: Correct pci_max_pasids() function name in header drivers/pci/ats.c| 2 +- drivers/pci/hotplug/acpi_pcihp.c | 2 +- drivers/pci/pcie/aer.c | 6 +++--- drivers/pci/pcie/pme.c | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) -- 2.20.1
[PATCH 4/4] PCI/ATS: Correct pci_max_pasids() function name in header
Fixes the following W=1 kernel build warning(s): drivers/pci/ats.c:490: warning: expecting prototype for pci_max_pasid(). Prototype was for pci_max_pasids() instead Reported-by: Hulk Robot Signed-off-by: Xiongfeng Wang --- drivers/pci/ats.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c index 0d3719407b8b..6d7d64939f82 100644 --- a/drivers/pci/ats.c +++ b/drivers/pci/ats.c @@ -480,7 +480,7 @@ EXPORT_SYMBOL_GPL(pci_pasid_features); #define PASID_NUMBER_SHIFT 8 #define PASID_NUMBER_MASK (0x1f << PASID_NUMBER_SHIFT) /** - * pci_max_pasid - Get maximum number of PASIDs supported by device + * pci_max_pasids - Get maximum number of PASIDs supported by device * @pdev: PCI device structure * * Returns negative value when PASID capability is not present. -- 2.20.1
[PATCH 3/4] PCI/PME: Correct pcie_pme_init() function name in the header
Fixes the following W=1 kernel build warning(s):
drivers/pci/pcie/pme.c:469: warning: expecting prototype for
pcie_pme_service_init(). Prototype was for pcie_pme_init() instead
Reported-by: Hulk Robot
Signed-off-by: Xiongfeng Wang
---
drivers/pci/pcie/pme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
index 3fc08488d65f..1d0dd77fed3a 100644
--- a/drivers/pci/pcie/pme.c
+++ b/drivers/pci/pcie/pme.c
@@ -463,7 +463,7 @@ static struct pcie_port_service_driver pcie_pme_driver = {
};
/**
- * pcie_pme_service_init - Register the PCIe PME service driver.
+ * pcie_pme_init - Register the PCIe PME service driver.
*/
int __init pcie_pme_init(void)
{
--
2.20.1
Re: [PATCH] tee: optee: add invoke_fn tracepoints
On Thu, Mar 25, 2021 at 3:50 AM Jisheng Zhang wrote: > > On Wed, 24 Mar 2021 10:53:13 -0400 > Steven Rostedt wrote: > > > > > > On Wed, 24 Mar 2021 07:48:53 -0700 > > Guenter Roeck wrote: > > > > > On Wed, Mar 24, 2021 at 07:34:07AM -0700, Guenter Roeck wrote: > > > > On Wed, Feb 10, 2021 at 02:44:09PM +0800, Jisheng Zhang wrote: > > > > > Add tracepoints to retrieve information about the invoke_fn. This > > > > > would > > > > > help to measure how many invoke_fn are triggered and how long it takes > > > > > to complete one invoke_fn call. > > > > > > > > > > Signed-off-by: Jisheng Zhang > > > > > > > > arm64:defconfig: > > > > > > > > make-arm64 -j drivers/tee/optee/call.o > > > > CALLscripts/atomic/check-atomics.sh > > > > CALLscripts/checksyscalls.sh > > > > CC drivers/tee/optee/call.o > > > > In file included from drivers/tee/optee/optee_trace.h:67, > > > > from drivers/tee/optee/call.c:18: > > > > ./include/trace/define_trace.h:95:42: fatal error: ./optee_trace.h: No > > > > such file or directory > > > >95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE) > > > > | ^ > > > > compilation terminated. > > Interesting, I always build linux kernel with "O=", didn't see such build > error > and IIRC, we didn't receive any lkp robot build error report. > > My steps are: > > mkdir /tmp/test > > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=/tmp/test defconfig > > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=/tmp/test > drivers/tee/optee/ > > Today, I tried to build the linux kernel w/o "O=...", I reproduced this error! > This is the first time I saw "O=" make a different behavior. I'm also compiling with O=... and couldn't understand what was going on. Thanks for saving me from digging any deeper. > > I'll send out a patch to fix it. Thanks, Jens
[PATCH v2 00/16] clk: st: embed clock outputs within drivers
Most of ST clock drivers used by STi platform are updated in order to introduce clock outputs informations within each drivers and thus allow to avoid having to rely on clock-output-names properties within DT clock nodes. For that purpose, drivers are updated to allow handling both modes (with or without clock-output-names). Once all DT will have been updated, the legacy mode could be removed from the drivers. This will also allow, once all STi DT will be corrected, to remove the of_clk_detect_critical API from clk core code since STi clock drivers are the only drivers using this API. This serie also contains modifications within STi DTS in order to use the newly introduced compatible and remove clock-output-names properties. Alain Volmat (16): clk: st: clkgen-pll: remove used variable of struct clkgen_pll clk: st: flexgen: embed soc clock outputs within compatible data dt-bindings: clock: st: flexgen: add new introduced compatible clk: st: clkgen-pll: embed soc clock outputs within compatible data dt-bindings: clock: st: clkgen-pll: add new introduced compatible clk: st: clkgen-fsyn: embed soc clock outputs within compatible data dt-bindings: clock: st: clkgen-fsyn: add new introduced compatible ARM: dts: sti: update flexgen compatible within stih418-clock ARM: dts: sti: update flexgen compatible within stih407-clock ARM: dts: sti: update flexgen compatible within stih410-clock ARM: dts: sti: update clkgen-pll entries in stih407-clock ARM: dts: sti: update clkgen-pll entries in stih410-clock ARM: dts: sti: update clkgen-pll entries in stih418-clock ARM: dts: sti: update clkgen-fsyn entries in stih407-clock ARM: dts: sti: update clkgen-fsyn entries in stih410-clock ARM: dts: sti: update clkgen-fsyn entries in stih418-clock .../bindings/clock/st/st,clkgen-pll.txt | 3 + .../bindings/clock/st/st,flexgen.txt | 10 + .../bindings/clock/st/st,quadfs.txt | 3 + arch/arm/boot/dts/stih407-clock.dtsi | 128 +-- arch/arm/boot/dts/stih410-clock.dtsi | 138 +-- arch/arm/boot/dts/stih418-clock.dtsi | 136 +-- drivers/clk/st/clk-flexgen.c | 344 +- drivers/clk/st/clkgen-fsyn.c | 113 +- drivers/clk/st/clkgen-pll.c | 121 +- 9 files changed, 588 insertions(+), 408 deletions(-) --- v2: fix drivers to update some clocks as CLK_IS_CRITICAL -- 2.17.1
[PATCH v2 01/16] clk: st: clkgen-pll: remove used variable of struct clkgen_pll
ODF field within the struct clkgen_pll is never used by the driver
and can thus be removed.
Signed-off-by: Alain Volmat
---
drivers/clk/st/clkgen-pll.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
index 119c5b33080c..f6c56ca90c7d 100644
--- a/drivers/clk/st/clkgen-pll.c
+++ b/drivers/clk/st/clkgen-pll.c
@@ -146,7 +146,6 @@ struct clkgen_pll {
u32 ndiv;
u32 idf;
- u32 odf;
u32 cp;
};
--
2.17.1
[PATCH v2 02/16] clk: st: flexgen: embed soc clock outputs within compatible data
In order to avoid relying on the old style description via the DT
clock-output-names, add compatible data describing the flexgen
outputs clocks for all STiH407/STiH410 and STiH418 SOCs.
In order to ease transition between the two methods, this commit
introduce the new compatible without removing the old method.
Once DTs will be fixed, the method relying on DT clock-output-names
will be removed from this driver as well as old compatibles.
Signed-off-by: Alain Volmat
---
v2: add some missing clock as CLK_IS_CRITICAL
drivers/clk/st/clk-flexgen.c | 344 +--
1 file changed, 330 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/st/clk-flexgen.c b/drivers/clk/st/clk-flexgen.c
index 55873d4b7603..24dd0c7dc6c3 100644
--- a/drivers/clk/st/clk-flexgen.c
+++ b/drivers/clk/st/clk-flexgen.c
@@ -16,9 +16,16 @@
#include
#include
+struct clkgen_clk_out {
+ const char *name;
+ unsigned long flags;
+};
+
struct clkgen_data {
unsigned long flags;
bool mode;
+ const struct clkgen_clk_out *outputs;
+ const unsigned int outputs_nb;
};
struct flexgen {
@@ -295,6 +302,267 @@ static const struct clkgen_data clkgen_video = {
.mode = 1,
};
+static const struct clkgen_clk_out clkgen_stih407_a0_clk_out[] = {
+ { .name = "clk-ic-lmi0", .flags = CLK_IS_CRITICAL },
+};
+
+static const struct clkgen_data clkgen_stih407_a0 = {
+ .outputs = clkgen_stih407_a0_clk_out,
+ .outputs_nb = ARRAY_SIZE(clkgen_stih407_a0_clk_out),
+};
+
+static const struct clkgen_clk_out clkgen_stih410_a0_clk_out[] = {
+ { .name = "clk-ic-lmi0", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-ic-lmi1", .flags = CLK_IS_CRITICAL },
+};
+
+static const struct clkgen_data clkgen_stih410_a0 = {
+ .outputs = clkgen_stih410_a0_clk_out,
+ .outputs_nb = ARRAY_SIZE(clkgen_stih410_a0_clk_out),
+};
+
+static const struct clkgen_clk_out clkgen_stih407_c0_clk_out[] = {
+ { .name = "clk-icn-gpu", },
+ { .name = "clk-fdma", },
+ { .name = "clk-nand", },
+ { .name = "clk-hva", },
+ { .name = "clk-proc-stfe", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-proc-tp", },
+ { .name = "clk-rx-icn-dmu", },
+ { .name = "clk-rx-icn-hva", },
+ { .name = "clk-icn-cpu", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-tx-icn-dmu", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-mmc-0", },
+ { .name = "clk-mmc-1", },
+ { .name = "clk-jpegdec", },
+ { .name = "clk-ext2fa9", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-ic-bdisp-0", },
+ { .name = "clk-ic-bdisp-1", },
+ { .name = "clk-pp-dmu", },
+ { .name = "clk-vid-dmu", },
+ { .name = "clk-dss-lpc", },
+ { .name = "clk-st231-aud-0", },
+ { .name = "clk-st231-gp-1", },
+ { .name = "clk-st231-dmu", },
+ { .name = "clk-icn-lmi", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-tx-icn-disp-1", },
+ { .name = "clk-icn-sbc", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-stfe-frc2", },
+ { .name = "clk-eth-phy", },
+ { .name = "clk-eth-ref-phyclk", },
+ { .name = "clk-flash-promip", },
+ { .name = "clk-main-disp", },
+ { .name = "clk-aux-disp", },
+ { .name = "clk-compo-dvp", },
+};
+
+static const struct clkgen_data clkgen_stih407_c0 = {
+ .outputs = clkgen_stih407_c0_clk_out,
+ .outputs_nb = ARRAY_SIZE(clkgen_stih407_c0_clk_out),
+};
+
+static const struct clkgen_clk_out clkgen_stih410_c0_clk_out[] = {
+ { .name = "clk-icn-gpu", },
+ { .name = "clk-fdma", },
+ { .name = "clk-nand", },
+ { .name = "clk-hva", },
+ { .name = "clk-proc-stfe", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-proc-tp", },
+ { .name = "clk-rx-icn-dmu", },
+ { .name = "clk-rx-icn-hva", },
+ { .name = "clk-icn-cpu", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-tx-icn-dmu", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-mmc-0", },
+ { .name = "clk-mmc-1", },
+ { .name = "clk-jpegdec", },
+ { .name = "clk-ext2fa9", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-ic-bdisp-0", },
+ { .name = "clk-ic-bdisp-1", },
+ { .name = "clk-pp-dmu", },
+ { .name = "clk-vid-dmu", },
+ { .name = "clk-dss-lpc", },
+ { .name = "clk-st231-aud-0", },
+ { .name = "clk-st231-gp-1", },
+ { .name = "clk-st231-dmu", },
+ { .name = "clk-icn-lmi", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-tx-icn-disp-1", },
+ { .name = "clk-icn-sbc", .flags = CLK_IS_CRITICAL },
+ { .name = "clk-stfe-frc2", },
+ { .name = "clk-eth-phy", },
+ { .name = "clk-eth-ref-phyclk", },
+ { .name = "clk-flash-promip", },
+ { .name = "clk-main-disp", },
+ { .name = "clk-aux-disp", },
+ { .name = "clk-compo-dvp", },
+ { .name = "clk-tx-icn-hades", },
+ { .name = "clk-rx-icn-hades", },
+ { .name = "clk-icn-r
[PATCH v2 03/16] dt-bindings: clock: st: flexgen: add new introduced compatible
New compatible are added, supporting various kind of flexgen in STiH407, STiH410 and STiH418 Signed-off-by: Alain Volmat --- .../devicetree/bindings/clock/st/st,flexgen.txt| 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt index 7ff77fc57dff..55a18939bddd 100644 --- a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt +++ b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt @@ -64,6 +64,16 @@ Required properties: audio use case) "st,flexgen-video", "st,flexgen" (enable clock propagation on parent and activate synchronous mode) + "st,flexgen-stih407-a0" + "st,flexgen-stih410-a0" + "st,flexgen-stih407-c0" + "st,flexgen-stih410-c0" + "st,flexgen-stih418-c0" + "st,flexgen-stih407-d0" + "st,flexgen-stih410-d0" + "st,flexgen-stih407-d2" + "st,flexgen-stih418-d2" + "st,flexgen-stih407-d3" - #clock-cells : from common clock binding; shall be set to 1 (multiple clock outputs). -- 2.17.1
[PATCH v2 04/16] clk: st: clkgen-pll: embed soc clock outputs within compatible data
In order to avoid relying on the old style description via the DT
clock-output-names, add compatible data describing the flexgen
outputs clocks for all STiH407/STiH410 and STiH418 SOCs.
In order to ease transition between the two methods, this commit
introduce the new compatible without removing the old method.
Once DTs will be fixed, the method relying on DT clock-output-names
will be removed from this driver as well as old compatibles.
Signed-off-by: Alain Volmat
---
v2: clk-s-a0-pll-odf-0 don't need to be CLK_IS_CRITICAL
mark several clock as CLK_IS_CRITICAL
drivers/clk/st/clkgen-pll.c | 120 +++-
1 file changed, 106 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
index f6c56ca90c7d..8c6215b3c808 100644
--- a/drivers/clk/st/clkgen-pll.c
+++ b/drivers/clk/st/clkgen-pll.c
@@ -57,6 +57,17 @@ struct clkgen_pll_data {
const struct clk_ops *ops;
};
+struct clkgen_clk_out {
+ const char *name;
+ unsigned long flags;
+};
+
+struct clkgen_pll_data_clks {
+ struct clkgen_pll_data *data;
+ const struct clkgen_clk_out *outputs;
+};
+
+
static const struct clk_ops stm_pll3200c32_ops;
static const struct clk_ops stm_pll3200c32_a9_ops;
static const struct clk_ops stm_pll4600c28_ops;
@@ -74,6 +85,28 @@ static const struct clkgen_pll_data st_pll3200c32_cx_0 = {
.ops= &stm_pll3200c32_ops,
};
+static const struct clkgen_pll_data_clks st_pll3200c32_cx_0_legacy_data = {
+ .data = (struct clkgen_pll_data *)&st_pll3200c32_cx_0,
+};
+
+static const struct clkgen_clk_out st_pll3200c32_ax_0_clks[] = {
+ { .name = "clk-s-a0-pll-odf-0", },
+};
+
+static const struct clkgen_pll_data_clks st_pll3200c32_a0_data = {
+ .data = (struct clkgen_pll_data *)&st_pll3200c32_cx_0,
+ .outputs= st_pll3200c32_ax_0_clks,
+};
+
+static const struct clkgen_clk_out st_pll3200c32_cx_0_clks[] = {
+ { .name = "clk-s-c0-pll0-odf-0",.flags = CLK_IS_CRITICAL },
+};
+
+static const struct clkgen_pll_data_clks st_pll3200c32_c0_data = {
+ .data = (struct clkgen_pll_data *)&st_pll3200c32_cx_0,
+ .outputs= st_pll3200c32_cx_0_clks,
+};
+
static const struct clkgen_pll_data st_pll3200c32_cx_1 = {
/* 407 C0 PLL1 */
.pdn_status = CLKGEN_FIELD(0x2c8, 0x1,8),
@@ -87,6 +120,19 @@ static const struct clkgen_pll_data st_pll3200c32_cx_1 = {
.ops= &stm_pll3200c32_ops,
};
+static const struct clkgen_pll_data_clks st_pll3200c32_cx_1_legacy_data = {
+ .data = (struct clkgen_pll_data *)&st_pll3200c32_cx_1,
+};
+
+static const struct clkgen_clk_out st_pll3200c32_cx_1_clks[] = {
+ { .name = "clk-s-c0-pll1-odf-0",.flags = CLK_IS_CRITICAL },
+};
+
+static const struct clkgen_pll_data_clks st_pll3200c32_c1_data = {
+ .data = (struct clkgen_pll_data *)&st_pll3200c32_cx_1,
+ .outputs= st_pll3200c32_cx_1_clks,
+};
+
static const struct clkgen_pll_data st_pll3200c32_407_a9 = {
/* 407 A9 */
.pdn_status = CLKGEN_FIELD(0x1a8, 0x1,0),
@@ -104,6 +150,15 @@ static const struct clkgen_pll_data st_pll3200c32_407_a9 =
{
.ops= &stm_pll3200c32_a9_ops,
};
+static const struct clkgen_clk_out st_pll3200c32_407_a9_clks[] = {
+ { .name = "clockgen-a9-pll-odf",.flags = CLK_IS_CRITICAL },
+};
+
+static const struct clkgen_pll_data_clks st_pll3200c32_407_a9_data = {
+ .data = (struct clkgen_pll_data *)&st_pll3200c32_407_a9,
+ .outputs= st_pll3200c32_407_a9_clks,
+};
+
static struct clkgen_pll_data st_pll4600c28_418_a9 = {
/* 418 A9 */
.pdn_status = CLKGEN_FIELD(0x1a8, 0x1,0),
@@ -120,6 +175,15 @@ static struct clkgen_pll_data st_pll4600c28_418_a9 = {
.ops= &stm_pll4600c28_ops,
};
+static const struct clkgen_clk_out st_pll4600c28_418_a9_clks[] = {
+ { .name = "clockgen-a9-pll-odf", },
+};
+
+static const struct clkgen_pll_data_clks st_pll4600c28_418_a9_data = {
+ .data = (struct clkgen_pll_data *)&st_pll4600c28_418_a9,
+ .outputs= st_pll4600c28_418_a9_clks,
+};
+
/**
* DOC: Clock Generated by PLL, rate set and enabled by bootloader
*
@@ -684,7 +748,7 @@ static struct clk * __init clkgen_odf_register(const char
*parent_name,
static void __init clkgen_c32_pll_setup(struct device_node *np,
- struct clkgen_pll_data *data)
+ struct clkgen_pll_data_clks *datac)
{
struct clk *clk;
const char *parent_name, *pll_name;
@@ -704,14 +768,14 @@ static void __init clkgen_c32_pll_setup(struct
device_node *np,
of_clk_detect_critical(np, 0, &pll_flags);
- clk = clkgen_pll_register(parent_name, data, pll_base, pll_flags,
- np->name, data->lock);
+
[PATCH v2 05/16] dt-bindings: clock: st: clkgen-pll: add new introduced compatible
New compatible are added, supporting various kind of clkgen-pll used for STiH407, STiH410 and STiH418 Signed-off-by: Alain Volmat --- Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt index f207053e0550..d0fa1e02d06d 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt @@ -10,7 +10,10 @@ Required properties: - compatible : shall be: "st,clkgen-pll0" + "st,clkgen-pll0-a0" + "st,clkgen-pll0-c0" "st,clkgen-pll1" + "st,clkgen-pll1-c0" "st,stih407-clkgen-plla9" "st,stih418-clkgen-plla9" -- 2.17.1
[PATCH v2 08/16] ARM: dts: sti: update flexgen compatible within stih418-clock
With the introduction of new flexgen compatible within the clk-flexgen
driver, remove the clock-output-names entry from the flexgen nodes
and set the new proper compatible corresponding.
Signed-off-by: Alain Volmat
---
arch/arm/boot/dts/stih418-clock.dtsi | 96 ++--
1 file changed, 5 insertions(+), 91 deletions(-)
diff --git a/arch/arm/boot/dts/stih418-clock.dtsi
b/arch/arm/boot/dts/stih418-clock.dtsi
index 8fa092462102..35d12979cdf4 100644
--- a/arch/arm/boot/dts/stih418-clock.dtsi
+++ b/arch/arm/boot/dts/stih418-clock.dtsi
@@ -83,15 +83,12 @@
};
clk_s_a0_flexgen: clk-s-a0-flexgen {
- compatible = "st,flexgen";
+ compatible = "st,flexgen",
"st,flexgen-stih410-a0";
#clock-cells = <1>;
clocks = <&clk_s_a0_pll 0>,
<&clk_sysin>;
-
- clock-output-names = "clk-ic-lmi0",
-"clk-ic-lmi1";
};
};
@@ -132,7 +129,7 @@
clk_s_c0_flexgen: clk-s-c0-flexgen {
#clock-cells = <1>;
- compatible = "st,flexgen";
+ compatible = "st,flexgen",
"st,flexgen-stih418-c0";
clocks = <&clk_s_c0_pll0 0>,
<&clk_s_c0_pll1 0>,
@@ -142,49 +139,6 @@
<&clk_s_c0_quadfs 3>,
<&clk_sysin>;
- clock-output-names = "clk-icn-gpu",
-"clk-fdma",
-"clk-nand",
-"clk-hva",
-"clk-proc-stfe",
-"clk-tp",
-"clk-rx-icn-dmu",
-"clk-rx-icn-hva",
-"clk-icn-cpu",
-"clk-tx-icn-dmu",
-"clk-mmc-0",
-"clk-mmc-1",
-"clk-jpegdec",
-"clk-icn-reg",
-"clk-proc-bdisp-0",
-"clk-proc-bdisp-1",
-"clk-pp-dmu",
-"clk-vid-dmu",
-"clk-dss-lpc",
-"clk-st231-aud-0",
-"clk-st231-gp-1",
-"clk-st231-dmu",
-"clk-icn-lmi",
-"clk-tx-icn-1",
-"clk-icn-sbc",
-"clk-stfe-frc2",
-"clk-eth-phyref",
-"clk-eth-ref-phyclk",
-"clk-flash-promip",
-"clk-main-disp",
-"clk-aux-disp",
-"clk-compo-dvp",
-"clk-tx-icn-hades",
-"clk-rx-icn-hades",
-"clk-icn-reg-16",
-"clk-pp-hevc",
-"clk-clust-hevc",
-"clk-hwpe-hevc",
-"clk-fc-hevc",
-"clk-proc-mixer",
-"clk-proc-sc",
-"clk-avsp-hevc";
-
/*
* ARM Peripheral clock for timers
*/
@@ -221,20 +175,13 @@
clk_s_d0_flexgen: clk-s-d0-flexgen {
#clock-cells = <1>;
- compatible = "st,flexgen-audio", "st,flexgen";
+
[PATCH v2 07/16] dt-bindings: clock: st: clkgen-fsyn: add new introduced compatible
New compatible are added, supporting various kind of clkgen-fsyn used for STiH407, STiH410 and STiH418 Signed-off-by: Alain Volmat --- Documentation/devicetree/bindings/clock/st/st,quadfs.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt index d93d49342e60..c4ba2adb0b4f 100644 --- a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt +++ b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt @@ -12,6 +12,9 @@ This binding uses the common clock binding[1]. Required properties: - compatible : shall be: "st,quadfs" + "st,quadfs-d0" + "st,quadfs-d2" + "st,quadfs-d3" "st,quadfs-pll" -- 2.17.1
[PATCH v2 10/16] ARM: dts: sti: update flexgen compatible within stih410-clock
With the introduction of new flexgen compatible within the clk-flexgen
driver, remove the clock-output-names entry from the flexgen nodes
and set the new proper compatible corresponding.
Signed-off-by: Alain Volmat
---
arch/arm/boot/dts/stih410-clock.dtsi | 95 ++--
1 file changed, 6 insertions(+), 89 deletions(-)
diff --git a/arch/arm/boot/dts/stih410-clock.dtsi
b/arch/arm/boot/dts/stih410-clock.dtsi
index 81a8c25d7ba5..04b0d7080353 100644
--- a/arch/arm/boot/dts/stih410-clock.dtsi
+++ b/arch/arm/boot/dts/stih410-clock.dtsi
@@ -83,16 +83,12 @@
};
clk_s_a0_flexgen: clk-s-a0-flexgen {
- compatible = "st,flexgen";
+ compatible = "st,flexgen",
"st,flexgen-stih410-a0";
#clock-cells = <1>;
clocks = <&clk_s_a0_pll 0>,
<&clk_sysin>;
-
- clock-output-names = "clk-ic-lmi0",
-"clk-ic-lmi1";
- clock-critical = ;
};
};
@@ -135,7 +131,7 @@
clk_s_c0_flexgen: clk-s-c0-flexgen {
#clock-cells = <1>;
- compatible = "st,flexgen";
+ compatible = "st,flexgen",
"st,flexgen-stih410-c0";
clocks = <&clk_s_c0_pll0 0>,
<&clk_s_c0_pll1 0>,
@@ -145,52 +141,6 @@
<&clk_s_c0_quadfs 3>,
<&clk_sysin>;
- clock-output-names = "clk-icn-gpu",
-"clk-fdma",
-"clk-nand",
-"clk-hva",
-"clk-proc-stfe",
-"clk-proc-tp",
-"clk-rx-icn-dmu",
-"clk-rx-icn-hva",
-"clk-icn-cpu",
-"clk-tx-icn-dmu",
-"clk-mmc-0",
-"clk-mmc-1",
-"clk-jpegdec",
-"clk-ext2fa9",
-"clk-ic-bdisp-0",
-"clk-ic-bdisp-1",
-"clk-pp-dmu",
-"clk-vid-dmu",
-"clk-dss-lpc",
-"clk-st231-aud-0",
-"clk-st231-gp-1",
-"clk-st231-dmu",
-"clk-icn-lmi",
-"clk-tx-icn-disp-1",
-"clk-icn-sbc",
-"clk-stfe-frc2",
-"clk-eth-phy",
-"clk-eth-ref-phyclk",
-"clk-flash-promip",
-"clk-main-disp",
-"clk-aux-disp",
-"clk-compo-dvp",
-"clk-tx-icn-hades",
-"clk-rx-icn-hades",
-"clk-icn-reg-16",
-"clk-pp-hades",
-"clk-clust-hades",
-"clk-hwpe-hades",
-"clk-fc-hades";
- clock-critical = ,
-,
-,
-,
-,
-;
-
/*
* ARM Peripheral clock for timers
*/
@@ -227,20 +177,13 @@
clk_s_d0_flexgen: clk-s-d0-fl
[PATCH v2 06/16] clk: st: clkgen-fsyn: embed soc clock outputs within compatible data
In order to avoid relying on the old style description via the DT
clock-output-names, add compatible data describing the flexgen
outputs clocks for all STiH407/STiH410 and STiH418 SOCs.
In order to ease transition between the two methods, this commit
introduce the new compatible without removing the old method.
Once DTs will be fixed, the method relying on DT clock-output-names
will be removed from this driver as well as old compatibles.
Signed-off-by: Alain Volmat
---
v2: clk-s-c0-fs0-ch0 do not need to be CLK_IS_CRITICAL
drivers/clk/st/clkgen-fsyn.c | 113 +++
1 file changed, 101 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/st/clkgen-fsyn.c b/drivers/clk/st/clkgen-fsyn.c
index dd6062e043e0..164285d6be97 100644
--- a/drivers/clk/st/clkgen-fsyn.c
+++ b/drivers/clk/st/clkgen-fsyn.c
@@ -66,6 +66,16 @@ struct clkgen_quadfs_data {
unsigned long *);
};
+struct clkgen_clk_out {
+ const char *name;
+ unsigned long flags;
+};
+
+struct clkgen_quadfs_data_clks {
+ struct clkgen_quadfs_data *data;
+ const struct clkgen_clk_out *outputs;
+};
+
static const struct clk_ops st_quadfs_pll_c32_ops;
static int clk_fs660c32_dig_get_params(unsigned long input,
@@ -115,6 +125,18 @@ static const struct clkgen_quadfs_data st_fs660c32_C = {
.get_rate = clk_fs660c32_dig_get_rate,
};
+static const struct clkgen_clk_out st_fs660c32_C_clks[] = {
+ { .name = "clk-s-c0-fs0-ch0", },
+ { .name = "clk-s-c0-fs0-ch1", },
+ { .name = "clk-s-c0-fs0-ch2", },
+ { .name = "clk-s-c0-fs0-ch3", },
+};
+
+static const struct clkgen_quadfs_data_clks st_fs660c32_C_data = {
+ .data = (struct clkgen_quadfs_data *)&st_fs660c32_C,
+ .outputs= st_fs660c32_C_clks,
+};
+
static const struct clkgen_quadfs_data st_fs660c32_D = {
.nrst_present = true,
.nrst = { CLKGEN_FIELD(0x2a0, 0x1, 0),
@@ -156,6 +178,46 @@ static const struct clkgen_quadfs_data st_fs660c32_D = {
.get_params = clk_fs660c32_dig_get_params,
.get_rate = clk_fs660c32_dig_get_rate,};
+static const struct clkgen_quadfs_data_clks st_fs660c32_D_data = {
+ .data = (struct clkgen_quadfs_data *)&st_fs660c32_D,
+};
+
+static const struct clkgen_clk_out st_fs660c32_D0_clks[] = {
+ { .name = "clk-s-d0-fs0-ch0", },
+ { .name = "clk-s-d0-fs0-ch1", },
+ { .name = "clk-s-d0-fs0-ch2", },
+ { .name = "clk-s-d0-fs0-ch3", },
+};
+
+static const struct clkgen_quadfs_data_clks st_fs660c32_D0_data = {
+ .data = (struct clkgen_quadfs_data *)&st_fs660c32_D,
+ .outputs= st_fs660c32_D0_clks,
+};
+
+static const struct clkgen_clk_out st_fs660c32_D2_clks[] = {
+ { .name = "clk-s-d2-fs0-ch0", },
+ { .name = "clk-s-d2-fs0-ch1", },
+ { .name = "clk-s-d2-fs0-ch2", },
+ { .name = "clk-s-d2-fs0-ch3", },
+};
+
+static const struct clkgen_quadfs_data_clks st_fs660c32_D2_data = {
+ .data = (struct clkgen_quadfs_data *)&st_fs660c32_D,
+ .outputs= st_fs660c32_D2_clks,
+};
+
+static const struct clkgen_clk_out st_fs660c32_D3_clks[] = {
+ { .name = "clk-s-d3-fs0-ch0", },
+ { .name = "clk-s-d3-fs0-ch1", },
+ { .name = "clk-s-d3-fs0-ch2", },
+ { .name = "clk-s-d3-fs0-ch3", },
+};
+
+static const struct clkgen_quadfs_data_clks st_fs660c32_D3_data = {
+ .data = (struct clkgen_quadfs_data *)&st_fs660c32_D,
+ .outputs= st_fs660c32_D3_clks,
+};
+
/**
* DOC: A Frequency Synthesizer that multiples its input clock by a fixed
factor
*
@@ -857,7 +919,7 @@ static struct clk * __init st_clk_register_quadfs_fsynth(
static void __init st_of_create_quadfs_fsynths(
struct device_node *np, const char *pll_name,
- struct clkgen_quadfs_data *quadfs, void __iomem *reg,
+ struct clkgen_quadfs_data_clks *quadfs, void __iomem *reg,
spinlock_t *lock)
{
struct clk_onecell_data *clk_data;
@@ -881,9 +943,15 @@ static void __init st_of_create_quadfs_fsynths(
const char *clk_name;
unsigned long flags = 0;
- if (of_property_read_string_index(np, "clock-output-names",
- fschan, &clk_name)) {
- break;
+ if (quadfs->outputs) {
+ clk_name = quadfs->outputs[fschan].name;
+ flags = quadfs->outputs[fschan].flags;
+ } else {
+ if (of_property_read_string_index(np,
+ "clock-output-names",
+ fschan, &clk_name))
+ break;
+ of_clk_detect_critical(np, fschan, &flags);
}
/*
@@ -892,10 +960,8 @@ static void __init st_of_
[PATCH v2 09/16] ARM: dts: sti: update flexgen compatible within stih407-clock
With the introduction of new flexgen compatible within the clk-flexgen
driver, remove the clock-output-names entry from the flexgen nodes
and set the new proper compatible corresponding.
Signed-off-by: Alain Volmat
---
arch/arm/boot/dts/stih407-clock.dtsi | 85 ++--
1 file changed, 6 insertions(+), 79 deletions(-)
diff --git a/arch/arm/boot/dts/stih407-clock.dtsi
b/arch/arm/boot/dts/stih407-clock.dtsi
index 1ab40db7c91a..ecd568777e5f 100644
--- a/arch/arm/boot/dts/stih407-clock.dtsi
+++ b/arch/arm/boot/dts/stih407-clock.dtsi
@@ -83,15 +83,12 @@
};
clk_s_a0_flexgen: clk-s-a0-flexgen {
- compatible = "st,flexgen";
+ compatible = "st,flexgen",
"st,flexgen-stih407-a0";
#clock-cells = <1>;
clocks = <&clk_s_a0_pll 0>,
<&clk_sysin>;
-
- clock-output-names = "clk-ic-lmi0";
- clock-critical = ;
};
};
@@ -134,7 +131,7 @@
clk_s_c0_flexgen: clk-s-c0-flexgen {
#clock-cells = <1>;
- compatible = "st,flexgen";
+ compatible = "st,flexgen",
"st,flexgen-stih407-c0";
clocks = <&clk_s_c0_pll0 0>,
<&clk_s_c0_pll1 0>,
@@ -144,45 +141,6 @@
<&clk_s_c0_quadfs 3>,
<&clk_sysin>;
- clock-output-names = "clk-icn-gpu",
-"clk-fdma",
-"clk-nand",
-"clk-hva",
-"clk-proc-stfe",
-"clk-proc-tp",
-"clk-rx-icn-dmu",
-"clk-rx-icn-hva",
-"clk-icn-cpu",
-"clk-tx-icn-dmu",
-"clk-mmc-0",
-"clk-mmc-1",
-"clk-jpegdec",
-"clk-ext2fa9",
-"clk-ic-bdisp-0",
-"clk-ic-bdisp-1",
-"clk-pp-dmu",
-"clk-vid-dmu",
-"clk-dss-lpc",
-"clk-st231-aud-0",
-"clk-st231-gp-1",
-"clk-st231-dmu",
-"clk-icn-lmi",
-"clk-tx-icn-disp-1",
-"clk-icn-sbc",
-"clk-stfe-frc2",
-"clk-eth-phy",
-"clk-eth-ref-phyclk",
-"clk-flash-promip",
-"clk-main-disp",
-"clk-aux-disp",
-"clk-compo-dvp";
- clock-critical = ,
-,
-,
-,
-,
-;
-
/*
* ARM Peripheral clock for timers
*/
@@ -219,18 +177,13 @@
clk_s_d0_flexgen: clk-s-d0-flexgen {
#clock-cells = <1>;
- compatible = "st,flexgen-audio", "st,flexgen";
+ compatible = "st,flexgen",
"st,flexgen-stih407-d0";
clocks = <&clk_s_d0_quadfs 0>,
<&clk_s_d0_quadfs 1>,
<&clk_s_d0_quadfs 2>,
<&clk_s_d0_quadfs 3>,
<&clk_sysin>;
-
-
[PATCH v2 11/16] ARM: dts: sti: update clkgen-pll entries in stih407-clock
The clkgen-pll driver now embed the clock names (assuming the
right compatible is used). Remove all clock-output-names property
and update when necessary the compatible.
Signed-off-by: Alain Volmat
---
arch/arm/boot/dts/stih407-clock.dtsi | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/stih407-clock.dtsi
b/arch/arm/boot/dts/stih407-clock.dtsi
index ecd568777e5f..2603226a6ca8 100644
--- a/arch/arm/boot/dts/stih407-clock.dtsi
+++ b/arch/arm/boot/dts/stih407-clock.dtsi
@@ -36,8 +36,6 @@
compatible = "st,stih407-clkgen-plla9";
clocks = <&clk_sysin>;
-
- clock-output-names = "clockgen-a9-pll-odf";
};
};
@@ -74,12 +72,9 @@
clk_s_a0_pll: clk-s-a0-pll {
#clock-cells = <1>;
- compatible = "st,clkgen-pll0";
+ compatible = "st,clkgen-pll0-a0";
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-a0-pll-ofd-0";
- clock-critical = <0>; /* clk-s-a0-pll-ofd-0 */
};
clk_s_a0_flexgen: clk-s-a0-flexgen {
@@ -112,21 +107,16 @@
clk_s_c0_pll0: clk-s-c0-pll0 {
#clock-cells = <1>;
- compatible = "st,clkgen-pll0";
+ compatible = "st,clkgen-pll0-c0";
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-c0-pll0-odf-0";
- clock-critical = <0>; /* clk-s-c0-pll0-odf-0 */
};
clk_s_c0_pll1: clk-s-c0-pll1 {
#clock-cells = <1>;
- compatible = "st,clkgen-pll1";
+ compatible = "st,clkgen-pll1-c0";
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-c0-pll1-odf-0";
};
clk_s_c0_flexgen: clk-s-c0-flexgen {
--
2.17.1
Re: [PATCH v2 1/2] leds: rt4505: Add support for Richtek RT4505 flash LED controller
Hi, Jacek: Jacek Anaszewski 於 2020年11月3日 週二 上午4:44寫道： > > Hi ChiYuan, > > On 11/2/20 3:42 AM, cy_huang wrote: > > From: ChiYuan Huang > > > > Add support for RT4505 flash LED controller. It can support up to 1.5A > > flash current with hardware timeout and low input voltage protection. > > > > Signed-off-by: ChiYuan Huang > > --- > > Changes since v1 to v2 > > > > - Create flash directory into drvers/leds. > > - Coding style fix to meet 80 charactors per line limit. > > - Refine the description in the Kconfig help text. > > - Change all descriptions for 'led' text to uppercase 'LED'. > > > > --- > > drivers/leds/Kconfig | 2 + > > drivers/leds/Makefile| 3 + > > drivers/leds/flash/Kconfig | 17 ++ > > drivers/leds/flash/Makefile | 2 + > > drivers/leds/flash/leds-rt4505.c | 430 > > +++ > > 5 files changed, 454 insertions(+) > > create mode 100644 drivers/leds/flash/Kconfig > > create mode 100644 drivers/leds/flash/Makefile > > create mode 100644 drivers/leds/flash/leds-rt4505.c > > Acked-by: Jacek Anaszewski > Any problem with this patch? Do I need to submit it again? > -- > Best regards, > Jacek Anaszewski
[PATCH v2 12/16] ARM: dts: sti: update clkgen-pll entries in stih410-clock
The clkgen-pll driver now embed the clock names (assuming the
right compatible is used). Remove all clock-output-names property
and update when necessary the compatible.
Signed-off-by: Alain Volmat
---
arch/arm/boot/dts/stih410-clock.dtsi | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/stih410-clock.dtsi
b/arch/arm/boot/dts/stih410-clock.dtsi
index 04b0d7080353..3aeabdd6e305 100644
--- a/arch/arm/boot/dts/stih410-clock.dtsi
+++ b/arch/arm/boot/dts/stih410-clock.dtsi
@@ -39,8 +39,6 @@
compatible = "st,stih407-clkgen-plla9";
clocks = <&clk_sysin>;
-
- clock-output-names = "clockgen-a9-pll-odf";
};
};
@@ -74,12 +72,9 @@
clk_s_a0_pll: clk-s-a0-pll {
#clock-cells = <1>;
- compatible = "st,clkgen-pll0";
+ compatible = "st,clkgen-pll0-a0";
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-a0-pll-ofd-0";
- clock-critical = <0>; /* clk-s-a0-pll-ofd-0 */
};
clk_s_a0_flexgen: clk-s-a0-flexgen {
@@ -112,21 +107,16 @@
clk_s_c0_pll0: clk-s-c0-pll0 {
#clock-cells = <1>;
- compatible = "st,clkgen-pll0";
+ compatible = "st,clkgen-pll0-c0";
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-c0-pll0-odf-0";
- clock-critical = <0>; /* clk-s-c0-pll0-odf-0 */
};
clk_s_c0_pll1: clk-s-c0-pll1 {
#clock-cells = <1>;
- compatible = "st,clkgen-pll1";
+ compatible = "st,clkgen-pll1-c0";
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-c0-pll1-odf-0";
};
clk_s_c0_flexgen: clk-s-c0-flexgen {
--
2.17.1
[PATCH v2 14/16] ARM: dts: sti: update clkgen-fsyn entries in stih407-clock
The clkgen-fsyn driver now embed the clock names (assuming the
right compatible is used). Remove all clock-output-names property
and update when necessary the compatible.
Signed-off-by: Alain Volmat
---
arch/arm/boot/dts/stih407-clock.dtsi | 27 +++
1 file changed, 3 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/stih407-clock.dtsi
b/arch/arm/boot/dts/stih407-clock.dtsi
index 2603226a6ca8..9cce9541e26b 100644
--- a/arch/arm/boot/dts/stih407-clock.dtsi
+++ b/arch/arm/boot/dts/stih407-clock.dtsi
@@ -93,12 +93,6 @@
reg = <0x9103000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-c0-fs0-ch0",
-"clk-s-c0-fs0-ch1",
-"clk-s-c0-fs0-ch2",
-"clk-s-c0-fs0-ch3";
- clock-critical = <0>; /* clk-s-c0-fs0-ch0 */
};
clk_s_c0: clockgen-c@9103000 {
@@ -150,15 +144,10 @@
clk_s_d0_quadfs: clk-s-d0-quadfs@9104000 {
#clock-cells = <1>;
- compatible = "st,quadfs";
+ compatible = "st,quadfs-d0";
reg = <0x9104000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-d0-fs0-ch0",
-"clk-s-d0-fs0-ch1",
-"clk-s-d0-fs0-ch2",
-"clk-s-d0-fs0-ch3";
};
clockgen-d0@9104000 {
@@ -179,15 +168,10 @@
clk_s_d2_quadfs: clk-s-d2-quadfs@9106000 {
#clock-cells = <1>;
- compatible = "st,quadfs";
+ compatible = "st,quadfs-d2";
reg = <0x9106000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-d2-fs0-ch0",
-"clk-s-d2-fs0-ch1",
-"clk-s-d2-fs0-ch2",
-"clk-s-d2-fs0-ch3";
};
clockgen-d2@9106000 {
@@ -210,15 +194,10 @@
clk_s_d3_quadfs: clk-s-d3-quadfs@9107000 {
#clock-cells = <1>;
- compatible = "st,quadfs";
+ compatible = "st,quadfs-d3";
reg = <0x9107000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-d3-fs0-ch0",
-"clk-s-d3-fs0-ch1",
-"clk-s-d3-fs0-ch2",
-"clk-s-d3-fs0-ch3";
};
clockgen-d3@9107000 {
--
2.17.1
[PATCH v2 13/16] ARM: dts: sti: update clkgen-pll entries in stih418-clock
The clkgen-pll driver now embed the clock names (assuming the
right compatible is used). Remove all clock-output-names property
and update when necessary the compatible.
Signed-off-by: Alain Volmat
---
arch/arm/boot/dts/stih418-clock.dtsi | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/stih418-clock.dtsi
b/arch/arm/boot/dts/stih418-clock.dtsi
index 35d12979cdf4..d628e656458d 100644
--- a/arch/arm/boot/dts/stih418-clock.dtsi
+++ b/arch/arm/boot/dts/stih418-clock.dtsi
@@ -39,8 +39,6 @@
compatible = "st,stih418-clkgen-plla9";
clocks = <&clk_sysin>;
-
- clock-output-names = "clockgen-a9-pll-odf";
};
};
@@ -75,11 +73,9 @@
clk_s_a0_pll: clk-s-a0-pll {
#clock-cells = <1>;
- compatible = "st,clkgen-pll0";
+ compatible = "st,clkgen-pll0-a0";
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-a0-pll-ofd-0";
};
clk_s_a0_flexgen: clk-s-a0-flexgen {
@@ -111,20 +107,16 @@
clk_s_c0_pll0: clk-s-c0-pll0 {
#clock-cells = <1>;
- compatible = "st,clkgen-pll0";
+ compatible = "st,clkgen-pll0-c0";
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-c0-pll0-odf-0";
};
clk_s_c0_pll1: clk-s-c0-pll1 {
#clock-cells = <1>;
- compatible = "st,clkgen-pll1";
+ compatible = "st,clkgen-pll1-c0";
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-c0-pll1-odf-0";
};
clk_s_c0_flexgen: clk-s-c0-flexgen {
--
2.17.1
[PATCH v2 15/16] ARM: dts: sti: update clkgen-fsyn entries in stih410-clock
The clkgen-fsyn driver now embed the clock names (assuming the
right compatible is used). Remove all clock-output-names property
and update when necessary the compatible.
Signed-off-by: Alain Volmat
---
arch/arm/boot/dts/stih410-clock.dtsi | 27 +++
1 file changed, 3 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/stih410-clock.dtsi
b/arch/arm/boot/dts/stih410-clock.dtsi
index 3aeabdd6e305..6b0e6d4477a3 100644
--- a/arch/arm/boot/dts/stih410-clock.dtsi
+++ b/arch/arm/boot/dts/stih410-clock.dtsi
@@ -93,12 +93,6 @@
reg = <0x9103000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-c0-fs0-ch0",
-"clk-s-c0-fs0-ch1",
-"clk-s-c0-fs0-ch2",
-"clk-s-c0-fs0-ch3";
- clock-critical = <0>; /* clk-s-c0-fs0-ch0 */
};
clk_s_c0: clockgen-c@9103000 {
@@ -150,15 +144,10 @@
clk_s_d0_quadfs: clk-s-d0-quadfs@9104000 {
#clock-cells = <1>;
- compatible = "st,quadfs";
+ compatible = "st,quadfs-d0";
reg = <0x9104000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-d0-fs0-ch0",
-"clk-s-d0-fs0-ch1",
-"clk-s-d0-fs0-ch2",
-"clk-s-d0-fs0-ch3";
};
clockgen-d0@9104000 {
@@ -179,15 +168,10 @@
clk_s_d2_quadfs: clk-s-d2-quadfs@9106000 {
#clock-cells = <1>;
- compatible = "st,quadfs";
+ compatible = "st,quadfs-d2";
reg = <0x9106000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-d2-fs0-ch0",
-"clk-s-d2-fs0-ch1",
-"clk-s-d2-fs0-ch2",
-"clk-s-d2-fs0-ch3";
};
clockgen-d2@9106000 {
@@ -210,15 +194,10 @@
clk_s_d3_quadfs: clk-s-d3-quadfs@9107000 {
#clock-cells = <1>;
- compatible = "st,quadfs";
+ compatible = "st,quadfs-d3";
reg = <0x9107000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-d3-fs0-ch0",
-"clk-s-d3-fs0-ch1",
-"clk-s-d3-fs0-ch2",
-"clk-s-d3-fs0-ch3";
};
clockgen-d3@9107000 {
--
2.17.1
Re: [PATCH] KVM: x86/vPMU: Forbid writing to MSR_F15H_PERF MSRs when guest doesn't have X86_FEATURE_PERFCTR_CORE
On Tue, Mar 23, 2021 at 4:48 PM Vitaly Kuznetsov wrote: > > MSR_F15H_PERF_CTL0-5, MSR_F15H_PERF_CTR0-5 MSRs are only available when > X86_FEATURE_PERFCTR_CORE CPUID bit was exposed to the guest. KVM, however, > allows these MSRs unconditionally because kvm_pmu_is_valid_msr() -> > amd_msr_idx_to_pmc() check always passes and because kvm_pmu_set_msr() -> > amd_pmu_set_msr() doesn't fail. > > In case of a counter (CTRn), no big harm is done as we only increase > internal PMC's value but in case of an eventsel (CTLn), we go deep into > perf internals with a non-existing counter. > > Note, kvm_get_msr_common() just returns '0' when these MSRs don't exist > and this also seems to contradict architectural behavior which is #GP > (I did check one old Opteron host) but changing this status quo is a bit > scarier. When msr doesn't exist, kvm_get_msr_common() returns KVM_MSR_RET_INVALID in `default:` and kvm_complete_insn_gp() will inject #GP to guest. Also i have wrote a kvm-unit-test, tested both on amd EPYC and intel CascadeLake. A #GP error was printed. Just like: Unhandled exception 13 #GP at ip 00400420 error_code= rflags=00010006 cs=0008 rax= rcx=0620 rdx=006164a0 rbx=9500 rbp=00517490 rsi=00616ae0 rdi=0001 r8=0001 r9=03f8 r10=000d r11= r12= r13= r14= r15= cr0=8011 cr2= cr3=0040b000 cr4=0020 cr8= STACK: @400420 400338
[PATCH v2 16/16] ARM: dts: sti: update clkgen-fsyn entries in stih418-clock
The clkgen-fsyn driver now embed the clock names (assuming the
right compatible is used). Remove all clock-output-names property
and update when necessary the compatible.
Signed-off-by: Alain Volmat
---
arch/arm/boot/dts/stih418-clock.dtsi | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/arch/arm/boot/dts/stih418-clock.dtsi
b/arch/arm/boot/dts/stih418-clock.dtsi
index d628e656458d..e84c476b83ed 100644
--- a/arch/arm/boot/dts/stih418-clock.dtsi
+++ b/arch/arm/boot/dts/stih418-clock.dtsi
@@ -94,11 +94,6 @@
reg = <0x9103000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-c0-fs0-ch0",
-"clk-s-c0-fs0-ch1",
-"clk-s-c0-fs0-ch2",
-"clk-s-c0-fs0-ch3";
};
clk_s_c0: clockgen-c@9103000 {
@@ -150,15 +145,10 @@
clk_s_d0_quadfs: clk-s-d0-quadfs@9104000 {
#clock-cells = <1>;
- compatible = "st,quadfs";
+ compatible = "st,quadfs-d0";
reg = <0x9104000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-d0-fs0-ch0",
-"clk-s-d0-fs0-ch1",
-"clk-s-d0-fs0-ch2",
-"clk-s-d0-fs0-ch3";
};
clockgen-d0@9104000 {
@@ -179,15 +169,10 @@
clk_s_d2_quadfs: clk-s-d2-quadfs@9106000 {
#clock-cells = <1>;
- compatible = "st,quadfs";
+ compatible = "st,quadfs-d2";
reg = <0x9106000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-d2-fs0-ch0",
-"clk-s-d2-fs0-ch1",
-"clk-s-d2-fs0-ch2",
-"clk-s-d2-fs0-ch3";
};
clockgen-d2@9106000 {
@@ -210,15 +195,10 @@
clk_s_d3_quadfs: clk-s-d3-quadfs@9107000 {
#clock-cells = <1>;
- compatible = "st,quadfs";
+ compatible = "st,quadfs-d3";
reg = <0x9107000 0x1000>;
clocks = <&clk_sysin>;
-
- clock-output-names = "clk-s-d3-fs0-ch0",
-"clk-s-d3-fs0-ch1",
-"clk-s-d3-fs0-ch2",
-"clk-s-d3-fs0-ch3";
};
clockgen-d3@9107000 {
--
2.17.1
RE: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back
> -Original Message- > From: Jon Hunter > Sent: 2021年3月24日 20:39 > To: Joakim Zhang > Cc: net...@vger.kernel.org; Linux Kernel Mailing List > ; linux-tegra ; > Jakub Kicinski > Subject: Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac > resume back > > > > On 24/03/2021 12:20, Joakim Zhang wrote: > > ... > > > Sorry for this breakage at your side. > > > > You mean one of your boards? Does other boards with STMMAC can work > fine? > > We have two devices with the STMMAC and one works OK and the other fails. > They are different generation of device and so there could be some > architectural differences which is causing this to only be seen on one device. It's really strange, but I also don't know what architectural differences could affect this. Sorry. > > We do daily test with NFS to mount rootfs, on issue found. And I add this > patch at the resume patch, and on error check, this should not break suspend. > > I even did the overnight stress test, there is no issue found. > > > > Could you please do more test to see where the issue happen? > > The issue occurs 100% of the time on the failing board and always on the first > resume from suspend. Is there any more debug I can enable to track down > what the problem is? > As commit messages described, the patch aims to re-init rx buffers address, since the address is not fixed, so I only can recycle and then re-allocate all of them. The page pool is allocated once when open the net device. Could you please debug if it fails at some functions, such as page_pool_dev_alloc_pages() ? Best Regards, Joakim Zhang > Jon > > -- > nvpublic
RE: [PATCH v5 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy
Hi Hans.
> -Original Message-
> From: Hans de Goede
> Sent: Wednesday, March 24, 2021 3:40 AM
> To: Pierre-Louis Bossart; Yuan, Perry; po...@protonmail.com;
> oder_ch...@realtek.com; pe...@perex.cz; ti...@suse.com;
> mgr...@linux.intel.com; Limonciello, Mario
> Cc: alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org;
> lgirdw...@gmail.com; platform-driver-...@vger.kernel.org;
> broo...@kernel.org
> Subject: Re: [PATCH v5 1/2] platform/x86: dell-privacy: Add support for Dell
> hardware privacy
>
>
> [EXTERNAL EMAIL]
>
> Hi,
>
> On 3/23/21 7:57 PM, Pierre-Louis Bossart wrote:
> > Minor comments below.
>
>
> >> +int __init dell_privacy_acpi_init(void)
> >
> > is the __init necessary? You call this routine from another which already
> > has
> this qualifier.
>
> Yes this is necessary, all functions which are only used during module_load /
> from the module's init function must be marked as __init so that the kernel
> can unload them after module loading is done.
>
> I do wonder if this one should not be static though (I've not looked at this
> patch in detail yet).
>
> >
> >> +{
> >> + int err;
> >> + struct platform_device *pdev;
> >> +
> >> + if (!wmi_has_guid(DELL_PRIVACY_GUID))
> >> + return -ENODEV;
> >> +
> >> + privacy_acpi = kzalloc(sizeof(*privacy_acpi), GFP_KERNEL);
> >> + if (!privacy_acpi)
> >> + return -ENOMEM;
> >> +
> >> + err = platform_driver_register(&dell_privacy_platform_drv);
> >> + if (err)
> >> + goto pdrv_err;
> >> +
> >> + pdev = platform_device_register_simple(
> >> + PRIVACY_PLATFORM_NAME, PLATFORM_DEVID_NONE, NULL, 0);
> >> + if (IS_ERR(pdev)) {
> >> + err = PTR_ERR(pdev);
> >> + goto pdev_err;
> >> + }
> >> +
> >> + return 0;
> >> +
> >> +pdev_err:
> >> + platform_device_unregister(pdev);
> >> +pdrv_err:
> >> + kfree(privacy_acpi);
> >> + return err;
> >> +}
> >> +
> >> +void __exit dell_privacy_acpi_exit(void)
> >
> > is the __exit required here?
>
> Idem. Also static ?
>
> Regards,
>
> Hans
>
If adding static to the function, I will be worried about that the init and
exit cannot be called by another file .
>
>
> >
> >> +{
> >> + struct platform_device *pdev =
> >> +to_platform_device(privacy_acpi->dev);
> >> +
> >> + platform_device_unregister(pdev);
> >> + platform_driver_unregister(&dell_privacy_platform_drv);
> >> + kfree(privacy_acpi);
> >> +}
> >> +
> >> +MODULE_AUTHOR("Perry Yuan ");
> >> +MODULE_DESCRIPTION("DELL Privacy ACPI Driver");
> >> +MODULE_LICENSE("GPL");
> >
> >
Re: [PATCH 0/3] Apple M1 DART IOMMU driver
On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote: > On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote: > > > Date: Sat, 20 Mar 2021 15:19:33 + > > > From: Sven Peter > > > I have just noticed today though that at least the USB DWC3 controller in > > > host > > > mode uses *two* darts at the same time. I'm not sure yet which parts seem > > > to > > > require which DART instance. > > > > > > This means that we might need to support devices attached to two iommus > > > simultaneously and just create the same iova mappings. Currently this only > > > seems to be required for USB according to Apple's Device Tree. > > > > > > I see two options for this and would like to get feedback before > > > I implement either one: > > > > > > 1) Change #iommu-cells = <1>; to #iommu-cells = <2>; and use the > > > first cell > > >to identify the DART and the second one to identify the master. > > >The DART DT node would then also take two register ranges that > > > would > > >correspond to the two DARTs. Both instances use the same IRQ and > > > the > > >same clocks according to Apple's device tree and my experiments. > > >This would keep a single device node and the DART driver would then > > >simply map iovas in both DARTs if required. > > > > > > 2) Keep #iommu-cells as-is but support > > > iommus = <&usb_dart1a 1>, <&usb_dart1b 0>; > > >instead. > > >This would then require two devices nodes for the two DART > > > instances and > > >some housekeeping in the DART driver to support mapping iovas in > > > both > > >DARTs. > > >I believe omap-iommu.c supports this setup but I will have to read > > >more code to understand the details there and figure out how to > > > implement > > >this in a sane way. > > > > > > I currently prefer the first option but I don't understand enough details > > > of > > > the iommu system to actually make an informed decision. > > Please don't mix what does the h/w look like and what's easy to > implement in Linux's IOMMU subsytem. It's pretty clear (at least > from the description here) that option 2 reflects the h/w. > Good point, I'll keep that in mind and give option 2 a try. > > > > As I mentioned before, not all DARTs support the full 32-bit aperture. > > In particular the PCIe DARTs support a smaller address-space. It is > > not clear whether this is a restriction of the PCIe host controller or > > the DART, but the Apple Device Tree has "vm-base" and "vm-size" > > properties that encode the base address and size of the aperture. > > These single-cell properties which is probably why for the USB DARTs > > only "vm-base" is given; since "vm-base" is 0, a 32-bit number > > wouldn't be able to encode the full aperture size. We could make them > > 64-bit numbers in the Linux device tree though and always be explicit > > about the size. Older Sun SPARC machines used a single "virtual-dma" > > property to encode the aperture. We could do someting similar. You > > would use this property to initialize domain->geometry.aperture_start > > and domain->geometry.aperture_end in diff 3/3 of this series. > > 'dma-ranges' is what should be used here. > The iommu binding documentation [1] mentions that The device tree node of the IOMMU device's parent bus must contain a valid "dma-ranges" property that describes how the physical address space of the IOMMU maps to memory. An empty "dma-ranges" property means that there is a 1:1 mapping from IOMMU to memory. which, if I understand this correctly, means that the 'dma-ranges' for the parent bus of the iommu should be empty since the DART hardware can see the full physical address space with a 1:1 mapping. The documentation also mentions that When an "iommus" property is specified in a device tree node, the IOMMU will be used for address translation. If a "dma-ranges" property exists in the device's parent node it will be ignored. which means that specifying a 'dma-ranges' in the parent bus of any devices that use the iommu will just be ignored. As a concrete example, the PCIe DART IOMMU only allows translations from iovas within 0x0010...0x3ff0 to the entire physical address space (though realistically it will only map to 16GB RAM starting at 0x8 on the M1). I'm probably just confused or maybe the documentation is outdated but I don't see how I could specify "this device can only use DMA addresses from 0x0010...0x3ff0 but can map these via the iommu to any physical address" using 'dma-ranges'. Could you maybe point me to the right direction or give me a small example? That would help a lot! Thanks, Sven [1] Documentation/devicetree/bindings/iommu/iommu.txt
Re: [PATCH v3 06/10] pinctrl: Ingenic: Add pinctrl driver for JZ4730.
On 2021/3/23 上午2:17, Paul Cercueil wrote:
Le mer. 17 mars 2021 à 17:58, 周琰杰 (Zhou Yanjie)
a écrit :
Add support for probing the pinctrl-ingenic driver on the
JZ4730 SoC from Ingenic.
This driver is derived from Paul Boddie. It is worth to
noting that the JZ4730 SoC is special in having two control
registers (upper/lower), so add code to handle the JZ4730
specific register offsets and some register pairs which have
2 bits for each GPIO pin.
Tested-by: H. Nikolaus Schaller # on Letux400
Co-developed-by: Paul Boddie
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
Signed-off-by: 周琰杰 (Zhou Yanjie)
---
Notes:
v3:
New patch.
drivers/pinctrl/pinctrl-ingenic.c | 222
+++---
1 file changed, 206 insertions(+), 16 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index b8165f5..25458d6 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -3,8 +3,8 @@
* Ingenic SoCs pinctrl driver
*
* Copyright (c) 2017 Paul Cercueil
- * Copyright (c) 2019 周琰杰 (Zhou Yanjie)
* Copyright (c) 2017, 2019 Paul Boddie
+ * Copyright (c) 2019, 2020 周琰杰 (Zhou Yanjie)
*/
#include
@@ -29,6 +29,17 @@
#define GPIO_PIN 0x00
#define GPIO_MSK 0x20
+#define JZ4730_GPIO_DATA 0x00
+#define JZ4730_GPIO_GPDIR 0x04
+#define JZ4730_GPIO_GPPUR 0x0c
+#define JZ4730_GPIO_GPALR 0x10
+#define JZ4730_GPIO_GPAUR 0x14
+#define JZ4730_GPIO_GPIDLR 0x18
+#define JZ4730_GPIO_GPIDUR 0x1c
+#define JZ4730_GPIO_GPIER 0x20
+#define JZ4730_GPIO_GPIMR 0x24
+#define JZ4730_GPIO_GPFR 0x28
+
#define JZ4740_GPIO_DATA 0x10
#define JZ4740_GPIO_PULL_DIS 0x30
#define JZ4740_GPIO_FUNC 0x40
@@ -57,6 +68,7 @@
#define GPIO_PULL_DOWN 2
#define PINS_PER_GPIO_CHIP 32
+#define JZ4730_PINS_PER_PAIRED_REG 16
#define INGENIC_PIN_GROUP_FUNCS(name, id, funcs) \
{ \
@@ -70,6 +82,7 @@
INGENIC_PIN_GROUP_FUNCS(name, id, (void *)(func))
enum jz_version {
+ ID_JZ4730,
ID_JZ4740,
ID_JZ4725B,
ID_JZ4760,
@@ -110,6 +123,96 @@ struct ingenic_gpio_chip {
unsigned int irq, reg_base;
};
+static const u32 jz4730_pull_ups[4] = {
+ 0x3fa3320f, 0xf200, 0x, 0x,
+};
+
+static const u32 jz4730_pull_downs[4] = {
+ 0x0df0, 0x0dff, 0x, 0x,
+};
+
+static int jz4730_mmc_1bit_pins[] = { 0x27, 0x26, 0x22, };
+static int jz4730_mmc_4bit_pins[] = { 0x23, 0x24, 0x25, };
+static int jz4730_uart0_data_pins[] = { 0x7e, 0x7f, };
+static int jz4730_uart1_data_pins[] = { 0x18, 0x19, };
+static int jz4730_uart2_data_pins[] = { 0x6f, 0x7d, };
+static int jz4730_uart3_data_pins[] = { 0x10, 0x15, };
+static int jz4730_uart3_hwflow_pins[] = { 0x11, 0x17, };
+static int jz4730_lcd_8bit_pins[] = {
+ 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x3a, 0x39, 0x38,
+};
+static int jz4730_lcd_16bit_pins[] = {
+ 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x3b,
+};
+static int jz4730_lcd_16bit_tft_pins[] = { 0x3e, 0x3f, 0x3d, 0x3c, };
+static int jz4730_nand_cs1_pins[] = { 0x53, };
+static int jz4730_nand_cs2_pins[] = { 0x54, };
+static int jz4730_nand_cs3_pins[] = { 0x55, };
+static int jz4730_nand_cs4_pins[] = { 0x56, };
+static int jz4730_nand_cs5_pins[] = { 0x57, };
+static int jz4730_pwm_pwm0_pins[] = { 0x5e, };
+static int jz4730_pwm_pwm1_pins[] = { 0x5f, };
+
+static u8 jz4730_lcd_8bit_funcs[] = { 1, 1, 1, 1, 1, 1, 1, 1, 2, 2,
2, };
+
+static const struct group_desc jz4730_groups[] = {
+ INGENIC_PIN_GROUP("mmc-1bit", jz4730_mmc_1bit, 1),
+ INGENIC_PIN_GROUP("mmc-4bit", jz4730_mmc_4bit, 1),
+ INGENIC_PIN_GROUP("uart0-data", jz4730_uart0_data, 1),
+ INGENIC_PIN_GROUP("uart1-data", jz4730_uart1_data, 1),
+ INGENIC_PIN_GROUP("uart2-data", jz4730_uart2_data, 1),
+ INGENIC_PIN_GROUP("uart3-data", jz4730_uart3_data, 1),
+ INGENIC_PIN_GROUP("uart3-hwflow", jz4730_uart3_hwflow, 1),
+ INGENIC_PIN_GROUP_FUNCS("lcd-8bit", jz4730_lcd_8bit,
jz4730_lcd_8bit_funcs),
+ INGENIC_PIN_GROUP("lcd-16bit", jz4730_lcd_16bit, 1),
+ INGENIC_PIN_GROUP("lcd-16bit-tft", jz4730_lcd_16bit_tft, 1),
+ INGENIC_PIN_GROUP("nand-cs1", jz4730_nand_cs1, 1),
+ INGENIC_PIN_GROUP("nand-cs2", jz4730_nand_cs2, 1),
+ INGENIC_PIN_GROUP("nand-cs3", jz4730_nand_cs3, 1),
+ INGENIC_PIN_GROUP("nand-cs4", jz4730_nand_cs4, 1),
+ INGENIC_PIN_GROUP("nand-cs5", jz4730_nand_cs5, 1),
+ INGENIC_PIN_GROUP("pwm0", jz4730_pwm_pwm0, 1),
+ INGENIC_PIN_GROUP("pwm1", jz4730_pwm_pwm1, 1),
+};
+
+static const char *jz4730_mmc_groups[] = { "mmc-1bit", "mmc-4bit", };
+static const char *jz4730_uart0_groups[] = { "uart0-data", };
+static const char *jz4730_uart1_groups[] = { "uart1-data", };
+static const char *jz4730_uart2_groups[] = {
linux-next: Tree for Mar 25
Hi all, Changes since 20210324: The fscache tree gained a conflict against Linus' tree. The akpm-current tree still had its its build failure. Non-merge commits (relative to Linus' tree): 6524 6315 files changed, 396627 insertions(+), 135053 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 335 trees (counting Linus' and 87 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (4ee998b0ef8b Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux) Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2) Merging kbuild-current/fixes (bcbcf50f5218 kbuild: fix ld-version.sh to not be affected by locale) Merging arc-current/for-curr (83520d62cc5a ARC: treewide: avoid the pointer addition with NULL pointer) Merging arm-current/fixes (a38fd8748464 Linux 5.12-rc2) Merging arm64-fixes/for-next/fixes (7011d72588d1 kselftest/arm64: sve: Do not use non-canonical FFR register value) Merging arm-soc-fixes/arm/fixes (67335b8d28cd Merge tag 'imx-fixes-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes) Merging drivers-memory-fixes/fixes (a38fd8748464 Linux 5.12-rc2) Merging m68k-current/for-linus (a65a802aadba m68k: Fix virt_addr_valid() W=1 compiler warnings) Merging powerpc-fixes/fixes (274cb1ca2e7c powerpc/pseries/mobility: handle premature return from H_JOIN) Merging s390-fixes/fixes (0d02ec6b3136 Linux 5.12-rc4) Merging sparc/master (05a59d79793d Merge git://git.kernel.org:/pub/scm/linux/kernel/git/netdev/net) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (6f235a69e594 ch_ktls: fix enum-conversion warning) Merging bpf/master (87d77e59d1eb docs: networking: Fix a typo) Merging ipsec/master (154deab6a3ba esp: delete NETIF_F_SCTP_CRC bit from features for esp offload) CONFLICT (content): Merge conflict in net/ipv6/ip6_vti.c CONFLICT (content): Merge conflict in net/ipv4/ip_vti.c Merging netfilter/master (6ab4c3117aec net: bridge: don't notify switchdev for local FDB addresses) Merging ipvs/master (b58f33d49e42 netfilter: ctnetlink: fix dump of the expect mask attribute) Merging wireless-drivers/master (bd83a2fc05ed brcmfmac: p2p: Fix recently introduced deadlock issue) Merging mac80211/master (6f235a69e594 ch_ktls: fix enum-conversion warning) Merging rdma-fixes/for-rc (af06b628a6bd RDMA/hns: Fix bug during CMDQ initialization) Merging sound-current/for-linus (e54f30befa79 ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook) Merging sound-asoc-fixes/for-linus (3fcef2d205f9 Merge remote-tracking branch 'asoc/for-5.12' into asoc-linus) Merging regmap-fixes/for-linus (f29fd6d5a08d Merge remote-tracking branch 'regmap/for-5.12' into regmap-linus) Merging regulator-fixes/for-linus (595bd434897b Merge remote-tracking branch 'regulator/for-5.12' into regulator-linus) Merging spi-fixes/for-linus (e5d94e0160f7 Merge remote-tracking branch 'spi/for-5.12' into spi-linus) Merging pci-current/for-linus (fd4162f05194 PCI: dwc: Move iATU detection earlier) Merging driver-core.current/driver-core-linus (f0acf637d60f driver core: clear deferred probe reason on probe retry) Merging tty.current/tty-linus (1e28eed17697 Linux 5.12-rc3) Merging usb.current/usb-
[PATCH net-next 0/2] net: gve: make cleanup for gve
This patch set replace deprecated strlcpy by strscpy, remove repeat word "allowed" in gve driver. for more details, please refer to each patch. Daode Huang (2): net: gve: convert strlcpy to strscpy net: gve: remove duplicated allowed drivers/net/ethernet/google/gve/gve_ethtool.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.8.1
[PATCH net-next 2/2] net: gve: remove duplicated allowed
fix the WARNING of Possible repeated word: 'allowed' Signed-off-by: Daode Huang --- drivers/net/ethernet/google/gve/gve_ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/google/gve/gve_ethtool.c b/drivers/net/ethernet/google/gve/gve_ethtool.c index e40e052..5fb05cf 100644 --- a/drivers/net/ethernet/google/gve/gve_ethtool.c +++ b/drivers/net/ethernet/google/gve/gve_ethtool.c @@ -388,7 +388,7 @@ static int gve_set_channels(struct net_device *netdev, gve_get_channels(netdev, &old_settings); - /* Changing combined is not allowed allowed */ + /* Changing combined is not allowed */ if (cmd->combined_count != old_settings.combined_count) return -EINVAL; -- 2.8.1
[PATCH] [v3] drivers: staging: _adapter is declared twice
struct _adapter has been declared at 23rd line.
Remove the duplicate.
Signed-off-by: Wan Jiabing
---
Changelog:
v3:
- Delete trailing whitespace.
v2:
- Delete the blank line.
---
drivers/staging/rtl8712/drv_types.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index 0c4325073c63..a44d04effc8b 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -36,8 +36,6 @@ enum _NIC_VERSION {
RTL8716_NIC
};
-struct _adapter;
-
struct qos_priv{
/* bit mask option: u-apsd, s-apsd, ts, block ack... */
unsigned int qos_option;
--
2.25.1
Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back
On 25/03/2021 07:53, Joakim Zhang wrote: > >> -Original Message- >> From: Jon Hunter >> Sent: 2021年3月24日 20:39 >> To: Joakim Zhang >> Cc: net...@vger.kernel.org; Linux Kernel Mailing List >> ; linux-tegra ; >> Jakub Kicinski >> Subject: Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac >> resume back >> >> >> >> On 24/03/2021 12:20, Joakim Zhang wrote: >> >> ... >> >>> Sorry for this breakage at your side. >>> >>> You mean one of your boards? Does other boards with STMMAC can work >> fine? >> >> We have two devices with the STMMAC and one works OK and the other fails. >> They are different generation of device and so there could be some >> architectural differences which is causing this to only be seen on one >> device. > It's really strange, but I also don't know what architectural differences > could affect this. Sorry. Maybe caching somewhere? In other words, could there be any cache flushing that we are missing here? >>> We do daily test with NFS to mount rootfs, on issue found. And I add this >> patch at the resume patch, and on error check, this should not break suspend. >>> I even did the overnight stress test, there is no issue found. >>> >>> Could you please do more test to see where the issue happen? >> >> The issue occurs 100% of the time on the failing board and always on the >> first >> resume from suspend. Is there any more debug I can enable to track down >> what the problem is? >> > > As commit messages described, the patch aims to re-init rx buffers address, > since the address is not fixed, so I only can > recycle and then re-allocate all of them. The page pool is allocated once > when open the net device. > > Could you please debug if it fails at some functions, such as > page_pool_dev_alloc_pages() ? Yes that was the first thing I tried, but no obvious failures from allocating the pools. Are you certain that the problem you are seeing, that is being fixed by this change, is generic to all devices? The commit message states that 'descriptor write back by DMA could exhibit unusual behavior', is this a known issue in the STMMAC controller? If so does this impact all versions and what is the actual problem? Jon -- nvpublic
[PATCH net-next 1/2] net: gve: convert strlcpy to strscpy
Usage of strlcpy in linux kernel has been recently deprecated[1], so
convert gve driver to strscpy
[1] https://lore.kernel.org/lkml/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL
=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Daode Huang
---
drivers/net/ethernet/google/gve/gve_ethtool.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve_ethtool.c
b/drivers/net/ethernet/google/gve/gve_ethtool.c
index 0901fa6..e40e052 100644
--- a/drivers/net/ethernet/google/gve/gve_ethtool.c
+++ b/drivers/net/ethernet/google/gve/gve_ethtool.c
@@ -14,9 +14,9 @@ static void gve_get_drvinfo(struct net_device *netdev,
{
struct gve_priv *priv = netdev_priv(netdev);
- strlcpy(info->driver, "gve", sizeof(info->driver));
- strlcpy(info->version, gve_version_str, sizeof(info->version));
- strlcpy(info->bus_info, pci_name(priv->pdev), sizeof(info->bus_info));
+ strscpy(info->driver, "gve", sizeof(info->driver));
+ strscpy(info->version, gve_version_str, sizeof(info->version));
+ strscpy(info->bus_info, pci_name(priv->pdev), sizeof(info->bus_info));
}
static void gve_set_msglevel(struct net_device *netdev, u32 value)
--
2.8.1
Re: [PATCH 0/3] Apple M1 DART IOMMU driver
Hi Robin, On Wed, Mar 24, 2021, at 16:29, Robin Murphy wrote: > On 2021-03-20 15:19, Sven Peter wrote: > > > > I have just noticed today though that at least the USB DWC3 controller in > > host > > mode uses *two* darts at the same time. I'm not sure yet which parts seem to > > require which DART instance. > > > > This means that we might need to support devices attached to two iommus > > simultaneously and just create the same iova mappings. Currently this only > > seems to be required for USB according to Apple's Device Tree. > > > > I see two options for this and would like to get feedback before > > I implement either one: > > > > 1) Change #iommu-cells = <1>; to #iommu-cells = <2>; and use the first > > cell > > to identify the DART and the second one to identify the master. > > The DART DT node would then also take two register ranges that would > > correspond to the two DARTs. Both instances use the same IRQ and the > > same clocks according to Apple's device tree and my experiments. > > This would keep a single device node and the DART driver would then > > simply map iovas in both DARTs if required. > > This is broadly similar to the approach used by rockchip-iommu and the > special arm-smmu-nvidia implementation, where there are multiple > instances which require programming identically, that are abstracted > behind a single "device". Your case is a little different since you're > not programming both *entirely* identically, although maybe that's a > possibility if each respective ID isn't used by anything else on the > "other" DART? That would be possible. The only difference is that I need to program ID 0 of the first DART and ID 1 of the second one. Both of these IDs are only connected to the same USB controller. > > Overall I tend to view this approach as a bit of a hack because it's not > really describing the hardware truthfully - just because two distinct > functional blocks have their IRQ lines wired together doesn't suddenly > make them a single monolithic block with multiple interfaces - and tends > to be done for the sake of making the driver implementation easier in > terms of the Linux IOMMU API (which, note, hasn't evolved all that far > from its PCI-centric origins and isn't exactly great for arbitrary SoC > topologies). Yes, the easier driver implementation was my reason to favour this option. > > > 2) Keep #iommu-cells as-is but support > > iommus = <&usb_dart1a 1>, <&usb_dart1b 0>; > > instead. > > This would then require two devices nodes for the two DART > > instances and > > some housekeeping in the DART driver to support mapping iovas in > > both > > DARTs. > > I believe omap-iommu.c supports this setup but I will have to read > > more code to understand the details there and figure out how to > > implement > > this in a sane way. > > This approach is arguably the most honest, and more robust in terms of > making fewer assumptions, and is used by at least exynos-iommu and > omap-iommu. In Linux it currently takes a little bit more housekeeping > to keep track of linked instances within the driver since the IOMMU API > holds the notion that any given client device is associated with "an > IOMMU", but that's always free to change at any time, unlike the design > of a DT binding. Sounds good. I'll read those drivers and give it a try for v2. Thanks, Sven
[PATCH V2 0/5] Add driver support for Data Capture and Compare Engine(DCC) for SM8150
DCC(Data Capture and Compare) is a DMA engine designed for debugging purposes.In case of a system crash or manual software triggers by the user the DCC hardware stores the value at the register addresses which can be used for debugging purposes.The DCC driver provides the user with sysfs interface to configure the register addresses.The options that the DCC hardware provides include reading from registers,writing to registers,first reading and then writing to registers and looping through the values of the same register. In certain cases a register write needs to be executed for accessing the rest of the registers, also the user might want to record the changing values of a register with time for which he has the option to use the loop feature. The options mentioned above are exposed to the user by sysfs files once the driver is probed.The details and usage of this sysfs files are documented in Documentation/ABI/testing/sysfs-driver-dcc. As an example let us consider a couple of debug scenarios where DCC has been proved to be effective for debugging purposes:- i)TimeStamp Related Issue On SC7180, there was a coresight timestamp issue where it would occasionally be all 0 instead of proper timestamp values. Proper timestamp: Idx:3373; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x13004d8f5b7aa; CC=0x9e Zero timestamp: Idx:3387; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x0; CC=0xa2 Now this is a non-fatal issue and doesn't need a system reset, but still needs to be rootcaused and fixed for those who do care about coresight etm traces. Since this is a timestamp issue, we would be looking for any timestamp related clocks and such. o we get all the clk register details from IP documentation and configure it via DCC config syfs node. Before that we set the current linked list. /* Set the current linked list */ echo 3 > /sys/bus/platform/devices/10a2000.dcc/curr_list /* Program the linked list with the addresses */ echo 0x10c004 > /sys/bus/platform/devices/10a2000.dcc/config echo 0x10c008 > /sys/bus/platform/devices/10a2000.dcc/config echo 0x10c00c > /sys/bus/platform/devices/10a2000.dcc/config echo 0x10c010 > /sys/bus/platform/devices/10a2000.dcc/config . and so on for other timestamp related clk registers /* Other way of specifying is in "addr len" pair, in below case it specifies to capture 4 words starting 0x10C004 */ echo 0x10C004 4 > /sys/bus/platform/devices/10a2000.dcc/config /* Enable DCC */ echo 1 > /sys/bus/platform/devices/10a2000.dcc/enable /* Run the timestamp test for working case */ /* Send SW trigger */ echo 1 > /sys/bus/platform/devices/10a2000.dcc/trigger /* Read SRAM */ cat /dev/dcc_sram > dcc_sram1.bin /* Run the timestamp test for non-working case */ /* Send SW trigger */ echo 1 > /sys/bus/platform/devices/10a2000.dcc/trigger /* Read SRAM */ cat /dev/dcc_sram > dcc_sram2.bin Get the parser from [1] and checkout the latest branch. /* Parse the SRAM bin */ python dcc_parser.py -s dcc_sram1.bin --v2 -o output/ python dcc_parser.py -s dcc_sram2.bin --v2 -o output/ Sample parsed output of dcc_sram1.bin: 03/14/21 Linux DCC Parser next_ll_offset : 0x1c ii)NOC register errors A particular class of registers called NOC which are functional registers was reporting errors while logging the values.To trace these errors the DCC has been used effectively. The steps followed were similar to the ones mentioned above. In addition to NOC registers a few other dependent registers were configured in DCC to monitor it's values during a crash. A look at the dependent register values revealed that the crash was happening due to a secured access to one of these dependent registers. All these debugging activity and finding the root cause was achieved using DCC. DCC parser is available at the following open source location https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools/tree/dcc_parser Souradeep Chowdhury (5): dt-bindings: Added the yaml bindings for DCC soc: qcom: dcc:Add driver support for Data Capture and Compare unit(DCC) DCC: Added the sysfs entries for DCC(Data Capture and Compare) driver MAINTAINERS:Add the entry for DCC(Data Capture and Compare) driver support arm64: dts: qcom: sm8150: Add Data Capture and Compare(DCC) support node Documentation/ABI/testing/sysfs-driver-dcc | 114 ++ .../devicetree/bindings/arm/msm/qcom,dcc.yaml | 49 + MAINTAINERS|8 + arch/arm64/boot/dts/qcom/sm8150.dtsi |7 + drivers/soc/qcom/Kconfig |8 + drivers/soc/qcom/Makefile |1 + drivers/soc/qcom/dcc.c | 1549 7 files changed, 1
Re: [PATCH] linux/gpio/driver.h: some edits for clarity
On Tue, Mar 23, 2021 at 11:19 PM Randy Dunlap wrote: > Fix a few typos and some punctuation. > Also, change CONFIG_OF to CONFIG_OF_GPIO in one comment. > > Signed-off-by: Randy Dunlap > Cc: Linus Walleij > Cc: Bartosz Golaszewski > Cc: linux-g...@vger.kernel.org Reviewed-by: Linus Walleij Yours, Linus Walleij
[PATCH V2 3/5] DCC: Added the sysfs entries for DCC(Data Capture and Compare) driver
The DCC is a DMA engine designed to store register values either in case of a system crash or in case of software triggers manually done by the user.Using DCC hardware and the sysfs interface of the driver the user can exploit various functionalities of DCC.The user can specify the register addresses,the values of which is stored by DCC in it's dedicated SRAM.The register addresses can be used either to read from, write to,first read and store value and then write or to loop.All these options can be exploited using the sysfs interface given to the user. Following are the sysfs interfaces exposed in DCC driver which are documented 1)trigger 2)config 3)config_write 4)config_reset 5)enable 6)rd_mod_wr 7)loop Signed-off-by: Souradeep Chowdhury --- Documentation/ABI/testing/sysfs-driver-dcc | 114 + 1 file changed, 114 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc diff --git a/Documentation/ABI/testing/sysfs-driver-dcc b/Documentation/ABI/testing/sysfs-driver-dcc new file mode 100644 index 000..05d24f0 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-dcc @@ -0,0 +1,114 @@ +What: /sys/bus/platform/devices/.../trigger +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This is the sysfs interface for manual software + triggers.The user can simply enter a 1 against + the sysfs file and enable a manual trigger. + Example: + echo 1 > /sys/bus/platform/devices/.../trigger + +What: /sys/bus/platform/devices/.../enable +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This sysfs interface is used for enabling the + the dcc hardware.Without this being set to 1, + the dcc hardware ceases to function. + Example: + echo 0 > /sys/bus/platform/devices/.../enable + (disable interface) + echo 1 > /sys/bus/platform/devices/.../enable + (enable interface) + +What: /sys/bus/platform/devices/.../config +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This is the most commonly used sysfs interface + file and this basically stores the addresses of + the registers which needs to be read in case of + a hardware crash or manual software triggers. + Example: + echo 0x8010 10 > /sys/bus/platform/devices/../config + This specifies that 10 words starting from address + 0x8010 is to be read.In case there are no words to be + specified we can simply enter the address. + +What: /sys/bus/platform/devices/.../config_write +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This file allows user to write a value to the register + address given as argument.The values are entered in the + form of .The reason for this + feature of dcc is that for accessing certain registers + it is necessary to set some bits of soe other register. + That is achievable by giving DCC this privelege. + Example: + echo 0x8000 0xFF > /sys/bus/platform/devices/.../config_write + +What: /sys/bus/platform/devices/.../config_reset +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This file is used to reset the configuration of + a dcc driver to the default configuration. + Example: + echo 1 > /sys/bus/platform/devices/.../config_reset + +What: /sys/bus/platform/devices/.../loop +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This file is used to enter the loop count as dcc + driver gives the option to loop multiple times on + the same register and store the values for each + loop.This is done to capture the changing values + of a register with time which comes handy for + debugging purposes. + Example: + echo 10 > /sys/bus/platform/devices/10a2000.dcc/loop + (Setting the loop count to 10) + echo 0x8010 10 > /sys/bus/platform/devices/.../config +(Read 10 words starting from address 0x8010O) + echo 1 > /sys/bus/platform/devices/.../loop + (Terminate the loop by writing a count of 1 to the loop sysfs node) + +What: /sys/bus/platform/devices/.../rd_mod_wr +Date: March 2021 +Contact:Souradeep Chowdhury +Description: + This file is used to read the value of the register + and then write the value given as an argument to the +
[PATCH V2 4/5] MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver support
Added the entries for all the files added as a part of driver support for DCC(Data Capture and Compare). Signed-off-by: Souradeep Chowdhury --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d92f85c..fb28218 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4969,6 +4969,14 @@ F: include/linux/tfrc.h F: include/uapi/linux/dccp.h F: net/dccp/ +QTI DCC DRIVER +M: Souradeep Chowdhury +L: linux-arm-...@vger.kernel.org +S: Maintained +F: Documentation/ABI/testing/sysfs-driver-dcc +F: Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml +F: drivers/soc/qcom/dcc.c + DECnet NETWORK LAYER L: linux-decnet-u...@lists.sourceforge.net S: Orphan -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH V2 2/5] soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC)
The DCC is a DMA Engine designed to capture and store data during system crash or software triggers.The DCC operates based on user inputs via the sysfs interface.The user gives addresses as inputs and these addresses are stored in the form of linkedlists.In case of a system crash or a manual software trigger by the user through the sysfs interface, the dcc captures and stores the values at these addresses. This patch contains the driver which has all the methods pertaining to the sysfs interface, auxiliary functions to support all the four fundamental operations of dcc namely read, write, first read then write and loop.The probe method here instantiates all the resources necessary for dcc to operate mainly the dedicated dcc sram where it stores the values.The DCC driver can be used for debugging purposes without going for a reboot since it can perform manual triggers. Signed-off-by: Souradeep Chowdhury --- drivers/soc/qcom/Kconfig |8 + drivers/soc/qcom/Makefile |1 + drivers/soc/qcom/dcc.c| 1549 + 3 files changed, 1558 insertions(+) create mode 100644 drivers/soc/qcom/dcc.c diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig index 79b568f..8819e0b 100644 --- a/drivers/soc/qcom/Kconfig +++ b/drivers/soc/qcom/Kconfig @@ -69,6 +69,14 @@ config QCOM_LLCC SDM845. This provides interfaces to clients that use the LLCC. Say yes here to enable LLCC slice driver. +config QCOM_DCC + tristate "Qualcomm Technologies, Inc. Data Capture and Compare engine driver" + depends on ARCH_QCOM || COMPILE_TEST + help + This option enables driver for Data Capture and Compare engine. DCC + driver provides interface to configure DCC block and read back + captured data from DCC's internal SRAM. + config QCOM_KRYO_L2_ACCESSORS bool depends on ARCH_QCOM && ARM64 || COMPILE_TEST diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile index ad675a6..1b00870 100644 --- a/drivers/soc/qcom/Makefile +++ b/drivers/soc/qcom/Makefile @@ -26,3 +26,4 @@ obj-$(CONFIG_QCOM_LLCC) += llcc-qcom.o obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o obj-$(CONFIG_QCOM_KRYO_L2_ACCESSORS) +=kryo-l2-accessors.o +obj-$(CONFIG_QCOM_DCC) += dcc.o diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c new file mode 100644 index 000..a55d8ca7 --- /dev/null +++ b/drivers/soc/qcom/dcc.c @@ -0,0 +1,1549 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#define TIMEOUT_US 100 + +#define dcc_writel(drvdata, val, off) \ + writel((val), drvdata->base + dcc_offset_conv(drvdata, off)) +#define dcc_readl(drvdata, off) \ + readl(drvdata->base + dcc_offset_conv(drvdata, off)) + +#define dcc_sram_readl(drvdata, off) \ + readl(drvdata->ram_base + off) + +#define DCC_SRAM_NODE "dcc_sram" + +/* DCC registers */ +#define DCC_HW_INFO0x04 +#define DCC_LL_NUM_INFO0x10 +#define DCC_STATUS 0x1C +#define DCC_LL_LOCK(m) (0x34 + 0x80 * m) +#define DCC_LL_CFG(m) (0x38 + 0x80 * m) +#define DCC_LL_BASE(m) (0x3c + 0x80 * m) +#define DCC_FD_BASE(m) (0x40 + 0x80 * m) +#define DCC_LL_TIMEOUT(m) (0x44 + 0x80 * m) +#define DCC_LL_INT_ENABLE(m) (0x4C + 0x80 * m) +#define DCC_LL_INT_STATUS(m) (0x50 + 0x80 * m) +#define DCC_LL_SW_TRIGGER(m) (0x60 + 0x80 * m) +#define DCC_LL_BUS_ACCESS_STATUS(m)(0x64 + 0x80 * m) + +#define DCC_MAP_LEVEL1 0x18 +#define DCC_MAP_LEVEL2 0x34 +#define DCC_MAP_LEVEL3 0x4C + +#define DCC_MAP_OFFSET10x10 +#define DCC_MAP_OFFSET20x18 +#define DCC_MAP_OFFSET30x1C +#define DCC_MAP_OFFSET40x8 + +#define DCC_FIX_LOOP_OFFSET16 +#define DCC_VER_INFO_BIT 9 + +#define DCC_READ 0 +#define DCC_WRITE 1 +#define DCC_LOOP 2 +#define DCC_READ_WRITE 3 + +#define MAX_DCC_OFFSET GENMASK(9, 2) +#define MAX_DCC_LENGENMASK(6, 0) +#define MAX_LOOP_CNT GENMASK(7, 0) + +#define DCC_ADDR_DESCRIPTOR0x00 +#define DCC_LOOP_DESCRIPTORBIT(30) +#define DCC_RD_MOD_WR_DESCRIPTOR BIT(31) +#define DCC_LINK_DESCRIPTORGENMASK(31, 30) + +#define DCC_READ_IND 0x00 +#define DCC_WRITE_IND (BIT(2
[PATCH V2 5/5] arm64: dts: qcom: sm8150: Add Data Capture and Compare(DCC) support node
Add the DCC(Data Capture and Compare) device tree node entry along with
the addresses for register regions.
Signed-off-by: Souradeep Chowdhury
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index e5bb17b..e5a39c4 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -654,6 +654,13 @@
interrupts = ;
};
+ dcc@10a2000 {
+ compatible = "qcom,sm8150-dcc", "qcom,dcc";
+ reg = <0x0 0x010a2000 0x0 0x1000>,
+ <0x0 0x010ad000 0x0 0ox3000>;
+ reg-names = "dcc", "dcc-ram";
+ };
+
ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,sm8150-ufshc", "qcom,ufshc",
"jedec,ufs-2.0";
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH BUGFIX/IMPROVEMENT V2 0/6] revised version of third and last batch of patches
Hello. On Thu, Mar 04, 2021 at 06:46:21PM +0100, Paolo Valente wrote: > Hi, > this is the V2 for the third and last batches of patches that I > proposed recently [1]. > > I've tried to address all issues raised in [1]. > > In more detail, main changes for V1 are: > 1. I've improved code as requested in "block, bfq: merge bursts of > newly-created queues" > 2. I've improved comments as requested in "block, bfq: put reqs of > waker and woken in dispatch list" > > Thanks, > Paolo > > [1] https://www.spinics.net/lists/linux-block/msg64333.html > > Paolo Valente (6): > block, bfq: always inject I/O of queues blocked by wakers > block, bfq: put reqs of waker and woken in dispatch list > block, bfq: make shared queues inherit wakers > block, bfq: fix weight-raising resume with !low_latency > block, bfq: keep shared queues out of the waker mechanism > block, bfq: merge bursts of newly-created queues > > block/bfq-cgroup.c | 2 + > block/bfq-iosched.c | 399 +--- > block/bfq-iosched.h | 15 ++ > block/bfq-wf2q.c| 8 + > 4 files changed, 402 insertions(+), 22 deletions(-) > > -- > 2.20.1 I'm running the kernel with this submission applied on multiple machines for 3 weeks now and haven't encountered any visible issues. Tested-by: Oleksandr Natalenko Thanks. -- Oleksandr Natalenko (post-factum)
[PATCH v3 0/4] riscv: Add qspinlock/qrwlock
From: Guo Ren Current riscv is still using baby spinlock implementation. It'll cause fairness and cache line bouncing problems. Many people are involved and pay the efforts to improve it: - The first version of patch was made in 2019.1: https://lore.kernel.org/linux-riscv/20190211043829.30096-1-michaeljcl...@mac.com/#r - The second version was made in 2020.11: https://lore.kernel.org/linux-riscv/1606225437-22948-2-git-send-email-guo...@kernel.org/ - A good discussion at Platform HSC.2021-03-08: https://drive.google.com/drive/folders/1ooqdnIsYx7XKor5O1XTtM6D1CHp4hc0p Hope your comments and Tested-by or Co-developed-by or Reviewed-by ... Let's kick the qspinlock into riscv right now (Also for the architectures which doesn't have short atmoic xchg instructions.) Change V3: - Fixup short-xchg asm code (slli -> slliw, srli -> srliw) - Coding convention by Peter Zijlstra's advices Change V2: - Coding convention in cmpxchg.h - Re-implement short xchg - Remove char & cmpxchg implementations V1: (by michael) Guo Ren (3): riscv: cmpxchg.h: Cleanup unused code riscv: cmpxchg.h: Merge macros riscv: cmpxchg.h: Implement xchg for short Michael Clark (1): riscv: Convert custom spinlock/rwlock to generic qspinlock/qrwlock arch/riscv/Kconfig | 2 + arch/riscv/include/asm/Kbuild | 3 + arch/riscv/include/asm/cmpxchg.h| 211 ++-- arch/riscv/include/asm/spinlock.h | 126 +- arch/riscv/include/asm/spinlock_types.h | 15 +- 5 files changed, 58 insertions(+), 299 deletions(-) -- 2.17.1
Re: [PATCH v2] net: make unregister netdev warning timeout configurable
On Wed, Mar 24, 2021 at 10:40 AM Eric Dumazet wrote:
>
> On Tue, Mar 23, 2021 at 7:49 AM Dmitry Vyukov wrote:
> >
> > netdev_wait_allrefs() issues a warning if refcount does not drop to 0
> > after 10 seconds. While 10 second wait generally should not happen
> > under normal workload in normal environment, it seems to fire falsely
> > very often during fuzzing and/or in qemu emulation (~10x slower).
> > At least it's not possible to understand if it's really a false
> > positive or not. Automated testing generally bumps all timeouts
> > to very high values to avoid flake failures.
> > Add net.core.netdev_unregister_timeout_secs sysctl to make
> > the timeout configurable for automated testing systems.
> > Lowering the timeout may also be useful for e.g. manual bisection.
> > The default value matches the current behavior.
> >
> > Signed-off-by: Dmitry Vyukov
> > Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=211877
> > Cc: net...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> >
> > ---
> > Changes since v1:
> > - use sysctl instead of a config
> > ---
>
> > },
> > + {
> > + .procname = "netdev_unregister_timeout_secs",
> > + .data = &netdev_unregister_timeout_secs,
> > + .maxlen = sizeof(unsigned int),
> > + .mode = 0644,
> > + .proc_handler = proc_dointvec_minmax,
> > + .extra1 = SYSCTL_ZERO,
> > + .extra2 = &int_3600,
> > + },
> > { }
> > };
> >
>
> If we allow the sysctl to be 0, then we risk a flood of pr_emerg()
> (one per jiffy ?)
My reasoning was that it's up to the user. Some spammy output on the
console for rare events is probably not the worst way how root can
misconfigure the kernel :)
It allows one to check (more or less) if we are reaching
unregister_netdevice with non-zero refcount, which may be useful for
some debugging maybe.
But I don't mind changing it to 1 (or 5) if you prefer. On syzbot we
only want to increase it.
> If you really want the zero value, you need to change pr_emerg() to
> pr_emerg_ratelimited()
>
> Also, please base your patch on net-next, to avoid future merge conflicts
> with my prior patch add2d7363107 "net: set initial device refcount to 1".
[PATCH v3 4/4] riscv: Convert custom spinlock/rwlock to generic qspinlock/qrwlock
From: Michael Clark
Update the RISC-V port to use the generic qspinlock and qrwlock.
This patch requires support for xchg for short which are added by
a previous patch.
Guo fixed up compile error which made by below include sequence:
+#include
+#include
Signed-off-by: Michael Clark
Co-developed-by: Guo Ren
Tested-by: Guo Ren
Link:
https://lore.kernel.org/linux-riscv/20190211043829.30096-3-michaeljcl...@mac.com/
Cc: Peter Zijlstra
Cc: Anup Patel
Cc: Arnd Bergmann
Cc: Palmer Dabbelt
---
arch/riscv/Kconfig | 2 +
arch/riscv/include/asm/Kbuild | 3 +
arch/riscv/include/asm/spinlock.h | 126 +---
arch/riscv/include/asm/spinlock_types.h | 15 +--
4 files changed, 10 insertions(+), 136 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 87d7b52f278f..c78b8b0ccf96 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -33,6 +33,8 @@ config RISCV
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_FRAME_POINTERS
select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
+ select ARCH_USE_QUEUED_RWLOCKS
+ select ARCH_USE_QUEUED_SPINLOCKS
select CLONE_BACKWARDS
select CLINT_TIMER if !MMU
select COMMON_CLK
diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
index 445ccc97305a..750c1056b90f 100644
--- a/arch/riscv/include/asm/Kbuild
+++ b/arch/riscv/include/asm/Kbuild
@@ -3,5 +3,8 @@ generic-y += early_ioremap.h
generic-y += extable.h
generic-y += flat.h
generic-y += kvm_para.h
+generic-y += mcs_spinlock.h
+generic-y += qrwlock.h
+generic-y += qspinlock.h
generic-y += user.h
generic-y += vmlinux.lds.h
diff --git a/arch/riscv/include/asm/spinlock.h
b/arch/riscv/include/asm/spinlock.h
index f4f7fa1b7ca8..a557de67a425 100644
--- a/arch/riscv/include/asm/spinlock.h
+++ b/arch/riscv/include/asm/spinlock.h
@@ -7,129 +7,7 @@
#ifndef _ASM_RISCV_SPINLOCK_H
#define _ASM_RISCV_SPINLOCK_H
-#include
-#include
-#include
-
-/*
- * Simple spin lock operations. These provide no fairness guarantees.
- */
-
-/* FIXME: Replace this with a ticket lock, like MIPS. */
-
-#define arch_spin_is_locked(x) (READ_ONCE((x)->lock) != 0)
-
-static inline void arch_spin_unlock(arch_spinlock_t *lock)
-{
- smp_store_release(&lock->lock, 0);
-}
-
-static inline int arch_spin_trylock(arch_spinlock_t *lock)
-{
- int tmp = 1, busy;
-
- __asm__ __volatile__ (
- " amoswap.w %0, %2, %1\n"
- RISCV_ACQUIRE_BARRIER
- : "=r" (busy), "+A" (lock->lock)
- : "r" (tmp)
- : "memory");
-
- return !busy;
-}
-
-static inline void arch_spin_lock(arch_spinlock_t *lock)
-{
- while (1) {
- if (arch_spin_is_locked(lock))
- continue;
-
- if (arch_spin_trylock(lock))
- break;
- }
-}
-
-/***/
-
-static inline void arch_read_lock(arch_rwlock_t *lock)
-{
- int tmp;
-
- __asm__ __volatile__(
- "1: lr.w%1, %0\n"
- " bltz%1, 1b\n"
- " addi%1, %1, 1\n"
- " sc.w%1, %1, %0\n"
- " bnez%1, 1b\n"
- RISCV_ACQUIRE_BARRIER
- : "+A" (lock->lock), "=&r" (tmp)
- :: "memory");
-}
-
-static inline void arch_write_lock(arch_rwlock_t *lock)
-{
- int tmp;
-
- __asm__ __volatile__(
- "1: lr.w%1, %0\n"
- " bnez%1, 1b\n"
- " li %1, -1\n"
- " sc.w%1, %1, %0\n"
- " bnez%1, 1b\n"
- RISCV_ACQUIRE_BARRIER
- : "+A" (lock->lock), "=&r" (tmp)
- :: "memory");
-}
-
-static inline int arch_read_trylock(arch_rwlock_t *lock)
-{
- int busy;
-
- __asm__ __volatile__(
- "1: lr.w%1, %0\n"
- " bltz%1, 1f\n"
- " addi%1, %1, 1\n"
- " sc.w%1, %1, %0\n"
- " bnez%1, 1b\n"
- RISCV_ACQUIRE_BARRIER
- "1:\n"
- : "+A" (lock->lock), "=&r" (busy)
- :: "memory");
-
- return !busy;
-}
-
-static inline int arch_write_trylock(arch_rwlock_t *lock)
-{
- int busy;
-
- __asm__ __volatile__(
- "1: lr.w%1, %0\n"
- " bnez%1, 1f\n"
- " li %1, -1\n"
- " sc.w%1, %1, %0\n"
- " bnez%1, 1b\n"
- RISCV_ACQUIRE_BARRIER
- "1:\n"
- : "+A" (lock->lock), "=&r" (busy)
- :: "memory");
-
- return !busy;
-}
-
-static inline void arch_read_unlock(arch_rwlock_t *lock)
-{
- __asm__ __volatile__(
-
Re: [PATCH V8 1/8] PM / devfreq: Add cpu based scaling support to passive_governor
Hi,
You are missing to add these patches to linux-pm mailing list.
Need to send them to linu-pm ML.
Also, before received this series, I tried to clean-up these patches
on testing branch[1]. So that I add my comment with my clean-up case.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-passive-gov
And 'Saravana Kannan ' is wrong email address.
Please update the email or drop this email.
On 3/23/21 8:33 PM, Andrew-sh.Cheng wrote:
> From: Saravana Kannan
>
> Many CPU architectures have caches that can scale independent of the
> CPUs. Frequency scaling of the caches is necessary to make sure that the
> cache is not a performance bottleneck that leads to poor performance and
> power. The same idea applies for RAM/DDR.
>
> To achieve this, this patch adds support for cpu based scaling to the
> passive governor. This is accomplished by taking the current frequency
> of each CPU frequency domain and then adjust the frequency of the cache
> (or any devfreq device) based on the frequency of the CPUs. It listens
> to CPU frequency transition notifiers to keep itself up to date on the
> current CPU frequency.
>
> To decide the frequency of the device, the governor does one of the
> following:
> * Derives the optimal devfreq device opp from required-opps property of
> the parent cpu opp_table.
>
> * Scales the device frequency in proportion to the CPU frequency. So, if
> the CPUs are running at their max frequency, the device runs at its
> max frequency. If the CPUs are running at their min frequency, the
> device runs at its min frequency. It is interpolated for frequencies
> in between.
>
> Andrew-sh.Cheng change
> dev_pm_opp_xlate_opp to dev_pm_opp_xlate_required_opp devfreq->max_freq
> to devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value
> after kernel-5.7
> Don't return -EINVAL in devfreq_passive_event_handler()
> since it doesn't handle DEVFREQ_GOV_SUSPEND DEVFREQ_GOV_RESUME cases.
>
> Signed-off-by: Saravana Kannan
> [Sibi: Integrated cpu-freqmap governor into passive_governor]
> Signed-off-by: Sibi Sankar
> Signed-off-by: Andrew-sh.Cheng
> ---
> drivers/devfreq/Kconfig| 2 +
> drivers/devfreq/governor_passive.c | 329
> +++--
> include/linux/devfreq.h| 29 +++-
> 3 files changed, 342 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 00704efe6398..f56132b0ae64 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -73,6 +73,8 @@ config DEVFREQ_GOV_PASSIVE
> device. This governor does not change the frequency by itself
> through sysfs entries. The passive governor recommends that
> devfreq device uses the OPP table to get the frequency/voltage.
> + Alternatively the governor can also be chosen to scale based on
> + the online CPUs current frequency.
>
> comment "DEVFREQ Drivers"
>
> diff --git a/drivers/devfreq/governor_passive.c
> b/drivers/devfreq/governor_passive.c
> index b094132bd20b..9cc57b083839 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -8,11 +8,103 @@
> */
>
> #include
> +#include
> +#include
> +#include
> #include
> #include
> +#include
> #include "governor.h"
>
> -static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
> +struct devfreq_cpu_state {
> + unsigned int curr_freq;
> + unsigned int min_freq;
> + unsigned int max_freq;
> + unsigned int first_cpu;
> + struct device *cpu_dev;
> + struct opp_table *opp_table;
> +};
As I knew, the previous version has the description of structure
as following: I wan to add the description like below.
And if you have no any objection, I'd like you to order
the variables as following and use 'dev' instead of 'cpu_dev'
because this patch use the 'cpu_state->cpu_dev' at the multiple points.
I think that 'cpu_state->dev' is better than 'cpu_state->cpu_dev'.
Also, I prefer to use 'cur_freq' instead of 'curr_freq'
because devfreq subsystem uses 'cur_freq' for expressing the 'current
frequency'.
/**
* struct devfreq_cpu_state - Hold the per-cpu data
* @dev:reference to cpu device.
* @first_cpu: the cpumask of the first cpu of a policy.
* @opp_table: reference to cpu opp table.
* @cur_freq: the current frequency of the cpu.
* @min_freq: the min frequency of the cpu.
* @max_freq: the max frequency of the cpu.
*
* This structure stores the required cpu_data of a cpu.
* This is au
Re: [PATCH V8 7/8] devfreq: mediatek: cci devfreq register opp notification for SVS support
Hi,
I think that you can squash this patch to patch4.
On 3/23/21 8:34 PM, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng"
>
> SVS will change the voltage of opp item.
What it the full name of SVS?
> CCI devfreq need to react to change frequency.
>
> Signed-off-by: Andrew-sh.Cheng
> ---
> drivers/devfreq/mt8183-cci-devfreq.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/devfreq/mt8183-cci-devfreq.c
> b/drivers/devfreq/mt8183-cci-devfreq.c
> index 018543db7bae..6942a48f3f4f 100644
> --- a/drivers/devfreq/mt8183-cci-devfreq.c
> +++ b/drivers/devfreq/mt8183-cci-devfreq.c
> @@ -21,6 +21,7 @@ struct cci_devfreq {
> struct clk *cci_clk;
> int old_vproc;
> unsigned long old_freq;
> + struct notifier_block opp_nb;
> };
>
> static int mtk_cci_set_voltage(struct cci_devfreq *cci_df, int vproc)
> @@ -89,6 +90,26 @@ static int mtk_cci_devfreq_target(struct device *dev,
> unsigned long *freq,
> return 0;
> }
>
> +static int ccidevfreq_opp_notifier(struct notifier_block *nb,
I think that you better to change the function name as following:
ccidevfreq_opp_notifier -> mtk_cci_devfreq_opp_notifier
> +unsigned long event, void *data)
> +{
> + struct dev_pm_opp *opp = data;
> + struct cci_devfreq *cci_df = container_of(nb, struct cci_devfreq,
> + opp_nb);
> + unsigned long freq, volt;
> +
> + if (event == OPP_EVENT_ADJUST_VOLTAGE) {
> + freq = dev_pm_opp_get_freq(opp);
> + /* current opp item is changed */
> + if (freq == cci_df->old_freq) {
> + volt = dev_pm_opp_get_voltage(opp);
> + mtk_cci_set_voltage(cci_df, volt);
> + }
> + }
> +
> + return 0;
> +}
> +
> static struct devfreq_dev_profile cci_devfreq_profile = {
> .target = mtk_cci_devfreq_target,
> };
> @@ -98,12 +119,15 @@ static int mtk_cci_devfreq_probe(struct platform_device
> *pdev)
> struct device *cci_dev = &pdev->dev;
> struct cci_devfreq *cci_df;
> struct devfreq_passive_data *passive_data;
> + struct notifier_block *opp_nb;
> int ret;
>
> cci_df = devm_kzalloc(cci_dev, sizeof(*cci_df), GFP_KERNEL);
> if (!cci_df)
> return -ENOMEM;
>
> + opp_nb = &cci_df->opp_nb;
Just move this code at the neighborhood of 'opp_nb->notifier_call' init code.
> +
> cci_df->cci_clk = devm_clk_get(cci_dev, "cci_clock");
> ret = PTR_ERR_OR_ZERO(cci_df->cci_clk);
> if (ret) {
> @@ -152,6 +176,9 @@ static int mtk_cci_devfreq_probe(struct platform_device
> *pdev)
> goto err_opp;
> }
>
> + opp_nb->notifier_call = ccidevfreq_opp_notifier;
> + dev_pm_opp_register_notifier(cci_dev, opp_nb);
Need to check whether return value is valid or not.
> +
> return 0;
>
> err_opp:
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[PATCH v3 2/4] riscv: cmpxchg.h: Merge macros
From: Guo Ren
To reduce assembly codes, let's merge duplicate codes into one
(xchg_acquire, xchg_release, cmpxchg_release).
Signed-off-by: Guo Ren
Link:
https://lore.kernel.org/linux-riscv/CAJF2gTT1_mP-wiK2HsCpTeU61NqZVKZX1A5ye=twqvgn4tp...@mail.gmail.com/
Cc: Peter Zijlstra
Cc: Michael Clark
Cc: Anup Patel
Cc: Arnd Bergmann
Cc: Palmer Dabbelt
---
arch/riscv/include/asm/cmpxchg.h | 92 +---
1 file changed, 12 insertions(+), 80 deletions(-)
diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
index f1383c15e16b..50513b95411d 100644
--- a/arch/riscv/include/asm/cmpxchg.h
+++ b/arch/riscv/include/asm/cmpxchg.h
@@ -11,6 +11,12 @@
#include
#include
+#define __local_acquire_fence()
\
+ __asm__ __volatile__(RISCV_ACQUIRE_BARRIER "" ::: "memory")
+
+#define __local_release_fence()
\
+ __asm__ __volatile__(RISCV_RELEASE_BARRIER "" ::: "memory")
+
#define __xchg_relaxed(ptr, new, size) \
({ \
__typeof__(ptr) __ptr = (ptr); \
@@ -46,58 +52,16 @@
#define __xchg_acquire(ptr, new, size) \
({ \
- __typeof__(ptr) __ptr = (ptr); \
- __typeof__(new) __new = (new); \
__typeof__(*(ptr)) __ret; \
- switch (size) { \
- case 4: \
- __asm__ __volatile__ ( \
- " amoswap.w %0, %2, %1\n" \
- RISCV_ACQUIRE_BARRIER \
- : "=r" (__ret), "+A" (*__ptr) \
- : "r" (__new) \
- : "memory");\
- break; \
- case 8: \
- __asm__ __volatile__ ( \
- " amoswap.d %0, %2, %1\n" \
- RISCV_ACQUIRE_BARRIER \
- : "=r" (__ret), "+A" (*__ptr) \
- : "r" (__new) \
- : "memory");\
- break; \
- default:\
- BUILD_BUG();\
- } \
+ __ret = __xchg_relaxed(ptr, new, size); \
+ __local_acquire_fence();\
__ret; \
})
#define __xchg_release(ptr, new, size) \
({ \
- __typeof__(ptr) __ptr = (ptr); \
- __typeof__(new) __new = (new); \
- __typeof__(*(ptr)) __ret; \
- switch (size) { \
- case 4: \
- __asm__ __volatile__ ( \
- RISCV_RELEASE_BARRIER \
- " amoswap.w %0, %2, %1\n" \
- : "=r" (__ret), "+A" (*__ptr) \
- : "r" (__new) \
- : "memory");\
- break; \
- case 8: \
- __asm__ __volatile__ ( \
- RISCV_RELEASE_BARRIER \
- " amoswap.d %0, %2, %1\n" \
- : "=r" (__ret), "+A" (*__ptr) \
- : "r" (__new) \
- : "memory");\
- break; \
- default:
Re: [PATCH v3 07/10] pinctrl: Ingenic: Add pinctrl driver for JZ4750.
On 2021/3/23 上午2:20, Paul Cercueil wrote:
Le mer. 17 mars 2021 à 17:58, 周琰杰 (Zhou Yanjie)
a écrit :
Add support for probing the pinctrl-ingenic driver on the
JZ4750 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
---
Notes:
v3:
New patch.
drivers/pinctrl/pinctrl-ingenic.c | 137
++
1 file changed, 137 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 25458d6..d98767b 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -85,6 +85,7 @@ enum jz_version {
ID_JZ4730,
ID_JZ4740,
ID_JZ4725B,
+ ID_JZ4750,
ID_JZ4760,
ID_JZ4770,
ID_JZ4780,
@@ -424,6 +425,138 @@ static const struct ingenic_chip_info
jz4725b_chip_info = {
.pull_downs = jz4740_pull_downs,
};
+static const u32 jz4750_pull_ups[6] = {
+ 0x, 0x, 0x3fff, 0x7fff, 0x1fff3fff,
0x00ff,
+};
+
+static const u32 jz4750_pull_downs[6] = {
+ 0x, 0x, 0x, 0x, 0x,
0x,
+};
+
+static int jz4750_uart0_data_pins[] = { 0xa4, 0xa5, };
+static int jz4750_uart0_hwflow_pins[] = { 0xa6, 0xa7, };
+static int jz4750_uart1_data_pins[] = { 0x90, 0x91, };
+static int jz4750_uart1_hwflow_pins[] = { 0x92, 0x93, };
+static int jz4750_uart2_data_pins[] = { 0x9b, 0x9a, };
+static int jz4750_uart3_data_pins[] = { 0xb0, 0xb1, };
+static int jz4750_uart3_hwflow_pins[] = { 0xb2, 0xb3, };
+static int jz4750_mmc0_1bit_pins[] = { 0xa8, 0xa9, 0xa0, };
+static int jz4750_mmc0_4bit_pins[] = { 0xa1, 0xa2, 0xa3, };
+static int jz4750_mmc0_8bit_pins[] = { 0xa4, 0xa5, 0xa6, 0xa7, };
+static int jz4750_mmc1_1bit_pins[] = { 0xae, 0xaf, 0xaa, };
+static int jz4750_mmc1_4bit_pins[] = { 0xab, 0xac, 0xad, };
+static int jz4750_i2c_pins[] = { 0x8c, 0x8d, };
+static int jz4750_cim_pins[] = {
+ 0x89, 0x8b, 0x8a, 0x88,
+ 0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
+};
+static int jz4750_lcd_8bit_pins[] = {
+ 0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x72, 0x73, 0x74,
+};
+static int jz4750_lcd_16bit_pins[] = {
+ 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x75,
+};
+static int jz4750_lcd_18bit_pins[] = { 0x70, 0x71, };
+static int jz4750_lcd_18bit_tft_pins[] = { 0x78, 0x79, 0x76, 0x77, };
+static int jz4750_nand_cs1_pins[] = { 0x55, };
+static int jz4750_nand_cs2_pins[] = { 0x56, };
+static int jz4750_nand_cs3_pins[] = { 0x57, };
+static int jz4750_nand_cs4_pins[] = { 0x58, };
+static int jz4750_nand_fre_fwe_pins[] = { 0x5c, 0x5d, };
+static int jz4750_pwm_pwm0_pins[] = { 0x94, };
+static int jz4750_pwm_pwm1_pins[] = { 0x95, };
+static int jz4750_pwm_pwm2_pins[] = { 0x96, };
+static int jz4750_pwm_pwm3_pins[] = { 0x97, };
+static int jz4750_pwm_pwm4_pins[] = { 0x98, };
+static int jz4750_pwm_pwm5_pins[] = { 0x99, };
+
+static const struct group_desc jz4750_groups[] = {
+ INGENIC_PIN_GROUP("uart0-data", jz4750_uart0_data, 1),
+ INGENIC_PIN_GROUP("uart0-hwflow", jz4750_uart0_hwflow, 1),
+ INGENIC_PIN_GROUP("uart1-data", jz4750_uart1_data, 0),
+ INGENIC_PIN_GROUP("uart1-hwflow", jz4750_uart1_hwflow, 0),
+ INGENIC_PIN_GROUP("uart2-data", jz4750_uart2_data, 1),
+ INGENIC_PIN_GROUP("uart3-data", jz4750_uart3_data, 0),
+ INGENIC_PIN_GROUP("uart3-hwflow", jz4750_uart3_hwflow, 0),
+ INGENIC_PIN_GROUP("mmc0-1bit", jz4750_mmc0_1bit, 0),
+ INGENIC_PIN_GROUP("mmc0-4bit", jz4750_mmc0_4bit, 0),
+ INGENIC_PIN_GROUP("mmc0-8bit", jz4750_mmc0_8bit, 0),
+ INGENIC_PIN_GROUP("mmc1-1bit", jz4750_mmc1_1bit, 0),
+ INGENIC_PIN_GROUP("mmc1-4bit", jz4750_mmc1_4bit, 0),
+ INGENIC_PIN_GROUP("i2c-data", jz4750_i2c, 0),
+ INGENIC_PIN_GROUP("cim-data", jz4750_cim, 0),
+ INGENIC_PIN_GROUP("lcd-8bit", jz4750_lcd_8bit, 0),
+ INGENIC_PIN_GROUP("lcd-16bit", jz4750_lcd_16bit, 0),
+ INGENIC_PIN_GROUP("lcd-18bit", jz4750_lcd_18bit, 0),
+ INGENIC_PIN_GROUP("lcd-18bit-tft", jz4750_lcd_18bit_tft, 0),
+ { "lcd-no-pins", },
Please drop "lcd-no-pins" from your patches, it is pointless.
Sure.
Cheers,
-Paul
+ INGENIC_PIN_GROUP("nand-cs1", jz4750_nand_cs1, 0),
+ INGENIC_PIN_GROUP("nand-cs2", jz4750_nand_cs2, 0),
+ INGENIC_PIN_GROUP("nand-cs3", jz4750_nand_cs3, 0),
+ INGENIC_PIN_GROUP("nand-cs4", jz4750_nand_cs4, 0),
+ INGENIC_PIN_GROUP("nand-fre-fwe", jz4750_nand_fre_fwe, 0),
+ INGENIC_PIN_GROUP("pwm0", jz4750_pwm_pwm0, 0),
+ INGENIC_PIN_GROUP("pwm1", jz4750_pwm_pwm1, 0),
+ INGENIC_PIN_GROUP("pwm2", jz4750_pwm_pwm2, 0),
+ INGENIC_PIN_GROUP("pwm3", jz4750_pwm_pwm3, 0),
+ INGENIC_PIN_GROUP("pwm4", jz4750_pwm_pwm4, 0),
+ INGENIC_PIN_GROUP("pwm5", jz4750_pwm_pwm5, 0),
+};
+
+static const char *jz4750_uart0_groups[] = { "uart0-data",
"uart0-hwflow", };
+static const char *jz4750_uart1_groups[] = { "uart1-data",
"uart1-hwflow", };
+static const char *jz4750_uart2_groups[] = { "uart2-data", };
+static const char *jz4750_uart3_groups[] = { "uart3-data",
"uart3-hwf
