Re: [Linux-stm32] [PATCH v9 22/33] counter: Internalize sysfs interface code
On Fri, Mar 12, 2021 at 04:02:42PM +0100, Fabrice Gasnier wrote:
> On 3/9/21 2:19 PM, William Breathitt Gray wrote:
> > +static ssize_t enums_available_show(const u32 *const enums,
> > + const size_t num_enums,
> > + const char *const strs[], char *buf)
> > +{
> > + size_t len = 0;
> > + size_t index;
> > +
> > + for (index = 0; index < num_enums; index++)
> > + len += sysfs_emit(buf + len, "%s\n", strs[enums[index]]);
> > +
> > + return len;
> > +}
> > +
> > +static ssize_t strs_available_show(const struct counter_available *const
> > avail,
> > + char *buf)
> > +{
> > + size_t len = 0;
> > + size_t index;
> > +
> > + for (index = 0; index < avail->num_items; index++)
> > + len += sysfs_emit(buf + len, "%s\n", avail->strs[index]);
> > +
> > + return len;
> > +}
>
> Hi William,
>
> I was willing to do some testing on this series, on the stm32 counter
> drivers, since we released few fixes around them.
>
> I tried to apply this series against current testing branch, with few
> patches applied (so it applies cleanly):
> - dt-bindings: counter: add interrupt-counter binding
> - counter: add IRQ or GPIO based counter
> - counter: stm32-timer-cnt: fix ceiling miss-alignment with reload register
> - counter: stm32-timer-cnt: fix ceiling write max value
> counter: stm32-timer-cnt: Report count function when SLAVE_MODE_DISABLED
>
>
> For both the "stm32-lptimer-cnt" and "stm32-timer-cnt" drivers, I get a
> warning message and stack dump in "sysfs_emit" when reading the
> available functions from sysfs.
> I started to do some testing on v8 of this series last week. I didn't
> noticed that.
>
> For both the "stm32-lptimer-cnt", there are 2 functions currently I get
> 1 stack dump. Only the "increase" function is printed correctly.
>
> For the "stm32-timer-cnt", there are 4 functions currently, I get 3
> stack dumps. Only the "increase" function is printed correctly
>
> Sample log for "stm32-timer-cnt:
>
> root@stm32mp1:/sys/devices/platform/soc/4400.timer/4400.timer:counter/counter0#
> cat count0/function_available
> [ 4689.195506] [ cut here ]
> [ 4689.198747] WARNING: CPU: 1 PID: 5841 at fs/sysfs/file.c:737
> sysfs_emit+0x88/0x94
> [ 4689.206233] invalid sysfs_emit: buf:f4a66208
> [ 4689.210553] Modules linked in: sha256_generic libsha256 sha256_arm
> cfg80211 panel_orisetech_otm8009a snd_soc_hdmi_codec
> snd_soc_stm32_sai_sub stm32_lptimers
> [ 4689.261444] CPU: 1 PID: 5841 Comm: cat Tainted: GW
> 5.12.0-rc1 #534
> [ 4689.268999] Hardware name: STM32 (Device Tree Support)
> [ 4689.274166] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [ 4689.281942] [] (show_stack) from []
> (dump_stack+0xc0/0xd4)
> [ 4689.289199] [] (dump_stack) from []
> (__warn+0xec/0x148)
> [ 4689.296194] [] (__warn) from []
> (warn_slowpath_fmt+0x98/0xbc)
> [ 4689.303714] [] (warn_slowpath_fmt) from []
> (sysfs_emit+0x88/0x94)
> [ 4689.311586] [] (sysfs_emit) from []
> (counter_comp_available_show+0x11c/0x1a4 [counter])
> [ 4689.321382] [] (counter_comp_available_show [counter]) from
> [] (dev_attr_show+0x18/0x48)
> [ 4689.331263] [] (dev_attr_show) from []
> (sysfs_kf_seq_show+0x88/0xf0)
> [ 4689.339394] [] (sysfs_kf_seq_show) from []
> (seq_read_iter+0x1a4/0x554)
> [ 4689.347703] [] (seq_read_iter) from []
> (vfs_read+0x1ac/0x2c4)
> [ 4689.355224] [] (vfs_read) from []
> (ksys_read+0x64/0xdc)
> [ 4689.362219] [] (ksys_read) from []
> (ret_fast_syscall+0x0/0x58)
> [ 4689.369827] Exception stack(0xc7261fa8 to 0xc7261ff0)
> [ 4689.374906] 1fa0: 0002 0003
> b6f35000 0002
> [ 4689.383126] 1fc0: 0002 b6f56ce0 0003 0003
> 0002
> [ 4689.391344] 1fe0: 0003 be8239a8 410bff27 4104c066
> ...
> 2 more stack dumps follow
> ...
> [ 4689.810479] ---[ end trace 59ed79949efe984c ]---
> increase
>
> I get similar backtrace with other _available attributes:
> $ cat signal0_action_available
> $ cat signal1_action_available
>
> Do you think I'm doing something wrong ?
>
> I tested then "quadrature x4" on the timer driver... It seems all fine.
>
> Best regards
> Fabrice
>
> > +
> > +static ssize_t counter_comp_available_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + const struct counter_attribute *const a = to_counter_attribute(attr);
> > + const struct counter_count *const count = a->parent;
> > + const struct counter_synapse *const synapse = a->comp.priv;
> > + const struct counter_available *const avail = a->comp.priv;
> > +
> > + switch (a->comp.type) {
> > + case COUNTER_COMP_FUNCTION:
> > + return enums_available_show(count->functions_list,
> > + count->num_functions,
> > +
Re: [PATCH v1 01/14] include/linux/memcontrol.h: do not warn in page_memcg_rcu() if !CONFIG_MEMCG
On Sat, Mar 13, 2021 at 03:09:18PM +, Matthew Wilcox wrote: > On Sat, Mar 13, 2021 at 12:57:34AM -0700, Yu Zhao wrote: > > We want to make sure the rcu lock is held while using > > page_memcg_rcu(). But having a WARN_ON_ONCE() in page_memcg_rcu() when > > !CONFIG_MEMCG is superfluous because of the following legit use case: > > > > memcg = lock_page_memcg(page1) > > (rcu_read_lock() if CONFIG_MEMCG=y) > > > > do something to page1 > > > > if (page_memcg_rcu(page2) == memcg) > > do something to page2 too as it cannot be migrated away from the > > memcg either. > > > > unlock_page_memcg(page1) > > (rcu_read_unlock() if CONFIG_MEMCG=y) > > > > This patch removes the WARN_ON_ONCE() from page_memcg_rcu() for the > > !CONFIG_MEMCG case. > > I think this is wrong. Usually we try to have the same locking > environment no matter what the CONFIG options are, like with > kmap_atomic(). I think lock_page_memcg() should disable RCU even if > CONFIG_MEMCG=n. I agree in principle. On this topic I often debate myself where to draw the line between being rigorous and paranoid. But in this particular case, I thought it's no brainer because, imo, most of the systems that don't use memcgs are small and preemptable, e.g., openwrt. They wouldn't appreciate a larger code size or rcu stalls due to preemptions of functions that take rcu locks just to be rigorous. This shouldn't be a problem if we only do so when CONFIG_DEBUG_VM=y, but then its test coverage is another question. I'd be happy to work out something in this direction, hopefully worth the trouble, if you think this compromise is acceptable.
[PATCH] ASoC: Intel: Skylake: skl-topology: fix -frame-larger-than
Fixes:
sound/soc/intel/skylake/skl-topology.c:3613:13: warning: stack frame
size of 1304 bytes in function 'skl_tplg_complete'
[-Wframe-larger-than=]
struct snd_ctl_elem_value is 1224 bytes in my configuration.
Heap allocate it, then free it within the current frame.
Signed-off-by: Nick Desaulniers
---
sound/soc/intel/skylake/skl-topology.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/sound/soc/intel/skylake/skl-topology.c
b/sound/soc/intel/skylake/skl-topology.c
index ae466cd59292..cdc916c91301 100644
--- a/sound/soc/intel/skylake/skl-topology.c
+++ b/sound/soc/intel/skylake/skl-topology.c
@@ -3613,10 +3613,15 @@ static int skl_manifest_load(struct snd_soc_component
*cmpnt, int index,
static void skl_tplg_complete(struct snd_soc_component *component)
{
struct snd_soc_dobj *dobj;
- struct snd_soc_acpi_mach *mach =
- dev_get_platdata(component->card->dev);
+ struct snd_soc_acpi_mach *mach;
+ struct snd_ctl_elem_value *val;
int i;
+ val = kzalloc(sizeof(*val), GFP_KERNEL);
+ if (!val)
+ return;
+
+ mach = dev_get_platdata(component->card->dev);
list_for_each_entry(dobj, >dobj_list, list) {
struct snd_kcontrol *kcontrol = dobj->control.kcontrol;
struct soc_enum *se =
@@ -3631,14 +3636,13 @@ static void skl_tplg_complete(struct snd_soc_component
*component)
sprintf(chan_text, "c%d", mach->mach_params.dmic_num);
for (i = 0; i < se->items; i++) {
- struct snd_ctl_elem_value val;
-
if (strstr(texts[i], chan_text)) {
- val.value.enumerated.item[0] = i;
- kcontrol->put(kcontrol, );
+ val->value.enumerated.item[0] = i;
+ kcontrol->put(kcontrol, val);
}
}
}
+ kfree(val);
}
static struct snd_soc_tplg_ops skl_tplg_ops = {
base-commit: 65f0d2414b7079556fbbcc070b3d1c9f9587606d
prerequisite-patch-id: 4d05aad8c2b50c0c3b4447dd842abe8b1b840927
--
2.25.1
Re: [PATCH] staging: octeon-usb: fixed precedence issue
On Sat, Mar 13, 2021 at 11:02:47PM +0530, Selvakumar Elangovan wrote: > Added parenthesis around reg macro to avoid precedence issue identified by > checkpatch.pl > > Signed-off-by: Selvakumar Elangovan > --- > drivers/staging/octeon-usb/octeon-hcd.h | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/drivers/staging/octeon-usb/octeon-hcd.h > b/drivers/staging/octeon-usb/octeon-hcd.h > index 9ed619c93a4e..5aefd3fb3854 100644 > --- a/drivers/staging/octeon-usb/octeon-hcd.h > +++ b/drivers/staging/octeon-usb/octeon-hcd.h > @@ -51,11 +51,11 @@ > #include > > #define CVMX_USBCXBASE 0x00016F001000ull > -#define CVMX_USBCXREG1(reg, bid) \ > - (CVMX_ADD_IO_SEG(CVMX_USBCXBASE | reg) + \ > +#define CVMX_USBCXREG1((reg), bid) \ Why did you change this line?
[PATCH] soc: fsl: guts: fix comment syntax in file
The opening comment mark '/**' is used for kernel-doc comments. There are certain comments in include/linux/fsl/guts.h which follows this syntax, but the content inside does not comply with kernel-doc. E.g., opening comment for "Freecale 85xx and 86xx Global Utilties register set" follows kernel-doc syntax(i.e., '/**'), but the content inside does not comply with any kernel-doc specification (function, struct, etc). This causes unwelcomed warning from kernel-doc: "warning: expecting prototype for Freecale 85xx and 86xx Global Utilties register set(). Prototype was for __FSL_GUTS_H__() instead" Replace all such comment occurrences with general comment format, i.e. '/*' to pervent kernel-doc from parsing these. Signed-off-by: Aditya Srivastava --- * Applies perfectly on next-20210312 include/linux/fsl/guts.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h index 0ac27b233f12..fdb55ca47a4f 100644 --- a/include/linux/fsl/guts.h +++ b/include/linux/fsl/guts.h @@ -1,5 +1,5 @@ /* SPDX-License-Identifier: GPL-2.0-or-later */ -/** +/* * Freecale 85xx and 86xx Global Utilties register set * * Authors: Jeff Brown @@ -14,7 +14,7 @@ #include #include -/** +/* * Global Utility Registers. * * Not all registers defined in this structure are available on all chips, so -- 2.17.1
Re: macb broken on HiFive Unleashed
On Mär 13 2021, Emil Renner Berthing wrote: > As you can see I haven't updated OpenSBI or u-boot in a while Does it also work if you use the u-boot SPL instead of FSBL? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[PATCH V2] tty: vt: Mundane typo fix in the file vt.c
s/spurrious/spurious/ s/worse/worst/ Signed-off-by: Bhaskar Chowdhury --- Changes from V1: Incorporated Randy's suggestion. drivers/tty/vt/vt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index 284b07224c55..d9366da51e06 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -4448,7 +4448,7 @@ void poke_blanked_console(void) might_sleep(); /* This isn't perfectly race free, but a race here would be mostly harmless, -* at worse, we'll do a spurrious blank and it's unlikely +* at worst, we'll do a spurious blank and it's unlikely */ del_timer(_timer); blank_timer_expired = 0; -- 2.26.2
Re: [PATCH] clk: clk.c: Fixed statics initialized to 0
On Sun, 14 Mar 2021 at 02:36, Stephen Boyd wrote: > > Quoting Pallavi Prabhu (2021-03-12 19:41:12) > > Uninitialized static variable from 0, as statics get auto-initialized to 0 > > during execution. > > Signed-off-by: Pallavi Prabhu > > Need a newline between signed-off-by line and commit text. Also please > wrap the commit text at 80 or 78 characters or so. > > > --- > > drivers/clk/clk.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c > > index 5052541a0986..763ad2c960bd 100644 > > --- a/drivers/clk/clk.c > > +++ b/drivers/clk/clk.c > > @@ -2931,7 +2931,7 @@ EXPORT_SYMBOL_GPL(clk_is_match); > > #include > > > > static struct dentry *rootdir; > > -static int inited = 0; > > +static int inited; > > I think it's being explicit; although it is the same. Is this noticed by > some static checker or something? I'd like to ignore this patch if > possible. The Static variable initialized to 0 was noticed by the checkpatch. This error message was corrected. Would you want me to send a v2 with the proper commit text?
[PATCH] kbuild: replace sed with $(subst ) or $(patsubst )
For simple text replacement, it is better to use a built-in function instead of sed if possible. You can save one process forking. I do not mean to replace all sed invocations because GNU Make itself does not support regular expression (unless you use guile). I just replaced simple ones. Signed-off-by: Masahiro Yamada --- Documentation/devicetree/bindings/Makefile | 2 +- Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index 780e5618ec0a..ac446c62fbc3 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -48,7 +48,7 @@ define rule_chkdt $(call cmd,mk_schema) endef -DT_DOCS = $(shell $(find_cmd) | sed -e 's|^$(srctree)/||') +DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_cmd))) override DTC_FLAGS := \ -Wno-avoid_unnecessary_addr_size \ diff --git a/Makefile b/Makefile index 70fc39e6b677..0be138adae74 100644 --- a/Makefile +++ b/Makefile @@ -574,7 +574,7 @@ endif # Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile. # CC_VERSION_TEXT is referenced from Kconfig (so it needs export), # and from include/config/auto.conf.cmd to detect the compiler upgrade. -CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1 | sed 's/\#//g') +CC_VERSION_TEXT = $(subst $(pound),,$(shell $(CC) --version 2>/dev/null | head -n 1)) ifneq ($(findstring clang,$(CC_VERSION_TEXT)),) ifneq ($(CROSS_COMPILE),) -- 2.27.0
Re: [PATCH] docs: kbuild: Fix a typo in the file Kconfig.recursion-issue-02
On 3/13/21 8:30 PM, Bhaskar Chowdhury wrote: > > s/sematics/semantics/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > Documentation/kbuild/Kconfig.recursion-issue-02 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/kbuild/Kconfig.recursion-issue-02 > b/Documentation/kbuild/Kconfig.recursion-issue-02 > index df245fd7670d..0034eb494d11 100644 > --- a/Documentation/kbuild/Kconfig.recursion-issue-02 > +++ b/Documentation/kbuild/Kconfig.recursion-issue-02 > @@ -6,7 +6,7 @@ > # make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 > allnoconfig > # > # The recursive limitations with Kconfig has some non intuitive implications > on > -# kconfig sematics which are documented here. One known practical implication > +# kconfig semantics which are documented here. One known practical > implication > # of the recursive limitation is that drivers cannot negate features from > other > # drivers if they share a common core requirement and use disjoint semantics > to > # annotate those requirements, ie, some drivers use "depends on" while others > -- -- ~Randy
[PATCH v7 2/2] arm64: dts: qcom: Add sound node for sc7180-trogdor-coachz
This is a trgodor variant, required to have sound node variable
for coachz specific platform.
Signed-off-by: Srinivasa Rao Mandadapu
Reviewed-by: Stephen Boyd
---
arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
index 4ad520f00485..e2ffe71c2d52 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
@@ -89,6 +89,16 @@ _out {
data-lanes = <0 1 2 3>;
};
+ {
+ compatible = "google,sc7180-coachz";
+ model = "sc7180-adau7002-max98357a";
+ audio-routing = "PDM_DAT", "DMIC";
+};
+
+_multimedia0_codec {
+ sound-dai = <>;
+};
+
/* PINCTRL - modifications to sc7180-trogdor.dtsi */
_pp3300_dx_edp {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v7 1/2] arm64: dts: qcom: sc7180-trogdor: Add lpass dai link for I2S driver
From: Ajit Pandey
Add dai link for supporting lpass I2S driver, which is used
for audio capture and playback.
Add lpass-cpu node with pin controls and i2s primary
and secondary dai-links
Signed-off-by: Ajit Pandey
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao Mandadapu
---
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 58
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 436582279dad..fd345972a361 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
/* PMICs depend on spmi_bus label and so must come after SoC */
#include "pm6150.dtsi"
@@ -283,6 +284,42 @@ keyboard_backlight: keyboard-backlight {
max-brightness = <1023>;
};
};
+
+ sound: sound {
+ compatible = "google,sc7180-trogdor";
+ model = "sc7180-rt5682-max98357a-1mic";
+
+ audio-routing =
+ "Headphone Jack", "HPOL",
+ "Headphone Jack", "HPOR";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dai-link@0 {
+ link-name = "MultiMedia0";
+ reg = ;
+ cpu {
+ sound-dai = <_cpu MI2S_PRIMARY>;
+ };
+
+ sound_multimedia0_codec: codec {
+ sound-dai = < 0 /* aif1 */>;
+ };
+ };
+
+ dai-link@1 {
+ link-name = "MultiMedia1";
+ reg = ;
+ cpu {
+ sound-dai = <_cpu MI2S_SECONDARY>;
+ };
+
+ sound_multimedia1_codec: codec {
+ sound-dai = <>;
+ };
+ };
+ };
};
{
@@ -720,6 +757,27 @@ {
modem-init;
};
+_cpu {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_mi2s_active>, <_mi2s_active>,
<_mi2s_mclk_active>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mi2s@0 {
+ reg = ;
+ qcom,playback-sd-lines = <1>;
+ qcom,capture-sd-lines = <0>;
+ };
+
+ mi2s@1 {
+ reg = ;
+ qcom,playback-sd-lines = <0>;
+ };
+};
+
{
status = "okay";
};
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v7 0/2] Qualcomm's lpass device tree changes for I2s dai
These patches are device tree changes to support audio over I2S. Changes Since v6: -- Changed mi2s node names Changes Since v5: -- Removed lpass macro in codec dai cell -- Renamed multimedia dai codec alias name Changes Since v4: -- Removed duplication of dai-link in sound node. -- Replaced reg values with common dt-bindings macros in coachz dtsi -- Included sc7180-lpass.h instead of qcom,lpass.h -- Sound node placement change in coachz dtsi. Changes Since v3: -- Compatible name changed as per trogdor Changes Since v2: -- Sound node variable is added in sc7180-trogdor-coachz.dtsi. -- Audio-jack property is removed, as it may create conflicts with the boards having different codecs. -- Replaced reg values with common dt-bindings macros Changes Since v1: -- Ajith's Certification is added. -- Alias name added for sound dai link node Ajit Pandey (1): arm64: dts: qcom: sc7180-trogdor: Add lpass dai link for I2S driver Srinivasa Rao Mandadapu (1): arm64: dts: qcom: Add sound node for sc7180-trogdor-coachz .../boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 10 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 58 +++ 2 files changed, 68 insertions(+) -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH] kernel: trace: A typo fix in the file trace_event_perf.c
On 3/13/21 9:06 PM, Bhaskar Chowdhury wrote: > > s/suprises/surprises/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > kernel/trace/trace_event_perf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c > index a71181655958..d1eac45b79d2 100644 > --- a/kernel/trace/trace_event_perf.c > +++ b/kernel/trace/trace_event_perf.c > @@ -16,7 +16,7 @@ static char __percpu *perf_trace_buf[PERF_NR_CONTEXTS]; > > /* > * Force it to be aligned to unsigned long to avoid misaligned accesses > - * suprises > + * surprises > */ > typedef typeof(unsigned long [PERF_MAX_TRACE_SIZE / sizeof(unsigned long)]) > perf_trace_t; > -- -- ~Randy
Re: [PATCH] h8300: kernel: Spelling fix in the file irq.c
On 3/13/21 9:19 PM, Bhaskar Chowdhury wrote: > > s/writerble/writeable/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > arch/h8300/kernel/irq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/h8300/kernel/irq.c b/arch/h8300/kernel/irq.c > index 834e4d7b1bcf..4afa13db6774 100644 > --- a/arch/h8300/kernel/irq.c > +++ b/arch/h8300/kernel/irq.c > @@ -43,7 +43,7 @@ static unsigned long __init *get_vector_address(void) > /* ramvector base address */ > base -= EXT_IRQ0*4; > > - /* writerble? */ > + /* writeable? */ > tmp = ~(*(volatile unsigned long *)base); > (*(volatile unsigned long *)base) = tmp; > if ((*(volatile unsigned long *)base) != tmp) > -- -- ~Randy
Re: [PATCH] vfio: pci: Spello fix in the file vfio_pci.c
On 3/13/21 9:29 PM, Bhaskar Chowdhury wrote:
>
> s/permision/permission/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> drivers/vfio/pci/vfio_pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 706de3ef94bb..62f137692a4f 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -2411,7 +2411,7 @@ static int __init vfio_pci_init(void)
> {
> int ret;
>
> - /* Allocate shared config space permision data used by all devices */
> + /* Allocate shared config space permission data used by all devices */
> ret = vfio_pci_init_perm_bits();
> if (ret)
> return ret;
> --
--
~Randy
[PATCH 1/1] amdgpu: use MMIO to init atombios if device is Thunderbolt / USB4 attached
When using some Thunderbolt hosts using BIOS-assisted PCI enumeration
with IO BAR assigned, we get an atombios timeout, such as:
[drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 20secs
aborting
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck
executing B456 (len 304, WS 4, PS 0) @ 0xB51B
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck
executing B104 (len 183, WS 0, PS 8) @ 0xB17E
amdgpu :08:00.0: amdgpu: gpu post error!
amdgpu :08:00.0: amdgpu: Fatal error during GPU init
amdgpu: probe of :08:00.0 failed with error -22
A workaround is to use MMIO to access ATOMBIOS when device is
Thunderbolt / USB4 attached.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index 86add0f4e..5d16ec10d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -1999,11 +1999,15 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
atom_card_info->reg_read = cail_reg_read;
atom_card_info->reg_write = cail_reg_write;
/* needed for iio ops */
- if (adev->rio_mem) {
+ if (adev->rio_mem && !pci_is_thunderbolt_attached(adev->pdev)) {
atom_card_info->ioreg_read = cail_ioreg_read;
atom_card_info->ioreg_write = cail_ioreg_write;
} else {
- DRM_DEBUG("PCI I/O BAR is not found. Using MMIO to access ATOM
BIOS\n");
+ if (pci_is_thunderbolt_attached(adev->pdev))
+ DRM_DEBUG("Device is attached via Thunderbolt / USB4.
Using MMIO to access ATOM BIOS\n");
+ else
+ DRM_DEBUG("PCI I/O BAR is not found. Using MMIO to
access ATOM BIOS\n");
+
atom_card_info->ioreg_read = cail_reg_read;
atom_card_info->ioreg_write = cail_reg_write;
}
--
2.30.2
[PATCH 0/1] Init atombios timeout when amdgpu is Thunderbolt / USB4 when IO BAR is assigned
Hi all, I am not certain why this happens, but when IO bar is assigned on Thunderbolt, the amdgpu init fails: [drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 20secs aborting [drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing B456 (len 304, WS 4, PS 0) @ 0xB51B [drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing B104 (len 183, WS 0, PS 8) @ 0xB17E amdgpu :08:00.0: amdgpu: gpu post error! amdgpu :08:00.0: amdgpu: Fatal error during GPU init amdgpu: probe of :08:00.0 failed with error -22 It seems to happen mostly when BIOS-assisted PCI enumeration is used (older Thunderbolt systems). I cannot rule it out with native enumeration, but generally native enumeration works, as the IO BAR is not assigned, due to limited IO resources. This patch is a simple fix against v5.12-rc2. I have experienced this issue for a long time, and have finally decided to do something about it. I do not see a downside to using MMIO, which is required to be assigned. Kind regards, Nicholas Johnson Nicholas Johnson (1): amdgpu: use MMIO to init atombios if device is Thunderbolt / USB4 attached drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) -- 2.30.2
Re: [PATCH] tty: vt: Mundane typo fix in the file vt.c
On 3/13/21 3:38 PM, Bhaskar Chowdhury wrote: > > s/spurrious/spurious/ > > Signed-off-by: Bhaskar Chowdhury > --- > drivers/tty/vt/vt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c > index 284b07224c55..c29e16505dd9 100644 > --- a/drivers/tty/vt/vt.c > +++ b/drivers/tty/vt/vt.c > @@ -4448,7 +4448,7 @@ void poke_blanked_console(void) > might_sleep(); > > /* This isn't perfectly race free, but a race here would be mostly > harmless, > - * at worse, we'll do a spurrious blank and it's unlikely > + * at worse, we'll do a spurious blank and it's unlikely also: at worst, >*/ > del_timer(_timer); > blank_timer_expired = 0; > -- > 2.26.2 > -- ~Randy
ERROR: modpost: "__aeabi_unwind_cpp_pr0" undefined!
Hi Alexandru, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 88fe49249c99de14e543c632a46248d85411ab9e commit: b0bd407e94b036d597c6060d64c22094ff85b13c hwmon: (ltc2992) Add support date: 3 months ago config: arm-randconfig-r024-20210314 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project dfd27ebbd0eb137c9a439b7c537bb87ba903efd3) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm cross compiling tool for clang build # apt-get install binutils-arm-linux-gnueabi # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0bd407e94b036d597c6060d64c22094ff85b13c git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout b0bd407e94b036d597c6060d64c22094ff85b13c # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-ortek.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-monterey.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-microsoft.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-macally.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-lcpower.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-kye.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-ite.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-icade.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-gyration.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-glorious.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-gfrm.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-gembird.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-ezkey.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-emsff.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-corsair.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-chicony.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-belkin.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-aureal.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/uhid.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/crypto/inside-secure/crypto_safexcel.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/crypto/ccree/ccree.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-el15203000.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-dac124s085.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-wm8350.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-tlc591xx.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-pwm.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-pm8058.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-max8997.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-max77650.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lt3593.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lp8788.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lp50xx.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lp3952.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lp3944.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lm3601x.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lm3533.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lm3530.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-ktd2692.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-is31fl32xx.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-da903x.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-cpcap.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-aw2013.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-as3645a.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-aat1290.ko]
Re: [PATCH] gpu: drm: i915: gt: Rudimentary typo fix in the file intel_timeline.c
On 3/13/21 8:43 PM, Bhaskar Chowdhury wrote: > > s/bariers/barriers/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c > b/drivers/gpu/drm/i915/gt/intel_timeline.c > index 8015964043eb..2b921c1796dc 100644 > --- a/drivers/gpu/drm/i915/gt/intel_timeline.c > +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c > @@ -416,7 +416,7 @@ void intel_timeline_exit(struct intel_timeline *tl) > spin_unlock(>lock); > > /* > - * Since this timeline is idle, all bariers upon which we were waiting > + * Since this timeline is idle, all barriers upon which we were waiting >* must also be complete and so we can discard the last used barriers >* without loss of information. >*/ > -- -- ~Randy
Re: [PATCH v6 1/2] arm64: dts: qcom: sc7180-trogdor: Add lpass dai link for I2S driver
Hi Stephen,
Thanks for Your Time and Inputs!!!
On 3/14/2021 2:26 AM, Stephen Boyd wrote:
Quoting Srinivasa Rao Mandadapu (2021-03-12 21:46:53)
From: Ajit Pandey
Add dai link for supporting lpass I2S driver, which is used
for audio capture and playback.
Add lpass-cpu node with pin controls and i2s primary
Why two spaces before 'pin'?
and secondary dai-links
Please end sentence with a period.
Signed-off-by: Ajit Pandey
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao Mandadapu
---
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 58
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 436582279dad..3a24383247db 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -283,6 +284,42 @@ keyboard_backlight: keyboard-backlight {
max-brightness = <1023>;
};
};
+
+ sound: sound {
+ compatible = "google,sc7180-trogdor";
+ model = "sc7180-rt5682-max98357a-1mic";
+
+ audio-routing =
+ "Headphone Jack", "HPOL",
+ "Headphone Jack", "HPOR";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dai-link@0 {
+ link-name = "MultiMedia0";
+ reg = ;
+ cpu {
+ sound-dai = <_cpu MI2S_PRIMARY>;
+ };
+
+ sound_multimedia0_codec: codec {
+ sound-dai = < 0 /*aif1*/>;
Nitpick, add a space for comment
sound-dai = < 0 /* aif1 */>;
Okay. Will re post with Fix.
+ };
+ };
+
+ dai-link@1 {
+ link-name = "MultiMedia1";
+ reg = ;
+ cpu {
+ sound-dai = <_cpu MI2S_SECONDARY>;
+ };
+
+ sound_multimedia1_codec: codec {
+ sound-dai = <>;
+ };
+ };
+ };
};
{
@@ -720,6 +757,27 @@ {
modem-init;
};
+_cpu {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_mi2s_active _mi2s_active _mi2s_mclk_active>;
Super nitpick: I prefer this style
pinctrl-0 = <_mi2s_active>, <_mi2s_active>,
<_mi2s_mclk_active>;
It's effectively the same but the brackets help us see that these are
the end of the phandle specifier instead of having to figure out that
the first phandle isn't specifying the second phandle as an argument.
Okay. Will change accordingly.
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mi2s-primary@0 {
Should the node name just be mi2s instead of mi2s-primary? We have reg
property so I think 'mi2s' should be sufficient to differentiate.
Okay. I will change it as mi2s@0 instead of mi2s-primary@0
+ reg = ;
+ qcom,playback-sd-lines = <1>;
+ qcom,capture-sd-lines = <0>;
+ };
+
+ mi2s-secondary@1 {
+ reg = ;
+ qcom,playback-sd-lines = <0>;
+ };
+};
+
{
status = "okay";
};
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH] vfio: pci: Spello fix in the file vfio_pci.c
s/permision/permission/
Signed-off-by: Bhaskar Chowdhury
---
drivers/vfio/pci/vfio_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 706de3ef94bb..62f137692a4f 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -2411,7 +2411,7 @@ static int __init vfio_pci_init(void)
{
int ret;
- /* Allocate shared config space permision data used by all devices */
+ /* Allocate shared config space permission data used by all devices */
ret = vfio_pci_init_perm_bits();
if (ret)
return ret;
--
2.26.2
[PATCH] h8300: kernel: Spelling fix in the file irq.c
s/writerble/writeable/ Signed-off-by: Bhaskar Chowdhury --- arch/h8300/kernel/irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/h8300/kernel/irq.c b/arch/h8300/kernel/irq.c index 834e4d7b1bcf..4afa13db6774 100644 --- a/arch/h8300/kernel/irq.c +++ b/arch/h8300/kernel/irq.c @@ -43,7 +43,7 @@ static unsigned long __init *get_vector_address(void) /* ramvector base address */ base -= EXT_IRQ0*4; - /* writerble? */ + /* writeable? */ tmp = ~(*(volatile unsigned long *)base); (*(volatile unsigned long *)base) = tmp; if ((*(volatile unsigned long *)base) != tmp) -- 2.26.2
Re: Why is the bit size different between a syscall and its wrapper?
Willy,
Thanks for the explanation.
On Fri, Mar 12, 2021 at 12:27 PM Willy Tarreau wrote:
>
> On Fri, Mar 12, 2021 at 11:48:11AM +0900, Masahiro Yamada wrote:
> > Hi.
> >
> > I think I am missing something, but
> > is there any particular reason to
> > use a different bit size between
> > a syscall and its userspace wrapper?
> >
> >
> >
> > For example, for the unshare syscall,
> >
> > unshare(2) says the parameter is int.
> >
> >
> > SYNOPSIS
> >#define _GNU_SOURCE
> >#include
> >
> >int unshare(int flags);
> >
> >
> >
> >
> > In the kernel, it is unsigned long.
> >
> >
> > SYSCALL_DEFINE1(unshare, unsigned long, unshare_flags)
> > {
> > return ksys_unshare(unshare_flags);
> > }
>
> The syscalls must have a well defined interface for a given architecture.
> Thus in practice the ABI will define that arg1 goes into this register,
> arg2 into this one etc, regardless of their type (plenty of them are
> pointers for example). The long is the size of a register so it can carry
> any of the types we care about. So by defining each syscall as a function
> taking 1 to 6 fixed-size arguments you can implement about all syscalls.
>
> Regarding the libc, it has to offer an interface which is compatible with
> the standard definition of the syscalls as defined by POSIX or as commonly
> found on other OSes, and this regardless of the platform.
>
> For example look at recv(), it takes an int, a pointer, a size_t and an
> int. It requires to be defined like this for portability, but at the OS
> level all these will typically be passed as a register each.
>
You are right.
Functions in POSIX such as 'recv' should be portable with other OSes.
For the syscall ABI level, we have more freedom to choose
parameter types more convenient for the kernel.
IIUC, 'unshare' seems to be Linux-specific, and
I think "other OSes" do not exist.
Using types that have the same width as registers
avoids the ambiguity about the upper 32-bits
in 64-bit registers anyway. This is a benefit.
Historically, it caused a issue:
https://nvd.nist.gov/vuln/detail/CVE-2009-0029
We do not need to be worried since
commit 1a94bc34768e463a93cb3751819709ab0ea80a01.
All parameters are properly sign-extended by
forcibly casting to (long).
--
Best Regards
Masahiro Yamada
Re: [PATCH 2/2] usb: cdns3: Optimize DMA request buffer allocation
On 21-03-09 06:19:40, Sanket Parmar wrote:
> dma_alloc_coherent() might fail on the platform with a small DMA region.
>
> To avoid such failure in cdns3_prepare_aligned_request_buf(),
> dma_alloc_coherent() is replaced with kmalloc and dma_map API to
> allocate aligned request buffer of dynamic length.
>
> Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
The comment with the 1st patch, it is not a bug-fix.
> Reported-by: Aswath Govindraju
> Signed-off-by: Sanket Parmar
> ---
> drivers/usb/cdns3/cdns3-gadget.c | 73 +
> drivers/usb/cdns3/cdns3-gadget.h |2 +
> 2 files changed, 51 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/usb/cdns3/cdns3-gadget.c
> b/drivers/usb/cdns3/cdns3-gadget.c
> index 5f51215..b4955ce 100644
> --- a/drivers/usb/cdns3/cdns3-gadget.c
> +++ b/drivers/usb/cdns3/cdns3-gadget.c
> @@ -818,10 +818,26 @@ void cdns3_gadget_giveback(struct cdns3_endpoint
> *priv_ep,
> usb_gadget_unmap_request_by_dev(priv_dev->sysdev, request,
> priv_ep->dir);
>
> - if ((priv_req->flags & REQUEST_UNALIGNED) &&
> - priv_ep->dir == USB_DIR_OUT && !request->status)
> - memcpy(request->buf, priv_req->aligned_buf->buf,
> -request->length);
> + if ((priv_req->flags & REQUEST_UNALIGNED) && priv_req->aligned_buf) {
> + struct cdns3_aligned_buf *buf;
> +
> + buf = priv_req->aligned_buf;
> + dma_unmap_single(priv_dev->sysdev, buf->dma, buf->size,
> + buf->dir);
> + priv_req->flags &= ~REQUEST_UNALIGNED;
> +
> + if (priv_ep->dir == USB_DIR_OUT && !request->status) {
> + memcpy(request->buf, priv_req->aligned_buf->buf,
> +request->length);
> + }
> +
> + trace_cdns3_free_aligned_request(priv_req);
> + priv_req->aligned_buf->in_use = 0;
> + queue_work(system_freezable_wq,
> +_dev->aligned_buf_wq);
> + priv_req->aligned_buf = NULL;
> +
> + }
>
> priv_req->flags &= ~(REQUEST_PENDING | REQUEST_UNALIGNED);
> /* All TRBs have finished, clear the counter */
> @@ -883,8 +899,7 @@ static void cdns3_free_aligned_request_buf(struct
> work_struct *work)
>* interrupts.
>*/
> spin_unlock_irqrestore(_dev->lock, flags);
> - dma_free_coherent(priv_dev->sysdev, buf->size,
> - buf->buf, buf->dma);
> + kfree(buf->buf);
> kfree(buf);
> spin_lock_irqsave(_dev->lock, flags);
> }
> @@ -910,27 +925,16 @@ static int cdns3_prepare_aligned_request_buf(struct
> cdns3_request *priv_req)
> if (!buf)
> return -ENOMEM;
>
> - buf->size = priv_req->request.length;
> + buf->size = usb_endpoint_dir_out(priv_ep->endpoint.desc) ?
> + usb_ep_align(&(priv_ep->endpoint),
> priv_req->request.length)
> + : priv_req->request.length;
>
> - buf->buf = dma_alloc_coherent(priv_dev->sysdev,
> - buf->size,
> - >dma,
> - GFP_ATOMIC);
> + buf->buf = kmalloc(buf->size, GFP_ATOMIC);
> if (!buf->buf) {
> kfree(buf);
> return -ENOMEM;
> }
>
> - if (priv_req->aligned_buf) {
> - trace_cdns3_free_aligned_request(priv_req);
> - priv_req->aligned_buf->in_use = 0;
> - queue_work(system_freezable_wq,
> -_dev->aligned_buf_wq);
> - }
> -
> - buf->in_use = 1;
> - priv_req->aligned_buf = buf;
> -
> list_add_tail(>list,
> _dev->aligned_buf_list);
> }
> @@ -940,6 +944,27 @@ static int cdns3_prepare_aligned_request_buf(struct
> cdns3_request *priv_req)
> priv_req->request.length);
> }
>
> + if (priv_req->aligned_buf) {
> + trace_cdns3_free_aligned_request(priv_req);
> + priv_req->aligned_buf->in_use = 0;
> + queue_work(system_freezable_wq,
> +_dev->aligned_buf_wq);
@Pawel, do you remember when this condition is met?
> + }
> +
> + buf->dir = priv_ep->dir ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
> + buf->in_use = 1;
> + priv_req->aligned_buf = buf;
> +
> + buf->dma = dma_map_single(priv_dev->sysdev, buf->buf, buf->size,
> + buf->dir);
> +
> + if (dma_mapping_error(priv_dev->sysdev, buf->dma)) {
> + dev_err(priv_dev->dev,
Re: [PATCH v3 2/3] mm: disable LRU pagevec during the migration temporarily
On 2021-03-11 14:41, Chris Goldsworthy wrote:
On 2021-03-10 08:14, Minchan Kim wrote:
LRU pagevec holds refcount of pages until the pagevec are drained.
It could prevent migration since the refcount of the page is greater
than the expection in migration logic. To mitigate the issue,
callers of migrate_pages drains LRU pagevec via migrate_prep or
lru_add_drain_all before migrate_pages call.
However, it's not enough because pages coming into pagevec after the
draining call still could stay at the pagevec so it could keep
preventing page migration. Since some callers of migrate_pages have
retrial logic with LRU draining, the page would migrate at next trail
but it is still fragile in that it doesn't close the fundamental race
between upcoming LRU pages into pagvec and migration so the migration
failure could cause contiguous memory allocation failure in the end.
To close the race, this patch disables lru caches(i.e, pagevec)
during ongoing migration until migrate is done.
Since it's really hard to reproduce, I measured how many times
migrate_pages retried with force mode(it is about a fallback to a
sync migration) with below debug code.
int migrate_pages(struct list_head *from, new_page_t get_new_page,
..
..
if (rc && reason == MR_CONTIG_RANGE && pass > 2) {
printk(KERN_ERR, "pfn 0x%lx reason %d\n", page_to_pfn(page),
rc);
dump_page(page, "fail to migrate");
}
The test was repeating android apps launching with cma allocation
in background every five seconds. Total cma allocation count was
about 500 during the testing. With this patch, the dump_page count
was reduced from 400 to 30.
The new interface is also useful for memory hotplug which currently
drains lru pcp caches after each migration failure. This is rather
suboptimal as it has to disrupt others running during the operation.
With the new interface the operation happens only once. This is also
in
line with pcp allocator cache which are disabled for the offlining as
well.
Signed-off-by: Minchan Kim
---
Hi Minchan,
This all looks good to me - feel free to add a Reviewed-by from me.
Thanks,
Chris.
Should have added:
Reviewed-by: Chris Goldsworthy
--
The Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
[PATCH] kernel: trace: A typo fix in the file trace_event_perf.c
s/suprises/surprises/ Signed-off-by: Bhaskar Chowdhury --- kernel/trace/trace_event_perf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c index a71181655958..d1eac45b79d2 100644 --- a/kernel/trace/trace_event_perf.c +++ b/kernel/trace/trace_event_perf.c @@ -16,7 +16,7 @@ static char __percpu *perf_trace_buf[PERF_NR_CONTEXTS]; /* * Force it to be aligned to unsigned long to avoid misaligned accesses - * suprises + * surprises */ typedef typeof(unsigned long [PERF_MAX_TRACE_SIZE / sizeof(unsigned long)]) perf_trace_t; -- 2.26.2
Re: [PATCH v4 03/25] mm/vmstat: Add functions to account folio statistics
On Sun, 14 Mar 2021 04:11:55 + Matthew Wilcox wrote:
> On Sat, Mar 13, 2021 at 12:37:07PM -0800, Andrew Morton wrote:
> > On Fri, 5 Mar 2021 04:18:39 + "Matthew Wilcox (Oracle)"
> > wrote:
> >
> > > Allow page counters to be more readily modified by callers which have
> > > a folio. Name these wrappers with 'stat' instead of 'state' as requested
> > > by Linus here:
> > > https://lore.kernel.org/linux-mm/CAHk-=wj847sudr-kt+46ft3+xffgiwpgthvm7djwgdi4cvr...@mail.gmail.com/
> > >
> > > --- a/include/linux/vmstat.h
> > > +++ b/include/linux/vmstat.h
> > > @@ -402,6 +402,54 @@ static inline void drain_zonestat(struct zone *zone,
> > > struct per_cpu_pageset *pset) { }
> > > #endif /* CONFIG_SMP */
> > >
> > > +static inline
> > > +void __inc_zone_folio_stat(struct folio *folio, enum zone_stat_item item)
> > > +{
> > > + __mod_zone_page_state(folio_zone(folio), item, folio_nr_pages(folio));
> > > +}
> >
> > The naming is unfortunate. We expect
> >
> > inc: add one to
> > dec: subtract one from
> > mod: modify by signed quantity
> >
> > So these are inconsistent. Perhaps use "add" and "sub" instead. At
> > least to alert people to the fact that these are different.
> >
> > And, again, it's nice to see the subsystem's name leading the
> > identifiers, so "zone_folio_stat_add()".
>
> I thought this was a 'zone stat', so __zone_stat_add_folio()?
> I'm not necessarily signing up to change the existing
> __inc_node_page_state(), but I might. If so, __node_stat_add_page()?
That works. It's the "inc means +1" and "dec means -1" whiplash that
struck me the most.
[bisected] Re: nouveau: lockdep cli->mutex vs reservation_ww_class_mutex deadlock report
This little bugger bisected to...
b73cd1e2ebfc "drm/ttm: stop destroying pinned ghost object"
...and (the second time around) was confirmed on the spot. However,
while the fingered commit still reverts cleanly, doing so at HEAD does
not make lockdep return to happy camper state (leading to bisection
#2), ie the fingered commit is only the beginning of nouveau's 5.12
cycle lockdep woes.
homer:..kernel/linux-master # quilt applied|grep revert
patches/revert-drm-ttm-Remove-pinned-bos-from-LRU-in-ttm_bo_move_to_lru_tail-v2.patch
patches/revert-drm-ttm-cleanup-LRU-handling-further.patch
patches/revert-drm-ttm-use-pin_count-more-extensively.patch
patches/revert-drm-ttm-stop-destroying-pinned-ghost-object.patch
That still ain't enough to appease lockdep at HEAD. I'm not going to
muck about with it beyond that, since this looks a whole lot like yet
another example of "fixing stuff exposes other busted stuff".
On Wed, 2021-03-10 at 10:58 +0100, Mike Galbraith wrote:
> [ 29.966927] ==
> [ 29.966929] WARNING: possible circular locking dependency detected
> [ 29.966932] 5.12.0.g05a59d7-master #2 Tainted: GW E
> [ 29.966934] --
> [ 29.966937] X/2145 is trying to acquire lock:
> [ 29.966939] 888120714518 (>mutex){+.+.}-{3:3}, at:
> nouveau_bo_move+0x11f/0x980 [nouveau]
> [ 29.967002]
>but task is already holding lock:
> [ 29.967004] 888123c201a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
> nouveau_bo_pin+0x2b/0x310 [nouveau]
> [ 29.967053]
>which lock already depends on the new lock.
>
> [ 29.967056]
>the existing dependency chain (in reverse order) is:
> [ 29.967058]
>-> #1 (reservation_ww_class_mutex){+.+.}-{3:3}:
> [ 29.967063]__ww_mutex_lock.constprop.16+0xbe/0x10d0
> [ 29.967069]nouveau_bo_pin+0x2b/0x310 [nouveau]
> [ 29.967112]nouveau_channel_prep+0x106/0x2e0 [nouveau]
> [ 29.967151]nouveau_channel_new+0x4f/0x760 [nouveau]
> [ 29.967188]nouveau_abi16_ioctl_channel_alloc+0xdf/0x350 [nouveau]
> [ 29.967223]drm_ioctl_kernel+0x91/0xe0 [drm]
> [ 29.967245]drm_ioctl+0x2db/0x380 [drm]
> [ 29.967259]nouveau_drm_ioctl+0x56/0xb0 [nouveau]
> [ 29.967303]__x64_sys_ioctl+0x76/0xb0
> [ 29.967307]do_syscall_64+0x33/0x40
> [ 29.967310]entry_SYSCALL_64_after_hwframe+0x44/0xae
> [ 29.967314]
>-> #0 (>mutex){+.+.}-{3:3}:
> [ 29.967318]__lock_acquire+0x1494/0x1ac0
> [ 29.967322]lock_acquire+0x23e/0x3b0
> [ 29.967325]__mutex_lock+0x95/0x9d0
> [ 29.967330]nouveau_bo_move+0x11f/0x980 [nouveau]
> [ 29.967377]ttm_bo_handle_move_mem+0x79/0x130 [ttm]
> [ 29.967384]ttm_bo_validate+0x156/0x1b0 [ttm]
> [ 29.967390]nouveau_bo_validate+0x48/0x70 [nouveau]
> [ 29.967438]nouveau_bo_pin+0x1de/0x310 [nouveau]
> [ 29.967487]nv50_wndw_prepare_fb+0x53/0x4d0 [nouveau]
> [ 29.967531]drm_atomic_helper_prepare_planes+0x8a/0x110
> [drm_kms_helper]
> [ 29.967547]nv50_disp_atomic_commit+0xa9/0x1b0 [nouveau]
> [ 29.967593]drm_atomic_helper_update_plane+0x10a/0x150
> [drm_kms_helper]
> [ 29.967606]drm_mode_cursor_universal+0x10b/0x220 [drm]
> [ 29.967627]drm_mode_cursor_common+0x190/0x200 [drm]
> [ 29.967648]drm_mode_cursor_ioctl+0x3d/0x50 [drm]
> [ 29.967669]drm_ioctl_kernel+0x91/0xe0 [drm]
> [ 29.967684]drm_ioctl+0x2db/0x380 [drm]
> [ 29.967699]nouveau_drm_ioctl+0x56/0xb0 [nouveau]
> [ 29.967748]__x64_sys_ioctl+0x76/0xb0
> [ 29.967752]do_syscall_64+0x33/0x40
> [ 29.967756]entry_SYSCALL_64_after_hwframe+0x44/0xae
> [ 29.967760]
>other info that might help us debug this:
>
> [ 29.967764] Possible unsafe locking scenario:
>
> [ 29.967767]CPU0CPU1
> [ 29.967770]
> [ 29.967772] lock(reservation_ww_class_mutex);
> [ 29.967776]lock(>mutex);
> [ 29.967779]
> lock(reservation_ww_class_mutex);
> [ 29.967783] lock(>mutex);
> [ 29.967786]
> *** DEADLOCK ***
>
> [ 29.967790] 3 locks held by X/2145:
> [ 29.967792] #0: 88810365bcf8 (crtc_ww_class_acquire){+.+.}-{0:0}, at:
> drm_mode_cursor_common+0x87/0x200 [drm]
> [ 29.967817] #1: 888108d9e098 (crtc_ww_class_mutex){+.+.}-{3:3}, at:
> drm_modeset_lock+0xc3/0xe0 [drm]
> [ 29.967841] #2: 888123c201a0
> (reservation_ww_class_mutex){+.+.}-{3:3}, at: nouveau_bo_pin+0x2b/0x310
> [nouveau]
> [ 29.967896]
>stack backtrace:
> [ 29.967899] CPU: 6 PID: 2145 Comm: X Kdump: loaded Tainted: GW E
> 5.12.0.g05a59d7-master #2
> [ 29.967904]
[PATCH] gpu: drm: i915: gt: Rudimentary typo fix in the file intel_timeline.c
s/bariers/barriers/ Signed-off-by: Bhaskar Chowdhury --- drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c b/drivers/gpu/drm/i915/gt/intel_timeline.c index 8015964043eb..2b921c1796dc 100644 --- a/drivers/gpu/drm/i915/gt/intel_timeline.c +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c @@ -416,7 +416,7 @@ void intel_timeline_exit(struct intel_timeline *tl) spin_unlock(>lock); /* -* Since this timeline is idle, all bariers upon which we were waiting +* Since this timeline is idle, all barriers upon which we were waiting * must also be complete and so we can discard the last used barriers * without loss of information. */ -- 2.26.2
Re: [PATCH 2/3] net: ethernet: actions: Add Actions Semi Owl Ethernet MAC driver
> > > + if (phy->interface != PHY_INTERFACE_MODE_RMII) {
> > > + netdev_err(netdev, "unsupported phy mode: %s\n",
> > > +phy_modes(phy->interface));
> > > + phy_disconnect(phy);
> > > + netdev->phydev = NULL;
> > > + return -EINVAL;
> > > + }
> >
> > It looks like the MAC only supports symmetric pause. So you should
> > call phy_set_sym_pause() to let the PHY know this.
>
> I did not find any reference related to the supported pause types,
> is this normally dependant on the PHY interface mode?
There is a MAC / PHY split there. The PHY is responsible for the
negotiation for what each end can do. But it is the MAC which actually
implements pause. The MAC needs to listen to pause frames and not send
out data frames when the link peer indicates pause. And the MAC needs
to send a pause frames when its receive buffers are full. The code you
have in this MAC driver seems to indicate the MAC only supports
symmetric pause. Hence you need to configure the PHY to only auto-neg
symmetric pause.
> > > + ret = crypto_skcipher_encrypt(req);
> > > + if (ret) {
> > > + dev_err(dev, "failed to encrypt S/N: %d\n", ret);
> > > + goto err_free_tfm;
> > > + }
> > > +
> > > + netdev->dev_addr[0] = 0xF4;
> > > + netdev->dev_addr[1] = 0x4E;
> > > + netdev->dev_addr[2] = 0xFD;
> >
> > 0xF4 has the locally administered bit 0. So this is a true OUI. Who
> > does it belong to? Ah!
> >
> > F4:4E:FD Actions Semiconductor Co.,Ltd.(Cayman Islands)
> >
> > Which makes sense. But is there any sort of agreement this is allowed?
> > It is going to cause problems if they are giving out these MAC
> > addresses in a controlled way.
>
> Unfortunately this is another undocumented logic taken from the vendor
> code. I have already disabled it from being built by default, although,
> personally, I prefer to have it enabled in order to get a stable MAC
> address instead of using a randomly generated one or manually providing
> it via DT.
>
> Just for clarification, I did not have any agreement or preliminary
> discussion with the vendor. This is just a personal initiative to
> improve the Owl SoC support in the mainline kernel.
>
> > Maybe it would be better to set bit 1 of byte 0? And then you can use
> > 5 bytes from enc_sn, not just 4.
>
> I included the MAC generation feature in the driver to be fully
> compatible with the original implementation, but I'm open for changes
> if it raises concerns and compatibility is less important.
This is not a simple question to answer. If the vendor driver does
this, then the vendor can never assign MAC addresses in a controlled
way, unless they have a good idea how the algorithm turns serial
numbers into MAC addresses, and they can avoid MAC addresses for
serial numbers already issued.
But should the Linux kernel do the same? If all you want is a stable
MAC address, my personal preference would be to set the locally
administered bit, and fill the other 5 bytes from the hash
algorithm. You then have a stable MAC addresses, but you clearly
indicate it is not guaranteed to by globally unique, and you do not
need to worry about what the vendor is doing.
> > Otherwise, this look a new clean driver.
>
> Well, I tried to do my best, given my limited experience as a self-taught
> kernel developer. Hopefully reviewing my code will not cause too many
> headaches! :)
This is actually above average for a self-taught kernel
developer. Well done.
Andrew
[PATCH] docs: kbuild: Fix a typo in the file Kconfig.recursion-issue-02
s/sematics/semantics/ Signed-off-by: Bhaskar Chowdhury --- Documentation/kbuild/Kconfig.recursion-issue-02 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kbuild/Kconfig.recursion-issue-02 b/Documentation/kbuild/Kconfig.recursion-issue-02 index df245fd7670d..0034eb494d11 100644 --- a/Documentation/kbuild/Kconfig.recursion-issue-02 +++ b/Documentation/kbuild/Kconfig.recursion-issue-02 @@ -6,7 +6,7 @@ # make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig # # The recursive limitations with Kconfig has some non intuitive implications on -# kconfig sematics which are documented here. One known practical implication +# kconfig semantics which are documented here. One known practical implication # of the recursive limitation is that drivers cannot negate features from other # drivers if they share a common core requirement and use disjoint semantics to # annotate those requirements, ie, some drivers use "depends on" while others -- 2.26.2
Re: [PATCH] mm: Allow shmem mappings with MREMAP_DONTUNMAP
On Wed, 3 Mar 2021, Brian Geffon wrote:
> Currently MREMAP_DONTUNMAP only accepts private anonymous mappings. This
> change
> will widen the support to include shmem mappings. The primary use case
> is to support MREMAP_DONTUNMAP on mappings which may have been created from
> a memfd.
>
> Lokesh Gidra who works on the Android JVM, provided an explanation of how such
> a feature will improve Android JVM garbage collection:
> "Android is developing a new garbage collector (GC), based on userfaultfd. The
> garbage collector will use userfaultfd (uffd) on the java heap during
> compaction.
> On accessing any uncompacted page, the application threads will find it
> missing,
> at which point the thread will create the compacted page and then use
> UFFDIO_COPY
> ioctl to get it mapped and then resume execution. Before starting this
> compaction,
> in a stop-the-world pause the heap will be mremap(MREMAP_DONTUNMAP) so that
> the
> java heap is ready to receive UFFD_EVENT_PAGEFAULT events after resuming
> execution.
>
> To speedup mremap operations, pagetable movement was optimized by moving PUD
> entries
> instead of PTE entries [1]. It was necessary as mremap of even modest sized
> memory
> ranges also took several milliseconds, and stopping the application for that
> long
> isn't acceptable in response-time sensitive cases. With UFFDIO_CONTINUE
> feature [2],
> it will be even more efficient to implement this GC, particularly the
> 'non-moveable'
> portions of the heap. It will also help in reducing the need to copy
> (UFFDIO_COPY)
> the pages. However, for this to work, the java heap has to be on a 'shared'
> vma.
> Currently MREMAP_DONTUNMAP only supports private anonymous mappings, this
> patch will
> enable using UFFDIO_CONTINUE for the new userfaultfd-based heap compaction."
>
> [1]
> https://lore.kernel.org/linux-mm/20201215030730.nc3cu98e4%25a...@linux-foundation.org/
> [2]
> https://lore.kernel.org/linux-mm/20210302000133.272579-1-axelrasmus...@google.com/
> ---
> mm/mremap.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/mm/mremap.c b/mm/mremap.c
> index ec8f840399ed..6934d199da54 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -653,8 +653,7 @@ static struct vm_area_struct *vma_to_resize(unsigned long
> addr,
> return ERR_PTR(-EINVAL);
> }
>
> - if (flags & MREMAP_DONTUNMAP && (!vma_is_anonymous(vma) ||
> - vma->vm_flags & VM_SHARED))
> + if (flags & MREMAP_DONTUNMAP && !(vma_is_anonymous(vma) ||
> vma_is_shmem(vma)))
> return ERR_PTR(-EINVAL);
>
> if (is_vm_hugetlb_page(vma))
> --
Yet something to improve...
Thanks for extending MREMAP_DONTUNMAP to shmem, but I think this patch
goes in the wrong direction, complicating when it should be generalizing:
the mremap syscall is about rearranging the user's virtual address space,
and is not specific to the underlying anonymous or shmem or file object
(though so far you have only been interested in anonymous, and now shmem).
A better patch would say:
- if (flags & MREMAP_DONTUNMAP && (!vma_is_anonymous(vma) ||
- vma->vm_flags & VM_SHARED))
+ if ((flags & MREMAP_DONTUNMAP) &&
+ (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP)))
return ERR_PTR(-EINVAL);
VM_DONTEXPAND is what has long been used on special mappings, to prevent
surprises from mremap changing the size of the mapping: MREMAP_DONTUNMAP
introduced a different way of expanding the mapping, so VM_DONTEXPAND
still seems a reasonable name (I've thrown in VM_PFNMAP there because
it's in the VM_DONTEXPAND test lower down: for safety I guess, and best
if both behave the same - though one says -EINVAL and the other -EFAULT).
With that VM_DONTEXPAND check in, Dmitry's commit cd544fd1dc92
("mremap: don't allow MREMAP_DONTUNMAP on special_mappings and aio")
can still be reverted (as you agreed on 28th December), even though
vma_is_anonymous() will no longer protect it.
Was there an mremap(2) man page update for MREMAP_DONTUNMAP?
Whether or not there was before, it ought to get one now.
Thanks,
Hugh
Re: [PATCH 6/6] arm64: dts: qcom: sc7280: Add nodes to boot WPSS
On Sat 13 Mar 15:46 CST 2021, Stephen Boyd wrote:
> Quoting Sibi Sankar (2021-03-08 21:51:51)
> > Add miscellaneous nodes to boot the Wireless Processor Subsystem on
>
> Maybe add (WPSS) after the name so we know they're related.
>
> > SC7280 SoCs.
> >
> > Signed-off-by: Sibi Sankar
> > ---
> >
> > https://patchwork.kernel.org/project/linux-arm-msm/list/?series=438217
> > Depends on ipcc dt node enablement from ^^
> >
> > arch/arm64/boot/dts/qcom/sc7280.dtsi | 143
> > +++
> > 1 file changed, 143 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > index 18637c369c1d..4f03c468df51 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > @@ -244,12 +251,131 @@
> > reg = <0 0x8000 0 0>;
> > };
> >
> > + tcsr_mutex: hwlock {
> > + compatible = "qcom,tcsr-mutex";
> > + syscon = <_mutex_regs 0 0x1000>;
> > + #hwlock-cells = <1>;
> > + };
>
> Is this node in the right place? I think the node above it is 'memory'?
> In which case 'hwlock' comes before 'memory' alphabetically.
>
Thanks for spotting this, as it's no longer acceptable to have a
standalone "syscon" node I was asked to rewrite the binding for this a
few months ago. So the tcsr_mutex should now be represented with a reg
under /soc.
> > +
> > + smem {
> > + compatible = "qcom,smem";
> > + memory-region = <_mem>;
> > + hwlocks = <_mutex 3>;
> > + };
> > +
> > firmware {
> > scm {
> > compatible = "qcom,scm-sc7280", "qcom,scm";
> > };
> > };
> >
> > + smp2p-adsp {
> > + compatible = "qcom,smp2p";
> > + qcom,smem = <443>, <429>;
> > + interrupts-extended = < IPCC_CLIENT_LPASS
> > +IPCC_MPROC_SIGNAL_SMP2P
> > +IRQ_TYPE_EDGE_RISING>;
> > + mboxes = < IPCC_CLIENT_LPASS
> > + IPCC_MPROC_SIGNAL_SMP2P>;
> > +
> > + qcom,local-pid = <0>;
> > + qcom,remote-pid = <2>;
> > +
> > + adsp_smp2p_out: master-kernel {
> > + qcom,entry-name = "master-kernel";
> > + #qcom,smem-state-cells = <1>;
> > + };
> > +
> > + adsp_smp2p_in: slave-kernel {
> > + qcom,entry-name = "slave-kernel";
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + };
> > + };
> > +
> > + smp2p-cdsp {
> > + compatible = "qcom,smp2p";
> > + qcom,smem = <94>, <432>;
> > + interrupts-extended = < IPCC_CLIENT_CDSP
> > +IPCC_MPROC_SIGNAL_SMP2P
> > +IRQ_TYPE_EDGE_RISING>;
> > + mboxes = < IPCC_CLIENT_CDSP
> > + IPCC_MPROC_SIGNAL_SMP2P>;
> > +
> > + qcom,local-pid = <0>;
> > + qcom,remote-pid = <5>;
> > +
> > + cdsp_smp2p_out: master-kernel {
> > + qcom,entry-name = "master-kernel";
> > + #qcom,smem-state-cells = <1>;
> > + };
> > +
> > + cdsp_smp2p_in: slave-kernel {
> > + qcom,entry-name = "slave-kernel";
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + };
> > + };
> > +
> > + smp2p-mpss {
> > + compatible = "qcom,smp2p";
> > + qcom,smem = <435>, <428>;
> > + interrupts-extended = < IPCC_CLIENT_MPSS
> > +IPCC_MPROC_SIGNAL_SMP2P
> > +IRQ_TYPE_EDGE_RISING>;
> > + mboxes = < IPCC_CLIENT_MPSS
> > + IPCC_MPROC_SIGNAL_SMP2P>;
> > +
> > + qcom,local-pid = <0>;
> > + qcom,remote-pid = <1>;
> > +
> > + modem_smp2p_out: master-kernel {
> > + qcom,entry-name = "master-kernel";
> > + #qcom,smem-state-cells = <1>;
> > + };
> > +
> > + modem_smp2p_in: slave-kernel {
> > + qcom,entry-name = "slave-kernel";
>
> Do these names need to have 'master' and 'slave' in them? We're trying
> to avoid these terms. See Documentation/process/coding-style.rst Section
> 4 naming.
>
They need to match the naming in the firmware, but I would welcome a
future change to something in line with the coding style and simply more
descriptive.
Regards,
Bjorn
> > +
Re: [PATCH v4 03/25] mm/vmstat: Add functions to account folio statistics
On Sat, Mar 13, 2021 at 12:37:07PM -0800, Andrew Morton wrote:
> On Fri, 5 Mar 2021 04:18:39 + "Matthew Wilcox (Oracle)"
> wrote:
>
> > Allow page counters to be more readily modified by callers which have
> > a folio. Name these wrappers with 'stat' instead of 'state' as requested
> > by Linus here:
> > https://lore.kernel.org/linux-mm/CAHk-=wj847sudr-kt+46ft3+xffgiwpgthvm7djwgdi4cvr...@mail.gmail.com/
> >
> > --- a/include/linux/vmstat.h
> > +++ b/include/linux/vmstat.h
> > @@ -402,6 +402,54 @@ static inline void drain_zonestat(struct zone *zone,
> > struct per_cpu_pageset *pset) { }
> > #endif /* CONFIG_SMP */
> >
> > +static inline
> > +void __inc_zone_folio_stat(struct folio *folio, enum zone_stat_item item)
> > +{
> > + __mod_zone_page_state(folio_zone(folio), item, folio_nr_pages(folio));
> > +}
>
> The naming is unfortunate. We expect
>
> inc: add one to
> dec: subtract one from
> mod: modify by signed quantity
>
> So these are inconsistent. Perhaps use "add" and "sub" instead. At
> least to alert people to the fact that these are different.
>
> And, again, it's nice to see the subsystem's name leading the
> identifiers, so "zone_folio_stat_add()".
I thought this was a 'zone stat', so __zone_stat_add_folio()?
I'm not necessarily signing up to change the existing
__inc_node_page_state(), but I might. If so, __node_stat_add_page()?
[syzbot] WARNING: ODEBUG bug in ext4_fill_super (3)
Hello,
syzbot found the following issue on:
HEAD commit:28806e4d Merge tag 'media/v5.12-2' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=136d1bbcd0
kernel config: https://syzkaller.appspot.com/x/.config?x=6bcf96204c1b8e77
dashboard link: https://syzkaller.appspot.com/bug?extid=628472a2aac693ab0fcd
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1133abfad0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1191aab2d0
The issue was bisected to:
commit 2d01ddc86606564fb08c56e3bc93a0693895f710
Author: Jan Kara
Date: Wed Dec 16 10:18:40 2020 +
ext4: save error info to sb through journal if available
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=152b9d56d0
final oops: https://syzkaller.appspot.com/x/report.txt?x=172b9d56d0
console output: https://syzkaller.appspot.com/x/log.txt?x=132b9d56d0
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+628472a2aac693ab0...@syzkaller.appspotmail.com
Fixes: 2d01ddc86606 ("ext4: save error info to sb through journal if available")
ODEBUG: free active (active state 0) object type: timer_list hint:
print_daily_error_info+0x0/0x1f0 fs/ext4/super.c:1334
WARNING: CPU: 1 PID: 12723 at lib/debugobjects.c:505
debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Modules linked in:
CPU: 0 PID: 12723 Comm: syz-executor932 Not tainted 5.12.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
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 a0
06 c2 89 4c 89 ee 48 c7 c7 a0 fa c1 89 e8 fc 41 f8 04 <0f> 0b 83 05 05 7e fb 09
01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
RSP: 0018:c9000e6ef980 EFLAGS: 00010286
RAX: RBX: 0003 RCX:
RDX: 88801d5e9bc0 RSI: 815c0d25 RDI: f52001cddf22
RBP: 0001 R08: R09:
R10: 815b9abe R11: R12: 896d7da0
R13: 89c200e0 R14: 81629d00 R15: dc00
FS: 00f93300() GS:8880b9c0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7fcda3ec CR3: 155a1000 CR4: 00350ef0
Call Trace:
__debug_check_no_obj_freed lib/debugobjects.c:987 [inline]
debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1018
slab_free_hook mm/slub.c:1554 [inline]
slab_free_freelist_hook+0x147/0x210 mm/slub.c:1600
slab_free mm/slub.c:3161 [inline]
kfree+0xe5/0x7f0 mm/slub.c:4213
ext4_fill_super+0x84f/0xded0 fs/ext4/super.c:5182
mount_bdev+0x34d/0x410 fs/super.c:1367
legacy_get_tree+0x105/0x220 fs/fs_context.c:592
vfs_get_tree+0x89/0x2f0 fs/super.c:1497
do_new_mount fs/namespace.c:2903 [inline]
path_mount+0x132a/0x1f90 fs/namespace.c:3233
do_mount fs/namespace.c:3246 [inline]
__do_sys_mount fs/namespace.c:3454 [inline]
__se_sys_mount fs/namespace.c:3431 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3431
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x445c0a
Code: 48 c7 c2 c0 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 a8 00 00 00
0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01
c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7ffe8bf4c3b8 EFLAGS: 0202
ORIG_RAX: 00a5
RAX: ffda RBX: 7ffe8bf4c410 RCX: 00445c0a
RDX: 2040 RSI: 2100 RDI: 7ffe8bf4c3d0
RBP: 7ffe8bf4c3d0 R08: 7ffe8bf4c410 R09:
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH v4 01/25] mm: Introduce struct folio
On Sat, Mar 13, 2021 at 12:37:02PM -0800, Andrew Morton wrote:
> On Fri, 5 Mar 2021 04:18:37 + "Matthew Wilcox (Oracle)"
> wrote:
>
> > A struct folio refers to an entire (possibly compound) page. A function
> > which takes a struct folio argument declares that it will operate on the
> > entire compound page, not just PAGE_SIZE bytes. In return, the caller
> > guarantees that the pointer it is passing does not point to a tail page.
> >
> > Signed-off-by: Matthew Wilcox (Oracle)
> > ---
> > include/linux/mm.h | 30 ++
> > include/linux/mm_types.h | 17 +
>
> Perhaps a new folio.h would be neater.
I understand that urge (I'm no fan of the size of mm.h ...), but it ends
up pretty interwoven with mm.h. For example:
static inline struct zone *folio_zone(const struct folio *folio)
{
return page_zone(>page);
}
so we need both struct folio defined here and we need page_zone().
page_zone() is defined in mm.h, so we'd have folio.h including mm.h.
But then put_page() calls put_folio(), so we need folio.h included
in mm.h.
The patch series I have does a lot of movement of page cache functionality
from mm.h to filemap.h, so you may end up with a smaller mm.h at the
end of it. Right now, it's 10 lines longer than it was.
> > +static inline struct folio *next_folio(struct folio *folio)
> > +{
> > +#if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP)
> > + return (struct folio *)nth_page(>page, folio_nr_pages(folio));
> > +#else
> > + return folio + folio_nr_pages(folio);
> > +#endif
> > +}
>
> It's a shame this isn't called folio_something(), like the rest of the API.
>
> Unclear what this does. Some comments would help.
folio_next() it can be. I'll add some commentary.
> > +static inline unsigned int folio_shift(struct folio *folio)
> > +{
> > + return PAGE_SHIFT + folio_order(folio);
> > +}
> > +
> > +static inline size_t folio_size(struct folio *folio)
> > +{
> > + return PAGE_SIZE << folio_order(folio);
> > +}
>
> Why size_t? That's pretty rare in this space and I'd have expected
> unsigned long.
I like to use size_t for things which are the number of bytes represented
by an in-memory object. As opposed to all the other things which we
use unsigned long for. Maybe that's more common on the filesystem side
of the house.
> > +static inline struct folio *page_folio(struct page *page)
> > +{
> > + unsigned long head = READ_ONCE(page->compound_head);
> > +
> > + if (unlikely(head & 1))
> > + return (struct folio *)(head - 1);
> > + return (struct folio *)page;
> > +}
>
> What purpose does the READ_ONCE() serve?
Same purpose as it does in compound_head():
static inline struct page *compound_head(struct page *page)
{
unsigned long head = READ_ONCE(page->compound_head);
if (unlikely(head & 1))
return (struct page *) (head - 1);
return page;
}
I think Kirill would say that it's to defend against splitting if we
don't have a refcount on the page yet. So if we do something like walk
the page tables, find a PTE, translate it to a struct page, then try to
get a reference on the head page, we don't end up with an incoherent
answer from 'compound_head()' if it's split in the middle of the call
and the page->compound_head field gets assigned some other value.
It might return the wrong page, so get_user_pages() still has to check
the page is right after it's got the reference, but at least this way
it's guaranteed to return something that was right at one time.
There might be more to it, but that's my understanding of why the code
is currently written this way.
[PATCH] staging: comedi: cb_pcidas: replace slash in name
request_irq() wont accept a name which contains slash so we need to
repalce it with something else -- otherwise it will trigger a warning
and the entry in /proc/irq/ will not be created
[1.630764] name 'pci-das1602/16'
[1.630950] WARNING: CPU: 0 PID: 181 at fs/proc/generic.c:180
__xlate_proc_name+0x93/0xb0
[1.634009] RIP: 0010:__xlate_proc_name+0x93/0xb0
[1.639441] Call Trace:
[1.639976] proc_mkdir+0x18/0x20
[1.641946] request_threaded_irq+0xfe/0x160
[1.642186] cb_pcidas_auto_attach+0xf4/0x610 [cb_pcidas]
Signed-off-by: Tong Zhang
---
drivers/staging/comedi/drivers/cb_pcidas.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidas.c
b/drivers/staging/comedi/drivers/cb_pcidas.c
index d740c4782775..df0960d41cff 100644
--- a/drivers/staging/comedi/drivers/cb_pcidas.c
+++ b/drivers/staging/comedi/drivers/cb_pcidas.c
@@ -230,7 +230,7 @@ struct cb_pcidas_board {
static const struct cb_pcidas_board cb_pcidas_boards[] = {
[BOARD_PCIDAS1602_16] = {
- .name = "pci-das1602/16",
+ .name = "pci-das1602-16",
.ai_speed = 5000,
.ao_scan_speed = 1,
.fifo_size = 512,
@@ -248,7 +248,7 @@ static const struct cb_pcidas_board cb_pcidas_boards[] = {
.has_ao = 1,
},
[BOARD_PCIDAS1602_12] = {
- .name = "pci-das1602/12",
+ .name = "pci-das1602-12",
.ai_speed = 3200,
.ao_scan_speed = 4000,
.fifo_size = 1024,
@@ -257,12 +257,12 @@ static const struct cb_pcidas_board cb_pcidas_boards[] = {
.is_1602= 1,
},
[BOARD_PCIDAS1200_JR] = {
- .name = "pci-das1200/jr",
+ .name = "pci-das1200-jr",
.ai_speed = 3200,
.fifo_size = 1024,
},
[BOARD_PCIDAS1602_16_JR] = {
- .name = "pci-das1602/16/jr",
+ .name = "pci-das1602-16-jr",
.ai_speed = 5000,
.fifo_size = 512,
.is_16bit = 1,
--
2.25.1
[PATCH] staging: comedi: replace slash in name
request_irq() wont accept a name which contains slash so we need to
repalce it with something else -- otherwise it will trigger a warning
and the entry in /proc/irq/ will not be created
[1.565966] name 'pci-das6402/16'
[1.566149] WARNING: CPU: 0 PID: 184 at fs/proc/generic.c:180
__xlate_proc_name+0x93/0xb0
[1.568923] RIP: 0010:__xlate_proc_name+0x93/0xb0
[1.574200] Call Trace:
[1.574722] proc_mkdir+0x18/0x20
[1.576629] request_threaded_irq+0xfe/0x160
[1.576859] auto_attach+0x60a/0xc40 [cb_pcidas64]
Signed-off-by: Tong Zhang
---
drivers/staging/comedi/drivers/cb_pcidas64.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c
b/drivers/staging/comedi/drivers/cb_pcidas64.c
index fa987bb0e7cd..662d6ffb8f60 100644
--- a/drivers/staging/comedi/drivers/cb_pcidas64.c
+++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
@@ -677,7 +677,7 @@ static const int bytes_in_sample = 2;
static const struct pcidas64_board pcidas64_boards[] = {
[BOARD_PCIDAS6402_16] = {
- .name = "pci-das6402/16",
+ .name = "pci-das6402-16",
.ai_se_chans= 64,
.ai_bits= 16,
.ai_speed = 5000,
@@ -693,7 +693,7 @@ static const struct pcidas64_board pcidas64_boards[] = {
.has_8255 = 1,
},
[BOARD_PCIDAS6402_12] = {
- .name = "pci-das6402/12", /* XXX check */
+ .name = "pci-das6402-12", /* XXX check */
.ai_se_chans= 64,
.ai_bits= 12,
.ai_speed = 5000,
@@ -709,7 +709,7 @@ static const struct pcidas64_board pcidas64_boards[] = {
.has_8255 = 1,
},
[BOARD_PCIDAS64_M1_16] = {
- .name = "pci-das64/m1/16",
+ .name = "pci-das64-m1-16",
.ai_se_chans= 64,
.ai_bits= 16,
.ai_speed = 1000,
@@ -725,7 +725,7 @@ static const struct pcidas64_board pcidas64_boards[] = {
.has_8255 = 1,
},
[BOARD_PCIDAS64_M2_16] = {
- .name = "pci-das64/m2/16",
+ .name = "pci-das64-m2-16",
.ai_se_chans= 64,
.ai_bits= 16,
.ai_speed = 500,
@@ -741,7 +741,7 @@ static const struct pcidas64_board pcidas64_boards[] = {
.has_8255 = 1,
},
[BOARD_PCIDAS64_M3_16] = {
- .name = "pci-das64/m3/16",
+ .name = "pci-das64-m3-16",
.ai_se_chans= 64,
.ai_bits= 16,
.ai_speed = 333,
@@ -984,7 +984,7 @@ static const struct pcidas64_board pcidas64_boards[] = {
.has_8255 = 0,
},
[BOARD_PCIDAS4020_12] = {
- .name = "pci-das4020/12",
+ .name = "pci-das4020-12",
.ai_se_chans= 4,
.ai_bits= 12,
.ai_speed = 50,
--
2.25.1
Re: [PATCH v4 09/25] mm: Add folio_index, folio_page and folio_contains
On Sat, Mar 13, 2021 at 12:37:16PM -0800, Andrew Morton wrote:
> On Fri, 5 Mar 2021 04:18:45 + "Matthew Wilcox (Oracle)"
> wrote:
> > folio_index() is the equivalent of page_index() for folios. folio_page()
> > finds the page in a folio for a page cache index. folio_contains()
> > tells you whether a folio contains a particular page cache index.
> >
>
> copy-paste changelog into each function's covering comment?
Certainly.
> > +static inline struct page *folio_page(struct folio *folio, pgoff_t index)
> > +{
> > + index -= folio_index(folio);
> > + VM_BUG_ON_FOLIO(index >= folio_nr_pages(folio), folio);
> > + return >page + index;
> > +}
>
> One would expect folio_page() to be the reverse of page_folio(), only
> it isn't anything like that.
It is ... but only for files. So maybe folio_file_page()?
[linux-stable-rc CI] Test report for 5.10.24-rc1 /x86
Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-5.10.y Arch: x86 Version: 5.10.24-rc1 Commit: 7496dbd02b27316275e097a4e52cebcd2ca5a5c0 Compiler: gcc version 7.3.0 (GCC) All testcases PASSED. Testcase Result Summary: total_num: 4693 succeed_num: 4693 failed_num: 0 timeout_num: 0 Tested-by: Hulk Robot
[linux-stable-rc CI] Test report for 4.19.181-rc1 /arm64
Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-4.19.y Arch: arm64 Version: 4.19.181-rc1 Commit: a233c6b3f6de88ca62da8fde45f330b104827851 Compiler: gcc version 7.3.0 (GCC) All testcases PASSED. Testcase Result Summary: total_num: 4651 succeed_num: 4651 failed_num: 0 timeout_num: 0 Tested-by: Hulk Robot
ERROR: modpost: "__aeabi_unwind_cpp_pr0" undefined!
Hi Wilken, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 88fe49249c99de14e543c632a46248d85411ab9e commit: d115b51e0e567199c821fc39e13b6af7e78f247d hwmon: add Corsair PSU HID controller driver date: 3 months ago config: arm-randconfig-r024-20210314 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project dfd27ebbd0eb137c9a439b7c537bb87ba903efd3) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm cross compiling tool for clang build # apt-get install binutils-arm-linux-gnueabi # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d115b51e0e567199c821fc39e13b6af7e78f247d git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout d115b51e0e567199c821fc39e13b6af7e78f247d # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-chicony.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-belkin.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/hid-aureal.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/hid/uhid.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/crypto/inside-secure/crypto_safexcel.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/crypto/ccree/ccree.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-el15203000.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-dac124s085.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-wm8350.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-tlc591xx.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-pwm.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-pm8058.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-max8997.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-max77650.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lt3593.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lp8788.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lp50xx.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lp3952.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lp3944.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lm3601x.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lm3533.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-lm3530.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-ktd2692.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-is31fl32xx.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-da903x.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-cpcap.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-aw2013.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-as3645a.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/leds-aat1290.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/leds/led-class-flash.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/core/mmc_block.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/core/pwrseq_emmc.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/core/pwrseq_simple.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/core/mmc_core.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/host/mmc_hsq.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/host/cqhci.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/host/sdhci-omap.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/host/sdhci-of-aspeed.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/host/sdhci-cadence.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/host/sdhci-pltfm.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/host/usdhi6rol0.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/host/ushc.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [drivers/mmc/host/vub300.ko]
Re: [PATCH v4 00/25] Page folios
On Sat, 13 Mar 2021, Andrew Morton wrote: > On Fri, 5 Mar 2021 04:18:36 + "Matthew Wilcox (Oracle)" > wrote: > > > Our type system does not currently distinguish between tail pages and > > head or single pages. This is a problem because we call compound_head() > > multiple times (and the compiler cannot optimise it out), bloating the > > kernel. It also makes programming hard as it is often unclear whether > > a function operates on an individual page, or an entire compound page. > > > > This patch series introduces the struct folio, which is a type that > > represents an entire compound page. This initial set reduces the kernel > > size by approximately 6kB, although its real purpose is adding > > infrastructure to enable further use of the folio. > > Geeze it's a lot of noise. More things to remember and we'll forever > have a mismash of `page' and `folio' and code everywhere converting > from one to the other. Ongoing addition of folio > accessors/manipulators to overlay the existing page > accessors/manipulators, etc. > > It's unclear to me that it's all really worth it. What feedback have > you seen from others? My own feeling and feedback have been much like yours. I don't get very excited by type safety at this level; and although I protested back when all those compound_head()s got tucked into the *PageFlag() functions, the text size increase was not very much, and I never noticed any adverse performance reports. To me, it's distraction, churn and friction, ongoing for years; but that's just me, and I'm resigned to the possibility that it will go in. Matthew is not alone in wanting to pursue it: let others speak. Hugh
[PATCH net-next v2] mfd: Add Renesas Synchronization Management Unit (SMU) support
From: Min Li
Add support for ClockMatrix(TM) and 82P33xxx families of timing
and synchronization devices. The access interface can be either
SPI or I2C. Currently, it will create 2 types of MFD devices,
which are to be used by the corresponding rsmu character device
driver and the PTP hardware clock driver, respectively.
Signed-off-by: Min Li
---
Changes since v1:
-MFD_RSMU_I2C is exclusive with MFD_RSMU_SPI.
drivers/mfd/Kconfig | 29 +-
drivers/mfd/Makefile | 2 +
drivers/mfd/rsmu_i2c.c | 344 +
drivers/mfd/rsmu_private.h | 32 ++
drivers/mfd/rsmu_spi.c | 371 ++
include/linux/mfd/idt82p33_reg.h | 102 +
include/linux/mfd/idt8a340_reg.h | 817 +++
include/linux/mfd/rsmu.h | 42 ++
8 files changed, 1738 insertions(+), 1 deletion(-)
create mode 100644 drivers/mfd/rsmu_i2c.c
create mode 100644 drivers/mfd/rsmu_private.h
create mode 100644 drivers/mfd/rsmu_spi.c
create mode 100644 include/linux/mfd/idt82p33_reg.h
create mode 100644 include/linux/mfd/idt8a340_reg.h
create mode 100644 include/linux/mfd/rsmu.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b74efa4..de00dfa 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2087,6 +2087,33 @@ config MFD_ACER_A500_EC
The controller itself is ENE KB930, it is running firmware
customized for the specific needs of the Acer A500 hardware.
+config MFD_RSMU_I2C
+ tristate "Renesas Synchronization Management Unit with I2C"
+ depends on I2C && OF
+ depends on MFD_RSMU_SPI=n
+ select MFD_CORE
+ help
+ Support for the Renesas synchronization management unit, such as
+ Clockmatrix and 82P33XXX series. This option supports I2C as
+ the control interface.
+
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
+config MFD_RSMU_SPI
+ tristate "Renesas Synchronization Management Unit with SPI"
+ depends on SPI && OF
+ select MFD_CORE
+ help
+ Support for the Renesas synchronization management unit, such as
+ Clockmatrix and 82P33XXX series. This option supports SPI as
+ the control interface.
+
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
menu "Multimedia Capabilities Port drivers"
depends on ARCH_SA1100
@@ -2131,7 +2158,7 @@ config RAVE_SP_CORE
device found on several devices in RAVE line of hardware.
config SGI_MFD_IOC3
- bool "SGI IOC3 core driver"
+ tristate "SGI IOC3 core driver"
depends on PCI && MIPS && 64BIT
select MFD_CORE
help
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 834f546..dae4d2e 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -237,6 +237,8 @@ obj-$(CONFIG_MFD_HI655X_PMIC) += hi655x-pmic.o
obj-$(CONFIG_MFD_DLN2) += dln2.o
obj-$(CONFIG_MFD_RT5033) += rt5033.o
obj-$(CONFIG_MFD_SKY81452) += sky81452.o
+obj-$(CONFIG_MFD_RSMU_I2C) += rsmu_i2c.o
+obj-$(CONFIG_MFD_RSMU_SPI) += rsmu_spi.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/rsmu_i2c.c b/drivers/mfd/rsmu_i2c.c
new file mode 100644
index 000..06f582b
--- /dev/null
+++ b/drivers/mfd/rsmu_i2c.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Multi-function driver for the IDT ClockMatrix(TM) and 82P33xxx families of
+ * timing and synchronization devices.
+ *
+ * Copyright (C) 2019 Integrated Device Technology, Inc., a Renesas Company.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "rsmu_private.h"
+
+/*
+ * 16-bit register address: the lower 8 bits of the register address come
+ * from the offset addr byte and the upper 8 bits come from the page register.
+ */
+#defineRSMU_CM_PAGE_ADDR 0xFD
+#defineRSMU_CM_PAGE_WINDOW 256
+
+/*
+ * 15-bit register address: the lower 7 bits of the register address come
+ * from the offset addr byte and the upper 8 bits come from the page register.
+ */
+#defineRSMU_SABRE_PAGE_ADDR0x7F
+#defineRSMU_SABRE_PAGE_WINDOW 128
+
+static bool rsmu_cm_volatile_reg(struct device *dev, unsigned int reg);
+static bool rsmu_sabre_volatile_reg(struct device *dev, unsigned int reg);
+
+/* Current mfd device index */
+static atomic_t rsmu_ndevs = ATOMIC_INIT(0);
+
+/* Platform data */
+static struct rsmu_pdata rsmu_pdata[RSMU_MAX_MFD_DEV];
+
+/* clockmatrix phc devices */
+static struct mfd_cell rsmu_cm_pdev[RSMU_MAX_MFD_DEV] = {
+ [0] = {
+
Re: [PATCH 1/2] usb: cdns3: Use dma_pool_* api to alloc trb pool
On 21-03-09 06:19:39, Sanket Parmar wrote:
> Allocation of DMA coherent memory in atomic context using
> dma_alloc_coherent() might fail on platforms with smaller
> DMA region.
>
> To fix it, dma_alloc_coherent() is replaced with dma_pool
> API to allocate a smaller chunk of DMA coherent memory for
> TRB rings.
>
> Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
The patch is ok, but I don't think it is a bug-fix, it is an
improvement for smaller DMA region use case.
I will apply it with deletion of above Fixes tag if you have no
more opinion.
Peter
> Reported-by: Aswath Govindraju
> Signed-off-by: Sanket Parmar
> ---
> drivers/usb/cdns3/cdns3-gadget.c | 42 +
> drivers/usb/cdns3/cdns3-gadget.h |1 +
> 2 files changed, 20 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/usb/cdns3/cdns3-gadget.c
> b/drivers/usb/cdns3/cdns3-gadget.c
> index 582bfec..5f51215 100644
> --- a/drivers/usb/cdns3/cdns3-gadget.c
> +++ b/drivers/usb/cdns3/cdns3-gadget.c
> @@ -59,6 +59,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "core.h"
> @@ -190,29 +191,13 @@ dma_addr_t cdns3_trb_virt_to_dma(struct cdns3_endpoint
> *priv_ep,
> return priv_ep->trb_pool_dma + offset;
> }
>
> -static int cdns3_ring_size(struct cdns3_endpoint *priv_ep)
> -{
> - switch (priv_ep->type) {
> - case USB_ENDPOINT_XFER_ISOC:
> - return TRB_ISO_RING_SIZE;
> - case USB_ENDPOINT_XFER_CONTROL:
> - return TRB_CTRL_RING_SIZE;
> - default:
> - if (priv_ep->use_streams)
> - return TRB_STREAM_RING_SIZE;
> - else
> - return TRB_RING_SIZE;
> - }
> -}
> -
> static void cdns3_free_trb_pool(struct cdns3_endpoint *priv_ep)
> {
> struct cdns3_device *priv_dev = priv_ep->cdns3_dev;
>
> if (priv_ep->trb_pool) {
> - dma_free_coherent(priv_dev->sysdev,
> - cdns3_ring_size(priv_ep),
> - priv_ep->trb_pool, priv_ep->trb_pool_dma);
> + dma_pool_free(priv_dev->eps_dma_pool,
> + priv_ep->trb_pool, priv_ep->trb_pool_dma);
> priv_ep->trb_pool = NULL;
> }
> }
> @@ -226,7 +211,7 @@ static void cdns3_free_trb_pool(struct cdns3_endpoint
> *priv_ep)
> int cdns3_allocate_trb_pool(struct cdns3_endpoint *priv_ep)
> {
> struct cdns3_device *priv_dev = priv_ep->cdns3_dev;
> - int ring_size = cdns3_ring_size(priv_ep);
> + int ring_size = TRB_RING_SIZE;
> int num_trbs = ring_size / TRB_SIZE;
> struct cdns3_trb *link_trb;
>
> @@ -234,10 +219,10 @@ int cdns3_allocate_trb_pool(struct cdns3_endpoint
> *priv_ep)
> cdns3_free_trb_pool(priv_ep);
>
> if (!priv_ep->trb_pool) {
> - priv_ep->trb_pool = dma_alloc_coherent(priv_dev->sysdev,
> -ring_size,
> -_ep->trb_pool_dma,
> -GFP_DMA32 | GFP_ATOMIC);
> + priv_ep->trb_pool = dma_pool_alloc(priv_dev->eps_dma_pool,
> +GFP_DMA32 | GFP_ATOMIC,
> +_ep->trb_pool_dma);
> +
> if (!priv_ep->trb_pool)
> return -ENOMEM;
>
> @@ -3113,6 +3098,7 @@ static void cdns3_gadget_exit(struct cdns *cdns)
>
> dma_free_coherent(priv_dev->sysdev, 8, priv_dev->setup_buf,
> priv_dev->setup_dma);
> + dma_pool_destroy(priv_dev->eps_dma_pool);
>
> kfree(priv_dev->zlp_buf);
> usb_put_gadget(_dev->gadget);
> @@ -3185,6 +3171,14 @@ static int cdns3_gadget_start(struct cdns *cdns)
> /* initialize endpoint container */
> INIT_LIST_HEAD(_dev->gadget.ep_list);
> INIT_LIST_HEAD(_dev->aligned_buf_list);
> + priv_dev->eps_dma_pool = dma_pool_create("cdns3_eps_dma_pool",
> + priv_dev->sysdev,
> + TRB_RING_SIZE, 8, 0);
> + if (!priv_dev->eps_dma_pool) {
> + dev_err(priv_dev->dev, "Failed to create TRB dma pool\n");
> + ret = -ENOMEM;
> + goto err1;
> + }
>
> ret = cdns3_init_eps(priv_dev);
> if (ret) {
> @@ -3235,6 +3229,8 @@ static int cdns3_gadget_start(struct cdns *cdns)
> err2:
> cdns3_free_all_eps(priv_dev);
> err1:
> + dma_pool_destroy(priv_dev->eps_dma_pool);
> +
> usb_put_gadget(_dev->gadget);
> cdns->gadget_dev = NULL;
> return ret;
> diff --git a/drivers/usb/cdns3/cdns3-gadget.h
> b/drivers/usb/cdns3/cdns3-gadget.h
> index 21fa461..ecf9b91 100644
> --- a/drivers/usb/cdns3/cdns3-gadget.h
> +++ b/drivers/usb/cdns3/cdns3-gadget.h
> @@ -1298,6 +1298,7 @@ struct cdns3_device {
>
> struct cdns3_usb_regs
Re: [PATCH v2] usb: gadget: uvc: add bInterval checking for HS mode
Hi Pawel, Thank you for the patch. On Mon, Mar 08, 2021 at 01:53:38PM +0100, Pawel Laszczak wrote: > From: Pawel Laszczak > > Patch adds extra checking for bInterval passed by configfs. > The 5.6.4 chapter of USB Specification (rev. 2.0) say: > "A high-bandwidth endpoint must specify a period of 1x125 µs > (i.e., a bInterval value of 1)." > > The issue was observed during testing UVC class on CV. > I treat this change as improvement because we can control > bInterval by configfs. > > Signed-off-by: Pawel Laszczak Reviewed-by: Laurent Pinchart Felipe, could you take this patch in your tree ? > --- > Changlog: > v2: > - removed duplicated assignment > > drivers/usb/gadget/function/f_uvc.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/gadget/function/f_uvc.c > b/drivers/usb/gadget/function/f_uvc.c > index 44b4352a2676..ed77a126a74f 100644 > --- a/drivers/usb/gadget/function/f_uvc.c > +++ b/drivers/usb/gadget/function/f_uvc.c > @@ -633,7 +633,12 @@ uvc_function_bind(struct usb_configuration *c, struct > usb_function *f) > > uvc_hs_streaming_ep.wMaxPacketSize = > cpu_to_le16(max_packet_size | ((max_packet_mult - 1) << 11)); > - uvc_hs_streaming_ep.bInterval = opts->streaming_interval; > + > + /* A high-bandwidth endpoint must specify a bInterval value of 1 */ > + if (max_packet_mult > 1) > + uvc_hs_streaming_ep.bInterval = 1; > + else > + uvc_hs_streaming_ep.bInterval = opts->streaming_interval; > > uvc_ss_streaming_ep.wMaxPacketSize = cpu_to_le16(max_packet_size); > uvc_ss_streaming_ep.bInterval = opts->streaming_interval; -- Regards, Laurent Pinchart
Re: [PATCH v4 00/25] Page folios
On Sat, Mar 13, 2021 at 12:36:58PM -0800, Andrew Morton wrote: > On Fri, 5 Mar 2021 04:18:36 + "Matthew Wilcox (Oracle)" > wrote: > > > Our type system does not currently distinguish between tail pages and > > head or single pages. This is a problem because we call compound_head() > > multiple times (and the compiler cannot optimise it out), bloating the > > kernel. It also makes programming hard as it is often unclear whether > > a function operates on an individual page, or an entire compound page. > > > > This patch series introduces the struct folio, which is a type that > > represents an entire compound page. This initial set reduces the kernel > > size by approximately 6kB, although its real purpose is adding > > infrastructure to enable further use of the folio. > > Geeze it's a lot of noise. More things to remember and we'll forever > have a mismash of `page' and `folio' and code everywhere converting > from one to the other. Ongoing addition of folio > accessors/manipulators to overlay the existing page > accessors/manipulators, etc. > > It's unclear to me that it's all really worth it. What feedback have > you seen from others? Mmm. The thing is, the alternative is ongoing bugs. And inefficiencies. Today, we have code everywhere converting from tail pages to head pages -- we just don't notice it because it's all wrapped up in macros. I have over 10kB in text size reductions in my tree (yes, it's a monster series of patches), almost all from removing those conversions. And it's far from done. And these conversions are all in hot paths, like handling page faults and read(). For example: filemap_fault 19801289-691 it's two-thirds the size it was! Surely that's not all in the hot path, but still it's going to have some kind of effect. As well, we have code today that _looks_ right but is buggy. Take a look at vfs_dedupe_file_range_compare(). There's nothing wrong with it at first glance, until you realise that vfs_dedupe_get_page() might return a tail page, and you can't look at page->mapping for a tail page. Nor page->index, so vfs_lock_two_pages() is also broken. As far as feedback, I really want more. Particularly from filesystem people. I don't think a lot of them realise yet that I'm going to change 15 of the 22 address_space_ops to work with folios instead of pages. Individual filesystems can keep working with pages, of course, until they enable the "use multipage folios" bit.
Re: [PATCH 2/2] usb: webcam: Invalid size of Processing Unit Descriptor
Hi Pawel,
Thank you for the patch.
On Mon, Mar 08, 2021 at 11:27:35AM +0100, Pawel Laszczak wrote:
> From: Pawel Laszczak
>
> According with USB Device Class Definition for Video Device the
> Processing Unit Descriptor bLength should be 12 (10 + bmControlSize),
> but it has 11.
>
> Invalid length caused that Processing Unit Descriptor Test Video form
> CV tool failed. To fix this issue patch adds bmVideoStandards into
> uvc_processing_unit_descriptor structure.
The bmVideoStandards field was added in UVC 1.1, it wasn't part of UVC
1.0a. The commit message should explain this.
This change looks good to me, but could you also update
drivers/usb/gadget/legacy/webcam.c and
drivers/usb/gadget/function/f_uvc.c to explicitly set this field to 0 ?
With that,
Reviewed-by: Laurent Pinchart
> Signed-off-by: Pawel Laszczak
> ---
> include/uapi/linux/usb/video.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/usb/video.h b/include/uapi/linux/usb/video.h
> index d854cb19c42c..2a54e8fdd341 100644
> --- a/include/uapi/linux/usb/video.h
> +++ b/include/uapi/linux/usb/video.h
> @@ -302,6 +302,7 @@ struct uvc_processing_unit_descriptor {
> __u8 bControlSize;
> __u8 bmControls[2];
> __u8 iProcessing;
> + __u8 bmVideoStandards;
> } __attribute__((__packed__));
>
> #define UVC_DT_PROCESSING_UNIT_SIZE(n) (9+(n))
--
Regards,
Laurent Pinchart
Re: [PATCH v2] usb: gadget: uvc: add bInterval checking for HS mode
On 21-03-08 13:53:38, Pawel Laszczak wrote: > From: Pawel Laszczak > > Patch adds extra checking for bInterval passed by configfs. > The 5.6.4 chapter of USB Specification (rev. 2.0) say: > "A high-bandwidth endpoint must specify a period of 1x125 µs > (i.e., a bInterval value of 1)." > > The issue was observed during testing UVC class on CV. > I treat this change as improvement because we can control > bInterval by configfs. > > Signed-off-by: Pawel Laszczak > > --- > Changlog: > v2: > - removed duplicated assignment > > drivers/usb/gadget/function/f_uvc.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/gadget/function/f_uvc.c > b/drivers/usb/gadget/function/f_uvc.c > index 44b4352a2676..ed77a126a74f 100644 > --- a/drivers/usb/gadget/function/f_uvc.c > +++ b/drivers/usb/gadget/function/f_uvc.c > @@ -633,7 +633,12 @@ uvc_function_bind(struct usb_configuration *c, struct > usb_function *f) > > uvc_hs_streaming_ep.wMaxPacketSize = > cpu_to_le16(max_packet_size | ((max_packet_mult - 1) << 11)); > - uvc_hs_streaming_ep.bInterval = opts->streaming_interval; > + > + /* A high-bandwidth endpoint must specify a bInterval value of 1 */ > + if (max_packet_mult > 1) > + uvc_hs_streaming_ep.bInterval = 1; > + else > + uvc_hs_streaming_ep.bInterval = opts->streaming_interval; > > uvc_ss_streaming_ep.wMaxPacketSize = cpu_to_le16(max_packet_size); > uvc_ss_streaming_ep.bInterval = opts->streaming_interval; > -- > 2.25.1 > Reviewed-by: Peter Chen -- Thanks, Peter Chen
Re: [PATCH] devlink: fix typo in documentation
Hello: This patch was applied to netdev/net.git (refs/heads/master): On Sat, 13 Mar 2021 01:04:13 +0100 you wrote: > This commit fixes three spelling typos in devlink-dpipe.rst and > devlink-port.rst. > > Signed-off-by: Eva Dengler > --- > Documentation/networking/devlink/devlink-dpipe.rst | 2 +- > Documentation/networking/devlink/devlink-port.rst | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) Here is the summary with links: - devlink: fix typo in documentation https://git.kernel.org/netdev/net/c/ad236ccde19a You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH 1/2] usb: gadget: uvc: Updating bcdUVC field to 0x0110
Hello Pawel,
Thank you for the patch.
On Sun, Mar 14, 2021 at 09:58:46AM +0800, Peter Chen wrote:
> On 21-03-08 11:27:34, Pawel Laszczak wrote:
> > From: Pawel Laszczak
> >
> > Command Verifier during UVC Descriptor Tests (Class Video Control
> > Interface Descriptor Test Video) compleins about:
>
> %s/compleins/complains
>
> > Video Control Interface Header bcdUVC is 0x0100. USB Video Class
> > specification 1.0 has been replaced by 1.1 specification
> > (UVC: 6.2.26) Class Video Control Interface Descriptor bcdUVC is not 1.1
>
> What does this (UVC: 6.2.26) mean? There are only 4 chapters for this
> spec, Am I something wrong?
I assume this is a reference to a test case in the test suite.
> > Signed-off-by: Pawel Laszczak
> > ---
> > drivers/usb/gadget/function/uvc_configfs.c | 2 +-
> > drivers/usb/gadget/legacy/webcam.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/function/uvc_configfs.c
> > b/drivers/usb/gadget/function/uvc_configfs.c
> > index 00fb58e50a15..cd28dec837dd 100644
> > --- a/drivers/usb/gadget/function/uvc_configfs.c
> > +++ b/drivers/usb/gadget/function/uvc_configfs.c
> > @@ -231,7 +231,7 @@ static struct config_item
> > *uvcg_control_header_make(struct config_group *group,
> > h->desc.bLength = UVC_DT_HEADER_SIZE(1);
> > h->desc.bDescriptorType = USB_DT_CS_INTERFACE;
> > h->desc.bDescriptorSubType = UVC_VC_HEADER;
> > - h->desc.bcdUVC = cpu_to_le16(0x0100);
> > + h->desc.bcdUVC = cpu_to_le16(0x0110);
> > h->desc.dwClockFrequency= cpu_to_le32(4800);
> >
> > config_item_init_type_name(>item, name, _control_header_type);
> > diff --git a/drivers/usb/gadget/legacy/webcam.c
> > b/drivers/usb/gadget/legacy/webcam.c
> > index a9f8eb8e1c76..3a61de4bb2b1 100644
> > --- a/drivers/usb/gadget/legacy/webcam.c
> > +++ b/drivers/usb/gadget/legacy/webcam.c
> > @@ -90,7 +90,7 @@ static const struct UVC_HEADER_DESCRIPTOR(1)
> > uvc_control_header = {
> > .bLength= UVC_DT_HEADER_SIZE(1),
> > .bDescriptorType= USB_DT_CS_INTERFACE,
> > .bDescriptorSubType = UVC_VC_HEADER,
> > - .bcdUVC = cpu_to_le16(0x0100),
> > + .bcdUVC = cpu_to_le16(0x0110),
> > .wTotalLength = 0, /* dynamic */
> > .dwClockFrequency = cpu_to_le32(4800),
> > .bInCollection = 0, /* dynamic */
The change looks good to me. With the typo in the commit message fixed,
Reviewed-by: Laurent Pinchart
--
Regards,
Laurent Pinchart
Re: [PATCH] drm/omap: dsi: fix unsigned expression compared with zero
Hi Junlin,
Thank you for the patch.
On Fri, Mar 12, 2021 at 03:14:45PM +0800, angkery wrote:
> From: Junlin Yang
>
> r is "u32" always >= 0,mipi_dsi_create_packet may return little than zero.
> so r < 0 condition is never accessible.
>
> Fixes coccicheck warnings:
> ./drivers/gpu/drm/omapdrm/dss/dsi.c:2155:5-6:
> WARNING: Unsigned expression compared with zero: r < 0
>
> Signed-off-by: Junlin Yang
Reviewed-by: Laurent Pinchart
Tomi, will you take this in your tree ?
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 8e11612..b31d750 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -2149,11 +2149,12 @@ static int dsi_vc_send_short(struct dsi_data *dsi,
> int vc,
>const struct mipi_dsi_msg *msg)
> {
> struct mipi_dsi_packet pkt;
> + int ret;
> u32 r;
>
> - r = mipi_dsi_create_packet(, msg);
> - if (r < 0)
> - return r;
> + ret = mipi_dsi_create_packet(, msg);
> + if (ret < 0)
> + return ret;
>
> WARN_ON(!dsi_bus_is_locked(dsi));
>
--
Regards,
Laurent Pinchart
Re: [PATCH] drivers: net: vxlan.c: Fix declaration issue
Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Sat, 13 Mar 2021 14:06:49 +0530 you wrote: > Added a blank line after structure declaration. > This is done to maintain code uniformity. > > Signed-off-by: Sanjana Srinidhi > --- > drivers/net/vxlan.c | 1 + > 1 file changed, 1 insertion(+) Here is the summary with links: - drivers: net: vxlan.c: Fix declaration issue https://git.kernel.org/netdev/net-next/c/6fadbdd6dd32 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH] net: ethernet: marvell: Fixed typo in the file sky2.c
Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Sat, 13 Mar 2021 11:15:36 +0530 you wrote: > s/calclation/calculation/ > > Signed-off-by: Bhaskar Chowdhury > --- > drivers/net/ethernet/marvell/sky2.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > [...] Here is the summary with links: - net: ethernet: marvell: Fixed typo in the file sky2.c https://git.kernel.org/netdev/net-next/c/65c7bc1b7a66 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH net-next] net: stmmac: Set FIFO sizes for ipq806x
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Sat, 13 Mar 2021 13:18:26 + you wrote:
> Commit eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values")
> started using the TX FIFO size to verify what counts as a valid MTU
> request for the stmmac driver. This is unset for the ipq806x variant.
> Looking at older patches for this it seems the RX + TXs buffers can be
> up to 8k, so set appropriately.
>
> (I sent this as an RFC patch in June last year, but received no replies.
> I've been running with this on my hardware (a MikroTik RB3011) since
> then with larger MTUs to support both the internal qca8k switch and
> VLANs with no problems. Without the patch it's impossible to set the
> larger MTU required to support this.)
>
> [...]
Here is the summary with links:
- [net-next] net: stmmac: Set FIFO sizes for ipq806x
https://git.kernel.org/netdev/net-next/c/e127906b68b4
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH v2 net-next 0/6] skbuff: micro-optimize flow dissection
None of these apply to net-next as per the patchwork automated checks. Any idea why? Thanks.
Re: [PATCH net] net: lapbether: Prevent racing when checking whether the netif is running
Hi Martin, Could you ack? Thanks!
Re: [PATCH 1/2] usb: gadget: uvc: Updating bcdUVC field to 0x0110
On 21-03-08 11:27:34, Pawel Laszczak wrote:
> From: Pawel Laszczak
>
> Command Verifier during UVC Descriptor Tests (Class Video Control
> Interface Descriptor Test Video) compleins about:
%s/compleins/complains
>
> Video Control Interface Header bcdUVC is 0x0100. USB Video Class
> specification 1.0 has been replaced by 1.1 specification
> (UVC: 6.2.26) Class Video Control Interface Descriptor bcdUVC is not 1.1
What does this (UVC: 6.2.26) mean? There are only 4 chapters for this
spec, Am I something wrong?
>
> Signed-off-by: Pawel Laszczak
> ---
> drivers/usb/gadget/function/uvc_configfs.c | 2 +-
> drivers/usb/gadget/legacy/webcam.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/uvc_configfs.c
> b/drivers/usb/gadget/function/uvc_configfs.c
> index 00fb58e50a15..cd28dec837dd 100644
> --- a/drivers/usb/gadget/function/uvc_configfs.c
> +++ b/drivers/usb/gadget/function/uvc_configfs.c
> @@ -231,7 +231,7 @@ static struct config_item
> *uvcg_control_header_make(struct config_group *group,
> h->desc.bLength = UVC_DT_HEADER_SIZE(1);
> h->desc.bDescriptorType = USB_DT_CS_INTERFACE;
> h->desc.bDescriptorSubType = UVC_VC_HEADER;
> - h->desc.bcdUVC = cpu_to_le16(0x0100);
> + h->desc.bcdUVC = cpu_to_le16(0x0110);
> h->desc.dwClockFrequency= cpu_to_le32(4800);
>
> config_item_init_type_name(>item, name, _control_header_type);
> diff --git a/drivers/usb/gadget/legacy/webcam.c
> b/drivers/usb/gadget/legacy/webcam.c
> index a9f8eb8e1c76..3a61de4bb2b1 100644
> --- a/drivers/usb/gadget/legacy/webcam.c
> +++ b/drivers/usb/gadget/legacy/webcam.c
> @@ -90,7 +90,7 @@ static const struct UVC_HEADER_DESCRIPTOR(1)
> uvc_control_header = {
> .bLength= UVC_DT_HEADER_SIZE(1),
> .bDescriptorType= USB_DT_CS_INTERFACE,
> .bDescriptorSubType = UVC_VC_HEADER,
> - .bcdUVC = cpu_to_le16(0x0100),
> + .bcdUVC = cpu_to_le16(0x0110),
> .wTotalLength = 0, /* dynamic */
> .dwClockFrequency = cpu_to_le32(4800),
> .bInCollection = 0, /* dynamic */
> --
> 2.25.1
>
--
Thanks,
Peter Chen
Re: [PATCH 3/3] fs: unicode: Add utf8 module and a unicode layer
Shreeya Patel writes:
> utf8data.h_shipped has a large database table which is an auto-generated
> decodification trie for the unicode normalization functions.
> It is not necessary to carry this large table in the kernel hence make
> UTF-8 encoding loadable by converting it into a module.
> Also, modify the file called unicode-core which will act as a layer for
> unicode subsystem. It will load the UTF-8 module and access it's functions
> whenever any filesystem that needs unicode is mounted.
>
> Signed-off-by: Shreeya Patel
Hi Shreeya,
> ---
> fs/unicode/Kconfig| 7 +-
> fs/unicode/Makefile | 5 +-
> fs/unicode/unicode-core.c | 201 ++-
> fs/unicode/utf8-core.c| 112 +
> fs/unicode/utf8mod.c | 246 ++
> include/linux/unicode.h | 20
> 6 files changed, 427 insertions(+), 164 deletions(-)
> create mode 100644 fs/unicode/utf8-core.c
> create mode 100644 fs/unicode/utf8mod.c
>
> diff --git a/fs/unicode/Kconfig b/fs/unicode/Kconfig
> index 2c27b9a5cd6c..33a27deef729 100644
> --- a/fs/unicode/Kconfig
> +++ b/fs/unicode/Kconfig
> @@ -8,7 +8,12 @@ config UNICODE
> Say Y here to enable UTF-8 NFD normalization and NFD+CF casefolding
> support.
>
> +config UNICODE_UTF8
> + tristate "UTF-8 module"
> + depends on UNICODE
> + default m
> +
> config UNICODE_NORMALIZATION_SELFTEST
> tristate "Test UTF-8 normalization support"
> - depends on UNICODE
> + depends on UNICODE_UTF8
> default n
> diff --git a/fs/unicode/Makefile b/fs/unicode/Makefile
> index fbf9a629ed0d..9dbb04194b32 100644
> --- a/fs/unicode/Makefile
> +++ b/fs/unicode/Makefile
> @@ -1,11 +1,14 @@
> # SPDX-License-Identifier: GPL-2.0
>
> obj-$(CONFIG_UNICODE) += unicode.o
> +obj-$(CONFIG_UNICODE_UTF8) += utf8.o
> obj-$(CONFIG_UNICODE_NORMALIZATION_SELFTEST) += utf8-selftest.o
>
> -unicode-y := utf8-norm.o unicode-core.o
> +unicode-y := unicode-core.o
> +utf8-y := utf8mod.o utf8-norm.o
>
> $(obj)/utf8-norm.o: $(obj)/utf8data.h
> +$(obj)/utf8mod.o: $(obj)/utf8-norm.o
>
> # In the normal build, the checked-in utf8data.h is just shipped.
> #
> diff --git a/fs/unicode/unicode-core.c b/fs/unicode/unicode-core.c
> index d5f09e022ac5..b832341f1e7b 100644
> --- a/fs/unicode/unicode-core.c
> +++ b/fs/unicode/unicode-core.c
> @@ -7,70 +7,29 @@
> #include
> #include
> #include
> +#include
>
> -#include "utf8n.h"
> +struct unicode_ops *utf8_ops;
> +
> +static int unicode_load_module(void);
This is unnecessary
>
> int unicode_validate(const struct unicode_map *um, const struct qstr *str)
> {
> - const struct utf8data *data = utf8nfdi(um->version);
> -
> - if (utf8nlen(data, str->name, str->len) < 0)
> - return -1;
> - return 0;
> + return utf8_ops->validate(um, str);
> }
> EXPORT_SYMBOL(unicode_validate);
>
> int unicode_strncmp(const struct unicode_map *um,
> const struct qstr *s1, const struct qstr *s2)
> {
> - const struct utf8data *data = utf8nfdi(um->version);
> - struct utf8cursor cur1, cur2;
> - int c1, c2;
> -
> - if (utf8ncursor(, data, s1->name, s1->len) < 0)
> - return -EINVAL;
> -
> - if (utf8ncursor(, data, s2->name, s2->len) < 0)
> - return -EINVAL;
> -
> - do {
> - c1 = utf8byte();
> - c2 = utf8byte();
> -
> - if (c1 < 0 || c2 < 0)
> - return -EINVAL;
> - if (c1 != c2)
> - return 1;
> - } while (c1);
> -
> - return 0;
> + return utf8_ops->strncmp(um, s1, s2);
> }
I think these would go on a header file and inlined.
> EXPORT_SYMBOL(unicode_strncmp);
>
> int unicode_strncasecmp(const struct unicode_map *um,
> const struct qstr *s1, const struct qstr *s2)
> {
> - const struct utf8data *data = utf8nfdicf(um->version);
> - struct utf8cursor cur1, cur2;
> - int c1, c2;
> -
> - if (utf8ncursor(, data, s1->name, s1->len) < 0)
> - return -EINVAL;
> -
> - if (utf8ncursor(, data, s2->name, s2->len) < 0)
> - return -EINVAL;
> -
> - do {
> - c1 = utf8byte();
> - c2 = utf8byte();
> -
> - if (c1 < 0 || c2 < 0)
> - return -EINVAL;
> - if (c1 != c2)
> - return 1;
> - } while (c1);
> -
> - return 0;
> + return utf8_ops->strncasecmp(um, s1, s2);
> }
> EXPORT_SYMBOL(unicode_strncasecmp);
>
> @@ -81,155 +40,73 @@ int unicode_strncasecmp_folded(const struct unicode_map
> *um,
> const struct qstr *cf,
> const struct qstr *s1)
> {
> - const struct utf8data *data = utf8nfdicf(um->version);
> - struct utf8cursor cur1;
> - int c1, c2;
> - int i = 0;
> -
> - if (utf8ncursor(, data, s1->name, s1->len) < 0)
> - return
Re: [PATCH 2/2] usb: webcam: Invalid size of Processing Unit Descriptor
On 21-03-08 11:27:35, Pawel Laszczak wrote:
> From: Pawel Laszczak
>
> According with USB Device Class Definition for Video Device the
> Processing Unit Descriptor bLength should be 12 (10 + bmControlSize),
> but it has 11.
Does the reason forget filling bmVideoStandards entry?
Peter
>
> Invalid length caused that Processing Unit Descriptor Test Video form
> CV tool failed. To fix this issue patch adds bmVideoStandards into
> uvc_processing_unit_descriptor structure.
>
> Signed-off-by: Pawel Laszczak
> ---
> include/uapi/linux/usb/video.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/usb/video.h b/include/uapi/linux/usb/video.h
> index d854cb19c42c..2a54e8fdd341 100644
> --- a/include/uapi/linux/usb/video.h
> +++ b/include/uapi/linux/usb/video.h
> @@ -302,6 +302,7 @@ struct uvc_processing_unit_descriptor {
> __u8 bControlSize;
> __u8 bmControls[2];
> __u8 iProcessing;
> + __u8 bmVideoStandards;
> } __attribute__((__packed__));
>
> #define UVC_DT_PROCESSING_UNIT_SIZE(n) (9+(n))
> --
> 2.25.1
>
--
Thanks,
Peter Chen
ERROR: modpost: "__aeabi_unwind_cpp_pr0" undefined!
Hi Mark, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 88fe49249c99de14e543c632a46248d85411ab9e commit: 4ecc08b2f51d874f35185724eda769492b60a18d Merge tag 'auxbus-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core into asoc-5.11 date: 3 months ago config: arm-randconfig-r024-20210314 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project dfd27ebbd0eb137c9a439b7c537bb87ba903efd3) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm cross compiling tool for clang build # apt-get install binutils-arm-linux-gnueabi # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4ecc08b2f51d874f35185724eda769492b60a18d git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 4ecc08b2f51d874f35185724eda769492b60a18d # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/hsr/hsr.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/nsh/nsh.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/vmw_vsock/vmw_vsock_virtio_transport.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/vmw_vsock/vsock_diag.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/vmw_vsock/vsock.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/batman-adv/batman-adv.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/mac802154/mac802154.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/9p/9pnet_virtio.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/9p/9pnet.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/lapb/lapb.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/appletalk/appletalk.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/llc/llc2.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/llc/llc.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/xdp/xsk_diag.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/qrtr/qrtr-smd.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/unix/unix_diag.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/em_text.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/em_nbyte.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/em_cmp.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/cls_matchall.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/cls_cgroup.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/cls_basic.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/cls_rsvp6.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/cls_u32.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_cbs.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_fq_pie.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_pie.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_hhf.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_ets.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_teql.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_dsmark.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_red.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/802/psnap.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/802/p8022.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/ftrace/sample-trace-array.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/trace_printk/trace-printk.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/rpmsg/rpmsg_client_sample.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/kobject/kset-example.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/kobject/kobject-example.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/vfio-mdev/mdpy-fb.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/ac97_bus.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/xilinx/snd-soc-xlnx-spdif.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/xilinx/snd-soc-xlnx-formatter-pcm.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0"
Re: [PATCH] gpu: drm: mediatek: delete redundant printing of return value
Hi, Wang:
Wang Qing 於 2021年3月13日 週六 下午3:48寫道：
>
> platform_get_irq() has already checked and printed the return value,
> the printing here is nothing special, it is not necessary at all.
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Signed-off-by: Wang Qing
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index b05f900..0ac4962
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -751,10 +751,8 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> }
>
> dpi->irq = platform_get_irq(pdev, 0);
> - if (dpi->irq <= 0) {
> - dev_err(dev, "Failed to get irq: %d\n", dpi->irq);
> + if (dpi->irq <= 0)
> return -EINVAL;
> - }
>
> ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> NULL, >next_bridge);
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 07/11] kentry: Make entry/exit_to_user_mode() arm64-only
On Mon, Mar 8, 2021 at 2:06 AM Mark Rutland wrote: > > On Thu, Mar 04, 2021 at 11:06:00AM -0800, Andy Lutomirski wrote: > > exit_to_user_mode() does part, but not all, of the exit-to-user-mode work. > > It's used only by arm64, and arm64 should stop using it (hint, hint!). > > Compile it out on other architectures to minimize the chance of error. > > For context, I do plan to move over, but there's a reasonable amount of > preparatory work needed first (e.g. factoring out the remaining asm > entry points, and reworking our pseudo-NMI management to play nicely > with the common entry code). > > > enter_from_user_mode() is a legacy way to spell > > kentry_enter_from_user_mode(). It's also only used by arm64. Give it > > the same treatment. > > I think you can remove these entirely, no ifdeferry necessary. > > Currently arm64 cannot select CONFIG_GENERIC_ENTRY, so we open-code > copies of these in arch/arm64/kernel/entry-common.c, and doesn't use > these common versions at all. When we move over to the common code we > can move directly to the kentry_* versions. If we are relying on the > prototypes anywhere, that's a bug as of itself. I got faked out! Fixed for the next version.
Re: [PATCH 2/3] net: ethernet: actions: Add Actions Semi Owl Ethernet MAC driver
Hi Andrew,
Thank you for the detailed review!
On Sat, Mar 13, 2021 at 02:01:19AM +0100, Andrew Lunn wrote:
> On Thu, Mar 11, 2021 at 03:20:13AM +0200, Cristian Ciocaltea wrote:
> > +static inline void owl_emac_reg_set(struct owl_emac_priv *priv,
> > + u32 reg, u32 bits)
> > +{
> > + owl_emac_reg_update(priv, reg, bits, bits);
> > +}
>
> Hi Cristian
>
> No inline functions in C files please. Let the compiler decide. Please
> fix them all.
Sure.
> > +static struct sk_buff *owl_emac_alloc_skb(struct net_device *netdev)
> > +{
> > + int offset;
> > + struct sk_buff *skb;
>
> Reverse Christmas tree please.
Already fixed this and all the others I could find.
> > +
> > + skb = netdev_alloc_skb(netdev, OWL_EMAC_RX_FRAME_MAX_LEN +
> > + OWL_EMAC_SKB_RESERVE);
> > + if (unlikely(!skb))
> > + return NULL;
> > +
> > + /* Ensure 4 bytes DMA alignment. */
> > + offset = ((uintptr_t)skb->data) & (OWL_EMAC_SKB_ALIGN - 1);
> > + if (unlikely(offset))
> > + skb_reserve(skb, OWL_EMAC_SKB_ALIGN - offset);
> > +
> > + return skb;
> > +}
> > +
> > +static void owl_emac_phy_config(struct owl_emac_priv *priv)
>
> You are not really configuring the PHY here, but configuring the MAC
> with what the PHY tells you has been negotiated. So maybe change this
> name?
Right, this was an uninspired choice on my side! I think something like
'owl_emac_update_link_state' would be more appropriate..
> > +{
> > + u32 val, status;
> > +
> > + if (priv->pause) {
> > + val = OWL_EMAC_BIT_MAC_CSR20_FCE | OWL_EMAC_BIT_MAC_CSR20_TUE;
> > + val |= OWL_EMAC_BIT_MAC_CSR20_TPE | OWL_EMAC_BIT_MAC_CSR20_RPE;
> > + val |= OWL_EMAC_BIT_MAC_CSR20_BPE;
> > + } else {
> > + val = 0;
> > + }
> > +
> > + /* Update flow control. */
> > + owl_emac_reg_write(priv, OWL_EMAC_REG_MAC_CSR20, val);
[...]
> > +static inline void owl_emac_ether_addr_push(u8 **dst, const u8 *src)
> > +{
> > + u32 *a = (u32 *)(*dst);
>
> Is *dst guaranteed to by 32bit aligned? Given that it is skb->data, i
> don't think it is.
>
> > + const u16 *b = (const u16 *)src;
> > +
> > + a[0] = b[0];
> > + a[1] = b[1];
> > + a[2] = b[2];
>
> So i don't know if this is safe. Some architectures don't like doing
> miss aligned read/writes. You probably should be using one of the
> put_unaligned_() macros.
Actually skb->data is 32bit aligned, as required by the MAC hardware
for DMA access - please see 'owl_emac_alloc_skb()'.
> > +
> > + *dst += 12;
> > +}
> > +
> > +static void
> > +owl_emac_setup_frame_prepare(struct owl_emac_priv *priv, struct sk_buff
> > *skb)
> > +{
> > + const u8 bcast_addr[] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };
> > + const u8 *mac_addr = priv->netdev->dev_addr;
> > + u8 *frame;
> > + int i;
> > +
> > + skb_put(skb, OWL_EMAC_SETUP_FRAME_LEN);
> > +
> > + frame = skb->data;
> > + memset(frame, 0, skb->len);
> > +
> > + owl_emac_ether_addr_push(, mac_addr);
> > + owl_emac_ether_addr_push(, bcast_addr);
> > +
> > + /* Fill multicast addresses. */
> > + WARN_ON(priv->mcaddr_list.count >= OWL_EMAC_MAX_MULTICAST_ADDRS);
> > + for (i = 0; i < priv->mcaddr_list.count; i++) {
> > + mac_addr = priv->mcaddr_list.addrs[i];
> > + owl_emac_ether_addr_push(, mac_addr);
> > + }
>
> Please could you add some comments to this. You are building a rather
> odd frame here! What is it used form?
Yes, I actually planned to document this but eventually I missed it.
The setup frames are special descriptors used to provide physical
addresses to the MAC hardware for filtering purposes.
[...]
> > +static void owl_emac_mdio_clock_enable(struct owl_emac_priv *priv)
> > +{
> > + u32 val;
> > +
> > + /* Enable MDC clock generation by setting CLKDIV to at least 128. */
>
> You should be aiming for 2.5MHz bus clock. Does this depend on the
> speed of one of the two clocks you have? Maybe you can dynamically
> calculate the divider?
Unfortunately this is not properly documented in the datasheet, so I
cannot tell which is the reference clock for the MDC clock divider.
With the current approach (taken from the old vendor driver code), the
divider is actually set to 1024 (obtained by OR-ing the HW default with
this "magic" 128 correspondent).
What I know for sure is that 'eth' clock has a fixed rate (25MHz), while
'rmii' is set by the driver to 50MHz, both of
drivers/gpu/drm/i915/gt/selftest_execlists.c:167:4: error: format string is not a string literal (potentially insecure)
Hi Chris,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 88fe49249c99de14e543c632a46248d85411ab9e
commit: 70a2b431c36483c0c06e589e11c59e438cd0ac06 drm/i915/gt: Rename lrc.c to
execlists_submission.c
date: 3 months ago
config: x86_64-randconfig-r034-20210314 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
dfd27ebbd0eb137c9a439b7c537bb87ba903efd3)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70a2b431c36483c0c06e589e11c59e438cd0ac06
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 70a2b431c36483c0c06e589e11c59e438cd0ac06
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from
drivers/gpu/drm/i915/gt/intel_execlists_submission.c:6116:
>> drivers/gpu/drm/i915/gt/selftest_execlists.c:167:4: error: format string is
>> not a string literal (potentially insecure) [-Werror,-Wformat-security]
GEM_TRACE("spinner failed to start\n");
^~
drivers/gpu/drm/i915/i915_gem.h:69:24: note: expanded from macro 'GEM_TRACE'
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
^
include/linux/kernel.h:724:3: note: expanded from macro 'trace_printk'
do_trace_printk(fmt, ##__VA_ARGS__);\
^~~
include/linux/kernel.h:738:30: note: expanded from macro 'do_trace_printk'
__trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
^~~~
drivers/gpu/drm/i915/gt/selftest_execlists.c:167:4: note: treat the string
as an argument to avoid this
drivers/gpu/drm/i915/i915_gem.h:69:24: note: expanded from macro 'GEM_TRACE'
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
^
include/linux/kernel.h:724:3: note: expanded from macro 'trace_printk'
do_trace_printk(fmt, ##__VA_ARGS__);\
^
include/linux/kernel.h:738:30: note: expanded from macro 'do_trace_printk'
__trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
^
In file included from
drivers/gpu/drm/i915/gt/intel_execlists_submission.c:6116:
drivers/gpu/drm/i915/gt/selftest_execlists.c:1790:4: error: format string is
not a string literal (potentially insecure) [-Werror,-Wformat-security]
GEM_TRACE("lo spinner failed to start\n");
^
drivers/gpu/drm/i915/i915_gem.h:69:24: note: expanded from macro 'GEM_TRACE'
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
^
include/linux/kernel.h:724:3: note: expanded from macro 'trace_printk'
do_trace_printk(fmt, ##__VA_ARGS__);\
^~~
include/linux/kernel.h:738:30: note: expanded from macro 'do_trace_printk'
__trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
^~~~
drivers/gpu/drm/i915/gt/selftest_execlists.c:1790:4: note: treat the string
as an argument to avoid this
drivers/gpu/drm/i915/i915_gem.h:69:24: note: expanded from macro 'GEM_TRACE'
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
^
include/linux/kernel.h:724:3: note: expanded from macro 'trace_printk'
do_trace_printk(fmt, ##__VA_ARGS__);\
^
include/linux/kernel.h:738:30: note: expanded from macro 'do_trace_printk'
__trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
^
In file included from
drivers/gpu/drm/i915/gt/intel_execlists_submission.c:6116:
drivers/gpu/drm/i915/gt/selftest_execlists.c:1807:4: error: format string is
not a string literal (potentially insecure) [-Werror,-Wformat-security]
GEM_TRACE("hi spinner failed to start\n");
^
drivers/gpu/drm/i915/i915_gem.h:69:24: note: expanded from
Re: [PATCH 3/3] fs: unicode: Make UTF-8 encoding loadable
Hi Shreeya,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on ext4/dev]
[also build test WARNING on f2fs/dev-test linux/master linus/master v5.12-rc2
next-20210312]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Shreeya-Patel/Make-UTF-8-encoding-loadable/20210314-071604
base: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
config: riscv-randconfig-r022-20210314 (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/85f4765787c386a4b949afaf9721046c0e85955a
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Shreeya-Patel/Make-UTF-8-encoding-loadable/20210314-071604
git checkout 85f4765787c386a4b949afaf9721046c0e85955a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In function 'utf8_parse_version',
inlined from 'utf8_load' at fs/unicode/utf8mod.c:195:7:
>> fs/unicode/utf8mod.c:175:2: warning: 'strncpy' specified bound 12 equals
>> destination size [-Wstringop-truncation]
175 | strncpy(version_string, version, sizeof(version_string));
| ^~~~
vim +/strncpy +175 fs/unicode/utf8mod.c
164
165 static int utf8_parse_version(const char *version, unsigned int *maj,
166unsigned int *min, unsigned int *rev)
167 {
168 substring_t args[3];
169 char version_string[12];
170 static const struct match_token token[] = {
171 {1, "%d.%d.%d"},
172 {0, NULL}
173 };
174
> 175 strncpy(version_string, version, sizeof(version_string));
176
177 if (match_token(version_string, token, args) != 1)
178 return -EINVAL;
179
180 if (match_int([0], maj) || match_int([1], min) ||
181 match_int([2], rev))
182 return -EINVAL;
183
184 return 0;
185 }
186
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] tools/x86/kcpuid: Add AMD Secure Encryption leaf
On Sat, Mar 13, 2021 at 03:01:18PM +0100, Borislav Petkov wrote: > From: Borislav Petkov > > Add the 0x801f leaf's fields. > > Signed-off-by: Borislav Petkov > --- > tools/arch/x86/kcpuid/cpuid.csv | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/tools/arch/x86/kcpuid/cpuid.csv b/tools/arch/x86/kcpuid/cpuid.csv > index f4a5b85073f4..7cb5c2189345 100644 > --- a/tools/arch/x86/kcpuid/cpuid.csv > +++ b/tools/arch/x86/kcpuid/cpuid.csv > @@ -378,3 +378,13 @@ > 0x8008,0, EAX,7:0, phy_adr_bits, Physical Address Bits > 0x8008,0, EAX, 15:8, lnr_adr_bits, Linear Address Bits > 0x8007,0, EBX, 9, wbnoinvd, WBNOINVD > + > +# 801F: AMD Secure Encryption > +0x801F, 0, EAX, 0, SME, Secure Memory Encryption > +0x801F, 0, EAX, 1, SEV, Secure Encrypted Virtualization > +0x801F, 0, EAX, 2, VmPgFlush, VM Page Flush MSR > +0x801F, 0, EAX, 3, SevEs, SEV Encrypted State > +0x801F, 0, EBX, 5:0, C-Bit, Page table bit number used to enable memory > encryption > +0x801F, 0, EBX, 11:6, MemEncryptPhysAddWidth, Reduction of physical > address space in bits when SME is enabled > +0x801F, 0, ECX, 31:0, NumEncryptedGuests, Maximum ASID value that may > be used for an SEV-enabled guest > +0x801F, 0, EDX, 31:0, MinimumSEVASID, Minimum ASID value that must be > used for an SEV-enabled, SEV-ES-disabled guest Yeah, I guess we should keep the bit names in lowercase, for simplicity. --- From: Borislav Petkov Date: Sat, 13 Mar 2021 14:56:16 +0100 Subject: [PATCH] tools/x86/kcpuid: Add AMD Secure Encryption leaf Add the 0x801f leaf's fields. Signed-off-by: Borislav Petkov --- tools/arch/x86/kcpuid/cpuid.csv | 10 ++ 1 file changed, 10 insertions(+) diff --git a/tools/arch/x86/kcpuid/cpuid.csv b/tools/arch/x86/kcpuid/cpuid.csv index f4a5b85073f4..dd94c07421a8 100644 --- a/tools/arch/x86/kcpuid/cpuid.csv +++ b/tools/arch/x86/kcpuid/cpuid.csv @@ -378,3 +378,13 @@ 0x8008,0, EAX,7:0, phy_adr_bits, Physical Address Bits 0x8008,0, EAX, 15:8, lnr_adr_bits, Linear Address Bits 0x8007,0, EBX, 9, wbnoinvd, WBNOINVD + +# 801F: AMD Secure Encryption +0x801F,0, EAX, 0, sme, Secure Memory Encryption +0x801F,0, EAX, 1, sev, Secure Encrypted Virtualization +0x801F,0, EAX, 2, vmpgflush, VM Page Flush MSR +0x801F,0, EAX, 3, seves, SEV Encrypted State +0x801F,0, EBX, 5:0, c-bit, Page table bit number used to enable memory encryption +0x801F,0, EBX, 11:6, mem_encrypt_physaddr_width, Reduction of physical address space in bits with SME enabled +0x801F,0, ECX, 31:0, num_encrypted_guests, Maximum ASID value that may be used for an SEV-enabled guest +0x801F,0, EDX, 31:0, minimum_sev_asid, Minimum ASID value that must be used for an SEV-enabled, SEV-ES-disabled guest -- 2.29.2 -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH 01/13] arm64: dts: qcom: sc7180: Update dts for DP phy inside QMP phy
On 26/02/2021 01:12, Douglas Anderson wrote:
From: Stephen Boyd
Drop the old node and add the new one in its place.
Cc: Stephen Boyd
Cc: Jeykumar Sankaran
Cc: Chandan Uddaraju
Cc: Vara Reddy
Cc: Tanmay Shah
Cc: Rob Clark
Signed-off-by: Stephen Boyd
[dianders: Adjusted due to DP not itself not in upstream dts yet]
Signed-off-by: Douglas Anderson
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 1ea3344ab62c..60248a6757d8 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2770,12 +2770,11 @@ usb_1_hsphy: phy@88e3000 {
};
usb_1_qmpphy: phy-wrapper@88e9000 {
- compatible = "qcom,sc7180-qmp-usb3-phy";
+ compatible = "qcom,sc7180-qmp-usb3-dp-phy";
reg = <0 0x088e9000 0 0x18c>,
- <0 0x088e8000 0 0x38>;
- reg-names = "reg-base", "dp_com";
+ <0 0x088e8000 0 0x38>,
Technically this should be 0x3c. Offset 0x38 is USB3_DP_COM_REVISION_ID3
(not used by the current driver though).
+ <0 0x088ea000 0 0x40>;
I think 0x40 is not enough here.
This is a serdes region and qmp_v3_dp_serdes_tbl contains registers
0x148 and 0x154.
status = "disabled";
- #clock-cells = <1>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
@@ -2790,7 +2789,7 @@ usb_1_qmpphy: phy-wrapper@88e9000 {
< GCC_USB3_DP_PHY_PRIM_BCR>;
reset-names = "phy", "common";
- usb_1_ssphy: phy@88e9200 {
+ usb_1_ssphy: usb3-phy@88e9200 {
reg = <0 0x088e9200 0 0x128>,
<0 0x088e9400 0 0x200>,
<0 0x088e9c00 0 0x218>,
@@ -2803,6 +2802,16 @@ usb_1_ssphy: phy@88e9200 {
clock-names = "pipe0";
clock-output-names = "usb3_phy_pipe_clk_src";
};
+
+ dp_phy: dp-phy@88ea200 {
+ reg = <0 0x088ea200 0 0x200>,
+ <0 0x088ea400 0 0x200>,
+ <0 0x088eaa00 0 0x200>,
+ <0 0x088ea600 0 0x200>,
+ <0 0x088ea800 0 0x200>;
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+ };
};
dc_noc: interconnect@916 {
@@ -3166,8 +3175,8 @@ dispcc: clock-controller@af0 {
< GCC_DISP_GPLL0_CLK_SRC>,
<_phy 0>,
<_phy 1>,
-<0>,
-<0>;
+<_phy 0>,
+<_phy 1>;
clock-names = "bi_tcxo",
"gcc_disp_gpll0_clk_src",
"dsi0_phy_pll_out_byteclk",
--
With best wishes
Dmitry
Re: [PATCH] gpio: mpc8xxx: Add ACPI support
Am 2021-03-12 12:07, schrieb Bartosz Golaszewski:
On Fri, Mar 12, 2021 at 7:51 AM Ran Wang wrote:
Current implementation only supports DT, now add ACPI support.
Note that compared to device of 'fsl,qoriq-gpio', LS1028A and
LS1088A's GPIO have no extra programming, so simplify related
checking.
Signed-off-by: Ran Wang
---
drivers/gpio/gpio-mpc8xxx.c | 50
+++--
1 file changed, 37 insertions(+), 13 deletions(-)
diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index 6dfca83bcd90..de5b7e17cde3 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -9,6 +9,7 @@
* kind, whether express or implied.
*/
+#include
#include
#include
#include
@@ -292,8 +293,6 @@ static const struct of_device_id
mpc8xxx_gpio_ids[] = {
{ .compatible = "fsl,mpc5121-gpio", .data =
_gpio_devtype, },
{ .compatible = "fsl,mpc5125-gpio", .data =
_gpio_devtype, },
{ .compatible = "fsl,pq3-gpio", },
- { .compatible = "fsl,ls1028a-gpio", },
- { .compatible = "fsl,ls1088a-gpio", },
Why are you removing support for those?
I guess because it doesn't matter because usually
compatible = "fsl,ls1028a-gpio", "fsl,qoriq-gpio";
is used. But I just had a look at the dt binding and it doesn't
mandate it. So please keep it.
-michael
Bart
{ .compatible = "fsl,qoriq-gpio", },
{}
};
@@ -303,10 +302,19 @@ static int mpc8xxx_probe(struct platform_device
*pdev)
struct device_node *np = pdev->dev.of_node;
struct mpc8xxx_gpio_chip *mpc8xxx_gc;
struct gpio_chip*gc;
- const struct mpc8xxx_gpio_devtype *devtype =
- of_device_get_match_data(>dev);
+ const struct mpc8xxx_gpio_devtype *devtype;
+ const struct acpi_device_id *acpi_id;
int ret;
+ if (pdev->dev.of_node) {
+ devtype = of_device_get_match_data(>dev);
+ } else {
+ acpi_id =
acpi_match_device(pdev->dev.driver->acpi_match_table,
+ >dev);
+ if (acpi_id)
+ devtype = (struct mpc8xxx_gpio_devtype *)
acpi_id->driver_data;
+ }
+
mpc8xxx_gc = devm_kzalloc(>dev, sizeof(*mpc8xxx_gc),
GFP_KERNEL);
if (!mpc8xxx_gc)
return -ENOMEM;
@@ -315,14 +323,14 @@ static int mpc8xxx_probe(struct platform_device
*pdev)
raw_spin_lock_init(_gc->lock);
- mpc8xxx_gc->regs = of_iomap(np, 0);
+ mpc8xxx_gc->regs = devm_platform_ioremap_resource(pdev, 0);
if (!mpc8xxx_gc->regs)
return -ENOMEM;
gc = _gc->gc;
gc->parent = >dev;
- if (of_property_read_bool(np, "little-endian")) {
+ if (device_property_read_bool(>dev, "little-endian")) {
ret = bgpio_init(gc, >dev, 4,
mpc8xxx_gc->regs + GPIO_DAT,
NULL, NULL,
@@ -369,10 +377,14 @@ static int mpc8xxx_probe(struct platform_device
*pdev)
* associated input enable must be set (GPIOxGPIE[IEn]=1) to
propagate
* the port value to the GPIO Data Register.
*/
- if (of_device_is_compatible(np, "fsl,qoriq-gpio") ||
- of_device_is_compatible(np, "fsl,ls1028a-gpio") ||
- of_device_is_compatible(np, "fsl,ls1088a-gpio"))
- gc->write_reg(mpc8xxx_gc->regs + GPIO_IBE,
0x);
+ if (pdev->dev.of_node) {
+ if (of_device_is_compatible(np, "fsl,qoriq-gpio"))
+ gc->write_reg(mpc8xxx_gc->regs + GPIO_IBE,
0x);
+ } else {
+ if
(acpi_match_device(pdev->dev.driver->acpi_match_table,
+ >dev))
+ gc->write_reg(mpc8xxx_gc->regs + GPIO_IBE,
0x);
+ }
ret = gpiochip_add_data(gc, mpc8xxx_gc);
if (ret) {
@@ -381,12 +393,15 @@ static int mpc8xxx_probe(struct platform_device
*pdev)
goto err;
}
- mpc8xxx_gc->irqn = irq_of_parse_and_map(np, 0);
+ mpc8xxx_gc->irqn = platform_get_irq(pdev, 0);
if (!mpc8xxx_gc->irqn)
return 0;
- mpc8xxx_gc->irq = irq_domain_add_linear(np, MPC8XXX_GPIO_PINS,
- _gpio_irq_ops,
mpc8xxx_gc);
+ mpc8xxx_gc->irq =
irq_domain_create_linear(dev_fwnode(>dev),
+ MPC8XXX_GPIO_PINS,
+
_gpio_irq_ops,
+ mpc8xxx_gc);
+
if (!mpc8xxx_gc->irq)
return 0;
@@ -425,12 +440,21 @@ static int mpc8xxx_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id gpio_acpi_ids[] = {
+ {"NXP0031",},
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, gpio_acpi_ids);
+#endif
+
static struct
ERROR: modpost: "__aeabi_unwind_cpp_pr0" undefined!
Hi Nathan, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 88fe49249c99de14e543c632a46248d85411ab9e commit: c39866f268f89868df17724cd2262d121552d8c9 arm/build: Always handle .ARM.exidx and .ARM.extab sections date: 5 months ago config: arm-randconfig-r024-20210314 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project dfd27ebbd0eb137c9a439b7c537bb87ba903efd3) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm cross compiling tool for clang build # apt-get install binutils-arm-linux-gnueabi # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c39866f268f89868df17724cd2262d121552d8c9 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout c39866f268f89868df17724cd2262d121552d8c9 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/hsr/hsr.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/nsh/nsh.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" >> [net/vmw_vsock/vmw_vsock_virtio_transport_common.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" >> [net/vmw_vsock/vmw_vsock_virtio_transport.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/vmw_vsock/vsock_diag.ko] >> undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/vmw_vsock/vsock.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/batman-adv/batman-adv.ko] >> undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/mac802154/mac802154.ko] >> undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/9p/9pnet_virtio.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/9p/9pnet.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/lapb/lapb.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/appletalk/appletalk.ko] >> undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/llc/llc2.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/llc/llc.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/xdp/xsk_diag.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/qrtr/qrtr-smd.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/unix/unix_diag.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/em_text.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/em_nbyte.ko] undefined! >> ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/em_cmp.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/cls_matchall.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/cls_cgroup.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/cls_basic.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/cls_rsvp6.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/cls_u32.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_cbs.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_fq_pie.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_pie.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_hhf.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_ets.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_teql.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_dsmark.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/sched/sch_red.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/802/psnap.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [net/802/p8022.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/ftrace/sample-trace-array.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/trace_printk/trace-printk.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/rpmsg/rpmsg_client_sample.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/kobject/kset-example.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/kobject/kobject-example.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [samples/vfio-mdev/mdpy-fb.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/ac97_bus.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/xilinx/snd-soc-xlnx-spdif.ko] undefined! ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/xilinx/snd-soc-xlnx-formatter-pcm.ko] undefined! ERROR: modpost:
[PATCH v2] PCI: Run platform power transition on initial D0 entry
On some devices and platforms, the initial platform (e.g. ACPI) power
state is not in sync with the power state of the PCI device.
This seems like it is, for all intents and purposes, an issue with the
device firmware (e.g. ACPI). On some devices, specifically Microsoft
Surface Books 2 and 3, we encounter ACPI code akin to the following
power resource, corresponding to a PCI device:
PowerResource (PRP5, 0x00, 0x)
{
// Initialized to zero, i.e. off. There is no logic for checking
// the actual state dynamically.
Name (_STA, Zero)
Method (_ON, 0, Serialized)
{
// ... code omitted ...
_STA = One
}
Method (_OFF, 0, Serialized)
{
// ... code omitted ...
_STA = Zero
}
}
This resource is initialized to 'off' and does not have any logic for
checking its actual state, i.e. the state of the corresponding PCI
device. The stored state of this resource can only be changed by running
the (platform/ACPI) power transition functions (i.e. _ON and _OFF).
This means that, at boot, the PCI device power state is out of sync with
the power state of the corresponding ACPI resource.
During initial bring-up of a PCI device, pci_enable_device_flags()
updates its PCI core state (from initially 'unknown') by reading from
its PCI_PM_CTRL register. It does, however, not check if the platform
(here ACPI) state is in sync with/valid for the actual device state and
needs updating.
The later call to pci_set_power_state(..., PCI_D0), which would normally
perform such platform transitions, will evaluate to a no-op if the
stored state has been updated to D0 via this. Thus any such power
resource, required for D0, will never get "officially" turned on.
One could also make the case that this could cause PCI devices requiring
some secondary power resources to not work properly, as no attempt is
ever made at checking that they are in fact synchronized (i.e. turned
on/off as required e.g. by ACPI) for the updated state.
Ultimately, this breaks the first D3cold entry for the discrete GPU on
the aforementioned Surface Books. On transition of the PCI device to
D3cold, the power resource is not properly turned off as it is already
considered off:
$ echo auto > /sys/bus/pci/devices/:02:00.0/power/control
[ 104.430304] ACPI: \_SB_.PCI0.RP05: ACPI: PM: GPE69 enabled for wakeup
[ 104.430310] pcieport :00:1c.4: Wakeup enabled by ACPI
[ 104.444144] ACPI: \_SB_.PCI0.RP05: ACPI: PM: Power state change: D3cold
-> D3cold
[ 104.444151] acpi device:3b: Device already in D3cold
[ 104.444154] pcieport :00:1c.4: power state changed by ACPI to D3cold
However, the device still consumes a non-negligible amount of power and
gets warm. A full power-cycle fixes this and results in the device being
properly transitioned to D3cold:
$ echo on > /sys/bus/pci/devices/:02:00.0/power/control
[ 134.258039] ACPI: \_SB_.PCI0.RP05: ACPI: PM: Power state change: D3cold
-> D0
[ 134.369140] ACPI: PM: Power resource [PRP5] turned on
[ 134.369157] acpi device:3b: Power state changed to D0
[ 134.369165] pcieport :00:1c.4: power state changed by ACPI to D0
[ 134.369338] pcieport :00:1c.4: Wakeup disabled by ACPI
$ echo auto > /sys/bus/pci/devices/:02:00.0/power/control
[ 310.338597] ACPI: \_SB_.PCI0.RP05: ACPI: PM: GPE69 enabled for wakeup
[ 310.338604] pcieport :00:1c.4: Wakeup enabled by ACPI
[ 310.353841] ACPI: \_SB_.PCI0.RP05: ACPI: PM: Power state change: D0 ->
D3cold
[ 310.403879] ACPI: PM: Power resource [PRP5] turned off
[ 310.403894] acpi device:3b: Power state changed to D3cold
[ 310.403901] pcieport :00:1c.4: power state changed by ACPI to D3cold
By replacing pci_set_power_state(..., PCI_DO) with pci_power_up() in
do_pci_enable_device(), we can ensure that the state of power resources
is always checked. This essentially drops the initial (first) check on
the current state of the PCI device and calls platform specific code,
i.e. pci_platform_power_transition() to perform the appropriate platform
transition.
This can be verified by
$ echo auto > /sys/bus/pci/devices/:02:00.0/power/control
[ 152.790448] ACPI: \_SB_.PCI0.RP05: ACPI: PM: GPE69 enabled for wakeup
[ 152.790454] pcieport :00:1c.4: Wakeup enabled by ACPI
[ 152.804252] ACPI: \_SB_.PCI0.RP05: ACPI: PM: Power state change: D0 ->
D3cold
[ 152.857548] ACPI: PM: Power resource [PRP5] turned off
[ 152.857563] acpi device:3b: Power state changed to D3cold
[ 152.857570] pcieport :00:1c.4: power state changed by ACPI to D3cold
which yields the expected behavior.
Note that
a) pci_set_power_state() would call pci_power_up() if the check on the
current state failed. This means that in case of the updated state not
being D0, there is no functional change.
b) The core and platform transitions, i.e.
Re: [PATCH RFC] net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc
Hi Yunsheng,
On Sat, Mar 13, 2021 at 10:47:47AM +0800, Yunsheng Lin wrote:
> Currently pfifo_fast has both TCQ_F_CAN_BYPASS and TCQ_F_NOLOCK
> flag set, but queue discipline by-pass does not work for lockless
> qdisc because skb is always enqueued to qdisc even when the qdisc
> is empty, see __dev_xmit_skb().
>
> This patch calles sch_direct_xmit() to transmit the skb directly
> to the driver for empty lockless qdisc too, which aviod enqueuing
> and dequeuing operation. qdisc->empty is set to false whenever a
> skb is enqueued, and is set to true when skb dequeuing return NULL,
> see pfifo_fast_dequeue().
>
> Also, qdisc is scheduled at the end of qdisc_run_end() when q->empty
> is false to avoid packet stuck problem.
>
> The performance for ip_forward test increases about 10% with this
> patch.
>
> Signed-off-by: Yunsheng Lin
> ---
I can confirm the ~10% IP forwarding throughput improvement brought by
this patch, but as you might be aware, there was a previous attempt to
add qdisc bypass to pfifo_fast by Paolo Abeni:
https://lore.kernel.org/netdev/661cc33a-5f65-2769-cc1a-65791cb4b...@pengutronix.de/
It was reverted because TX reordering was observed with SocketCAN
(although, presumably it should also be seen with Ethernet and such).
In fact I have a setup with two NXP LS1028A-RDB boards (which use the
drivers/net/can/flexcan.c driver and the pfifo_fast qdisc):
+---+ +---+
| | | |
| Generator | | DUT |
| |->| |
| canfdtest | reflector | canfdtest |
| |<-| |
|can1 | |can0 |
| | | |
+---+ +---+
where reordering happens in the TX side of the DUT and is noticed in the
RX side of the generator. The test frames are classic CAN, not CAN FD.
I was able to run the canfdtest described above successfully for several
hours (10 million CAN frames) on the current net-next (HEAD at commit
34bb97512641 ("net: fddi: skfp: Mundane typo fixes throughout the file
smt.h")) with no reordering.
Then, after applying your patch, I am seeing TX reordering within a few
minutes (less than 100K frames sent), therefore this reintroduces the
bug due to which Paolo's patch was reverted.
Sadly I am not knowledgeable enough to give you any hints as to what is
going wrong, but in case you have any ideas for debug, I would be glad
to test them out on my boards.
[tip:master] BUILD SUCCESS f34bf80037a1e8a00b948cbd5fac8e9d3c9b0b0f
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: f34bf80037a1e8a00b948cbd5fac8e9d3c9b0b0f Merge branch 'linus' elapsed time: 722m configs tested: 97 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig sh se7751_defconfig mipsmaltaup_defconfig sh sh7770_generic_defconfig riscv defconfig shedosk7705_defconfig arc axs103_defconfig sh defconfig powerpc64 defconfig arm mxs_defconfig xtensa iss_defconfig shhp6xx_defconfig sh sh7710voipgw_defconfig sh se7705_defconfig sh kfr2r09-romimage_defconfig arm cns3420vb_defconfig armmini2440_defconfig arm s3c2410_defconfig powerpc mpc836x_mds_defconfig sh microdev_defconfig mipsomega2p_defconfig powerpc ppc64_defconfig riscv nommu_k210_sdcard_defconfig shshmin_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20210313 i386 randconfig-a005-20210313 i386 randconfig-a002-20210313 i386 randconfig-a003-20210313 i386 randconfig-a004-20210313 i386 randconfig-a006-20210313 i386 randconfig-a013-20210313 i386 randconfig-a016-20210313 i386 randconfig-a011-20210313 i386 randconfig-a015-20210313 i386 randconfig-a014-20210313 i386 randconfig-a012-20210313 x86_64 randconfig-a006-20210313 x86_64 randconfig-a001-20210313 x86_64 randconfig-a005-20210313 x86_64 randconfig-a003-20210313 x86_64 randconfig-a002-20210313 x86_64 randconfig-a004-20210313 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv rv32_defconfig riscvallmodconfig x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a011-20210313 x86_64 randconfig-a016-20210313 x86_64 randconfig-a013-20210313 x86_64 randconfig-a014-20210313 x86_64 randconfig-a015-20210313 x86_64 randconfig-a012-20210313 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] tty: vt: Mundane typo fix in the file vt.c
s/spurrious/spurious/ Signed-off-by: Bhaskar Chowdhury --- drivers/tty/vt/vt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index 284b07224c55..c29e16505dd9 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -4448,7 +4448,7 @@ void poke_blanked_console(void) might_sleep(); /* This isn't perfectly race free, but a race here would be mostly harmless, -* at worse, we'll do a spurrious blank and it's unlikely +* at worse, we'll do a spurious blank and it's unlikely */ del_timer(_timer); blank_timer_expired = 0; -- 2.26.2
Re: [PATCH] docs: devicetree: bindings: sound: Fix a typo in the file rt5682.txt
On 3/13/21 3:18 PM, Bhaskar Chowdhury wrote: > > s/drving/driving/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > Documentation/devicetree/bindings/sound/rt5682.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/sound/rt5682.txt > b/Documentation/devicetree/bindings/sound/rt5682.txt > index 9c5fadb6ac82..cd8c53d8497e 100644 > --- a/Documentation/devicetree/bindings/sound/rt5682.txt > +++ b/Documentation/devicetree/bindings/sound/rt5682.txt > @@ -44,7 +44,7 @@ Optional properties: > - realtek,dmic-delay-ms : Set the delay time (ms) for the requirement of >the particular DMIC. > > -- realtek,dmic-clk-driving-high : Set the high drving of the DMIC clock out. > +- realtek,dmic-clk-driving-high : Set the high driving of the DMIC clock out. > > Pins on the device (for linking into audio routes) for RT5682: > > -- -- ~Randy
[PATCH] docs: devicetree: bindings: sound: Fix a typo in the file rt5682.txt
s/drving/driving/ Signed-off-by: Bhaskar Chowdhury --- Documentation/devicetree/bindings/sound/rt5682.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/rt5682.txt b/Documentation/devicetree/bindings/sound/rt5682.txt index 9c5fadb6ac82..cd8c53d8497e 100644 --- a/Documentation/devicetree/bindings/sound/rt5682.txt +++ b/Documentation/devicetree/bindings/sound/rt5682.txt @@ -44,7 +44,7 @@ Optional properties: - realtek,dmic-delay-ms : Set the delay time (ms) for the requirement of the particular DMIC. -- realtek,dmic-clk-driving-high : Set the high drving of the DMIC clock out. +- realtek,dmic-clk-driving-high : Set the high driving of the DMIC clock out. Pins on the device (for linking into audio routes) for RT5682: -- 2.26.2
[PATCH 3/3] fs: unicode: Add utf8 module and a unicode layer
utf8data.h_shipped has a large database table which is an auto-generated
decodification trie for the unicode normalization functions.
It is not necessary to carry this large table in the kernel hence make
UTF-8 encoding loadable by converting it into a module.
Also, modify the file called unicode-core which will act as a layer for
unicode subsystem. It will load the UTF-8 module and access it's functions
whenever any filesystem that needs unicode is mounted.
Signed-off-by: Shreeya Patel
---
fs/unicode/Kconfig| 7 +-
fs/unicode/Makefile | 5 +-
fs/unicode/unicode-core.c | 201 ++-
fs/unicode/utf8-core.c| 112 +
fs/unicode/utf8mod.c | 246 ++
include/linux/unicode.h | 20
6 files changed, 427 insertions(+), 164 deletions(-)
create mode 100644 fs/unicode/utf8-core.c
create mode 100644 fs/unicode/utf8mod.c
diff --git a/fs/unicode/Kconfig b/fs/unicode/Kconfig
index 2c27b9a5cd6c..33a27deef729 100644
--- a/fs/unicode/Kconfig
+++ b/fs/unicode/Kconfig
@@ -8,7 +8,12 @@ config UNICODE
Say Y here to enable UTF-8 NFD normalization and NFD+CF casefolding
support.
+config UNICODE_UTF8
+ tristate "UTF-8 module"
+ depends on UNICODE
+ default m
+
config UNICODE_NORMALIZATION_SELFTEST
tristate "Test UTF-8 normalization support"
- depends on UNICODE
+ depends on UNICODE_UTF8
default n
diff --git a/fs/unicode/Makefile b/fs/unicode/Makefile
index fbf9a629ed0d..9dbb04194b32 100644
--- a/fs/unicode/Makefile
+++ b/fs/unicode/Makefile
@@ -1,11 +1,14 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_UNICODE) += unicode.o
+obj-$(CONFIG_UNICODE_UTF8) += utf8.o
obj-$(CONFIG_UNICODE_NORMALIZATION_SELFTEST) += utf8-selftest.o
-unicode-y := utf8-norm.o unicode-core.o
+unicode-y := unicode-core.o
+utf8-y := utf8mod.o utf8-norm.o
$(obj)/utf8-norm.o: $(obj)/utf8data.h
+$(obj)/utf8mod.o: $(obj)/utf8-norm.o
# In the normal build, the checked-in utf8data.h is just shipped.
#
diff --git a/fs/unicode/unicode-core.c b/fs/unicode/unicode-core.c
index d5f09e022ac5..b832341f1e7b 100644
--- a/fs/unicode/unicode-core.c
+++ b/fs/unicode/unicode-core.c
@@ -7,70 +7,29 @@
#include
#include
#include
+#include
-#include "utf8n.h"
+struct unicode_ops *utf8_ops;
+
+static int unicode_load_module(void);
int unicode_validate(const struct unicode_map *um, const struct qstr *str)
{
- const struct utf8data *data = utf8nfdi(um->version);
-
- if (utf8nlen(data, str->name, str->len) < 0)
- return -1;
- return 0;
+ return utf8_ops->validate(um, str);
}
EXPORT_SYMBOL(unicode_validate);
int unicode_strncmp(const struct unicode_map *um,
const struct qstr *s1, const struct qstr *s2)
{
- const struct utf8data *data = utf8nfdi(um->version);
- struct utf8cursor cur1, cur2;
- int c1, c2;
-
- if (utf8ncursor(, data, s1->name, s1->len) < 0)
- return -EINVAL;
-
- if (utf8ncursor(, data, s2->name, s2->len) < 0)
- return -EINVAL;
-
- do {
- c1 = utf8byte();
- c2 = utf8byte();
-
- if (c1 < 0 || c2 < 0)
- return -EINVAL;
- if (c1 != c2)
- return 1;
- } while (c1);
-
- return 0;
+ return utf8_ops->strncmp(um, s1, s2);
}
EXPORT_SYMBOL(unicode_strncmp);
int unicode_strncasecmp(const struct unicode_map *um,
const struct qstr *s1, const struct qstr *s2)
{
- const struct utf8data *data = utf8nfdicf(um->version);
- struct utf8cursor cur1, cur2;
- int c1, c2;
-
- if (utf8ncursor(, data, s1->name, s1->len) < 0)
- return -EINVAL;
-
- if (utf8ncursor(, data, s2->name, s2->len) < 0)
- return -EINVAL;
-
- do {
- c1 = utf8byte();
- c2 = utf8byte();
-
- if (c1 < 0 || c2 < 0)
- return -EINVAL;
- if (c1 != c2)
- return 1;
- } while (c1);
-
- return 0;
+ return utf8_ops->strncasecmp(um, s1, s2);
}
EXPORT_SYMBOL(unicode_strncasecmp);
@@ -81,155 +40,73 @@ int unicode_strncasecmp_folded(const struct unicode_map
*um,
const struct qstr *cf,
const struct qstr *s1)
{
- const struct utf8data *data = utf8nfdicf(um->version);
- struct utf8cursor cur1;
- int c1, c2;
- int i = 0;
-
- if (utf8ncursor(, data, s1->name, s1->len) < 0)
- return -EINVAL;
-
- do {
- c1 = utf8byte();
- c2 = cf->name[i++];
- if (c1 < 0)
- return -EINVAL;
- if (c1 != c2)
- return 1;
- } while (c1);
-
- return 0;
+ return
[PATCH 3/3] fs: unicode: Make UTF-8 encoding loadable
utf8data.h_shipped has a large database table which is an auto-generated
decodification trie for the unicode normalization functions.
It is not necessary to carry this large table in the kernel hence make
UTF-8 encoding loadable by converting it into a module.
Also, modify the file called unicode-core which will act as a layer for
unicode subsystem. It will load the UTF-8 module and access it's functions
whenever any filesystem that needs unicode is mounted.
Signed-off-by: Shreeya Patel
---
fs/unicode/Kconfig| 7 +-
fs/unicode/Makefile | 5 +-
fs/unicode/unicode-core.c | 201 ++-
fs/unicode/utf8-core.c| 112 +
fs/unicode/utf8mod.c | 246 ++
include/linux/unicode.h | 20
6 files changed, 427 insertions(+), 164 deletions(-)
create mode 100644 fs/unicode/utf8-core.c
create mode 100644 fs/unicode/utf8mod.c
diff --git a/fs/unicode/Kconfig b/fs/unicode/Kconfig
index 2c27b9a5cd6c..33a27deef729 100644
--- a/fs/unicode/Kconfig
+++ b/fs/unicode/Kconfig
@@ -8,7 +8,12 @@ config UNICODE
Say Y here to enable UTF-8 NFD normalization and NFD+CF casefolding
support.
+config UNICODE_UTF8
+ tristate "UTF-8 module"
+ depends on UNICODE
+ default m
+
config UNICODE_NORMALIZATION_SELFTEST
tristate "Test UTF-8 normalization support"
- depends on UNICODE
+ depends on UNICODE_UTF8
default n
diff --git a/fs/unicode/Makefile b/fs/unicode/Makefile
index fbf9a629ed0d..9dbb04194b32 100644
--- a/fs/unicode/Makefile
+++ b/fs/unicode/Makefile
@@ -1,11 +1,14 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_UNICODE) += unicode.o
+obj-$(CONFIG_UNICODE_UTF8) += utf8.o
obj-$(CONFIG_UNICODE_NORMALIZATION_SELFTEST) += utf8-selftest.o
-unicode-y := utf8-norm.o unicode-core.o
+unicode-y := unicode-core.o
+utf8-y := utf8mod.o utf8-norm.o
$(obj)/utf8-norm.o: $(obj)/utf8data.h
+$(obj)/utf8mod.o: $(obj)/utf8-norm.o
# In the normal build, the checked-in utf8data.h is just shipped.
#
diff --git a/fs/unicode/unicode-core.c b/fs/unicode/unicode-core.c
index d5f09e022ac5..b832341f1e7b 100644
--- a/fs/unicode/unicode-core.c
+++ b/fs/unicode/unicode-core.c
@@ -7,70 +7,29 @@
#include
#include
#include
+#include
-#include "utf8n.h"
+struct unicode_ops *utf8_ops;
+
+static int unicode_load_module(void);
int unicode_validate(const struct unicode_map *um, const struct qstr *str)
{
- const struct utf8data *data = utf8nfdi(um->version);
-
- if (utf8nlen(data, str->name, str->len) < 0)
- return -1;
- return 0;
+ return utf8_ops->validate(um, str);
}
EXPORT_SYMBOL(unicode_validate);
int unicode_strncmp(const struct unicode_map *um,
const struct qstr *s1, const struct qstr *s2)
{
- const struct utf8data *data = utf8nfdi(um->version);
- struct utf8cursor cur1, cur2;
- int c1, c2;
-
- if (utf8ncursor(, data, s1->name, s1->len) < 0)
- return -EINVAL;
-
- if (utf8ncursor(, data, s2->name, s2->len) < 0)
- return -EINVAL;
-
- do {
- c1 = utf8byte();
- c2 = utf8byte();
-
- if (c1 < 0 || c2 < 0)
- return -EINVAL;
- if (c1 != c2)
- return 1;
- } while (c1);
-
- return 0;
+ return utf8_ops->strncmp(um, s1, s2);
}
EXPORT_SYMBOL(unicode_strncmp);
int unicode_strncasecmp(const struct unicode_map *um,
const struct qstr *s1, const struct qstr *s2)
{
- const struct utf8data *data = utf8nfdicf(um->version);
- struct utf8cursor cur1, cur2;
- int c1, c2;
-
- if (utf8ncursor(, data, s1->name, s1->len) < 0)
- return -EINVAL;
-
- if (utf8ncursor(, data, s2->name, s2->len) < 0)
- return -EINVAL;
-
- do {
- c1 = utf8byte();
- c2 = utf8byte();
-
- if (c1 < 0 || c2 < 0)
- return -EINVAL;
- if (c1 != c2)
- return 1;
- } while (c1);
-
- return 0;
+ return utf8_ops->strncasecmp(um, s1, s2);
}
EXPORT_SYMBOL(unicode_strncasecmp);
@@ -81,155 +40,73 @@ int unicode_strncasecmp_folded(const struct unicode_map
*um,
const struct qstr *cf,
const struct qstr *s1)
{
- const struct utf8data *data = utf8nfdicf(um->version);
- struct utf8cursor cur1;
- int c1, c2;
- int i = 0;
-
- if (utf8ncursor(, data, s1->name, s1->len) < 0)
- return -EINVAL;
-
- do {
- c1 = utf8byte();
- c2 = cf->name[i++];
- if (c1 < 0)
- return -EINVAL;
- if (c1 != c2)
- return 1;
- } while (c1);
-
- return 0;
+ return
[PATCH 2/3] fs: unicode: Rename utf8-core file to unicode-core
Rename the file name from utf8-core to unicode-core for transformation of
utf8-core file into the unicode subsystem layer file and also for better
understanding.
Signed-off-by: Shreeya Patel
---
fs/unicode/Makefile| 2 +-
fs/unicode/{utf8-core.c => unicode-core.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename fs/unicode/{utf8-core.c => unicode-core.c} (100%)
diff --git a/fs/unicode/Makefile b/fs/unicode/Makefile
index b88aecc86550..fbf9a629ed0d 100644
--- a/fs/unicode/Makefile
+++ b/fs/unicode/Makefile
@@ -3,7 +3,7 @@
obj-$(CONFIG_UNICODE) += unicode.o
obj-$(CONFIG_UNICODE_NORMALIZATION_SELFTEST) += utf8-selftest.o
-unicode-y := utf8-norm.o utf8-core.o
+unicode-y := utf8-norm.o unicode-core.o
$(obj)/utf8-norm.o: $(obj)/utf8data.h
diff --git a/fs/unicode/utf8-core.c b/fs/unicode/unicode-core.c
similarity index 100%
rename from fs/unicode/utf8-core.c
rename to fs/unicode/unicode-core.c
--
2.30.1
[PATCH 1/3] fs: unicode: Rename function names from utf8 to unicode
Rename the function names from utf8 to unicode for taking the first step
towards the transformation of utf8-core file into the unicode subsystem
layer file.
Signed-off-by: Shreeya Patel
---
fs/ext4/hash.c | 2 +-
fs/ext4/namei.c| 12
fs/ext4/super.c| 6 ++--
fs/f2fs/dir.c | 12
fs/f2fs/super.c| 6 ++--
fs/libfs.c | 6 ++--
fs/unicode/utf8-core.c | 57 +++---
fs/unicode/utf8-selftest.c | 8 +++---
include/linux/unicode.h| 32 ++---
9 files changed, 70 insertions(+), 71 deletions(-)
diff --git a/fs/ext4/hash.c b/fs/ext4/hash.c
index a92eb79de0cc..8890a76abe86 100644
--- a/fs/ext4/hash.c
+++ b/fs/ext4/hash.c
@@ -285,7 +285,7 @@ int ext4fs_dirhash(const struct inode *dir, const char
*name, int len,
if (!buff)
return -ENOMEM;
- dlen = utf8_casefold(um, , buff, PATH_MAX);
+ dlen = unicode_casefold(um, , buff, PATH_MAX);
if (dlen < 0) {
kfree(buff);
goto opaque_seq;
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 686bf982c84e..dde5ce795416 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1290,9 +1290,9 @@ int ext4_ci_compare(const struct inode *parent, const
struct qstr *name,
int ret;
if (quick)
- ret = utf8_strncasecmp_folded(um, name, entry);
+ ret = unicode_strncasecmp_folded(um, name, entry);
else
- ret = utf8_strncasecmp(um, name, entry);
+ ret = unicode_strncasecmp(um, name, entry);
if (ret < 0) {
/* Handle invalid character sequence as either an error
@@ -1324,9 +1324,9 @@ void ext4_fname_setup_ci_filename(struct inode *dir,
const struct qstr *iname,
if (!cf_name->name)
return;
- len = utf8_casefold(dir->i_sb->s_encoding,
- iname, cf_name->name,
- EXT4_NAME_LEN);
+ len = unicode_casefold(dir->i_sb->s_encoding,
+ iname, cf_name->name,
+ EXT4_NAME_LEN);
if (len <= 0) {
kfree(cf_name->name);
cf_name->name = NULL;
@@ -2201,7 +2201,7 @@ static int ext4_add_entry(handle_t *handle, struct dentry
*dentry,
#ifdef CONFIG_UNICODE
if (sb_has_strict_encoding(sb) && IS_CASEFOLDED(dir) &&
- sb->s_encoding && utf8_validate(sb->s_encoding, >d_name))
+ sb->s_encoding && unicode_validate(sb->s_encoding, >d_name))
return -EINVAL;
#endif
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index ad34a37278cd..2fb845752c90 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1259,7 +1259,7 @@ static void ext4_put_super(struct super_block *sb)
fs_put_dax(sbi->s_daxdev);
fscrypt_free_dummy_policy(>s_dummy_enc_policy);
#ifdef CONFIG_UNICODE
- utf8_unload(sb->s_encoding);
+ unicode_unload(sb->s_encoding);
#endif
kfree(sbi);
}
@@ -4304,7 +4304,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
goto failed_mount;
}
- encoding = utf8_load(encoding_info->version);
+ encoding = unicode_load(encoding_info->version);
if (IS_ERR(encoding)) {
ext4_msg(sb, KERN_ERR,
"can't mount with superblock charset: %s-%s "
@@ -5165,7 +5165,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
crypto_free_shash(sbi->s_chksum_driver);
#ifdef CONFIG_UNICODE
- utf8_unload(sb->s_encoding);
+ unicode_unload(sb->s_encoding);
#endif
#ifdef CONFIG_QUOTA
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index e6270a867be1..f160f9dd667d 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -84,10 +84,10 @@ int f2fs_init_casefolded_name(const struct inode *dir,
GFP_NOFS);
if (!fname->cf_name.name)
return -ENOMEM;
- fname->cf_name.len = utf8_casefold(sb->s_encoding,
- fname->usr_fname,
- fname->cf_name.name,
- F2FS_NAME_LEN);
+ fname->cf_name.len = unicode_casefold(sb->s_encoding,
+ fname->usr_fname,
+ fname->cf_name.name,
+ F2FS_NAME_LEN);
if ((int)fname->cf_name.len <= 0) {
kfree(fname->cf_name.name);
fname->cf_name.name = NULL;
@@ -237,7 +237,7 @@ static int f2fs_match_ci_name(const
[PATCH 0/3] Make UTF-8 encoding loadable
utf8data.h_shipped has a large database table which is an auto-generated decodification trie for the unicode normalization functions and it is not necessary to carry this large table in the kernel. Goal is to make UTF-8 encoding loadable by converting it into a module and adding a layer between the filesystems and the utf8 module which will load the module whenever any filesystem that needs unicode is mounted. Unicode is the subsystem and utf8 is a charachter encoding for the subsystem, hence first two patches in the series are renaming functions and file name to unicode for better understanding the difference between UTF-8 module and unicode layer. Last patch in the series adds the layer and utf8 module. Shreeya Patel (3): fs: unicode: Rename function names from utf8 to unicode fs: unicode: Rename utf8-core file to unicode-core fs: unicode: Add utf8 module and a unicode layer fs/ext4/hash.c | 2 +- fs/ext4/namei.c| 12 +- fs/ext4/super.c| 6 +- fs/f2fs/dir.c | 12 +- fs/f2fs/super.c| 6 +- fs/libfs.c | 6 +- fs/unicode/Kconfig | 7 +- fs/unicode/Makefile| 5 +- fs/unicode/unicode-core.c | 112 + fs/unicode/utf8-core.c | 248 ++--- fs/unicode/utf8-selftest.c | 8 +- fs/unicode/utf8mod.c | 246 include/linux/unicode.h| 52 +--- 13 files changed, 492 insertions(+), 230 deletions(-) create mode 100644 fs/unicode/unicode-core.c create mode 100644 fs/unicode/utf8mod.c -- 2.30.1
Re: [PATCH 1/2] clk: Add clk_get_first_to_set_rate
Hi Stephen, Le sam. 13 mars 2021 à 14:28, Stephen Boyd a écrit : Quoting Paul Cercueil (2021-03-07 09:07:41) The purpose of this function is to be used along with the notifier mechanism. When a parent clock can see its rate externally changed at any moment, and a driver needs a specific clock rate to function, it can register a notifier on the parent clock, and call clk_set_rate() on the base clock to adjust its frequency according to the new parent clock. Can the driver use the rate locking mechanism to get a certain rate instead of registering for notifiers and trying to react to changes? You mean with clk_rate_exclusive_get()? That sounds like a good idea, but what would happen when a different driver calls the non-exclusive clk_set_rate() on this clock (or the parent), would it return -EBUSY, lock on a mutex? ... Cheers, -Paul This works fine, until the base clock has the CLK_SET_RATE_PARENT flag set. In that case, calling clk_set_rate() on the base clock will call clk_set_rate() on the parent clock, which will trigger the notifier again, and we're in a loop. For that reason, we need to register the notifier on the parent clock of the first ancestor of the base clock that will effectively modify its rate when clk_set_rate() is called, which we can now obtain with clk_get_first_to_set_rate(). Signed-off-by: Paul Cercueil
Re: [PATCH] perf-stat: introduce bperf, share hardware PMCs with BPF
> On Mar 13, 2021, at 2:06 PM, Jiri Olsa wrote:
>
> On Fri, Mar 12, 2021 at 04:09:53PM +, Song Liu wrote:
>>
>>
>>> On Mar 12, 2021, at 7:45 AM, Song Liu wrote:
>>>
>>>
>>>
On Mar 12, 2021, at 4:12 AM, Jiri Olsa wrote:
On Thu, Mar 11, 2021 at 06:02:57PM -0800, Song Liu wrote:
> perf uses performance monitoring counters (PMCs) to monitor system
> performance. The PMCs are limited hardware resources. For example,
> Intel CPUs have 3x fixed PMCs and 4x programmable PMCs per cpu.
>
> Modern data center systems use these PMCs in many different ways:
> system level monitoring, (maybe nested) container level monitoring, per
> process monitoring, profiling (in sample mode), etc. In some cases,
> there are more active perf_events than available hardware PMCs. To allow
> all perf_events to have a chance to run, it is necessary to do expensive
> time multiplexing of events.
>
> On the other hand, many monitoring tools count the common metrics (cycles,
> instructions). It is a waste to have multiple tools create multiple
> perf_events of "cycles" and occupy multiple PMCs.
>
> bperf tries to reduce such wastes by allowing multiple perf_events of
> "cycles" or "instructions" (at different scopes) to share PMUs. Instead
> of having each perf-stat session to read its own perf_events, bperf uses
> BPF programs to read the perf_events and aggregate readings to BPF maps.
> Then, the perf-stat session(s) reads the values from these BPF maps.
>
> Please refer to the comment before the definition of bperf_ops for the
> description of bperf architecture.
>
> bperf is off by default. To enable it, pass --use-bpf option to perf-stat.
> bperf uses a BPF hashmap to share information about BPF programs and maps
> used by bperf. This map is pinned to bpffs. The default address is
> /sys/fs/bpf/bperf_attr_map. The user could change the address with option
> --attr-map.
nice, I recall the presentation about that and was wondering
when this will come up ;-)
>>>
>>> The progress is slower than I expected. But I finished some dependencies of
>>> this in the last year:
>>>
>>> 1. BPF_PROG_TEST_RUN for raw_tp event;
>>> 2. perf-stat -b, which introduced skeleton and bpf_counter;
>>> 3. BPF task local storage, I didn't use it in this version, but it could,
>>>help optimize bperf in the future.
>>>
>
> ---
> Known limitations:
> 1. Do not support per cgroup events;
> 2. Do not support monitoring of BPF program (perf-stat -b);
> 3. Do not support event groups.
>
> The following commands have been tested:
>
> perf stat --use-bpf -e cycles -a
> perf stat --use-bpf -e cycles -C 1,3,4
> perf stat --use-bpf -e cycles -p 123
> perf stat --use-bpf -e cycles -t 100,101
I assume the output is same as standard perf?
>>
>> Btw, please give it a try. :)
>>
>> It worked pretty well in my tests. If it doesn't work for some combination
>> of options, please let me know.
>
> heya, can't compile
>
> CLANG
> /home/jolsa/linux-perf/tools/perf/util/bpf_skel/.tmp/bperf_follower.bpf.o
> util/bpf_skel/bperf_follower.bpf.c:8:10: fatal error: 'bperf_u.h' file not
> found
> #include "bperf_u.h"
> ^~~
Oops, I forgot git-add. :(
The file is very simple:
tools/perf/util/bpf_skel/bperf_u.h:
// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
// Copyright (c) 2021 Facebook
#ifndef __BPERF_STAT_U_H
#define __BPERF_STAT_U_H
enum bperf_filter_type {
BPERF_FILTER_GLOBAL = 1,
BPERF_FILTER_CPU,
BPERF_FILTER_PID,
BPERF_FILTER_TGID,
};
#endif /* __BPERF_STAT_U_H */
Thanks,
Song
Re: [PATCH v2] clk: qcom: clk-rcg2: Add support for duty-cycle for RCG
Quoting Taniya Das (2021-03-11 04:51:32)
> The root clock generators with MND divider has the capability to support
> change in duty-cycle by updating the 'D'. Add the clock ops which would
> check all the boundary conditions and enable setting the desired duty-cycle
> as per the consumer.
>
> Signed-off-by: Taniya Das
> ---
> drivers/clk/qcom/clk-rcg2.c | 42 ++
> 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
> index 42f13a2..aac6893 100644
> --- a/drivers/clk/qcom/clk-rcg2.c
> +++ b/drivers/clk/qcom/clk-rcg2.c
> @@ -357,6 +357,46 @@ static int clk_rcg2_set_floor_rate_and_parent(struct
> clk_hw *hw,
> return __clk_rcg2_set_rate(hw, rate, FLOOR);
> }
>
> +static int clk_rcg2_set_duty_cycle(struct clk_hw *hw, struct clk_duty *duty)
> +{
> + struct clk_rcg2 *rcg = to_clk_rcg2(hw);
> + u32 notn_m_val, n_val, m_val, d_val, not2d_val, mask, duty_per;
> + int ret;
> +
> + if (!rcg->mnd_width)
> + return 0;
Shouldn't we fail this call if the duty cycle can't be changed? Or have
another set of clk ops that doesn't support this clk op if the mnd
isn't present.
> +
> + mask = BIT(rcg->mnd_width) - 1;
> +
> + regmap_read(rcg->clkr.regmap, RCG_N_OFFSET(rcg), _m_val);
> + regmap_read(rcg->clkr.regmap, RCG_M_OFFSET(rcg), _val);
> +
> + n_val = (~(notn_m_val) + m_val) & mask;
> +
> + duty_per = (duty->num * 100) / duty->den;
> +
> + /* Calculate 2d value */
> + d_val = DIV_ROUND_CLOSEST(n_val * duty_per * 2, 100);
> +
> +/* Check BIT WIDTHS OF 2d. If D is too big reduce Duty cycle. */
Why is BIT WIDTHS capitalized? And Duty?
> + if (d_val > mask)
> + d_val = mask;
> +
> + if ((d_val / 2) > (n_val - m_val))
> + d_val = (n_val - m_val) * 2;
> + else if ((d_val / 2) < (m_val / 2))
> + d_val = m_val;
> +
> + not2d_val = ~d_val & mask;
> +
> + ret = regmap_update_bits(rcg->clkr.regmap, RCG_D_OFFSET(rcg), mask,
> +not2d_val);
> + if (ret)
> + return ret;
> +
> + return update_config(rcg);
> +}
> +
> const struct clk_ops clk_rcg2_ops = {
> .is_enabled = clk_rcg2_is_enabled,
> .get_parent = clk_rcg2_get_parent,
> @@ -365,6 +405,7 @@ const struct clk_ops clk_rcg2_ops = {
> .determine_rate = clk_rcg2_determine_rate,
> .set_rate = clk_rcg2_set_rate,
> .set_rate_and_parent = clk_rcg2_set_rate_and_parent,
> + .set_duty_cycle = clk_rcg2_set_duty_cycle,
Can you also implement get_duty_cycle?
> };
> EXPORT_SYMBOL_GPL(clk_rcg2_ops);
>
Re: [PATCH 1/4] mips: bmips: add BCM63268 timer clock definitions
Subject should probably be clk related instead of mips prefixed. Or dt-bindings: clk: ?
Re: [PATCH v1] iommu/tegra-smmu: Make tegra_smmu_probe_device() to handle all IOMMU phandles
On Fri, Mar 12, 2021 at 06:54:39PM +0300, Dmitry Osipenko wrote:
> The tegra_smmu_probe_device() handles only the first IOMMU device-tree
> phandle, skipping the rest. Devices like 3D module on Tegra30 have
> multiple IOMMU phandles, one for each h/w block, and thus, only one
> IOMMU phandle is added to fwspec for the 3D module, breaking GPU.
> Previously this problem was masked by tegra_smmu_attach_dev() which
> didn't use the fwspec, but parsed the DT by itself. The previous commit
> to tegra-smmu driver partially reverted changes that caused problems for
> T124 and now we have tegra_smmu_attach_dev() that uses the fwspec and
> the old-buggy variant of tegra_smmu_probe_device() which skips secondary
> IOMMUs.
>
> Make tegra_smmu_probe_device() not to skip the secondary IOMMUs. This
> fixes a partially attached IOMMU of the 3D module on Tegra30 and now GPU
> works properly once again.
>
> Fixes: 765a9d1d02b2 ("iommu/tegra-smmu: Fix mc errors on tegra124-nyan")
> Signed-off-by: Dmitry Osipenko
Tested-by: Nicolin Chen
Re: [PATCH 4/4] clk: bcm: Add BCM63268 timer clock and reset driver
Quoting Alvaro Fernandez Rojas (2021-02-25 11:42:01)
> diff --git a/drivers/clk/bcm/clk-bcm63268-timer.c
> b/drivers/clk/bcm/clk-bcm63268-timer.c
> new file mode 100644
> index ..5609c4ddb50c
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-bcm63268-timer.c
> @@ -0,0 +1,232 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * BCM63268 Timer Clock and Reset Controller Driver
> + *
> + * Copyright (C) 2021 Álvaro Fernández Rojas
> + */
> +
> +#include
> +#include
> +#include
Is this used?
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define BCM63268_TIMER_RESET_SLEEP_MIN_US 1
> +#define BCM63268_TIMER_RESET_SLEEP_MAX_US 2
> +
> +struct bcm63268_tclkrst_hw {
> + void __iomem *regs;
> + spinlock_t lock;
> +
> + struct reset_controller_dev rcdev;
> + struct clk_hw_onecell_data data;
> +};
> +
> +struct bcm63268_tclk_table_entry {
> + const char * const name;
> + u8 bit;
> + unsigned long flags;
This isn't used. Drop it?
> +};
> +
> +static const struct bcm63268_tclk_table_entry bcm63268_timer_clocks[] = {
> + {
> + .name = "ephy1",
> + .bit = BCM63268_TCLK_EPHY1,
> + }, {
> + .name = "ephy2",
> + .bit = BCM63268_TCLK_EPHY2,
> + }, {
> + .name = "ephy3",
> + .bit = BCM63268_TCLK_EPHY3,
> + }, {
> + .name = "gphy1",
> + .bit = BCM63268_TCLK_GPHY1,
> + }, {
> + .name = "dsl",
> + .bit = BCM63268_TCLK_DSL,
> + }, {
> + .name = "wakeon_ephy",
> + .bit = BCM63268_TCLK_WAKEON_EPHY,
> + }, {
> + .name = "wakeon_dsl",
> + .bit = BCM63268_TCLK_WAKEON_DSL,
> + }, {
> + .name = "fap1_pll",
> + .bit = BCM63268_TCLK_FAP1,
> + }, {
> + .name = "fap2_pll",
> + .bit = BCM63268_TCLK_FAP2,
> + }, {
> + .name = "uto_50",
> + .bit = BCM63268_TCLK_UTO_50,
> + }, {
> + .name = "uto_extin",
> + .bit = BCM63268_TCLK_UTO_EXTIN,
> + }, {
> + .name = "usb_ref",
> + .bit = BCM63268_TCLK_USB_REF,
> + }, {
> + /* sentinel */
> + }
> +};
> +
> +static inline struct bcm63268_tclkrst_hw *
> +to_bcm63268_timer_reset(struct reset_controller_dev *rcdev)
> +{
> + return container_of(rcdev, struct bcm63268_tclkrst_hw, rcdev);
> +}
> +
> +static int bcm63268_timer_reset_update(struct reset_controller_dev *rcdev,
> + unsigned long id, bool assert)
> +{
> + struct bcm63268_tclkrst_hw *reset = to_bcm63268_timer_reset(rcdev);
> + unsigned long flags;
> + uint32_t val;
> +
> + spin_lock_irqsave(>lock, flags);
> + val = __raw_readl(reset->regs);
> + if (assert)
> + val &= ~BIT(id);
> + else
> + val |= BIT(id);
> + __raw_writel(val, reset->regs);
> + spin_unlock_irqrestore(>lock, flags);
> +
> + return 0;
> +}
> +
> +static int bcm63268_timer_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + return bcm63268_timer_reset_update(rcdev, id, true);
> +}
> +
> +static int bcm63268_timer_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + return bcm63268_timer_reset_update(rcdev, id, false);
> +}
> +
> +static int bcm63268_timer_reset_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + bcm63268_timer_reset_update(rcdev, id, true);
> + usleep_range(BCM63268_TIMER_RESET_SLEEP_MIN_US,
> +BCM63268_TIMER_RESET_SLEEP_MAX_US);
> +
> + bcm63268_timer_reset_update(rcdev, id, false);
> + /*
> +* Ensure component is taken out reset state by sleeping also after
> +* deasserting the reset. Otherwise, the component may not be ready
> +* for operation.
> +*/
> + usleep_range(BCM63268_TIMER_RESET_SLEEP_MIN_US,
> +BCM63268_TIMER_RESET_SLEEP_MAX_US);
> +
> + return 0;
> +}
> +
> +static int bcm63268_timer_reset_status(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct bcm63268_tclkrst_hw *reset = to_bcm63268_timer_reset(rcdev);
> +
> + return !(__raw_readl(reset->regs) & BIT(id));
> +}
> +
> +static struct reset_control_ops bcm63268_timer_reset_ops = {
> + .assert = bcm63268_timer_reset_assert,
> + .deassert = bcm63268_timer_reset_deassert,
> + .reset = bcm63268_timer_reset_reset,
> + .status = bcm63268_timer_reset_status,
> +};
> +
> +static int bcm63268_tclk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + const
Re: [PATCH] arm64: dts: qcom: sc7180: Drop duplicate dp_hot_plug_det node in trogdor
Quoting Douglas Anderson (2021-03-11 13:12:41)
> From: Stephen Boyd
>
> This moved from being trogdor specific to being part of the general
> sc7180.dtsi SoC file in commit 681a607ad21a ("arm64: dts: qcom:
> sc7180: Add DisplayPort HPD pin dt node"). Then we dropped the pinconf
> from the general sc7180.dtsi file in commit 8d079bf20410 ("arm64: dts:
> qcom: sc7180: Drop pinconf on dp_hot_plug_det") and added it back to
> the trogdor dts file in commit f772081f4883 ("arm64: dts: qcom:
> sc7180: Add "dp_hot_plug_det" pinconf for trogdor").
>
> As part of this we managed to forget to drop the old copy in the
> trogdor dts. Let's do it now.
>
> Signed-off-by: Stephen Boyd
> [dianders: updated desc]
> Signed-off-by: Douglas Anderson
> ---
Thanks for the catch!
Re: [PATCH] staging: andriod: ashmem: Declared file operation with const keyword
On Sat, Mar 13, 2021 at 10:59:43PM +0530, B K Karthik wrote: > On Sat, Mar 13, 2021 at 10:57 PM namratajanawade > wrote: > > > > Warning found by checkpatch.pl script. > > That doesn't tell what you did or why you did it. Please write an > appropriate commit description and resend the patch. > > karthik This patch will not even build, it has been sent several times before... https://lore.kernel.org/r/2020101605.1947-1-kirank.su...@gmail.com/ https://lore.kernel.org/r/20200328151523.17516-1-sandeshkenjanaas...@gmail.com/ https://lore.kernel.org/r/20201128121627.GA27317@worker-node1/ https://lore.kernel.org/r/20201227112645.256943-1-senguptaangshuma...@gmail.com/ https://lore.kernel.org/r/20201228051301.14983-1-jovin...@gmail.com/ https://lore.kernel.org/r/20210214023136.8916-1-thaiscamac...@gmail.com/ https://lore.kernel.org/r/20210219101338.2670-1-amritkher...@gmail.com/ https://lore.kernel.org/r/20210306063817.674041-1-nabil.ibn.mah...@gmail.com/ I once considered adding a comment above it saying that it should not be marked const but it is a good benchmark for seeing if people compile their patches before sending them out. Cheers, Nathan
Re: [PATCH 2/2] PCI: Revoke mappings like devmem
On Sat, Mar 13, 2021 at 10:57 PM Bjorn Helgaas wrote:
>
> [+cc Krzysztof, Pali, Oliver]
>
> On Thu, Feb 04, 2021 at 05:58:31PM +0100, Daniel Vetter wrote:
> > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> > the default for all driver uses.
> >
> > Except there's two more ways to access PCI BARs: sysfs and proc mmap
> > support. Let's plug that hole.
>
> IIUC, the idea is that if a driver calls request_mem_region() on a PCI
> BAR, we prevent access to the BAR via sysfs. I guess I'm OK with that
> if it's a real security improvement or something.
Yup.
> But the downside of this implementation is that it depends on
> iomem_get_mapping(), which doesn't work until after fs_initcalls,
> which means the sysfs files cannot be static attributes of devices
> added before that. PCI devices are typically enumerated in
> subsys_initcall.
>
> Krzysztof is converting PCI sysfs files (config, rom, reset, vpd, etc)
> to static attributes. This is a major improvement that could get rid
> of pci_create_sysfs_dev_files(), the late_initcall pci_sysfs_init(),
> and the "sysfs_initialized" hack. This would fix a race reported by
> Pali [1] (thanks to Oliver for the idea [2]).
>
> EXCEPT that this revoke change means the "resource%d", "legacy_io",
> and "legacy_mem" files cannot be static attributes because of
> iomem_get_mapping().
>
> Any ideas on how to deal with this? Having to keep the
> pci_sysfs_init() initcall just for these few files seems like the tail
> wagging the dog.
It's a bit "pick your ugly". Either we have the late init call (not
pretty), or the sysfs side needs a callback to fish out the
address_space for the mmap at open() time, which didn't stir up much
enthusiams with Greg because we need a new callback just for these
mmio files. Either approach works.
-Daniel
> [1] https://lore.kernel.org/r/20200716110423.xtfyb3n6tn5ixedh@pali
> [2]
> https://lore.kernel.org/r/caosf1chss03dbsdo4pmttmp0tceu5kscn704zewlkgxqzbf...@mail.gmail.com
>
> > For revoke_devmem() to work we need to link our vma into the same
> > address_space, with consistent vma->vm_pgoff. ->pgoff is already
> > adjusted, because that's how (io_)remap_pfn_range works, but for the
> > mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
> > to adjust this at at ->open time:
> >
> > - for sysfs this is easy, now that binary attributes support this. We
> > just set bin_attr->mapping when mmap is supported
> > - for procfs it's a bit more tricky, since procfs pci access has only
> > one file per device, and access to a specific resources first needs
> > to be set up with some ioctl calls. But mmap is only supported for
> > the same resources as sysfs exposes with mmap support, and otherwise
> > rejected, so we can set the mapping unconditionally at open time
> > without harm.
> >
> > A special consideration is for arch_can_pci_mmap_io() - we need to
> > make sure that the ->f_mapping doesn't alias between ioport and iomem
> > space. There's only 2 ways in-tree to support mmap of ioports: generic
> > pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
> > architecture hand-rolling. Both approach support ioport mmap through a
> > special pfn range and not through magic pte attributes. Aliasing is
> > therefore not a problem.
> >
> > The only difference in access checks left is that sysfs PCI mmap does
> > not check for CAP_RAWIO. I'm not really sure whether that should be
> > added or not.
> >
> > Acked-by: Bjorn Helgaas
> > Reviewed-by: Dan Williams
> > Signed-off-by: Daniel Vetter
> > Cc: Stephen Rothwell
> > Cc: Jason Gunthorpe
> > Cc: Kees Cook
> > Cc: Dan Williams
> > Cc: Andrew Morton
> > Cc: John Hubbard
> > Cc: Jérôme Glisse
> > Cc: Jan Kara
> > Cc: Dan Williams
> > Cc: Greg Kroah-Hartman
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Bjorn Helgaas
> > Cc: linux-...@vger.kernel.org
> > ---
> > drivers/pci/pci-sysfs.c | 4
> > drivers/pci/proc.c | 1 +
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > index 0c45b4f7b214..f8afd54ca3e1 100644
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/drivers/pci/pci-sysfs.c
> > @@ -942,6 +942,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> > b->legacy_io->read = pci_read_legacy_io;
> > b->legacy_io->write = pci_write_legacy_io;
> > b->legacy_io->mmap = pci_mmap_legacy_io;
> > + b->legacy_io->mapping = iomem_get_mapping();
> > pci_adjust_legacy_attr(b, pci_mmap_io);
> > error = device_create_bin_file(>dev, b->legacy_io);
> > if (error)
> > @@ -954,6 +955,7 @@ void pci_create_legacy_files(struct pci_bus *b)
> > b->legacy_mem->size = 1024*1024;
> >
Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout
On Sat, Mar 13, 2021 at 9:23 AM Alex Ghiti wrote: > > Yes I considered it...when you re-proposed it :) I'm not opposed to your > solution in the vmalloc region but I can't find any advantage over the > current solution, are there ? That would harmonize with Linus's work, > but then we'd be quite different from x86 address space. > > And by the way, thanks for having suggested the current solution in a > previous conversation :) Ah, I really need to keep track better of what I already commented on... Arnd
Re: [PATCH 5.4 00/24] 5.4.105-rc1 review
Hi! > > So I guess we are good, until we are not. It concerns me however that > > this (latent at the time) issue was reported at Wed, 10 Mar 2021 > > 20:19:48 -0800 which is well before the deadline of Fri, 12 Mar 2021 > > 13:23:09 +, and yet, the v5.4.105 was announced on Thu, 11 Mar 2021 > > 05:33:31 -0800 (PST) and it went through with that patch nonetheless. > > It's a judgement call on my side as to when to do the release, based on > the testing that has happened, any reports, and my knowledge of what is > in the patches themselves. For this patchset, all of the expected > testers came back with no problems, except for your report. > > And if your report turned out to be real (the fact that it was a > backport of an "old" patch made it much less likely to be real), I can > always instantly revert it and push out a new release quickly for the > tiny subset of those that have problems with this. > > So I took a guess based on all of this and decided it was more important > to get the release out early, so that it can start to make its way to > the huge majority of systems that did report testing worked fine, than > to delay it to wait for your single system report. Because again, if > this turned out to be a real issue, a quick release for any affected > systems would have been trivial to create. You are setting yourself (and testers) a deadline... and then you ignore it. People are not only testing the release, they are also reviewing the patches, and having at least two days for that is useful. You clearly disagree, but in any case you should not mention deadline in the initial if you don't intend to keep them. Thats confusing, and clearly it is not only confusing to me. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany signature.asc Description: Digital signature
Re: [PATCH net] net: ipa: terminate message handler arrays
Hello: This patch was applied to netdev/net.git (refs/heads/master): On Fri, 12 Mar 2021 09:12:48 -0600 you wrote: > When a QMI handle is initialized, an array of message handler > structures is provided, defining how any received message should > be handled based on its type and message ID. The QMI core code > traverses this array when a message arrives and calls the function > associated with the (type, msg_id) found in the array. > > The array is supposed to be terminated with an empty (all zero) > entry though. Without it, an unsupported message will cause > the QMI core code to go past the end of the array. > > [...] Here is the summary with links: - [net] net: ipa: terminate message handler arrays https://git.kernel.org/netdev/net/c/3a9ef3e11c5d You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH 1/2] clk: Add clk_get_first_to_set_rate
Quoting Paul Cercueil (2021-03-07 09:07:41) > The purpose of this function is to be used along with the notifier > mechanism. > > When a parent clock can see its rate externally changed at any moment, > and a driver needs a specific clock rate to function, it can register a > notifier on the parent clock, and call clk_set_rate() on the base clock > to adjust its frequency according to the new parent clock. Can the driver use the rate locking mechanism to get a certain rate instead of registering for notifiers and trying to react to changes? > > This works fine, until the base clock has the CLK_SET_RATE_PARENT flag > set. In that case, calling clk_set_rate() on the base clock will call > clk_set_rate() on the parent clock, which will trigger the notifier > again, and we're in a loop. > > For that reason, we need to register the notifier on the parent clock of > the first ancestor of the base clock that will effectively modify its > rate when clk_set_rate() is called, which we can now obtain with > clk_get_first_to_set_rate(). > > Signed-off-by: Paul Cercueil
Re: [PATCH] clk: Call clk_core_enable_lock variant when lock is needed
Quoting Abel Vesa (2021-03-07 10:52:08) > Instead of locking explicitly every time, call the clk_core_enable_lock > variant. > > Signed-off-by: Abel Vesa This is done by https://lore.kernel.org/r/20210305003334.575831-1-li...@rasmusvillemoes.dk
Re: [PATCH v3 4/4] clk: rockchip: add clock controller for rk3568
Quoting Elaine Zhang (2021-02-28 22:47:49)
> Add the clock tree definition for the new rk3568 SoC.
>
> Signed-off-by: Elaine Zhang
> ---
> drivers/clk/rockchip/Kconfig |7 +
> drivers/clk/rockchip/Makefile |1 +
> drivers/clk/rockchip/clk-rk3568.c | 1726 +
> drivers/clk/rockchip/clk.h| 30 +-
> 4 files changed, 1763 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/rockchip/clk-rk3568.c
>
> diff --git a/drivers/clk/rockchip/Kconfig b/drivers/clk/rockchip/Kconfig
> index effd05032e85..2e31901f4213 100644
> --- a/drivers/clk/rockchip/Kconfig
> +++ b/drivers/clk/rockchip/Kconfig
> @@ -85,4 +85,11 @@ config CLK_RK3399
> default y
> help
> Build the driver for RK3399 Clock Driver.
> +
> +config CLK_RK3568
> + tristate "Rockchip RK3568 clock controller support"
> + depends on (ARM64 || COMPILE_TEST)
Drop parenthesis please.
> + default y
> + help
> + Build the driver for RK3568 Clock Driver.
> endif
> diff --git a/drivers/clk/rockchip/clk-rk3568.c
> b/drivers/clk/rockchip/clk-rk3568.c
> new file mode 100644
> index ..60913aa91897
> --- /dev/null
> +++ b/drivers/clk/rockchip/clk-rk3568.c
> @@ -0,0 +1,1726 @@
[...]
> +};
> +builtin_platform_driver_probe(clk_rk3568_driver, clk_rk3568_probe);
> +
> +MODULE_DESCRIPTION("Rockchip RK3568 Clock Driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:clk-rk3568");
I think module alias does nothing?
Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax
On Sat, Mar 13, 2021 at 11:24:00AM -0500, Neal Gompa wrote: > On Sat, Mar 13, 2021 at 8:09 AM Adam Borowski wrote: > > > > On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote: > > > On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote: > > > > DAX on btrfs has been attempted[1]. Of course, we could not > > > > > > But why? A completeness fetish? I don't understand why you decided > > > to do this work. > > > > * xfs can shapshot only single files, btrfs entire subvolumes > > * btrfs-send|receive > > * enumeration of changed parts of a file > > XFS cannot do snapshots since it lacks metadata COW. XFS reflinking is > primarily for space efficiency. A reflink is a single-file snapshot. My work team really wants this very patchset -- reflinks on DAX allow backups and/or checkpointing, without stopping the world (there's a single file, "pool", here). Besides, you can still get poor-man's whole-subvolume(/directory) snapshots by manually walking the tree and reflinking everything. That's not atomic -- but rsync isn't atomic either. That's enough for eg. dnf/dpkg purposes. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ NADIE anticipa la inquisición de españa! ⠈⠳⣄
Re: [PATCH] perf-stat: introduce bperf, share hardware PMCs with BPF
On Fri, Mar 12, 2021 at 04:09:53PM +, Song Liu wrote: > > > > On Mar 12, 2021, at 7:45 AM, Song Liu wrote: > > > > > > > >> On Mar 12, 2021, at 4:12 AM, Jiri Olsa wrote: > >> > >> On Thu, Mar 11, 2021 at 06:02:57PM -0800, Song Liu wrote: > >>> perf uses performance monitoring counters (PMCs) to monitor system > >>> performance. The PMCs are limited hardware resources. For example, > >>> Intel CPUs have 3x fixed PMCs and 4x programmable PMCs per cpu. > >>> > >>> Modern data center systems use these PMCs in many different ways: > >>> system level monitoring, (maybe nested) container level monitoring, per > >>> process monitoring, profiling (in sample mode), etc. In some cases, > >>> there are more active perf_events than available hardware PMCs. To allow > >>> all perf_events to have a chance to run, it is necessary to do expensive > >>> time multiplexing of events. > >>> > >>> On the other hand, many monitoring tools count the common metrics (cycles, > >>> instructions). It is a waste to have multiple tools create multiple > >>> perf_events of "cycles" and occupy multiple PMCs. > >>> > >>> bperf tries to reduce such wastes by allowing multiple perf_events of > >>> "cycles" or "instructions" (at different scopes) to share PMUs. Instead > >>> of having each perf-stat session to read its own perf_events, bperf uses > >>> BPF programs to read the perf_events and aggregate readings to BPF maps. > >>> Then, the perf-stat session(s) reads the values from these BPF maps. > >>> > >>> Please refer to the comment before the definition of bperf_ops for the > >>> description of bperf architecture. > >>> > >>> bperf is off by default. To enable it, pass --use-bpf option to perf-stat. > >>> bperf uses a BPF hashmap to share information about BPF programs and maps > >>> used by bperf. This map is pinned to bpffs. The default address is > >>> /sys/fs/bpf/bperf_attr_map. The user could change the address with option > >>> --attr-map. > >> > >> nice, I recall the presentation about that and was wondering > >> when this will come up ;-) > > > > The progress is slower than I expected. But I finished some dependencies of > > this in the last year: > > > > 1. BPF_PROG_TEST_RUN for raw_tp event; > > 2. perf-stat -b, which introduced skeleton and bpf_counter; > > 3. BPF task local storage, I didn't use it in this version, but it could, > > help optimize bperf in the future. > > > >> > >>> > >>> --- > >>> Known limitations: > >>> 1. Do not support per cgroup events; > >>> 2. Do not support monitoring of BPF program (perf-stat -b); > >>> 3. Do not support event groups. > >>> > >>> The following commands have been tested: > >>> > >>> perf stat --use-bpf -e cycles -a > >>> perf stat --use-bpf -e cycles -C 1,3,4 > >>> perf stat --use-bpf -e cycles -p 123 > >>> perf stat --use-bpf -e cycles -t 100,101 > >> > >> I assume the output is same as standard perf? > > Btw, please give it a try. :) > > It worked pretty well in my tests. If it doesn't work for some combination > of options, please let me know. heya, can't compile CLANG /home/jolsa/linux-perf/tools/perf/util/bpf_skel/.tmp/bperf_follower.bpf.o util/bpf_skel/bperf_follower.bpf.c:8:10: fatal error: 'bperf_u.h' file not found #include "bperf_u.h" ^~~ jirka
