drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable 'at91_adc_dt_ids'
Hi Alexandru,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0fa8ee0d9ab95c9350b8b84574824d9a384a9f7d
commit: 4027860dcc4cd0c45c36bae21e45bee5a17f2f0f iio: Kconfig: at91_adc: add
COMPILE_TEST dependency to driver
date: 5 months ago
config: x86_64-randconfig-a011-20201118 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
b2613fb2f0f53691dd0211895afbb9413457fca7)
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=4027860dcc4cd0c45c36bae21e45bee5a17f2f0f
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 4027860dcc4cd0c45c36bae21e45bee5a17f2f0f
# 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 warnings (new ones prefixed by >>):
>> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable
>> 'at91_adc_dt_ids' [-Wunused-const-variable]
static const struct of_device_id at91_adc_dt_ids[] = {
^
1 warning generated.
vim +/at91_adc_dt_ids +1439 drivers/iio/adc/at91_adc.c
e1811f97ba985fe Josh Wu 2013-08-27 1438
e364185f3ed2ecc Maxime Ripard 2012-05-11 @1439 static const struct
of_device_id at91_adc_dt_ids[] = {
e1811f97ba985fe Josh Wu 2013-08-27 1440 { .compatible =
"atmel,at91sam9260-adc", .data = _caps },
65b1fdbac9e39d9 Alexandre Belloni 2014-04-15 1441 { .compatible =
"atmel,at91sam9rl-adc", .data = _caps },
e1811f97ba985fe Josh Wu 2013-08-27 1442 { .compatible =
"atmel,at91sam9g45-adc", .data = _caps },
e1811f97ba985fe Josh Wu 2013-08-27 1443 { .compatible =
"atmel,at91sam9x5-adc", .data = _caps },
e364185f3ed2ecc Maxime Ripard 2012-05-11 1444 {},
e364185f3ed2ecc Maxime Ripard 2012-05-11 1445 };
e364185f3ed2ecc Maxime Ripard 2012-05-11 1446 MODULE_DEVICE_TABLE(of,
at91_adc_dt_ids);
467a44b0372d826 Alexandre Belloni 2014-05-03 1447
:: The code at line 1439 was first introduced by commit
:: e364185f3ed2ecc0a4dbfe2507f20fd5db76c966 IIO: AT91: Add DT support to
at91_adc driver
:: TO: Maxime Ripard
:: CC: Greg Kroah-Hartman
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: linux-next: build failure after merge of the gpio tree
On Wed, Nov 18, 2020 at 4:30 AM Stephen Rothwell wrote:
> drivers/gpio/gpio-xilinx.c: In function 'xgpio_remove':
> drivers/gpio/gpio-xilinx.c:275:2: error: implicit declaration of function
> 'pm_runtime_disable' [-Werror=implicit-function-declaration]
> 275 | pm_runtime_disable(>dev);
> | ^~
>
> Caused by commit
>
> fbbeb6c0a1d0 ("gpio: gpio-xilinx: Add remove function")
Ooops my fault for merging patches out-of-order, I'll go in
and fix it up manually by removing the pm call from remove().
Yours,
Linus Walleij
Corporate and Personal Loan *
Hello linux-kernel@vger.kernel.org We are Base Investment Company offering Corporate and Personal Loan at 3% Interest Rate for a duration of 10Years. We also pay 1% commission to brokers, who introduce project owners for finance or other opportunities. Please get back to me if you are interested for more details. Yours faithfully, Hashim Murrah
Re: linux-next: manual merge of the gpio tree with the kspp-gustavo tree
On Wed, Nov 18, 2020 at 4:24 AM Stephen Rothwell wrote:
> b8e0b635e6e6 ("gpio: Fix fall-through warnings for Clang")
>
> from the kspp-gustavo tree and commit:
Interesting I guess this is a clang tree?
Please rebase on the GPIO tree and send me + Andy this patch so we
can integrate it properly.
Yours,
Linus Walleij
Re: [PATCH 1/3] clk: fix redefinition of clk_prepare on MIPS with HAVE_LEGACY_CLK
On Tue, Nov 17, 2020 at 11:41:57PM -0800, Stephen Boyd wrote: > Quoting Krzysztof Kozlowski (2020-11-15 09:09:48) > > COMMON_CLK even though is a user-selectable symbol, is still selected by > > multiple other config options. COMMON_CLK should not be used when > > legacy clocks are provided by architecture, so it correctly depends on > > !HAVE_LEGACY_CLK. > > > > However it is possible to create a config which selects both COMMON_CLK > > (by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (by SOC_RT305X) which leads to > > Why is SND_SUN8I_CODEC selecting COMMON_CLK? Or really, why is > SOC_RT305X selecting HAVE_LEGACY_CLK? The SND_SUN8I_CODEC I fixed in following patch (I sent separately v2 of it). The SOC_RT305X select HAVE_LEGACY_CLK? because it is an old, Ralink platform, not converted to Common clock frm. Few clock operations are defined in: arch/mips/ralink/clk.c Best regards, Krzysztof
Re: [PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
On Wed, Nov 18, 2020 at 3:40 AM John Stultz wrote: > On Fri, Nov 13, 2020 at 12:39 PM Daniel Vetter wrote: > > On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote: > > > On Thu, Nov 12, 2020 at 1:32 AM Daniel Vetter wrote: > > > > On Thu, Nov 12, 2020 at 11:09:04AM +0530, Sumit Semwal wrote: > > > > > On Tue, 10 Nov 2020 at 09:19, John Stultz > > > > > wrote: > > > > > > > > > > > > Hey All, > > > > > > So just wanted to send my last revision of my patch series > > > > > > of performance optimizations to the dma-buf system heap. > > > > > > > > > > Thanks very much for your patches - I think the first 5 patches look > > > > > good to me. > > > > > > > > > > I know there was a bit of discussion over adding a new system-uncached > > > > > heap v/s using a flag to identify that; I think I prefer the separate > > > > > heap idea, but lets ask one last time if any one else has any real > > > > > objections to it. > > > > > > > > > > Daniel, Christian: any comments from your side on this? > > > > > > > > I do wonder a bit where the userspace stack for this all is, since > > > > tuning > > > > allocators without a full stack is fairly pointless. dma-buf heaps is a > > > > bit in a limbo situation here it feels like. > > > > > > As mentioned in the system-uncached patch: > > > Pending opensource users of this code include: > > > * AOSP HiKey960 gralloc: > > > - > > > https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519 > > > - Visibly improves performance over the system heap > > > * AOSP Codec2 (possibly, needs more review): > > > - > > > https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325 > > > > > > Additionally both the HiKey, HiKey960 grallocs and Codec2 are already > > > able to use the current dmabuf heaps instead of ION. > > > > > > So I'm not sure what you mean by limbo, other than it being in a > > > transition state where the interface is upstream and we're working on > > > moving vendors to it from ION (which is staged to be dropped in 5.11). > > > Part of that work is making sure we don't regress the performance > > > expectations. > > > > The mesa thing below, since if we test this with some downstream kernel > > drivers or at least non-mesa userspace I'm somewhat worried we're just > > creating a nice split world between the android gfx world and the > > mesa/linux desktop gfx world. > > > > But then that's kinda how android rolls, so *shrug* > > > > > > Plus I'm vary of anything related to leaking this kind of stuff beyond > > > > the > > > > dma-api because dma api maintainers don't like us doing that. But > > > > personally no concern on that front really, gpus need this. It's just > > > > that > > > > we do need solid justification I think if we land this. Hence back to > > > > first point. > > > > > > > > Ideally first point comes in the form of benchmarking on android > > > > together > > > > with a mesa driver (or mesa + some v4l driver or whatever it takes to > > > > actually show the benefits, I have no idea). > > > > > > Tying it with mesa is a little tough as the grallocs for mesa devices > > > usually use gbm (gralloc.gbm or gralloc.minigbm). Swapping the > > > allocation path for dmabuf heaps there gets a little complex as last I > > > tried that (when trying to get HiKey working with Lima graphics, as > > > gbm wouldn't allocate the contiguous buffers required by the display), > > > I ran into issues with the drm_hwcomposer and mesa expecting the gbm > > > private handle metadata in the buffer when it was passed in. > > > > > > But I might take a look at it again. I got a bit lost digging through > > > the mesa gbm allocation paths last time. > > > > > > I'll also try to see if I can find a benchmark for the codec2 code > > > (using dmabuf heaps with and without the uncached heap) on on db845c > > > (w/ mesa), as that is already working and I suspect that might be > > > close to what you're looking for. > > > > tbh I think trying to push for this long term is the best we can hope for. > > > > Media is also a lot more *meh* since it's deeply fragmented and a lot less > > of it upstream than on the gles/display side. > > > > I think confirming that this at least doesn't horrible blow up on a > > gralloc/gbm+mesa stack would be useful I think. > > Sorry, I'm still a little foggy on precisely what you're suggesting here. > > The patch stack I have has already been used with db845c (mesa + > gbm_grallloc), with the codec2 (sw decoders) using dmabuf heaps. > So no blowing up there. And I'm working with Hridya to find a > benchmark for codec2 so we can try to show the performance delta. > > However, if you're wanting a dma-buf gralloc implementation with mesa, > that may be a little tougher to do, but I guess I can give it a go. > > Hopefully this will address concerns about the system-uncached heap > patch (the last two patches in this series)? > > In the meantime I hope we
Re: Re: [PATCH] Changes since v1 - Change subject form "ALSA" to "USB:"- Adjust to approoriate line
On Wed, Nov 18, 2020 at 03:41:08PM +0800, 彭浩 wrote: > 此电子邮件消息仅供预期收件人使用，其中可能包含保密或特权使用信息。如果您不是预 > 期收件人，请勿使用、传播、分发或复制此电子邮件或信赖此邮件采取任何行动。如果您 > 误收了此邮件，请立即回复邮件通知统信软件技术有限公司发件人，并删除误收电子邮件 > 及其相关附件。感谢配合！ > > This email message is intended only for the use of the individual or entity > who > /which is the intended recipient and may contain information that is > privileged > or confidential. If you are not the intended recipient, you are hereby > notified > that any use, dissemination, distribution or copying of, or taking any action > in reliance on, this e-mail is strictly prohibited. If you have received this > email in error, please notify UnionTech Software Technology immediately by > replying to this e-mail and immediately delete and discard all copies of the > e-mail and the attachment thereto (if any). Thank you. Message is now deleted.
[PATCH v2] ARM: dts: keystone-k2g-evm: add HDMI and analog audio data
The board is using McASP2 for both analog (tlv320aic3106) and
HDMI (SiI9022) audio.
12.288MHz oscillator provides the MCLK for both aic3106 and SiI9022.
Signed-off-by: Peter Ujfalusi
---
Hi,
Changes since v1:
- Rename the sii9022_mclk ficed clock to aud_mclk (as it is named in the schema)
and use it within the sound card dai nodes for the codecs.
Regards,
Peter
arch/arm/boot/dts/keystone-k2g-evm.dts | 112 +
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 8b3d64c913d8..14e26a4fd62a 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -46,6 +46,14 @@ vcc1v8_ldo1_reg: fixedregulator-vcc1v8-ldo1 {
regulator-always-on;
};
+ vcc1v8_ldo2_reg: fixedregulator-vcc1v8-ldo2 {
+ compatible = "regulator-fixed";
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
hdmi: connector {
compatible = "hdmi-connector";
label = "hdmi";
@@ -58,6 +66,57 @@ hdmi_connector_in: endpoint {
};
};
};
+
+ aud_mclk: aud_mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12288000>;
+ };
+
+ sound0: sound@0 {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "K2G-EVM";
+ simple-audio-card,widgets =
+ "Headphone", "Headphone Jack",
+ "Line", "Line In";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "LINE1L", "Line In",
+ "LINE1R", "Line In";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+ bitclock-master = <_0_master>;
+ frame-master = <_0_master>;
+ sound0_0_master: cpu {
+ sound-dai = <>;
+ clocks = <_clks 0x6 1>;
+ system-clock-direction-out;
+ };
+
+ codec {
+ sound-dai = <>;
+ clocks = <_mclk>;
+ };
+ };
+
+ simple-audio-card,dai-link@1 {
+ format = "i2s";
+ bitclock-master = <_1_master>;
+ frame-master = <_1_master>;
+ sound0_1_master: cpu {
+ sound-dai = <>;
+ clocks = <_clks 0x6 1>;
+ system-clock-direction-out;
+ };
+
+ codec {
+ sound-dai = <>;
+ clocks = <_mclk>;
+ };
+ };
+ };
};
_pinctrl {
@@ -214,6 +273,15 @@ K2G_CORE_IOPAD(0x10e4) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* dssde.dssd
K2G_CORE_IOPAD(0x10e8) (BUFFER_CLASS_B | PULL_DISABLE |
MUX_MODE0) /* dssfid.dssfid */
>;
};
+
+ mcasp2_pins: pinmux_mcasp2_pins {
+ pinctrl-single,pins = <
+ K2G_CORE_IOPAD(0x1234) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo2.mcasp2_axr2 */
+ K2G_CORE_IOPAD(0x1238) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo3.mcasp2_axr3 */
+ K2G_CORE_IOPAD(0x1254) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo10.mcasp2_afsx */
+ K2G_CORE_IOPAD(0x125c) (BUFFER_CLASS_B | PIN_PULLDOWN |
MUX_MODE4) /* pr0_pru_gpo12.mcasp2_aclkx */
+ >;
+ };
};
{
@@ -423,6 +491,10 @@ sii9022: sii9022@3b {
compatible = "sil,sii9022";
reg = <0x3b>;
+ sil,i2s-data-lanes = < 0 >;
+ clocks = <_mclk>;
+ clock-names = "mclk";
+
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -444,6 +516,19 @@ sii9022_out: endpoint {
};
};
};
+
+ tlv320aic3106: tlv320aic3106@1b {
+ #sound-dai-cells = <0>;
+ compatible = "ti,tlv320aic3106";
+ reg = <0x1b>;
+ status = "okay";
+
+ /* Regulators */
+ AVDD-supply = <_dcin_reg>;
+ IOVDD-supply = <_dcin_reg>;
+ DRVDD-supply = <_dcin_reg>;
+
Re: [RFC][PATCH v2 00/21] x86/pti: Defer CR3 switch to C code
On 11/17/20 10:26 PM, Borislav Petkov wrote: On Tue, Nov 17, 2020 at 07:12:07PM +0100, Alexandre Chartre wrote: Some benchmarks are available, in particular from phoronix: What I was expecting was benchmarks *you* have run which show that perf penalty, not something one can find quickly on the internet and something one cannot always reproduce her-/himself. You do know that presenting convincing numbers with a patchset greatly improves its chances of getting it upstreamed, right? Well, it looks like I wrongfully assume that KPTI was a well known performance overhead since it was introduced (because it adds extra page-table switches), but you are right I should be presenting my own numbers. Thanks, alex.
Re: [PATCH 1/3] clk: fix redefinition of clk_prepare on MIPS with HAVE_LEGACY_CLK
Quoting Krzysztof Kozlowski (2020-11-15 09:09:48) > COMMON_CLK even though is a user-selectable symbol, is still selected by > multiple other config options. COMMON_CLK should not be used when > legacy clocks are provided by architecture, so it correctly depends on > !HAVE_LEGACY_CLK. > > However it is possible to create a config which selects both COMMON_CLK > (by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (by SOC_RT305X) which leads to Why is SND_SUN8I_CODEC selecting COMMON_CLK? Or really, why is SOC_RT305X selecting HAVE_LEGACY_CLK?
Re: [PATCH 0/5] context_tracking: Flatter archs not using exception_enter/exit() v3
On Tue, Nov 17, 2020 at 04:16:32PM +0100, Frederic Weisbecker wrote: > Frederic Weisbecker (5): > context_tracking: Introduce HAVE_CONTEXT_TRACKING_OFFSTACK > context_tracking: Don't implement exception_enter/exit() on > CONFIG_HAVE_CONTEXT_TRACKING_OFFSTACK > sched: Detect call to schedule from critical entry code > context_tracking: Only define schedule_user() on > !HAVE_CONTEXT_TRACKING_OFFSTACK archs > x86: Support HAVE_CONTEXT_TRACKING_OFFSTACK Thanks! Acked-by: Peter Zijlstra (Intel)
[PATCH 3/3] dt-bindings: panel: Add bindings for MRB2801
From: Mikhail Durnev
Add binding for Ronbo MRB2801 display module.
This binding is for display panels using an Ilitek ILI9341 controller in
parallel mode.
Signed-off-by: Mikhail Durnev
---
.../devicetree/bindings/display/ronbo,mrb2801.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
diff --git a/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
b/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
new file mode 100644
index 000..db1a861e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ronbo,mrb2801.txt
@@ -0,0 +1,42 @@
+MRB2801 display panel
+
+This binding is for display panels using an Ilitek ILI9341 controller in
+parallel mode.
+
+Required properties:
+- compatible: "ronbo,mrb2801"
+- dc-gpios:D/C pin
+- wr-gpios:W/R pin
+- db-gpios:8 or 16 DB pins
+- reset-gpios: Reset pin
+- wr-up-down-delays: Delays in ns for changing W/R from down to up and from
up to down
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+ mrb2801{
+ compatible = "ronbo,mrb2801";
+ db-gpios = < 17 0>, /* DB0 */
+ < 18 0>, /* DB1 */
+ < 27 0>, /* DB2 */
+ < 22 0>, /* DB3 */
+ < 23 0>, /* DB4 */
+ < 24 0>, /* DB5 */
+ < 25 0>, /* DB6 */
+ < 4 0>, /* DB7 */
+ < 14 0>, /* DB8 */
+ < 15 0>, /* DB9 */
+ < 5 0>, /* DB10 */
+ < 6 0>, /* DB11 */
+ < 13 0>, /* DB12 */
+ < 19 0>, /* DB13 */
+ < 26 0>, /* DB14 */
+ < 12 0>; /* DB15 */
+ dc-gpios = < 16 0>; /* D/C */
+ wr-gpios = < 20 0>; /* W/R */
+ wr-up-down-delays = <10 51>;
+ reset-gpios = < 21 0>; /* RST */
+ backlight = <>;
+ };
--
2.7.4
Re: [PATCH] ARM: dts: keystone-k2g-evm: add HDMI and analog audio data
Hi,
On 17/11/2020 12.17, Peter Ujfalusi wrote:
> The board is using McASP2 for both analog (tlv320aic3106) and
> HDMI (SiI9022) audio.
>
> Signed-off-by: Peter Ujfalusi
> ---
> arch/arm/boot/dts/keystone-k2g-evm.dts | 112 +
> 1 file changed, 112 insertions(+)
>
> diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts
> b/arch/arm/boot/dts/keystone-k2g-evm.dts
> index 8b3d64c913d8..4d7e3514a3a7 100644
> --- a/arch/arm/boot/dts/keystone-k2g-evm.dts
> +++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
> @@ -46,6 +46,14 @@ vcc1v8_ldo1_reg: fixedregulator-vcc1v8-ldo1 {
> regulator-always-on;
> };
>
> + vcc1v8_ldo2_reg: fixedregulator-vcc1v8-ldo2 {
> + compatible = "regulator-fixed";
> + regulator-name = "ldo2";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + };
> +
> hdmi: connector {
> compatible = "hdmi-connector";
> label = "hdmi";
> @@ -58,6 +66,57 @@ hdmi_connector_in: endpoint {
> };
> };
> };
> +
> + sound0: sound@0 {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "K2G-EVM";
> + simple-audio-card,widgets =
> + "Headphone", "Headphone Jack",
> + "Line", "Line In";
> + simple-audio-card,routing =
> + "Headphone Jack", "HPLOUT",
> + "Headphone Jack", "HPROUT",
> + "LINE1L", "Line In",
> + "LINE1R", "Line In";
> +
> + simple-audio-card,dai-link@0 {
> + format = "i2s";
> + bitclock-master = <_0_master>;
> + frame-master = <_0_master>;
> + sound0_0_master: cpu {
> + sound-dai = <>;
> + clocks = <_clks 0x6 1>;
> + system-clock-direction-out;
> + };
> +
> + codec {
> + sound-dai = <>;
> + system-clock-frequency = <12288000>;
I think it would be better to use:
clocks = <_mclk>;
> + };
> + };
> +
> + simple-audio-card,dai-link@1 {
> + format = "i2s";
> + bitclock-master = <_1_master>;
> + frame-master = <_1_master>;
> + sound0_1_master: cpu {
> + sound-dai = <>;
> + clocks = <_clks 0x6 1>;
> + system-clock-direction-out;
> + };
> +
> + codec {
> + sound-dai = <>;
> + system-clock-frequency = <12288000>;
and here as well:
clocks = <_mclk>;
> + };
> + };
> + };
> +
> + sii9022_mclk: sii9022_mclk {
and rename the fixed clock to aud_mclk as the same clock is connected to
both aic3106 and SiI9022
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <12288000>;
> + };
> };
>
> _pinctrl {
> @@ -214,6 +273,15 @@ K2G_CORE_IOPAD(0x10e4) (BUFFER_CLASS_B | PULL_DISABLE |
> MUX_MODE0) /* dssde.dssd
> K2G_CORE_IOPAD(0x10e8) (BUFFER_CLASS_B | PULL_DISABLE |
> MUX_MODE0) /* dssfid.dssfid */
> >;
> };
> +
> + mcasp2_pins: pinmux_mcasp2_pins {
> + pinctrl-single,pins = <
> + K2G_CORE_IOPAD(0x1234) (BUFFER_CLASS_B | PIN_PULLDOWN |
> MUX_MODE4) /* pr0_pru_gpo2.mcasp2_axr2 */
> + K2G_CORE_IOPAD(0x1238) (BUFFER_CLASS_B | PIN_PULLDOWN |
> MUX_MODE4) /* pr0_pru_gpo3.mcasp2_axr3 */
> + K2G_CORE_IOPAD(0x1254) (BUFFER_CLASS_B | PIN_PULLDOWN |
> MUX_MODE4) /* pr0_pru_gpo10.mcasp2_afsx */
> + K2G_CORE_IOPAD(0x125c) (BUFFER_CLASS_B | PIN_PULLDOWN |
> MUX_MODE4) /* pr0_pru_gpo12.mcasp2_aclkx */
> + >;
> + };
> };
>
> {
> @@ -423,6 +491,10 @@ sii9022: sii9022@3b {
> compatible = "sil,sii9022";
> reg = <0x3b>;
>
> + sil,i2s-data-lanes = < 0 >;
> + clocks = <_mclk>;
> + clock-names = "mclk";
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -444,6 +516,19 @@ sii9022_out: endpoint {
> };
> };
> };
> +
> + tlv320aic3106: tlv320aic3106@1b {
> + #sound-dai-cells = <0>;
> + compatible = "ti,tlv320aic3106";
> + reg = <0x1b>;
> + status = "okay";
>
[PATCH 2/3] drm/tiny: Add driver for ili9341 with parallel bus
From: Mikhail Durnev
MRB2801 display module [1] is an example of ILI9341 display that connects to
Intel 8080 parallel bus. Its connector is compatible with the ALIENTEK STM32
development board.
It can be used with the drm/mipi-dbi bus driver if the bus is emulated with
GPIO.
[1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801
Signed-off-by: Mikhail Durnev
---
drivers/gpu/drm/tiny/Kconfig| 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9341_gpio.c | 290
3 files changed, 304 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f..e48e268 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -66,6 +66,19 @@ config TINYDRM_ILI9341
If M is selected the module will be called ili9341.
+config TINYDRM_ILI9341_GPIO
+ tristate "DRM support for ILI9341 display panels with parallel bus
interface over GPIO"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DBI
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ DRM driver for the following Ilitek ILI9341 panels:
+ * MRB2801 2.8" 240x320 TFT
+
+ If M is selected the module will be called ili9341_gpio.
+
config TINYDRM_ILI9486
tristate "DRM support for ILI9486 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5..1ad2c0d 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
+obj-$(CONFIG_TINYDRM_ILI9341_GPIO) += ili9341_gpio.o
obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o
obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
diff --git a/drivers/gpu/drm/tiny/ili9341_gpio.c
b/drivers/gpu/drm/tiny/ili9341_gpio.c
new file mode 100644
index 000..de8a63b8
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9341_gpio.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Ilitek ILI9341 panels with parallel bus interface
+ *
+ * Copyright 2020 Mikhail Durnev
+ *
+ * Based on ili9341.c:
+ * Copyright 2018 David Lechner
+ *
+ * Based on mi0283qt.c:
+ * Copyright 2016 Noralf Trønnes
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ILI9341_FRMCTR10xb1
+#define ILI9341_DISCTRL0xb6
+#define ILI9341_ETMOD 0xb7
+
+#define ILI9341_PWCTRL10xc0
+#define ILI9341_PWCTRL20xc1
+#define ILI9341_VMCTRL10xc5
+#define ILI9341_VMCTRL20xc7
+#define ILI9341_PWCTRLA0xcb
+#define ILI9341_PWCTRLB0xcf
+
+#define ILI9341_PGAMCTRL 0xe0
+#define ILI9341_NGAMCTRL 0xe1
+#define ILI9341_DTCTRLA0xe8
+#define ILI9341_DTCTRLB0xea
+#define ILI9341_PWRSEQ 0xed
+
+#define ILI9341_EN3GAM 0xf2
+#define ILI9341_PUMPCTRL 0xf7
+
+#define ILI9341_MADCTL_BGR BIT(3)
+#define ILI9341_MADCTL_MV BIT(5)
+#define ILI9341_MADCTL_MX BIT(6)
+#define ILI9341_MADCTL_MY BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct mipi_dbi *dbi = >dbi;
+ u8 addr_mode;
+ int ret, idx;
+
+ if (!drm_dev_enter(pipe->crtc.dev, ))
+ return;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = mipi_dbi_poweron_conditional_reset(dbidev);
+ if (ret < 0)
+ goto out_exit;
+ if (ret == 1)
+ goto out_enable;
+
+ mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_OFF);
+
+ mipi_dbi_command(dbi, ILI9341_PWCTRLB, 0x00, 0xc1, 0x30);
+ mipi_dbi_command(dbi, ILI9341_PWRSEQ, 0x64, 0x03, 0x12, 0x81);
+ mipi_dbi_command(dbi, ILI9341_DTCTRLA, 0x85, 0x00, 0x78);
+ mipi_dbi_command(dbi, ILI9341_PWCTRLA, 0x39, 0x2c, 0x00, 0x34, 0x02);
+ mipi_dbi_command(dbi, ILI9341_PUMPCTRL, 0x20);
+ mipi_dbi_command(dbi, ILI9341_DTCTRLB, 0x00, 0x00);
+
+ /* Power Control */
+ mipi_dbi_command(dbi, ILI9341_PWCTRL1, 0x23);
+ mipi_dbi_command(dbi, ILI9341_PWCTRL2, 0x10);
+ /* VCOM */
+ mipi_dbi_command(dbi, ILI9341_VMCTRL1, 0x3e, 0x28);
+ mipi_dbi_command(dbi, ILI9341_VMCTRL2, 0x86);
+
+ /* Memory Access
[PATCH 1/3] drm/mipi-dbi: Add support for Type B
From: Mikhail Durnev
Intel 8080 type (Type B) parallel bus over GPIO.
The parallel bus is implemented partially. It supports only write
operations from the host to the display. Read operations would
require switching GPIO mode between input and output back and
forth. But this implementation is very simple, and GPIO mode can
be set for all used pins to output once at initialization.
It is enough to support only write operations to initialize displays
and output video data. The bus driver returns EOPNOTSUPP for all read
operations requested through a display driver.
Bit banging is used to transmit data over the parallel bus from host
to display. There are two numbers that contol timings: wr_up_delay
and wr_down_delay. They should be provided by the display driver.
The first number is related to the write control pulse duration, and
the second number is related to the write cycle duration that can
be found in the specification of the display.
Signed-off-by: Mikhail Durnev
---
drivers/gpu/drm/drm_mipi_dbi.c | 116 -
include/drm/drm_mipi_dbi.h | 30 ++-
2 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 230c4fd..4d2e108 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -61,7 +61,7 @@
*3. 8-bit with the Data/Command signal as a separate D/CX pin
*
* Currently mipi_dbi only supports Type C options 1 and 3 with
- * mipi_dbi_spi_init().
+ * mipi_dbi_spi_init() and Type B with mipi_dbi_gpio_init().
*/
#define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
@@ -1158,6 +1158,120 @@ EXPORT_SYMBOL(mipi_dbi_spi_transfer);
#endif /* CONFIG_SPI */
+/*
+ * This function implements data transfer only from host to display.
+ */
+static void mipi_dbi_gpio_transfer(struct mipi_dbi *dbi, u16 data)
+{
+ unsigned long ldata = data;
+
+ /*
+* Set W/R to low to start transfer.
+* Set DB bits with provided data when W/R is low.
+*/
+ gpiod_set_value_cansleep(dbi->wr, 0);
+ gpiod_set_array_value_cansleep(dbi->db->ndescs, dbi->db->desc,
+ dbi->db->info, );
+
+ /*
+* The bus usually needs additional delay.
+*/
+ ndelay(dbi->wr_up_delay);
+
+ /*
+* Set W/R to high to indicate that DB lines are set.
+*/
+ gpiod_set_value_cansleep(dbi->wr, 1);
+
+ /*
+* The connected display needs some time to read the data.
+*/
+ ndelay(dbi->wr_down_delay);
+}
+
+static int mipi_dbi_gpio_command(struct mipi_dbi *dbi, u8 *cmd,
+ u8 *par, size_t num)
+{
+ int i;
+
+ /*
+* Read commands are not currently supported.
+*/
+ if (mipi_dbi_command_is_read(dbi, *cmd))
+ return -EOPNOTSUPP;
+
+ MIPI_DBI_DEBUG_COMMAND(*cmd, par, num);
+
+ gpiod_set_value_cansleep(dbi->dc, 0);
+ mipi_dbi_gpio_transfer(dbi, (u16)*cmd);
+ gpiod_set_value_cansleep(dbi->dc, 1);
+
+ if (dbi->db->ndescs == 16 &&
+ (*cmd == MIPI_DCS_WRITE_MEMORY_START ||
+*cmd == MIPI_DCS_WRITE_MEMORY_CONTINUE)) {
+ /*
+* Only a couple of commands supports 16-bit transfer.
+*/
+ for (i = 0; i < num; i += 2) {
+ u16 data = *(u16 *)[i];
+
+ if (dbi->swap_bytes)
+ data = (data >> 8) | (data << 8);
+
+ mipi_dbi_gpio_transfer(dbi, data);
+ }
+ } else {
+ for (i = 0; i < num; i++) {
+ /*
+* Other commands ignore most significant bits.
+*/
+ mipi_dbi_gpio_transfer(dbi, (u16)par[i]);
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * mipi_dbi_gpio_init - Initialize MIPI DBI Type B interface implemented via
GPIO
+ * @dbi: MIPI DBI structure to initialize
+ * @dc: D/C gpio
+ * @wr: W/R gpio
+ * @db: DB gpios
+ * @wr_up_delay: Delay after setting DB and before changing W/R from low to
high
+ * @wr_down_delay: Delay after changing W/R from low to high
+ *
+ * This function sets _dbi->command, enables _dbi->read_commands for
the
+ * usual read commands. It should be followed by a call to mipi_dbi_dev_init()
or
+ * a driver-specific init.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int mipi_dbi_gpio_init(struct mipi_dbi *dbi, struct gpio_desc *dc,
+ struct gpio_desc *wr, struct gpio_descs *db,
+ unsigned long wr_up_delay, unsigned long wr_down_delay)
+{
+ dbi->spi = 0; /* Type B uses GPIO lines rather than SPI */
+
+ dbi->read_commands = mipi_dbi_dcs_read_commands;
+ dbi->command = mipi_dbi_gpio_command;
+
+ dbi->dc = dc;
+ dbi->wr = wr;
+
[PATCH 0/3] drm/mipi-dbi: Type B bus support, drm/tiny: MRB2801
From: Mikhail Durnev Hi All, This patch series is aiming at extending the mipi-dbi bus driver to support Intel 8080 type parallel bus (Type B) over GPIO and adding a new driver for ILI9341 display panels with 8- or 16-bit parallel interface. It was tested with the MRB2801 display module [1] that had a connector compatible with the ALIENTEK STM32 development board. The module was connected to Raspberry Pi 3 via GPIO pins. The parallel bus is implemented partially. It supports only write operations from the host to the display. Read operations would require switching GPIO mode between input and output back and forth. But this implementation is very simple, and GPIO mode can be set for all used pins to output once at initialization. The RD pin of the display has to always receive the logic high signal to make sure the data bus pins from the dislay side are always in the high impedance state. Otherwise the display module as well as the GPIO controller of the host can be damaged. To be on the safe side I recommend using protective resistors for all GPIO pins conneced to DB pins of the display. Resistors of 10 kOhms are just fine for RPi 3. The WR and DC pins may not work well with 10K resistors. Although there is no need to protect them, you can try using 1K resistors if you want. Bit banging is used to transmit data over the parallel bus from host to display. There are two numbers that contol timings. They should be defined in the device tree via the wr-up-down-delays property. The first number is related to the write control pulse duration, and the second number is related to the write cycle duration. For ILI9341, the write pulse cannot be shorter than 15 ns, and the write duration cannot be shorter than 66 ns. Delays of 10 and 51 ns respectively allow to meet the specifications on RPi 3. Faster machines may need values closer to 15 and 66. [1] http://www.lcdwiki.com/2.8inch_16BIT_Module_ILI9341_SKU:MRB2801 Mikhail Durnev (3): drm/mipi-dbi: Add support for Type B drm/tiny: Add driver for ili9341 with parallel bus dt-bindings: panel: Add bindings for MRB2801 .../devicetree/bindings/display/ronbo,mrb2801.txt | 42 +++ drivers/gpu/drm/drm_mipi_dbi.c | 116 - drivers/gpu/drm/tiny/Kconfig | 13 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/ili9341_gpio.c| 290 + include/drm/drm_mipi_dbi.h | 30 ++- 6 files changed, 490 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/ronbo,mrb2801.txt create mode 100644 drivers/gpu/drm/tiny/ili9341_gpio.c -- 2.7.4
[PATCH 1/1] ACPI/nfit: avoid accessing uninitialized memory in acpi_nfit_ctl()
The ACPI_ALLOCATE() does not zero the "buf", so when the condition
"integer->type != ACPI_TYPE_INTEGER" in int_to_buf() is met, the result
is unpredictable in acpi_nfit_ctl().
Signed-off-by: Zhen Lei
---
drivers/acpi/nfit/core.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 442608220b5c..cda7b6c52504 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -282,18 +282,19 @@ static union acpi_object *pkg_to_buf(union acpi_object
*pkg)
static union acpi_object *int_to_buf(union acpi_object *integer)
{
- union acpi_object *buf = ACPI_ALLOCATE(sizeof(*buf) + 4);
+ union acpi_object *buf = NULL;
void *dst = NULL;
- if (!buf)
- goto err;
-
if (integer->type != ACPI_TYPE_INTEGER) {
WARN_ONCE(1, "BIOS bug, unexpected element type: %d\n",
integer->type);
goto err;
}
+ buf = ACPI_ALLOCATE(sizeof(*buf) + 4);
+ if (!buf)
+ goto err;
+
dst = buf + 1;
buf->type = ACPI_TYPE_BUFFER;
buf->buffer.length = 4;
--
2.26.0.106.g9fadedd
Re: [PATCH net-next v4 4/4] net: phy: dp83td510: Add support for the DP83TD510 Ethernet PHY
Hi Dan,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Dan-Murphy/DP83TD510-Single-Pair-10Mbps-Ethernet-PHY/20201118-041918
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
72308ecbf33b145641aba61071be31a85ebfd92c
config: arm-randconfig-m031-20201118 (attached as .config)
compiler: arm-linux-gnueabi-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/ec556cedbd640ecfa25713eadf48e5b7ee74fda3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Dan-Murphy/DP83TD510-Single-Pair-10Mbps-Ethernet-PHY/20201118-041918
git checkout ec556cedbd640ecfa25713eadf48e5b7ee74fda3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 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 >>):
drivers/net/phy/dp83td510.c: In function 'dp83869_of_init':
>> drivers/net/phy/dp83td510.c:450:2: error: 'dp83td510' undeclared (first use
>> in this function)
450 | dp83td510->hi_diff_output = DP83TD510_2_4V_P2P
| ^
drivers/net/phy/dp83td510.c:450:2: note: each undeclared identifier is
reported only once for each function it appears in
>> drivers/net/phy/dp83td510.c:451:2: error: expected ';' before 'dp83td510'
451 | dp83td510->tx_fifo_depth = DP83TD510_FIFO_DEPTH_5_B_NIB
| ^
drivers/net/phy/dp83td510.c:453:1: error: no return statement in function
returning non-void [-Werror=return-type]
453 | }
| ^
drivers/net/phy/dp83td510.c: In function 'dp83td510_probe':
>> drivers/net/phy/dp83td510.c:468:8: error: implicit declaration of function
>> 'dp83td510_of_init'; did you mean 'dp83td510_config_init'?
>> [-Werror=implicit-function-declaration]
468 | ret = dp83td510_of_init(phydev);
|^
|dp83td510_config_init
At top level:
drivers/net/phy/dp83td510.c:448:12: warning: 'dp83869_of_init' defined but
not used [-Wunused-function]
448 | static int dp83869_of_init(struct phy_device *phydev)
|^~~
cc1: some warnings being treated as errors
vim +/dp83td510 +450 drivers/net/phy/dp83td510.c
390
391 #if IS_ENABLED(CONFIG_OF_MDIO)
392 static int dp83td510_of_init(struct phy_device *phydev)
393 {
394 struct dp83td510_private *dp83td510 = phydev->priv;
395 struct device *dev = >mdio.dev;
396 struct device_node *of_node = dev->of_node;
397 s32 rx_int_delay;
398 s32 tx_int_delay;
399 int ret;
400
401 if (!of_node)
402 return -ENODEV;
403
404 ret = of_property_read_u32(phydev->mdio.dev.of_node,
405 "max-tx-rx-p2p-microvolt",
406 >hi_diff_output);
407 if (ret)
408 dp83td510->hi_diff_output = DP83TD510_2_4V_P2P;
409
410 if (dp83td510->hi_diff_output != DP83TD510_2_4V_P2P &&
411 dp83td510->hi_diff_output != DP83TD510_1_1V_P2P)
412 return -EINVAL;
413
414 if (of_property_read_u32(phydev->mdio.dev.of_node,
"tx-fifo-depth",
415 >tx_fifo_depth))
416 dp83td510->tx_fifo_depth = DP83TD510_FIFO_DEPTH_5_B_NIB;
417
418 switch (dp83td510->tx_fifo_depth) {
419 case 4:
420 dp83td510->tx_fifo_depth = DP83TD510_FIFO_DEPTH_4_B_NIB;
421 break;
422 case 6:
423 dp83td510->tx_fifo_depth = DP83TD510_FIFO_DEPTH_6_B_NIB;
424 break;
425 case 8:
426 dp83td510->tx_fifo_depth = DP83TD510_FIFO_DEPTH_8_B_NIB;
427 break;
428 case 5:
429 default:
430 dp83td510->tx_fifo_depth = DP83TD510_FIFO_DEPTH_5_B_NIB;
431 }
432
433 rx_int_delay = phy_get_internal_delay(phydev, dev, NULL, 0,
true);
434 if (rx_int_delay <= 0)
435 dp83td510->rgmii_delay = DP83TD510_RX_CLK_SHIFT;
436 else
437 dp83td510->rgmii_delay = 0;
438
439 tx_int_delay = phy_get_internal_delay(phydev, dev, NULL, 0,
false);
440 if (tx_int_delay <= 0)
441 dp83td510->rgmii_delay |= DP83TD510_TX_CLK_SHIFT;
442 else
443 dp83td510->rgmii_delay &= ~DP83TD510_TX_CLK_SHIFT;
444
Re: [PATCH v3] ALSA: usb-audio: disable 96khz support for HUAWEI USB-C HEADSET
On Wed, 18 Nov 2020 06:26:06 +0100, Macpaul Lin wrote: > > On Tue, 2020-11-10 at 17:04 +0800, Macpaul Lin wrote: > > The HUAWEI USB-C headset (VID:0x12d1, PID:0x3a07) reported it supports > > 96khz. However there will be some random issue under 96khz. > > Not sure if there is any alternate setting could be applied. > > Hence 48khz is suggested to be applied at this moment. > > > > Signed-off-by: Macpaul Lin > > Signed-off-by: Eddie Hung > > Cc: sta...@vger.kernel.org > > --- > > Changes for v2: > > - Fix build error. > > - Add Cc: sta...@vger.kernel.org > > Changes for v3: > > - Replace "udev" with "chip->dev" according to Takashi's suggestion. > > Thanks. > > > > sound/usb/format.c |5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/sound/usb/format.c b/sound/usb/format.c > > index 1b28d01..0aff774 100644 > > --- a/sound/usb/format.c > > +++ b/sound/usb/format.c > > @@ -217,6 +217,11 @@ static int parse_audio_format_rates_v1(struct > > snd_usb_audio *chip, struct audiof > > (chip->usb_id == USB_ID(0x041e, 0x4064) || > > chip->usb_id == USB_ID(0x041e, 0x4068))) > > rate = 8000; > > + /* Huawei headset can't support 96kHz fully */ > > + if (rate == 96000 && > > + chip->usb_id == USB_ID(0x12d1, 0x3a07) && > > + le16_to_cpu(chip->dev->descriptor.bcdDevice) == > > 0x49) > > + continue; > > > > fp->rate_table[fp->nr_rates] = rate; > > if (!fp->rate_min || rate < fp->rate_min) > > Sorry for bothering again, please hold-on this patch. > I'm still trying to clarify if there is another approach for this > interoperability issue. > I'll update this thread once the result has came out. OK, thanks for information. Takashi
[PATCH -next] scsi: lpfc: Mark lpfc_nvmet_prep_abort_wqe with static keyword
Fix the following sparse warning:
drivers/scsi/lpfc/lpfc_nvmet.c:3340:1: warning: symbol
'lpfc_nvmet_prep_abort_wqe' was not declared. Should it be static?
Signed-off-by: Zou Wei
---
drivers/scsi/lpfc/lpfc_nvmet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lpfc_nvmet.c b/drivers/scsi/lpfc/lpfc_nvmet.c
index c8b9434..a71df87 100644
--- a/drivers/scsi/lpfc/lpfc_nvmet.c
+++ b/drivers/scsi/lpfc/lpfc_nvmet.c
@@ -3336,7 +3336,7 @@ lpfc_nvmet_unsol_issue_abort(struct lpfc_hba *phba,
*
* This function is called with hbalock held.
**/
-void
+static void
lpfc_nvmet_prep_abort_wqe(struct lpfc_iocbq *pwqeq, u16 xritag, u8 opt)
{
union lpfc_wqe128 *wqe = >wqe;
--
2.6.2
[tip:efi/core] BUILD SUCCESS b283477d394ac41ca59ee20eb9293ae9002eb1d7
defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a006-20201117 i386 randconfig-a005-20201117 i386 randconfig-a001-20201117 i386 randconfig-a002-20201117 i386 randconfig-a004-20201117 i386 randconfig-a003-20201117 x86_64 randconfig-a015-20201115 x86_64 randconfig-a011-20201115 x86_64 randconfig-a014-20201115 x86_64 randconfig-a013-20201115 x86_64 randconfig-a016-20201115 x86_64 randconfig-a012-20201115 i386 randconfig-a012-20201117 i386 randconfig-a014-20201117 i386 randconfig-a016-20201117 i386 randconfig-a011-20201117 i386 randconfig-a015-20201117 i386 randconfig-a013-20201117 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a003-20201117 x86_64 randconfig-a005-20201117 x86_64 randconfig-a004-20201117 x86_64 randconfig-a002-20201117 x86_64 randconfig-a001-20201117 x86_64 randconfig-a006-20201117 x86_64 randconfig-a015-20201116 x86_64 randconfig-a011-20201116 x86_64 randconfig-a014-20201116 x86_64 randconfig-a013-20201116 x86_64 randconfig-a016-20201116 x86_64 randconfig-a012-20201116 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:x86/cleanups] BUILD SUCCESS 09a217c10504bcaef911cf2af74e424338efe629
defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a006-20201117 i386 randconfig-a005-20201117 i386 randconfig-a001-20201117 i386 randconfig-a002-20201117 i386 randconfig-a004-20201117 i386 randconfig-a003-20201117 x86_64 randconfig-a015-20201115 x86_64 randconfig-a011-20201115 x86_64 randconfig-a014-20201115 x86_64 randconfig-a013-20201115 x86_64 randconfig-a016-20201115 x86_64 randconfig-a012-20201115 i386 randconfig-a012-20201117 i386 randconfig-a014-20201117 i386 randconfig-a016-20201117 i386 randconfig-a011-20201117 i386 randconfig-a015-20201117 i386 randconfig-a013-20201117 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a003-20201117 x86_64 randconfig-a005-20201117 x86_64 randconfig-a004-20201117 x86_64 randconfig-a002-20201117 x86_64 randconfig-a001-20201117 x86_64 randconfig-a006-20201117 x86_64 randconfig-a015-20201116 x86_64 randconfig-a011-20201116 x86_64 randconfig-a014-20201116 x86_64 randconfig-a013-20201116 x86_64 randconfig-a016-20201116 x86_64 randconfig-a012-20201116 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v2 2/4] mtd: parsers: Add Qcom SMEM parser
On Tue, Nov 17, 2020 at 10:20:33PM -0600, Bjorn Andersson wrote:
> On Tue 17 Nov 11:48 CST 2020, Manivannan Sadhasivam wrote:
>
> > NAND based Qualcomm platforms have the partition table populated in the
> > Shared Memory (SMEM). Hence, add a parser for parsing the partitions
> > from it.
> >
> > Signed-off-by: Manivannan Sadhasivam
> > ---
> > drivers/mtd/parsers/Kconfig| 8 ++
> > drivers/mtd/parsers/Makefile | 1 +
> > drivers/mtd/parsers/qcomsmempart.c | 169 +
> > 3 files changed, 178 insertions(+)
> > create mode 100644 drivers/mtd/parsers/qcomsmempart.c
> >
> > diff --git a/drivers/mtd/parsers/Kconfig b/drivers/mtd/parsers/Kconfig
> > index e72354322f62..d90c30229052 100644
> > --- a/drivers/mtd/parsers/Kconfig
> > +++ b/drivers/mtd/parsers/Kconfig
> > @@ -160,3 +160,11 @@ config MTD_REDBOOT_PARTS_READONLY
> > 'FIS directory' images, enable this option.
> >
> > endif # MTD_REDBOOT_PARTS
> > +
> > +config MTD_QCOMSMEM_PARTS
> > + tristate "Qualcomm SMEM NAND flash partition parser"
> > + depends on MTD_NAND_QCOM || COMPILE_TEST
> > + depends on QCOM_SMEM
> > + help
> > + This provides support for parsing partitions from Shared Memory (SMEM)
> > + for NAND flash on Qualcomm platforms.
> > diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
> > index b0c5f62f9e85..50eb0b0a2210 100644
> > --- a/drivers/mtd/parsers/Makefile
> > +++ b/drivers/mtd/parsers/Makefile
> > @@ -9,3 +9,4 @@ obj-$(CONFIG_MTD_AFS_PARTS) += afs.o
> > obj-$(CONFIG_MTD_PARSER_TRX) += parser_trx.o
> > obj-$(CONFIG_MTD_SHARPSL_PARTS)+= sharpslpart.o
> > obj-$(CONFIG_MTD_REDBOOT_PARTS)+= redboot.o
> > +obj-$(CONFIG_MTD_QCOMSMEM_PARTS) += qcomsmempart.o
> > diff --git a/drivers/mtd/parsers/qcomsmempart.c
> > b/drivers/mtd/parsers/qcomsmempart.c
> > new file mode 100644
> > index ..d8c2a3fa4dfe
> > --- /dev/null
> > +++ b/drivers/mtd/parsers/qcomsmempart.c
> > @@ -0,0 +1,169 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Qualcomm SMEM NAND flash partition parser
> > + *
> > + * Copyright (C) 2020, Linaro Ltd.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define SMEM_AARM_PARTITION_TABLE 9
> > +#define SMEM_APPS 0
> > +
> > +#define SMEM_FLASH_PART_MAGIC1 0x55ee73aa
> > +#define SMEM_FLASH_PART_MAGIC2 0xe35ebddb
> > +#define SMEM_FLASH_PTABLE_V3 3
> > +#define SMEM_FLASH_PTABLE_V4 4
> > +#define SMEM_FLASH_PTABLE_MAX_PARTS_V3 16
> > +#define SMEM_FLASH_PTABLE_MAX_PARTS_V4 48
> > +#define SMEM_FLASH_PTABLE_HDR_LEN (4 * sizeof(u32))
> > +#define SMEM_FLASH_PTABLE_NAME_SIZE16
> > +
> > +/**
> > + * struct smem_flash_pentry - SMEM Flash partition entry
> > + * @name: Name of the partition
> > + * @offset: Offset in blocks
> > + * @length: Length of the partition in blocks
> > + * @attr: Flags for this partition
> > + */
> > +struct smem_flash_pentry {
> > + char name[SMEM_FLASH_PTABLE_NAME_SIZE];
> > + u32 offset;
>
> It would be nice if you noted that these are little endian (using
> __le32) and used le32_to_cpu() below.
>
>
Good catch! Will do.
> Apart from that I think this looks really good.
>
[...]
> > + }
> > +
> > + pr_debug("SMEM partition table found: ver: %d len: %d\n",
> > +ptable->version, ptable->numparts);
> > + *pparts = parts;
> > +
> > + return i;
>
> Had to check a few times, but afaict this is just ptable->numparts in
> disguise... So how about just writing that instead?
>
Sure, will do.
Thanks,
Mani
[PATCH v2 3/4] arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4
From: Chen-Yu Tsai
Only the NanoPC T4 hs the PCIe reset pin routed to the SoC. For the
NanoPi M4 family, no such signal is routed to the expansion header on
the base board.
As the schematics for the expansion board were not released, it is
unclear how this is handled, but the likely answer is that the signal
is always pulled high.
Move the ep-gpios property from the common nanopi4.dtsi file to the
board level nanopc-t4.dts file. This makes the nanopi-m4 lack ep-gpios,
matching the board design.
A companion patch "PCI: rockchip: make ep_gpio optional" for the Linux
driver is required, as the driver currently requires the property to be
present.
Fixes: e7a095908227 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4")
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts | 1 +
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
index e0d75617bb7e..452728b82e42 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
@@ -95,6 +95,7 @@ map3 {
};
{
+ ep-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
num-lanes = <4>;
vpcie3v3-supply = <_sys>;
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 76a8b40a93c6..48ed4aaa37f3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -504,7 +504,6 @@ _phy {
};
{
- ep-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
max-link-speed = <2>;
num-lanes = <2>;
vpcie0v9-supply = <_s3>;
--
2.29.1
[PATCH v2 0/4] arm64: rockchip: Fix PCIe ep-gpios requirement and Add Nanopi M4B
From: Chen-Yu Tsai Hi everyone, This is v2 of my Nanopi M4B series. Changes since v1 include: - Rewrite subject of patch 1 to match existing convention and reference 'ep-gpios' DT property instead of the 'ep_gpio' field This series mainly adds support for the new Nanopi M4B, which is a newer variant of the Nanopi M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi While working on this, I found that for the M4 family, the PCIe reset pin (from the M.2 expansion board) was not wired to the SoC. Only the NanoPC T4 has this wired. This ended up in patches 1 and 3. Patch 1 makes ep_gpio in the Rockchip PCIe driver optional. This property is optional in the DT binding, so this just makes the driver adhere to the binding. Patch 2 adds a new compatible string for the new board. Patch 3 moves the ep-gpios property of the pcie controller from the common nanopi4.dtsi file to the nanopc-t4.dts file. Patch 4 adds a new device tree file for the new board. It includes the original device tree for the M4, and then lists the differences. Given that patch 3 would make PCIe unusable without patch 1, I suggest merging patch 1 through the PCI tree as a fix for 5.10, and the rest for 5.11 through the Rockchip tree. Please have a look. The changes are mostly trivial. Regards ChenYu Chen-Yu Tsai (4): PCI: rockchip: Make 'ep-gpios' DT property optional dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4 arm64: dts: rockchip: rk3399: Add NanoPi M4B .../devicetree/bindings/arm/rockchip.yaml | 1 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3399-nanopc-t4.dts| 1 + .../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++ .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - drivers/pci/controller/pcie-rockchip.c| 2 +- 6 files changed, 56 insertions(+), 2 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts -- 2.29.1
[PATCH v2 4/4] arm64: dts: rockchip: rk3399: Add NanoPi M4B
From: Chen-Yu Tsai
The NanoPi M4B is a minor revision of the original M4.
The differences against the original Nanopi M4 that are common with the
other M4V2 revision include:
- microphone header removed
- power button added
- recovery button added
Additional changes specific to the M4B:
- USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x
USB 2.0 ports
- ADB toggle switch added; this changes the top USB 3.0 host port to
a peripheral port
- Type-C port no longer supports data or PD
- WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0
but only 1T1R (down from 2T2R) for WiFi
Add a new dts file for the new board revision that shows the difference
against the original.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++
2 files changed, 53 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 5a53979b7057..fd47414e40eb 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-kobol-helios64.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-pinebook-pro.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
new file mode 100644
index ..72182c58cc46
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPi M4B board device tree source
+ *
+ * Copyright (c) 2020 Chen-Yu Tsai
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi-m4.dts"
+
+/ {
+ model = "FriendlyElec NanoPi M4B";
+ compatible = "friendlyarm,nanopi-m4b", "rockchip,rk3399";
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <150>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <18000>;
+ };
+ };
+};
+
+/* No USB type-C PD power manager */
+/delete-node/
+
+ {
+ status = "disabled";
+};
+
+_host {
+ phy-supply = <_usb2>;
+};
+
+_otg {
+ phy-supply = <_typec>;
+};
+
+_otg {
+ phy-supply = <_usb1>;
+};
+
+_typec {
+ enable-active-high;
+ gpios = < RK_PD2 GPIO_ACTIVE_HIGH>;
+};
--
2.29.1
[PATCH v2 1/4] PCI: rockchip: Make 'ep-gpios' DT property optional
From: Chen-Yu Tsai
The Rockchip PCIe controller DT binding clearly states that 'ep-gpios' is
an optional property. And indeed there are boards that don't require it.
Make the driver follow the binding by using devm_gpiod_get_optional()
instead of devm_gpiod_get().
Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
Fixes: 964bac9455be ("PCI: rockchip: Split out rockchip_pcie_parse_dt() to
parse DT")
Signed-off-by: Chen-Yu Tsai
---
Changes since v1:
- Rewrite subject to match existing convention and reference
'ep-gpios' DT property instead of the 'ep_gpio' field
---
drivers/pci/controller/pcie-rockchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-rockchip.c
b/drivers/pci/controller/pcie-rockchip.c
index 904dec0d3a88..c95950e9004f 100644
--- a/drivers/pci/controller/pcie-rockchip.c
+++ b/drivers/pci/controller/pcie-rockchip.c
@@ -118,7 +118,7 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
}
if (rockchip->is_rc) {
- rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
+ rockchip->ep_gpio = devm_gpiod_get_optional(dev, "ep",
GPIOD_OUT_HIGH);
if (IS_ERR(rockchip->ep_gpio)) {
dev_err(dev, "missing ep-gpios property in node\n");
return PTR_ERR(rockchip->ep_gpio);
--
2.29.1
[PATCH v2 2/4] dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B
From: Chen-Yu Tsai The NanoPi M4B is a minor revision of the original M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi Add a compatible string for the new board revision. Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/arm/rockchip.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 37fd456170d2..1c0ec57ba860 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -126,6 +126,7 @@ properties: - enum: - friendlyarm,nanopc-t4 - friendlyarm,nanopi-m4 + - friendlyarm,nanopi-m4b - friendlyarm,nanopi-neo4 - const: rockchip,rk3399 -- 2.29.1
Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver
On Tue, Nov 17, 2020 at 05:06:47PM -0700, Mathieu Poirier wrote: [snip] > I confirm that all this is working as expected - I will send a new revision of > this set tomorrow afternoon. > > Guennadi, can I add a Co-developed-by and Signed-off-by with your name on the > patch? You can add the "Co-developed-by" tag, sure, if you like. As for the SOB: I'm not sure if this is a proper use of it? AFAIK SOB is used when that person "transmitted" the patch, e.g. if they developed and submitted it to a list, or if they received it from someone and forwarded it upstream (maintainer case). I'm not sure about this case, but well, feel free, don't think we'd be violating anything since I did send versions of code, similar to parts of that, some with my SOF, so, should be fine. Thanks Guennadi
Re: [RFC][PATCH v2 00/21] x86/pti: Defer CR3 switch to C code
On 11/17/20 10:23 PM, Borislav Petkov wrote: On Tue, Nov 17, 2020 at 08:02:51PM +0100, Alexandre Chartre wrote: No. This prevents the guest VM from gathering data from the host kernel on the same cpu-thread. But there's no mitigation for a guest VM running on a cpu-thread attacking another cpu-thread (which can be running another guest VM or the host kernel) from the same cpu-core. You cannot use flush/clear barriers because the two cpu-threads are running in parallel. Now there's your justification for why you're doing this. It took a while... The "why" should always be part of the 0th message to provide reviewers/maintainers with answers to the question, what this pile of patches is all about. Please always add this rationale to your patchset in the future. Sorry about that, I will definitively try to do better next time. :-} Thanks, alex.
[PATCH] Changes since v1 - Change subject form "ALSA" to "USB:" - Adjust to approoriate line
USB: quirks: Add USB_QUIRK_DISCONNECT_SUSPEND quirk for
Lenovo A630Z TIO built-in usb-audio card
Add a USB_QUIRK_DISCONNECT_SUSPEND quirk for the Lenovo TIO built-in
usb-audio. when A630Z going into S3,the system immediately wakeup 7-8
seconds later by usb-audio disconnect interrupt to avoids the issue.
Seeking a better fix, we've tried a lot of things, including:
- Check that the device's power/wakeup is disabled
- Check that remote wakeup is off at the USB level
- All the quirks in drivers/usb/core/quirks.c
e.g. USB_QUIRK_RESET_RESUME,
USB_QUIRK_RESET,
USB_QUIRK_IGNORE_REMOTE_WAKEUP,
USB_QUIRK_NO_LPM.
but none of that makes any difference.
There are no errors in the logs showing any suspend/resume-related issues.
When the system wakes up due to the modem, log-wise it appears to be a
normal resume.
Introduce a quirk to disable the port during suspend when the modem is
detected.
Signed-off-by: penghao
---
drivers/usb/core/quirks.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 7c1198f80c23..8d18e89f9eb0 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -410,7 +410,11 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x1532, 0x0116), .driver_info =
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
- /* BUILDWIN Photo Frame */
+/* Lenovo - ThinkCenter A630Z TI024Gen3 usb-audio card */
+{ USB_DEVICE(0x17ef, 0x0xa012), .driver_info =
+USB_QUIRK_DISCONNECT_SUSPEND },
+
+/* BUILDWIN Photo Frame */
{ USB_DEVICE(0x1908, 0x1315), .driver_info =
USB_QUIRK_HONOR_BNUMINTERFACES },
--
2.11.0
Re: [PATCH] Changes since v1 - Change subject form "ALSA" to "USB:" - Adjust to approoriate line
On Wed, Nov 18, 2020 at 02:51:32PM +0800, penghao wrote:
> USB: quirks: Add USB_QUIRK_DISCONNECT_SUSPEND quirk for
> Lenovo A630Z TIO built-in usb-audio card
Your subject line does not work, please put that information below the
--- line.
Also, we need a "real" name for the From: and signed-off-by line please.
> Add a USB_QUIRK_DISCONNECT_SUSPEND quirk for the Lenovo TIO built-in
> usb-audio. when A630Z going into S3,the system immediately wakeup 7-8
> seconds later by usb-audio disconnect interrupt to avoids the issue.
>
> Seeking a better fix, we've tried a lot of things, including:
> - Check that the device's power/wakeup is disabled
> - Check that remote wakeup is off at the USB level
> - All the quirks in drivers/usb/core/quirks.c
>e.g. USB_QUIRK_RESET_RESUME,
> USB_QUIRK_RESET,
> USB_QUIRK_IGNORE_REMOTE_WAKEUP,
> USB_QUIRK_NO_LPM.
>
> but none of that makes any difference.
>
> There are no errors in the logs showing any suspend/resume-related issues.
> When the system wakes up due to the modem, log-wise it appears to be a
> normal resume.
>
> Introduce a quirk to disable the port during suspend when the modem is
> detected.
>
> Signed-off-by: penghao
> ---
> drivers/usb/core/quirks.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> index 7c1198f80c23..8d18e89f9eb0 100644
> --- a/drivers/usb/core/quirks.c
> +++ b/drivers/usb/core/quirks.c
> @@ -410,7 +410,11 @@ static const struct usb_device_id usb_quirk_list[] = {
> { USB_DEVICE(0x1532, 0x0116), .driver_info =
> USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
>
> - /* BUILDWIN Photo Frame */
> +/* Lenovo - ThinkCenter A630Z TI024Gen3 usb-audio card */
> +{ USB_DEVICE(0x17ef, 0x0xa012), .driver_info =
> +USB_QUIRK_DISCONNECT_SUSPEND },
> +
> +/* BUILDWIN Photo Frame */
Your patch seems to have messed up spaces and tabs here, please fix that
up in your editor and always run scripts/checkpatch.pl on your patch
before resending it.
thanks,
greg k-h
Re: [PATCH v9 8/9] arch, mm: wire up memfd_secret system call were relevant
On Tue, Nov 17, 2020 at 05:15:30PM +, Catalin Marinas wrote: > On Tue, Nov 17, 2020 at 06:29:31PM +0200, Mike Rapoport wrote: > > From: Mike Rapoport > > > > Wire up memfd_secret system call on architectures that define > > ARCH_HAS_SET_DIRECT_MAP, namely arm64, risc-v and x86. > > > > Signed-off-by: Mike Rapoport > > Acked-by: Palmer Dabbelt > > Acked-by: Arnd Bergmann > > --- > > arch/arm64/include/asm/unistd.h| 2 +- > > arch/arm64/include/asm/unistd32.h | 2 ++ > > arch/arm64/include/uapi/asm/unistd.h | 1 + > > arch/riscv/include/asm/unistd.h| 1 + > > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > > include/linux/syscalls.h | 1 + > > include/uapi/asm-generic/unistd.h | 6 +- > > scripts/checksyscalls.sh | 4 > > 9 files changed, 17 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm64/include/asm/unistd.h > > b/arch/arm64/include/asm/unistd.h > > index 86a9d7b3eabe..949788f5ba40 100644 > > --- a/arch/arm64/include/asm/unistd.h > > +++ b/arch/arm64/include/asm/unistd.h > > @@ -38,7 +38,7 @@ > > #define __ARM_NR_compat_set_tls(__ARM_NR_COMPAT_BASE + 5) > > #define __ARM_NR_COMPAT_END(__ARM_NR_COMPAT_BASE + 0x800) > > > > -#define __NR_compat_syscalls 442 > > +#define __NR_compat_syscalls 443 > > #endif > > > > #define __ARCH_WANT_SYS_CLONE > > diff --git a/arch/arm64/include/asm/unistd32.h > > b/arch/arm64/include/asm/unistd32.h > > index 6c1dcca067e0..5279481ec95b 100644 > > --- a/arch/arm64/include/asm/unistd32.h > > +++ b/arch/arm64/include/asm/unistd32.h > > @@ -891,6 +891,8 @@ __SYSCALL(__NR_faccessat2, sys_faccessat2) > > __SYSCALL(__NR_process_madvise, sys_process_madvise) > > #define __NR_watch_mount 441 > > __SYSCALL(__NR_watch_mount, sys_watch_mount) > > +/* 442 is memfd_secret, it is not implemented for 32-bit */ > > +__SYSCALL(442, sys_ni_syscall) > > It now behaves correctly for compat but I don't think we need to > increment __NR_compat_syscalls. The compat syscall handler already calls > sys_ni_syscall() if out of range. Ok, let's drop this change as well :) > So the only arm64 change needed is defining __ARCH_WANT_MEMFD_SECRET > (well, we don't have a use for it yet ;)). > > -- > Catalin -- Sincerely yours, Mike.
[PATCH v3 1/3] media: v4l2-ctrl: Add frame-specific min/max qp controls for hevc
- Adds min/max qp controls for B frame for h264. - Adds min/max qp controls for I/P/B frames for hevc similar to h264. - Update valid range of mim/max qp for hevc to accommodate 10 bit. Signed-off-by: Dikshita Agarwal --- .../userspace-api/media/v4l/ext-ctrls-codec.rst| 52 +- drivers/media/v4l2-core/v4l2-ctrls.c | 8 include/uapi/linux/v4l2-controls.h | 9 3 files changed, 67 insertions(+), 2 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index aac1ea3..a9c7011 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1182,6 +1182,18 @@ enum v4l2_mpeg_video_h264_entropy_mode - V4L2_CID_MPEG_VIDEO_H264_MAX_QP is also set, the quantization parameter should be chosen to meet both requirements. +``V4L2_CID_MPEG_VIDEO_H264_B_FRAME_MIN_QP (integer)`` +Minimum quantization parameter for the H264 B frame to limit B frame +quality to a range. Valid range: from 0 to 51. If +V4L2_CID_MPEG_VIDEO_H264_MIN_QP is also set, the quantization parameter +should be chosen to meet both requirements. + +``V4L2_CID_MPEG_VIDEO_H264_B_FRAME_MAX_QP (integer)`` +Maximum quantization parameter for the H264 B frame to limit B frame +quality to a range. Valid range: from 0 to 51. If +V4L2_CID_MPEG_VIDEO_H264_MAX_QP is also set, the quantization parameter +should be chosen to meet both requirements. + ``V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP (integer)`` Quantization parameter for an I frame for MPEG4. Valid range: from 1 to 31. @@ -3441,11 +3453,11 @@ HEVC/H.265 Control IDs ``V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (integer)`` Minimum quantization parameter for HEVC. -Valid range: from 0 to 51. +Valid range: from 0 - 51 for 8 bit and 0 - 63 for 10 bit. ``V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP (integer)`` Maximum quantization parameter for HEVC. -Valid range: from 0 to 51. +Valid range: from 0 - 51 for 8 bit and 0 - 63 for 10 bit. ``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP (integer)`` Quantization parameter for an I frame for HEVC. @@ -3462,6 +3474,42 @@ HEVC/H.265 Control IDs Valid range: [V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP, V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP]. +``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_MIN_QP (integer)`` +Minimum quantization parameter for the HEVC I frame to limit I frame +quality to a range. Valid range: from 0 to 51 for 8 bit, 0 - 63 for 10 bit. +If V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP is also set, the quantization parameter +should be chosen to meet both requirements. + +``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_MAX_QP (integer)`` +Maximum quantization parameter for the HEVC I frame to limit I frame +quality to a range. Valid range: from 0 to 51 for 8 bit, 0 - 63 for 10 bit. +If V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP is also set, the quantization parameter +should be chosen to meet both requirements. + +``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_MIN_QP (integer)`` +Minimum quantization parameter for the HEVC P frame to limit P frame +quality to a range. Valid range: from 0 to 51 for 8 bit, 0 - 63 for 10 bit. +If V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP is also set, the quantization parameter +should be chosen to meet both requirements. + +``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_MAX_QP (integer)`` +Maximum quantization parameter for the HEVC P frame to limit P frame +quality to a range. Valid range: from 0 to 51 for 8 bit, 0 - 63 for 10 bit. +If V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP is also set, the quantization parameter +should be chosen to meet both requirements. + +``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_MIN_QP (integer)`` +Minimum quantization parameter for the HEVC B frame to limit B frame +quality to a range. Valid range: from 0 to 51 for 8 bit, 0 - 63 for 10 bit. +If V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP is also set, the quantization parameter +should be chosen to meet both requirements. + +``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_MAX_QP (integer)`` +Maximum quantization parameter for the HEVC B frame to limit B frame +quality to a range. Valid range: from 0 to 51 for 8 bit, 0 - 63 for 10 bit. +If V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP is also set, the quantization parameter +should be chosen to meet both requirements. + ``V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP (boolean)`` HIERARCHICAL_QP allows the host to specify the quantization parameter values for each temporal layer through HIERARCHICAL_QP_LAYER. This is diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c index e8ee29e..6e74500 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -920,6 +920,8 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP: return "H264 I-Frame
[PATCH v3 3/3] venus: venc: Add support for frame-specific min/max qp controls
Add support for frame type specific min and max qp controls
for encoder.
Signed-off-by: Dikshita Agarwal
---
drivers/media/platform/qcom/venus/core.h | 18 +
drivers/media/platform/qcom/venus/venc.c | 21 ---
drivers/media/platform/qcom/venus/venc_ctrls.c | 51 ++
3 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 3bc129a..6a764c9 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -230,10 +230,28 @@ struct venc_controls {
u32 h264_b_qp;
u32 h264_min_qp;
u32 h264_max_qp;
+ u32 h264_i_min_qp;
+ u32 h264_i_max_qp;
+ u32 h264_p_min_qp;
+ u32 h264_p_max_qp;
+ u32 h264_b_min_qp;
+ u32 h264_b_max_qp;
u32 h264_loop_filter_mode;
s32 h264_loop_filter_alpha;
s32 h264_loop_filter_beta;
+ u32 hevc_i_qp;
+ u32 hevc_p_qp;
+ u32 hevc_b_qp;
+ u32 hevc_min_qp;
+ u32 hevc_max_qp;
+ u32 hevc_i_min_qp;
+ u32 hevc_i_max_qp;
+ u32 hevc_p_min_qp;
+ u32 hevc_p_max_qp;
+ u32 hevc_b_min_qp;
+ u32 hevc_b_max_qp;
+
u32 vp8_min_qp;
u32 vp8_max_qp;
diff --git a/drivers/media/platform/qcom/venus/venc.c
b/drivers/media/platform/qcom/venus/venc.c
index 0bf92cc..f2f5a85 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -668,17 +668,28 @@ static int venc_set_properties(struct venus_inst *inst)
return ret;
ptype = HFI_PROPERTY_PARAM_VENC_SESSION_QP;
- quant.qp_i = ctr->h264_i_qp;
- quant.qp_p = ctr->h264_p_qp;
- quant.qp_b = ctr->h264_b_qp;
+ if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_HEVC) {
+ quant.qp_i = ctr->hevc_i_qp;
+ quant.qp_p = ctr->hevc_p_qp;
+ quant.qp_b = ctr->hevc_b_qp;
+ } else {
+ quant.qp_i = ctr->h264_i_qp;
+ quant.qp_p = ctr->h264_p_qp;
+ quant.qp_b = ctr->h264_b_qp;
+ }
quant.layer_id = 0;
ret = hfi_session_set_property(inst, ptype, );
if (ret)
return ret;
ptype = HFI_PROPERTY_PARAM_VENC_SESSION_QP_RANGE;
- quant_range.min_qp = ctr->h264_min_qp;
- quant_range.max_qp = ctr->h264_max_qp;
+ if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_HEVC) {
+ quant_range.min_qp = ctr->hevc_min_qp;
+ quant_range.max_qp = ctr->hevc_max_qp;
+ } else {
+ quant_range.min_qp = ctr->h264_min_qp;
+ quant_range.max_qp = ctr->h264_max_qp;
+ }
quant_range.layer_id = 0;
ret = hfi_session_set_property(inst, ptype, _range);
if (ret)
diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c
b/drivers/media/platform/qcom/venus/venc_ctrls.c
index 0708b3b..cd131e3 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -125,9 +125,60 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_H264_MIN_QP:
ctr->h264_min_qp = ctrl->val;
break;
+ case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP:
+ ctr->h264_i_min_qp = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP:
+ ctr->h264_p_min_qp = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_H264_B_FRAME_MIN_QP:
+ ctr->h264_b_min_qp = ctrl->val;
+ break;
case V4L2_CID_MPEG_VIDEO_H264_MAX_QP:
ctr->h264_max_qp = ctrl->val;
break;
+ case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP:
+ ctr->h264_i_max_qp = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP:
+ ctr->h264_p_max_qp = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_H264_B_FRAME_MAX_QP:
+ ctr->h264_b_max_qp = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:
+ ctr->hevc_i_qp = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP:
+ ctr->hevc_p_qp = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP:
+ ctr->hevc_b_qp = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP:
+ ctr->hevc_min_qp = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_MIN_QP:
+ ctr->hevc_i_min_qp = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_MIN_QP:
+ ctr->hevc_p_min_qp = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_MIN_QP:
+ ctr->hevc_b_min_qp = ctrl->val;
+ break;
[PATCH v3 0/3] Add new controls for QP and layer bitrate
This series adds frame specific min/max qp controls for hevc and layer wise bitrate control for h264. Chnages since v2: - addressed comments. - added driver side implementation for new controls. Dikshita Agarwal (3): media: v4l2-ctrl: Add frame-specific min/max qp controls for hevc media: v4l2-ctrl: Add layer wise bitrate controls for h264 venus: venc: Add support for frame-specific min/max qp controls .../userspace-api/media/v4l/ext-ctrls-codec.rst| 72 +- drivers/media/platform/qcom/venus/core.h | 18 ++ drivers/media/platform/qcom/venus/venc.c | 21 +-- drivers/media/platform/qcom/venus/venc_ctrls.c | 51 +++ drivers/media/v4l2-core/v4l2-ctrls.c | 15 + include/uapi/linux/v4l2-controls.h | 17 + 6 files changed, 187 insertions(+), 7 deletions(-) -- 2.7.4
Re: [PATCH v9 6/9] secretmem: add memcg accounting
On Tue, Nov 17, 2020 at 12:02:01PM -0800, Shakeel Butt wrote:
> On Tue, Nov 17, 2020 at 11:49 AM Roman Gushchin wrote:
> >
> > On Tue, Nov 17, 2020 at 06:29:29PM +0200, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > Account memory consumed by secretmem to memcg. The accounting is updated
> > > when the memory is actually allocated and freed.
> > >
> > > Signed-off-by: Mike Rapoport
> [snip]
> > >
> > > +static int secretmem_account_pages(struct page *page, gfp_t gfp, int
> > > order)
> > > +{
> > > + int err;
> > > +
> > > + err = memcg_kmem_charge_page(page, gfp, order);
>
> I haven't looked at the whole series but it seems like these pages
> will be mapped into the userspace, so this patch has dependency on
> Roman's "mm: allow mapping
> accounted kernel pages to userspace" patch series.
Yes, that's why I rebased the patches on top of mmotm.
--
Sincerely yours,
Mike.
[PATCH v3 2/3] media: v4l2-ctrl: Add layer wise bitrate controls for h264
Adds bitrate control for all coding layers for h264
same as hevc.
Signed-off-by: Dikshita Agarwal
---
.../userspace-api/media/v4l/ext-ctrls-codec.rst | 20
drivers/media/v4l2-core/v4l2-ctrls.c | 7 +++
include/uapi/linux/v4l2-controls.h | 8
3 files changed, 35 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index a9c7011..a334eef 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1513,6 +1513,26 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
* - Bit 16:32
- Layer number
+``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L0_BR (integer)``
+Indicates bit rate (bps) for hierarchical coding layer 0 for H264 encoder.
+
+``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L1_BR (integer)``
+Indicates bit rate (bps) for hierarchical coding layer 1 for H264 encoder.
+
+``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L2_BR (integer)``
+Indicates bit rate (bps) for hierarchical coding layer 2 for H264 encoder.
+
+``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L3_BR (integer)``
+Indicates bit rate (bps) for hierarchical coding layer 3 for H264 encoder.
+
+``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L4_BR (integer)``
+Indicates bit rate (bps) for hierarchical coding layer 4 for H264 encoder.
+
+``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L5_BR (integer)``
+Indicates bit rate (bps) for hierarchical coding layer 5 for H264 encoder.
+
+``V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L6_BR (integer)``
+Indicates bit rate (bps) for hierarchical coding layer 6 for H264 encoder.
.. _v4l2-mpeg-h264:
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 6e74500..31ae39c 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -922,6 +922,13 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP: return "H264
P-Frame Maximum QP Value";
case V4L2_CID_MPEG_VIDEO_H264_B_FRAME_MIN_QP: return "H264
B-Frame Minimum QP Value";
case V4L2_CID_MPEG_VIDEO_H264_B_FRAME_MAX_QP: return "H264
B-Frame Maximum QP Value";
+ case V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L0_BR:return "H264
Hierarchical Lay 0 Bitrate";
+ case V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L1_BR:return "H264
Hierarchical Lay 1 Bitrate";
+ case V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L2_BR:return "H264
Hierarchical Lay 2 Bitrate";
+ case V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L3_BR:return "H264
Hierarchical Lay 3 Bitrate";
+ case V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L4_BR:return "H264
Hierarchical Lay 4 Bitrate";
+ case V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L5_BR:return "H264
Hierarchical Lay 5 Bitrate";
+ case V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L6_BR:return "H264
Hierarchical Lay 6 Bitrate";
case V4L2_CID_MPEG_VIDEO_H264_SPS: return "H264
Sequence Parameter Set";
case V4L2_CID_MPEG_VIDEO_H264_PPS: return "H264
Picture Parameter Set";
case V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX: return "H264
Scaling Matrix";
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index fea0f18..0d8c080 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -590,12 +590,20 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type {
#define V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MAX_QP(V4L2_CID_MPEG_BASE+388)
#define V4L2_CID_MPEG_VIDEO_H264_B_FRAME_MIN_QP(V4L2_CID_MPEG_BASE+389)
#define V4L2_CID_MPEG_VIDEO_H264_B_FRAME_MAX_QP(V4L2_CID_MPEG_BASE+390)
+#define V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L0_BR (V4L2_CID_MPEG_BASE +
391)
+#define V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L1_BR (V4L2_CID_MPEG_BASE +
392)
+#define V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L2_BR (V4L2_CID_MPEG_BASE +
393)
+#define V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L3_BR (V4L2_CID_MPEG_BASE +
394)
+#define V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L4_BR (V4L2_CID_MPEG_BASE +
395)
+#define V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L5_BR (V4L2_CID_MPEG_BASE +
396)
+#define V4L2_CID_MPEG_VIDEO_H264_HIER_CODING_L6_BR (V4L2_CID_MPEG_BASE +
397)
#define V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP (V4L2_CID_MPEG_BASE+400)
#define V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP (V4L2_CID_MPEG_BASE+401)
#define V4L2_CID_MPEG_VIDEO_MPEG4_B_FRAME_QP (V4L2_CID_MPEG_BASE+402)
#define V4L2_CID_MPEG_VIDEO_MPEG4_MIN_QP (V4L2_CID_MPEG_BASE+403)
#define V4L2_CID_MPEG_VIDEO_MPEG4_MAX_QP (V4L2_CID_MPEG_BASE+404)
#define V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL(V4L2_CID_MPEG_BASE+405)
+
enum v4l2_mpeg_video_mpeg4_level {
[PATCH v3] power: suspend: Move dpm_watchdog to suspend.c and enhance it
On Fri, Nov 13, 2020 at 2:26 PM Greg Kroah-Hartman wrote: > > On Fri, Oct 23, 2020 at 02:04:17PM +0800, Joseph Jang wrote: > > Since dpm_watchdog just cover device power management, we proposed to > > move it to core power suspend.c to cover not only device power management > > hang issues, but also core power management hand issues. > > > > Since dpm_watchdog stands for device pm, we propose to use new name sleep > > timer and new timeout handler to cover more sleep hang issues. The new > > timeout handler will dump disk sleep task at first round timeout and > > trigger kernel panic at second round timeout. > > The default timer for each round is defined in > > CONFIG_PM_SLEEP_TIMER_TIMEOUT. > > > > Signed-off-by: Joseph Jang > > It still seems odd you can't use a watchdog for this, as you really have > just implemented the same thing here, but "open coded" the logic. > > I'll let Rafael chime in here too, as he knows this area much better > than I as to if this is viable or not. It is viable AFAICS. Just make the existing thing work with dev == NULL and use it as needed. Thank you Greg and Rafael code review and good suggestions. Since dpm_watchdog just covers two functions __device_suspend() and device_resume(). We still don't know how to use current dpm_watchdog to capture other suspend hang cases outside these two functions. So we are trying to enhance it by moving dpm_watchdog from "drivers/base/power/main.c" to "kernel/power/suspend.c" and enable/disable the watchdog in more core pm functions. Could you help to review if we can do that or not? If not, could you help to give us other better suggestions? If you agree to do that, I will provide a new PATCH version 4 to fix all coding problems later. Thank you, Joseph.
Re: WARNING: can't access registers at asm_common_interrupt
On 16.11.20 14:04, Peter Zijlstra wrote:
On Mon, Nov 16, 2020 at 12:56:32PM +0100, Jürgen Groß wrote:
static inline notrace unsigned long arch_local_save_flags(void)
{
PVOP_CALL_ARGS;
PVOP_TEST_NULL(irq.save_fl);
asm_inline volatile(ALTERNATIVE(paravirt_alt(PARAVIRT_CALL),
"PUSHF; POP _ASM_AX",
X86_FEATURE_NATIVE)
I am wondering whether we really want a new feature (basically "not
XENPV). We could use ~X86_FEATURE_XENPV and teach apply_alternatives()
to understand negated features (yes, this limits the number of features
to 32767, but I don't think this is a real problem for quite some time).
Thoughts?
I went with the simple thing for now... If we ever want/need another
negative alternative I suppose we can do as you suggest...
I was still poking at objtool to actually dtrt though..
I'd like to include this part in my series (with a different solution
for the restore_fl part, as suggested by Andy before).
Peter, are you fine with me taking your patch and adding your SoB?
Juergen
---
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index dad350d42ecf..cc88f358bac5 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -237,6 +237,7 @@
#define X86_FEATURE_VMCALL( 8*32+18) /* "" Hypervisor supports
the VMCALL instruction */
#define X86_FEATURE_VMW_VMMCALL ( 8*32+19) /* "" VMware prefers
VMMCALL hypercall instruction */
#define X86_FEATURE_SEV_ES( 8*32+20) /* AMD Secure Encrypted
Virtualization - Encrypted State */
+#define X86_FEATURE_NOT_XENPV ( 8*32+21) /* "" inverse of
X86_FEATURE_XENPV */
/* Intel-defined CPU features, CPUID level 0x0007:0 (EBX), word 9 */
#define X86_FEATURE_FSGSBASE ( 9*32+ 0) /* RDFSBASE, WRFSBASE,
RDGSBASE, WRGSBASE instructions*/
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index d25cc6830e89..e2a9d3e6b7ad 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -645,22 +645,56 @@ bool __raw_callee_save___native_vcpu_is_preempted(long
cpu);
#ifdef CONFIG_PARAVIRT_XXL
static inline notrace unsigned long arch_local_save_flags(void)
{
- return PVOP_CALLEE0(unsigned long, irq.save_fl);
+ PVOP_CALL_ARGS;
+ PVOP_TEST_NULL(irq.save_fl);
+ asm_inline volatile(ALTERNATIVE(paravirt_alt(PARAVIRT_CALL),
+ "pushf; pop %%" _ASM_AX ";",
+ X86_FEATURE_NOT_XENPV)
+ : PVOP_CALLEE_CLOBBERS, ASM_CALL_CONSTRAINT
+ : paravirt_type(irq.save_fl.func),
+ paravirt_clobber(CLBR_RET_REG)
+ : "memory", "cc");
+ return __eax;
}
static inline notrace void arch_local_irq_restore(unsigned long f)
{
- PVOP_VCALLEE1(irq.restore_fl, f);
+ PVOP_CALL_ARGS;
+ PVOP_TEST_NULL(irq.restore_fl);
+ asm_inline volatile(ALTERNATIVE(paravirt_alt(PARAVIRT_CALL),
+ "push %%" _ASM_ARG1 "; popf;",
+ X86_FEATURE_NOT_XENPV)
+ : PVOP_VCALLEE_CLOBBERS, ASM_CALL_CONSTRAINT
+ : paravirt_type(irq.restore_fl.func),
+ paravirt_clobber(CLBR_RET_REG),
+ PVOP_CALL_ARG1(f)
+ : "memory", "cc");
}
static inline notrace void arch_local_irq_disable(void)
{
- PVOP_VCALLEE0(irq.irq_disable);
+ PVOP_CALL_ARGS;
+ PVOP_TEST_NULL(irq.irq_disable);
+ asm_inline volatile(ALTERNATIVE(paravirt_alt(PARAVIRT_CALL),
+ "cli;",
+ X86_FEATURE_NOT_XENPV)
+ : PVOP_VCALLEE_CLOBBERS, ASM_CALL_CONSTRAINT
+ : paravirt_type(irq.irq_disable.func),
+ paravirt_clobber(CLBR_RET_REG)
+ : "memory", "cc");
}
static inline notrace void arch_local_irq_enable(void)
{
- PVOP_VCALLEE0(irq.irq_enable);
+ PVOP_CALL_ARGS;
+ PVOP_TEST_NULL(irq.irq_enable);
+ asm_inline volatile(ALTERNATIVE(paravirt_alt(PARAVIRT_CALL),
+ "sti;",
+ X86_FEATURE_NOT_XENPV)
+ : PVOP_VCALLEE_CLOBBERS, ASM_CALL_CONSTRAINT
+ : paravirt_type(irq.irq_enable.func),
+ paravirt_clobber(CLBR_RET_REG)
+ : "memory", "cc");
}
static inline notrace unsigned long arch_local_irq_save(void)
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 2400ad62f330..5bd8f5503652 100644
---
[PATCH net-next v2] r8153_ecm: avoid to be prior to r8152 driver
Avoid r8153_ecm is compiled as built-in, if r8152 driver is compiled
as modules. Otherwise, the r8153_ecm would be used, even though the
device is supported by r8152 driver.
Fixes: c1aedf015ebd ("net/usb/r8153_ecm: support ECM mode for RTL8153")
Reported-by: Marek Szyprowski
Signed-off-by: Hayes Wang
---
v2:
Use a separate Kconfig entry for r8153_ecm with proper dependencies.
drivers/net/usb/Kconfig | 9 +
drivers/net/usb/Makefile | 3 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index b46993d5f997..1e3719028780 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -628,4 +628,13 @@ config USB_NET_AQC111
This driver should work with at least the following devices:
* Aquantia AQtion USB to 5GbE
+config USB_RTL8153_ECM
+ tristate "RTL8153 ECM support"
+ depends on USB_NET_CDCETHER && (USB_RTL8152 || USB_RTL8152=n)
+ default y
+ help
+ This option supports ECM mode for RTL8153 ethernet adapter, when
+ CONFIG_USB_RTL8152 is not set, or the RTL8153 device is not
+ supported by r8152 driver.
+
endif # USB_NET_DRIVERS
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 99381e6bea78..4964f7b326fb 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_USB_LAN78XX) += lan78xx.o
obj-$(CONFIG_USB_NET_AX8817X) += asix.o
asix-y := asix_devices.o asix_common.o ax88172a.o
obj-$(CONFIG_USB_NET_AX88179_178A) += ax88179_178a.o
-obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o r8153_ecm.o
+obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o
obj-$(CONFIG_USB_NET_CDC_EEM) += cdc_eem.o
obj-$(CONFIG_USB_NET_DM9601) += dm9601.o
obj-$(CONFIG_USB_NET_SR9700) += sr9700.o
@@ -41,3 +41,4 @@ obj-$(CONFIG_USB_NET_QMI_WWAN)+= qmi_wwan.o
obj-$(CONFIG_USB_NET_CDC_MBIM) += cdc_mbim.o
obj-$(CONFIG_USB_NET_CH9200) += ch9200.o
obj-$(CONFIG_USB_NET_AQC111) += aqc111.o
+obj-$(CONFIG_USB_RTL8153_ECM) += r8153_ecm.o
--
2.26.2
[PATCH v3 3/3] f2fs: Handle casefolding with Encryption
Expand f2fs's casefolding support to include encrypted directories. To
index casefolded+encrypted directories, we use the SipHash of the
casefolded name, keyed by a key derived from the directory's fscrypt
master key. This ensures that the dirhash doesn't leak information
about the plaintext filenames.
Encryption keys are unavailable during roll-forward recovery, so we
can't compute the dirhash when recovering a new dentry in an encrypted +
casefolded directory. To avoid having to force a checkpoint when a new
file is fsync'ed, store the dirhash on-disk appended to i_name.
This patch incorporates work by Eric Biggers
and Jaegeuk Kim .
Co-developed-by: Eric Biggers
Signed-off-by: Eric Biggers
Signed-off-by: Daniel Rosenberg
---
fs/f2fs/dir.c | 98 +++---
fs/f2fs/f2fs.h | 8 ++--
fs/f2fs/hash.c | 11 +-
fs/f2fs/inline.c | 4 ++
fs/f2fs/recovery.c | 12 +-
fs/f2fs/super.c| 6 ---
6 files changed, 106 insertions(+), 33 deletions(-)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 71fdf5076461..82b58d1f80eb 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -5,6 +5,7 @@
* Copyright (c) 2012 Samsung Electronics Co., Ltd.
* http://www.samsung.com/
*/
+#include
#include
#include
#include
@@ -206,30 +207,55 @@ static struct f2fs_dir_entry *find_in_block(struct inode
*dir,
/*
* Test whether a case-insensitive directory entry matches the filename
* being searched for.
+ *
+ * Returns 1 for a match, 0 for no match, and -errno on an error.
*/
-static bool f2fs_match_ci_name(const struct inode *dir, const struct qstr
*name,
+static int f2fs_match_ci_name(const struct inode *dir, const struct qstr *name,
const u8 *de_name, u32 de_name_len)
{
const struct super_block *sb = dir->i_sb;
const struct unicode_map *um = sb->s_encoding;
+ struct fscrypt_str decrypted_name = FSTR_INIT(NULL, de_name_len);
struct qstr entry = QSTR_INIT(de_name, de_name_len);
int res;
+ if (IS_ENCRYPTED(dir)) {
+ const struct fscrypt_str encrypted_name =
+ FSTR_INIT((u8 *)de_name, de_name_len);
+
+ if (WARN_ON_ONCE(!fscrypt_has_encryption_key(dir)))
+ return -EINVAL;
+
+ decrypted_name.name = kmalloc(de_name_len, GFP_KERNEL);
+ if (!decrypted_name.name)
+ return -ENOMEM;
+ res = fscrypt_fname_disk_to_usr(dir, 0, 0, _name,
+ _name);
+ if (res < 0)
+ goto out;
+ entry.name = decrypted_name.name;
+ entry.len = decrypted_name.len;
+ }
+
res = utf8_strncasecmp_folded(um, name, );
- if (res < 0) {
- /*
-* In strict mode, ignore invalid names. In non-strict mode,
-* fall back to treating them as opaque byte sequences.
-*/
- if (sb_has_strict_encoding(sb) || name->len != entry.len)
- return false;
- return !memcmp(name->name, entry.name, name->len);
+ /*
+* In strict mode, ignore invalid names. In non-strict mode,
+* fall back to treating them as opaque byte sequences.
+*/
+ if (res < 0 && !sb_has_strict_encoding(sb)) {
+ res = name->len == entry.len &&
+ memcmp(name->name, entry.name, name->len) == 0;
+ } else {
+ /* utf8_strncasecmp_folded returns 0 on match */
+ res = (res == 0);
}
- return res == 0;
+out:
+ kfree(decrypted_name.name);
+ return res;
}
#endif /* CONFIG_UNICODE */
-static inline bool f2fs_match_name(const struct inode *dir,
+static inline int f2fs_match_name(const struct inode *dir,
const struct f2fs_filename *fname,
const u8 *de_name, u32 de_name_len)
{
@@ -256,6 +282,7 @@ struct f2fs_dir_entry *f2fs_find_target_dentry(const struct
f2fs_dentry_ptr *d,
struct f2fs_dir_entry *de;
unsigned long bit_pos = 0;
int max_len = 0;
+ int res = 0;
if (max_slots)
*max_slots = 0;
@@ -273,10 +300,15 @@ struct f2fs_dir_entry *f2fs_find_target_dentry(const
struct f2fs_dentry_ptr *d,
continue;
}
- if (de->hash_code == fname->hash &&
- f2fs_match_name(d->inode, fname, d->filename[bit_pos],
- le16_to_cpu(de->name_len)))
- goto found;
+ if (de->hash_code == fname->hash) {
+ res = f2fs_match_name(d->inode, fname,
+ d->filename[bit_pos],
+ le16_to_cpu(de->name_len));
+
[PATCH v3 2/3] fscrypt: Have filesystems handle their d_ops
This shifts the responsibility of setting up dentry operations from
fscrypt to the individual filesystems, allowing them to have their own
operations while still setting fscrypt's d_revalidate as appropriate.
Most filesystems can just use generic_set_encrypted_ci_d_ops, unless
they have their own specific dentry operations as well. That operation
will set the minimal d_ops required under the circumstances.
Since the fscrypt d_ops are set later on, we must set all d_ops there,
since we cannot adjust those later on. This should not result in any
change in behavior.
Signed-off-by: Daniel Rosenberg
---
fs/crypto/fname.c | 4
fs/crypto/hooks.c | 1 -
fs/ext4/dir.c | 7 ---
fs/ext4/ext4.h | 4
fs/ext4/namei.c | 1 +
fs/ext4/super.c | 5 -
fs/f2fs/dir.c | 7 ---
fs/f2fs/f2fs.h | 3 ---
fs/f2fs/namei.c | 1 +
fs/f2fs/super.c | 1 -
fs/ubifs/dir.c | 1 +
include/linux/fscrypt.h | 7 +--
12 files changed, 8 insertions(+), 34 deletions(-)
diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c
index 1fbe6c24d705..cb3cfa6329ba 100644
--- a/fs/crypto/fname.c
+++ b/fs/crypto/fname.c
@@ -570,7 +570,3 @@ int fscrypt_d_revalidate(struct dentry *dentry, unsigned
int flags)
return valid;
}
EXPORT_SYMBOL_GPL(fscrypt_d_revalidate);
-
-const struct dentry_operations fscrypt_d_ops = {
- .d_revalidate = fscrypt_d_revalidate,
-};
diff --git a/fs/crypto/hooks.c b/fs/crypto/hooks.c
index 20b0df47fe6a..9006fa983335 100644
--- a/fs/crypto/hooks.c
+++ b/fs/crypto/hooks.c
@@ -117,7 +117,6 @@ int __fscrypt_prepare_lookup(struct inode *dir, struct
dentry *dentry,
spin_lock(>d_lock);
dentry->d_flags |= DCACHE_NOKEY_NAME;
spin_unlock(>d_lock);
- d_set_d_op(dentry, _d_ops);
}
return err;
}
diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c
index ca50c90adc4c..e757319a4472 100644
--- a/fs/ext4/dir.c
+++ b/fs/ext4/dir.c
@@ -667,10 +667,3 @@ const struct file_operations ext4_dir_operations = {
.open = ext4_dir_open,
.release= ext4_release_dir,
};
-
-#ifdef CONFIG_UNICODE
-const struct dentry_operations ext4_dentry_ops = {
- .d_hash = generic_ci_d_hash,
- .d_compare = generic_ci_d_compare,
-};
-#endif
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index bf9429484462..ad77f01d9e20 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -3380,10 +3380,6 @@ static inline void ext4_unlock_group(struct super_block
*sb,
/* dir.c */
extern const struct file_operations ext4_dir_operations;
-#ifdef CONFIG_UNICODE
-extern const struct dentry_operations ext4_dentry_ops;
-#endif
-
/* file.c */
extern const struct inode_operations ext4_file_inode_operations;
extern const struct file_operations ext4_file_operations;
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 33509266f5a0..12a417ff5648 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1614,6 +1614,7 @@ static struct buffer_head *ext4_lookup_entry(struct inode
*dir,
struct buffer_head *bh;
err = ext4_fname_prepare_lookup(dir, dentry, );
+ generic_set_encrypted_ci_d_ops(dentry);
if (err == -ENOENT)
return NULL;
if (err)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 6633b20224d5..0288bedf46e1 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4968,11 +4968,6 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
goto failed_mount4;
}
-#ifdef CONFIG_UNICODE
- if (sb->s_encoding)
- sb->s_d_op = _dentry_ops;
-#endif
-
sb->s_root = d_make_root(root);
if (!sb->s_root) {
ext4_msg(sb, KERN_ERR, "get root dentry failed");
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 4b9ef8bbfa4a..71fdf5076461 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -1099,10 +1099,3 @@ const struct file_operations f2fs_dir_operations = {
.compat_ioctl = f2fs_compat_ioctl,
#endif
};
-
-#ifdef CONFIG_UNICODE
-const struct dentry_operations f2fs_dentry_ops = {
- .d_hash = generic_ci_d_hash,
- .d_compare = generic_ci_d_compare,
-};
-#endif
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index cb700d797296..62b4f31d30e2 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -3767,9 +3767,6 @@ static inline void f2fs_update_sit_info(struct
f2fs_sb_info *sbi) {}
#endif
extern const struct file_operations f2fs_dir_operations;
-#ifdef CONFIG_UNICODE
-extern const struct dentry_operations f2fs_dentry_ops;
-#endif
extern const struct file_operations f2fs_file_operations;
extern const struct inode_operations f2fs_file_inode_operations;
extern const struct address_space_operations f2fs_dblock_aops;
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 8fa37d1434de..6edb1ab579a1 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -497,6 +497,7 @@ static struct dentry *f2fs_lookup(struct inode
[PATCH v3 1/3] libfs: Add generic function for setting dentry_ops
This adds a function to set dentry operations at lookup time that will
work for both encrypted filenames and casefolded filenames.
A filesystem that supports both features simultaneously can use this
function during lookup preparations to set up its dentry operations once
fscrypt no longer does that itself.
Currently the casefolding dentry operation are always set if the
filesystem defines an encoding because the features is toggleable on
empty directories. Unlike in the encryption case, the dentry operations
used come from the parent. Since we don't know what set of functions
we'll eventually need, and cannot change them later, we enable the
casefolding operations if the filesystem supports them at all.
By splitting out the various cases, we support as few dentry operations
as we can get away with, maximizing compatibility with overlayfs, which
will not function if a filesystem supports certain dentry_operations.
Signed-off-by: Daniel Rosenberg
---
fs/libfs.c | 70 ++
include/linux/fs.h | 1 +
2 files changed, 71 insertions(+)
diff --git a/fs/libfs.c b/fs/libfs.c
index fc34361c1489..babef1f7b50e 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -1449,4 +1449,74 @@ int generic_ci_d_hash(const struct dentry *dentry,
struct qstr *str)
return 0;
}
EXPORT_SYMBOL(generic_ci_d_hash);
+
+static const struct dentry_operations generic_ci_dentry_ops = {
+ .d_hash = generic_ci_d_hash,
+ .d_compare = generic_ci_d_compare,
+};
+#endif
+
+#ifdef CONFIG_FS_ENCRYPTION
+static const struct dentry_operations generic_encrypted_dentry_ops = {
+ .d_revalidate = fscrypt_d_revalidate,
+};
+#endif
+
+#if IS_ENABLED(CONFIG_UNICODE) && IS_ENABLED(CONFIG_FS_ENCRYPTION)
+static const struct dentry_operations generic_encrypted_ci_dentry_ops = {
+ .d_hash = generic_ci_d_hash,
+ .d_compare = generic_ci_d_compare,
+ .d_revalidate = fscrypt_d_revalidate,
+};
+#endif
+
+/**
+ * generic_set_encrypted_ci_d_ops - helper for setting d_ops for given dentry
+ * @dentry:dentry to set ops on
+ *
+ * Casefolded directories need d_hash and d_compare set, so that the dentries
+ * contained in them are handled case-insensitively. Note that these
operations
+ * are needed on the parent directory rather than on the dentries in it, and
+ * while the casefolding flag can be toggled on and off on an empty directory,
+ * dentry_operations can't be changed later. As a result, if the filesystem
has
+ * casefolding support enabled at all, we have to give all dentries the
+ * casefolding operations even if their inode doesn't have the casefolding flag
+ * currently (and thus the casefolding ops would be no-ops for now).
+ *
+ * Encryption works differently in that the only dentry operation it needs is
+ * d_revalidate, which it only needs on dentries that have the no-key name
flag.
+ * The no-key flag can't be set "later", so we don't have to worry about that.
+ *
+ * Finally, to maximize compatibility with overlayfs (which isn't compatible
+ * with certain dentry operations) and to avoid taking an unnecessary
+ * performance hit, we use custom dentry_operations for each possible
+ * combination rather than always installing all operations.
+ */
+void generic_set_encrypted_ci_d_ops(struct dentry *dentry)
+{
+#ifdef CONFIG_FS_ENCRYPTION
+ bool needs_encrypt_ops = dentry->d_flags & DCACHE_NOKEY_NAME;
+#endif
+#ifdef CONFIG_UNICODE
+ bool needs_ci_ops = dentry->d_sb->s_encoding;
+#endif
+#if defined(CONFIG_FS_ENCRYPTION) && defined(CONFIG_UNICODE)
+ if (needs_encrypt_ops && needs_ci_ops) {
+ d_set_d_op(dentry, _encrypted_ci_dentry_ops);
+ return;
+ }
#endif
+#ifdef CONFIG_FS_ENCRYPTION
+ if (needs_encrypt_ops) {
+ d_set_d_op(dentry, _encrypted_dentry_ops);
+ return;
+ }
+#endif
+#ifdef CONFIG_UNICODE
+ if (needs_ci_ops) {
+ d_set_d_op(dentry, _ci_dentry_ops);
+ return;
+ }
+#endif
+}
+EXPORT_SYMBOL(generic_set_encrypted_ci_d_ops);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 8667d0cdc71e..11345e66353b 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3202,6 +3202,7 @@ extern int generic_ci_d_hash(const struct dentry *dentry,
struct qstr *str);
extern int generic_ci_d_compare(const struct dentry *dentry, unsigned int len,
const char *str, const struct qstr *name);
#endif
+extern void generic_set_encrypted_ci_d_ops(struct dentry *dentry);
#ifdef CONFIG_MIGRATION
extern int buffer_migrate_page(struct address_space *,
--
2.29.2.454.gaff20da3a2-goog
[PATCH v3 0/3] Add support for Encryption and Casefolding in F2FS
These patches are on top of the torvalds tree. F2FS currently supports casefolding and encryption, but not at the same time. These patches aim to rectify that. In a later follow up, this will be added for Ext4 as well. The f2fs-tools changes have already been applied. Since both fscrypt and casefolding require their own dentry operations, I've moved the responsibility of setting the dentry operations from fscrypt to the filesystems and provided helper functions that should work for most cases. These are a follow-up to the previously sent patch set "[PATCH v12 0/4] Prepare for upcoming Casefolding/Encryption patches" v2: Simplified generic dentry_op function Passed through errors in f2fs_match_ci_name v3: Split some long lines Cleaned up some code Made some comments clearer Fixed bug in v2 error passing Daniel Rosenberg (3): libfs: Add generic function for setting dentry_ops fscrypt: Have filesystems handle their d_ops f2fs: Handle casefolding with Encryption fs/crypto/fname.c | 4 -- fs/crypto/hooks.c | 1 - fs/ext4/dir.c | 7 --- fs/ext4/ext4.h | 4 -- fs/ext4/namei.c | 1 + fs/ext4/super.c | 5 -- fs/f2fs/dir.c | 105 +--- fs/f2fs/f2fs.h | 11 ++--- fs/f2fs/hash.c | 11 - fs/f2fs/inline.c| 4 ++ fs/f2fs/namei.c | 1 + fs/f2fs/recovery.c | 12 - fs/f2fs/super.c | 7 --- fs/libfs.c | 70 +++ fs/ubifs/dir.c | 1 + include/linux/fs.h | 1 + include/linux/fscrypt.h | 7 ++- 17 files changed, 185 insertions(+), 67 deletions(-) base-commit: 0fa8ee0d9ab95c9350b8b84574824d9a384a9f7d -- 2.29.2.454.gaff20da3a2-goog
[PATCH net-next v5] net/tun: Call netdev notifiers
Call netdev notifiers before and after changing the device type.
Signed-off-by: Martin Schiller
---
Changes to v4:
* Fix copy'n'paste error
Changes to v3:
* Handle return value of call_netdevice_notifiers()
Changes to v2:
* Use subject_prefix 'net-next' to fix 'fixes_present' issue
Changes to v1:
* Fix 'subject_prefix' and 'checkpatch' warnings
---
drivers/net/tun.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 3d45d56172cb..7c62d82c57db 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -3071,10 +3071,19 @@ static long __tun_chr_ioctl(struct file *file, unsigned
int cmd,
"Linktype set failed because interface is
up\n");
ret = -EBUSY;
} else {
+ ret = call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE,
+ tun->dev);
+ ret = notifier_to_errno(ret);
+ if (ret) {
+ netif_info(tun, drv, tun->dev,
+ "Refused to change device type\n");
+ break;
+ }
tun->dev->type = (int) arg;
netif_info(tun, drv, tun->dev, "linktype set to %d\n",
tun->dev->type);
- ret = 0;
+ call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE,
+tun->dev);
}
break;
--
2.20.1
[PATCH] arm64: mm: add support for memmap kernel parameters
memmap should be an useful kernel parameter which has been supported by
x86, mips and xtensa. This patch adds support for ARM64. At this stage,
the below two modes are supported only:
memmap=nn[KMG]@ss[KMG]
Force usage of a specific region of memory
memmap=nn[KMG]$ss[KMG]
Region of memory to be reserved is from ss to ss+nn
If users set memmap=exactmap before memmap=nn[KMG]@ss[KMG], they will
get the exact memory specified by memmap=nn[KMG]@ss[KMG]. For example,
on one machine with 4GB memory, "memmap=exactmap memmap=1G@1G" will
make kernel use the memory from 1GB to 2GB only.
Signed-off-by: Barry Song
---
arch/arm64/mm/init.c | 59
1 file changed, 59 insertions(+)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 095540667f0f..f1c6bfdbc953 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -235,6 +235,65 @@ static int __init early_mem(char *p)
}
early_param("mem", early_mem);
+static int need_remove_real_memblock __initdata;
+
+static void __init parse_memmap_one(char *p)
+{
+ char *oldp;
+ unsigned long start_at, mem_size;
+
+ if (!p)
+ return;
+
+ if (!strncmp(p, "exactmap", 8)) {
+ need_remove_real_memblock = 1;
+ return;
+ }
+
+ oldp = p;
+ mem_size = memparse(p, );
+ if (p == oldp)
+ return;
+
+ switch (*p) {
+ case '@':
+ start_at = memparse(p + 1, );
+ /*
+* use the exactmap defined by nn[KMG]@ss[KMG], remove
+* memblock populated by DT etc.
+*/
+ if (need_remove_real_memblock) {
+ need_remove_real_memblock = 0;
+ memblock_remove(0, ULLONG_MAX);
+ }
+ memblock_add(start_at, mem_size);
+ break;
+ case '$':
+ start_at = memparse(p + 1, );
+ memblock_reserve(start_at, mem_size);
+ break;
+ default:
+ pr_warn("Unrecognized memmap syntax: %s\n", p);
+ break;
+ }
+}
+
+static int __init parse_memmap_opt(char *str)
+{
+ while (str) {
+ char *k = strchr(str, ',');
+
+ if (k)
+ *k++ = 0;
+
+ parse_memmap_one(str);
+ str = k;
+ }
+
+ return 0;
+}
+early_param("memmap", parse_memmap_opt);
+
static int __init early_init_dt_scan_usablemem(unsigned long node,
const char *uname, int depth, void *data)
{
--
2.25.1
Re: [PATCH 5.4 000/151] 5.4.78-rc1 review
On Tue, 17 Nov 2020 at 18:55, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.78 release. > There are 151 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 19 Nov 2020 12:20:51 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.78-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing NOTE: This intermittent kernel warning was noticed on arm64 NXP ls2088 while booting which was reported on stable-rc 5.8 and stable-rc 5.4. WARNING: CPU: 1 PID: 441 at kernel/irq/chip.c:242 __irq_startup+0x9c/0xa8 https://lore.kernel.org/stable/CA+G9fYsfEVK86ask=fL=m5juerbz+bwbfgcaz_uxwrphxyp...@mail.gmail.com/T/#t Summary kernel: 5.4.78-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: a3746663c34792114dfa71148be3dcc3f3f089ea git describe: v5.4.77-152-ga3746663c347 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.77-152-ga3746663c347 No regressions (compared to build v5.4.77) No fixes (compared to build v5.4.77) Ran 49989 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - x15 - x86 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * linux-log-parser * ltp-containers-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * v4l2-compliance * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-math-tests * network-basic-tests * ltp-open-posix-tests * ltp-tracing-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
[PATCH] mmc: mediatek: Add system suspend/resume interface
Before we got these errors on MT8192 platform:
[ 59.153891] Restarting tasks ...
[ 59.154540] done.
[ 59.159175] PM: suspend exit
[ 59.218724] mtk-msdc 11f6.mmc: phase: [map:fffe] [maxlen:31]
[final:16]
[ 119.776083] mmc0: cqhci: timeout for tag 9
[ 119.780196] mmc0: cqhci: CQHCI REGISTER DUMP ===
[ 119.786709] mmc0: cqhci: Caps: 0x100020b6 | Version: 0x0510
[ 119.793225] mmc0: cqhci: Config:0x0101 | Control: 0x
[ 119.799706] mmc0: cqhci: Int stat: 0x | Int enab: 0x
[ 119.806177] mmc0: cqhci: Int sig: 0x | Int Coal: 0x
[ 119.812670] mmc0: cqhci: TDL base: 0x | TDL up32: 0x
[ 119.819149] mmc0: cqhci: Doorbell: 0x003ffc00 | TCN: 0x0200
[ 119.825656] mmc0: cqhci: Dev queue: 0x | Dev Pend: 0x
[ 119.832155] mmc0: cqhci: Task clr: 0x | SSC1: 0x1000
[ 119.838627] mmc0: cqhci: SSC2: 0x | DCMD rsp: 0x
[ 119.845174] mmc0: cqhci: RED mask: 0xfdf9a080 | TERRI:0x891c
[ 119.851654] mmc0: cqhci: Resp idx: 0x | Resp arg: 0x
[ 119.865773] mmc0: cqhci: : ===
[ 119.872358] mmc0: running CQE recovery
>From these logs, we found TDL base was back to the default value.
After suspend, the mmc host is powered off by HW, and bring CQE register
to the default value, so we add system suspend/resume interface, then bring
CQE to deactivated state before suspend, it will be enabled by CQE first
request after resume.
Signed-off-by: Wenbin Mei
---
drivers/mmc/host/mtk-sd.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index fc5ee5df91ad..c5f9cd6fc951 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -2758,11 +2758,29 @@ static int msdc_runtime_resume(struct device *dev)
msdc_restore_reg(host);
return 0;
}
+
+static int msdc_sys_suspend(struct device *dev)
+{
+ struct mmc_host *mmc = dev_get_drvdata(dev);
+ int ret;
+
+ if (mmc->caps2 & MMC_CAP2_CQE) {
+ ret = cqhci_suspend(mmc);
+ if (ret)
+ return ret;
+ }
+
+ return pm_runtime_force_suspend(dev);
+}
+
+static int msdc_sys_resume(struct device *dev)
+{
+ return pm_runtime_force_resume(dev);
+}
#endif
static const struct dev_pm_ops msdc_dev_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
- pm_runtime_force_resume)
+ SET_SYSTEM_SLEEP_PM_OPS(msdc_sys_suspend, msdc_sys_resume)
SET_RUNTIME_PM_OPS(msdc_runtime_suspend, msdc_runtime_resume, NULL)
};
--
2.18.0
linux-next: Tree for Nov 18
Hi all, Changes since 20201117: The phy-next tree still had its a build failure so I used the version from next-20201116. The gpio tree gained a conflict against the kspp-gustavo tree. It also gained a build failure so I used the version from next-20201117. The mhi tree still had its build failure so I used a supplied patch. Non-merge commits (relative to Linus' tree): 6063 6093 files changed, 551698 insertions(+), 102185 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 327 trees (counting Linus' and 85 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (0fa8ee0d9ab9 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging fixes/fixes (9123e3a74ec7 Linux 5.9-rc1) Merging kbuild-current/fixes (d1889589a4f5 builddeb: Fix rootless build in setuid/setgid directory) Merging arc-current/for-curr (3b57533b460c ARC: [plat-hsdk] Remap CCMs super early in asm boot trampoline) Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe template) Merging arm64-fixes/for-next/fixes (23c216416056 arm64: cpu_errata: Apply Erratum 845719 to KRYO2XX Silver) Merging arm-soc-fixes/arm/fixes (cc05af8e2e91 Merge tag 'imx-fixes-5.10-4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes) Merging drivers-memory-fixes/fixes (275374b46da2 memory: pl353-smc: fix compile test on !ARM_AMBA) Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver to platform driver) Merging powerpc-fixes/fixes (e02152ba2810 powerpc: Drop -me200 addition to build flags) Merging s390-fixes/fixes (78d732e1f326 s390/cpum_sf.c: fix file permission for cpum_sfb_size) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (fd5736bf9f23 enetc: Workaround for MDIO register access issue) Merging bpf/master (2acc3c1bc8e9 selftests/bpf: Fix error return code in run_getsockopt_test()) Merging ipsec/master (48f486e13ffd net: xfrm: fix memory leak in xfrm_user_policy()) Merging netfilter/master (e59d6e876580 netfilter: nftables_offload: build mask based from the matching bytes) Merging ipvs/master (e59d6e876580 netfilter: nftables_offload: build mask based from the matching bytes) Merging wireless-drivers/master (fe56d05ee6c8 iwlwifi: mvm: fix kernel panic in case of assert during CSA) Merging mac80211/master (849920c70339 devlink: Add missing genlmsg_cancel() in devlink_nl_sb_port_pool_fill()) Merging rdma-fixes/for-rc (dabbd6abcdbe IB/hfi1: Fix error return code in hfi1_init_dd()) Merging sound-current/for-linus (54a2a3898f46 ALSA: usb-audio: Add delay quirk for all Logitech USB devices) Merging sound-asoc-fixes/for-linus (98a0b972f57f Merge remote-tracking branch 'asoc/for-5.10' into asoc-linus) Merging regmap-fixes/for-linus (3650b228f83a Linux 5.10-rc1) Merging regulator-fixes/for-linus (f5c042b23f74 regulator: workaround self-referent regulators) Merging spi-fixes/for-linus (0ab018a1b8ba Merge remote-tracking branch 'spi/for-5.10' into spi-linus) Merging pci-current/for-linus (51e2e24504ad PCI: Add function 1 DMA alias quirk f
Re: [PATCH] rtc: sc27xx: Always read normal alarm
Hi Alexandre,
Thanks for this cleanup.
On Wed, 18 Nov 2020 at 05:22, Alexandre Belloni
wrote:
>
> The RTC core only reads the alarm from the hardware at boot time, to know
> whether an alarm was already set before booting. It keeps track of all the
> alarms after that so there is no need to ever read the auxiliary alarm.
>
> Commit 3822d1bb0df1 ("rtc: sc27xx: Always read normal alarm when
> registering RTC device") already effectively removed the capability to read
> the auxiliary alarm a .read_alarm is always called with rtc->registered set
one nit suggestion: add a comma before "a .read_alarm is ..."
> to false.
>
> Signed-off-by: Alexandre Belloni
Reviewed-by: Chunyan Zhang
Cheers,
Chunyan
> ---
> drivers/rtc/rtc-sc27xx.c | 38 ++
> 1 file changed, 2 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/rtc/rtc-sc27xx.c b/drivers/rtc/rtc-sc27xx.c
> index 6e65f68ea86d..a953bc0a5a5b 100644
> --- a/drivers/rtc/rtc-sc27xx.c
> +++ b/drivers/rtc/rtc-sc27xx.c
> @@ -299,33 +299,6 @@ static int sprd_rtc_set_secs(struct sprd_rtc *rtc, enum
> sprd_rtc_reg_types type,
> sts_mask);
> }
>
> -static int sprd_rtc_read_aux_alarm(struct device *dev, struct rtc_wkalrm
> *alrm)
> -{
> - struct sprd_rtc *rtc = dev_get_drvdata(dev);
> - time64_t secs;
> - u32 val;
> - int ret;
> -
> - ret = sprd_rtc_get_secs(rtc, SPRD_RTC_AUX_ALARM, );
> - if (ret)
> - return ret;
> -
> - rtc_time64_to_tm(secs, >time);
> -
> - ret = regmap_read(rtc->regmap, rtc->base + SPRD_RTC_INT_EN, );
> - if (ret)
> - return ret;
> -
> - alrm->enabled = !!(val & SPRD_RTC_AUXALM_EN);
> -
> - ret = regmap_read(rtc->regmap, rtc->base + SPRD_RTC_INT_RAW_STS,
> );
> - if (ret)
> - return ret;
> -
> - alrm->pending = !!(val & SPRD_RTC_AUXALM_EN);
> - return 0;
> -}
> -
> static int sprd_rtc_set_aux_alarm(struct device *dev, struct rtc_wkalrm
> *alrm)
> {
> struct sprd_rtc *rtc = dev_get_drvdata(dev);
> @@ -415,16 +388,9 @@ static int sprd_rtc_read_alarm(struct device *dev,
> struct rtc_wkalrm *alrm)
> u32 val;
>
> /*
> -* Before RTC device is registered, it will check to see if there is
> an
> -* alarm already set in RTC hardware, and we always read the normal
> -* alarm at this time.
> -*
> -* Or if aie_timer is enabled, we should get the normal alarm time.
> -* Otherwise we should get auxiliary alarm time.
> +* The RTC core checks to see if there is an alarm already set in RTC
> +* hardware, and we always read the normal alarm at this time.
> */
> - if (rtc->rtc && rtc->rtc->registered && rtc->rtc->aie_timer.enabled
> == 0)
> - return sprd_rtc_read_aux_alarm(dev, alrm);
> -
> ret = sprd_rtc_get_secs(rtc, SPRD_RTC_ALARM, );
> if (ret)
> return ret;
> --
> 2.28.0
>
Re: [PATCH v2 3/3] f2fs: Handle casefolding with Encryption
On Tue, Nov 17, 2020 at 10:22:28PM -0800, Daniel Rosenberg wrote:
> > > @@ -273,10 +308,14 @@ struct f2fs_dir_entry
> > > *f2fs_find_target_dentry(const struct f2fs_dentry_ptr *d,
> > > continue;
> > > }
> > >
> > > - if (de->hash_code == fname->hash &&
> > > - f2fs_match_name(d->inode, fname, d->filename[bit_pos],
> > > - le16_to_cpu(de->name_len)))
> > > - goto found;
> > > + if (de->hash_code == fname->hash) {
> > > + res = f2fs_match_name(d->inode, fname,
> > > d->filename[bit_pos],
> > > + le16_to_cpu(de->name_len));
> > > + if (res < 0)
> > > + return ERR_PTR(res);
> > > + else if (res)
> > > + goto found;
> > > + }
> >
> > Overly long line here. Also 'else if' is unnecessary, just use 'if'.
> >
> > - Eric
> The 0 case is important, since that reflects that the name was not found.
I meant doing the following:
if (res < 0)
return ERR_PTR(res);
if (res)
goto found;
It doesn't really matter, but usually kernel code doesn't use 'else' after an
early return.
- Eric
Re: workqueue: Only kick a worker after thawed or for an unbound workqueue
On 2020/11/18 12:06, Lai Jiangshan wrote:
> On Tue, Nov 17, 2020 at 3:33 PM Yunfeng Ye wrote:
>>
>> In realtime scenario, We do not want to have interference on the
>> isolated cpu cores. but when invoking alloc_workqueue() for percpu wq
>> on the housekeeping cpu, it kick a kworker on the isolated cpu.
>>
>> alloc_workqueue
>> pwq_adjust_max_active
>> wake_up_worker
>>
>> The comment in pwq_adjust_max_active() said:
>> "Need to kick a worker after thawed or an unbound wq's
>>max_active is bumped"
>>
>> So it is unnecessary to kick a kworker for percpu wq's when
>> alloc_workqueue. this patch only kick a worker after thawed or for an
>> unbound workqueue.
>>
>> Signed-off-by: Yunfeng Ye
>> ---
>> kernel/workqueue.c | 18 +-
>> 1 file changed, 13 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>> index c41c3c17b86a..80f7bbd4889f 100644
>> --- a/kernel/workqueue.c
>> +++ b/kernel/workqueue.c
>> @@ -3696,14 +3696,16 @@ static void pwq_unbound_release_workfn(struct
>> work_struct *work)
>> }
>>
>> /**
>> - * pwq_adjust_max_active - update a pwq's max_active to the current setting
>> + * pwq_adjust_max_active_and_kick - update a pwq's max_active to the
>> current setting
>> * @pwq: target pool_workqueue
>> + * @force_kick: force to kick a worker
>> *
>> * If @pwq isn't freezing, set @pwq->max_active to the associated
>> * workqueue's saved_max_active and activate delayed work items
>> * accordingly. If @pwq is freezing, clear @pwq->max_active to zero.
>> */
>> -static void pwq_adjust_max_active(struct pool_workqueue *pwq)
>> +static void pwq_adjust_max_active_and_kick(struct pool_workqueue *pwq,
>> + bool force_kick)
>> {
>> struct workqueue_struct *wq = pwq->wq;
>> bool freezable = wq->flags & WQ_FREEZABLE;
>> @@ -3733,9 +3735,10 @@ static void pwq_adjust_max_active(struct
>> pool_workqueue *pwq)
>>
>> /*
>> * Need to kick a worker after thawed or an unbound wq's
>> -* max_active is bumped. It's a slow path. Do it always.
>> +* max_active is bumped.
>
>
> Hello
>
> Thanks for reporting the problem.
>
> But I don't like to add an argument. The waking up is called
> always just because it was considered no harm and it is slow
> path. But it can still be possible to detect if the waking up
> is really needed based on the actual activation of delayed works.
>
> The previous lines are:
>
> while (!list_empty(>delayed_works) &&
>pwq->nr_active < pwq->max_active)
> pwq_activate_first_delayed(pwq);
>
> And you can record the old pwq->nr_active before these lines:
>
> int old_nr_active = pwq->nr_active;
>
> while (!list_empty(>delayed_works) &&
>pwq->nr_active < pwq->max_active)
> pwq_activate_first_delayed(pwq);
>
> /* please add more comments here, see 951a078a5 */
> if (old_nr_active < pwq->nr_active) {
> if (!old_nr_active || (wq->flags & WQ_UNBOUND))
> wake_up_worker(pwq->pool);
> }
>
Ok, I will send a patch v2.
Thanks.
>
> Thanks for your work.
> Lai.
>
>> */
>> - wake_up_worker(pwq->pool);
>> + if (force_kick || (wq->flags & WQ_UNBOUND))
>> + wake_up_worker(pwq->pool);
>> } else {
>> pwq->max_active = 0;
>> }
>> @@ -3743,6 +3746,11 @@ static void pwq_adjust_max_active(struct
>> pool_workqueue *pwq)
>> raw_spin_unlock_irqrestore(>pool->lock, flags);
>> }
>>
>> +static void pwq_adjust_max_active(struct pool_workqueue *pwq)
>> +{
>> + pwq_adjust_max_active_and_kick(pwq, false);
>> +}
>> +
>> /* initialize newly alloced @pwq which is associated with @wq and @pool */
>> static void init_pwq(struct pool_workqueue *pwq, struct workqueue_struct
>> *wq,
>> struct worker_pool *pool)
>> @@ -5252,7 +5260,7 @@ void thaw_workqueues(void)
>> list_for_each_entry(wq, , list) {
>> mutex_lock(>mutex);
>> for_each_pwq(pwq, wq)
>> - pwq_adjust_max_active(pwq);
>> + pwq_adjust_max_active_and_kick(pwq, true);
>> mutex_unlock(>mutex);
>> }
>>
>> --
>> 2.18.4
> .
>
Re: [PATCH 2/2] fpga: dfl: look for vendor specific capability
On Tue, Nov 17, 2020 at 11:41:32AM -0800, matthew.gerl...@linux.intel.com wrote:
>
>
> On Tue, 17 Nov 2020, Xu Yilun wrote:
>
> >On Mon, Nov 16, 2020 at 05:25:52PM -0800, matthew.gerl...@linux.intel.com
> >wrote:
> >>From: Matthew Gerlach
> >>
> >>A DFL may not begin at offset 0 of BAR 0. A PCIe vendor
> >>specific capability can be used to specify the start of a
> >>number of DFLs.
> >>
> >>Signed-off-by: Matthew Gerlach
> >>---
> >> Documentation/fpga/dfl.rst | 10 +
> >> drivers/fpga/dfl-pci.c | 88 +-
> >> 2 files changed, 97 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
> >>index 0404fe6ffc74..c81ceb1e79e2 100644
> >>--- a/Documentation/fpga/dfl.rst
> >>+++ b/Documentation/fpga/dfl.rst
> >>@@ -501,6 +501,16 @@ Developer only needs to provide a sub feature driver
> >>with matched feature id.
> >> FME Partial Reconfiguration Sub Feature driver (see
> >> drivers/fpga/dfl-fme-pr.c)
> >> could be a reference.
> >>
> >>+Location of DFLs on PCI bus
> >>+===
> >>+The start of the DFL is assumed to be offset 0 of bar 0.
> >>+Alternatively, a vendor specific capability structure can be used to
> >>+specify the location of one or more DFLs. Intel has reserved the
> >>+vendor specific id of 0x43 for this purpose. The vendor specific
> >>+data begins with a 4 byte count of the number of DFLs followed 4 byte
> >>+Offset/BIR fields for each DFL. Bits 2:0 of Offset/BIR field indicates
> >>+the BAR, and bits 31:3 form the 8 byte aligned offset where bits 2:0 are
> >>+zero.
> >>
> >> Open discussion
> >> ===
> >>diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c
> >>index b1b157b41942..5418e8bf2496 100644
> >>--- a/drivers/fpga/dfl-pci.c
> >>+++ b/drivers/fpga/dfl-pci.c
> >>@@ -27,6 +27,13 @@
> >> #define DRV_VERSION"0.8"
> >> #define DRV_NAME "dfl-pci"
> >>
> >>+#define PCI_VNDR_ID_DFLS 0x43
> >>+
> >>+#define PCI_VNDR_DFLS_CNT_OFFSET 8
> >>+#define PCI_VNDR_DFLS_RES_OFFSET 0x0c
> >>+
> >>+#define PCI_VND_DFLS_RES_BAR_MASK 0x7
> >
> >We could define the mask by GENMASK().
> >
> >Also another macro PCI_VND_DFLS_RES_OFFSET_MASK is needed.
>
> I will use GENMASK and and add PCI_VND_DFLS_RES_OFFSET_MASK in v2.
> >
> >>+
> >> struct cci_drvdata {
> >>struct dfl_fpga_cdev *cdev; /* container device */
> >> };
> >>@@ -119,6 +126,82 @@ static int *cci_pci_create_irq_table(struct pci_dev
> >>*pcidev, unsigned int nvec)
> >>return table;
> >> }
> >>
> >>+static int find_dfl_in_cfg(struct pci_dev *pcidev,
> >>+ struct dfl_fpga_enum_info *info)
> >>+{
> >>+ u32 bar, offset, vndr_hdr, dfl_cnt, dfl_res;
> >>+ int dfl_res_off, i, voff = 0;
> >>+ resource_size_t start, len;
> >>+
> >>+ while ((voff = pci_find_next_ext_capability(pcidev, voff,
> >>PCI_EXT_CAP_ID_VNDR))) {
> >>+
> >>+ pci_read_config_dword(pcidev, voff + PCI_VNDR_HEADER,
> >>_hdr);
> >>+
> >>+ dev_dbg(>dev,
> >>+ "vendor-specific capability id 0x%x, rev 0x%x len
> >>0x%x\n",
> >>+ PCI_VNDR_HEADER_ID(vndr_hdr),
> >>+ PCI_VNDR_HEADER_REV(vndr_hdr),
> >>+ PCI_VNDR_HEADER_LEN(vndr_hdr));
> >>+
> >>+ if (PCI_VNDR_HEADER_ID(vndr_hdr) == PCI_VNDR_ID_DFLS)
> >>+ break;
> >>+ }
> >>+
> >>+ if (!voff) {
> >>+ dev_dbg(>dev, "%s no VSEC found\n", __func__);
> >>+ return -ENODEV;
> >>+ }
> >>+
> >>+ pci_read_config_dword(pcidev, voff + PCI_VNDR_DFLS_CNT_OFFSET,
> >>_cnt);
> >>+ dev_info(>dev, "dfl_cnt %d\n", dfl_cnt);
> >
> >dev_dbg() is better?
>
> I will change to dev_dbg in v2.
>
> >
> >>+ for (i = 0; i < dfl_cnt; i++) {
> >>+ dfl_res_off = voff + PCI_VNDR_DFLS_RES_OFFSET +
> >>+ (i * sizeof(dfl_res));
> >>+ pci_read_config_dword(pcidev, dfl_res_off, _res);
> >>+
> >>+ dev_dbg(>dev, "dfl_res 0x%x\n", dfl_res);
> >>+
> >>+ bar = dfl_res & PCI_VND_DFLS_RES_BAR_MASK;
> >
> >FIELD_GET is better?
>
> I think & will the GENMASK will be better because it will be
> symetrical to the & below for the offset.
Fine.
>
> >
> >>+
> >>+ if (bar >= PCI_STD_NUM_BARS) {
> >>+ dev_err(>dev, "%s bad bar number %d\n",
> >>+ __func__, bar);
> >>+ return -EINVAL;
> >>+ }
> >>+
> >>+ len = pci_resource_len(pcidev, bar);
> >>+
> >>+ if (len == 0) {
> >>+ dev_err(>dev, "%s unmapped bar number %d\n",
> >>+ __func__, bar);
> >>+ return -EINVAL;
> >>+ }
> >>+
> >>+ offset = dfl_res & ~PCI_VND_DFLS_RES_BAR_MASK;
> >
> >ditto
> We don't want to use FIELD_GET here because we don't the shifting.
That's correct.
>
> >
> >>+
> >>+ if (offset >= len) {
> >>+
[PATCH] mmc: sdhci-of-arasan: Add pinctrl support to the driver
Driver should be able to handle optional pinctrl setting.
Signed-off-by: Michal Simek
Signed-off-by: Manish Narani
---
drivers/mmc/host/sdhci-of-arasan.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 829ccef87426..f788cc9d5914 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "cqhci.h"
#include "sdhci-pltfm.h"
@@ -135,6 +136,8 @@ struct sdhci_arasan_clk_data {
* @clk_ops: Struct for the Arasan Controller Clock Operations.
* @soc_ctl_base: Pointer to regmap for syscon for soc_ctl registers.
* @soc_ctl_map: Map to get offsets into soc_ctl registers.
+ * @pinctrl: Per-device pin control state holder.
+ * @pins_default: Pinctrl state for a device.
* @quirks:Arasan deviations from spec.
*/
struct sdhci_arasan_data {
@@ -149,6 +152,8 @@ struct sdhci_arasan_data {
struct regmap *soc_ctl_base;
const struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pins_default;
unsigned intquirks;
/* Controller does not have CD wired and will not function normally without */
@@ -1619,6 +1624,25 @@ static int sdhci_arasan_probe(struct platform_device
*pdev)
goto unreg_clk;
}
+ sdhci_arasan->pinctrl = devm_pinctrl_get(>dev);
+ if (!IS_ERR(sdhci_arasan->pinctrl)) {
+ sdhci_arasan->pins_default =
+ pinctrl_lookup_state(sdhci_arasan->pinctrl,
+PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(sdhci_arasan->pins_default)) {
+ dev_err(>dev, "Missing default pinctrl config\n");
+ ret = PTR_ERR(sdhci_arasan->pins_default);
+ goto unreg_clk;
+ }
+
+ ret = pinctrl_select_state(sdhci_arasan->pinctrl,
+ sdhci_arasan->pins_default);
+ if (ret) {
+ dev_err(>dev, "could not select default state\n");
+ goto unreg_clk;
+ }
+ }
+
sdhci_arasan->phy = ERR_PTR(-ENODEV);
if (of_device_is_compatible(pdev->dev.of_node,
"arasan,sdhci-5.1")) {
--
2.17.1
Re: [PATCH v2 3/3] f2fs: Handle casefolding with Encryption
On Tue, Nov 17, 2020 at 10:50 AM Eric Biggers wrote:
>
>
> What is the assignment to dentry_page supposed to be accomplishing? It looks
> like it's meant to pass up errors from f2fs_find_target_dentry(), but it
> doesn't
> do that.
Woops. Fixed that for the next version.
>
> > @@ -222,14 +250,20 @@ static bool f2fs_match_ci_name(const struct inode
> > *dir, const struct qstr *name,
> >* fall back to treating them as opaque byte sequences.
> >*/
> > if (sb_has_strict_encoding(sb) || name->len != entry.len)
> > - return false;
> > - return !memcmp(name->name, entry.name, name->len);
> > + res = 0;
> > + else
> > + res = memcmp(name->name, entry.name, name->len) == 0;
> > + } else {
> > + /* utf8_strncasecmp_folded returns 0 on match */
> > + res = (res == 0);
> > }
>
> The following might be easier to understand:
>
> /*
> * In strict mode, ignore invalid names. In non-strict mode, fall
> back
> * to treating them as opaque byte sequences.
> */
> if (res < 0 && !sb_has_strict_encoding(sb)) {
> res = name->len == entry.len &&
> memcmp(name->name, entry.name, name->len) == 0;
> } else {
> /* utf8_strncasecmp_folded returns 0 on match */
> res = (res == 0);
> }
>
Thanks, that is a fair bit nicer.
> > @@ -273,10 +308,14 @@ struct f2fs_dir_entry *f2fs_find_target_dentry(const
> > struct f2fs_dentry_ptr *d,
> > continue;
> > }
> >
> > - if (de->hash_code == fname->hash &&
> > - f2fs_match_name(d->inode, fname, d->filename[bit_pos],
> > - le16_to_cpu(de->name_len)))
> > - goto found;
> > + if (de->hash_code == fname->hash) {
> > + res = f2fs_match_name(d->inode, fname,
> > d->filename[bit_pos],
> > + le16_to_cpu(de->name_len));
> > + if (res < 0)
> > + return ERR_PTR(res);
> > + else if (res)
> > + goto found;
> > + }
>
> Overly long line here. Also 'else if' is unnecessary, just use 'if'.
>
> - Eric
The 0 case is important, since that reflects that the name was not found.
-Daniel
Re: [PATCH v4 01/10] Add auxiliary bus support
On Tue, Nov 17, 2020 at 01:04:56PM -0800, Dan Williams wrote: > On Mon, Nov 16, 2020 at 11:02 PM Greg KH wrote: > > > > On Tue, Nov 17, 2020 at 07:30:00AM +0200, Leon Romanovsky wrote: > > > On Fri, Nov 13, 2020 at 08:18:50AM -0800, Dave Ertman wrote: > > > > Add support for the Auxiliary Bus, auxiliary_device and > > > > auxiliary_driver. > > > > It enables drivers to create an auxiliary_device and bind an > > > > auxiliary_driver to it. > > > > > > > > The bus supports probe/remove shutdown and suspend/resume callbacks. > > > > Each auxiliary_device has a unique string based id; driver binds to > > > > an auxiliary_device based on this id through the bus. > > > > > > > > Co-developed-by: Kiran Patil > > > > Signed-off-by: Kiran Patil > > > > Co-developed-by: Ranjani Sridharan > > > > Signed-off-by: Ranjani Sridharan > > > > Co-developed-by: Fred Oh > > > > Signed-off-by: Fred Oh > > > > Co-developed-by: Leon Romanovsky > > > > Signed-off-by: Leon Romanovsky > > > > Reviewed-by: Pierre-Louis Bossart > > > > Reviewed-by: Shiraz Saleem > > > > Reviewed-by: Parav Pandit > > > > Reviewed-by: Dan Williams > > > > Signed-off-by: Dave Ertman > > > > --- > > > > > > Greg, > > > > > > This horse was beaten to death, can we please progress with this patch? > > > Create special topic branch or ack so I'll prepare this branch. > > > > > > We are in -rc4 now and we (Mellanox) can't hold our submissions anymore. > > > My mlx5_core probe patches [1] were too intrusive and they are ready to > > > be merged, Parav's patches got positive review as well [2] and will be > > > taken next. > > > > > > We delayed and have in our internal queues the patches for VDPA, eswitch > > > and followup for mlx5_core probe rework, but trapped due to this AUX bus > > > patch. > > > > There are no deadlines for kernel patches here, sorry. Give me some > > time to properly review this, core kernel changes should not be rushed. > > > > Also, if you really want to blame someone for the delay, look at the > > patch submitters not the reviewers, as they are the ones that took a > > very long time with this over the lifecycle of this patchset, not me. I > > have provided many "instant" reviews of this patchset, and then months > > went by between updates from them. > > Please stop this finger pointing. It was already noted that the team, > out of abundance of caution / deference to the process, decided not to > push the patches while I was out on family leave. It's cruel to hold > that against them, and if anyone is to blame it's me for not > clarifying it was ok to proceed while I was out. I'm not blaming anyone, I'm just getting pissed when people are insisting that I do "quick reviews" for this patchset, which has been happening by different people since the very beginning of this whole feature, so I am trying to explain where others should be pointing their frustration at instead of me if they really want to do such a thing (hint, they shouldn't, but I wasn't explicit about that, sorry). Combine this with the long delays between my reviews and a new patchset submission, and on my end it's an extremely frustrating situation, which frankly, makes me want to review this thing even less and less as I know it's not going to be a fun or easy time when I do so. Everyone needs to remember that there are no deadlines here, and the people involved all have other things to work on at the same time, and that there are a lot of different subsystems and moving parts all involved. So someone is going to get grumpy about it, and right now, it seems to be me. I know I need to review this, and complaining that I haven't done so within 3 days of sending an updated patch set is not helping anyone. I'm going to try to carve out some time this week to review this properly. Hopefully there's no other major security "scares" popping up like there was the past few weeks to divert me from this... thanks, greg k-h
Re: WARNING: kernel/irq/chip.c:242 __irq_startup+0xa8/0xb0
On Tue, 13 Oct 2020 at 11:09, Naresh Kamboju wrote: > > On stable rc 5.8.15 the following kernel warning was noticed once > while boot and this is hard to reproduce. This is now reproduciable on arm64 NXP ls2088 device [ 19.980839] [ cut here ] [ 19.985468] WARNING: CPU: 1 PID: 441 at kernel/irq/chip.c:242 __irq_startup+0x9c/0xa8 [ 19.985472] Modules linked in: rfkill lm90 ina2xx crct10dif_ce qoriq_thermal fuse [ 20.000773] CPU: 1 PID: 441 Comm: (agetty) Not tainted 5.4.78-rc1 #2 [ 20.000775] Hardware name: Freescale Layerscape 2088A RDB Board (DT) [ 20.000779] pstate: 6085 (nZCv daIf -PAN -UAO) [ 20.018253] pc : __irq_startup+0x9c/0xa8 [ 20.018256] lr : irq_startup+0x64/0x130 [ 20.018259] sp : 80001122f8e0 [ 20.029303] x29: 80001122f8e0 x28: 0082c242d400 [ 20.029306] x27: dd0f47234768 x26: 00020902 [ 20.029309] x25: dd0f461a6f10 x24: dd0f461a6bc8 [ 20.029311] x23: x22: 0001 [ 20.029314] x21: 0001 x20: 0082c22f8780 [ 20.029316] x19: 0082c1060800 x18: 0001 [ 20.029318] x17: x16: 8000114a [ 20.029321] x15: x14: 0082c0e92f90 [ 20.071738] x13: 0082c0e93080 x12: 80001146 [ 20.071741] x11: dead0100 x10: 0040 [ 20.071743] x9 : dd0f47093ba8 x8 : dd0f47093ba0 [ 20.087653] x7 : 0082a2b0 x6 : dd0f47074958 [ 20.087655] x5 : dd0f47074000 x4 : 80001123 [ 20.087657] x3 : 0504 x2 : 0001 [ 20.103567] x1 : 03032004 x0 : 0082c1060858 [ 20.103570] Call trace: [ 20.103573] __irq_startup+0x9c/0xa8 [ 20.103577] irq_startup+0x64/0x130 [ 20.118359] __enable_irq+0x7c/0x88 [ 20.118362] enable_irq+0x54/0xa8 [ 20.118367] serial8250_do_startup+0x658/0x718 [ 20.118371] serial8250_startup+0x38/0x48 [ 20.133589] uart_startup.part.0+0x12c/0x2b8 [ 20.133592] uart_port_activate+0x64/0x98 [ 20.133595] tty_port_open+0x94/0x200 [ 20.133599] uart_open+0x2c/0x40 [ 20.148730] tty_open+0x108/0x438 [ 20.148734] chrdev_open+0xa8/0x1a0 [ 20.148737] do_dentry_open+0x118/0x3b8 [ 20.159348] vfs_open+0x38/0x48 [ 20.159350] path_openat+0x4c8/0x1290 [ 20.159353] do_filp_open+0x84/0x108 [ 20.159357] do_sys_open+0x180/0x228 [ 20.173271] __arm64_sys_openat+0x2c/0x38 [ 20.173274] el0_svc_handler+0x88/0x1c8 [ 20.173278] el0_svc+0x8/0x1bc [ 20.184148] ---[ end trace 736144791ac25035 ]--- ref: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.77-152-ga3746663c347/testrun/3452654/suite/linux-log-parser/test/check-kernel-warning-139363/log
Re: [PATCH v11 14/16] PCI/AER: Add pcie_walk_rcec() to RCEC AER handling
On 11/17/20 11:19 AM, Sean V Kelley wrote:
Root Complex Event Collectors (RCEC) appear as peers to Root Ports and also
have the AER capability. In addition, actions need to be taken for
associated RCiEPs. In such cases the RCECs will need to be walked in order
to find and act upon their respective RCiEPs.
Extend the existing ability to link the RCECs with a walking function
pcie_walk_rcec(). Add RCEC support to the current AER service driver and
attach the AER service driver to the RCEC device.
Reviewed-by: Kuppuswamy Sathyanarayanan
[bhelgaas: kernel doc, whitespace cleanup]
Co-developed-by: Qiuxu Zhuo
Link:
https://lore.kernel.org/r/20201002184735.1229220-13-seanvk@oregontracks.org
Signed-off-by: Qiuxu Zhuo
Signed-off-by: Sean V Kelley
Signed-off-by: Bjorn Helgaas
Reviewed-by: Jonathan Cameron
---
drivers/pci/pci.h | 6 ++
drivers/pci/pcie/aer.c | 29 ++---
drivers/pci/pcie/rcec.c | 37 +
3 files changed, 65 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index ae2ee4df1cff..e988cc930d0b 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -473,10 +473,16 @@ static inline void pci_dpc_init(struct pci_dev *pdev) {}
void pci_rcec_init(struct pci_dev *dev);
void pci_rcec_exit(struct pci_dev *dev);
void pcie_link_rcec(struct pci_dev *rcec);
+void pcie_walk_rcec(struct pci_dev *rcec,
+ int (*cb)(struct pci_dev *, void *),
+ void *userdata);
#else
static inline void pci_rcec_init(struct pci_dev *dev) {}
static inline void pci_rcec_exit(struct pci_dev *dev) {}
static inline void pcie_link_rcec(struct pci_dev *rcec) {}
+static inline void pcie_walk_rcec(struct pci_dev *rcec,
+ int (*cb)(struct pci_dev *, void *),
+ void *userdata) {}
#endif
#ifdef CONFIG_PCI_ATS
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 2869212af8b4..72723a1b67af 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -300,7 +300,8 @@ int pci_aer_raw_clear_status(struct pci_dev *dev)
return -EIO;
port_type = pci_pcie_type(dev);
- if (port_type == PCI_EXP_TYPE_ROOT_PORT) {
+ if (port_type == PCI_EXP_TYPE_ROOT_PORT ||
+ port_type == PCI_EXP_TYPE_RC_EC) {
pci_read_config_dword(dev, aer + PCI_ERR_ROOT_STATUS, );
pci_write_config_dword(dev, aer + PCI_ERR_ROOT_STATUS, status);
}
@@ -595,7 +596,8 @@ static umode_t aer_stats_attrs_are_visible(struct kobject
*kobj,
if ((a == _attr_aer_rootport_total_err_cor.attr ||
a == _attr_aer_rootport_total_err_fatal.attr ||
a == _attr_aer_rootport_total_err_nonfatal.attr) &&
- pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT)
+ ((pci_pcie_type(pdev) != PCI_EXP_TYPE_ROOT_PORT) &&
+(pci_pcie_type(pdev) != PCI_EXP_TYPE_RC_EC)))
return 0;
return a->mode;
@@ -916,7 +918,10 @@ static bool find_source_device(struct pci_dev *parent,
if (result)
return true;
- pci_walk_bus(parent->subordinate, find_device_iter, e_info);
+ if (pci_pcie_type(parent) == PCI_EXP_TYPE_RC_EC)
+ pcie_walk_rcec(parent, find_device_iter, e_info);
+ else
+ pci_walk_bus(parent->subordinate, find_device_iter, e_info);
if (!e_info->error_dev_num) {
pci_info(parent, "can't find device of ID%04x\n", e_info->id);
@@ -1053,6 +1058,7 @@ int aer_get_device_error_info(struct pci_dev *dev, struct
aer_err_info *info)
if (!(info->status & ~info->mask))
return 0;
} else if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT ||
+ pci_pcie_type(dev) == PCI_EXP_TYPE_RC_EC ||
pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
info->severity == AER_NONFATAL) {
@@ -1205,6 +1211,7 @@ static int set_device_error_reporting(struct pci_dev *dev, void *data)
int type = pci_pcie_type(dev);
if ((type == PCI_EXP_TYPE_ROOT_PORT) ||
+ (type == PCI_EXP_TYPE_RC_EC) ||
(type == PCI_EXP_TYPE_UPSTREAM) ||
(type == PCI_EXP_TYPE_DOWNSTREAM)) {
if (enable)
@@ -1229,9 +1236,12 @@ static void
set_downstream_devices_error_reporting(struct pci_dev *dev,
{
set_device_error_reporting(dev, );
- if (!dev->subordinate)
- return;
- pci_walk_bus(dev->subordinate, set_device_error_reporting, );
+ if (pci_pcie_type(dev) == PCI_EXP_TYPE_RC_EC)
+ pcie_walk_rcec(dev, set_device_error_reporting, );
+ else if (dev->subordinate)
+ pci_walk_bus(dev->subordinate, set_device_error_reporting,
+);
+
}
/**
@@ -1329,6 +1339,11 @@ static int aer_probe(struct pcie_device *dev)
struct
Re: [PATCH v11 15/16] PCI/PME: Add pcie_walk_rcec() to RCEC PME handling
On 11/17/20 11:19 AM, Sean V Kelley wrote:
Root Complex Event Collectors (RCEC) appear as peers of Root Ports and also
have the PME capability. As with AER, there is a need to be able to walk
the RCiEPs associated with their RCEC for purposes of acting upon them with
callbacks.
Add RCEC support through the use of pcie_walk_rcec() to the current PME
service driver and attach the PME service driver to the RCEC device.
Co-developed-by: Qiuxu Zhuo
Link:
https://lore.kernel.org/r/20201002184735.1229220-14-seanvk@oregontracks.org
Signed-off-by: Qiuxu Zhuo
Signed-off-by: Sean V Kelley
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pcie/pme.c | 15 +++
drivers/pci/pcie/portdrv_core.c | 9 +++--
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
index 6a32970bb731..87799166c96a 100644
--- a/drivers/pci/pcie/pme.c
+++ b/drivers/pci/pcie/pme.c
@@ -310,7 +310,10 @@ static int pcie_pme_can_wakeup(struct pci_dev *dev, void
*ign)
static void pcie_pme_mark_devices(struct pci_dev *port)
{
pcie_pme_can_wakeup(port, NULL);
- if (port->subordinate)
+
+ if (pci_pcie_type(port) == PCI_EXP_TYPE_RC_EC)
+ pcie_walk_rcec(port, pcie_pme_can_wakeup, NULL);
+ else if (port->subordinate)
pci_walk_bus(port->subordinate, pcie_pme_can_wakeup, NULL);
}
@@ -320,10 +323,15 @@ static void pcie_pme_mark_devices(struct pci_dev *port)
*/
static int pcie_pme_probe(struct pcie_device *srv)
{
- struct pci_dev *port;
+ struct pci_dev *port = srv->port;
struct pcie_pme_service_data *data;
int ret;
+ /* Limit to Root Ports or Root Complex Event Collectors */
+ if ((pci_pcie_type(port) != PCI_EXP_TYPE_RC_EC) &&
+ (pci_pcie_type(port) != PCI_EXP_TYPE_ROOT_PORT))
may be you can save the value pci_pcie_type(port)?
+ return -ENODEV;
+
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
@@ -333,7 +341,6 @@ static int pcie_pme_probe(struct pcie_device *srv)
data->srv = srv;
set_service_data(srv, data);
- port = srv->port;
pcie_pme_interrupt_enable(port, false);
pcie_clear_root_pme_status(port);
@@ -445,7 +452,7 @@ static void pcie_pme_remove(struct pcie_device *srv)
static struct pcie_port_service_driver pcie_pme_driver = {
.name = "pcie_pme",
- .port_type = PCI_EXP_TYPE_ROOT_PORT,
+ .port_type = PCIE_ANY_PORT,
.service= PCIE_PORT_SERVICE_PME,
.probe = pcie_pme_probe,
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 50a9522ab07d..e1fed6649c41 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -233,12 +233,9 @@ static int get_port_device_capability(struct pci_dev *dev)
}
#endif
- /*
-* Root ports are capable of generating PME too. Root Complex
-* Event Collectors can also generate PMEs, but we don't handle
-* those yet.
-*/
- if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT &&
+ /* Root Ports and Root Complex Event Collectors may generate PMEs */
+ if ((pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT ||
+pci_pcie_type(dev) == PCI_EXP_TYPE_RC_EC) &&
(pcie_ports_native || host->native_pme)) {
services |= PCIE_PORT_SERVICE_PME;
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
drivers/remoteproc/mtk_scp.c:306:39: sparse: sparse: incorrect type in argument 2 (different address spaces)
Hi Bjorn, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0fa8ee0d9ab95c9350b8b84574824d9a384a9f7d commit: 141bc97c1bfe31397b2a12e5676d0c2692c8e07e remoteproc/mediatek: Remove non-standard dsb() date: 5 weeks ago config: mips-randconfig-s032-20201117 (attached as .config) compiler: mips-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-107-gaf3512a6-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141bc97c1bfe31397b2a12e5676d0c2692c8e07e git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 141bc97c1bfe31397b2a12e5676d0c2692c8e07e # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" command-line: note: in included file: builtin:1:9: sparse: sparse: preprocessor token __ATOMIC_ACQUIRE redefined builtin:0:0: sparse: this was the original definition builtin:1:9: sparse: sparse: preprocessor token __ATOMIC_SEQ_CST redefined builtin:0:0: sparse: this was the original definition builtin:1:9: sparse: sparse: preprocessor token __ATOMIC_ACQ_REL redefined builtin:0:0: sparse: this was the original definition builtin:1:9: sparse: sparse: preprocessor token __ATOMIC_RELEASE redefined builtin:0:0: sparse: this was the original definition >> drivers/remoteproc/mtk_scp.c:306:39: sparse: sparse: incorrect type in >> argument 2 (different address spaces) @@ expected void volatile >> [noderef] __iomem *mem @@ got void *addr @@ >> drivers/remoteproc/mtk_scp.c:306:39: sparse: expected void volatile >> [noderef] __iomem *mem drivers/remoteproc/mtk_scp.c:306:39: sparse: got void *addr drivers/remoteproc/mtk_scp.c:307:19: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *mem @@ got void *addr @@ drivers/remoteproc/mtk_scp.c:307:19: sparse: expected void volatile [noderef] __iomem *mem drivers/remoteproc/mtk_scp.c:307:19: sparse: got void *addr drivers/remoteproc/mtk_scp.c:314:19: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *mem @@ got void *addr @@ drivers/remoteproc/mtk_scp.c:314:19: sparse: expected void volatile [noderef] __iomem *mem drivers/remoteproc/mtk_scp.c:314:19: sparse: got void *addr drivers/remoteproc/mtk_scp.c:316:39: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *mem @@ got void *addr @@ drivers/remoteproc/mtk_scp.c:316:39: sparse: expected void volatile [noderef] __iomem *mem drivers/remoteproc/mtk_scp.c:316:39: sparse: got void *addr drivers/remoteproc/mtk_scp.c:327:44: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void *addr @@ got void [noderef] __iomem * @@ drivers/remoteproc/mtk_scp.c:327:44: sparse: expected void *addr drivers/remoteproc/mtk_scp.c:327:44: sparse: got void [noderef] __iomem * drivers/remoteproc/mtk_scp.c:328:44: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void *addr @@ got void [noderef] __iomem * @@ drivers/remoteproc/mtk_scp.c:328:44: sparse: expected void *addr drivers/remoteproc/mtk_scp.c:328:44: sparse: got void [noderef] __iomem * drivers/remoteproc/mtk_scp.c:329:44: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void *addr @@ got void [noderef] __iomem * @@ drivers/remoteproc/mtk_scp.c:329:44: sparse: expected void *addr drivers/remoteproc/mtk_scp.c:329:44: sparse: got void [noderef] __iomem * drivers/remoteproc/mtk_scp.c:330:44: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void *addr @@ got void [noderef] __iomem * @@ drivers/remoteproc/mtk_scp.c:330:44: sparse: expected void *addr drivers/remoteproc/mtk_scp.c:330:44: sparse: got void [noderef] __iomem * drivers/remoteproc/mtk_scp.c:331:44: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void *addr @@ got void [noderef] __iomem * @@ drivers/remoteproc/mtk_scp.c:331:44: sparse: expected void *addr drivers/remoteproc/mtk_scp.c:331:44: spars
Re: [PATCH v11 16/16] PCI/AER: Add RCEC AER error injection support
On 11/17/20 11:19 AM, Sean V Kelley wrote:
From: Qiuxu Zhuo
Root Complex Event Collectors (RCEC) appear as peers to Root Ports and may
also have the AER capability.
Add RCEC support to the AER error injection driver.
Reviewed-by: Kuppuswamy Sathyanarayanan
Co-developed-by: Sean V Kelley
Link:
https://lore.kernel.org/r/20201002184735.1229220-15-seanvk@oregontracks.org
Signed-off-by: Qiuxu Zhuo
Signed-off-by: Sean V Kelley
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pcie/aer_inject.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/aer_inject.c b/drivers/pci/pcie/aer_inject.c
index c2cbf425afc5..767f8859b99b 100644
--- a/drivers/pci/pcie/aer_inject.c
+++ b/drivers/pci/pcie/aer_inject.c
@@ -333,8 +333,11 @@ static int aer_inject(struct aer_error_inj *einj)
if (!dev)
return -ENODEV;
rpdev = pcie_find_root_port(dev);
+ /* If Root Port not found, try to find an RCEC */
+ if (!rpdev)
+ rpdev = dev->rcec;
if (!rpdev) {
- pci_err(dev, "Root port not found\n");
+ pci_err(dev, "Neither Root Port nor RCEC found\n");
ret = -ENODEV;
goto out_put;
}
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Re: [RFC PATCH 5/5] locking/rwsem: Remove reader optimistic spinning
On Tue, 17 Nov 2020, Waiman Long wrote: The column "CS Load" represents the number of pause instructions issued in the locking critical section. A CS load of 1 is extremely short and is not likey in real situations. A load of 20 (moderate) and 100 (long) are more realistic. It can be seen that the previous patches in this series have reduced performance in general except in highly contended cases with moderate or long critical sections that performance improves a bit. This change is mostly caused by the "Prevent potential lock starvation" patch that reduce reader optimistic spinning and hence reduce reader fragmentation. The patch that further limit reader optimistic spinning doesn't seem to have too much impact on overall performance as shown in the benchmark data. The patch that disables reader optimistic spinning shows reduced performance at lightly loaded cases, but comparable or slightly better performance on with heavier contention. I'm not overly worried about the lightly loaded cases here as the users (mostly thinking mmap_sem) most likely won't care for real workloads, not, ie: will-it-scale type things. So at SUSE we also ran into this very same problem with reader optimistic spinning and considering the fragmentation went with disabling it, much like this patch - but without the reader optimistic lock stealing bits you have. So far nothing has really shown to fall out in our performance automation. And per your data a single reader spinner does not seem to be worth the added complexity of keeping reader spinning vs ripping it out. Thanks, Davidlohr
Re: [PATCH 4.19 000/264] 4.19.153-rc1 review
On Tue, Nov 17, 2020 at 08:36:21PM +0100, Salvatore Bonaccorso wrote:
> Hi Guenter,
>
> On Sat, Nov 14, 2020 at 05:27:41AM -0800, Guenter Roeck wrote:
> > On 11/14/20 12:35 AM, Salvatore Bonaccorso wrote:
> > > Hi Guenter,
> > >
> > > On Sat, Oct 31, 2020 at 07:31:32AM -0700, Guenter Roeck wrote:
> > >> On 10/31/20 2:45 AM, Salvatore Bonaccorso wrote:
> > >>> Hi Greg,
> > >>>
> > >>> On Wed, Oct 28, 2020 at 12:56:19PM -0700, Guenter Roeck wrote:
> > Retry.
> >
> > On Wed, Oct 28, 2020 at 10:10:35AM -0700, Guenter Roeck wrote:
> > > On Tue, Oct 27, 2020 at 02:50:58PM +0100, Greg Kroah-Hartman wrote:
> > >> This is the start of the stable review cycle for the 4.19.153
> > >> release.
> > >> There are 264 patches in this series, all will be posted as a
> > >> response
> > >> to this one. If anyone has any issues with these being applied,
> > >> please
> > >> let me know.
> > >>
> > >> Responses should be made by Thu, 29 Oct 2020 13:53:47 +.
> > >> Anything received after that time might be too late.
> > >>
> > >
> > > Build results:
> > > total: 155 pass: 152 fail: 3
> > > Failed builds:
> > > i386:tools/perf
> > > powerpc:ppc6xx_defconfig
> > > x86_64:tools/perf
> > > Qemu test results:
> > > total: 417 pass: 417 fail: 0
> > >
> > > perf failures are as usual. powerpc:
> > >>>
> > >>> Regarding the perf failures, do you plan to revert b801d568c7d8 ("perf
> > >>> cs-etm: Move definition of 'traceid_list' global variable from header
> > >>> file") included in 4.19.152 or is a bugfix underway?
> > >>>
> > >>
> > >> The problem is:
> > >>
> > >> In file included from util/evlist.h:15:0,
> > >> from util/evsel.c:30:
> > >> util/evsel.c: In function ‘perf_evsel__exit’:
> > >> util/util.h:25:28: error: passing argument 1 of ‘free’ discards ‘const’
> > >> qualifier from pointer target type
> > >> /usr/include/stdlib.h:563:13: note: expected ‘void *’ but argument is of
> > >> type ‘const char *’
> > >> extern void free (void *__ptr) __THROW;
> > >>
> > >> This is seen with older versions of gcc (6.5.0 in my case). I have no
> > >> idea why
> > >> newer versions of gcc/glibc accept this (afaics free() still expects a
> > >> char *,
> > >> not a const char *). The underlying problem is that pmu_name should not
> > >> be
> > >> declared const char *, but char *, since it is allocated. The upstream
> > >> version
> > >> of perf no longer uses the same definition of zfree(). It was changed
> > >> from
> > >> #define zfree(ptr) ({ free(*ptr); *ptr = NULL; })
> > >> to
> > >> #define zfree(ptr) __zfree((void **)(ptr))
> > >> which does the necessary typecast. The fix would be to either change the
> > >> definition
> > >> of zfree to add the typecast, or to change the definition of pmu_name to
> > >> drop the const.
> > >> Both would only apply to v4.19.y. I don't know if either would be
> > >> acceptable.
> > >>
> > >> Either case, reverting b801d568c7d8 won't solve that problem.
> > >
> > > Are we talking about the same problem though? With v4.19.157 and
> > > building with "gcc (Debian 8.3.0-6) 8.3.0", with an unpatched source:
> > >
> > > $ LC_ALL=C.UTF-8 ARCH=x86 make perf
> > > mkdir -p .
> > > make --no-print-directory -C perf O= subdir=
> > > BUILD: Doing 'make -j2' parallel build
> > > Warning: Kernel ABI header at 'tools/include/uapi/drm/i915_drm.h' differs
> > > from latest version at 'include/uapi/drm/i915_drm.h'
> > > diff -u tools/include/uapi/drm/i915_drm.h include/uapi/drm/i915_drm.h
> > > Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs
> > > from latest version at 'include/uapi/linux/kvm.h'
> > > diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h
> > > Warning: Kernel ABI header at 'tools/include/uapi/linux/perf_event.h'
> > > differs from latest version at 'include/uapi/linux/perf_event.h'
> > > diff -u tools/include/uapi/linux/perf_event.h
> > > include/uapi/linux/perf_event.h
> > > Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h'
> > > differs from latest version at 'arch/x86/include/asm/cpufeatures.h'
> > > diff -u tools/arch/x86/include/asm/cpufeatures.h
> > > arch/x86/include/asm/cpufeatures.h
> > > Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/kvm.h'
> > > differs from latest version at 'arch/x86/include/uapi/asm/kvm.h'
> > > diff -u tools/arch/x86/include/uapi/asm/kvm.h
> > > arch/x86/include/uapi/asm/kvm.h
> > > Warning: Kernel ABI header at 'tools/arch/x86/lib/memcpy_64.S' differs
> > > from latest version at 'arch/x86/lib/memcpy_64.S'
> > > diff -u tools/arch/x86/lib/memcpy_64.S arch/x86/lib/memcpy_64.S
> > > Warning: Kernel ABI header at 'tools/include/uapi/linux/mman.h' differs
> > > from latest version at 'include/uapi/linux/mman.h'
> > > diff -u tools/include/uapi/linux/mman.h include/uapi/linux/mman.h
> > >
> > >
Re: [PATCHv1 3/4] dt-bindings: fpga: add authenticate-fpga-config property
On Tue, Nov 17, 2020 at 09:39:55AM -0600, Richard Gong wrote: > > > On 11/16/20 8:24 PM, Xu Yilun wrote: > >On Mon, Nov 16, 2020 at 08:14:52AM -0600, Richard Gong wrote: > >> > >>Hi Yilun, > >> > >>On 11/15/20 8:47 PM, Xu Yilun wrote: > >>>On Sun, Nov 15, 2020 at 11:21:06AM -0800, Moritz Fischer wrote: > Hi Richard, > > On Thu, Nov 12, 2020 at 12:06:42PM -0600, richard.g...@linux.intel.com > wrote: > >From: Richard Gong > > > >Add authenticate-fpga-config property for FPGA bitstream authentication. > > > >Signed-off-by: Richard Gong > >--- > > Documentation/devicetree/bindings/fpga/fpga-region.txt | 1 + > > 1 file changed, 1 insertion(+) > > > >diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt > >b/Documentation/devicetree/bindings/fpga/fpga-region.txt > >index e811cf8..7a512bc 100644 > >--- a/Documentation/devicetree/bindings/fpga/fpga-region.txt > >+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt > >@@ -187,6 +187,7 @@ Optional properties: > > - external-fpga-config : boolean, set if the FPGA has already been > > configured > > prior to OS boot up. > > - encrypted-fpga-config : boolean, set if the bitstream is encrypted > >+- authenticate-fpga-config : boolean, set if do bitstream authentication > It is unclear to me from the description whether this entails > authentication + reconfiguration or just authentication. > > If the latter is the case this should probably be described as such. > >>> > >>>If it is just authentication, do we still need to disable bridges in > >>>fpga_region_program_fpga? > >>> > >> > >>Yes. > >> > >>Except for the actual configuration of the device, the authentication > >>feature is the same as FPGA configuration. > > > >FPGA Bridges gate bus signals between a host and FPGA. So the FPGA > >region could not be accessed by host when doing configuration. But for > >this authentication, we are just writing the flash, we don't actually > >touch the FPGA soft logic. The host should still be able to operate on > >the old logic before reboot, is it? > > > Yes, it's feasible in theory but doesn't make much sense in practice. I > prefer to keep fpga_region_program_fpga() unchanged. I'm thinking of the case of inband reprograming, that the QSPI flash controller itself is embedded in FPGA soft logic, then maybe host still need to access FPGA on authentication. Thanks, Yilun > >> > >>>I'm wondering if the FPGA functionalities could still be working when > >>>the authenticating is ongoing, or when the authenticating is failed. > >>> > >> > >> > >> > >>>Thanks, > >>>Yilun > >>> > > > - region-unfreeze-timeout-us : The maximum time in microseconds to > > wait for > > bridges to successfully become enabled after the region has been > > programmed. > >-- > >2.7.4 > > > > Thanks
[PATCH net-next v4] net/tun: Call netdev notifiers
Call netdev notifiers before and after changing the device type.
Signed-off-by: Martin Schiller
---
Changes to v3:
* Handle return value of call_netdevice_notifiers()
Changes to v2:
* Use subject_prefix 'net-next' to fix 'fixes_present' issue
Changes to v1:
* Fix 'subject_prefix' and 'checkpatch' warnings
---
drivers/net/tun.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 3d45d56172cb..704306695b88 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -3071,10 +3071,19 @@ static long __tun_chr_ioctl(struct file *file, unsigned
int cmd,
"Linktype set failed because interface is
up\n");
ret = -EBUSY;
} else {
+ ret = call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE,
+ tun->dev);
+ ret = notifier_to_errno(err);
+ if (ret) {
+ netif_info(tun, drv, tun->dev,
+ "Refused to change device type\n");
+ break;
+ }
tun->dev->type = (int) arg;
netif_info(tun, drv, tun->dev, "linktype set to %d\n",
tun->dev->type);
- ret = 0;
+ call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE,
+tun->dev);
}
break;
--
2.20.1
Re: [PATCH 5.9 000/255] 5.9.9-rc1 review
On Tue, 17 Nov 2020 at 19:02, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.9.9 release. > There are 255 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 19 Nov 2020 12:20:51 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.9-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing NOTE: 1) BUG: Invalid wait context on arm64 db410c device while booting. This issue has not reproduced after several testing loops. https://lore.kernel.org/stable/ca+g9fysk54r9re4e9bwpqsoxljpcvxrkfwrgdikvcpoye5z...@mail.gmail.com/T/#u 2) kselftest test suite version upgrade to v5.9 3) While running kselftest netfilter on x86, i386, arm64 and arm devices the following kernel warning was noticed. WARNING: at net/netfilter/nf_tables_api.c:622 lockdep_nfnl_nft_mutex_not_held+0x19/0x20 [nf_tables] https://lore.kernel.org/linux-kselftest/CA+G9fYvFUpODs+NkSYcnwKnXm62tmP=kslebpmb+kfrb2rv...@mail.gmail.com/ 4) >From this release we have started building kernels with clang-10 toolchain and testing LTP testsuite on qemu_arm64, qemu_arm, qemu_x86_64 and qemu_i386. Summary kernel: 5.9.9-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.9.y git commit: fb1622495321923cbb1ae2c6cf2da1e9ca286800 git describe: v5.9.8-256-gfb1622495321 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.8-256-gfb1622495321 No regressions (compared to build v5.9.8) No fixes (compared to build v5.9.8) Ran 52946 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-i386-clang - qemu-x86_64-clang - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - x15 - x86 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * perf * v4l2-compliance * ltp-controllers-tests * ltp-cve-tests * network-basic-tests * kselftest * ltp-open-posix-tests * kvm-unit-tests * kunit * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
linux-next: build warnings after merge of the v4l-dvb tree
Hi all,
After merging the v4l-dvb tree, today's linux-next build (htmldocs)
produced these warnings:
Documentation/output/videodev2.h.rst:6: WARNING: undefined label:
v4l2-meta-fmt-rk-isp1-params (if the link has no caption the label must precede
a section header)
Documentation/output/videodev2.h.rst:6: WARNING: undefined label:
v4l2-meta-fmt-rk-isp1-stat-3a (if the link has no caption the label must
precede a section header)
Introduced by commit
df22026aebd8 ("media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer format")
--
Cheers,
Stephen Rothwell
pgpFJETeluzKQ.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the v4l-dvb tree
Hi all,
After merging the v4l-dvb tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/output/lirc.h.rst:6: WARNING: undefined label: rc-proto-max (if
the link has no caption the label must precede a section header)
Introduced by commit
72e637fec558 ("media: rc: validate that "rc_proto" is reasonable")
--
Cheers,
Stephen Rothwell
pgpMzm5K1hKmt.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 07/22] drm/msm: Do rpm get sooner in the submit path
On 17-11-20, 09:02, Rob Clark wrote:
> With that on top of the previous patch,
Don't you still have this ? Which fixed the lockdep in the remove path.
https://lore.kernel.org/lkml/20201022080644.2ck4okrxygmkuatn@vireshk-i7/
To make it clear you need these patches to fix the OPP stuff:
//From 5.10-rc3 (the one from the above link).
commit e0df59de670b ("opp: Reduce the size of critical section in
_opp_table_kref_release()")
//Below two from linux-next
commit ef43f01ac069 ("opp: Always add entries in dev_list with opp_table->lock
held")
commit 27c09484dd3d ("opp: Allocate the OPP table outside of opp_table_lock")
This matches the diff I gave you earlier.
--
viresh
Re: [PATCH v3] ALSA: usb-audio: disable 96khz support for HUAWEI USB-C HEADSET
On Tue, 2020-11-10 at 17:04 +0800, Macpaul Lin wrote: > The HUAWEI USB-C headset (VID:0x12d1, PID:0x3a07) reported it supports > 96khz. However there will be some random issue under 96khz. > Not sure if there is any alternate setting could be applied. > Hence 48khz is suggested to be applied at this moment. > > Signed-off-by: Macpaul Lin > Signed-off-by: Eddie Hung > Cc: sta...@vger.kernel.org > --- > Changes for v2: > - Fix build error. > - Add Cc: sta...@vger.kernel.org > Changes for v3: > - Replace "udev" with "chip->dev" according to Takashi's suggestion. Thanks. > > sound/usb/format.c |5 + > 1 file changed, 5 insertions(+) > > diff --git a/sound/usb/format.c b/sound/usb/format.c > index 1b28d01..0aff774 100644 > --- a/sound/usb/format.c > +++ b/sound/usb/format.c > @@ -217,6 +217,11 @@ static int parse_audio_format_rates_v1(struct > snd_usb_audio *chip, struct audiof > (chip->usb_id == USB_ID(0x041e, 0x4064) || >chip->usb_id == USB_ID(0x041e, 0x4068))) > rate = 8000; > + /* Huawei headset can't support 96kHz fully */ > + if (rate == 96000 && > + chip->usb_id == USB_ID(0x12d1, 0x3a07) && > + le16_to_cpu(chip->dev->descriptor.bcdDevice) == > 0x49) > + continue; > > fp->rate_table[fp->nr_rates] = rate; > if (!fp->rate_min || rate < fp->rate_min) Sorry for bothering again, please hold-on this patch. I'm still trying to clarify if there is another approach for this interoperability issue. I'll update this thread once the result has came out. Thanks Macpaul Lin
linux-next: build warning after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/gpu/todo.rst:302: WARNING: Unexpected indentation.
Documentation/gpu/todo.rst:303: WARNING: Block quote ends without a blank line;
unexpected unindent.
Introduced by commit
39aead8373b3 ("fbcon: Disable accelerated scrolling")
--
Cheers,
Stephen Rothwell
pgpt5uD0be1Rj.pgp
Description: OpenPGP digital signature
Re: [PATCH net-next v3] net/tun: Call netdev notifiers
On 2020-11-18 01:32, Jakub Kicinski wrote:
On Mon, 16 Nov 2020 11:41:21 +0100 Martin Schiller wrote:
Call netdev notifiers before and after changing the device type.
Signed-off-by: Martin Schiller
---
Change from v2:
use subject_prefix 'net-next' to fix 'fixes_present' issue
Change from v1:
fix 'subject_prefix' and 'checkpatch' warnings
---
drivers/net/tun.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 3d45d56172cb..2d9a00f41023 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -3071,9 +3071,13 @@ static long __tun_chr_ioctl(struct file *file,
unsigned int cmd,
"Linktype set failed because interface is
up\n");
ret = -EBUSY;
} else {
+ call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE,
+tun->dev);
This call may return an error (which has to be unpacked with
notifier_to_errno()).
OK, I'll fix that and send a v3 patch.
tun->dev->type = (int) arg;
netif_info(tun, drv, tun->dev, "linktype set to %d\n",
tun->dev->type);
+ call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE,
+tun->dev);
ret = 0;
}
break;
Re: [PATCH v5 07/24] clk: mediatek: Fix asymmetrical PLL enable and disable control
On Wed, 2020-11-18 at 11:55 +0800, Ikjoon Jang wrote:
> On Mon, Nov 09, 2020 at 10:03:32AM +0800, Weiyi Lu wrote:
> > In fact, the en_mask is a combination of divider enable mask
> > and pll enable bit(bit0).
> > Before this patch, we enabled both divider mask and bit0 in prepare(),
> > but only cleared the bit0 in unprepare().
> > In the future, we hope en_mask will only be used as divider enable mask.
> > The enable register(CON0) will be set in 2 steps:
> > first is divider mask, and then bit0 during prepare(), and vice versa.
> > But considering backward compatibility, at this stage we allow en_mask
> > to be a combination or a pure divider enable mask.
> > And then we will make en_mask a pure divider enable mask in another
> > following patch series.
>
> I have a question on this: Are there any possible problems on controlling
> divider_en and bit0 at the same time? Or is this only for cleanups?
>
Yes, this is only for cleanups and controlling divider_en and bit0 at
the same time will not cause any problem.
> If mtk_pll_data::en_mask is not allowed to control with bit0 together,
> I guess register_pll() also needs to check en_mask::bit0 is cleared?
>
> >
> > Signed-off-by: Weiyi Lu
> > ---
> > drivers/clk/mediatek/clk-pll.c | 20
> > 1 file changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
> > index f440f2cd..11ed5d1 100644
> > --- a/drivers/clk/mediatek/clk-pll.c
> > +++ b/drivers/clk/mediatek/clk-pll.c
> > @@ -238,6 +238,7 @@ static int mtk_pll_prepare(struct clk_hw *hw)
> > {
> > struct mtk_clk_pll *pll = to_mtk_clk_pll(hw);
> > u32 r;
> > + u32 div_en_mask;
> >
> > r = readl(pll->pwr_addr) | CON0_PWR_ON;
> > writel(r, pll->pwr_addr);
> > @@ -247,10 +248,15 @@ static int mtk_pll_prepare(struct clk_hw *hw)
> > writel(r, pll->pwr_addr);
> > udelay(1);
> >
> > - r = readl(pll->base_addr + REG_CON0);
> > - r |= pll->data->en_mask;
> > + r = readl(pll->base_addr + REG_CON0) | CON0_BASE_EN;
> > writel(r, pll->base_addr + REG_CON0);
> >
> > + div_en_mask = pll->data->en_mask & ~CON0_BASE_EN;
> > + if (div_en_mask) {
> > + r = readl(pll->base_addr + REG_CON0) | div_en_mask;
> > + writel(r, pll->base_addr + REG_CON0);
> > + }
> > +
> > __mtk_pll_tuner_enable(pll);
> >
> > udelay(20);
> > @@ -268,6 +274,7 @@ static void mtk_pll_unprepare(struct clk_hw *hw)
> > {
> > struct mtk_clk_pll *pll = to_mtk_clk_pll(hw);
> > u32 r;
> > + u32 div_en_mask;
> >
> > if (pll->data->flags & HAVE_RST_BAR) {
> > r = readl(pll->base_addr + REG_CON0);
> > @@ -277,8 +284,13 @@ static void mtk_pll_unprepare(struct clk_hw *hw)
> >
> > __mtk_pll_tuner_disable(pll);
> >
> > - r = readl(pll->base_addr + REG_CON0);
> > - r &= ~CON0_BASE_EN;
> > + div_en_mask = pll->data->en_mask & ~CON0_BASE_EN;
> > + if (div_en_mask) {
> > + r = readl(pll->base_addr + REG_CON0) & ~div_en_mask;
> > + writel(r, pll->base_addr + REG_CON0);
> > + }
> > +
> > + r = readl(pll->base_addr + REG_CON0) & ~CON0_BASE_EN;
> > writel(r, pll->base_addr + REG_CON0);
> >
> > r = readl(pll->pwr_addr) | CON0_ISO_EN;
> > --
> > 1.8.1.1.dirty
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[RFC -V5] autonuma: Migrate on fault among multiple bound nodes
Now, AutoNUMA can only optimize the page placement among the NUMA
nodes if the default memory policy is used. Because the memory policy
specified explicitly should take precedence. But this seems too
strict in some situations. For example, on a system with 4 NUMA
nodes, if the memory of an application is bound to the node 0 and 1,
AutoNUMA can potentially migrate the pages between the node 0 and 1 to
reduce cross-node accessing without breaking the explicit memory
binding policy.
So in this patch, we add MPOL_F_AUTONUMA mode flag to set_mempolicy().
With the flag specified, AutoNUMA will be enabled within the thread to
optimize the page placement within the constrains of the specified
memory binding policy. With the newly added flag, the NUMA balancing
control mechanism becomes,
- sysctl knob numa_balancing can enable/disable the NUMA balancing
globally.
- even if sysctl numa_balancing is enabled, the NUMA balancing will be
disabled for the memory areas or applications with the explicit memory
policy by default.
- MPOL_F_AUTONUMA can be used to enable the NUMA balancing for the
applications when specifying the explicit memory policy.
Various page placement optimization based on the NUMA balancing can be
done with these flags. As the first step, in this patch, if the
memory of the application is bound to multiple nodes (MPOL_BIND), and
in the hint page fault handler the accessing node are in the policy
nodemask, the page will be tried to be migrated to the accessing node
to reduce the cross-node accessing.
In the previous version of the patch, we tried to reuse MPOL_MF_LAZY
for mbind(). But that flag is tied to MPOL_MF_MOVE.*, so it seems not
a good API/ABI for the purpose of the patch.
And because it's not clear whether it's necessary to enable AutoNUMA
for a specific memory area inside an application, so we only add the
flag at the thread level (set_mempolicy()) instead of the memory area
level (mbind()). We can do that when it become necessary.
Signed-off-by: "Huang, Ying"
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: Mel Gorman
Cc: Rik van Riel
Cc: Johannes Weiner
Cc: "Matthew Wilcox (Oracle)"
Cc: Dave Hansen
Cc: Andi Kleen
Cc: Michal Hocko
Cc: David Rientjes
Changes:
v5:
- Remove mbind() support, because it's not clear that it's necessary.
v4:
- Use new flags instead of reuse MPOL_MF_LAZY.
v3:
- Rebased on latest upstream (v5.10-rc3)
- Revised the change log.
v2:
- Rebased on latest upstream (v5.10-rc1)
Huang Ying (2):
mempolicy: Rename MPOL_F_MORON to MPOL_F_MOPRON
autonuma: Migrate on fault among multiple bound nodes
---
include/uapi/linux/mempolicy.h | 4 +++-
mm/mempolicy.c | 9 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/mempolicy.h b/include/uapi/linux/mempolicy.h
index 3354774af61e..adb49f13840e 100644
--- a/include/uapi/linux/mempolicy.h
+++ b/include/uapi/linux/mempolicy.h
@@ -28,12 +28,14 @@ enum {
/* Flags for set_mempolicy */
#define MPOL_F_STATIC_NODES(1 << 15)
#define MPOL_F_RELATIVE_NODES (1 << 14)
+#define MPOL_F_AUTONUMA(1 << 13) /* Optimize with AutoNUMA if
possible */
/*
* MPOL_MODE_FLAGS is the union of all possible optional mode flags passed to
* either set_mempolicy() or mbind().
*/
-#define MPOL_MODE_FLAGS(MPOL_F_STATIC_NODES | MPOL_F_RELATIVE_NODES)
+#define MPOL_MODE_FLAGS
\
+ (MPOL_F_STATIC_NODES | MPOL_F_RELATIVE_NODES | MPOL_F_AUTONUMA)
/* Flags for get_mempolicy */
#define MPOL_F_NODE(1<<0) /* return next IL mode instead of node mask */
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 3ca4898f3f24..dc77827e8c08 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -875,6 +875,9 @@ static long do_set_mempolicy(unsigned short mode, unsigned
short flags,
goto out;
}
+ if (new && new->mode == MPOL_BIND && (flags & MPOL_F_AUTONUMA))
+ new->flags |= (MPOL_F_MOF | MPOL_F_MORON);
+
ret = mpol_set_nodemask(new, nodes, scratch);
if (ret) {
mpol_put(new);
@@ -2490,6 +2493,12 @@ int mpol_misplaced(struct page *page, struct
vm_area_struct *vma, unsigned long
break;
case MPOL_BIND:
+ /* Optimize placement among multiple nodes via NUMA balancing */
+ if (pol->flags & MPOL_F_MORON) {
+ if (node_isset(thisnid, pol->v.nodes))
+ break;
+ goto out;
+ }
/*
* allows binding to multiple nodes.
--
2.29.2
linux-next: build warning after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/networking/index.rst:6: WARNING: toctree contains reference to
nonexisting document 'networking/framerelay'
Introduced by commit
f73659192b0b ("net: wan: Delete the DLCI / SDLA drivers")
--
Cheers,
Stephen Rothwell
pgpQ2i4yAL7Qa.pgp
Description: OpenPGP digital signature
[stable-rc 5.9] BUG: Invalid wait context on arm64 db410c device
While booting stable rc 5.9.9-rc1 kernel on arm64 Qualcomm db410c device
the following BUG: Invalid wait context noticed.
This issue has not reproduced after several testing loops.
[ 18.667840]
[ 18.667865] =
[ 18.668392] [ BUG: Invalid wait context ]
[ 18.672301] 5.9.9-rc1 #1 Not tainted
[ 18.676291] -
[ 18.679939] systemd-udevd/415 is trying to lock:
[ 18.683846] 3a73c718 (>mmap_lock){}-{3:3}, at:
__might_fault+0x60/0xa8
[ 18.688537] other info that might help us debug this:
[ 18.696259] context-{4:4}
[ 18.701379] 1 lock held by systemd-udevd/415:
[ 18.703982] #0: 800012781a38 (rcu_read_lock){}-{1:2}, at:
xa_load+0x0/0x178
[ 18.708328] stack backtrace:
[ 18.716137] CPU: 0 PID: 415 Comm: systemd-udevd Not tainted 5.9.9-rc1 #1
[ 18.719003] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[ 18.725687] Call trace:
[ 18.732369] dump_backtrace+0x0/0x1f8
[ 18.734540] show_stack+0x2c/0x38
[ 18.738360] dump_stack+0xec/0x158
[ 18.741658] __lock_acquire+0x520/0x1478
[ 18.744956] lock_acquire+0x120/0x4c8
[ 18.749035] __might_fault+0x84/0xa8
[ 18.752597] copy_page_to_iter+0xb4/0x3e8
[ 18.756242] generic_file_buffered_read+0x4bc/0xa98
[ 18.760148] generic_file_read_iter+0xd4/0x168
[ 18.764836] blkdev_read_iter+0x50/0x78
[ 18.769349] new_sync_read+0x100/0x1a0
[ 18.773082] vfs_read+0x1b4/0x1d8
[ 18.776900] ksys_read+0x74/0xf8
[ 18.780286] __arm64_sys_read+0x24/0x30
[ 18.783586] el0_svc_common.constprop.3+0x7c/0x198
[ 18.787143] do_el0_svc+0x34/0xa0
[ 18.792005] el0_sync_handler+0x16c/0x210
[ 18.795390] el0_sync+0x140/0x180
Reported-by: Naresh Kamboju
full test log details,
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.8-256-gfb1622495321/testrun/3452274/suite/linux-log-parser/test/check-kernel-bug-1951524/log
https://lkft.validation.linaro.org/scheduler/job/1951524#L4210
metadata:
git branch: linux-5.9.y
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git commit: fb1622495321923cbb1ae2c6cf2da1e9ca286800
git describe: v5.9.8-256-gfb1622495321
make_kernelversion: 5.9.9-rc1
kernel-config:
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-stable-rc-5.9/32/config
--
Linaro LKFT
https://lkft.linaro.org
Re: [PATCH 4/5] locking/rwsem: Wake up all waiting readers if RWSEM_WAKE_READ_OWNED
On Tue, 17 Nov 2020, Waiman Long wrote:
The rwsem wakeup logic has been modified by commit d3681e269fff
("locking/rwsem: Wake up almost all readers in wait queue") to wake up
all readers in the wait queue if the first waiter is a reader. In the
case of RWSEM_WAKE_READ_OWNED, not all readers can be woken up if the
first waiter happens to be a writer. Complete the logic by waking up
all readers even for this case.
While rwsems are certainly not fifo, I'm concerned this would give too
much priority to the readers by having the reader owned lock just skip
over the first waiter. And I'd say most users are more concerned about
the writer side. Basically this would affect the phase-fair properties.
Thanks,
Davidlohr
Re: [PATCH 2/4] dma-buf: add export symbol for dma-heap
On Tue, Nov 17, 2020 at 10:19 AM Minchan Kim wrote:
>
> From: Hyesoo Yu
>
> The heaps could be added as module, so some functions should
> be exported to register dma-heaps. And dma-heap of module can use
> cma area to allocate and free. However the function related cma
> is not exported now. Let's export them for next patches.
>
> Signed-off-by: Hyesoo Yu
> Signed-off-by: Minchan Kim
> ---
> drivers/dma-buf/dma-heap.c | 2 ++
> mm/cma.c | 3 +++
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index afd22c9dbdcf..cc6339cbca09 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -189,6 +189,7 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
> {
> return heap->priv;
> }
> +EXPORT_SYMBOL_GPL(dma_heap_get_drvdata);
>
> struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
> {
> @@ -272,6 +273,7 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> kfree(heap);
> return err_ret;
> }
> +EXPORT_SYMBOL_GPL(dma_heap_add);
>
> static char *dma_heap_devnode(struct device *dev, umode_t *mode)
> {
Thanks so much for sending this series along!
I'm ok with the dma-heap exports to support modules.
> diff --git a/mm/cma.c b/mm/cma.c
> index 7c11ec2dc04c..87834e2966fa 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -54,6 +54,7 @@ const char *cma_get_name(const struct cma *cma)
> {
> return cma->name;
> }
> +EXPORT_SYMBOL_GPL(cma_get_name);
>
> static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
> unsigned int align_order)
> @@ -498,6 +499,7 @@ struct page *cma_alloc(struct cma *cma, size_t count,
> unsigned int align,
> pr_debug("%s(): returned %p\n", __func__, page);
> return page;
> }
> +EXPORT_SYMBOL_GPL(cma_alloc);
>
> /*
> * cma_alloc_bulk() - allocate high order bulk pages from contiguous area
> with
> @@ -641,6 +643,7 @@ bool cma_release(struct cma *cma, const struct page
> *pages, unsigned int count)
>
> return true;
> }
> +EXPORT_SYMBOL_GPL(cma_release);
>
> int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data)
> {
> --
Though Christoph's (cc'ed) input would probably be good for the cma
ones, as I know he had concerns previously with similar patches.
thanks
-john
[gustavoars-linux:testing/clang-ft/for-linus] BUILD SUCCESS 60c3fe4030afca9f560eb513ff1411c7779fa5b8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git testing/clang-ft/for-linus branch HEAD: 60c3fe4030afca9f560eb513ff1411c7779fa5b8 HID: input: Fix fall-through warnings for Clang elapsed time: 726m configs tested: 124 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 nios2 10m50_defconfig powerpc eiger_defconfig m68kmvme147_defconfig xtensa iss_defconfig mips ci20_defconfig powerpc mgcoge_defconfig mips mtx1_defconfig m68k allmodconfig sh landisk_defconfig sh apsh4a3a_defconfig powerpcwarp_defconfig armu300_defconfig arm axm55xx_defconfig arm lpc18xx_defconfig arm moxart_defconfig arm u8500_defconfig m68kmac_defconfig arm alldefconfig arm shannon_defconfig h8300 h8s-sim_defconfig sh sh7724_generic_defconfig powerpcklondike_defconfig powerpc mpc832x_mds_defconfig powerpcgamecube_defconfig arm mainstone_defconfig mips bmips_be_defconfig xtensa common_defconfig armneponset_defconfig mipsmalta_kvm_guest_defconfig powerpc redwood_defconfig mips rb532_defconfig h8300h8300h-sim_defconfig arc axs103_defconfig armzeus_defconfig armclps711x_defconfig sh ap325rxa_defconfig mips cu1000-neo_defconfig sh sh7785lcr_32bit_defconfig nios2 defconfig powerpcadder875_defconfig m68k amcore_defconfig mipse55_defconfig shmigor_defconfig arm tct_hammer_defconfig mips mpc30x_defconfig riscv defconfig powerpc skiroot_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68kdefconfig m68k allyesconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a006-20201117 i386 randconfig-a005-20201117 i386 randconfig-a001-20201117 i386 randconfig-a002-20201117 i386 randconfig-a004-20201117 i386 randconfig-a003-20201117 x86_64 randconfig-a015-20201115 x86_64 randconfig-a011-20201115 x86_64 randconfig-a014-20201115 x86_64 randconfig-a013-20201115 x86_64 randconfig-a016-20201115 x86_64 randconfig-a012-20201115 i386 randconfig-a012-20201117 i386 randconfig-a014-20201117 i386 randconfig-a016-20201117 i386 randconfig-a011-20201117 i386 randconfig-a015-20201117 i386 randconfig-a013-20201117
Hello Dear
My dear I am Miss Lisha Haman 23 years of age , I am the only daughter to Dr Abdul Haman from France-Paris who work with (SEMAFO) the biggest Canadian gold producer here in West Africa Burkina Faso, Unfortunately my father was a victim on the deadliest attack by the jihadist On the 6 November 2019 when gunmen ambushed a convoy transporting workers of the Canadian mining firm Semafo, it is my sad moment each time I think about this, but the reason why I contacted you is that I have my late father receipt of deposit he made with a bank in abroad with my name as next of kin, The total amount deposited was 3.7 million United Stated dollars, Now I decided to travel for the money but embassy here deny me visa due to the Corona virus outbreak, I talk to the bank regarding my visa problem and they advise me to look for my relative trusted bank account so that they will transfer the total fund in there, But I am the only daughter of my father and have no relative to present, that is why I want to present you to the bank as my relative who will receive the total fund on my behalf and also take care of me as well, I attached my picture with this mail please send me your complete full details such as, Your Full Name: Home and Office Addresses: Telephone Number: Occupation: Country of Residence: Your Bank account number where the bank will remit the fund Once I received your details, I will give you the bank contact so that you can contact them directly to discuss how they can transfer the total fund in your bank account so that you can relocate me to join you over there in your country, Sincerely Lisha Haman
Re: [PATCH rfc] workqueue: honour cond_resched() more effectively.
On Wed, Nov 18 2020, Hillf Danton wrote:
> On Wed, 18 Nov 2020 09:16:09 +1100
>> From: NeilBrown
>> Date: Mon, 9 Nov 2020 13:37:17 +1100
>
> What is the brand of your wall clock? The gap between the Date tag
> above and 18 Nov is longer than a week.
I guess 'git commit --amend' doesn't update the Date: stamp.
>
>> Subject: [PATCH] workqueue: warn when cond_resched called from
>> concurrency-managed worker
>>
>> Several workers in concurrency-managed work queues call cond_resched().
>> This suggest that they might consume a lot of CPU time and are willing
>> to allow other code to run concurrently.
>> This *does* allow non-workqueue code to run but does *not* allow other
>> concurrency-managed work items to run on the same CPU.
>>
>> In general such workers should not be run from a concurrency-managed
>> workqueue however:
>> 1/ there is no mechanism to alert coders to the fact that they are
>> using the wrong work queue, and
>> 2/ sometimes it is not clear, when a work item is created, whether it
>> will end up in code that might consume at lot of CPU time. So
>> choosing the best workqueue it not always easy.
>>
>> This patch addresses both these issues:
>> 1/ If a concurrency-managed worker calls cond_resched() a warning
>> (WARN_ON_ONCE) is generated (if CONFIG_WQ_WATCHDOG is selected).
>> 2/ A new interface - workqueue_prepare_use_cpu() - is provided which
>> may be called by low-level code which might be called in a workqueue
>> and might consume CPU. This switches the worker to CPU_INTENSIVE
>> mode so that other work items can run on the same CPU.
>> This means there is no need to chose the required behaviour when
>> submitting a work item, as the code can switch behaviour when needed.
>
> Hm...sounds like the cure can be prepared by splicing the new interface
> above to the cond_resched() in worker's context like
>
> static void foo_work_fn(struct work_struct *work)
> {
> + bool use;
> ...
> + use = workqueue_prepare_use_cpu();
> cond_resched();
> + workqueue_end_use_cpu(use);
> ...
> }
>
> bool workqueue_prepare_use_cpu(void)
> {
> struct worker *worker = current_wq_worker();
>
> if (worker && !(worker->flags & WORKER_CPU_INTENSIVE)) {
> worker_set_flags(worker, WORKER_CPU_INTENSIVE);
> return true;
> } else
> return false;
> }
>
> void workqueue_end_use_cpu(bool use)
> {
> if (use) {
> struct worker *worker = current_wq_worker();
>
> worker_clear_flags(worker, WORKER_CPU_INTENSIVE);
> }
> }
>
> And in a nutshell it looks like the below helper to avoid touching
> anything like cond_resched().
>
> void workqueue_cond_resched(void)
> {
> struct worker *worker = current_wq_worker();
>
> if (worker && !(worker->flags & WORKER_CPU_INTENSIVE)) {
> worker_set_flags(worker, WORKER_CPU_INTENSIVE);
> cond_resched();
> worker_clear_flags(worker, WORKER_CPU_INTENSIVE);
> } else
> cond_resched();
> }
I don't think this is a good idea.
cond_resched() is expected to be called often. Adding all this extra
work every time is excessive and unnecessary.
It might make sense to add a "workqueue_end_use_cpu()" call at the end
of functions that include "workqueue_prepare_use_cpu()" at the start. I
don't think it is likely to make a useful difference, but I'm open to
the possibility if anyone can make a case for it.
Thanks,
NeilBrown
>
>>
>> This patch also changes some code to avoid the warning:
>> - in some cases, system_unbound_wq is used instead of system_wq,
>>when the work item will normally call cond_resched()
>> - in other cases, calls to workqueue_prepare_use_cpu() are inserted.
>>
>> - in slab.c, a cond_resched() call is replaced by
>> if (tif_need_resched())
>> break;
>>so that the worker will relinquish CPU and try again later.
>>
>> There are doubtless more changes needed, but these allow me to boot and
>> access NFS files without warnings.
>>
>> Signed-off-by: NeilBrown
>> =2D--
>> fs/dcache.c| 2 ++
>> fs/nfs/delegation.c| 5 +
>> fs/nfs/write.c | 6 ++
>> include/linux/rhashtable.h | 4 ++--
>> include/linux/sched.h | 2 ++
>> include/linux/workqueue.h | 30 ++
>> kernel/rcu/tree.c | 2 +-
>> kernel/workqueue.c | 33 +++--
>> lib/rhashtable.c | 8
>> mm/page_alloc.c| 14 --
>> mm/slab.c | 3 ++-
>> mm/truncate.c | 3 +++
>> net/sunrpc/clnt.c | 2 +-
>> security/keys/gc.c | 8
>> security/keys/key.c| 2 +-
>> 15 files changed, 98 insertions(+), 26 deletions(-)
>>
>> diff --git a/fs/dcache.c b/fs/dcache.c
>> index ea0485861d93..46c83f712ad3 100644
>> =2D-- a/fs/dcache.c
>> +++ b/fs/dcache.c
Re: linux-next: build failure after merge of the mhi tree
Hi Stephen, On Wed, Nov 18, 2020 at 03:51:28PM +1100, Stephen Rothwell wrote: > Hi all, > > On Wed, 18 Nov 2020 15:45:00 +1100 Stephen Rothwell > wrote: > > > > On Wed, 18 Nov 2020 15:39:12 +1100 Stephen Rothwell > > wrote: > > > > > > Why isn't that "fix patch" in the mhi tree (with necessary Acked-bys)? > > > > Ignore that, I missed its appearance :-) > > Ignore that, my question stands (git confused me a lot :-(). > > I have applied the fix patch to the mhi tree merge today. After discussing with Kalle, we decided to have a single patch which changes MHI and ath11k (fix patch) to avoid issues. I'll send it today and get it applied to mhi-next soon (via immutable branch). Thanks, Mani > -- > Cheers, > Stephen Rothwell
[PATCH v2 1/5] perf metric: Restructure struct expr_parse_ctx.
A later change to parsing the ids out (in expr__find_other) will
potentially drop hashmaps and so it is more convenient to move
expr_parse_ctx to have a hashmap pointer rather than a struct value. As
this pointer must be freed, rather than just going out of scope,
add expr__ctx_new and expr__ctx_free to manage expr_parse_ctx memory.
Adjust use of struct expr_parse_ctx accordingly.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 81 ++-
tools/perf/tests/pmu-events.c | 37 +---
tools/perf/util/expr.c| 38
tools/perf/util/expr.h| 5 ++-
tools/perf/util/metricgroup.c | 44 ++-
tools/perf/util/stat-shadow.c | 50 +
6 files changed, 151 insertions(+), 104 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index 4d01051951cd..b0a3b5fd0c00 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -22,67 +22,70 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
const char *p;
double val;
int ret;
- struct expr_parse_ctx ctx;
+ struct expr_parse_ctx *ctx;
- expr__ctx_init();
- expr__add_id_val(, strdup("FOO"), 1);
- expr__add_id_val(, strdup("BAR"), 2);
+ ctx = expr__ctx_new();
+ TEST_ASSERT_VAL("expr__ctx_new", ctx);
+ expr__add_id_val(ctx, strdup("FOO"), 1);
+ expr__add_id_val(ctx, strdup("BAR"), 2);
- ret = test(, "1+1", 2);
- ret |= test(, "FOO+BAR", 3);
- ret |= test(, "(BAR/2)%2", 1);
- ret |= test(, "1 - -4", 5);
- ret |= test(, "(FOO-1)*2 + (BAR/2)%2 - -4", 5);
- ret |= test(, "1-1 | 1", 1);
- ret |= test(, "1-1 & 1", 0);
- ret |= test(, "min(1,2) + 1", 2);
- ret |= test(, "max(1,2) + 1", 3);
- ret |= test(, "1+1 if 3*4 else 0", 2);
- ret |= test(, "1.1 + 2.1", 3.2);
- ret |= test(, ".1 + 2.", 2.1);
- ret |= test(, "d_ratio(1, 2)", 0.5);
- ret |= test(, "d_ratio(2.5, 0)", 0);
- ret |= test(, "1.1 < 2.2", 1);
- ret |= test(, "2.2 > 1.1", 1);
- ret |= test(, "1.1 < 1.1", 0);
- ret |= test(, "2.2 > 2.2", 0);
- ret |= test(, "2.2 < 1.1", 0);
- ret |= test(, "1.1 > 2.2", 0);
+ ret = test(ctx, "1+1", 2);
+ ret |= test(ctx, "FOO+BAR", 3);
+ ret |= test(ctx, "(BAR/2)%2", 1);
+ ret |= test(ctx, "1 - -4", 5);
+ ret |= test(ctx, "(FOO-1)*2 + (BAR/2)%2 - -4", 5);
+ ret |= test(ctx, "1-1 | 1", 1);
+ ret |= test(ctx, "1-1 & 1", 0);
+ ret |= test(ctx, "min(1,2) + 1", 2);
+ ret |= test(ctx, "max(1,2) + 1", 3);
+ ret |= test(ctx, "1+1 if 3*4 else 0", 2);
+ ret |= test(ctx, "1.1 + 2.1", 3.2);
+ ret |= test(ctx, ".1 + 2.", 2.1);
+ ret |= test(ctx, "d_ratio(1, 2)", 0.5);
+ ret |= test(ctx, "d_ratio(2.5, 0)", 0);
+ ret |= test(ctx, "1.1 < 2.2", 1);
+ ret |= test(ctx, "2.2 > 1.1", 1);
+ ret |= test(ctx, "1.1 < 1.1", 0);
+ ret |= test(ctx, "2.2 > 2.2", 0);
+ ret |= test(ctx, "2.2 < 1.1", 0);
+ ret |= test(ctx, "1.1 > 2.2", 0);
- if (ret)
+ if (ret) {
+ expr__ctx_free(ctx);
return ret;
+ }
p = "FOO/0";
- ret = expr__parse(, , p, 1);
+ ret = expr__parse(, ctx, p, 1);
TEST_ASSERT_VAL("division by zero", ret == -1);
p = "BAR/";
- ret = expr__parse(, , p, 1);
+ ret = expr__parse(, ctx, p, 1);
TEST_ASSERT_VAL("missing operand", ret == -1);
- expr__ctx_clear();
+ expr__ctx_clear(ctx);
TEST_ASSERT_VAL("find other",
expr__find_other("FOO + BAR + BAZ + BOZO", "FOO",
-, 1) == 0);
- TEST_ASSERT_VAL("find other", hashmap__size() == 3);
- TEST_ASSERT_VAL("find other", hashmap__find(, "BAR",
+ctx, 1) == 0);
+ TEST_ASSERT_VAL("find other", hashmap__size(ctx->ids) == 3);
+ TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BAR",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(, "BAZ",
+ TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BAZ",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(, "BOZO",
+ TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BOZO",
(void **)_ptr));
- expr__ctx_clear();
+ expr__ctx_clear(ctx);
TEST_ASSERT_VAL("find other",
expr__find_other("EVENT1\\,param\\=?@ +
EVENT2\\,param\\=?@",
-NULL, , 3) == 0);
- TEST_ASSERT_VAL("find other", hashmap__size() == 2);
- TEST_ASSERT_VAL("find other", hashmap__find(, "EVENT1,param=3/",
+
[PATCH v2 5/5] perf metric: Don't compute unused events.
For a metric like:
EVENT1 if #smt_on else EVENT2
currently EVENT1 and EVENT2 will be measured and then when the metric is
reported EVENT1 or EVENT2 will be printed depending on the value from
smt_on() during the expr parsing. Computing both events is unnecessary and
can lead to multiplexing as discussed in this thread:
https://lore.kernel.org/lkml/20201110100346.2527031-1-irog...@google.com/
This change modifies the expression parsing code by:
- getting rid of the "other" parsing and introducing a boolean argument
to say whether ids should be computed or not.
- expressions are changed so that a pair of value and ids are returned.
- when computing the metric value the ids are unused.
- when computing the ids, constant values and smt_on are assigned to
the value.
- If the value is from an event ID then the event is added to the ids
hashmap and the value set to NAN.
- Typically operators union IDs for their inputs and set the value to
NAN, however, if the inputs are constant then these are computed and
propagated as the value.
- If the input is constant to certain operators like:
IDS1 if CONST else IDS2
then the result will be either IDS1 or IDS2 depending on CONST which
may be evaluated from an entire expression.
- The ids at the end of parsing are added to the context.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 10 ++
tools/perf/util/expr.c | 9 +-
tools/perf/util/expr.h | 1 -
tools/perf/util/expr.l | 9 --
tools/perf/util/expr.y | 341 +++-
5 files changed, 284 insertions(+), 86 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index 7c2a01cf0650..94ddd01b29fc 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include "util/debug.h"
#include "util/expr.h"
+#include "util/smt.h"
#include "tests.h"
#include
#include
@@ -132,6 +133,15 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "EVENT2,param=3/",
(void **)_ptr));
+ expr__ctx_clear(ctx);
+ TEST_ASSERT_VAL("find ids",
+ expr__find_ids("EVENT1 if #smt_on else EVENT2",
+ NULL, ctx, 0) == 0);
+ TEST_ASSERT_VAL("find ids", hashmap__size(ctx->ids) == 1);
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids,
+ smt_on() ? "EVENT1" :
"EVENT2",
+ (void **)_ptr));
+
expr__ctx_free(ctx);
return 0;
diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
index 1adb6cd202e0..28aaa50c6c68 100644
--- a/tools/perf/util/expr.c
+++ b/tools/perf/util/expr.c
@@ -329,10 +329,9 @@ void expr__ctx_free(struct expr_parse_ctx *ctx)
static int
__expr__parse(double *val, struct expr_parse_ctx *ctx, const char *expr,
- int start, int runtime)
+ bool compute_ids, int runtime)
{
struct expr_scanner_ctx scanner_ctx = {
- .start_token = start,
.runtime = runtime,
};
YY_BUFFER_STATE buffer;
@@ -352,7 +351,7 @@ __expr__parse(double *val, struct expr_parse_ctx *ctx,
const char *expr,
expr_set_debug(1, scanner);
#endif
- ret = expr_parse(val, ctx, scanner);
+ ret = expr_parse(val, ctx, compute_ids, scanner);
expr__flush_buffer(buffer, scanner);
expr__delete_buffer(buffer, scanner);
@@ -363,13 +362,13 @@ __expr__parse(double *val, struct expr_parse_ctx *ctx,
const char *expr,
int expr__parse(double *final_val, struct expr_parse_ctx *ctx,
const char *expr, int runtime)
{
- return __expr__parse(final_val, ctx, expr, EXPR_PARSE, runtime) ? -1 :
0;
+ return __expr__parse(final_val, ctx, expr, /*compute_ids=*/false,
runtime) ? -1 : 0;
}
int expr__find_ids(const char *expr, const char *one,
struct expr_parse_ctx *ctx, int runtime)
{
- int ret = __expr__parse(NULL, ctx, expr, EXPR_OTHER, runtime);
+ int ret = __expr__parse(NULL, ctx, expr, /*compute_ids=*/true, runtime);
if (one)
expr__del_id(ctx, one);
diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
index 62d3ae5ddfba..cefeb2c8d85e 100644
--- a/tools/perf/util/expr.h
+++ b/tools/perf/util/expr.h
@@ -26,7 +26,6 @@ struct expr_parse_ctx {
struct expr_id_data;
struct expr_scanner_ctx {
- int start_token;
int runtime;
};
diff --git a/tools/perf/util/expr.l b/tools/perf/util/expr.l
index 13e5e3c75f56..702fdf6456ca 100644
--- a/tools/perf/util/expr.l
+++ b/tools/perf/util/expr.l
@@ -91,15 +91,6 @@ symbol ({spec}|{sym})+
%%
struct expr_scanner_ctx *sctx = expr_get_extra(yyscanner);
- {
- int start_token = sctx->start_token;
-
-
[PATCH v2 3/5] perf metric: Rename expr__find_other.
A later change will remove the notion of other, rename the function to
expr__find_ids as this is what it populated.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 8
tools/perf/tests/pmu-events.c | 9 -
tools/perf/util/expr.c| 4 ++--
tools/perf/util/expr.h| 2 +-
tools/perf/util/metricgroup.c | 2 +-
tools/perf/util/stat-shadow.c | 6 +++---
6 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index b0a3b5fd0c00..9d7032041318 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -65,8 +65,8 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
expr__ctx_clear(ctx);
TEST_ASSERT_VAL("find other",
- expr__find_other("FOO + BAR + BAZ + BOZO", "FOO",
-ctx, 1) == 0);
+ expr__find_ids("FOO + BAR + BAZ + BOZO", "FOO",
+ ctx, 1) == 0);
TEST_ASSERT_VAL("find other", hashmap__size(ctx->ids) == 3);
TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BAR",
(void **)_ptr));
@@ -77,8 +77,8 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
expr__ctx_clear(ctx);
TEST_ASSERT_VAL("find other",
- expr__find_other("EVENT1\\,param\\=?@ +
EVENT2\\,param\\=?@",
-NULL, ctx, 3) == 0);
+ expr__find_ids("EVENT1\\,param\\=?@ +
EVENT2\\,param\\=?@",
+ NULL, ctx, 3) == 0);
TEST_ASSERT_VAL("find other", hashmap__size(ctx->ids) == 2);
TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "EVENT1,param=3/",
(void **)_ptr));
diff --git a/tools/perf/tests/pmu-events.c b/tools/perf/tests/pmu-events.c
index 294daf568bb6..3ac70fa31379 100644
--- a/tools/perf/tests/pmu-events.c
+++ b/tools/perf/tests/pmu-events.c
@@ -502,9 +502,8 @@ static int test_parsing(void)
if (!pe->metric_expr)
continue;
expr__ctx_clear(ctx);
- if (expr__find_other(pe->metric_expr, NULL, ctx, 0)
- < 0) {
- expr_failure("Parse other failed", map, pe);
+ if (expr__find_ids(pe->metric_expr, NULL, ctx, 0) < 0) {
+ expr_failure("Parse find ids failed", map, pe);
ret++;
continue;
}
@@ -559,8 +558,8 @@ static int metric_parse_fake(const char *str)
pr_debug("parsing '%s'\n", str);
ctx = expr__ctx_new();
- if (expr__find_other(str, NULL, ctx, 0) < 0) {
- pr_err("expr__find_other failed\n");
+ if (expr__find_ids(str, NULL, ctx, 0) < 0) {
+ pr_err("expr__find_ids failed\n");
return -1;
}
diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
index e0623d38e6ee..a248d14882cc 100644
--- a/tools/perf/util/expr.c
+++ b/tools/perf/util/expr.c
@@ -287,8 +287,8 @@ int expr__parse(double *final_val, struct expr_parse_ctx
*ctx,
return __expr__parse(final_val, ctx, expr, EXPR_PARSE, runtime) ? -1 :
0;
}
-int expr__find_other(const char *expr, const char *one,
-struct expr_parse_ctx *ctx, int runtime)
+int expr__find_ids(const char *expr, const char *one,
+ struct expr_parse_ctx *ctx, int runtime)
{
int ret = __expr__parse(NULL, ctx, expr, EXPR_OTHER, runtime);
diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
index 00b941cfe6a6..955d5adb7ca4 100644
--- a/tools/perf/util/expr.h
+++ b/tools/perf/util/expr.h
@@ -43,7 +43,7 @@ int expr__resolve_id(struct expr_parse_ctx *ctx, const char
*id,
struct expr_id_data **datap);
int expr__parse(double *final_val, struct expr_parse_ctx *ctx,
const char *expr, int runtime);
-int expr__find_other(const char *expr, const char *one,
+int expr__find_ids(const char *expr, const char *one,
struct expr_parse_ctx *ids, int runtime);
double expr_id_data__value(const struct expr_id_data *data);
diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 342dcccb860f..0be684bb020f 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -761,7 +761,7 @@ static int __add_metric(struct list_head *metric_list,
* For both the parent and referenced metrics, we parse
* all the metric's IDs and add it to the parent context.
*/
- if (expr__find_other(pe->metric_expr, NULL, m->pctx, runtime) < 0) {
+ if (expr__find_ids(pe->metric_expr, NULL, m->pctx, runtime) < 0) {
if
[PATCH v2 4/5] perf metric: Add utilities to work on ids map.
Add utilities to new/free an ids hashmap, as well as to union. Add
testing of the union. Unioning hashmaps will be used when parsing the
metric, if a value is known then the hashmap is unnecessary, otherwise
we need to union together all the event ids to compute their values for
reporting.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 47 ++
tools/perf/util/expr.c | 87 +++--
tools/perf/util/expr.h | 9 +
3 files changed, 139 insertions(+), 4 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index 9d7032041318..7c2a01cf0650 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -6,6 +6,51 @@
#include
#include
+static int test_ids_union(void)
+{
+ struct hashmap *ids1, *ids2;
+
+ /* Empty union. */
+ ids1 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids1);
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 0);
+
+ /* Union {foo, bar} against {}. */
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids1, strdup("foo"),
NULL), 0);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids1, strdup("bar"),
NULL), 0);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 2);
+
+ /* Union {foo, bar} against {foo}. */
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids2, strdup("foo"),
NULL), 0);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 2);
+
+ /* Union {foo, bar} against {bar,baz}. */
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids2, strdup("bar"),
NULL), 0);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids2, strdup("baz"),
NULL), 0);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 3);
+
+ ids__free(ids1);
+
+ return 0;
+}
+
static int test(struct expr_parse_ctx *ctx, const char *e, double val2)
{
double val;
@@ -24,6 +69,8 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
int ret;
struct expr_parse_ctx *ctx;
+ TEST_ASSERT_EQUAL("ids_union", test_ids_union(), 0);
+
ctx = expr__ctx_new();
TEST_ASSERT_VAL("expr__ctx_new", ctx);
expr__add_id_val(ctx, strdup("FOO"), 1);
diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
index a248d14882cc..1adb6cd202e0 100644
--- a/tools/perf/util/expr.c
+++ b/tools/perf/util/expr.c
@@ -59,8 +59,48 @@ static bool key_equal(const void *key1, const void *key2,
return !strcmp((const char *)key1, (const char *)key2);
}
-/* Caller must make sure id is allocated */
-int expr__add_id(struct expr_parse_ctx *ctx, const char *id)
+struct hashmap *ids__new(void)
+{
+ return hashmap__new(key_hash, key_equal, NULL);
+}
+
+void ids__free(struct hashmap *ids)
+{
+ struct hashmap_entry *cur;
+ size_t bkt;
+
+ if (ids == NULL)
+ return;
+
+#ifdef PARSER_DEBUG
+ fprintf(stderr, "freeing ids: ");
+ ids__print(ids);
+ fprintf(stderr, "\n");
+#endif
+
+ hashmap__for_each_entry(ids, cur, bkt) {
+ free((char *)cur->key);
+ free(cur->value);
+ }
+
+ hashmap__free(ids);
+}
+
+void ids__print(struct hashmap *ids)
+{
+ size_t bkt;
+ struct hashmap_entry *cur;
+
+ if (!ids)
+ return;
+
+ hashmap__for_each_entry(ids, cur, bkt) {
+ fprintf(stderr, "key:%s, ", (const char *)cur->key);
+ }
+}
+
+int ids__insert(struct hashmap *ids, const char *id,
+ struct expr_id *parent)
{
struct expr_id_data *data_ptr = NULL, *old_data = NULL;
char *old_key = NULL;
@@ -70,10 +110,10 @@ int expr__add_id(struct expr_parse_ctx *ctx, const char
*id)
if (!data_ptr)
return -ENOMEM;
- data_ptr->parent = ctx->parent;
+ data_ptr->parent = parent;
data_ptr->kind = EXPR_ID_DATA__PARENT;
- ret = hashmap__set(ctx->ids, id, data_ptr,
+ ret = hashmap__set(ids, id, data_ptr,
(const void **)_key, (void **)_data);
if (ret)
free(data_ptr);
@@ -82,6 +122,45 @@ int expr__add_id(struct expr_parse_ctx *ctx, const char *id)
return ret;
}
+struct hashmap *ids__union(struct hashmap *ids1, struct hashmap *ids2)
+{
+ size_t bkt;
+ struct hashmap_entry *cur;
+ int ret;
+ struct expr_id_data *old_data = NULL;
+ char *old_key = NULL;
+
+ if (!ids1)
+ return ids2;
+
+ if (!ids2)
+ return
[PATCH v2 2/5] perf metric: Use NAN for missing event IDs.
If during computing a metric an event (id) is missing the parsing
aborts. A later patch will make it so that events that aren't used in
the output are deliberately omitted, in which case we don't want the
abort. Modify the missing ID case to report NAN for these cases.
Signed-off-by: Ian Rogers
---
tools/perf/util/expr.y | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
index b2ada8f8309a..c22e3500a40f 100644
--- a/tools/perf/util/expr.y
+++ b/tools/perf/util/expr.y
@@ -1,6 +1,7 @@
/* Simple expression parser */
%{
#define YYDEBUG 1
+#include
#include
#include "util.h"
#include "util/debug.h"
@@ -89,8 +90,7 @@ expr: NUMBER
struct expr_id_data *data;
if (expr__resolve_id(ctx, $1, )) {
- free($1);
- YYABORT;
+ $$ = NAN;
}
$$ = expr_id_data__value(data);
--
2.29.2.299.gdc1121823c-goog
[PATCH v2 0/5] Don't compute events that won't be used in a metric.
For a metric like: EVENT1 if #smt_on else EVENT2 currently EVENT1 and EVENT2 will be measured and then when the metric is reported EVENT1 or EVENT2 will be printed depending on the value from smt_on() during the expr parsing. Computing both events is unnecessary and can lead to multiplexing as discussed in this thread: https://lore.kernel.org/lkml/20201110100346.2527031-1-irog...@google.com/ This change modifies expression parsing so that constants are considered when building the set of ids (events) and only events not contributing to a constant value are measured. v2. is a rebase. Ian Rogers (5): perf metric: Restructure struct expr_parse_ctx. perf metric: Use NAN for missing event IDs. perf metric: Rename expr__find_other. perf metric: Add utilities to work on ids map. perf metric: Don't compute unused events. tools/perf/tests/expr.c | 148 ++- tools/perf/tests/pmu-events.c | 42 +++-- tools/perf/util/expr.c| 136 -- tools/perf/util/expr.h| 17 +- tools/perf/util/expr.l| 9 - tools/perf/util/expr.y| 343 +++--- tools/perf/util/metricgroup.c | 44 +++-- tools/perf/util/stat-shadow.c | 54 -- 8 files changed, 586 insertions(+), 207 deletions(-) -- 2.29.2.299.gdc1121823c-goog
Re: [PATCH] bpf: don't fail kmalloc while releasing raw_tp
On Tue, Nov 17, 2020 at 08:09:22PM -0500, Steven Rostedt wrote: > On Tue, 17 Nov 2020 16:42:44 -0800 > Matt Mullins wrote: > > > > > Indeed with a stub function, I don't see any need for > > > READ_ONCE/WRITE_ONCE. > > > > I'm not sure if this is a practical issue, but without WRITE_ONCE, can't > > the write be torn? A racing __traceiter_ could potentially see a > > half-modified function pointer, which wouldn't work out too well. > > This has been discussed before, and Linus said: > > "We add READ_ONCE and WRITE_ONCE annotations when they make sense. Not > because of some theoretical "compiler is free to do garbage" > arguments. If such garbage happens, we need to fix the compiler" > > https://lore.kernel.org/lkml/CAHk-=wi_KeD1M-_-_SU_H92vJ-yNkDnAGhAS=rr1ynngwkw...@mail.gmail.com/ I have to ask... Did the ARM compilers get fixed? As of a few months ago, they would tear stores of some constant values. > > This was actually my gut instinct before I wrote the __GFP_NOFAIL > > instead -- currently that whole array's memory ordering is provided by > > RCU and I didn't dive deep enough to evaluate getting too clever with > > atomic modifications to it. > > The pointers are always going to be the architecture word size (by > definition), and any compiler that tears a write of a long is broken. But yes, if the write is of a non-constant pointer, the compiler does have less leverage. Thanx, Paul
[rcu:dev.2020.11.15a 38/47] ERROR: modpost: "poll_state_synchronize_srcu" undefined!
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2020.11.15a head: 0cbf40a040eee93f0060e7eebac98c91ef6af021 commit: 7d879f439ed440baf02e676a784e8fa68ca87109 [38/47] rcutorture: Add writer-side tests of polling grace-period API config: x86_64-randconfig-a013-20201116 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project c044709b8fbea2a9a375e4173a6bd735f6866c0c) 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/paulmck/linux-rcu.git/commit/?id=7d879f439ed440baf02e676a784e8fa68ca87109 git remote add rcu https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git git fetch --no-tags rcu dev.2020.11.15a git checkout 7d879f439ed440baf02e676a784e8fa68ca87109 # 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 Note: the rcu/dev.2020.11.15a HEAD 0cbf40a040eee93f0060e7eebac98c91ef6af021 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "poll_state_synchronize_srcu" [kernel/rcu/rcutorture.ko] >> undefined! >> ERROR: modpost: "start_poll_synchronize_srcu" [kernel/rcu/rcutorture.ko] >> undefined! >> ERROR: modpost: "get_state_synchronize_srcu" [kernel/rcu/rcutorture.ko] >> undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v2] tracepoint: Do not fail unregistering a probe due to memory allocation
On Tue, Nov 17, 2020 at 6:18 PM Steven Rostedt wrote:
>
> From: "Steven Rostedt (VMware)"
>
> The list of tracepoint callbacks is managed by an array that is protected
> by RCU. To update this array, a new array is allocated, the updates are
> copied over to the new array, and then the list of functions for the
> tracepoint is switched over to the new array. After a completion of an RCU
> grace period, the old array is freed.
>
> This process happens for both adding a callback as well as removing one.
> But on removing a callback, if the new array fails to be allocated, the
> callback is not removed, and may be used after it is freed by the clients
> of the tracepoint.
>
> There's really no reason to fail if the allocation for a new array fails
> when removing a function. Instead, the function can simply be replaced by a
> stub that will be ignored in the callback loop, and it will be cleaned up
> on the next modification of the array.
>
> Link: https://lore.kernel.org/r/20201115055256.65625-1-mmull...@mmlx.us
> Link: https://lkml.kernel.org/r/20201116175107.02db3...@gandalf.local.home
>
> Cc: Mathieu Desnoyers
> Cc: Ingo Molnar
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> Cc: Dmitry Vyukov
> Cc: Martin KaFai Lau
> Cc: Song Liu
> Cc: Yonghong Song
> Cc: Andrii Nakryiko
> Cc: John Fastabend
> Cc: KP Singh
> Cc: netdev
> Cc: bpf
> Cc: Kees Cook
> Cc: sta...@vger.kernel.org
> Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints")
> Reported-by: syzbot+83aa762ef23b6f0d1...@syzkaller.appspotmail.com
> Reported-by: syzbot+d29e58bb557324e55...@syzkaller.appspotmail.com
> Reported-by: Matt Mullins
> Signed-off-by: Steven Rostedt (VMware)
> ---
> Changes since v1:
>Use 1L value for stub function, and ignore calling it.
>
> include/linux/tracepoint.h | 9 -
> kernel/tracepoint.c| 80 +-
> 2 files changed, 69 insertions(+), 20 deletions(-)
>
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index 0f21617f1a66..2e06e05b9d2a 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -33,6 +33,8 @@ struct trace_eval_map {
>
> #define TRACEPOINT_DEFAULT_PRIO10
>
> +#define TRACEPOINT_STUB((void *)0x1L)
> +
> extern struct srcu_struct tracepoint_srcu;
>
> extern int
> @@ -310,7 +312,12 @@ static inline struct tracepoint
> *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> do {\
> it_func = (it_func_ptr)->func; \
> __data = (it_func_ptr)->data; \
> - ((void(*)(void *, proto))(it_func))(__data, args); \
> + /* \
> +* Removed functions that couldn't be allocated \
> +* are replaced with TRACEPOINT_STUB. \
> +*/ \
> + if (likely(it_func != TRACEPOINT_STUB)) \
> + ((void(*)(void *, proto))(it_func))(__data,
> args); \
I think you're overreacting to the problem.
Adding run-time check to extremely unlikely problem seems wasteful.
99.9% of the time allocate_probes() will do kmalloc from slab of small
objects.
If that slab is out of memory it means it cannot allocate a single page.
In such case so many things will be failing to alloc that system
is unlikely operational. oom should have triggered long ago.
Imo Matt's approach to add __GFP_NOFAIL to allocate_probes()
when it's called from func_remove() is much better.
The error was reported by syzbot that was using
memory fault injections. ENOMEM in allocate_probes() was
never seen in real life and highly unlikely will ever be seen.
[PATCH] arm64: dts: qcom: sc7180: Add prox sensor to LTE SKU Lazor boards
There's a proximity sensor on Lazor devices, but only for LTE SKUs.
Enable it only on the LTE SKUs and also configure it properly so it
works.
Cc: Douglas Anderson
Cc: Matthias Kaehlcke
Signed-off-by: Stephen Boyd
---
arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1-lte.dts | 8
arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dts | 8
arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi | 7 ++-
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1-lte.dts
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1-lte.dts
index 5a67e5baafec..e16ba7b01f25 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1-lte.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1-lte.dts
@@ -13,6 +13,14 @@ / {
compatible = "google,lazor-rev1-sku0", "google,lazor-rev2-sku0",
"qcom,sc7180";
};
+_sar_sensor {
+ status = "okay";
+};
+
+_sar_sensor_i2c {
+ status = "okay";
+};
+
_backlight {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dts
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dts
index 43836fc4d403..0881f8dd02c9 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dts
@@ -13,6 +13,14 @@ / {
compatible = "google,lazor-sku0", "qcom,sc7180";
};
+_sar_sensor {
+ status = "okay";
+};
+
+_sar_sensor_i2c {
+ status = "okay";
+};
+
_backlight {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi
index 180ef9e04306..89de69b60609 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi
@@ -30,7 +30,12 @@ panel_in_edp: endpoint {
};
_sar_sensor {
- status = "okay";
+ semtech,cs0-ground;
+ semtech,combined-sensors = <3>;
+ semtech,resolution = "fine";
+ semtech,startup-sensor = <1>;
+ semtech,proxraw-strength = <2>;
+ semtech,avg-pos-strength = <64>;
};
ap_ts_pen_1v8: {
base-commit: ead9f7d7ea9e20843e29e688b53859cea20044ee
--
Sent by a computer, using git, on the internet
Re: [PATCH v2 27/29] mm/memory_hotplug: extend offline_and_remove_memory() to handle more than one memory block
On Thu, 12 Nov 2020 14:38:13 +0100 David Hildenbrand wrote: > virtio-mem soon wants to use offline_and_remove_memory() memory that > exceeds a single Linux memory block (memory_block_size_bytes()). Let's > remove that restriction. > > Let's remember the old state and try to restore that if anything goes > wrong. While re-onlining can, in general, fail, it's highly unlikely to > happen (usually only when a notifier fails to allocate memory, and these > are rather rare). > > This will be used by virtio-mem to offline+remove memory ranges that are > bigger than a single memory block - for example, with a device block > size of 1 GiB (e.g., gigantic pages in the hypervisor) and a Linux memory > block size of 128MB. > > While we could compress the state into 2 bit, using 8 bit is much > easier. > > This handling is similar, but different to acpi_scan_try_to_offline(): > > a) We don't try to offline twice. I am not sure if this CONFIG_MEMCG > optimization is still relevant - it should only apply to ZONE_NORMAL > (where we have no guarantees). If relevant, we can always add it. > > b) acpi_scan_try_to_offline() simply onlines all memory in case > something goes wrong. It doesn't restore previous online type. Let's do > that, so we won't overwrite what e.g., user space configured. > > ... > uint8_t is a bit of a mouthful. u8 is less typing ;) Doesn't matter. Acked-by: Andrew Morton
Re: linux-next: build failure after merge of the mhi tree
Hi all, On Wed, 18 Nov 2020 15:45:00 +1100 Stephen Rothwell wrote: > > On Wed, 18 Nov 2020 15:39:12 +1100 Stephen Rothwell > wrote: > > > > Why isn't that "fix patch" in the mhi tree (with necessary Acked-bys)? > > Ignore that, I missed its appearance :-) Ignore that, my question stands (git confused me a lot :-(). I have applied the fix patch to the mhi tree merge today. -- Cheers, Stephen Rothwell pgp1b7V2gMM_6.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the mhi tree
Hi all, On Wed, 18 Nov 2020 15:39:12 +1100 Stephen Rothwell wrote: > > Why isn't that "fix patch" in the mhi tree (with necessary Acked-bys)? Ignore that, I missed its appearance :-) -- Cheers, Stephen Rothwell pgpiUFU2hM2C_.pgp Description: OpenPGP digital signature
Re: [PATCH v3 3/3] [RFC] CPUFreq: Add support for cpu-perf-dependencies
On 17-11-20, 14:06, Rafael J. Wysocki wrote: > Is this really a cpufreq thing, though, or is it arch stuff? I think > the latter, because it is not necessary for anything in cpufreq. > > Yes, acpi-cpufreq happens to know this information, because it uses > processor_perflib, but the latter may as well be used by the arch > enumeration of CPUs and the freqdomain_cpus mask may be populated from > there. > > As far as cpufreq is concerned, if the interface to the hardware is > per-CPU, there is one CPU per policy and cpufreq has no business > knowing anything about the underlying hardware coordination. It won't be used by cpufreq for now at least and yes I understand your concern. I opted for this because we already have a cpufreq implementation for the same thing and it is usually better to reuse this kind of stuff instead of inventing it over. -- viresh
[PATCH v2] ASoC: hdmi-codec: Get ELD in before reporting plugged event
In plugged callback, ELD should be updated from display driver so that
user space can query information from ELD immediately after receiving jack
plugged event.
When jack is unplugged, clear ELD buffer so that user space does not get
obsolete information of unplugged HDMI.
Signed-off-by: Cheng-Yi Chiang
---
Change from v1 to v2:
- Report jack unplug event then clear ELD. This makes sure user will not get a
cleared ELD during their usage of jack.
sound/soc/codecs/hdmi-codec.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 403d4c6a49a8..e8410b2433de 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -692,10 +692,16 @@ static void plugged_cb(struct device *dev, bool plugged)
{
struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
- if (plugged)
+ if (plugged) {
+ if (hcp->hcd.ops->get_eld) {
+ hcp->hcd.ops->get_eld(dev->parent, hcp->hcd.data,
+ hcp->eld, sizeof(hcp->eld));
+ }
hdmi_codec_jack_report(hcp, SND_JACK_LINEOUT);
- else
+ } else {
hdmi_codec_jack_report(hcp, 0);
+ memset(hcp->eld, 0, sizeof(hcp->eld));
+ }
}
static int hdmi_codec_set_jack(struct snd_soc_component *component,
--
2.29.2.299.gdc1121823c-goog
Re: linux-next: build failure after merge of the mhi tree
Hi Manivannan,
On Tue, 17 Nov 2020 09:53:59 +0530 Manivannan Sadhasivam
wrote:
>
> +ath11k list, kalle
>
> On Tue, Nov 17, 2020 at 03:12:25PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the mhi tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > drivers/net/wireless/ath/ath11k/mhi.c:27:4: error: 'struct
> > mhi_channel_config' has no member named 'auto_start'
> >27 | .auto_start = false,
> > |^~
> > drivers/net/wireless/ath/ath11k/mhi.c:42:4: error: 'struct
> > mhi_channel_config' has no member named 'auto_start'
> >42 | .auto_start = false,
> > |^~
> > drivers/net/wireless/ath/ath11k/mhi.c:57:4: error: 'struct
> > mhi_channel_config' has no member named 'auto_start'
> >57 | .auto_start = true,
> > |^~
> > drivers/net/wireless/ath/ath11k/mhi.c:72:4: error: 'struct
> > mhi_channel_config' has no member named 'auto_start'
> >72 | .auto_start = true,
> > |^~
> >
> > Caused by commit
> >
> > 0cc1f3a385b2 ("bus: mhi: Remove auto-start option")
>
> The fixing patch [1] should've landed in ath-next. Kalle can you please
> apply the patch on top of immutable branch?
>
> Stephen, feel free to pick it up in the meantime.
Why isn't that "fix patch" in the mhi tree (with necessary Acked-bys)?
--
Cheers,
Stephen Rothwell
pgpcQ6i_9lHqZ.pgp
Description: OpenPGP digital signature
Re: [PATCH RFC v5 01/13] perf jevents: Add support for an extra directory level
On 11/13/20 2:54 PM, John Garry wrote: > On 13/11/2020 08:48, kajoljain wrote: >> >> On 11/6/20 6:05 PM, John Garry wrote: >>> Currently only upto a level 2 directory is supported, in form >>> vendor/platform. >> Hi John, >> Just want to check in case of sub directories, >> Will it be good add on/feasible to be able to include events of particular >> sub-directory for a >> platform? Otherwise with this patch in the end all event will be part of >> same pmu_event structure. So what is the purpose of sub directories? Let me >> know if I am missing something. > > Hi Kajol Jain, > > So currently we support both of the following structure: > arch/platform > arch/vendor/platform/ > > arch/vendor/platform/ is for an arch like arm, where the arch provider may > not be the vendor. > > I want to go one step further, to support also: > arch/vendor/platform/cpu > arch/vendor/platform/sys > > Here we have separate folders for cpu and sys events. CPU events in "cpu" > folder are added to pmu_events_map[], as before. And events in "sys" folder > are added from patch 2/13 to new table pmu_sys_events_table[]. > > I hope it's clearer now. Hi John, Thanks for explaining. This patch looks good to me then. Reviewed-By: Kajol Jain Thanks, Kajol Jain > > Thanks, > John > >> >> Thanks, >> Kajol Jain >>> Add support for a further level, to support vendor/platform >>> sub-directories in future. >
