Re: [PATCH] Revert "ARM: dts: bcm2711: Add the BSC interrupt controller"

[Maxime Ripard]

On Fri, Feb 12, 2021 at 11:11:04AM -0800, Florian Fainelli wrote:
> As Dave reported:
> 
> This seems to have unintended side effects.  GIC interrupt 117 is shared
> between the standard I2C controllers (i2c-bcm2835) and the l2-intc block
> handling the HDMI I2C interrupts.
> 
> There is not a great way to share an interrupt between an interrupt
> controller using the chained IRQ handler which is an interrupt flow and
> another driver like i2c-bcm2835 which uses an interrupt handler
> (although it specifies IRQF_SHARED).
> 
> Simply revert this change for now which will mean that HDMI I2C will be
> polled, like it was before.
> 
> Reported-by: Dave Stevenson 
> Signed-off-by: Florian Fainelli 

Acked-by: Maxime Ripard 

Thanks!
Maxime


signature.asc
Description: PGP signature

Re: [PATCH 2/2] ath9k: fix ath_tx_process_buffer() potential null ptr dereference

[Felix Fietkau]

On 2021-02-16 08:03, Kalle Valo wrote:
> Shuah Khan  wrote:
> 
>> ath_tx_process_buffer() references ieee80211_find_sta_by_ifaddr()
>> return pointer (sta) outside null check. Fix it by moving the code
>> block under the null check.
>> 
>> This problem was found while reviewing code to debug RCU warn from
>> ath10k_wmi_tlv_parse_peer_stats_info() and a subsequent manual audit
>> of other callers of ieee80211_find_sta_by_ifaddr() that don't hold
>> RCU read lock.
>> 
>> Signed-off-by: Shuah Khan 
>> Signed-off-by: Kalle Valo 
> 
> Patch applied to ath-next branch of ath.git, thanks.
> 
> a56c14bb21b2 ath9k: fix ath_tx_process_buffer() potential null ptr dereference
I just took another look at this patch, and it is completely bogus.
Not only does the stated reason not make any sense (sta is simply passed
to other functions, not dereferenced without checks), but this also
introduces a horrible memory leak by skipping buffer completion if sta
is NULL.
Please drop it, the code is fine as-is.

- Felix

RE: [PATCH] PCI : check if type 0 devices have all BARs of size zero

[Wasim Khan]

Hi Bjorn,


> -Original Message-
> From: Bjorn Helgaas 
> Sent: Tuesday, February 16, 2021 2:43 AM
> To: Wasim Khan (OSS) 
> Cc: bhelg...@google.com; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Wasim Khan 
> Subject: Re: [PATCH] PCI : check if type 0 devices have all BARs of size zero
> 
> On Fri, Feb 12, 2021 at 11:08:56AM +0100, Wasim Khan wrote:
> > From: Wasim Khan 
> >
> > Log a message if all BARs of type 0 devices are of size zero. This can
> > help detecting type 0 devices not reporting BAR size correctly.
> 
> I could be missing something, but I don't think we can do this.  I would 
> think the
> simplest possible presilicon testing would find errors like this, and the 
> first
> attempt to have a driver claim the device would fail if required BARs were
> missing, so I'm not sure what this would add.
> 

Thank you for the review.
I observed this issue with an under development EP. Due to some logic problem 
in EP's firmware, the BAR sizes were reported zero and crash was observed 
sometime later in PCIe code. 
I agree with you that such issues should have been caught in pre-silicon 
testing, but not sure of pre-si testing details and if the issue was 
specifically observed with real OS. Also, because the EP is in early stage of 
development, device driver of EP is not available as of now. 
So, I though it will be a good idea to print an information message only for 
*type 0* devices to give a quick hint if the zero BAR size is expected for the 
given EP or not. So that SW can contribute to identify HW problem.

> While the subject line says "type 0 devices," this code path is also used for 
> type
> 1 devices (bridges), and it's quite common for bridges to have no BARs, which
> means they would all be hardwired to zero.
> 

Yes, for type 1 devices, it is common to have zero BAR size, so I added log msg 
for type 0 devices only , which are in-general expected to have valid BARs.


> It is also legal for even type 0 devices to implement no BARs.  They may be
> operated entirely via config space or via device-specific BARs that are 
> unknown
> to the PCI core.

OK, I did not know this . Thank you for sharing this.

> 
> > Signed-off-by: Wasim Khan 
> > ---
> >  drivers/pci/probe.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index
> > 953f15abc850..6438d6d56777 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -321,6 +321,7 @@ int __pci_read_base(struct pci_dev *dev, enum
> > pci_bar_type type,  static void pci_read_bases(struct pci_dev *dev,
> > unsigned int howmany, int rom)  {
> > unsigned int pos, reg;
> > +   bool found = false;
> >
> > if (dev->non_compliant_bars)
> > return;
> > @@ -333,8 +334,12 @@ static void pci_read_bases(struct pci_dev *dev,
> unsigned int howmany, int rom)
> > struct resource *res = >resource[pos];
> > reg = PCI_BASE_ADDRESS_0 + (pos << 2);
> > pos += __pci_read_base(dev, pci_bar_unknown, res, reg);
> > +   found |= res->flags ? 1 : 0;
> > }
> >
> > +   if (!dev->hdr_type && !found)
> > +   pci_info(dev, "BAR size is 0 for BAR[0..%d]\n", howmany - 1);
> > +
> > if (rom) {
> > struct resource *res = >resource[PCI_ROM_RESOURCE];
> > dev->rom_base_reg = rom;
> > --
> > 2.25.1
> >

Re: [PATCH 0/3] MAINTAINERS: update STMicroelectronics email

[Patrice CHOTARD]

Hi Arnd

On 2/15/21 3:19 PM, Arnd Bergmann wrote:
> On Mon, Feb 15, 2021 at 2:17 PM Patrice CHOTARD
>  wrote:
>>
>> Hi Arnd, Olof, Kevin
>>
>> What is the best way to get this series merged ?
>> Do you pick it and apply it directly, or do we integrate it in the next 
>> STM32 pull request ?
> 
> I usually pick up updates to the MAINTAINERS file as bugfixes, so
> either send them as part of the fixes pull request, or forward them
> to s...@kernel.org to apply directly.
> 
> If you cc me on patches for a particular platform, I usually just ignore them,
> unless they get sent to s...@kernel.org, and in that case I will either apply
> them or ask back if they were meant for us.
> 
>   Arnd
> 

Ok, i will resend this series to s...@kernel.org.
Thanks
Patrice

Re: [PATCH] i2c: exynos5: Preserve high speed master code

[Krzysztof Kozlowski]

On Mon, Feb 15, 2021 at 08:03:21PM +0100, Mårten Lindahl wrote:
> From: Mårten Lindahl 
> 
> When the controller starts to send a message with the MASTER_ID field
> set (high speed), the whole I2C_ADDR register is overwritten including
> MASTER_ID as the SLV_ADDR_MAS field is set.

Are you here describing bug in driver or hardware (the controller?)?
Looking at the code, I think the driver, but description got me
confused.

> 
> This patch preserves already written fields in I2C_ADDR when writing
> SLV_ADDR_MAS.
> 
> Signed-off-by: Mårten Lindahl 
> ---
>  drivers/i2c/busses/i2c-exynos5.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-exynos5.c 
> b/drivers/i2c/busses/i2c-exynos5.c
> index 20a9881a0d6c..f2d04c241299 100644
> --- a/drivers/i2c/busses/i2c-exynos5.c
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -606,6 +606,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c 
> *i2c, int stop)
>   u32 i2c_ctl;
>   u32 int_en = 0;
>   u32 i2c_auto_conf = 0;
> + u32 i2c_addr = 0;
>   u32 fifo_ctl;
>   unsigned long flags;
>   unsigned short trig_lvl;
> @@ -640,7 +641,12 @@ static void exynos5_i2c_message_start(struct exynos5_i2c 
> *i2c, int stop)
>   int_en |= HSI2C_INT_TX_ALMOSTEMPTY_EN;
>   }
>  
> - writel(HSI2C_SLV_ADDR_MAS(i2c->msg->addr), i2c->regs + HSI2C_ADDR);
> + i2c_addr = HSI2C_SLV_ADDR_MAS(i2c->msg->addr);
> +
> + if (i2c->op_clock >= I2C_MAX_FAST_MODE_PLUS_FREQ)
> + i2c_addr |= readl(i2c->regs + HSI2C_ADDR);

Any reason why not "|= MASTER_ID(i2c->adap.nr)" here instead of more
expensive IO read? It's quite important because your current code will
bitwise-or old I2C slave address with a new one... This should break
during tests with multiple I2C slave devices, shouldn't it?

On which HW did you test it?

Best regards,
Krzysztof


> +
> + writel(i2c_addr, i2c->regs + HSI2C_ADDR);

[RESEND PATCH 1/3] MAINTAINERS: Update some st.com email addresses to foss.st.com

[patrice.chotard]

From: Patrice Chotard 

Update some st.com to foss.st.com addresses related to STMicroelectronics
drivers. All these people will now use this new email address for upstream
activities.

Signed-off-by: Patrice Chotard 
---
 MAINTAINERS | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 667d03852191..98802b71385b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2504,7 +2504,7 @@ N:sc27xx
 N: sc2731
 
 ARM/STI ARCHITECTURE
-M: Patrice Chotard 
+M: Patrice Chotard 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 W: http://www.stlinux.com
@@ -2537,7 +2537,7 @@ F:include/linux/remoteproc/st_slim_rproc.h
 
 ARM/STM32 ARCHITECTURE
 M: Maxime Coquelin 
-M: Alexandre Torgue 
+M: Alexandre Torgue 
 L: linux-st...@st-md-mailman.stormreply.com (moderated for non-subscribers)
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
@@ -3149,7 +3149,7 @@ C:irc://irc.oftc.net/bcache
 F: drivers/md/bcache/
 
 BDISP ST MEDIA DRIVER
-M: Fabien Dessenne 
+M: Fabien Dessenne 
 L: linux-me...@vger.kernel.org
 S: Supported
 W: https://linuxtv.org
@@ -5042,7 +5042,7 @@ S:Maintained
 F: drivers/platform/x86/dell-wmi.c
 
 DELTA ST MEDIA DRIVER
-M: Hugues Fruchet 
+M: Hugues Fruchet 
 L: linux-me...@vger.kernel.org
 S: Supported
 W: https://linuxtv.org
@@ -5974,8 +5974,8 @@ F:
Documentation/devicetree/bindings/display/st,stih4xx.txt
 F: drivers/gpu/drm/sti
 
 DRM DRIVERS FOR STM
-M: Yannick Fertre 
-M: Philippe Cornu 
+M: Yannick Fertre 
+M: Philippe Cornu 
 M: Benjamin Gaignard 
 M: Vincent Abriou 
 L: dri-de...@lists.freedesktop.org
@@ -8196,7 +8196,7 @@ F:include/linux/hugetlb.h
 F: mm/hugetlb.c
 
 HVA ST MEDIA DRIVER
-M: Jean-Christophe Trotin 
+M: Jean-Christophe Trotin 
 L: linux-me...@vger.kernel.org
 S: Supported
 W: https://linuxtv.org
@@ -11101,7 +11101,7 @@ T:  git git://linuxtv.org/media_tree.git
 F: drivers/media/dvb-frontends/stv6111*
 
 MEDIA DRIVERS FOR STM32 - DCMI
-M: Hugues Fruchet 
+M: Hugues Fruchet 
 L: linux-me...@vger.kernel.org
 S: Supported
 T: git git://linuxtv.org/media_tree.git
@@ -16813,7 +16813,7 @@ F:  
Documentation/devicetree/bindings/media/i2c/st,st-mipid02.txt
 F: drivers/media/i2c/st-mipid02.c
 
 ST STM32 I2C/SMBUS DRIVER
-M: Pierre-Yves MORDRET 
+M: Pierre-Yves MORDRET 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: drivers/i2c/busses/i2c-stm32*
@@ -16944,7 +16944,7 @@ S:  Maintained
 F: drivers/block/skd*[ch]
 
 STI AUDIO (ASoC) DRIVERS
-M: Arnaud Pouliquen 
+M: Arnaud Pouliquen 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
 S: Maintained
 F: Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt
@@ -16964,15 +16964,15 @@ T:git git://linuxtv.org/media_tree.git
 F: drivers/media/usb/stk1160/
 
 STM32 AUDIO (ASoC) DRIVERS
-M: Olivier Moysan 
-M: Arnaud Pouliquen 
+M: Olivier Moysan 
+M: Arnaud Pouliquen 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
 S: Maintained
 F: Documentation/devicetree/bindings/iio/adc/st,stm32-*.yaml
 F: sound/soc/stm/
 
 STM32 TIMER/LPTIMER DRIVERS
-M: Fabrice Gasnier 
+M: Fabrice Gasnier 
 S: Maintained
 F: Documentation/ABI/testing/*timer-stm32
 F: Documentation/devicetree/bindings/*/*stm32-*timer*
@@ -16982,7 +16982,7 @@ F:  include/linux/*/stm32-*tim*
 
 STMMAC ETHERNET DRIVER
 M: Giuseppe Cavallaro 
-M: Alexandre Torgue 
+M: Alexandre Torgue 
 M: Jose Abreu 
 L: net...@vger.kernel.org
 S: Supported
-- 
2.17.1

[RESEND PATCH 3/3] MAINTAINERS: Add Alain Volmat as STM32 I2C/SMBUS maintainer

[patrice.chotard]

From: Patrice Chotard 

Add Alain Volmat as STM32 I2C/SMBUS driver co-maintainer.

Signed-off-by: Patrice Chotard 
Cc: alain.vol...@foss.st.com
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c6266d311061..7de268e4aec0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16812,6 +16812,7 @@ F:  drivers/media/i2c/st-mipid02.c
 
 ST STM32 I2C/SMBUS DRIVER
 M: Pierre-Yves MORDRET 
+M: Alain Volmat 
 L: linux-...@vger.kernel.org
 S: Maintained
 F: drivers/i2c/busses/i2c-stm32*
-- 
2.17.1

[RESEND PATCH 0/3] MAINTAINERS: update STMicroelectronics email

[patrice.chotard]

From: Patrice Chotard 

This series:
  _ Update st.com to foss.st.com email for some maintainers.
  _ Remove Vincent Abriou as STI/STM DRM driver
  _ Add Alain Volmat as STM32 I2C/SMBUS driver maintainer

Patrice Chotard (3):
  MAINTAINERS: Update some st.com email addresses to foss.st.com
  MAINTAINERS: Remove Vincent Abriou for STM/STI DRM drivers.
  MAINTAINERS: Add Alain Volmat as STM32 I2C/SMBUS maintainer

 MAINTAINERS | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

-- 
2.17.1

[RESEND PATCH 2/3] MAINTAINERS: Remove Vincent Abriou for STM/STI DRM drivers.

[patrice.chotard]

From: Patrice Chotard 

Remove Vincent Abriou's email as he has no more review activities on
STM/STI DRM drivers.

Signed-off-by: Patrice Chotard 
Cc: Vincent Abriou 
---
 MAINTAINERS | 2 --
 1 file changed, 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 98802b71385b..c6266d311061 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5966,7 +5966,6 @@ F:drivers/gpu/drm/rockchip/
 
 DRM DRIVERS FOR STI
 M: Benjamin Gaignard 
-M: Vincent Abriou 
 L: dri-de...@lists.freedesktop.org
 S: Maintained
 T: git git://anongit.freedesktop.org/drm/drm-misc
@@ -5977,7 +5976,6 @@ DRM DRIVERS FOR STM
 M: Yannick Fertre 
 M: Philippe Cornu 
 M: Benjamin Gaignard 
-M: Vincent Abriou 
 L: dri-de...@lists.freedesktop.org
 S: Maintained
 T: git git://anongit.freedesktop.org/drm/drm-misc
-- 
2.17.1

Re: [PATCH] perf tools: Add OCaml demangling

[Namhyung Kim]

Hello,

(+ Cc: LKML)

On Thu, Feb 4, 2021 at 6:22 AM Fabian Hemmer  wrote:
>
> Detect symbols generated by the OCaml compiler based on their prefix.
>
> Demangle OCaml symbols, returning a newly allocated string (like the
> existing Java demangling functionality).
>
> Move a helper function (hex) from tests/code-reading.c to util/string.c
>
> To test:
>
> echo 'Printf.printf "%d\n" (Random.int 42)' > test.ml
> perf record ocamlopt.opt test.ml
> perf report -d ocamlopt.opt
>
> Signed-off-by: Fabian Hemmer 

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>  tools/perf/tests/Build |  1 +
>  tools/perf/tests/builtin-test.c|  4 ++
>  tools/perf/tests/code-reading.c| 10 +---
>  tools/perf/tests/demangle-ocaml-test.c | 43 ++
>  tools/perf/tests/tests.h   |  1 +
>  tools/perf/util/Build  |  1 +
>  tools/perf/util/demangle-ocaml.c   | 80 ++
>  tools/perf/util/demangle-ocaml.h   |  7 +++
>  tools/perf/util/string.c   |  9 +++
>  tools/perf/util/string2.h  |  2 +
>  tools/perf/util/symbol-elf.c   |  9 ++-
>  11 files changed, 156 insertions(+), 11 deletions(-)
>  create mode 100644 tools/perf/tests/demangle-ocaml-test.c
>  create mode 100644 tools/perf/util/demangle-ocaml.c
>  create mode 100644 tools/perf/util/demangle-ocaml.h
>
> diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
> index aa4dc4f5abde..650aec19d490 100644
> --- a/tools/perf/tests/Build
> +++ b/tools/perf/tests/Build
> @@ -58,6 +58,7 @@ perf-y += time-utils-test.o
>  perf-y += genelf.o
>  perf-y += api-io.o
>  perf-y += demangle-java-test.o
> +perf-y += demangle-ocaml-test.o
>  perf-y += pfm.o
>  perf-y += parse-metric.o
>  perf-y += pe-file-parsing.o
> diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
> index 7273823d0d02..c4b888f18e9c 100644
> --- a/tools/perf/tests/builtin-test.c
> +++ b/tools/perf/tests/builtin-test.c
> @@ -338,6 +338,10 @@ static struct test generic_tests[] = {
> .desc = "Demangle Java",
> .func = test__demangle_java,
> },
> +   {
> +   .desc = "Demangle OCaml",
> +   .func = test__demangle_ocaml,
> +   },
> {
> .desc = "Parse and process metrics",
> .func = test__parse_metric,
> diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
> index 7c098d49c77e..280f0348a09c 100644
> --- a/tools/perf/tests/code-reading.c
> +++ b/tools/perf/tests/code-reading.c
> @@ -26,6 +26,7 @@
>  #include "event.h"
>  #include "record.h"
>  #include "util/mmap.h"
> +#include "util/string2.h"
>  #include "util/synthetic-events.h"
>  #include "thread.h"
>
> @@ -41,15 +42,6 @@ struct state {
> size_t done_cnt;
>  };
>
> -static unsigned int hex(char c)
> -{
> -   if (c >= '0' && c <= '9')
> -   return c - '0';
> -   if (c >= 'a' && c <= 'f')
> -   return c - 'a' + 10;
> -   return c - 'A' + 10;
> -}
> -
>  static size_t read_objdump_chunk(const char **line, unsigned char **buf,
>  size_t *buf_len)
>  {
> diff --git a/tools/perf/tests/demangle-ocaml-test.c 
> b/tools/perf/tests/demangle-ocaml-test.c
> new file mode 100644
> index ..a273ed5163d7
> --- /dev/null
> +++ b/tools/perf/tests/demangle-ocaml-test.c
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include 
> +#include 
> +#include 
> +#include "tests.h"
> +#include "session.h"
> +#include "debug.h"
> +#include "demangle-ocaml.h"
> +
> +int test__demangle_ocaml(struct test *test __maybe_unused, int subtest 
> __maybe_unused)
> +{
> +   int ret = TEST_OK;
> +   char *buf = NULL;
> +   size_t i;
> +
> +   struct {
> +   const char *mangled, *demangled;
> +   } test_cases[] = {
> +   { "main",
> + NULL },
> +   { "camlStdlib__array__map_154",
> + "Stdlib.array.map" },
> +   { 
> "camlStdlib__anon_fn$5bstdlib$2eml$3a334$2c0$2d$2d54$5d_1453",
> + "Stdlib.anon_fn[stdlib.ml:334,0--54]" },
> +   { "camlStdlib__bytes__$2b$2b_2205",
> + "Stdlib.bytes.++" },
> +   };
> +
> +   for (i = 0; i < sizeof(test_cases) / sizeof(test_cases[0]); i++) {
> +   buf = ocaml_demangle_sym(test_cases[i].mangled);
> +   if ((buf == NULL && test_cases[i].demangled != NULL)
> +   || (buf != NULL && test_cases[i].demangled == 
> NULL)
> +   || (buf != NULL && strcmp(buf, 
> test_cases[i].demangled))) {
> +   pr_debug("FAILED: %s: %s != %s\n", 
> test_cases[i].mangled,
> +buf == NULL ? "(null)" : buf,
> +test_cases[i].demangled == NULL ? "(null)" : 
> test_cases[i].demangled);
> +   ret = 

Re: [PATCH net-next RFC v3] net: hdlc_x25: Queue outgoing LAPB frames

[Leon Romanovsky]

On Mon, Feb 15, 2021 at 11:30:25PM -0800, Xie He wrote:
> On Mon, Feb 15, 2021 at 10:04 PM Leon Romanovsky  wrote:
> >
> > On Mon, Feb 15, 2021 at 11:08:02AM -0800, Xie He wrote:
> > > On Mon, Feb 15, 2021 at 10:54 AM Leon Romanovsky  wrote:
> > > >
> > > > On Mon, Feb 15, 2021 at 09:23:32AM -0800, Xie He wrote:
> > > > > On Mon, Feb 15, 2021 at 1:25 AM Leon Romanovsky  
> > > > > wrote:
> > > > > >
> > > > > > > + /* When transmitting data:
> > > > > > > +  * first we'll remove a pseudo header of 1 byte,
> > > > > > > +  * then the LAPB module will prepend an LAPB header of at 
> > > > > > > most 3 bytes.
> > > > > > > +  */
> > > > > > > + dev->needed_headroom = 3 - 1;
> > > > > >
> > > > > > 3 - 1 = 2
> > > > > >
> > > > > > Thanks
> > > > >
> > > > > Actually this is intentional. It makes the numbers more meaningful.
> > > > >
> > > > > The compiler should automatically generate the "2" so there would be
> > > > > no runtime penalty.
> > > >
> > > > If you want it intentional, write it in the comment.
> > > >
> > > > /* When transmitting data, we will need extra 2 bytes headroom,
> > > >  * which are 3 bytes of LAPB header minus one byte of pseudo header.
> > > >  */
> > > >  dev->needed_headroom = 2;
> > >
> > > I think this is unnecessary. The current comment already explains the
> > > meaning of the "1" and the "3". There's no need for a reader of this
> > > code to understand what a "2" is. That is the job of the compiler, not
> > > the human reader.
> >
> > It is not related to compiler/human format. If you need to write "3 - 1"
> > to make it easy for users, it means that your comment above is not
> > full/correct/e.t.c.
>
> My point is: there is no need for human programmers / code readers to
> understand what this "2" is. There is no need to explain what this "2"
> means in the comment. There is no need to write this "2" in the code.
> There is no need for this "2" to appear anywhere. That is just an
> intermediate result generated by the compiler. It is similar to
> assembly or machine code. It is generated by the compiler. Human
> programmers just don't care about this intermediate result.
>
> My point could be more apparent if you consider a more complex
> situation: "3 - 1 + 2 + 4 + 2". No human would want to see a
> meaningless "10" in the code. We want to see the meaning of the
> numbers, not a meaningless intermediate calculation result.

Right, and we are using defines for that.

Thanks

Re: [PATCH] vdpa/mlx5: Extract correct pointer from driver data

[Leon Romanovsky]

On Tue, Feb 16, 2021 at 08:42:26AM +0200, Eli Cohen wrote:
> On Tue, Feb 16, 2021 at 08:35:51AM +0200, Leon Romanovsky wrote:
> > On Tue, Feb 16, 2021 at 07:50:22AM +0200, Eli Cohen wrote:
> > > struct mlx5_vdpa_net pointer was stored in drvdata. Extract it as well
> > > in mlx5v_remove().
> > >
> > > Fixes: 74c9729dd892 ("vdpa/mlx5: Connect mlx5_vdpa to auxiliary bus")
> > > Signed-off-by: Eli Cohen 
> > > ---
> > >  drivers/vdpa/mlx5/net/mlx5_vnet.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
> > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > index 6b0a42183622..4103d3b64a2a 100644
> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > @@ -2036,9 +2036,9 @@ static int mlx5v_probe(struct auxiliary_device 
> > > *adev,
> > >
> > >  static void mlx5v_remove(struct auxiliary_device *adev)
> > >  {
> > > - struct mlx5_vdpa_dev *mvdev = dev_get_drvdata(>dev);
> > > + struct mlx5_vdpa_net *ndev = dev_get_drvdata(>dev);
> > >
> > > - vdpa_unregister_device(>vdev);
> > > + vdpa_unregister_device(>mvdev.vdev);
> > >  }
> >
> > IMHO, The more correct solution is to fix dev_set_drvdata() call,
> > because we are regustering/unregistering/allocating "struct mlx5_vdpa_dev".
> >
>
> We're allocating "struct mlx5_vdpa_net". "struct mlx5_vdpa_dev" is just
> a member field of "struct mlx5_vdpa_net".

I referred to these lines in the mlx5v_probe():
  1986 err = mlx5_vdpa_alloc_resources(>mvdev);
  1987 if (err)
  1988 goto err_mtu;
  1989
  1990 err = alloc_resources(ndev);
  1991 if (err)
  1992 goto err_res;
  1993
  1994 err = vdpa_register_device(>vdev);

So mlx5v_remove() is better to be symmetrical.

Thanks

>
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index 88dde3455bfd..079b8fe669af 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -1995,7 +1995,7 @@ static int mlx5v_probe(struct auxiliary_device *adev,
> > if (err)
> > goto err_reg;
> >
> > -   dev_set_drvdata(>dev, ndev);
> > +   dev_set_drvdata(>dev, mvdev);
> > return 0;
> >
> >  err_reg:
> >
> > >
> > >  static const struct auxiliary_device_id mlx5v_id_table[] = {
> >
> > > --
> > > 2.29.2
> > >

Re: [PATCH v2 1/1] arm64: mm: correct the inside linear map boundaries during hotplug check

[Ard Biesheuvel]

On Tue, 16 Feb 2021 at 04:12, Anshuman Khandual
 wrote:
>
>
>
> On 2/16/21 1:21 AM, Pavel Tatashin wrote:
> > On Mon, Feb 15, 2021 at 2:34 PM Ard Biesheuvel  wrote:
> >>
> >> On Mon, 15 Feb 2021 at 20:30, Pavel Tatashin  
> >> wrote:
> >>>
>  Can't we simply use signed arithmetic here? This expression works fine
>  if the quantities are all interpreted as s64 instead of u64
> >>>
> >>> I was thinking about that, but I do not like the idea of using sign
> >>> arithmetics for physical addresses. Also, I am worried that someone in
> >>> the future will unknowingly change it to unsigns or to phys_addr_t. It
> >>> is safer to have start explicitly set to 0 in case of wrap.
> >>
> >> memstart_addr is already a s64 for this exact reason.
> >
> > memstart_addr is basically an offset and it must be negative. For
> > example, this would not work if it was not signed:
> > #define vmemmap ((struct page *)VMEMMAP_START - (memstart_addr >> 
> > PAGE_SHIFT))
> >
> > However, on powerpc it is phys_addr_t type.
> >
> >>
> >> Btw, the KASLR check is incorrect: memstart_addr could also be
> >> negative when running the 52-bit VA kernel on hardware that is only
> >> 48-bit VA capable.
> >
> > Good point!
> >
> > if (IS_ENABLED(CONFIG_ARM64_VA_BITS_52) && (vabits_actual != 52))
> > memstart_addr -= _PAGE_OFFSET(48) - _PAGE_OFFSET(52);
> >
> > So, I will remove IS_ENABLED(CONFIG_RANDOMIZE_BASE) again.
> >
> > I am OK to change start_linear_pa, end_linear_pa to signed, but IMO
> > what I have now is actually safer to make sure that does not break
> > again in the future.
> An explicit check for the flip over and providing two different start
> addresses points would be required in order to use the new framework.

I don't think so. We no longer randomize over the same range, but take
the support PA range into account. (97d6786e0669d)

This should ensure that __pa(_PAGE_OFFSET(vabits_actual)) never
assumes a negative value. And to Pavel's point re 48/52 bit VAs: the
fact that vabits_actual appears in this expression means that it
already takes this into account, so you are correct that we don't have
to care about that here.

So even if memstart_addr could be negative, this expression should
never produce a negative value. And with the patch above applied, it
should never do so when running under KASLR either.

So question to Pavel and Tyler: could you please check whether you
have that patch, and whether it fixes the issue? It was introduced in
v5.11, and hasn't been backported yet (it wasn't marked for -stable)

Re: [PATCH] perf metricgroup: remove unneeded semicolon

[Namhyung Kim]

Hello,

On Mon, Feb 1, 2021 at 4:41 PM Yang Li  wrote:
>
> Eliminate the following coccicheck warning:
> ./tools/perf/util/metricgroup.c:382:3-4: Unneeded semicolon
>
> Reported-by: Abaci Robot 
> Signed-off-by: Yang Li 

Acked-by: Namhyung Kim 

Thanks,
Namhyung

> ---
>  tools/perf/util/metricgroup.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index e6d3452..26c990e 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -379,7 +379,7 @@ static int metricgroup__setup_events(struct list_head 
> *groups,
> metric_refs[i].metric_expr = ref->metric_expr;
> i++;
> }
> -   };
> +   }
>
> expr->metric_refs = metric_refs;
> expr->metric_expr = m->metric_expr;
> --
> 1.8.3.1
>

Re: [PATCH] bus: mhi: core: Fix check for syserr at power_up

[Manivannan Sadhasivam]

On Fri, Feb 12, 2021 at 02:27:23PM -0700, Jeffrey Hugo wrote:
> The check to see if we have reset the device after detecting syserr at
> power_up is inverted.  wait_for_event_timeout() returns 0 on failure,
> and a positive value on success.  The check is looking for non-zero
> as a failure, which is likely to incorrectly cause a device init failure
> if syserr was detected at power_up.  Fix this.
> 
> Fixes: e18d4e9fa79b ("bus: mhi: core: Handle syserr during power_up")
> Signed-off-by: Jeffrey Hugo 

Reviewed-by: Manivannan Sadhasivam 

Thanks,
Mani

> ---
>  drivers/bus/mhi/core/pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index 681960c..36ab7aa 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -1092,7 +1092,7 @@ int mhi_async_power_up(struct mhi_controller *mhi_cntrl)
>  ) ||
>   !val,
>   msecs_to_jiffies(mhi_cntrl->timeout_ms));
> - if (ret) {
> + if (!ret) {
>   ret = -EIO;
>   dev_info(dev, "Failed to reset MHI due to syserr 
> state\n");
>   goto error_bhi_offset;
> -- 
> Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.
> 

Re: [PATCH v2 25/25] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree

[Krzysztof Kozlowski]

On Mon, Feb 15, 2021 at 01:00:58PM -0800, Randy Dunlap wrote:
> On 2/15/21 11:29 AM, Krzysztof Kozlowski wrote:
> >> diff --git a/arch/arm64/boot/dts/apple/apple-j274.dts 
> >> b/arch/arm64/boot/dts/apple/apple-j274.dts
> >> new file mode 100644
> >> index ..9a1be91a2cf0
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/apple/apple-j274.dts
> >> @@ -0,0 +1,41 @@
> >> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> > () around licenses, so:
> > (GPL-2.0+ OR MIT)
> 
> Hi,
> When/where does that "() around licenses" apply, please?

Hmm, somehow this pattern got into me but now I checked on the spdx.dev
and the preferred syntax is indeed without (). Skip this comment then.

Best regards,
Krzysztof

Re: [PATCH] bus: mhi: core: Use current ee in intvec handler for syserr

[Manivannan Sadhasivam]

On Fri, Feb 12, 2021 at 05:40:14PM -0700, Jeffrey Hugo wrote:
> The intvec handler stores the caches ee in a local variable for use in
> processing the intvec.  When determining if a syserr is a fatal error or
> not, the intvec handler is using the cached version, when it should be
> using the current ee read from the device.  Currently, the device could
> be in the PBL ee as the result of a fatal error, but the cached ee might
> be AMSS, which would cause the intvec handler to incorrectly signal a
> non-fatal syserr.
> 
> Fixes: 3000f85b8f47 ("bus: mhi: core: Add support for basic PM operations")
> Signed-off-by: Jeffrey Hugo 

Reviewed-by: Manivannan Sadhasivam 

Thanks,
Mani

> ---
>  drivers/bus/mhi/core/main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 4e0131b..f182736 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -448,7 +448,7 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
> void *priv)
>   wake_up_all(_cntrl->state_event);
>  
>   /* For fatal errors, we let controller decide next step */
> - if (MHI_IN_PBL(ee))
> + if (MHI_IN_PBL(mhi_cntrl->ee))
>   mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_FATAL_ERROR);
>   else
>   mhi_pm_sys_err_handler(mhi_cntrl);
> -- 
> Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.
> 

Re: [PATCH net-next RFC v3] net: hdlc_x25: Queue outgoing LAPB frames

[Xie He]

On Mon, Feb 15, 2021 at 10:04 PM Leon Romanovsky  wrote:
>
> On Mon, Feb 15, 2021 at 11:08:02AM -0800, Xie He wrote:
> > On Mon, Feb 15, 2021 at 10:54 AM Leon Romanovsky  wrote:
> > >
> > > On Mon, Feb 15, 2021 at 09:23:32AM -0800, Xie He wrote:
> > > > On Mon, Feb 15, 2021 at 1:25 AM Leon Romanovsky  wrote:
> > > > >
> > > > > > + /* When transmitting data:
> > > > > > +  * first we'll remove a pseudo header of 1 byte,
> > > > > > +  * then the LAPB module will prepend an LAPB header of at 
> > > > > > most 3 bytes.
> > > > > > +  */
> > > > > > + dev->needed_headroom = 3 - 1;
> > > > >
> > > > > 3 - 1 = 2
> > > > >
> > > > > Thanks
> > > >
> > > > Actually this is intentional. It makes the numbers more meaningful.
> > > >
> > > > The compiler should automatically generate the "2" so there would be
> > > > no runtime penalty.
> > >
> > > If you want it intentional, write it in the comment.
> > >
> > > /* When transmitting data, we will need extra 2 bytes headroom,
> > >  * which are 3 bytes of LAPB header minus one byte of pseudo header.
> > >  */
> > >  dev->needed_headroom = 2;
> >
> > I think this is unnecessary. The current comment already explains the
> > meaning of the "1" and the "3". There's no need for a reader of this
> > code to understand what a "2" is. That is the job of the compiler, not
> > the human reader.
>
> It is not related to compiler/human format. If you need to write "3 - 1"
> to make it easy for users, it means that your comment above is not
> full/correct/e.t.c.

My point is: there is no need for human programmers / code readers to
understand what this "2" is. There is no need to explain what this "2"
means in the comment. There is no need to write this "2" in the code.
There is no need for this "2" to appear anywhere. That is just an
intermediate result generated by the compiler. It is similar to
assembly or machine code. It is generated by the compiler. Human
programmers just don't care about this intermediate result.

My point could be more apparent if you consider a more complex
situation: "3 - 1 + 2 + 4 + 2". No human would want to see a
meaningless "10" in the code. We want to see the meaning of the
numbers, not a meaningless intermediate calculation result.

Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys

[Jarkko Sakkinen]

On Mon, Feb 15, 2021 at 06:37:00PM +0530, Sumit Garg wrote:
> On Fri, 12 Feb 2021 at 05:04, Jarkko Sakkinen  wrote:
> >
> > On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> > > Hi Jarkko,
> > >
> > > On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen  wrote:
> > > >
> > > > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > > > >
> > > > >
> > > > > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > > > > > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> > > > > >> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > > > >  On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> > > > > > On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen 
> > > > > >  wrote:
> > > > > >>
> > > > > >> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen 
> > > > > >> wrote:
> > > > > >>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > > > >  On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen 
> > > > >   wrote:
> > > > > >
> > > > > > On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > > > >> Hi Jarkko,
> > > > > >>
> > > > > >> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen 
> > > > > >>  wrote:
> > > > > >>>
> > > > > >>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg 
> > > > > >>> wrote:
> > > > >  Add support for TEE based trusted keys where TEE 
> > > > >  provides the functionality
> > > > >  to seal and unseal trusted keys using hardware unique 
> > > > >  key.
> > > > > 
> > > > >  Refer to Documentation/tee.txt for detailed information 
> > > > >  about TEE.
> > > > > 
> > > > >  Signed-off-by: Sumit Garg 
> > > > > >>>
> > > > > >>> I haven't yet got QEMU environment working with aarch64, 
> > > > > >>> this produces
> > > > > >>> just a blank screen:
> > > > > >>>
> > > > > >>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu 
> > > > > >>> cortex-a53 -smp 1 -kernel output/images/Image -initrd 
> > > > > >>> output/images/rootfs.cpio -serial stdio
> > > > > >>>
> > > > > >>> My BuildRoot fork for TPM and keyring testing is located 
> > > > > >>> over here:
> > > > > >>>
> > > > > >>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > > > >>>
> > > > > >>> The "ARM version" is at this point in aarch64 branch. 
> > > > > >>> Over time I will
> > > > > >>> define tpmdd-x86_64 and tpmdd-aarch64 boards and 
> > > > > >>> everything will be then
> > > > > >>> in the master branch.
> > > > > >>>
> > > > > >>> To create identical images you just need to
> > > > > >>>
> > > > > >>> $ make tpmdd_defconfig && make
> > > > > >>>
> > > > > >>> Can you check if you see anything obviously wrong? I'm 
> > > > > >>> eager to test this
> > > > > >>> patch set, and in bigger picture I really need to have 
> > > > > >>> ready to run
> > > > > >>> aarch64 environment available.
> > > > > >>
> > > > > >> I would rather suggest you to follow steps listed here [1] 
> > > > > >> as to test
> > > > > >> this feature on Qemu aarch64 we need to build firmwares 
> > > > > >> such as TF-A,
> > > > > >> OP-TEE, UEFI etc. which are all integrated into OP-TEE 
> > > > > >> Qemu build
> > > > > >> system [2]. And then it would be easier to migrate them to 
> > > > > >> your
> > > > > >> buildroot environment as well.
> > > > > >>
> > > > > >> [1] 
> > > > > >> https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/27.html
> > > > > >> [2] 
> > > > > >> https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > > >>
> > > > > >> -Sumit
> > > > > >
> > > > > > Can you provide 'keyctl_change'? Otherwise, the steps are 
> > > > > > easy to follow.
> > > > > >
> > > > > 
> > > > >  $ cat keyctl_change
> > > > >  diff --git a/common.mk b/common.mk
> > > > >  index aeb7b41..663e528 100644
> > > > >  --- a/common.mk
> > > > >  +++ b/common.mk
> > > > >  @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= 
> > > > >  $(OPTEE_OS_TA_DEV_KIT_DIR)
> > > > >   BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > > > >   BR2_PACKAGE_STRACE ?= y
> > > > >   BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > > > >  $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > > > >  

Re: [PATCH v2 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy

[Perry Yuan]

Hi Hans:

On 2021/1/13 2:37, Hans de Goede wrote:

Hi,

I know there already is a v3 out and I will try to get around to reviewing
that soon, still 1 remark about the discussion surrounding v2:

On 1/11/21 2:42 PM, Perry Yuan wrote:




*The flow is like this:
1) User presses key. HW does stuff with this key (timeout is started)
2) Event is emitted from FW
3) Event received by dell-privacy
4) KEY_MICMUTE emitted from dell-privacy
5) Userland picks up key and modifies kcontrol for SW mute
6) Codec kernel driver catches and calls ledtrig_audio_set, like this:
ledtrig_audio_set(LED_AUDIO_MICMUTE,
rt715->micmute_led ? LED_ON :LED_OFF);
7) If "LED" is set to on dell-privacy notifies ec,
   and timeout is cancelled,HW mic mute activated.


Please proofread the commit message again, and pay attention to capitalization
and spacing.

I want to reformat it and move the commit info to cover letter.


Please also put a copy of this as a comment in either the wmi or the
acpi driver (with a comment pointing to the comment in the other) this is
important info to have for someone reading the code and trying to understand
how this all fits together.

Regards,

Hans


Hans.
I have added the comments to the dell-privacy  driver file in V4

---
drivers/platform/x86/dell-privacy-wmi.c

EXPORT_SYMBOL_GPL(dell_privacy_valid);
/*
 * The flow of privacy event:
 * 1) User presses key. HW does stuff with this key (timeout is started)
 * 2) WMI event is emitted from BIOS
 * 3) WMI event is received by dell-privacy
 * 4) KEY_MICMUTE emitted from dell-privacy
 * 5) Userland picks up key and modifies kcontrol for SW mute
 * 6) Codec kernel driver catches and calls ledtrig_audio_set defined by
 *dell-privacy-acpi driver.
 *codec driver will call like this to switch micmute led state.
 *  ledtrig_audio_set(LED_AUDIO_MICMUTE, micmute_led ? LED_ON 
:LED_OFF);
 * 7) If "LED" is set to on dell-privacy notifies EC,and timeout is 
cancelled,

 *  HW mic mute activated.
 */
void dell_privacy_process_event(int type, int code, int status)
{
struct privacy_wmi_data *priv;
const struct key_entry *key;

mutex_lock(_mutex);


---
drivers/platform/x86/dell-privacy-acpi.c

/*
 * Pressing the mute key activates a time delayed circuit to physically cut
 * off the mute. The LED is in the same circuit, so it reflects the true
 * state of the HW mute.  The reason for the EC "ack" is so that software
 * can first invoke a SW mute before the HW circuit is cut off.  Without SW
 * cutting this off first does not affect the time delayed muting or status
 * of the LED but there is a possibility of a "popping" noise.
 *
 * If the EC receives the SW ack, the circuit will be activated before the
 * delay completed.
 *
 * Exposing as an LED device allows the codec drivers notification path to
 * EC ACK to work
 */
static int dell_privacy_leds_setup(struct device *dev)
{
struct privacy_acpi_priv *priv = dev_get_drvdata(dev);
int ret = 0;

.

[PATCH v2] fs: ubifs: set s_uuid in super block to support ima/evm uuid options

[Juergen Borleis]

From: Steffen Trumtrar 

This is required to provide uuid based integrity functionality for:
ima_policy (fsuuid option) and the 'evmctl' command ('--uuid' option).

Co-developed-by: Oleksij Rempel 
Co-developed-by: Juergen Borleis 
Signed-off-by: Steffen Trumtrar 
---
 fs/ubifs/super.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 138b9426c6c1..a8383ca39a47 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -2230,6 +2230,8 @@ static int ubifs_fill_super(struct super_block *sb, void 
*data, int silent)
goto out_umount;
}
 
+   import_uuid(>s_uuid, c->uuid);
+
mutex_unlock(>umount_mutex);
return 0;
 
-- 
2.20.1

fs: ubifs: set s_uuid in super block to support ima/evm uuid options

[Juergen Borleis]

This is V2 to support ima/evm uuid in ubifs.

- the previously used memcopy is now replaced by a helper function as suggested
  by Andy

jb

linux-next: manual merge of the gpio-brgl tree with the arm-soc, net-next trees

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the gpio-brgl tree got a conflict in:

  arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts

between commits:

  4fd18fc38757 ("arm64: dts: visconti: Add watchdog support for TMPV7708 SoC")
  0109a17564fc ("arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO 
driver")
  ec8a42e73432 ("arm: dts: visconti: Add DT support for Toshiba Visconti5 
ethernet controller")

from the arm-soc, net-next trees and commit:

  c988ae37c722 ("arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO 
driver")

from the gpio-brgl tree.

I fixed it up (I used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpnzXM19cg5x.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the gpio-brgl tree with the net-next tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the gpio-brgl tree got a conflict in:

  MAINTAINERS

between commit:

  df53e4f48e8d ("MAINTAINERS: Add entries for Toshiba Visconti ethernet 
controller")

from the net-next tree and commit:

  5103c90d133c ("MAINTAINERS: Add entries for Toshiba Visconti GPIO controller")

from the gpio-brgl tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc MAINTAINERS
index 9a8285485f0d,656ae6685430..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -2615,13 -2641,11 +2615,15 @@@ L:   linux-arm-ker...@lists.infradead.or
  S:Supported
  T:git 
git://git.kernel.org/pub/scm/linux/kernel/git/iwamatsu/linux-visconti.git
  F:Documentation/devicetree/bindings/arm/toshiba.yaml
+ F:Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
 +F:Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
  F:Documentation/devicetree/bindings/pinctrl/toshiba,tmpv7700-pinctrl.yaml
 +F:Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml
  F:arch/arm64/boot/dts/toshiba/
+ F:drivers/gpio/gpio-visconti.c
 +F:drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c
  F:drivers/pinctrl/visconti/
 +F:drivers/watchdog/visconti_wdt.c
  N:visconti
  
  ARM/UNIPHIER ARCHITECTURE


pgpVWkfl5wnsx.pgp
Description: OpenPGP digital signature

Re: [PATCH][next] ath11k: debugfs: Fix spelling mistake "Opportunies" -> "Opportunities"

[Kalle Valo]

Colin King  wrote:

> There is a spelling mistake in some debug text, fix this.
> 
> Signed-off-by: Colin Ian King 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

9c349dbd0752 ath11k: debugfs: Fix spelling mistake "Opportunies" -> 
"Opportunities"

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20210212113627.212787-1-colin.k...@canonical.com/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 2/2] ath9k: fix ath_tx_process_buffer() potential null ptr dereference

[Kalle Valo]

Shuah Khan  wrote:

> ath_tx_process_buffer() references ieee80211_find_sta_by_ifaddr()
> return pointer (sta) outside null check. Fix it by moving the code
> block under the null check.
> 
> This problem was found while reviewing code to debug RCU warn from
> ath10k_wmi_tlv_parse_peer_stats_info() and a subsequent manual audit
> of other callers of ieee80211_find_sta_by_ifaddr() that don't hold
> RCU read lock.
> 
> Signed-off-by: Shuah Khan 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

a56c14bb21b2 ath9k: fix ath_tx_process_buffer() potential null ptr dereference

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/43ed9abb9e8d7112f3cc168c2f8c489e253635ba.1613090339.git.sk...@linuxfoundation.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v5 1/2] bio: limit bio max size

[Greg KH]

On Tue, Feb 16, 2021 at 03:42:42PM +0900, Changheun Lee wrote:
> > 
> > On Tue, Feb 16, 2021 at 11:00:32AM +0900, Changheun Lee wrote:
> > > Please feedback to me if more modification is needed to apply. :)
> > 
> > No context here :(
> > 
> 
> I'm so sorry. I missed it.
> 
> > bio size can grow up to 4GB when muli-page bvec is enabled.
> > but sometimes it would lead to inefficient behaviors.
> > in case of large chunk direct I/O, - 32MB chunk read in user space -
> > all pages for 32MB would be merged to a bio structure if the pages
> > physical addresses are contiguous. it makes some delay to submit
> > until merge complete. bio max size should be limited to a proper size.
> > 
> > When 32MB chunk read with direct I/O option is coming from userspace,
> > kernel behavior is below now in do_direct_IO() loop. it's timeline.
> > 
> >  | bio merge for 32MB. total 8,192 pages are merged.
> >  | total elapsed time is over 2ms.
> >  |-- ... --->|
> >  | 8,192 pages merged a bio.
> >  | at this time, first bio 
> > submit is done.
> >  | 1 bio is split to 32 
> > read request and issue.
> >  |--->
> >   |--->
> >|--->
> >   ..
> >
> > |--->
> > 
> > |--->|
> >   total 19ms elapsed to complete 32MB read done 
> > from device. |
> > 
> > If bio max size is limited with 1MB, behavior is changed below.
> > 
> >  | bio merge for 1MB. 256 pages are merged for each bio.
> >  | total 32 bio will be made.
> >  | total elapsed time is over 2ms. it's same.
> >  | but, first bio submit timing is fast. about 100us.
> >  |--->|--->|--->|---> ... -->|--->|--->|--->|--->|
> >   | 256 pages merged a bio.
> >   | at this time, first bio submit is done.
> >   | and 1 read request is issued for 1 bio.
> >   |--->
> >|--->
> > |--->
> >   ..
> >  |--->
> >   |--->|
> > total 17ms elapsed to complete 32MB read done from device. |
> > 
> > As a result, read request issue timing is faster if bio max size is limited.
> > Current kernel behavior with multipage bvec, super large bio can be created.
> > And it lead to delay first I/O request issue.
> > 
> > Signed-off-by: Changheun Lee 
> > ---
> >  block/bio.c| 13 -
> >  include/linux/bio.h|  2 +-
> >  include/linux/blkdev.h |  3 +++
> >  3 files changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/block/bio.c b/block/bio.c
> > index 1f2cc1fbe283..c528e1f944c7 100644
> > --- a/block/bio.c
> > +++ b/block/bio.c
> > @@ -287,6 +287,17 @@ void bio_init(struct bio *bio, struct bio_vec *table,
> >  }
> >  EXPORT_SYMBOL(bio_init);
> >  
> > +unsigned int bio_max_size(struct bio *bio)
> > +{
> > +   struct request_queue *q = bio->bi_disk->queue;
> > +
> > +   if (blk_queue_limit_bio_size(q))
> > +   return blk_queue_get_max_sectors(q, bio_op(bio))
> > +   << SECTOR_SHIFT;
> > +
> > +   return UINT_MAX;
> > +}
> > +
> >  /**
> >   * bio_reset - reinitialize a bio
> >   * @bio:   bio to reset
> > @@ -877,7 +888,7 @@ bool __bio_try_merge_page(struct bio *bio, struct page 
> > *page,
> > struct bio_vec *bv = >bi_io_vec[bio->bi_vcnt - 1];
> >  
> > if (page_is_mergeable(bv, page, len, off, same_page)) {
> > -   if (bio->bi_iter.bi_size > UINT_MAX - len) {
> > +   if (bio->bi_iter.bi_size > bio_max_size(bio) - len) {
> > *same_page = false;
> > return false;
> > }
> > diff --git a/include/linux/bio.h b/include/linux/bio.h
> > index 1edda614f7ce..13b6f6562a5b 100644
> > --- a/include/linux/bio.h
> > +++ b/include/linux/bio.h
> > @@ -113,7 +113,7 @@ static inline bool bio_full(struct bio *bio, unsigned 
> > len)
> > if (bio->bi_vcnt >= bio->bi_max_vecs)
> > return true;
> >  
> > -   if (bio->bi_iter.bi_size > UINT_MAX - len)
> > +   if (bio->bi_iter.bi_size > bio_max_size(bio) - len)
> > return true;
> >  
> > return false;
> > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> > index f94ee3089e01..3aeab9e7e97b 100644
> > --- a/include/linux/blkdev.h
> > +++ b/include/linux/blkdev.h
> > @@ -621,6 +621,7 @@ struct 

Re: [RFC PATCH v4 02/17] af_vsock: separate wait data loop

[Arseny Krasnov]

On 11.02.2021 18:11, Jorgen Hansen wrote:
>> On 7 Feb 2021, at 16:14, Arseny Krasnov  wrote:
>>
>> This moves wait loop for data to dedicated function, because later
>> it will be used by SEQPACKET data receive loop.
>>
>> Signed-off-by: Arseny Krasnov 
>> ---
>> net/vmw_vsock/af_vsock.c | 158 +--
>> 1 file changed, 86 insertions(+), 72 deletions(-)
>>
>> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>> index f4fabec50650..38927695786f 100644
>> --- a/net/vmw_vsock/af_vsock.c
>> +++ b/net/vmw_vsock/af_vsock.c
>> @@ -1833,6 +1833,71 @@ static int vsock_connectible_sendmsg(struct socket 
>> *sock, struct msghdr *msg,
>>  return err;
>> }
>>
>> +static int vsock_wait_data(struct sock *sk, struct wait_queue_entry *wait,
>> +   long timeout,
>> +   struct vsock_transport_recv_notify_data *recv_data,
>> +   size_t target)
>> +{
>> +const struct vsock_transport *transport;
>> +struct vsock_sock *vsk;
>> +s64 data;
>> +int err;
>> +
>> +vsk = vsock_sk(sk);
>> +err = 0;
>> +transport = vsk->transport;
>> +prepare_to_wait(sk_sleep(sk), wait, TASK_INTERRUPTIBLE);
>> +
>> +while ((data = vsock_stream_has_data(vsk)) == 0) {
>> +if (sk->sk_err != 0 ||
>> +(sk->sk_shutdown & RCV_SHUTDOWN) ||
>> +(vsk->peer_shutdown & SEND_SHUTDOWN)) {
>> +goto out;
>> +}
>> +
>> +/* Don't wait for non-blocking sockets. */
>> +if (timeout == 0) {
>> +err = -EAGAIN;
>> +goto out;
>> +}
>> +
>> +if (recv_data) {
>> +err = transport->notify_recv_pre_block(vsk, target, 
>> recv_data);
>> +if (err < 0)
>> +goto out;
>> +}
>> +
>> +release_sock(sk);
>> +timeout = schedule_timeout(timeout);
>> +lock_sock(sk);
>> +
>> +if (signal_pending(current)) {
>> +err = sock_intr_errno(timeout);
>> +goto out;
>> +} else if (timeout == 0) {
>> +err = -EAGAIN;
>> +goto out;
>> +}
>> +}
>> +
>> +finish_wait(sk_sleep(sk), wait);
>> +
>> +/* Invalid queue pair content. XXX This should
>> + * be changed to a connection reset in a later
>> + * change.
>> + */
> Since you are here, could you update this comment to something like:
>
> /* Internal transport error when checking for available
>  * data. XXX This should be changed to a connection
>  * reset in a later change.
>  */
>
>> +if (data < 0)
>> +return -ENOMEM;
>> +
>> +/* Have some data, return. */
>> +if (data)
>> +return data;
>> +
>> +out:
>> +finish_wait(sk_sleep(sk), wait);
>> +return err;
>> +}
> I agree with Stefanos suggestion to get rid of the out: part  and just have 
> the single finish_wait().
>
>> +
>> static int
>> vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t 
>> len,
>>int flags)
>> @@ -1912,85 +1977,34 @@ vsock_connectible_recvmsg(struct socket *sock, 
>> struct msghdr *msg, size_t len,
>>
>>
>>  while (1) {
>> -s64 ready;
>> +ssize_t read;
>>
>> -prepare_to_wait(sk_sleep(sk), , TASK_INTERRUPTIBLE);
>> -ready = vsock_stream_has_data(vsk);
>> -
>> -if (ready == 0) {
>> -if (sk->sk_err != 0 ||
>> -(sk->sk_shutdown & RCV_SHUTDOWN) ||
>> -(vsk->peer_shutdown & SEND_SHUTDOWN)) {
>> -finish_wait(sk_sleep(sk), );
>> -break;
>> -}
>> -/* Don't wait for non-blocking sockets. */
>> -if (timeout == 0) {
>> -err = -EAGAIN;
>> -finish_wait(sk_sleep(sk), );
>> -break;
>> -}
>> -
>> -err = transport->notify_recv_pre_block(
>> -vsk, target, _data);
>> -if (err < 0) {
>> -finish_wait(sk_sleep(sk), );
>> -break;
>> -}
>> -release_sock(sk);
>> -timeout = schedule_timeout(timeout);
>> -lock_sock(sk);
>> -
>> -if (signal_pending(current)) {
>> -err = sock_intr_errno(timeout);
>> -finish_wait(sk_sleep(sk), );
>> -break;
>> -} else if (timeout == 0) {
>> -err = -EAGAIN;
>> -finish_wait(sk_sleep(sk), );
>> -   

Re: [PATCH v5 1/2] bio: limit bio max size

[Changheun Lee]

> 
> On Tue, Feb 16, 2021 at 11:00:32AM +0900, Changheun Lee wrote:
> > Please feedback to me if more modification is needed to apply. :)
> 
> No context here :(
> 

I'm so sorry. I missed it.

> bio size can grow up to 4GB when muli-page bvec is enabled.
> but sometimes it would lead to inefficient behaviors.
> in case of large chunk direct I/O, - 32MB chunk read in user space -
> all pages for 32MB would be merged to a bio structure if the pages
> physical addresses are contiguous. it makes some delay to submit
> until merge complete. bio max size should be limited to a proper size.
> 
> When 32MB chunk read with direct I/O option is coming from userspace,
> kernel behavior is below now in do_direct_IO() loop. it's timeline.
> 
>  | bio merge for 32MB. total 8,192 pages are merged.
>  | total elapsed time is over 2ms.
>  |-- ... --->|
>  | 8,192 pages merged a bio.
>  | at this time, first bio 
> submit is done.
>  | 1 bio is split to 32 read 
> request and issue.
>  |--->
>   |--->
>|--->
>   ..
>
> |--->
> 
> |--->|
>   total 19ms elapsed to complete 32MB read done from 
> device. |
> 
> If bio max size is limited with 1MB, behavior is changed below.
> 
>  | bio merge for 1MB. 256 pages are merged for each bio.
>  | total 32 bio will be made.
>  | total elapsed time is over 2ms. it's same.
>  | but, first bio submit timing is fast. about 100us.
>  |--->|--->|--->|---> ... -->|--->|--->|--->|--->|
>   | 256 pages merged a bio.
>   | at this time, first bio submit is done.
>   | and 1 read request is issued for 1 bio.
>   |--->
>|--->
> |--->
>   ..
>  |--->
>   |--->|
> total 17ms elapsed to complete 32MB read done from device. |
> 
> As a result, read request issue timing is faster if bio max size is limited.
> Current kernel behavior with multipage bvec, super large bio can be created.
> And it lead to delay first I/O request issue.
> 
> Signed-off-by: Changheun Lee 
> ---
>  block/bio.c| 13 -
>  include/linux/bio.h|  2 +-
>  include/linux/blkdev.h |  3 +++
>  3 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/block/bio.c b/block/bio.c
> index 1f2cc1fbe283..c528e1f944c7 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -287,6 +287,17 @@ void bio_init(struct bio *bio, struct bio_vec *table,
>  }
>  EXPORT_SYMBOL(bio_init);
>  
> +unsigned int bio_max_size(struct bio *bio)
> +{
> + struct request_queue *q = bio->bi_disk->queue;
> +
> + if (blk_queue_limit_bio_size(q))
> + return blk_queue_get_max_sectors(q, bio_op(bio))
> + << SECTOR_SHIFT;
> +
> + return UINT_MAX;
> +}
> +
>  /**
>   * bio_reset - reinitialize a bio
>   * @bio: bio to reset
> @@ -877,7 +888,7 @@ bool __bio_try_merge_page(struct bio *bio, struct page 
> *page,
>   struct bio_vec *bv = >bi_io_vec[bio->bi_vcnt - 1];
>  
>   if (page_is_mergeable(bv, page, len, off, same_page)) {
> - if (bio->bi_iter.bi_size > UINT_MAX - len) {
> + if (bio->bi_iter.bi_size > bio_max_size(bio) - len) {
>   *same_page = false;
>   return false;
>   }
> diff --git a/include/linux/bio.h b/include/linux/bio.h
> index 1edda614f7ce..13b6f6562a5b 100644
> --- a/include/linux/bio.h
> +++ b/include/linux/bio.h
> @@ -113,7 +113,7 @@ static inline bool bio_full(struct bio *bio, unsigned len)
>   if (bio->bi_vcnt >= bio->bi_max_vecs)
>   return true;
>  
> - if (bio->bi_iter.bi_size > UINT_MAX - len)
> + if (bio->bi_iter.bi_size > bio_max_size(bio) - len)
>   return true;
>  
>   return false;
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index f94ee3089e01..3aeab9e7e97b 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -621,6 +621,7 @@ struct request_queue {
>  #define QUEUE_FLAG_RQ_ALLOC_TIME 27  /* record rq->alloc_time_ns */
>  #define QUEUE_FLAG_HCTX_ACTIVE   28  /* at least one blk-mq hctx is 
> active */
>  #define QUEUE_FLAG_NOWAIT   29   /* device supports NOWAIT */
> +#define 

Re: [PATCH v3 1/3] platform/x86: dell-privacy: Add support for Dell hardware privacy

[Perry Yuan]

Hi Pierre:
thanks for the review effort.
On 2021/1/13 3:00, Pierre-Louis Bossart wrote:



On 1/12/21 11:17 AM, Perry Yuan wrote:

From: Perry Yuan 

add support for dell privacy driver for the dell units equipped
hardware privacy design, which protect users privacy of audio and
camera from hardware level. once the audio or camera privacy mode
enabled, any applications will not get any audio or video stream
when user pressed ctrl+F4 hotkey, audio privacy mode will be
enabled,Micmute led will be also changed accordingly
The micmute led is fully controlled by hardware & EC(embedded controller)
and camera mute hotkey is ctrl+f9. currently design only emmit
SW_CAMERA_LENS_COVER event while the camera lens shutter will be
changed by EC & hw(hadware) control


It wouldn't hurt to use capital letters and punctuation, it helps with 
readility..



I will try to improve the description in V4

[...]

diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c

index 70edc5bb3a14..2fea1f34fcf9 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -30,6 +30,7 @@
  #include 
  #include "dell-rbtn.h"
  #include "dell-smbios.h"
+#include "dell-privacy-wmi.h"
  struct quirk_entry {
  bool touchpad_led;
@@ -90,6 +91,7 @@ static struct rfkill *wifi_rfkill;
  static struct rfkill *bluetooth_rfkill;
  static struct rfkill *wwan_rfkill;
  static bool force_rfkill;
+static bool privacy_valid;


why is this variable needed? Was the intent to have a kernel parameter 
here?
The var is used to mark if the Dell privacy wmi  driver was loaded 
successfully for now,if privacy loaded,the micmute_led_cdev.brightness

will not be registered by dell-laptop, it will be in dell-privacy-acpi
file using dell_privacy_leds_setup to register the led class.




  module_param(force_rfkill, bool, 0444);
  MODULE_PARM_DESC(force_rfkill, "enable rfkill on non whitelisted 
models");

@@ -2205,11 +2207,18 @@ static int __init dell_init(void)
  dell_laptop_register_notifier(_laptop_notifier);
  if (dell_smbios_find_token(GLOBAL_MIC_MUTE_DISABLE) &&
-    dell_smbios_find_token(GLOBAL_MIC_MUTE_ENABLE)) {
-    micmute_led_cdev.brightness = 
ledtrig_audio_get(LED_AUDIO_MICMUTE);
-    ret = led_classdev_register(_device->dev, 
_led_cdev);

-    if (ret < 0)
-    goto fail_led;
+    dell_smbios_find_token(GLOBAL_MIC_MUTE_ENABLE)) {
+#if IS_ENABLED(CONFIG_DELL_PRIVACY)
+    ret = dell_privacy_valid();
+    if (!ret)
+    privacy_valid = true;
+#endif
+    if (!privacy_valid) {


if it was intended to be used as a kernel parameter it's not done the 
right way: the value set by the user would be ignored...
The privacy_valid value will be retrieved from dell-privacy-wmi showing 
if the privacy driver loaded.


+    micmute_led_cdev.brightness = 
ledtrig_audio_get(LED_AUDIO_MICMUTE);
+    ret = led_classdev_register(_device->dev, 
_led_cdev);

+    if (ret < 0)
+    goto fail_led;
+    }
  }
  if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
@@ -2257,7 +2266,8 @@ static int __init dell_init(void)
  fail_get_brightness:
  backlight_device_unregister(dell_backlight_device);
  fail_backlight:
-    led_classdev_unregister(_led_cdev);
+    if (!privacy_valid)
+    led_classdev_unregister(_led_cdev);
  fail_led:
  dell_cleanup_rfkill();
  fail_rfkill:
@@ -2278,7 +2288,8 @@ static void __exit dell_exit(void)
  touchpad_led_exit();
  kbd_led_exit();
  backlight_device_unregister(dell_backlight_device);
-    led_classdev_unregister(_led_cdev);
+    if (!privacy_valid)
+    led_classdev_unregister(_led_cdev);
  dell_cleanup_rfkill();
  if (platform_device) {
  platform_device_unregister(platform_device);
diff --git a/drivers/platform/x86/dell-privacy-acpi.c 
b/drivers/platform/x86/dell-privacy-acpi.c

new file mode 100644
index ..df6a86e1345c
--- /dev/null
+++ b/drivers/platform/x86/dell-privacy-acpi.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Dell privacy notification driver
+ *
+ * Copyright (C) 2021 Dell Inc. All Rights Reserved.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dell-privacy-wmi.h"
+
+#define PRIVACY_PLATFORM_NAME    "dell-privacy-acpi"
+#define DELL_PRIVACY_GUID    "6932965F-1671-4CEB-B988-D3AB0A901919"
+
+struct privacy_acpi_priv {
+    struct device *dev;
+    struct platform_device *platform_device;
+    struct led_classdev cdev;
+};
+static struct privacy_acpi_priv *privacy_acpi;
+
+static int dell_privacy_micmute_led_set(struct led_classdev *led_cdev,
+    enum led_brightness brightness)
+{
+    struct privacy_acpi_priv *priv = privacy_acpi;
+    acpi_status status;
+    acpi_handle handle;
+    char 

Re: [PATCH v3] firmware: xilinx: Remove zynqmp_pm_get_eemi_ops() in IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE)

[Michal Simek]

On 2/15/21 4:58 PM, Nobuhiro Iwamatsu wrote:
> zynqmp_pm_get_eemi_ops() was removed in commit 4db8180ffe7c: "Firmware: 
> xilinx:
> Remove eemi ops for fpga related APIs", but not in 
> IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE).
> Any driver who want to communicate with PMC using EEMI APIs use the functions 
> provided
> for each function
> This removed zynqmp_pm_get_eemi_ops() in 
> IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE), and also
> modify the documentation for this driver.
> 
> Fixes: 4db8180ffe7c ("firmware: xilinx: Remove eemi ops for fpga related 
> APIs")
> Signed-off-by: Nobuhiro Iwamatsu 
> ---
>  v3: Update eemi.rst.
>  v2: Added the comment pointed out by Michal.  
> 
>  Documentation/driver-api/xilinx/eemi.rst | 31 ++--
>  include/linux/firmware/xlnx-zynqmp.h |  5 
>  2 files changed, 2 insertions(+), 34 deletions(-)
> 
> diff --git a/Documentation/driver-api/xilinx/eemi.rst 
> b/Documentation/driver-api/xilinx/eemi.rst
> index 9dcbc6f18d75df..579cf9a407ac2f 100644
> --- a/Documentation/driver-api/xilinx/eemi.rst
> +++ b/Documentation/driver-api/xilinx/eemi.rst
> @@ -16,35 +16,8 @@ components running across different processing clusters on 
> a chip or
>  device to communicate with a power management controller (PMC) on a
>  device to issue or respond to power management requests.
>  
> -EEMI ops is a structure containing all eemi APIs supported by Zynq MPSoC.
> -The zynqmp-firmware driver maintain all EEMI APIs in zynqmp_eemi_ops
> -structure. Any driver who want to communicate with PMC using EEMI APIs
> -can call zynqmp_pm_get_eemi_ops().
> -
> -Example of EEMI ops::
> -
> - /* zynqmp-firmware driver maintain all EEMI APIs */
> - struct zynqmp_eemi_ops {
> - int (*get_api_version)(u32 *version);
> - int (*query_data)(struct zynqmp_pm_query_data qdata, u32 *out);
> - };
> -
> - static const struct zynqmp_eemi_ops eemi_ops = {
> - .get_api_version = zynqmp_pm_get_api_version,
> - .query_data = zynqmp_pm_query_data,
> - };
> -
> -Example of EEMI ops usage::
> -
> - static const struct zynqmp_eemi_ops *eemi_ops;
> - u32 ret_payload[PAYLOAD_ARG_CNT];
> - int ret;
> -
> - eemi_ops = zynqmp_pm_get_eemi_ops();
> - if (IS_ERR(eemi_ops))
> - return PTR_ERR(eemi_ops);
> -
> - ret = eemi_ops->query_data(qdata, ret_payload);
> +Any driver who want to communicate with PMC using EEMI APIs use the

wants

> +functions provided for each function.
>  
>  IOCTL
>  --
> diff --git a/include/linux/firmware/xlnx-zynqmp.h 
> b/include/linux/firmware/xlnx-zynqmp.h
> index c8a18da6906e78..70e19ab34ff1ca 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -416,11 +416,6 @@ int zynqmp_pm_read_pggs(u32 index, u32 *value);
>  int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype);
>  int zynqmp_pm_set_boot_health_status(u32 value);
>  #else
> -static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
> -{
> - return ERR_PTR(-ENODEV);
> -}
> -
>  static inline int zynqmp_pm_get_api_version(u32 *version)
>  {
>   return -ENODEV;
> 

Queue for 5.13 with corrected sentence above.

Thanks,
Michal

Re: [PATCH] microblaze: Fix built-in DTB alignment to be 8-byte aligned

[Michal Simek]

so 13. 2. 2021 v 2:16 odesílatel Rob Herring  napsal:
>
> Commit 79edff12060f ("scripts/dtc: Update to upstream version
> v1.6.0-51-g183df9e9c2b9") broke booting on Microblaze systems depending on
> the build. The problem is libfdt gained an 8-byte starting alignment check,
> but the Microblaze built-in DTB area is only 4-byte aligned. This affected
> not just built-in DTBs as bootloader passed DTBs are copied into the
> built-in DTB region.
>
> Other arches using built-in DTBs use a common linker macro which has
> sufficient alignment.
>
> Fixes: 79edff12060f ("scripts/dtc: Update to upstream version 
> v1.6.0-51-g183df9e9c2b9")
> Reported-by: Guenter Roeck 
> Tested-by: Guenter Roeck 
> Cc: Michal Simek 
> Signed-off-by: Rob Herring 
> ---
> As the commit is in my tree, I'll take this via the DT tree.
>
>  arch/microblaze/kernel/vmlinux.lds.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/microblaze/kernel/vmlinux.lds.S 
> b/arch/microblaze/kernel/vmlinux.lds.S
> index df07b3d06cd6..fb31747ec092 100644
> --- a/arch/microblaze/kernel/vmlinux.lds.S
> +++ b/arch/microblaze/kernel/vmlinux.lds.S
> @@ -45,7 +45,7 @@ SECTIONS {
> _etext = . ;
> }
>
> -   . = ALIGN (4) ;
> +   . = ALIGN (8) ;
> __fdt_blob : AT(ADDR(__fdt_blob) - LOAD_OFFSET) {
> _fdt_start = . ;/* place for fdt blob */
> *(__fdt_blob) ; /* Any link-placed DTB */
> --
> 2.27.0
>

Applied.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] vdpa/mlx5: Extract correct pointer from driver data

[Eli Cohen]

On Tue, Feb 16, 2021 at 08:35:51AM +0200, Leon Romanovsky wrote:
> On Tue, Feb 16, 2021 at 07:50:22AM +0200, Eli Cohen wrote:
> > struct mlx5_vdpa_net pointer was stored in drvdata. Extract it as well
> > in mlx5v_remove().
> >
> > Fixes: 74c9729dd892 ("vdpa/mlx5: Connect mlx5_vdpa to auxiliary bus")
> > Signed-off-by: Eli Cohen 
> > ---
> >  drivers/vdpa/mlx5/net/mlx5_vnet.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index 6b0a42183622..4103d3b64a2a 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -2036,9 +2036,9 @@ static int mlx5v_probe(struct auxiliary_device *adev,
> >
> >  static void mlx5v_remove(struct auxiliary_device *adev)
> >  {
> > -   struct mlx5_vdpa_dev *mvdev = dev_get_drvdata(>dev);
> > +   struct mlx5_vdpa_net *ndev = dev_get_drvdata(>dev);
> >
> > -   vdpa_unregister_device(>vdev);
> > +   vdpa_unregister_device(>mvdev.vdev);
> >  }
> 
> IMHO, The more correct solution is to fix dev_set_drvdata() call,
> because we are regustering/unregistering/allocating "struct mlx5_vdpa_dev".
> 

We're allocating "struct mlx5_vdpa_net". "struct mlx5_vdpa_dev" is just
a member field of "struct mlx5_vdpa_net".

> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index 88dde3455bfd..079b8fe669af 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -1995,7 +1995,7 @@ static int mlx5v_probe(struct auxiliary_device *adev,
>   if (err)
>   goto err_reg;
> 
> - dev_set_drvdata(>dev, ndev);
> + dev_set_drvdata(>dev, mvdev);
>   return 0;
> 
>  err_reg:
> 
> >
> >  static const struct auxiliary_device_id mlx5v_id_table[] = {
> 
> > --
> > 2.29.2
> >

Re: [PATCH] gen_compile_commands: prune some directories

[Masahiro Yamada]

On Fri, Feb 12, 2021 at 2:19 AM Nathan Chancellor  wrote:
>
> On Fri, Feb 12, 2021 at 01:11:54AM +0900, Masahiro Yamada wrote:
> > If directories are passed to gen_compile_commands.py, os.walk() traverses
> > all the subdirectories to search for .cmd files, but we know some of them
> > are not worth traversing.
> >
> > Use the 'topdown' parameter of os.walk to prune them.
> >
> > Documentation about the 'topdown' option of os.walk:
> >   When topdown is True, the caller can modify the dirnames list
> >   in-place (perhaps using del or slice assignment), and walk() will
> >   only recurse into the subdirectories whose names remain in dirnames;
> >   this can be used to prune the search, impose a specific order of
> >   visiting, or even to inform walk() about directories the caller
> >   creates or renames before it resumes walk() again. Modifying
> >   dirnames when topdown is False has no effect on the behavior of
> >   the walk, because in bottom-up mode the directories in dirnames
> >   are generated before dirpath itself is generated.
> >
> > This commit prunes four directories, .git, Documentation, include, and
> > tools.
> >
> > The first three do not contain any C files. My main motivation is the
> > last one, tools/ directory.
> >
> > Commit 6ca4c6d25949 ("gen_compile_commands: do not support .cmd files
> > under tools/ directory") stopped supporting the tools/ directory.
> > The current code no longer picks up .cmd files from the tools/
> > directory.
> >
> > If you run:
> >
> >   ./scripts/clang-tools/gen_compile_commands.py --log_level=INFO
> >
> > then, you will see several "File ... not found" log messages.
> >
> > This is expected, and I do not want to support the tools/ directory.
> > However, without an explicit comment "do not support tools/", somebody
> > might try to get it back. Clarify this.
> >
> > Signed-off-by: Masahiro Yamada 
>
> Sorry, I did not realize that gen_compile_commands.py did not intend to
> support. I was only looking at the history for the current location, not
> the former one of scripts/gen_compile_commands.py.
>
> Acked-by: Nathan Chancellor 
>

Applied to linux-kbuild.



Best Regards
Masahiro Yamada

Re: INFO: task hung in nbd_ioctl (3)

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:f40ddce8 Linux 5.11
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10a8b204d0
kernel config:  https://syzkaller.appspot.com/x/.config?x=4b919ebed7b4902
dashboard link: https://syzkaller.appspot.com/bug?extid=fe03c50d25c0188f7487
compiler:   Debian clang version 11.0.1-2
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11a7953cd0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11bc9914d0

The issue was bisected to:

commit e9e006f5fcf2bab59149cb38a48a4817c1b538b4
Author: Mike Christie 
Date:   Sun Aug 4 19:10:06 2019 +

nbd: fix max number of supported devs

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=171556f050
final oops: https://syzkaller.appspot.com/x/report.txt?x=149556f050
console output: https://syzkaller.appspot.com/x/log.txt?x=109556f050

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+fe03c50d25c0188f7...@syzkaller.appspotmail.com
Fixes: e9e006f5fcf2 ("nbd: fix max number of supported devs")

INFO: task syz-executor645:8465 blocked for more than 143 seconds.
  Not tainted 5.11.0-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor645 state:D stack:28256 pid: 8465 ppid:  8464 flags:0x4004
Call Trace:
 context_switch kernel/sched/core.c:4327 [inline]
 __schedule+0x999/0xe70 kernel/sched/core.c:5078
 schedule+0x14b/0x200 kernel/sched/core.c:5157
 schedule_timeout+0x43/0x250 kernel/time/timer.c:1854
 do_wait_for_common+0x266/0x3a0 kernel/sched/completion.c:85
 __wait_for_common kernel/sched/completion.c:106 [inline]
 wait_for_common kernel/sched/completion.c:117 [inline]
 wait_for_completion+0x43/0x50 kernel/sched/completion.c:138
 flush_workqueue+0x704/0x1620 kernel/workqueue.c:2838
 nbd_start_device_ioctl drivers/block/nbd.c:1332 [inline]
 __nbd_ioctl drivers/block/nbd.c:1393 [inline]
 nbd_ioctl+0x76d/0x940 drivers/block/nbd.c:1433
 blkdev_ioctl+0x2d6/0x5f0 block/ioctl.c:576
 block_ioctl+0xae/0xf0 fs/block_dev.c:1658
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4441e9
RSP: 002b:7ffc87363948 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 004004a0 RCX: 004441e9
RDX:  RSI: ab03 RDI: 0003
RBP:  R08: 7ffc87363ae8 R09: 7ffc87363ae8
R10: 7ffc87363ae8 R11: 0246 R12: 00403500
R13: 431bde82d7b634db R14: 004b2018 R15: 004004a0

Showing all locks held in the system:
1 lock held by khungtaskd/1644:
 #0: 8c711680 (rcu_read_lock){}-{1:2}, at: 
rcu_lock_acquire+0x0/0x30 arch/x86/pci/mmconfig_64.c:151
3 locks held by kworker/u5:0/2034:
 #0: 888016152938 ((wq_completion)knbd0-recv){+.+.}-{0:0}, at: 
process_one_work+0x6f4/0xfc0 kernel/workqueue.c:2248
 #1: c900072afd78 ((work_completion)(>work)){+.+.}-{0:0}, at: 
process_one_work+0x733/0xfc0 kernel/workqueue.c:2250
 #2: 888018ca7120 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock 
include/net/sock.h:1594 [inline]
 #2: 888018ca7120 (sk_lock-AF_AX25){+.+.}-{0:0}, at: 
ax25_recvmsg+0x86/0x740 net/ax25/af_ax25.c:1626
1 lock held by in:imklog/8097:
 #0: 8880198b14f0 (>f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0x24e/0x2f0 
fs/file.c:947

=

NMI backtrace for cpu 1
CPU: 1 PID: 1644 Comm: khungtaskd Not tainted 5.11.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x137/0x1be lib/dump_stack.c:120
 nmi_cpu_backtrace+0x16c/0x190 lib/nmi_backtrace.c:105
 nmi_trigger_cpumask_backtrace+0x191/0x2f0 lib/nmi_backtrace.c:62
 trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
 check_hung_uninterruptible_tasks kernel/hung_task.c:209 [inline]
 watchdog+0xce9/0xd30 kernel/hung_task.c:294
 kthread+0x39a/0x3c0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 4866 Comm: systemd-journal Not tainted 5.11.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:rw_verify_area+0xef/0x370 fs/read_write.c:392
Code: 49 8d 9f 20 02 00 00 48 89 d8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df 
80 3c 08 00 74 08 48 89 df e8 55 a5 f6 ff 48 83 3b 00 <74> 6f 49 8d 5f 28 48 89 
d8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff
RSP: 0018:c9000167fde0 EFLAGS: 0246
RAX: 1110280e66bc RBX: 8881407335e0 RCX: dc00
RDX:  RSI: 2000 RDI: 
RBP: c9000167ff00 R08: 81c4ad94 R09: 

Re: [PATCH] vdpa/mlx5: Extract correct pointer from driver data

[Leon Romanovsky]

On Tue, Feb 16, 2021 at 07:50:22AM +0200, Eli Cohen wrote:
> struct mlx5_vdpa_net pointer was stored in drvdata. Extract it as well
> in mlx5v_remove().
>
> Fixes: 74c9729dd892 ("vdpa/mlx5: Connect mlx5_vdpa to auxiliary bus")
> Signed-off-by: Eli Cohen 
> ---
>  drivers/vdpa/mlx5/net/mlx5_vnet.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index 6b0a42183622..4103d3b64a2a 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -2036,9 +2036,9 @@ static int mlx5v_probe(struct auxiliary_device *adev,
>
>  static void mlx5v_remove(struct auxiliary_device *adev)
>  {
> - struct mlx5_vdpa_dev *mvdev = dev_get_drvdata(>dev);
> + struct mlx5_vdpa_net *ndev = dev_get_drvdata(>dev);
>
> - vdpa_unregister_device(>vdev);
> + vdpa_unregister_device(>mvdev.vdev);
>  }

IMHO, The more correct solution is to fix dev_set_drvdata() call,
because we are regustering/unregistering/allocating "struct mlx5_vdpa_dev".

diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 88dde3455bfd..079b8fe669af 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1995,7 +1995,7 @@ static int mlx5v_probe(struct auxiliary_device *adev,
if (err)
goto err_reg;

-   dev_set_drvdata(>dev, ndev);
+   dev_set_drvdata(>dev, mvdev);
return 0;

 err_reg:

>
>  static const struct auxiliary_device_id mlx5v_id_table[] = {

> --
> 2.29.2
>

Re: [PATCH] mfd: syscon: Don't free allocated name for regmap_config

[Tomi Valkeinen]

Hi Marc,

On 03/09/2020 19:02, Marc Zyngier wrote:
> The name allocated for the regmap_config structure is freed
> pretty early, right after the registration of the MMIO region.
> 
> Unfortunately, that doesn't follow the life cycle that debugfs
> expects, as it can access the name field long after the free
> has occured.
> 
> Move the free on the error path, and keep it forever otherwise.
> 
> Fixes: e15d7f2b81d2 ("mfd: syscon: Use a unique name with regmap_config")
> Signed-off-by: Marc Zyngier 
> ---
>  drivers/mfd/syscon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 75859e492984..7a660411c562 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -108,7 +108,6 @@ static struct syscon *of_syscon_register(struct 
> device_node *np, bool check_clk)
>   syscon_config.max_register = resource_size() - reg_io_width;
>  
>   regmap = regmap_init_mmio(NULL, base, _config);
> - kfree(syscon_config.name);
>   if (IS_ERR(regmap)) {
>   pr_err("regmap init failed\n");
>   ret = PTR_ERR(regmap);
> @@ -145,6 +144,7 @@ static struct syscon *of_syscon_register(struct 
> device_node *np, bool check_clk)
>   regmap_exit(regmap);
>  err_regmap:
>   iounmap(base);
> + kfree(syscon_config.name);
>  err_map:
>   kfree(syscon);
>   return ERR_PTR(ret);
> 

This patch causes lots of kmemleak reports, for example:

unreferenced object 0xc8e6f000 (size 64):
  comm "kworker/1:1", pid 22, jiffies 4294938454 (age 95.540s)
  hex dump (first 32 bytes):
64 73 70 5f 73 79 73 74 65 6d 40 34 30 64 30 30  dsp_system@40d00
30 30 30 00 e0 09 4d c1 ac 1b 4d c1 64 74 4c c1  000...M...M.dtL.
  backtrace:
[<(ptrval)>] __kmalloc_track_caller+0x2bc/0x418
[<(ptrval)>] kvasprintf+0x9c/0x124
[<(ptrval)>] kasprintf+0x70/0xac
[<(ptrval)>] of_syscon_register+0x1f0/0x4f0
[<(ptrval)>] device_node_get_regmap+0x12c/0x158
[<(ptrval)>] syscon_regmap_lookup_by_phandle+0x5c/0x6c
[<(ptrval)>] omap_iommu_probe+0x6ac/0xc28
[<(ptrval)>] platform_probe+0x120/0x1e0
[<(ptrval)>] really_probe+0x2b4/0x121c
[<(ptrval)>] driver_probe_device+0x10c/0x4c0
[<(ptrval)>] __device_attach_driver+0x1d8/0x26c
[<(ptrval)>] bus_for_each_drv+0x174/0x200
[<(ptrval)>] __device_attach+0x2f0/0x45c
[<(ptrval)>] device_initial_probe+0x1c/0x20
[<(ptrval)>] bus_probe_device+0x224/0x2b8
[<(ptrval)>] device_add+0xad0/0x1e18

 Tomi

Re: [PATCH] drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features

[Chun-Kuang Hu]

Hi, Nicolas:

Nicolas Boichat  於 2021年2月11日 週四 上午11:34寫道：
>
> Many of the DSI flags have names opposite to their actual effects,
> e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually
> be disabled. Fix this by including _NO_ in the flag names, e.g.
> MIPI_DSI_MODE_NO_EOT_PACKET.

For Mediatek part,

Acked-by: Chun-Kuang Hu 

>
> Signed-off-by: Nicolas Boichat 
> ---
> I considered adding _DISABLE_ instead, but that'd make the
> flag names a big too long.
>
> Generated with:
> flag=MIPI_DSI_MODE_VIDEO_HFP; git grep $flag | cut -f1 -d':' | \
>   xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HFP/" {}
> flag=MIPI_DSI_MODE_VIDEO_HBP; git grep $flag | cut -f1 -d':' | \
>   xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HBP/" {}
> flag=MIPI_DSI_MODE_VIDEO_HSA; git grep $flag | cut -f1 -d':' | \
>   xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HSA/" {}
> flag=MIPI_DSI_MODE_EOT_PACKET; git grep $flag | cut -f1 -d':' | \
>   xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_NO_EOT_PACKET/" {}
> (then minor format changes)
>
>  drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +-
>  drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
>  drivers/gpu/drm/bridge/cdns-dsi.c| 4 ++--
>  drivers/gpu/drm/bridge/tc358768.c| 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  | 8 
>  drivers/gpu/drm/mcde/mcde_dsi.c  | 2 +-
>  drivers/gpu/drm/mediatek/mtk_dsi.c   | 2 +-
>  drivers/gpu/drm/msm/dsi/dsi_host.c   | 8 
>  drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c | 2 +-
>  drivers/gpu/drm/panel/panel-dsi-cm.c | 2 +-
>  drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +-
>  drivers/gpu/drm/panel/panel-khadas-ts050.c   | 2 +-
>  drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c   | 2 +-
>  drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c   | 2 +-
>  drivers/gpu/drm/panel/panel-novatek-nt35510.c| 2 +-
>  drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c   | 2 +-
>  drivers/gpu/drm/panel/panel-samsung-s6d16d0.c| 2 +-
>  drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 2 +-
>  drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c| 2 +-
>  drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 4 ++--
>  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c  | 2 +-
>  drivers/gpu/drm/panel/panel-simple.c | 2 +-
>  drivers/gpu/drm/panel/panel-sony-acx424akp.c | 2 +-
>  drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c | 2 +-
>  include/drm/drm_mipi_dsi.h   | 8 
>  25 files changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c 
> b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> index aa19d5a40e31..59d718bde8c4 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> @@ -165,7 +165,7 @@ int adv7533_attach_dsi(struct adv7511 *adv)
> dsi->lanes = adv->num_dsi_lanes;
> dsi->format = MIPI_DSI_FMT_RGB888;
> dsi->mode_flags = MIPI_DSI_MODE_VIDEO | 
> MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> - MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
> + MIPI_DSI_MODE_NO_EOT_PACKET | 
> MIPI_DSI_MODE_VIDEO_HSE;
>
> ret = mipi_dsi_attach(dsi);
> if (ret < 0) {
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 65cc05982f82..beecfe6bf359 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -1334,7 +1334,7 @@ static int anx7625_attach_dsi(struct anx7625_data *ctx)
> dsi->format = MIPI_DSI_FMT_RGB888;
> dsi->mode_flags = MIPI_DSI_MODE_VIDEO   |
> MIPI_DSI_MODE_VIDEO_SYNC_PULSE  |
> -   MIPI_DSI_MODE_EOT_PACKET|
> +   MIPI_DSI_MODE_NO_EOT_PACKET |
> MIPI_DSI_MODE_VIDEO_HSE;
>
> if (mipi_dsi_attach(dsi) < 0) {
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index 76373e31df92..34aa24269a57 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -829,7 +829,7 @@ static void cdns_dsi_bridge_enable(struct drm_bridge 
> *bridge)
> tmp = DIV_ROUND_UP(dsi_cfg.htotal, nlanes) -
>   DIV_ROUND_UP(dsi_cfg.hsa, nlanes);
>
> -   if (!(output->dev->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
> +   if (!(output->dev->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET))
> tmp -= DIV_ROUND_UP(DSI_EOT_PKT_SIZE, nlanes);
>
> tx_byte_period = DIV_ROUND_DOWN_ULL((u64)NSEC_PER_SEC * 8,
> @@ -902,7 +902,7 @@ static void cdns_dsi_bridge_enable(struct drm_bridge 
> *bridge)
> tmp = readl(dsi->regs + MCTL_MAIN_DATA_CTL);
> tmp &= ~(IF_VID_SELECT_MASK | HOST_EOT_GEN | IF_VID_MODE);
>
> -

Re: [PATCH v5 1/2] bio: limit bio max size

[Greg KH]

On Tue, Feb 16, 2021 at 11:00:32AM +0900, Changheun Lee wrote:
> Please feedback to me if more modification is needed to apply. :)

No context here :(

Re: [PATCH net-next RFC v3] net: hdlc_x25: Queue outgoing LAPB frames

[Leon Romanovsky]

On Mon, Feb 15, 2021 at 11:08:02AM -0800, Xie He wrote:
> On Mon, Feb 15, 2021 at 10:54 AM Leon Romanovsky  wrote:
> >
> > On Mon, Feb 15, 2021 at 09:23:32AM -0800, Xie He wrote:
> > > On Mon, Feb 15, 2021 at 1:25 AM Leon Romanovsky  wrote:
> > > >
> > > > > + /* When transmitting data:
> > > > > +  * first we'll remove a pseudo header of 1 byte,
> > > > > +  * then the LAPB module will prepend an LAPB header of at most 
> > > > > 3 bytes.
> > > > > +  */
> > > > > + dev->needed_headroom = 3 - 1;
> > > >
> > > > 3 - 1 = 2
> > > >
> > > > Thanks
> > >
> > > Actually this is intentional. It makes the numbers more meaningful.
> > >
> > > The compiler should automatically generate the "2" so there would be
> > > no runtime penalty.
> >
> > If you want it intentional, write it in the comment.
> >
> > /* When transmitting data, we will need extra 2 bytes headroom,
> >  * which are 3 bytes of LAPB header minus one byte of pseudo header.
> >  */
> >  dev->needed_headroom = 2;
>
> I think this is unnecessary. The current comment already explains the
> meaning of the "1" and the "3". There's no need for a reader of this
> code to understand what a "2" is. That is the job of the compiler, not
> the human reader.

It is not related to compiler/human format. If you need to write "3 - 1"
to make it easy for users, it means that your comment above is not
full/correct/e.t.c.

Thanks

[PATCH] regulator: pf8x00: Use regulator_map_voltage_ascend for pf8x00_buck7_ops

[Axel Lin]

The voltages in pf8x00_sw7_voltages are in ascendant order, so use
regulator_map_voltage_ascend.

Signed-off-by: Axel Lin 
---
 drivers/regulator/pf8x00-regulator.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/pf8x00-regulator.c 
b/drivers/regulator/pf8x00-regulator.c
index 9b28bd63208d..5d319fb81288 100644
--- a/drivers/regulator/pf8x00-regulator.c
+++ b/drivers/regulator/pf8x00-regulator.c
@@ -359,6 +359,7 @@ static const struct regulator_ops pf8x00_buck7_ops = {
.disable = regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
.list_voltage = regulator_list_voltage_table,
+   .map_voltage = regulator_map_voltage_ascend,
.set_voltage_sel = regulator_set_voltage_sel_regmap,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
.get_current_limit = regulator_get_current_limit_regmap,
-- 
2.25.1

[PATCH] vdpa/mlx5: Extract correct pointer from driver data

[Eli Cohen]

struct mlx5_vdpa_net pointer was stored in drvdata. Extract it as well
in mlx5v_remove().

Fixes: 74c9729dd892 ("vdpa/mlx5: Connect mlx5_vdpa to auxiliary bus")
Signed-off-by: Eli Cohen 
---
 drivers/vdpa/mlx5/net/mlx5_vnet.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 6b0a42183622..4103d3b64a2a 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -2036,9 +2036,9 @@ static int mlx5v_probe(struct auxiliary_device *adev,
 
 static void mlx5v_remove(struct auxiliary_device *adev)
 {
-   struct mlx5_vdpa_dev *mvdev = dev_get_drvdata(>dev);
+   struct mlx5_vdpa_net *ndev = dev_get_drvdata(>dev);
 
-   vdpa_unregister_device(>vdev);
+   vdpa_unregister_device(>mvdev.vdev);
 }
 
 static const struct auxiliary_device_id mlx5v_id_table[] = {
-- 
2.29.2

[PATCH] vdpa/mlx5: Extract correct pointer from driver data

[Eli Cohen]

struct mlx5_vdpa_net pointer was stored in drvdata. Extract it as well
in mlx5v_remove().

Fixes: 74c9729dd892 ("vdpa/mlx5: Connect mlx5_vdpa to auxiliary bus")
Signed-off-by: Eli Cohen 
---
 drivers/vdpa/mlx5/net/mlx5_vnet.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 6b0a42183622..4103d3b64a2a 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -2036,9 +2036,9 @@ static int mlx5v_probe(struct auxiliary_device *adev,
 
 static void mlx5v_remove(struct auxiliary_device *adev)
 {
-   struct mlx5_vdpa_dev *mvdev = dev_get_drvdata(>dev);
+   struct mlx5_vdpa_net *ndev = dev_get_drvdata(>dev);
 
-   vdpa_unregister_device(>vdev);
+   vdpa_unregister_device(>mvdev.vdev);
 }
 
 static const struct auxiliary_device_id mlx5v_id_table[] = {
-- 
2.29.2

Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz

[nnet]

> Could you test following change instead of PATCH 04/10? I added here also
> logic for 1.2 GHz variant with 1.132 V value another change is that
> value for load L0 is not touched as it is stable.

These changes to patch 04/10 worked going 600 MHz <-> 1.2 GHz , _but_ only with:

++#define MIN_VOLT_MV_FOR_L1_1200MHZ 1213

During this latest testing I saw freezes with 1132 mV.

I've had no lockups with 1213 mV which I just used from the values for L1/L0 
from OTP.

I only tested with those two values.

drivers/video/fbdev/aty/atyfb_base.c:2002:7: error: implicit declaration of function 'aty_ld_lcd'; did you mean

[kernel test robot]

Hi Vaibhav,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f40ddce88593482919761f74910f42f4b84c004b
commit: 348b2956d5e6d9876b567226184de598d00c9bd1 fbdev: aty: use generic power 
management
date:   5 months ago
config: powerpc64-randconfig-r031-20210216 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=348b2956d5e6d9876b567226184de598d00c9bd1
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 348b2956d5e6d9876b567226184de598d00c9bd1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_power_mgmt':
>> drivers/video/fbdev/aty/atyfb_base.c:2002:7: error: implicit declaration of 
>> function 'aty_ld_lcd'; did you mean 'aty_ld_8'? 
>> [-Werror=implicit-function-declaration]
2002 |  pm = aty_ld_lcd(POWER_MANAGEMENT, par);
 |   ^~
 |   aty_ld_8
>> drivers/video/fbdev/aty/atyfb_base.c:2004:2: error: implicit declaration of 
>> function 'aty_st_lcd'; did you mean 'aty_st_8'? 
>> [-Werror=implicit-function-declaration]
2004 |  aty_st_lcd(POWER_MANAGEMENT, pm, par);
 |  ^~
 |  aty_st_8
   drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_init':
   drivers/video/fbdev/aty/atyfb_base.c:2363:6: warning: variable 'dac_type' 
set but not used [-Wunused-but-set-variable]
2363 |   u8 dac_type, dac_subtype, clk_type;
 |  ^~~~
   cc1: some warnings being treated as errors


vim +2002 drivers/video/fbdev/aty/atyfb_base.c

^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 1993  
efc08a75d3a2d4 drivers/video/aty/atyfb_base.c Ville Syrjala  2006-12-08 
 1994  #ifdef CONFIG_PPC_PMAC
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 1995  /* Power management routines. Those are used for PowerBook sleep.
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 1996   */
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 1997  static int aty_power_mgmt(int sleep, struct atyfb_par *par)
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 1998  {
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 1999   u32 pm;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2000   int timeout;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2001  
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
@2002   pm = aty_ld_lcd(POWER_MANAGEMENT, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2003   pm = (pm & ~PWR_MGT_MODE_MASK) | PWR_MGT_MODE_REG;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
@2004   aty_st_lcd(POWER_MANAGEMENT, pm, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2005   pm = aty_ld_lcd(POWER_MANAGEMENT, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2006  
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2007   timeout = 2000;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2008   if (sleep) {
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2009   /* Sleep */
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2010   pm &= ~PWR_MGT_ON;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2011   aty_st_lcd(POWER_MANAGEMENT, pm, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2012   pm = aty_ld_lcd(POWER_MANAGEMENT, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2013   udelay(10);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2014   pm &= ~(PWR_BLON | AUTO_PWR_UP);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2015   pm |= SUSPEND_NOW;
^1da177e4c3f41 drivers/video/aty/atyfb_base.c Linus Torvalds 2005-04-16 
 2016   aty_st_lcd(POWER_MANAGEMENT, pm, par);
^1da177e4c3f41 drivers/video/aty/atyfb_base.c 

Re: [PATCH 00/33] Network fs helper library & fscache kiocb API [ver #3]

[Steve French]

On Mon, Feb 15, 2021 at 8:10 PM Matthew Wilcox  wrote:
>
> On Mon, Feb 15, 2021 at 06:40:27PM -0600, Steve French wrote:
> > It could be good if netfs simplifies the problem experienced by
> > network filesystems on Linux with readahead on large sequential reads
> > - where we don't get as much parallelism due to only having one
> > readahead request at a time (thus in many cases there is 'dead time'
> > on either the network or the file server while waiting for the next
> > readpages request to be issued).   This can be a significant
> > performance problem for current readpages when network latency is long
> > (or e.g. in cases when network encryption is enabled, and hardware
> > offload not available so time consuming on the server or client to
> > encrypt the packet).
> >
> > Do you see netfs much faster than currentreadpages for ceph?
> >
> > Have you been able to get much benefit from throttling readahead with
> > ceph from the current netfs approach for clamping i/o?
>
> The switch from readpages to readahead does help in a couple of corner
> cases.  For example, if you have two processes reading the same file at
> the same time, one will now block on the other (due to the page lock)
> rather than submitting a mess of overlapping and partial reads.

Do you have a simple repro example of this we could try (fio, dbench, iozone
etc) to get some objective perf data?

My biggest worry is making sure that the switch to netfs doesn't degrade
performance (which might be a low bar now since current network file copy
perf seems to signifcantly lag at least Windows), and in some easy to understand
scenarios want to make sure it actually helps perf.

-- 
Thanks,

Steve

Re: [PATCH 00/33] Network fs helper library & fscache kiocb API [ver #3]

[Steve French]

On Mon, Feb 15, 2021 at 8:10 PM Matthew Wilcox  wrote:
>
> On Mon, Feb 15, 2021 at 06:40:27PM -0600, Steve French wrote:
> > It could be good if netfs simplifies the problem experienced by
> > network filesystems on Linux with readahead on large sequential reads
> > - where we don't get as much parallelism due to only having one
> > readahead request at a time (thus in many cases there is 'dead time'
> > on either the network or the file server while waiting for the next
> > readpages request to be issued).   This can be a significant
> > performance problem for current readpages when network latency is long
> > (or e.g. in cases when network encryption is enabled, and hardware
> > offload not available so time consuming on the server or client to
> > encrypt the packet).
> >
> > Do you see netfs much faster than currentreadpages for ceph?
> >
> > Have you been able to get much benefit from throttling readahead with
> > ceph from the current netfs approach for clamping i/o?
>
> The switch from readpages to readahead does help in a couple of corner
> cases.  For example, if you have two processes reading the same file at
> the same time, one will now block on the other (due to the page lock)
> rather than submitting a mess of overlapping and partial reads.
>
> We're not there yet on having multiple outstanding reads.  Bill and I
> had a chat recently about how to make the readahead code detect that
> it is in a "long fat pipe" situation (as opposed to just dealing with
> a slow device), and submit extra readahead requests to make best use of
> the bandwidth and minimise blocking of the application.
>
> That's not something for the netfs code to do though; we can get into
> that situation with highly parallel SSDs.

This (readahead behavior improvements in Linux, on single large file sequential
read workloads like cp or grep) gets particularly interesting
with SMB3 as multichannel becomes more common.  With one channel having
one readahead request pending on the network is suboptimal - but not as bad as
when multichannel is negotiated. Interestingly in most cases two
network connections
to the same server (different TCP sockets,but the same mount, even in
cases where
only network adapter) can achieve better performance - but still significantly
lags Windows (and probably other clients) as in Linux we don't keep
multiple I/Os
in flight at one time (unless different files are being read at the same time
by different threads).   As network adapters are added and removed from the
server (other client typically poll to detect interface changes, and SMB3
also leverages the "witness protocol" to get notification of adapter additions
or removals) - it would be helpful to change the maximum number of
readahead requests in flight.  In addition, as the server throttles back
(reducing the number of 'credits' granted to the client) it will be important
to give hints to the readahead logic about reducing the number of
read ahead requests in flight.   Keeping multiple readahead requests
is easier to imagine when multiple processes are copying or reading
files, but there are many scenarios where we could do better with parallelizing
a single process doing copy by ensuring that there is no 'dead time' on
the network.


-- 
Thanks,

Steve

Re: [PATCH] arc: Replace lkml.org links with lore

[Vineet Gupta]

On 2/10/21 3:28 PM, Kees Cook wrote:

As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org
links with lore"), replace lkml.org links with lore to better use a
single source that's more likely to stay available long-term.

Signed-off-by: Kees Cook 


Acked-by: Vineet Gupta 

Let me know if you want me to pick this up.

Thx,
-Vineet


---
  arch/arc/include/asm/irqflags-compact.h | 8 ++--
  arch/arc/mm/dma.c   | 2 +-
  arch/arc/plat-axs10x/axs10x.c   | 2 +-
  arch/arc/plat-hsdk/platform.c   | 2 +-
  4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arc/include/asm/irqflags-compact.h 
b/arch/arc/include/asm/irqflags-compact.h
index 863d63ad18d6..0d63e568d64c 100644
--- a/arch/arc/include/asm/irqflags-compact.h
+++ b/arch/arc/include/asm/irqflags-compact.h
@@ -50,8 +50,12 @@
   * are redone after IRQs are re-enabled (and gcc doesn't reuse stale register)
   *
   * Noted at the time of Abilis Timer List corruption
- * Orig Bug + Rejected solution: https://lkml.org/lkml/2013/3/29/67
- * Reasoning   : https://lkml.org/lkml/2013/4/8/15
+ *
+ * Orig Bug + Rejected solution:
+ * 
https://lore.kernel.org/lkml/1364553218-31255-1-git-send-email-vgu...@synopsys.com
+ *
+ * Reasoning:
+ * 
https://lore.kernel.org/lkml/ca+55afyfwjpsvqm6m266tkrg_zxjzz-nyejpmxyqxbrr42m...@mail.gmail.com
   *
   **/
  
diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c

index 517988e60cfc..2a7fbbb83b70 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -32,7 +32,7 @@ void arch_dma_prep_coherent(struct page *page, size_t size)
  
  /*

   * Cache operations depending on function and direction argument, inspired by
- * https://lkml.org/lkml/2018/5/18/979
+ * https://lore.kernel.org/lkml/20180518175004.gf17...@n2100.armlinux.org.uk
   * "dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20]
   * dma-mapping: provide a generic dma-noncoherent implementation)"
   *
diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c
index 63ea5a606ecd..b821df7b0089 100644
--- a/arch/arc/plat-axs10x/axs10x.c
+++ b/arch/arc/plat-axs10x/axs10x.c
@@ -50,7 +50,7 @@ static void __init axs10x_enable_gpio_intc_wire(void)
 * Current implementation of "irq-dw-apb-ictl" driver doesn't work well
 * with stacked INTCs. In particular problem happens if its master INTC
 * not yet instantiated. See discussion here -
-* https://lkml.org/lkml/2015/3/4/755
+* https://lore.kernel.org/lkml/54f6fe2c.7020...@synopsys.com
 *
 * So setup the first gpio block as a passive pass thru and hide it from
 * DT hardware topology - connect MB intc directly to cpu intc
diff --git a/arch/arc/plat-hsdk/platform.c b/arch/arc/plat-hsdk/platform.c
index b3ea1fa11f87..c4a875b22352 100644
--- a/arch/arc/plat-hsdk/platform.c
+++ b/arch/arc/plat-hsdk/platform.c
@@ -52,7 +52,7 @@ static void __init hsdk_enable_gpio_intc_wire(void)
 * Current implementation of "irq-dw-apb-ictl" driver doesn't work well
 * with stacked INTCs. In particular problem happens if its master INTC
 * not yet instantiated. See discussion here -
-* https://lkml.org/lkml/2015/3/4/755
+* https://lore.kernel.org/lkml/54f6fe2c.7020...@synopsys.com
 *
 * So setup the first gpio block as a passive pass thru and hide it from
 * DT hardware topology - connect intc directly to cpu intc

[PATCH] ionic: Remove unused function pointer typedef ionic_reset_cb

[Chen Lin]

From: Chen Lin 

Remove the 'ionic_reset_cb' typedef as it is not used.

Signed-off-by: Chen Lin 
---
 drivers/net/ethernet/pensando/ionic/ionic_lif.h |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/pensando/ionic/ionic_lif.h 
b/drivers/net/ethernet/pensando/ionic/ionic_lif.h
index 9bed427..563dba3 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_lif.h
+++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.h
@@ -249,8 +249,6 @@ static inline u32 ionic_coal_usec_to_hw(struct ionic 
*ionic, u32 usecs)
return (usecs * mult) / div;
 }
 
-typedef void (*ionic_reset_cb)(struct ionic_lif *lif, void *arg);
-
 void ionic_link_status_check_request(struct ionic_lif *lif, bool can_sleep);
 void ionic_get_stats64(struct net_device *netdev,
   struct rtnl_link_stats64 *ns);
-- 
1.7.9.5

Re: [External] Re: [PATCH v15 4/8] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page

[Muchun Song]

On Tue, Feb 16, 2021 at 3:39 AM Michal Hocko  wrote:
>
> On Tue 16-02-21 02:19:20, Muchun Song wrote:
> > On Tue, Feb 16, 2021 at 1:48 AM Muchun Song  
> > wrote:
> > >
> > > On Tue, Feb 16, 2021 at 12:28 AM Michal Hocko  wrote:
> > > >
> > > > On Mon 15-02-21 23:36:49, Muchun Song wrote:
> > > > [...]
> > > > > > There shouldn't be any real reason why the memory allocation for
> > > > > > vmemmaps, or handling vmemmap in general, has to be done from 
> > > > > > within the
> > > > > > hugetlb lock and therefore requiring a non-sleeping semantic. All 
> > > > > > that
> > > > > > can be deferred to a more relaxed context. If you want to make a
> > > > >
> > > > > Yeah, you are right. We can put the freeing hugetlb routine to a
> > > > > workqueue. Just like I do in the previous version (before v13) patch.
> > > > > I will pick up these patches.
> > > >
> > > > I haven't seen your v13 and I will unlikely have time to revisit that
> > > > version. I just wanted to point out that the actual allocation doesn't
> > > > have to happen from under the spinlock. There are multiple ways to go
> > > > around that. Dropping the lock would be one of them. Preallocation
> > > > before the spin lock is taken is another. WQ is certainly an option but
> > > > I would take it as the last resort when other paths are not feasible.
> > > >
> > >
> > > "Dropping the lock" and "Preallocation before the spin lock" can limit
> > > the context of put_page to non-atomic context. I am not sure if there
> > > is a page puted somewhere under an atomic context. e.g. compaction.
> > > I am not an expert on this.
> >
> > Using GFP_KERNEL will also use the current task cpuset to allocate
> > memory. Do we have an interface to ignore current task cpuset？If not,
> > WQ may be the only option and it also will not limit the context of
> > put_page. Right?
>
> Well, GFP_KERNEL is constrained to the task cpuset only if the said
> cpuset is hardwalled IIRC. But I do not see why this is a problem.

I mean that if there are more than one node in the system,
but the current task cpuset only allows one node. If current
node has no memory and other nodes have enough memory.
We can fail to allocate vmemmap pages. But actually it is
suitable to allocate vmemmap pages from other nodes.
Right?

Thanks.

> --
> Michal Hocko
> SUSE Labs

[PATCH -next] fs: namei: fix kernel-doc for struct renamedata and more

[Randy Dunlap]

Fix kernel-doc warnings in namei.c:

../fs/namei.c:1149: warning: Excess function parameter 'dir_mode' description 
in 'may_create_in_sticky'
../fs/namei.c:1149: warning: Excess function parameter 'dir_uid' description in 
'may_create_in_sticky'
../fs/namei.c:3396: warning: Function parameter or member 'open_flag' not 
described in 'vfs_tmpfile'
../fs/namei.c:3396: warning: Excess function parameter 'open_flags' description 
in 'vfs_tmpfile'
../fs/namei.c:4460: warning: Function parameter or member 'rd' not described in 
'vfs_rename'
../fs/namei.c:4460: warning: Excess function parameter 'old_mnt_userns' 
description in 'vfs_rename'
../fs/namei.c:4460: warning: Excess function parameter 'old_dir' description in 
'vfs_rename'
../fs/namei.c:4460: warning: Excess function parameter 'old_dentry' description 
in 'vfs_rename'
../fs/namei.c:4460: warning: Excess function parameter 'new_mnt_userns' 
description in 'vfs_rename'
../fs/namei.c:4460: warning: Excess function parameter 'new_dir' description in 
'vfs_rename'
../fs/namei.c:4460: warning: Excess function parameter 'new_dentry' description 
in 'vfs_rename'
../fs/namei.c:4460: warning: Excess function parameter 'delegated_inode' 
description in 'vfs_rename'
../fs/namei.c:4460: warning: Excess function parameter 'flags' description in 
'vfs_rename'

Fixes: 9fe61450972d ("namei: introduce struct renamedata")
Signed-off-by: Randy Dunlap 
Cc: Christoph Hellwig 
Cc: David Howells 
Cc: Al Viro 
Cc: linux-fsde...@vger.kernel.org
Cc: Christian Brauner 
---
 fs/namei.c |   14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

--- linux-next-20210215.orig/fs/namei.c
+++ linux-next-20210215/fs/namei.c
@@ -1121,8 +1121,7 @@ int may_linkat(struct user_namespace *mn
  *   should be allowed, or not, on files that already
  *   exist.
  * @mnt_userns:user namespace of the mount the inode was found from
- * @dir_mode: mode bits of directory
- * @dir_uid: owner of directory
+ * @nd: nameidata pathwalk data
  * @inode: the inode of the file to open
  *
  * Block an O_CREAT open of a FIFO (or a regular file) when:
@@ -3381,7 +3380,7 @@ static int do_open(struct nameidata *nd,
  * @mnt_userns:user namespace of the mount the inode was found from
  * @dentry:pointer to dentry of the base directory
  * @mode:  mode of the new tmpfile
- * @open_flags:flags
+ * @open_flag: flags
  *
  * Create a temporary file.
  *
@@ -4406,14 +4405,7 @@ SYSCALL_DEFINE2(link, const char __user
 
 /**
  * vfs_rename - rename a filesystem object
- * @old_mnt_userns:old user namespace of the mount the inode was found from
- * @old_dir:   parent of source
- * @old_dentry:source
- * @new_mnt_userns:new user namespace of the mount the inode was found from
- * @new_dir:   parent of destination
- * @new_dentry:destination
- * @delegated_inode:   returns an inode needing a delegation break
- * @flags: rename flags
+ * @rd:pointer to  renamedata info
  *
  * The caller must hold multiple mutexes--see lock_rename()).
  *

[PATCH -next] fs: fix new and older kernel-doc warnings in fs/

[Randy Dunlap]

 [PATCH -next] fs: libfs: fix kernel-doc for mnt_userns
 [PATCH -next] fs: namei: fix kernel-doc for struct renamedata and more
 [PATCH -next] fs: xattr: fix kernel-doc for mnt_userns and vfs xattr helpers

Cc: Christoph Hellwig 
Cc: David Howells 
Cc: Al Viro 
Cc: linux-fsde...@vger.kernel.org
Cc: Christian Brauner 
Cc: David P. Quigley 
Cc: James Morris 

 fs/libfs.c |1 +
 fs/namei.c |   14 +++---
 fs/xattr.c |   14 --
 3 files changed, 12 insertions(+), 17 deletions(-)

[PATCH] cw1200: Remove unused function pointer typedef wsm_*

[Chen Lin]

From: Chen Lin 

Remove the 'wsm_*' typedef as it is not used.

Signed-off-by: Chen Lin 
---
 drivers/net/wireless/st/cw1200/wsm.h |   12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/net/wireless/st/cw1200/wsm.h 
b/drivers/net/wireless/st/cw1200/wsm.h
index 1ffa479..89fdc91 100644
--- a/drivers/net/wireless/st/cw1200/wsm.h
+++ b/drivers/net/wireless/st/cw1200/wsm.h
@@ -785,8 +785,6 @@ struct wsm_tx_confirm {
 };
 
 /* 3.15 */
-typedef void (*wsm_tx_confirm_cb) (struct cw1200_common *priv,
-  struct wsm_tx_confirm *arg);
 
 /* Note that ideology of wsm_tx struct is different against the rest of
  * WSM API. wsm_hdr is /not/ a caller-adapted struct to be used as an input
@@ -862,9 +860,6 @@ struct wsm_rx {
 /* = sizeof(generic hi hdr) + sizeof(wsm hdr) */
 #define WSM_RX_EXTRA_HEADROOM (16)
 
-typedef void (*wsm_rx_cb) (struct cw1200_common *priv, struct wsm_rx *arg,
-  struct sk_buff **skb_p);
-
 /* 3.17 */
 struct wsm_event {
/* WSM_STATUS_... */
@@ -1180,8 +1175,6 @@ struct wsm_switch_channel {
 int wsm_switch_channel(struct cw1200_common *priv,
   const struct wsm_switch_channel *arg);
 
-typedef void (*wsm_channel_switch_cb) (struct cw1200_common *priv);
-
 #define WSM_START_REQ_ID 0x0017
 #define WSM_START_RESP_ID 0x0417
 
@@ -1240,8 +1233,6 @@ int wsm_beacon_transmit(struct cw1200_common *priv,
 
 int wsm_stop_find(struct cw1200_common *priv);
 
-typedef void (*wsm_find_complete_cb) (struct cw1200_common *priv, u32 status);
-
 struct wsm_suspend_resume {
/* See 3.52 */
/* Link ID */
@@ -1256,9 +1247,6 @@ struct wsm_suspend_resume {
/* [out] */ int queue;
 };
 
-typedef void (*wsm_suspend_resume_cb) (struct cw1200_common *priv,
-  struct wsm_suspend_resume *arg);
-
 /* 3.54 Update-IE request. */
 struct wsm_update_ie {
/* WSM_UPDATE_IE_... */
-- 
1.7.9.5

[PATCH] cw1200: Remove unused function pointer typedef cw1200_wsm_handler

[Chen Lin]

From: Chen Lin 

Remove the 'cw1200_wsm_handler' typedef as it is not used.

Signed-off-by: Chen Lin 
---
 drivers/net/wireless/st/cw1200/bh.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/wireless/st/cw1200/bh.c 
b/drivers/net/wireless/st/cw1200/bh.c
index c364a39..8bade5d 100644
--- a/drivers/net/wireless/st/cw1200/bh.c
+++ b/drivers/net/wireless/st/cw1200/bh.c
@@ -42,9 +42,6 @@ enum cw1200_bh_pm_state {
CW1200_BH_RESUME,
 };
 
-typedef int (*cw1200_wsm_handler)(struct cw1200_common *priv,
-   u8 *data, size_t size);
-
 static void cw1200_bh_work(struct work_struct *work)
 {
struct cw1200_common *priv =
-- 
1.7.9.5

[PATCH -next] fs: xattr: fix kernel-doc for mnt_userns and vfs xattr helpers

[Randy Dunlap]

Fix kernel-doc warnings in xattr.c:

../fs/xattr.c:257: warning: Function parameter or member 'mnt_userns' not 
described in '__vfs_setxattr_locked'
../fs/xattr.c:485: warning: Function parameter or member 'mnt_userns' not 
described in '__vfs_removexattr_locked'

and fix one function whose kernel-doc was not in the correct format.

Fixes: 71bc356f93a1 ("commoncap: handle idmapped mounts")
Fixes: b1ab7e4b2a88 ("VFS: Factor out part of vfs_setxattr so it can be called 
from the SELinux hook for inode_setsecctx.")
Signed-off-by: Randy Dunlap 
Cc: Christoph Hellwig 
Cc: David Howells 
Cc: Al Viro 
Cc: linux-fsde...@vger.kernel.org
Cc: Christian Brauner 
Cc: David P. Quigley 
Cc: James Morris 
---
 fs/xattr.c |   14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

--- linux-next-20210215.orig/fs/xattr.c
+++ linux-next-20210215/fs/xattr.c
@@ -186,12 +186,12 @@ EXPORT_SYMBOL(__vfs_setxattr);
  *  __vfs_setxattr_noperm - perform setxattr operation without performing
  *  permission checks.
  *
- *  @mnt_userns - user namespace of the mount the inode was found from
- *  @dentry - object to perform setxattr on
- *  @name - xattr name to set
- *  @value - value to set @name to
- *  @size - size of @value
- *  @flags - flags to pass into filesystem operations
+ *  @mnt_userns: user namespace of the mount the inode was found from
+ *  @dentry: object to perform setxattr on
+ *  @name: xattr name to set
+ *  @value: value to set @name to
+ *  @size: size of @value
+ *  @flags: flags to pass into filesystem operations
  *
  *  returns the result of the internal setxattr or setsecurity operations.
  *
@@ -242,6 +242,7 @@ int __vfs_setxattr_noperm(struct user_na
  * __vfs_setxattr_locked - set an extended attribute while holding the inode
  * lock
  *
+ *  @mnt_userns: user namespace of the mount of the target inode
  *  @dentry: object to perform setxattr on
  *  @name: xattr name to set
  *  @value: value to set @name to
@@ -473,6 +474,7 @@ EXPORT_SYMBOL(__vfs_removexattr);
  * __vfs_removexattr_locked - set an extended attribute while holding the inode
  * lock
  *
+ *  @mnt_userns: user namespace of the mount of the target inode
  *  @dentry: object to perform setxattr on
  *  @name: name of xattr to remove
  *  @delegated_inode: on return, will contain an inode pointer that

[PATCH -next] fs: libfs: fix kernel-doc for mnt_userns

[Randy Dunlap]

Fix kernel-doc warning in libfs.c.

../fs/libfs.c:498: warning: Function parameter or member 'mnt_userns' not 
described in 'simple_setattr'

Fixes: 549c7297717c ("fs: make helpers idmap mount aware")
Signed-off-by: Randy Dunlap 
Cc: Christoph Hellwig 
Cc: David Howells 
Cc: Al Viro 
Cc: linux-fsde...@vger.kernel.org
Cc: Christian Brauner 
---
 fs/libfs.c |1 +
 1 file changed, 1 insertion(+)

--- linux-next-20210215.orig/fs/libfs.c
+++ linux-next-20210215/fs/libfs.c
@@ -481,6 +481,7 @@ EXPORT_SYMBOL(simple_rename);
 
 /**
  * simple_setattr - setattr for simple filesystem
+ * @mnt_userns: user namespace of the target mount
  * @dentry: dentry
  * @iattr: iattr structure
  *

Re: [PATCH 5.10 000/104] 5.10.17-rc1 review

[Naresh Kamboju]

On Mon, 15 Feb 2021 at 21:02, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.10.17 release.
> There are 104 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 17 Feb 2021 15:27:00 +.
> 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.10.17-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.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and i386.

Tested-by: Linux Kernel Functional Testing 

NOTE:
The reported problem from last week's fix is in discussion.
scripts: Fix linking extract-cert against libcrypto
https://lore.kernel.org/stable/20210209050047.1958473-1-daniel.d...@linaro.org/T/#u

Summary


kernel: 5.10.17-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.10.y
git commit: 643709657afaaebc02f8fc7cd4e96bebe6ad0ccb
git describe: v5.10.16-105-g643709657afa
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.16-105-g643709657afa/

No regressions (compared to build v5.10.16)

No fixes (compared to build v5.10.16)

Ran 50355 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan
- x86_64

Test Suites
---
* build
* linux-log-parser
* install-android-platform-tools-r2600
* kvm-unit-tests
* libhugetlbfs
* ltp-commands-tests
* ltp-containers-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* fwts
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-mm-tests
* ltp-controllers-tests
* ltp-open-posix-tests
* network-basic-tests
* perf
* v4l2-compliance
* kunit
* rcutorture
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-lib
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* kselftest
* kselftest-intel_pstate
* kselftest-kexec
* kselftest-kvm
* kselftest-livepatch
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-vm
* kselftest-x86

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 2/2] exfat: add support FITRIM ioctl

[Hyeongseok Kim]

Hi Chaitanya,
Thank you for the review.

On 2/16/21 4:33 AM, Chaitanya Kulkarni wrote:

On 2/14/21 20:28, Hyeongseok Kim wrote:

+
+int exfat_trim_fs(struct inode *inode, struct fstrim_range *range)
+{
+   struct super_block *sb = inode->i_sb;

Reverse tree style for function variable declaration would be nice which you
partially have it here.

So, you mean that it would be better to be somethink like this, right?

+
+int exfat_trim_fs(struct inode *inode, struct fstrim_range *range)
+{
+   unsigned int trim_begin, trim_end, count, next_free_clu;
+   u64 clu_start, clu_end, trim_minlen, trimmed_total = 0;
+   struct super_block *sb = inode->i_sb;
+   struct exfat_sb_info *sbi = EXFAT_SB(sb);
+   int err = 0;
+


+   else {
+   /* trim current range if it's larger than trim_minlen */
+   count = trim_end - trim_begin + 1;
+   if (count >= trim_minlen) {
+   err = sb_issue_discard(sb,
+   exfat_cluster_to_sector(sbi, 
trim_begin),
+   count * sbi->sect_per_clus, GFP_NOFS, 
0);

You are specifying the last argument as 0 to sb_issue_disacrd() i.e.
flags == 0 this will propagate to :-

sb_issue_discard()
 blkdev_issue_discard()
 __blkdev__issue_discard()

Now blkdev_issue_disacrd() returns -ENOTSUPP in 3 cases :-

1. If flags arg is set to BLKDEV_DISCARD_SECURE and queue doesn't support
secure erase. In this case you have not set BLKDEV_DISCARD_SECURE that.
So it should not return -EOPNOTSUPP.
2. If queue doesn't support discard. In this case caller of this function
already set that. So it should not return -EOPNOTSUPP.
3. If q->limits.discard_granularity is not but LLD which I think caller of
this function already used that to calculate the range->minlen.

If above is true then err will not have value of -EOPNOTSUPP ?
I think case 3. could be possible, but I agree we don't need to handle 
-EOPNOTSUPP in other way,

but better to just return it. I'll fix this in v2.

+   if (need_resched()) {
+   mutex_unlock(_SB(inode->i_sb)->s_lock);

sb_issue_discard() ->blkdev_issue_discard() will call cond_resced().
1. The check for need_resched() will ever be true since
blkdev_issue_discard()
is already calling cond_sched() ?
2. If so do you still need to drop the mutex before calling
sb_issue_discard() ?
I considered the case if there are no more used blocks or no more free 
blocks (no fragmentation)
to the end of the disk, then we couldn't have the chance to call 
sb_issue_discard() until this loop ends,

that would possibly take long time.
But it's not a good idea because other process can have chance to use 
blocks which were already
been ready to discard, if we release the mutex here. I'll remove this in 
v2.

+   cond_resched();
+   mutex_lock(_SB(inode->i_sb)->s_lock);
+   }
+

..

+
switch (cmd) {
+   case FITRIM:
+   {
+   struct request_queue *q = bdev_get_queue(sb->s_bdev);
+   struct fstrim_range range;
+   int ret = 0;
+
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+
+   if (!blk_queue_discard(q))
+   return -EOPNOTSUPP;
+
+   if (copy_from_user(, (struct fstrim_range __user *)arg,
+   sizeof(range)))
+   return -EFAULT;
+
+   range.minlen = max_t(unsigned int, range.minlen,
+   q->limits.discard_granularity);
+
+   ret = exfat_trim_fs(inode, );
+   if (ret < 0)
+   return ret;
+
+   if (copy_to_user((struct fstrim_range __user *)arg, ,
+   sizeof(range)))
+   return -EFAULT;
+
+   return 0;
+   }
+

Is {} really needed for switch case ?
Also, code related to FITRIM needs to be moved to a helper otherwise it
will bloat
the ioctl function, unless that is the objective here.

default:
return -ENOTTY;
}

OK, I'll move it into the exfat_trim_fs().

Re: [PATCH 5.4 00/60] 5.4.99-rc1 review

[Naresh Kamboju]

On Mon, 15 Feb 2021 at 20:59, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.4.99 release.
> There are 60 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 17 Feb 2021 15:27:00 +.
> 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.99-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:
The following lockdep warning was found during the arm64 db410c boot.
And this is easily reproducible.

WARNING: possible recursive locking detected
5.4.99-rc1 #1 Not tainted

 kworker/1:1/31 is trying to acquire lock:
 0eb36940 (regulator_ww_class_mutex){+.+.}, at:
create_regulator+0x23c/0x360


Summary


kernel: 5.4.99-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: c65ed94f3071e59865975e91b52ec522a50f7ade
git describe: v5.4.98-61-gc65ed94f3071
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.98-61-gc65ed94f3071

No regressions (compared to build v5.4.97-25-g539f3bba2f5b)

No fixes (compared to build v5.4.97-25-g539f3bba2f5b)

Ran 50148 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan
- x86_64

Test Suites
---
* build
* linux-log-parser
* install-android-platform-tools-r2600
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-intel_pstate
* kselftest-livepatch
* kselftest-lkdtm
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-dio-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* perf
* fwts
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-tc-testing
* kvm-unit-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-sched-tests
* ltp-syscalls-tests
* network-basic-tests
* v4l2-compliance
* kselftest-kexec
* kselftest-kvm
* kselftest-vm
* kselftest-x86
* ltp-controllers-tests
* ltp-fs-tests
* ltp-open-posix-tests
* ltp-tracing-tests
* rcutorture
* kselftest-
* kselftest-vsyscall-mode-native-
* ssuite
* timesync-off


--
Linaro LKFT
https://lkft.linaro.org

[PATCH v5 2/3] x86/sgx: Allows ioctl PROVISION to execute before CREATE

[Tianjia Zhang]

In the function sgx_create_enclave(), the direct assignment
operation of attributes_mask determines that the ioctl PROVISION
operation must be executed after the ioctl CREATE operation,
which will limit the flexibility of SGX developers.

This patch takes the assignment of attributes_mask from the
function sgx_create_enclave() has been moved to the function
sgx_open(), this will allow users to perform ioctl PROVISION
operations before ioctl CREATE, increase the flexibility of
the API and reduce restrictions.

Signed-off-by: Tianjia Zhang 
---
 arch/x86/kernel/cpu/sgx/driver.c | 1 +
 arch/x86/kernel/cpu/sgx/ioctl.c  | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/sgx/driver.c b/arch/x86/kernel/cpu/sgx/driver.c
index 8ce6d8371cfb..892e2a2a3221 100644
--- a/arch/x86/kernel/cpu/sgx/driver.c
+++ b/arch/x86/kernel/cpu/sgx/driver.c
@@ -36,6 +36,7 @@ static int sgx_open(struct inode *inode, struct file *file)
return ret;
}
 
+   encl->attributes_mask = SGX_ATTR_DEBUG | SGX_ATTR_MODE64BIT | 
SGX_ATTR_KSS;
file->private_data = encl;
 
return 0;
diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index 90a5caf76939..1c6ecf9fbeff 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -109,7 +109,6 @@ static int sgx_encl_create(struct sgx_encl *encl, struct 
sgx_secs *secs)
encl->base = secs->base;
encl->size = secs->size;
encl->attributes = secs->attributes;
-   encl->attributes_mask = SGX_ATTR_DEBUG | SGX_ATTR_MODE64BIT | 
SGX_ATTR_KSS;
 
/* Set only after completion, as encl->lock has not been taken. */
set_bit(SGX_ENCL_CREATED, >flags);
-- 
2.19.1.3.ge56e4f7

[PATCH v5 0/3] Some optimizations related to sgx

[Tianjia Zhang]

This is an optimization of a set of sgx-related codes, each of which
is independent of the patch. Because the second and third patches have
conflicting dependencies, these patches are put together.

---
v5 changes:
  * Remove the two patches with no actual value
  * Typo fix in commit message

v4 changes:
  * Improvements suggested by review

v3 changes:
  * split free_cnt count and spin lock optimization into two patches

v2 changes:
  * review suggested changes

Tianjia Zhang (3):
  selftests/x86: Use getauxval() to simplify the code in sgx
  x86/sgx: Allows ioctl PROVISION to execute before CREATE
  x86/sgx: Remove redundant if conditions in sgx_encl_create

 arch/x86/kernel/cpu/sgx/driver.c   |  1 +
 arch/x86/kernel/cpu/sgx/ioctl.c|  8 
 tools/testing/selftests/sgx/main.c | 24 
 3 files changed, 9 insertions(+), 24 deletions(-)

-- 
2.19.1.3.ge56e4f7

[PATCH v5 3/3] x86/sgx: Remove redundant if conditions in sgx_encl_create

[Tianjia Zhang]

In this scenario, there is no case where va_page is NULL, and
the error has been checked. The if-condition statement here is
redundant, so remove the condition detection.

Signed-off-by: Tianjia Zhang 
Acked-by: Jarkko Sakkinen 
---
 arch/x86/kernel/cpu/sgx/ioctl.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index 1c6ecf9fbeff..719c21cca569 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -66,9 +66,10 @@ static int sgx_encl_create(struct sgx_encl *encl, struct 
sgx_secs *secs)
va_page = sgx_encl_grow(encl);
if (IS_ERR(va_page))
return PTR_ERR(va_page);
-   else if (va_page)
-   list_add(_page->list, >va_pages);
-   /* else the tail page of the VA page list had free slots. */
+   if (!va_page)
+   return -EIO;
+
+   list_add(_page->list, >va_pages);
 
/* The extra page goes to SECS. */
encl_size = secs->size + PAGE_SIZE;
-- 
2.19.1.3.ge56e4f7

[PATCH v5 1/3] selftests/x86: Use getauxval() to simplify the code in sgx

[Tianjia Zhang]

Simplify the sgx code implemntation by using library function
getauxval() instead of a custom function to get the base address
of vDSO.

Signed-off-by: Tianjia Zhang 
Reviewed-by: Jarkko Sakkinen 
Acked-by: Shuah Khan 
---
 tools/testing/selftests/sgx/main.c | 24 
 1 file changed, 4 insertions(+), 20 deletions(-)

diff --git a/tools/testing/selftests/sgx/main.c 
b/tools/testing/selftests/sgx/main.c
index 724cec700926..5167505fbb46 100644
--- a/tools/testing/selftests/sgx/main.c
+++ b/tools/testing/selftests/sgx/main.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "defines.h"
 #include "main.h"
 #include "../kselftest.h"
@@ -28,24 +29,6 @@ struct vdso_symtab {
Elf64_Word *elf_hashtab;
 };
 
-static void *vdso_get_base_addr(char *envp[])
-{
-   Elf64_auxv_t *auxv;
-   int i;
-
-   for (i = 0; envp[i]; i++)
-   ;
-
-   auxv = (Elf64_auxv_t *)[i + 1];
-
-   for (i = 0; auxv[i].a_type != AT_NULL; i++) {
-   if (auxv[i].a_type == AT_SYSINFO_EHDR)
-   return (void *)auxv[i].a_un.a_val;
-   }
-
-   return NULL;
-}
-
 static Elf64_Dyn *vdso_get_dyntab(void *addr)
 {
Elf64_Ehdr *ehdr = addr;
@@ -162,7 +145,7 @@ static int user_handler(long rdi, long rsi, long rdx, long 
ursp, long r8, long r
return 0;
 }
 
-int main(int argc, char *argv[], char *envp[])
+int main(int argc, char *argv[])
 {
struct sgx_enclave_run run;
struct vdso_symtab symtab;
@@ -203,7 +186,8 @@ int main(int argc, char *argv[], char *envp[])
memset(, 0, sizeof(run));
run.tcs = encl.encl_base;
 
-   addr = vdso_get_base_addr(envp);
+   /* Get vDSO base address */
+   addr = (void *)getauxval(AT_SYSINFO_EHDR);
if (!addr)
goto err;
 
-- 
2.19.1.3.ge56e4f7

[RFC PATCH] mm, oom: introduce vm.sacrifice_hugepage_on_oom

[Eiichi Tsukata]

Hugepages can be preallocated to avoid unpredictable allocation latency.
If we run into 4k page shortage, the kernel can trigger OOM even though
there were free hugepages. When OOM is triggered by user address page
fault handler, we can use oom notifier to free hugepages in user space
but if it's triggered by memory allocation for kernel, there is no way
to synchronously handle it in user space.

This patch introduces a new sysctl vm.sacrifice_hugepage_on_oom. If
enabled, it first tries to free a hugepage if available before invoking
the oom-killer. The default value is disabled not to change the current
behavior.

Signed-off-by: Eiichi Tsukata 
---
 Documentation/admin-guide/sysctl/vm.rst | 12 
 include/linux/hugetlb.h |  2 ++
 include/linux/oom.h |  1 +
 kernel/sysctl.c |  9 +
 mm/hugetlb.c|  4 ++--
 mm/oom_kill.c   | 23 +++
 6 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/sysctl/vm.rst 
b/Documentation/admin-guide/sysctl/vm.rst
index e35a3f2fb006..f2f195524be6 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -65,6 +65,7 @@ Currently, these files are in /proc/sys/vm:
 - page-cluster
 - panic_on_oom
 - percpu_pagelist_fraction
+- sacrifice_hugepage_on_oom
 - stat_interval
 - stat_refresh
 - numa_stat
@@ -807,6 +808,17 @@ The initial value is zero.  Kernel does not use this value 
at boot time to set
 the high water marks for each per cpu page list.  If the user writes '0' to 
this
 sysctl, it will revert to this default behavior.
 
+sacrifice_hugepage_on_oom
+=
+
+This value controls whether the kernel should attempt to break up hugepages
+when out-of-memory happens. OOM happens under memory cgroup would not invoke
+this.
+
+If set to 0 (default), the kernel doesn't touch the hugepage pool during OOM
+conditions.
+If set to 1, the kernel frees one hugepage at a time, if available, before
+invoking the oom-killer.
 
 stat_interval
 =
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index b5807f23caf8..8aad2f2ab6e6 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -145,6 +145,8 @@ int hugetlb_reserve_pages(struct inode *inode, long from, 
long to,
 long hugetlb_unreserve_pages(struct inode *inode, long start, long end,
long freed);
 bool isolate_huge_page(struct page *page, struct list_head *list);
+int free_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed,
+   bool acct_surplus);
 void putback_active_hugepage(struct page *page);
 void move_hugetlb_state(struct page *oldpage, struct page *newpage, int 
reason);
 void free_huge_page(struct page *page);
diff --git a/include/linux/oom.h b/include/linux/oom.h
index 2db9a1432511..0bfae027ec16 100644
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -127,4 +127,5 @@ extern struct task_struct *find_lock_task_mm(struct 
task_struct *p);
 extern int sysctl_oom_dump_tasks;
 extern int sysctl_oom_kill_allocating_task;
 extern int sysctl_panic_on_oom;
+extern int sysctl_sacrifice_hugepage_on_oom;
 #endif /* _INCLUDE_LINUX_OOM_H */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index c9fbdd848138..d2e3ec625f5f 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2708,6 +2708,15 @@ static struct ctl_table vm_table[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec,
},
+   {
+   .procname   = "sacrifice_hugepage_on_oom",
+   .data   = _sacrifice_hugepage_on_oom,
+   .maxlen = sizeof(sysctl_sacrifice_hugepage_on_oom),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec_minmax,
+   .extra1 = SYSCTL_ZERO,
+   .extra2 = SYSCTL_ONE,
+   },
{
.procname   = "overcommit_ratio",
.data   = _overcommit_ratio,
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4bdb58ab14cb..e2d57200fd00 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1726,8 +1726,8 @@ static int alloc_pool_huge_page(struct hstate *h, 
nodemask_t *nodes_allowed,
  * balanced over allowed nodes.
  * Called with hugetlb_lock locked.
  */
-static int free_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed,
-bool acct_surplus)
+int free_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed,
+   bool acct_surplus)
 {
int nr_nodes, node;
int ret = 0;
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 04b19b7b5435..fd2c1f427926 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include "internal.h"
@@ -52,6 +53,7 @@
 

Re: [PATCH v3 3/5] x86/sgx: Optimize the free_cnt count in sgx_epc_section

[Tianjia Zhang]

On 2/12/21 8:19 PM, Jarkko Sakkinen wrote:

On Thu, Feb 11, 2021 at 02:04:12PM +0800, Tianjia Zhang wrote:

Hi,

Sorry for the late reply.

On 1/28/21 1:40 AM, Jarkko Sakkinen wrote:

I could bet some money that this does not bring any significant
performance gain.



Yes, this does not bring performance gains. This is not a change for
performance, mainly to make the value of free_cnt look more accurate.


On Sun, Jan 24, 2021 at 02:29:05PM +0800, Tianjia Zhang wrote:

`section->free_cnt` represents the free page in sgx_epc_section,
which is assigned once after initialization. In fact, just after the
initialization is completed, the pages are in the `init_laundry_list`
list and cannot be allocated. This needs to be recovered by EREMOVE
of function sgx_sanitize_section() before it can be used as a page
that can be allocated. The sgx_sanitize_section() will be called in
the kernel thread ksgxd.

This patch moves the initialization of `section->free_cnt` from the
initialization function `sgx_setup_epc_section()` to the function
`sgx_sanitize_section()`, and then accumulates the count after the


Use single quotes instead of hyphens.

successful execution of EREMOVE. This seems to be more reasonable,

free_cnt will also truly reflect the allocatable free pages in EPC.

Sined-off-by: Tianjia Zhang 
Reviewed-by: Sean Christopherson 
---
   arch/x86/kernel/cpu/sgx/main.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
index 4465912174fd..e455ec7b3449 100644
--- a/arch/x86/kernel/cpu/sgx/main.c
+++ b/arch/x86/kernel/cpu/sgx/main.c
@@ -48,6 +48,7 @@ static void sgx_sanitize_section(struct sgx_epc_section 
*section)
if (!ret) {
spin_lock(>lock);
list_move(>list, >page_list);
+   section->free_cnt++;
spin_unlock(>lock);


Someone can try to allocate a page while sanitize process is in progress.

I think it is better to keep critical sections in the form that when you
leave from one, the global state is legit.



Do you mean to move the critical section to protect the entire while loop?
Of course, this is also possible, sanitize is a process only needed for
initialization, and the possibility of conflict is very small.

Best regards,
Tianjia


The big picture of this change to me, to be frank is that it's completely
useless.

Please start with the picture.

/Jarkko



I carefully considered your suggestion, and I will delete 2/5 and 3/5 in 
the next version.


Best regards,
Tianjia

[tip:irq/core] BUILD SUCCESS 0b6d70e571a1c764ab079e5c31d4156feee4b06b

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
irq/core
branch HEAD: 0b6d70e571a1c764ab079e5c31d4156feee4b06b  Merge tag 'irqchip-5.12' 
of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core

elapsed time: 722m

configs tested: 120
configs skipped: 5

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
arm eseries_pxa_defconfig
sparcalldefconfig
powerpc  ppc6xx_defconfig
sh  rts7751r2d1_defconfig
arc nsimosci_hs_smp_defconfig
mips   capcella_defconfig
mips allmodconfig
sh   se7619_defconfig
powerpcge_imp3a_defconfig
powerpc   holly_defconfig
powerpcmpc7448_hpc2_defconfig
mips  maltasmvp_defconfig
powerpc mpc836x_mds_defconfig
armvt8500_v6_v7_defconfig
nios2 3c120_defconfig
arm bcm2835_defconfig
m68kq40_defconfig
nds32 allnoconfig
mipsmaltaup_xpa_defconfig
shsh7763rdp_defconfig
arm   stm32_defconfig
riscvnommu_virt_defconfig
m68k   m5275evb_defconfig
xtensa   common_defconfig
powerpc powernv_defconfig
ia64  tiger_defconfig
powerpc mpc837x_rdb_defconfig
openrisc  or1klitex_defconfig
c6x defconfig
sh  rsk7264_defconfig
arm  pxa255-idp_defconfig
arcvdk_hs38_defconfig
sh  r7780mp_defconfig
arm  badge4_defconfig
powerpc ksi8560_defconfig
riscvnommu_k210_defconfig
mips   ip27_defconfig
armpleb_defconfig
arm  jornada720_defconfig
sh   se7722_defconfig
mips cu1000-neo_defconfig
sh espt_defconfig
armxcep_defconfig
powerpc  iss476-smp_defconfig
h8300h8300h-sim_defconfig
arm  lpd270_defconfig
mipsnlm_xlp_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a003-20210215
i386 randconfig-a005-20210215
i386 randconfig-a002-20210215
i386 randconfig-a006-20210215
i386 randconfig-a004-20210215
i386 randconfig-a001-20210215
x86_64   randconfig-a016-20210215
x86_64   randconfig-a013-20210215
x86_64   randconfig-a012-20210215
x86_64   randconfig-a015-20210215
x86_64   randconfig-a014-20210215
x86_64   randconfig-a011-20210215
i386 randconfig-a016-20210215
i386 randconfig-a014-20210215
i386 randconfig-a012-20210215
i386

Re: [PATCH] of: property: fw_devlink: Ignore interrupts property for some configs

[Guenter Roeck]

On Mon, Feb 15, 2021 at 02:42:58PM -0800, Saravana Kannan wrote:
> When CONFIG_OF_IRQ is not defined, it doesn't make sense to parse
> interrupts property.
> 
> Also, parsing and tracking interrupts property breaks some PPC
> devices[1].  But none of the IRQ drivers in PPC seem ready to be
> converted to a proper platform (or any bus) driver. So, there's not much
> of a point in tracking the interrupts property for CONFIG_PPC. So, let's
> stop parsing interrupts for CONFIG_PPC.
> 
> [1] - https://lore.kernel.org/lkml/20210213185422.ga195...@roeck-us.net/
> Fixes: 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts")
> Reported-by: Guenter Roeck 
> Signed-off-by: Saravana Kannan 

That does the trick, at least for my test cases.

Tested-by: Guenter Roeck 

Guenter

> ---
> Greg/Rob,
> 
> I believe this needs to land on driver-core-next.
> 
> -Saravana
> 
>  drivers/of/property.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 79b68519fe30..5036a362f52e 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1300,6 +1300,9 @@ static struct device_node *parse_interrupts(struct 
> device_node *np,
>  {
>   struct of_phandle_args sup_args;
>  
> + if (!IS_ENABLED(CONFIG_OF_IRQ) || IS_ENABLED(CONFIG_PPC))
> + return NULL;
> +
>   if (strcmp(prop_name, "interrupts") &&
>   strcmp(prop_name, "interrupts-extended"))
>   return NULL;
> -- 
> 2.30.0.478.g8a0d178c01-goog
> 

Re: [PATCH v2 1/1] arm64: mm: correct the inside linear map boundaries during hotplug check

[Anshuman Khandual]

On 2/16/21 1:21 AM, Pavel Tatashin wrote:
> On Mon, Feb 15, 2021 at 2:34 PM Ard Biesheuvel  wrote:
>>
>> On Mon, 15 Feb 2021 at 20:30, Pavel Tatashin  
>> wrote:
>>>
 Can't we simply use signed arithmetic here? This expression works fine
 if the quantities are all interpreted as s64 instead of u64
>>>
>>> I was thinking about that, but I do not like the idea of using sign
>>> arithmetics for physical addresses. Also, I am worried that someone in
>>> the future will unknowingly change it to unsigns or to phys_addr_t. It
>>> is safer to have start explicitly set to 0 in case of wrap.
>>
>> memstart_addr is already a s64 for this exact reason.
> 
> memstart_addr is basically an offset and it must be negative. For
> example, this would not work if it was not signed:
> #define vmemmap ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))
> 
> However, on powerpc it is phys_addr_t type.
> 
>>
>> Btw, the KASLR check is incorrect: memstart_addr could also be
>> negative when running the 52-bit VA kernel on hardware that is only
>> 48-bit VA capable.
> 
> Good point!
> 
> if (IS_ENABLED(CONFIG_ARM64_VA_BITS_52) && (vabits_actual != 52))
> memstart_addr -= _PAGE_OFFSET(48) - _PAGE_OFFSET(52);
> 
> So, I will remove IS_ENABLED(CONFIG_RANDOMIZE_BASE) again.
> 
> I am OK to change start_linear_pa, end_linear_pa to signed, but IMO
> what I have now is actually safer to make sure that does not break
> again in the future.
An explicit check for the flip over and providing two different start
addresses points would be required in order to use the new framework.

[PATCH 2/2] kbuild: check the minimum linker version in Kconfig

[Masahiro Yamada]

Unify the two scripts/ld-version.sh and scripts/lld-version.sh, and
check the minimum linker version like scripts/cc-version.sh did.

I tested this script for some corner cases reported in the past:

 - GNU ld version 2.25-15.fc23
   as reported by commit 8083013fc320 ("ld-version: Fix it on Fedora")

 - GNU ld (GNU Binutils) 2.20.1.20100303
   as reported by commit 0d61ed17dd30 ("ld-version: Drop the 4th and
   5th version components")

This script show an error message if the linker is too old:

  $ make LD=ld.lld-9
SYNCinclude/config/auto.conf
  ***
  *** Linker is too old.
  ***   Your LLD version:9.0.1
  ***   Minimum LLD version: 10.0.1
  ***
  scripts/Kconfig.include:50: Sorry, this linker is not supported.
  make[2]: *** [scripts/kconfig/Makefile:71: syncconfig] Error 1
  make[1]: *** [Makefile:600: syncconfig] Error 2
  make: *** [Makefile:708: include/config/auto.conf] Error 2

I also moved the check for gold to this script, so gold is still rejected:

  $ make LD=gold
SYNCinclude/config/auto.conf
  gold linker is not supported as it is not capable of linking the kernel 
proper.
  scripts/Kconfig.include:50: Sorry, this linker is not supported.
  make[2]: *** [scripts/kconfig/Makefile:71: syncconfig] Error 1
  make[1]: *** [Makefile:600: syncconfig] Error 2
  make: *** [Makefile:708: include/config/auto.conf] Error 2

Thanks to David Laight for suggesting shell script improvements.

Signed-off-by: Masahiro Yamada 
---

 MAINTAINERS |  1 -
 init/Kconfig| 21 +++
 scripts/Kconfig.include |  7 +++-
 scripts/ld-version.sh   | 82 -
 scripts/lld-version.sh  | 20 --
 5 files changed, 90 insertions(+), 41 deletions(-)
 delete mode 100755 scripts/lld-version.sh

diff --git a/MAINTAINERS b/MAINTAINERS
index df820969be1f..6b82ad6990b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4314,7 +4314,6 @@ C:irc://chat.freenode.net/clangbuiltlinux
 F: Documentation/kbuild/llvm.rst
 F: include/linux/compiler-clang.h
 F: scripts/clang-tools/
-F: scripts/lld-version.sh
 K: \b(?i:clang|llvm)\b
 
 CLEANCACHE API
diff --git a/init/Kconfig b/init/Kconfig
index 7bcfa24524c2..42b69ee29dca 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -33,24 +33,29 @@ config GCC_VERSION
default $(cc-version) if CC_IS_GCC
default 0
 
-config LD_VERSION
-   int
-   default $(shell,$(LD) --version | $(srctree)/scripts/ld-version.sh)
-
 config CC_IS_CLANG
def_bool $(success,test "$(cc-name)" = Clang)
 
-config LD_IS_LLD
-   def_bool $(success,$(LD) -v | head -n 1 | grep -q LLD)
-
 config CLANG_VERSION
int
default $(cc-version) if CC_IS_CLANG
default 0
 
+config LD_IS_BFD
+   def_bool $(success,test "$(ld-name)" = BFD)
+
+config LD_VERSION
+   int
+   default $(ld-version) if LD_IS_BFD
+   default 0
+
+config LD_IS_LLD
+   def_bool $(success,test "$(ld-name)" = LLD)
+
 config LLD_VERSION
int
-   default $(shell,$(srctree)/scripts/lld-version.sh $(LD))
+   default $(ld-version) if LD_IS_LLD
+   default 0
 
 config CC_CAN_LINK
bool
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index 0228cb9c74aa..58fdb5308725 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -45,8 +45,11 @@ $(error-if,$(success,test -z "$(cc-info)"),Sorry$(comma) 
this compiler is not su
 cc-name := $(shell,set -- $(cc-info) && echo $1)
 cc-version := $(shell,set -- $(cc-info) && echo $2)
 
-# Fail if the linker is gold as it's not capable of linking the kernel proper
-$(error-if,$(success, $(LD) -v | grep -q gold), gold linker '$(LD)' not 
supported)
+# Get the linker name, version, and error out if it is not supported.
+ld-info := $(shell,$(srctree)/scripts/ld-version.sh $(LD))
+$(error-if,$(success,test -z "$(ld-info)"),Sorry$(comma) this linker is not 
supported.)
+ld-name := $(shell,set -- $(ld-info) && echo $1)
+ld-version := $(shell,set -- $(ld-info) && echo $2)
 
 # machine bit flags
 #  $(m32-flag): -m32 if the compiler supports it, or an empty string otherwise.
diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
index 0f8a2c0f9502..a463273509b5 100755
--- a/scripts/ld-version.sh
+++ b/scripts/ld-version.sh
@@ -1,11 +1,73 @@
-#!/usr/bin/awk -f
+#!/bin/sh
 # SPDX-License-Identifier: GPL-2.0
-# extract linker version number from stdin and turn into single number
-   {
-   gsub(".*\\)", "");
-   gsub(".*version ", "");
-   gsub("-.*", "");
-   split($1,a, ".");
-   print a[1]*1 + a[2]*100 + a[3];
-   exit
-   }
+#
+# Print the linker name and its version in a 5 or 6-digit form.
+# Also, perform the minimum version check.
+
+set -e
+
+# When you raise the minimum linker version, please update
+# Documentation/process/changes.rst as well.
+bfd_min_version=2.23.0
+lld_min_version=10.0.1
+
+# Convert the version string x.y.z to a canonical 5 or 6-digit form.

[PATCH 1/2] kbuild: remove ld-version macro

[Masahiro Yamada]

There is no direct user of ld-version; you can use CONFIG_LD_VERSION
if needed.

Signed-off-by: Masahiro Yamada 
---

 scripts/Kbuild.include | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 08e011175b4c..509e0856d653 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -141,13 +141,9 @@ cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) 
$(2)000 ] && echo $(3) || e
 # Usage: KBUILD_LDFLAGS += $(call ld-option, -X, -Y)
 ld-option = $(call try-run, $(LD) $(KBUILD_LDFLAGS) $(1) -v,$(1),$(2),$(3))
 
-# ld-version
-# Note this is mainly for HJ Lu's 3 number binutil versions
-ld-version = $(shell $(LD) --version | $(srctree)/scripts/ld-version.sh)
-
 # ld-ifversion
 # Usage:  $(call ld-ifversion, -ge, 22252, y)
-ld-ifversion = $(shell [ $(ld-version) $(1) $(2) ] && echo $(3) || echo $(4))
+ld-ifversion = $(shell [ $(CONFIG_LD_VERSION)0 $(1) $(2)0 ] && echo $(3) || 
echo $(4))
 
 ##
 
-- 
2.27.0

Re: [PATCH] ntfs: move check for valid resident attribute offset and length

[Anton Altaparmakov]

Hi Rustam,

Thank you for the patch but it is not quite correct:

1) The first delta: yes that is a good idea to add this check but the error 
message is incorrect.  It should say "Corrupt standard information attribute in 
inode." instead.

2) The second delta: The check of the attribute list attribute needs to remain, 
i.e. your second delta needs to be deleted.

Please could you address both of the above comments and then resend?  Please 
then also add: "Acked-by: Anton Altaparmakov " to the patch.

Thanks a lot in advance!

Best regards,

Anton

> On 14 Feb 2021, at 22:12, Rustam Kovhaev  wrote:
> 
> we should check for valid resident atribute offset and length before
> loading STANDARD_INFORMATION attribute in ntfs_read_locked_inode()
> let's make that check a bit earlier in the same function to avoid
> use-after-free bug
> 
> Reported-and-tested-by: syzbot+c584225dabdea2f71...@syzkaller.appspotmail.com
> Signed-off-by: Rustam Kovhaev 
> Link: https://syzkaller.appspot.com/bug?extid=c584225dabdea2f71969
> ---
> fs/ntfs/inode.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
> index f7e4cbc26eaf..70745aea5106 100644
> --- a/fs/ntfs/inode.c
> +++ b/fs/ntfs/inode.c
> @@ -629,6 +629,13 @@ static int ntfs_read_locked_inode(struct inode *vi)
>   }
>   a = ctx->attr;
>   /* Get the standard information attribute value. */
> + if ((u8 *)a + le16_to_cpu(a->data.resident.value_offset)
> + + le32_to_cpu(
> + a->data.resident.value_length) >
> + (u8 *)ctx->mrec + vol->mft_record_size) {
> + ntfs_error(vi->i_sb, "Corrupt attribute list in inode.");
> + goto unm_err_out;
> + }
>   si = (STANDARD_INFORMATION*)((u8*)a +
>   le16_to_cpu(a->data.resident.value_offset));
> 
> @@ -731,14 +738,6 @@ static int ntfs_read_locked_inode(struct inode *vi)
>   goto unm_err_out;
>   }
>   } else /* if (!a->non_resident) */ {
> - if ((u8*)a + le16_to_cpu(a->data.resident.value_offset)
> - + le32_to_cpu(
> - a->data.resident.value_length) >
> - (u8*)ctx->mrec + vol->mft_record_size) {
> - ntfs_error(vi->i_sb, "Corrupt attribute list "
> - "in inode.");
> - goto unm_err_out;
> - }
>   /* Now copy the attribute list. */
>   memcpy(ni->attr_list, (u8*)a + le16_to_cpu(
>   a->data.resident.value_offset),
> -- 
> 2.30.0
> 


-- 
Anton Altaparmakov  (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer

Re: [PATCH] PCI: hotplug: Remove unused function pointer typedef acpiphp_callback

[Krzysztof Wilczyński]

Hi Chen,

> Remove the 'acpiphp_callback' typedef as it is not used.
[...]

Good catch!

This typedef was initially added in 2005, and then it stopped being used
around the Kernel version 3.7 release, which is also when the sole user
of this typedef called acpiphp_for_each_slot() has also been retired.

Reviewed-by: Krzysztof Wilczyński 

Krzysztof

Re: [PATCH v2 1/1] arm64: mm: correct the inside linear map boundaries during hotplug check

[Anshuman Khandual]

On 2/16/21 12:57 AM, Ard Biesheuvel wrote:
> On Mon, 15 Feb 2021 at 20:22, Pavel Tatashin  
> wrote:
>>
>> Memory hotplug may fail on systems with CONFIG_RANDOMIZE_BASE because the
>> linear map range is not checked correctly.
>>
>> The start physical address that linear map covers can be actually at the
>> end of the range because of randomization. Check that and if so reduce it
>> to 0.
>>
>> This can be verified on QEMU with setting kaslr-seed to ~0ul:
>>
>> memstart_offset_seed = 0x
>> START: __pa(_PAGE_OFFSET(vabits_actual)) = 9000c000
>> END:   __pa(PAGE_END - 1) =  1000bfff
>>
>> Signed-off-by: Pavel Tatashin 
>> Fixes: 58284a901b42 ("arm64/mm: Validate hotplug range before creating 
>> linear mapping")
>> Tested-by: Tyler Hicks 
> 
>> ---
>>  arch/arm64/mm/mmu.c | 20 ++--
>>  1 file changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index ae0c3d023824..cc16443ea67f 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -1444,14 +1444,30 @@ static void __remove_pgd_mapping(pgd_t *pgdir, 
>> unsigned long start, u64 size)
>>
>>  static bool inside_linear_region(u64 start, u64 size)
>>  {
>> +   u64 start_linear_pa = __pa(_PAGE_OFFSET(vabits_actual));
>> +   u64 end_linear_pa = __pa(PAGE_END - 1);
>> +
>> +   if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
>> +   /*
>> +* Check for a wrap, it is possible because of randomized 
>> linear
>> +* mapping the start physical address is actually bigger than
>> +* the end physical address. In this case set start to zero
>> +* because [0, end_linear_pa] range must still be able to 
>> cover
>> +* all addressable physical addresses.
>> +*/
>> +   if (start_linear_pa > end_linear_pa)
>> +   start_linear_pa = 0;
>> +   }
>> +
>> +   WARN_ON(start_linear_pa > end_linear_pa);
>> +
>> /*
>>  * Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
>>  * accommodating both its ends but excluding PAGE_END. Max physical
>>  * range which can be mapped inside this linear mapping range, must
>>  * also be derived from its end points.
>>  */
>> -   return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
>> -  (start + size - 1) <= __pa(PAGE_END - 1);
> 
> Can't we simply use signed arithmetic here? This expression works fine
> if the quantities are all interpreted as s64 instead of u64

There is a new generic framework which expects the platform to provide two
distinct range points (low and high) for hotplug address comparison. Those
range points can be different depending on whether address randomization
is enabled and the flip occurs. But this comparison here in the platform
code is going away.

This patch needs to rebased on the new framework which is part of linux-next.

https://patchwork.kernel.org/project/linux-mm/list/?series=425051

[PATCH] PCI: hotplug: Remove unused function pointer typedef acpiphp_callback

[Chen Lin]

From: Chen Lin 

Remove the 'acpiphp_callback' typedef as it is not used.

Signed-off-by: Chen Lin 
---
 drivers/pci/hotplug/acpiphp.h |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/pci/hotplug/acpiphp.h b/drivers/pci/hotplug/acpiphp.h
index a2094c0..a74b274 100644
--- a/drivers/pci/hotplug/acpiphp.h
+++ b/drivers/pci/hotplug/acpiphp.h
@@ -176,9 +176,6 @@ struct acpiphp_attention_info
 int acpiphp_register_hotplug_slot(struct acpiphp_slot *slot, unsigned int sun);
 void acpiphp_unregister_hotplug_slot(struct acpiphp_slot *slot);
 
-/* acpiphp_glue.c */
-typedef int (*acpiphp_callback)(struct acpiphp_slot *slot, void *data);
-
 int acpiphp_enable_slot(struct acpiphp_slot *slot);
 int acpiphp_disable_slot(struct acpiphp_slot *slot);
 u8 acpiphp_get_power_status(struct acpiphp_slot *slot);
-- 
1.7.9.5

RE: linux-next: manual merge of the net-next tree with the arm-soc tree

[nobuhiro1.iwamatsu]

Hi,

> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Tuesday, February 16, 2021 11:05 AM
> To: David Miller ; Networking ; 
> Olof Johansson ; Arnd
> Bergmann ; ARM 
> Cc: Bartosz Golaszewski ; Linux Kernel Mailing 
> List ; Linux
> Next Mailing List ; iwamatsu nobuhiro(岩松 信洋 
> □ＳＷＣ◯ＡＣＴ)
> 
> Subject: linux-next: manual merge of the net-next tree with the arm-soc tree
> 
> Hi all,
> 
> Today's linux-next merge of the net-next tree got conflicts in:
> 
>   arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
>   arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
> 
> between commits:
> 
>   4fd18fc38757 ("arm64: dts: visconti: Add watchdog support for TMPV7708 SoC")
>   0109a17564fc ("arm: dts: visconti: Add DT support for Toshiba Visconti5 
> GPIO driver")
> 
> from the arm-soc tree and commit:
> 
>   ec8a42e73432 ("arm: dts: visconti: Add DT support for Toshiba Visconti5 
> ethernet controller")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

This is because the DTS changes are included in net-next. This patch should be 
merged via the soc tree.
I had the same problem before. How is it correct to send a DTS patch?
Should I separate into different series?

Best regards,
  Nobuhiro

[PATCH v5 1/2] bio: limit bio max size

[Changheun Lee]

Please feedback to me if more modification is needed to apply. :)

---
Changheun Lee

Re: [PATCH v8 21/22] counter: 104-quad-8: Replace mutex with spinlock

[William Breathitt Gray]

On Sun, Feb 14, 2021 at 06:19:46PM +, Jonathan Cameron wrote:
> On Fri, 12 Feb 2021 21:13:45 +0900
> William Breathitt Gray  wrote:
> 
> > This patch replaces the mutex I/O lock with a spinlock. This is in
> > preparation for a subsequent patch adding IRQ support for 104-QUAD-8
> > devices; we can't sleep in an interrupt context, so we'll need to use a
> > spinlock instead.
> > 
> > Cc: Syed Nayyar Waris 
> > Signed-off-by: William Breathitt Gray 
> 
> Why do these need to be raw_spin_locks?
> Normally only need to do that if in code related to interrupt chips etc,
> not their use.
> 
> Jonathan

This lock can be taken in an interrupt context in a subsequent patch:
counter_push_event() called by quad8_irq_handler() can end up calling
the Counter component callbacks which take this lock. We can't use a
mutex nor a regular spinlock because those can sleep on RT setups [1]
which would result in a deadlock due to the interrupt context here -- so
therefore we're left with using raw_spin_lock.

[1] https://lwn.net/Articles/367219/

William Breathitt Gray


signature.asc
Description: PGP signature

Re: [PATCH 00/33] Network fs helper library & fscache kiocb API [ver #3]

[Matthew Wilcox]

On Mon, Feb 15, 2021 at 06:40:27PM -0600, Steve French wrote:
> It could be good if netfs simplifies the problem experienced by
> network filesystems on Linux with readahead on large sequential reads
> - where we don't get as much parallelism due to only having one
> readahead request at a time (thus in many cases there is 'dead time'
> on either the network or the file server while waiting for the next
> readpages request to be issued).   This can be a significant
> performance problem for current readpages when network latency is long
> (or e.g. in cases when network encryption is enabled, and hardware
> offload not available so time consuming on the server or client to
> encrypt the packet).
> 
> Do you see netfs much faster than currentreadpages for ceph?
> 
> Have you been able to get much benefit from throttling readahead with
> ceph from the current netfs approach for clamping i/o?

The switch from readpages to readahead does help in a couple of corner
cases.  For example, if you have two processes reading the same file at
the same time, one will now block on the other (due to the page lock)
rather than submitting a mess of overlapping and partial reads.

We're not there yet on having multiple outstanding reads.  Bill and I
had a chat recently about how to make the readahead code detect that
it is in a "long fat pipe" situation (as opposed to just dealing with
a slow device), and submit extra readahead requests to make best use of
the bandwidth and minimise blocking of the application.

That's not something for the netfs code to do though; we can get into
that situation with highly parallel SSDs.

linux-next: manual merge of the net-next tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got conflicts in:

  arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
  arch/arm64/boot/dts/toshiba/tmpv7708.dtsi

between commits:

  4fd18fc38757 ("arm64: dts: visconti: Add watchdog support for TMPV7708 SoC")
  0109a17564fc ("arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO 
driver")

from the arm-soc tree and commit:

  ec8a42e73432 ("arm: dts: visconti: Add DT support for Toshiba Visconti5 
ethernet controller")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
index 2407b2d89c1e,48fa8776e36f..
--- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
+++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
@@@ -42,11 -42,20 +42,29 @@@
clock-names = "apb_pclk";
  };
  
 + {
 +  status = "okay";
 +  clocks = <_clk>;
 +};
 +
 + {
 +  status = "okay";
++};`
++
+  {
+   status = "okay";
+   phy-handle = <>;
+   phy-mode = "rgmii-id";
+   clocks = <>, <>;
+   clock-names = "stmmaceth", "phy_ref_clk";
+ 
+   mdio0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "snps,dwmac-mdio";
+   phy0: ethernet-phy@1 {
+   device_type = "ethernet-phy";
+   reg = <0x1>;
+   };
+   };
  };
diff --cc arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
index 4264f3e6ac9c,3366786699fc..
--- a/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
+++ b/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
@@@ -134,12 -134,20 +134,26 @@@
#clock-cells = <0>;
};
  
 +  wdt_clk: wdt-clk {
 +  compatible = "fixed-clock";
 +  clock-frequency = <15000>;
 +  #clock-cells = <0>;
 +  };
 +
+   clk125mhz: clk125mhz {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   #clock-cells = <0>;
+   clock-output-names = "clk125mhz";
+   };
+ 
+   clk300mhz: clk300mhz {
+   compatible = "fixed-clock";
+   clock-frequency = <3>;
+   #clock-cells = <0>;
+   clock-output-names = "clk300mhz";
+   };
+ 
soc {
#address-cells = <2>;
#size-cells = <2>;
@@@ -402,11 -399,16 +416,22 @@@
status = "disabled";
};
  
 +  wdt: wdt@2833 {
 +  compatible = "toshiba,visconti-wdt";
 +  reg = <0 0x2833 0 0x1000>;
 +  status = "disabled";
 +  };
++
+   piether: ethernet@2800 {
+   compatible = "toshiba,visconti-dwmac", 
"snps,dwmac-4.20a";
+   reg = <0 0x2800 0 0x1>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   snps,txpbl = <4>;
+   snps,rxpbl = <4>;
+   snps,tso;
+   status = "disabled";
+   };
};
  };
  


pgpm0sBGsiF1m.pgp
Description: OpenPGP digital signature

[PATCH 1/2] scripts: add generic syscalltbl.sh

[Masahiro Yamada]

Most of architectures generate syscall headers at the compile time
in a similar way.

The syscall table has the same format for all architectures. Each line
has up to 5 fields; syscall number, ABI, syscall name, native entry
point, and compat entry point. The syscall table is processed by
syscalltbl.sh script into header files.

Despite the same pattern, scripts are maintained per architecture,
which results in code duplication and bad maintainability.

As of v5.11-rc1, 12 architectures duplicate similar shell scripts:

  $ find arch -name syscalltbl.sh | sort
  arch/alpha/kernel/syscalls/syscalltbl.sh
  arch/arm/tools/syscalltbl.sh
  arch/ia64/kernel/syscalls/syscalltbl.sh
  arch/m68k/kernel/syscalls/syscalltbl.sh
  arch/microblaze/kernel/syscalls/syscalltbl.sh
  arch/mips/kernel/syscalls/syscalltbl.sh
  arch/parisc/kernel/syscalls/syscalltbl.sh
  arch/powerpc/kernel/syscalls/syscalltbl.sh
  arch/sh/kernel/syscalls/syscalltbl.sh
  arch/sparc/kernel/syscalls/syscalltbl.sh
  arch/x86/entry/syscalls/syscalltbl.sh
  arch/xtensa/kernel/syscalls/syscalltbl.sh

My goal is to unify them into scripts/syscalltbl.sh.

__SYSCALL_WITH_COMPAT should be defined as follows:

32-bit kernel:
  #define __SYSCALL_WITH_COMPAT(nr, native, compat) __SYSCALL(nr, native)

64-bit kernel:

  #define __SYSCALL_WITH_COMPAT(nr, native, compat) __SYSCALL(nr, compat)

Signed-off-by: Masahiro Yamada 
---

 scripts/syscalltbl.sh | 73 +++
 1 file changed, 73 insertions(+)
 create mode 100755 scripts/syscalltbl.sh

diff --git a/scripts/syscalltbl.sh b/scripts/syscalltbl.sh
new file mode 100755
index ..aa6ab156301c
--- /dev/null
+++ b/scripts/syscalltbl.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Generate a syscall table header.
+#
+# Each line of the syscall table should have the following format:
+#
+# NR ABI NAME [NATIVE] [COMPAT]
+#
+# NR   syscall number
+# ABI  ABI name
+# NAME syscall name
+# NATIVE   native entry point (optional)
+# COMPAT   compat entry point (optional)
+
+set -e
+
+usage() {
+   echo >&2 "usage: $0 [--abis ABIS] INFILE OUTFILE" >&2
+   echo >&2
+   echo >&2 "  INFILEinput syscall table"
+   echo >&2 "  OUTFILE   output header file"
+   echo >&2
+   echo >&2 "options:"
+   echo >&2 "  --abis ABISABI(s) to handle (By default, all lines 
are handled)"
+   exit 1
+}
+
+# default unless specified by options
+abis=
+
+while [ $# -gt 0 ]
+do
+   case $1 in
+   --abis)
+   abis=$(echo "($2)" | tr ',' '|')
+   shift 2;;
+   -*)
+   echo "$1: unknown option" >&2
+   usage;;
+   *)
+   break;;
+   esac
+done
+
+if [ $# -ne 2 ]; then
+   usage
+fi
+
+infile="$1"
+outfile="$2"
+
+nxt=0
+
+grep -E "^[0-9]+[[:space:]]+$abis" "$infile" | sort -n | {
+
+   while read nr abi name native compat ; do
+
+   while [ $nxt -lt $nr ]; do
+   echo "__SYSCALL($nxt, sys_ni_syscall)"
+   nxt=$((nxt + 1))
+   done
+
+   if [ -n "$compat" ]; then
+   echo "__SYSCALL_WITH_COMPAT($nr, $native, $compat)"
+   elif [ -n "$native" ]; then
+   echo "__SYSCALL($nr, $native)"
+   else
+   echo "__SYSCALL($nr, sys_ni_syscall)"
+   fi
+   nxt=$((nr + 1))
+   done
+} > "$outfile"
-- 
2.27.0

[PATCH 2/2] scripts: add generic syscallhdr.sh

[Masahiro Yamada]

Most of architectures generate syscall headers at the compile time
in a similar way.

As of v5.11-rc1, 12 architectures duplicate similar shell scripts:

  $ find arch -name syscallhdr.sh | sort
  arch/alpha/kernel/syscalls/syscallhdr.sh
  arch/arm/tools/syscallhdr.sh
  arch/ia64/kernel/syscalls/syscallhdr.sh
  arch/m68k/kernel/syscalls/syscallhdr.sh
  arch/microblaze/kernel/syscalls/syscallhdr.sh
  arch/mips/kernel/syscalls/syscallhdr.sh
  arch/parisc/kernel/syscalls/syscallhdr.sh
  arch/powerpc/kernel/syscalls/syscallhdr.sh
  arch/sh/kernel/syscalls/syscallhdr.sh
  arch/sparc/kernel/syscalls/syscallhdr.sh
  arch/x86/entry/syscalls/syscallhdr.sh
  arch/xtensa/kernel/syscalls/syscallhdr.sh

My goal is to unify them into scripts/syscallhdr.sh.

Signed-off-by: Masahiro Yamada 
---

 scripts/syscallhdr.sh | 98 +++
 1 file changed, 98 insertions(+)
 create mode 100755 scripts/syscallhdr.sh

diff --git a/scripts/syscallhdr.sh b/scripts/syscallhdr.sh
new file mode 100755
index ..848ac2735115
--- /dev/null
+++ b/scripts/syscallhdr.sh
@@ -0,0 +1,98 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Generate a syscall number header.
+#
+# Each line of the syscall table should have the following format:
+#
+# NR ABI NAME [NATIVE] [COMPAT]
+#
+# NR   syscall number
+# ABI  ABI name
+# NAME syscall name
+# NATIVE   native entry point (optional)
+# COMPAT   compat entry point (optional)
+
+set -e
+
+usage() {
+   echo >&2 "usage: $0 [--abis ABIS] [--emit-nr] [--offset OFFSET] 
[--prefix PREFIX] INFILE OUTFILE" >&2
+   echo >&2
+   echo >&2 "  INFILEinput syscall table"
+   echo >&2 "  OUTFILE   output header file"
+   echo >&2
+   echo >&2 "options:"
+   echo >&2 "  --abis ABISABI(s) to handle (By default, all lines 
are handled)"
+   echo >&2 "  --emit-nr  Emit the macro of the number of syscalls 
(__NR_syscalls)"
+   echo >&2 "  --offset OFFSETThe offset of syscall numbers"
+   echo >&2 "  --prefix PREFIXThe prefix to the macro like 
__NR_"
+   exit 1
+}
+
+# default unless specified by options
+abis=
+emit_nr=
+offset=
+prefix=
+
+while [ $# -gt 0 ]
+do
+   case $1 in
+   --abis)
+   abis=$(echo "($2)" | tr ',' '|')
+   shift 2;;
+   --emit-nr)
+   emit_nr=1
+   shift 1;;
+   --offset)
+   offset=$2
+   shift 2;;
+   --prefix)
+   prefix=$2
+   shift 2;;
+   -*)
+   echo "$1: unknown option" >&2
+   usage;;
+   *)
+   break;;
+   esac
+done
+
+if [ $# -ne 2 ]; then
+   usage
+fi
+
+infile="$1"
+outfile="$2"
+
+guard=_UAPI_ASM_$(basename "$outfile" |
+   sed -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \
+   -e 's/[^A-Z0-9_]/_/g' -e 's/__/_/g')
+
+grep -E "^[0-9A-Fa-fXx]+[[:space:]]+$abis" "$infile" | sort -n | {
+   echo "#ifndef $guard"
+   echo "#define $guard"
+   echo
+
+   max=0
+   while read nr abi name native compat ; do
+
+   max=$nr
+
+   if [ -n "$offset" ]; then
+   nr="($offset + $nr)"
+   fi
+
+   echo "#define __NR_$prefix$name $nr"
+   done
+
+   if [ -n "$emit_nr" ]; then
+   echo
+   echo "#ifdef __KERNEL__"
+   echo "#define __NR_${prefix}syscalls $(($max + 1))"
+   echo "#endif"
+   fi
+
+   echo
+   echo "#endif /* $guard */"
+} > "$outfile"
-- 
2.27.0

Re: [PATCH] ftrace: Do not reference symbols in sections without size

[Steven Rostedt]

On Mon, 15 Feb 2021 20:06:39 -0500
Steven Rostedt  wrote:

> Strange, that when I applied this to the latest kernel on a my build
> system (binutils 2.35), it still created all the necessary mcount
> locations??

I know why it worked. If you are using the latest gcc on the latest
mainline, it will not even bother with recordmcount, and will just
create the __mcount_loc sections, as latest gcc knows about ftrace.

(this is what I get for working on a company holiday)

Since this is a toolchain issue, perhaps the correct thing to do is to
backport to stable the changes to have it build with -mrecord-mcount if
the build system enables it.

If you are using the lastest compilers to build stable releases, and
that's causing issues, then you should have the stable releases use the
latest kernel compiler options.

Greg,

Can you test the following two backports. It does change the semantics
of what is built, but then again if you are using a newer compiler to
build stable kernels, that can change things too.

96f60dfa5819a ("trace: Use -mcount-record for dynamic ftrace")
07d0408120216 ("tracing: Avoid calling cc-option -mrecord-mcount for every 
Makefile")

I attached the backports to 4.4. (just compiled tested, I'll test them more 
tomorrow)

Thanks!

-- Steve
>From f9a03bb58aa222824b3041efbf62488af693feaa Mon Sep 17 00:00:00 2001
From: Andi Kleen 
Date: Mon, 27 Nov 2017 13:34:13 -0800
Subject: [PATCH 1/2] trace: Use -mcount-record for dynamic ftrace

gcc 5 supports a new -mcount-record option to generate ftrace
tables directly. This avoids the need to run record_mcount
manually.

Use this option when available.

So far doesn't use -mcount-nop, which also exists now.

This is needed to make ftrace work with LTO because the
normal record-mcount script doesn't run over the link
time output.

It should also improve build times slightly in the general
case.
Link: http://lkml.kernel.org/r/20171127213423.27218-12-a...@firstfloor.org

Signed-off-by: Andi Kleen 
Signed-off-by: Steven Rostedt (VMware) 
---
 scripts/Makefile.build | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 42aef001dfdd..fff1452cb76e 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -221,6 +221,11 @@ cmd_modversions_c =\
 endif
 
 ifdef CONFIG_FTRACE_MCOUNT_RECORD
+# gcc 5 supports generating the mcount tables directly
+ifneq ($(call cc-option,-mrecord-mcount,y),y)
+KBUILD_CFLAGS += -mrecord-mcount
+else
+# else do it all manually
 ifdef BUILD_C_RECORDMCOUNT
 ifeq ("$(origin RECORDMCOUNT_WARN)", "command line")
   RECORDMCOUNT_FLAGS = -w
@@ -250,6 +255,7 @@ cmd_record_mcount =		\
 		$(sub_cmd_record_mcount)			\
 	fi;
 endif
+endif
 
 define rule_cc_o_c
 	$(call echo-cmd,checksrc) $(cmd_checksrc)			  \
-- 
2.30.1

>From 76a3bbb0b0b193ac4dcd3c005cc6abcaddaadfe6 Mon Sep 17 00:00:00 2001
From: Vasily Gorbik 
Date: Mon, 6 Aug 2018 15:17:44 +0200
Subject: [PATCH 2/2] tracing: Avoid calling cc-option -mrecord-mcount for
 every Makefile

Currently if CONFIG_FTRACE_MCOUNT_RECORD is enabled -mrecord-mcount
compiler flag support is tested for every Makefile.

Top 4 cc-option usages:
511 -mrecord-mcount
 11  -fno-stack-protector
  9 -Wno-override-init
  2 -fsched-pressure

To address that move cc-option from scripts/Makefile.build to top Makefile
and export CC_USING_RECORD_MCOUNT to be used in original place.

While doing that also add -mrecord-mcount to CC_FLAGS_FTRACE (if gcc
actually supports it).

Link: http://lkml.kernel.org/r/patch-2.thread-aa7b8d.git-de935bace15a.your-ad-here.call-01533557518-ext-9465@work.hours

Acked-by: Andi Kleen 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Steven Rostedt (VMware) 
---
 Makefile   | 7 +++
 scripts/Makefile.build | 7 ++-
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index 0057587d2cbe..9f2123555429 100644
--- a/Makefile
+++ b/Makefile
@@ -760,6 +760,13 @@ ifdef CONFIG_FUNCTION_TRACER
 ifndef CC_FLAGS_FTRACE
 CC_FLAGS_FTRACE := -pg
 endif
+ifdef CONFIG_FTRACE_MCOUNT_RECORD
+  # gcc 5 supports generating the mcount tables directly
+  ifeq ($(call cc-option-yn,-mrecord-mcount),y)
+CC_FLAGS_FTRACE	+= -mrecord-mcount
+export CC_USING_RECORD_MCOUNT := 1
+  endif
+endif
 export CC_FLAGS_FTRACE
 ifdef CONFIG_HAVE_FENTRY
 CC_USING_FENTRY	:= $(call cc-option, -mfentry -DCC_USING_FENTRY)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index fff1452cb76e..673ab54c0af6 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -221,11 +221,8 @@ cmd_modversions_c =\
 endif
 
 ifdef CONFIG_FTRACE_MCOUNT_RECORD
-# gcc 5 supports generating the mcount tables directly
-ifneq ($(call cc-option,-mrecord-mcount,y),y)
-KBUILD_CFLAGS += -mrecord-mcount
-else
-# else do it all manually
+ifndef CC_USING_RECORD_MCOUNT
+# compiler will not generate __mcount_loc use recordmcount or recordmcount.pl
 ifdef BUILD_C_RECORDMCOUNT
 ifeq ("$(origin 

Re: [PATCH v8 17/22] counter: Add character device interface

[William Breathitt Gray]

On Mon, Feb 15, 2021 at 10:24:12AM +0100, Oleksij Rempel wrote:
> Hi William,
> 
> On Fri, Feb 12, 2021 at 09:13:41PM +0900, William Breathitt Gray wrote:
> > This patch introduces a character device interface for the Counter
> > subsystem. Device data is exposed through standard character device read
> > operations. Device data is gathered when a Counter event is pushed by
> > the respective Counter device driver. Configuration is handled via ioctl
> > operations on the respective Counter character device node.
> 
> .
> 
> > +/**
> > + * counter_push_event - queue event for userspace reading
> > + * @counter:   pointer to Counter structure
> > + * @event: triggered event
> > + * @channel:   event channel
> > + *
> > + * Note: If no one is watching for the respective event, it is silently
> > + * discarded.
> > + */
> > +void counter_push_event(struct counter_device *const counter, const u8 
> > event,
> > +   const u8 channel)
> > +{
> > +   struct counter_event ev = {0};
> > +   unsigned int copied = 0;
> > +   unsigned long flags;
> > +   struct counter_event_node *event_node;
> > +   struct counter_comp_node *comp_node;
> > +
> > +   ev.timestamp = ktime_get_ns();
> > +   ev.watch.event = event;
> > +   ev.watch.channel = channel;
> > +
> > +   /* Could be in an interrupt context, so use a raw spin lock */
> > +   raw_spin_lock_irqsave(>events_list_lock, flags);
> > +
> > +   /* Search for event in the list */
> > +   list_for_each_entry(event_node, >events_list, l)
> > +   if (event_node->event == event &&
> > +   event_node->channel == channel)
> > +   break;
> > +
> > +   /* If event is not in the list */
> > +   if (_node->l == >events_list)
> > +   goto exit_early;
> 
> To cover my "interrupt-counter" use case, I added following line here to
> convert the tail drop fifo to the head drop fifo:
> 
> +   list_for_each_entry(comp_node, _node->comp_list, l)
> +   to_copy += sizeof(ev);
> +
> +   while (kfifo_avail(>events) < to_copy)
> +   kfifo_skip(>events);
> 
> May be it make sense to make it optional and integrate in to you patches
> before it goes mainline?
> 
> Regards,
> Oleksij
> -- 
> Pengutronix e.K.   | |
> Steuerwalder Str. 21   | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Hello Oleksij,

I appreciate your suggestion, and I'm excited about your
interrupt-counter driver -- it looks like the Counter character device
interface will be central for that driver. However, I want to hold off
on adding further functionality to this patchset so that we can stablize
it enough to merge.

Once the Counter character device interface is merged, please send your
changes again as a patch and we can review it further then.

Thank you,

William Breathitt Gray


signature.asc
Description: PGP signature

Re: [RFT][PATCH v1] cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known

[Michael Larabel]

On 2/15/21 1:24 PM, Rafael J. Wysocki wrote:

From: Rafael J. Wysocki 

Commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover
boost frequencies") attempted to address a performance issue involving
acpi-cpufreq, the schedutil governor and scale-invariance on x86 by
extending the frequency tables created by acpi-cpufreq to cover the
entire range of "turbo" (or "boost") frequencies, but that caused
frequencies reported via /proc/cpuinfo and the scaling_cur_freq
attribute in sysfs to change which may confuse users and monitoring
tools.

For this reason, revert the part of commit 3c55e94c0ade adding the
extra entry to the frequency table and use the observation that
in principle cpuinfo.max_freq need not be equal to the maximum
frequency listed in the frequency table for the given policy.

Namely, modify cpufreq_frequency_table_cpuinfo() to allow cpufreq
drivers to set their own cpuinfo.max_freq above that frequency and
change  acpi-cpufreq to set cpuinfo.max_freq to the maximum boost
frequency found via CPPC.

This should be sufficient to let all of the cpufreq subsystem know
the real maximum frequency of the CPU without changing frequency
reporting.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=211305
Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost 
frequencies")
Reported-by: Matt McDonald 
Signed-off-by: Rafael J. Wysocki 
---

Michael, Giovanni,

The fix for the EPYC performance regression that was merged into 5.11 introduced
an undesirable side-effect by distorting the CPU frequency reporting via
/proc/cpuinfo and scaling_cur_freq (see the BZ link above for details).

The patch below is reported to address this problem and it should still allow
schedutil to achieve desirable performance, because it simply sets
cpuinfo.max_freq without extending the frequency table of the CPU.

Please test this one and let me know if it adversely affects performance.

Thanks!



When carrying out tests so far today on an EPYC 7F72 2P and Ryzen 9 
5900X with workloads seeing impact from the prior patches, everything is 
looking good when comparing v5.11 to v5.11 + this patch. Not seeing any 
measurable difference on either of those systems as a result of this patch.


Running some additional tests and on a few more boxes that should wrap 
up tomorrow but at least so far the patch isn't showing any measurable 
changes to performance.


Michael




---
  drivers/cpufreq/acpi-cpufreq.c |   62 
++---
  drivers/cpufreq/freq_table.c   |8 -
  2 files changed, 23 insertions(+), 47 deletions(-)

Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
@@ -54,7 +54,6 @@ struct acpi_cpufreq_data {
unsigned int resume;
unsigned int cpu_feature;
unsigned int acpi_perf_cpu;
-   unsigned int first_perf_state;
cpumask_var_t freqdomain_cpus;
void (*cpu_freq_write)(struct acpi_pct_register *reg, u32 val);
u32 (*cpu_freq_read)(struct acpi_pct_register *reg);
@@ -223,10 +222,10 @@ static unsigned extract_msr(struct cpufr
  
  	perf = to_perf_data(data);
  
-	cpufreq_for_each_entry(pos, policy->freq_table + data->first_perf_state)

+   cpufreq_for_each_entry(pos, policy->freq_table)
if (msr == perf->states[pos->driver_data].status)
return pos->frequency;
-   return policy->freq_table[data->first_perf_state].frequency;
+   return policy->freq_table[0].frequency;
  }
  
  static unsigned extract_freq(struct cpufreq_policy *policy, u32 val)

@@ -365,7 +364,6 @@ static unsigned int get_cur_freq_on_cpu(
struct cpufreq_policy *policy;
unsigned int freq;
unsigned int cached_freq;
-   unsigned int state;
  
  	pr_debug("%s (%d)\n", __func__, cpu);
  
@@ -377,11 +375,7 @@ static unsigned int get_cur_freq_on_cpu(

if (unlikely(!data || !policy->freq_table))
return 0;
  
-	state = to_perf_data(data)->state;

-   if (state < data->first_perf_state)
-   state = data->first_perf_state;
-
-   cached_freq = policy->freq_table[state].frequency;
+   cached_freq = policy->freq_table[to_perf_data(data)->state].frequency;
freq = extract_freq(policy, get_cur_val(cpumask_of(cpu), data));
if (freq != cached_freq) {
/*
@@ -680,7 +674,6 @@ static int acpi_cpufreq_cpu_init(struct
struct cpuinfo_x86 *c = _data(cpu);
unsigned int valid_states = 0;
unsigned int result = 0;
-   unsigned int state_count;
u64 max_boost_ratio;
unsigned int i;
  #ifdef CONFIG_SMP
@@ -795,28 +788,8 @@ static int acpi_cpufreq_cpu_init(struct
goto err_unreg;
}
  
-	state_count = perf->state_count + 1;

-
-   max_boost_ratio = get_max_boost_ratio(cpu);
-   if 

[PATCH v4 7/9] cxl/mem: Add set of informational commands

[Ben Widawsky]

Add initial set of formal commands beyond basic identify and command
enumeration.

Signed-off-by: Ben Widawsky 
Reviewed-by: Dan Williams 
Reviewed-by: Jonathan Cameron  (v2)
---
 drivers/cxl/mem.c| 9 +
 include/uapi/linux/cxl_mem.h | 5 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 4d921b4375f9..dc608bb20a31 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -45,12 +45,16 @@
 enum opcode {
CXL_MBOX_OP_INVALID = 0x,
CXL_MBOX_OP_RAW = CXL_MBOX_OP_INVALID,
+   CXL_MBOX_OP_GET_FW_INFO = 0x0200,
CXL_MBOX_OP_ACTIVATE_FW = 0x0202,
CXL_MBOX_OP_GET_SUPPORTED_LOGS  = 0x0400,
CXL_MBOX_OP_GET_LOG = 0x0401,
CXL_MBOX_OP_IDENTIFY= 0x4000,
+   CXL_MBOX_OP_GET_PARTITION_INFO  = 0x4100,
CXL_MBOX_OP_SET_PARTITION_INFO  = 0x4101,
+   CXL_MBOX_OP_GET_LSA = 0x4102,
CXL_MBOX_OP_SET_LSA = 0x4103,
+   CXL_MBOX_OP_GET_HEALTH_INFO = 0x4200,
CXL_MBOX_OP_SET_SHUTDOWN_STATE  = 0x4204,
CXL_MBOX_OP_SCAN_MEDIA  = 0x4304,
CXL_MBOX_OP_GET_SCAN_MEDIA  = 0x4305,
@@ -167,6 +171,11 @@ static struct cxl_mem_command mem_commands[] = {
CXL_CMD(RAW, ~0, ~0, 0),
 #endif
CXL_CMD(GET_SUPPORTED_LOGS, 0, ~0, CXL_CMD_FLAG_FORCE_ENABLE),
+   CXL_CMD(GET_FW_INFO, 0, 0x50, 0),
+   CXL_CMD(GET_PARTITION_INFO, 0, 0x20, 0),
+   CXL_CMD(GET_LSA, 0x8, ~0, 0),
+   CXL_CMD(GET_HEALTH_INFO, 0, 0x12, 0),
+   CXL_CMD(GET_LOG, 0x18, ~0, CXL_CMD_FLAG_FORCE_ENABLE),
 };
 
 /*
diff --git a/include/uapi/linux/cxl_mem.h b/include/uapi/linux/cxl_mem.h
index 3b5bf4b58fb4..7670fe0e605a 100644
--- a/include/uapi/linux/cxl_mem.h
+++ b/include/uapi/linux/cxl_mem.h
@@ -24,6 +24,11 @@
___C(IDENTIFY, "Identify Command"),   \
___C(RAW, "Raw device command"),  \
___C(GET_SUPPORTED_LOGS, "Get Supported Logs"),   \
+   ___C(GET_FW_INFO, "Get FW Info"), \
+   ___C(GET_PARTITION_INFO, "Get Partition Information"),\
+   ___C(GET_LSA, "Get Label Storage Area"),  \
+   ___C(GET_HEALTH_INFO, "Get Health Info"), \
+   ___C(GET_LOG, "Get Log"), \
___C(MAX, "invalid / last command")
 
 #define ___C(a, b) CXL_MEM_COMMAND_ID_##a
-- 
2.30.1

[PATCH v4 6/9] cxl/mem: Enable commands via CEL

[Ben Widawsky]

CXL devices identified by the memory-device class code must implement
the Device Command Interface (described in 8.2.9 of the CXL 2.0 spec).
While the driver already maintains a list of commands it supports, there
is still a need to be able to distinguish between commands that the
driver knows about from commands that are optionally supported by the
hardware.

The Command Effects Log (CEL) is specified in the CXL 2.0 specification.
The CEL is one of two types of logs, the other being vendor specific.
They are distinguished in hardware/spec via UUID. The CEL is useful for
2 things:
1. Determine which optional commands are supported by the CXL device.
2. Enumerate any vendor specific commands

The CEL is used by the driver to determine which commands are available
in the hardware and therefore which commands userspace is allowed to
execute. The set of enabled commands might be a subset of commands which
are advertised in UAPI via CXL_MEM_SEND_COMMAND IOCTL.

With the CEL enabling comes a internal flag to indicate a base set of
commands that are enabled regardless of CEL. Such commands are required
for basic interaction with the hardware and thus can be useful in debug
cases, for example if the CEL is corrupted.

The implementation leaves the statically defined table of commands and
supplements it with a bitmap to determine commands that are enabled.
This organization was chosen for the following reasons:
- Smaller memory footprint. Doesn't need a table per device.
- Reduce memory allocation complexity.
- Fixed command IDs to opcode mapping for all devices makes development
  and debugging easier.
- Certain helpers are easily achievable, like cxl_for_each_cmd().

Signed-off-by: Ben Widawsky 
Reviewed-by: Dan Williams 
---
 drivers/cxl/cxl.h|   2 +
 drivers/cxl/mem.c| 213 ++-
 include/uapi/linux/cxl_mem.h |   1 +
 3 files changed, 213 insertions(+), 3 deletions(-)

diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index f69313dc3b4e..cb7a77ed443d 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -67,6 +67,7 @@ struct cxl_memdev;
  *(CXL 2.0 8.2.8.4.3 Mailbox Capabilities Register)
  * @mbox_mutex: Mutex to synchronize mailbox access.
  * @firmware_version: Firmware version for the memory device.
+ * @enabled_commands: Hardware commands found enabled in CEL.
  * @pmem: Persistent memory capacity information.
  * @ram: Volatile memory capacity information.
  */
@@ -82,6 +83,7 @@ struct cxl_mem {
size_t payload_size;
struct mutex mbox_mutex; /* Protects device mailbox and firmware */
char firmware_version[0x10];
+   unsigned long *enabled_cmds;
 
struct range pmem_range;
struct range ram_range;
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 6b4feb0ce47d..4d921b4375f9 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -46,6 +46,8 @@ enum opcode {
CXL_MBOX_OP_INVALID = 0x,
CXL_MBOX_OP_RAW = CXL_MBOX_OP_INVALID,
CXL_MBOX_OP_ACTIVATE_FW = 0x0202,
+   CXL_MBOX_OP_GET_SUPPORTED_LOGS  = 0x0400,
+   CXL_MBOX_OP_GET_LOG = 0x0401,
CXL_MBOX_OP_IDENTIFY= 0x4000,
CXL_MBOX_OP_SET_PARTITION_INFO  = 0x4101,
CXL_MBOX_OP_SET_LSA = 0x4103,
@@ -104,10 +106,28 @@ static DEFINE_IDA(cxl_memdev_ida);
 static struct dentry *cxl_debugfs;
 static bool cxl_raw_allow_all;
 
+enum {
+   CEL_UUID,
+   VENDOR_DEBUG_UUID,
+};
+
+/* See CXL 2.0 Table 170. Get Log Input Payload */
+static const uuid_t log_uuid[] = {
+   [CEL_UUID] = UUID_INIT(0xda9c0b5, 0xbf41, 0x4b78, 0x8f, 0x79, 0x96,
+  0xb1, 0x62, 0x3b, 0x3f, 0x17),
+   [VENDOR_DEBUG_UUID] = UUID_INIT(0xe1819d9, 0x11a9, 0x400c, 0x81, 0x1f,
+   0xd6, 0x07, 0x19, 0x40, 0x3d, 0x86),
+};
+
 /**
  * struct cxl_mem_command - Driver representation of a memory device command
  * @info: Command information as it exists for the UAPI
  * @opcode: The actual bits used for the mailbox protocol
+ * @flags: Set of flags effecting driver behavior.
+ *
+ *  * %CXL_CMD_FLAG_FORCE_ENABLE: In cases of error, commands with this flag
+ *will be enabled by the driver regardless of what hardware may have
+ *advertised.
  *
  * The cxl_mem_command is the driver's internal representation of commands that
  * are supported by the driver. Some of these commands may not be supported by
@@ -119,9 +139,12 @@ static bool cxl_raw_allow_all;
 struct cxl_mem_command {
struct cxl_command_info info;
enum opcode opcode;
+   u32 flags;
+#define CXL_CMD_FLAG_NONE 0
+#define CXL_CMD_FLAG_FORCE_ENABLE BIT(0)
 };
 
-#define CXL_CMD(_id, sin, sout)
\
+#define CXL_CMD(_id, sin, sout, _flags)
\
[CXL_MEM_COMMAND_ID_##_id] = { \
   

[PATCH v4 9/9] cxl/mem: Add payload dumping for debug

[Ben Widawsky]

It's often useful in debug scenarios to see what the hardware has dumped
out. As it stands today, any device error will result in the payload not
being copied out, so there is no way to triage commands which weren't
expected to fail (and sometimes the payload may have that information).

The functionality is protected by normal kernel security mechanisms as
well as a CONFIG option in the CXL driver.

This was extracted from the original version of the CXL enabling patch
series.

Signed-off-by: Ben Widawsky 
---
 drivers/cxl/Kconfig | 13 +
 drivers/cxl/mem.c   |  8 
 2 files changed, 21 insertions(+)

diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
index 97dc4d751651..3eec9276e586 100644
--- a/drivers/cxl/Kconfig
+++ b/drivers/cxl/Kconfig
@@ -50,4 +50,17 @@ config CXL_MEM_RAW_COMMANDS
  potential impact to memory currently in use by the kernel.
 
  If developing CXL hardware or the driver say Y, otherwise say N.
+
+config CXL_MEM_INSECURE_DEBUG
+   bool "CXL.mem debugging"
+   depends on CXL_MEM
+   help
+ Enable debug of all CXL command payloads.
+
+ Some CXL devices and controllers support encryption and other
+ security features. The payloads for the commands that enable
+ those features may contain sensitive clear-text security
+ material. Disable debug of those command payloads by default.
+ If you are a kernel developer actively working on CXL
+ security enabling say Y, otherwise say N.
 endif
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index dc608bb20a31..237b956f0be0 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -342,6 +342,14 @@ static int __cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm,
 
/* #5 */
rc = cxl_mem_wait_for_doorbell(cxlm);
+
+   if (!cxl_is_security_command(mbox_cmd->opcode) ||
+   IS_ENABLED(CONFIG_CXL_MEM_INSECURE_DEBUG)) {
+   print_hex_dump_debug("Payload ", DUMP_PREFIX_OFFSET, 16, 1,
+mbox_cmd->payload_in, mbox_cmd->size_in,
+true);
+   }
+
if (rc == -ETIMEDOUT) {
cxl_mem_mbox_timeout(cxlm, mbox_cmd);
return rc;
-- 
2.30.1

[PATCH v4 8/9] MAINTAINERS: Add maintainers of the CXL driver

[Ben Widawsky]

Cc: Dan Williams 
Cc: Vishal Verma 
Cc: Ira Weiny 
Cc: Alison Schofield 
Signed-off-by: Ben Widawsky 
---
 MAINTAINERS | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6eff4f720c72..93c8694a8f04 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -,6 +,17 @@ M:   Miguel Ojeda 
 S: Maintained
 F: include/linux/compiler_attributes.h
 
+COMPUTE EXPRESS LINK (CXL)
+M: Alison Schofield 
+M: Vishal Verma 
+M: Ira Weiny 
+M: Ben Widawsky 
+M: Dan Williams 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/cxl/
+F: include/uapi/linux/cxl_mem.h
+
 CONEXANT ACCESSRUNNER USB DRIVER
 L: accessrunner-gene...@lists.sourceforge.net
 S: Orphan
-- 
2.30.1

[PATCH v4 4/9] cxl/mem: Add basic IOCTL interface

[Ben Widawsky]

Add a straightforward IOCTL that provides a mechanism for userspace to
query the supported memory device commands. CXL commands as they appear
to userspace are described as part of the UAPI kerneldoc. The command
list returned via this IOCTL will contain the full set of commands that
the driver supports, however, some of those commands may not be
available for use by userspace.

Memory device commands first appear in the CXL 2.0 specification. They
are submitted through a mailbox mechanism specified in the CXL 2.0
specification.

The send command allows userspace to issue mailbox commands directly to
the hardware. The list of available commands to send are the output of
the query command. The driver verifies basic properties of the command
and possibly inspect the input (or output) payload to determine whether
or not the command is allowed (or might taint the kernel).

Reported-by: kernel test robot  # bug in earlier revision
Signed-off-by: Ben Widawsky 
Reviewed-by: Dan Williams  (v2)
---
 .clang-format |   1 +
 .../userspace-api/ioctl/ioctl-number.rst  |   1 +
 drivers/cxl/mem.c | 288 +-
 include/uapi/linux/cxl_mem.h  | 154 ++
 4 files changed, 443 insertions(+), 1 deletion(-)
 create mode 100644 include/uapi/linux/cxl_mem.h

diff --git a/.clang-format b/.clang-format
index 10dc5a9a61b3..3f11c8901b43 100644
--- a/.clang-format
+++ b/.clang-format
@@ -109,6 +109,7 @@ ForEachMacros:
   - 'css_for_each_child'
   - 'css_for_each_descendant_post'
   - 'css_for_each_descendant_pre'
+  - 'cxl_for_each_cmd'
   - 'device_for_each_child_node'
   - 'dma_fence_chain_for_each'
   - 'do_for_each_ftrace_op'
diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index a4c75a28c839..6eb8e634664d 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -352,6 +352,7 @@ Code  Seq#Include File  
 Comments
  

 0xCC  00-0F  drivers/misc/ibmvmc.h   pseries 
VMC driver
 0xCD  01 linux/reiserfs_fs.h
+0xCE  01-02  uapi/linux/cxl_mem.hCompute 
Express Link Memory Devices
 0xCF  02 fs/cifs/ioctl.c
 0xDB  00-0F  drivers/char/mwave/mwavepub.h
 0xDD  00-3F  ZFCP 
device driver see drivers/s390/scsi/
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 410adb1bdffc..a4298cb1182d 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /* Copyright(c) 2020 Intel Corporation. All rights reserved. */
+#include 
 #include 
 #include 
 #include 
@@ -40,6 +41,7 @@
 #define CXL_MAILBOX_TIMEOUT_MS (2 * HZ)
 
 enum opcode {
+   CXL_MBOX_OP_INVALID = 0x,
CXL_MBOX_OP_IDENTIFY= 0x4000,
CXL_MBOX_OP_MAX = 0x1
 };
@@ -91,6 +93,49 @@ struct cxl_memdev {
 static int cxl_mem_major;
 static DEFINE_IDA(cxl_memdev_ida);
 
+/**
+ * struct cxl_mem_command - Driver representation of a memory device command
+ * @info: Command information as it exists for the UAPI
+ * @opcode: The actual bits used for the mailbox protocol
+ *
+ * The cxl_mem_command is the driver's internal representation of commands that
+ * are supported by the driver. Some of these commands may not be supported by
+ * the hardware. The driver will use @info to validate the fields passed in by
+ * the user then submit the @opcode to the hardware.
+ *
+ * See struct cxl_command_info.
+ */
+struct cxl_mem_command {
+   struct cxl_command_info info;
+   enum opcode opcode;
+};
+
+#define CXL_CMD(_id, sin, sout)
\
+   [CXL_MEM_COMMAND_ID_##_id] = { \
+   .info = {  \
+   .id = CXL_MEM_COMMAND_ID_##_id,\
+   .size_in = sin,\
+   .size_out = sout,  \
+   }, \
+   .opcode = CXL_MBOX_OP_##_id,   \
+   }
+
+/*
+ * This table defines the supported mailbox commands for the driver. This table
+ * is made up of a UAPI structure. Non-negative values as parameters in the
+ * table will be validated against the user's input. For example, if size_in is
+ * 0, and the user passed in 1, it is an error.
+ */
+static struct cxl_mem_command mem_commands[] = {
+   CXL_CMD(IDENTIFY, 0, 0x43),
+};
+
+#define cxl_for_each_cmd(cmd)  

[PATCH v4 0/9] CXL 2.0 Support

[Ben Widawsky]

# Changes since v3 [1]

* Fix use of GET_SUPPORTED_LOGS (Ben)
  * Reported by Dan
* Rework userspace commands (Al, Dan)
  * Don't get_user twice (Al)
  * Don't pass __user @u to handle_mailbox_cmd_from_user()  (Dan)
* Use void * in cxl_mem_mbox_send_cmd() (Dan)
* Fix for 32b builds (Stephen, Randy, more)
  * Include io-64-nonatomic-lo-hi.h in mem.c
  * Use GENMASK_ULL where appropriate

---

In addition to the mailing list, please feel free to use #cxl on oftc IRC for
discussion.

---

# Summary

Introduce support for “type-3” memory devices defined in the Compute Express
Link (CXL) 2.0 specification [2]. Specifically, these are the memory devices
defined by section 8.2.8.5 of the CXL 2.0 spec. A reference implementation
emulating these devices has been submitted to the QEMU mailing list [3] and is
available on gitlab [4], but will move to a shared tree on kernel.org after
initial acceptance. “Type-3” is a CXL device that acts as a memory expander for
RAM or Persistent Memory. The device might be interleaved with other CXL devices
in a given physical address range.

In addition to the core functionality of discovering the spec defined registers
and resources, introduce a CXL device model that will be the foundation for
translating CXL capabilities into existing Linux infrastructure for Persistent
Memory and other memory devices. For now, this only includes support for the
management command mailbox the surfacing of type-3 devices. These control
devices fill the role of “DIMMs” / nmemX memory-devices in LIBNVDIMM terms.

## Userspace Interaction

Interaction with the driver and type-3 devices via the CXL drivers is introduced
in this patch series and considered stable ABI. They include

   * sysfs - Documentation/ABI/testing/sysfs-bus-cxl
   * IOCTL - Documentation/driver-api/cxl/memory-devices.rst
   * debugfs - Documentation/ABI/testing/debugfs-debug

Work is in process to add support for CXL interactions to the ndctl project [5]

### Development plans

One of the unique challenges that CXL imposes on the Linux driver model is that
it requires the operating system to perform physical address space management
interleaved across devices and bridges. Whereas LIBNVDIMM handles a list of
established static persistent memory address ranges (for example from the ACPI
NFIT), CXL introduces hotplug and the concept of allocating address space to
instantiate persistent memory ranges. This is similar to PCI in the sense that
the platform establishes the MMIO range for PCI BARs to be allocated, but it is
significantly complicated by the fact that a given device can optionally be
interleaved with other devices and can participate in several interleave-sets at
once. LIBNVDIMM handled something like this with the aliasing between PMEM and
BLOCK-WINDOW mode, but CXL adds flexibility to alias DEVICE MEMORY through up to
10 decoders per device.

All of the above needs to be enabled with respect to PCI hotplug events on
Type-3 memory device which needs hooks to determine if a given device is
contributing to a "System RAM" address range that is unable to be unplugged. In
other words CXL ties PCI hotplug to Memory Hotplug and PCI hotplug needs to be
able to negotiate with memory hotplug.  In the medium term the implications of
CXL hotplug vs ACPI SRAT/SLIT/HMAT need to be reconciled. One capability that
seems to be needed is either the dynamic allocation of new memory nodes, or
default initializing extra pgdat instances beyond what is enumerated in ACPI
SRAT to accommodate hot-added CXL memory.

Patches welcome, questions welcome as the development effort on the post v5.12
capabilities proceeds.

## Running in QEMU

The incantation to get CXL support in QEMU [4] is considered unstable at this
time. Future readers of this cover letter should verify if any changes are
needed. For the novice QEMU user, the following can be copy/pasted into a
working QEMU commandline. It is enough to make the simplest topology possible.
The topology would consist of a single memory window, single type3 device,
single root port, and single host bridge.

+-+
|   CXL PXB   |
| |
|  +---+  |<--+
|  |CXL RP |  |   |
+--+---+--+   v
   |+--+
   || "window" |
   |+--+
   v  ^
+-+   |
|  CXL Type 3 |   |
|   Device|<--+
+-+

// Memory backend for "window"
-object memory-backend-file,id=cxl-mem1,share,mem-path=cxl-type3,size=512M

// Memory backend for LSA
-object memory-backend-file,id=cxl-mem1-lsa,share,mem-path=cxl-mem1-lsa,size=1K

// Host Bridge
-device pxb-cxl id=cxl.0,bus=pcie.0,bus_nr=52,uid=0 
len-window-base=1,window-base[0]=0x4c000 memdev[0]=cxl-mem1

// Single root port
-device cxl rp,id=rp0,bus=cxl.0,addr=0.0,chassis=0,slot=0,memdev=cxl-mem1

// Single type3 device
-device 

[PATCH v4 3/9] cxl/mem: Register CXL memX devices

[Ben Widawsky]

From: Dan Williams 

Create the /sys/bus/cxl hierarchy to enumerate:

* Memory Devices (per-endpoint control devices)

* Memory Address Space Devices (platform address ranges with
  interleaving, performance, and persistence attributes)

* Memory Regions (active provisioned memory from an address space device
  that is in use as System RAM or delegated to libnvdimm as Persistent
  Memory regions).

For now, only the per-endpoint control devices are registered on the
'cxl' bus. However, going forward it will provide a mechanism to
coordinate cross-device interleave.

Signed-off-by: Dan Williams 
Signed-off-by: Ben Widawsky 
Reviewed-by: Jonathan Cameron  (v2)
---
 Documentation/ABI/testing/sysfs-bus-cxl   |  26 ++
 .../driver-api/cxl/memory-devices.rst |  17 +
 drivers/cxl/Makefile  |   3 +
 drivers/cxl/bus.c |  29 ++
 drivers/cxl/cxl.h |   3 +
 drivers/cxl/mem.c | 301 +-
 6 files changed, 377 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-cxl
 create mode 100644 drivers/cxl/bus.c

diff --git a/Documentation/ABI/testing/sysfs-bus-cxl 
b/Documentation/ABI/testing/sysfs-bus-cxl
new file mode 100644
index ..2fe7490ad6a8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-cxl
@@ -0,0 +1,26 @@
+What:  /sys/bus/cxl/devices/memX/firmware_version
+Date:  December, 2020
+KernelVersion: v5.12
+Contact:   linux-...@vger.kernel.org
+Description:
+   (RO) "FW Revision" string as reported by the Identify
+   Memory Device Output Payload in the CXL-2.0
+   specification.
+
+What:  /sys/bus/cxl/devices/memX/ram/size
+Date:  December, 2020
+KernelVersion: v5.12
+Contact:   linux-...@vger.kernel.org
+Description:
+   (RO) "Volatile Only Capacity" as bytes. Represents the
+   identically named field in the Identify Memory Device Output
+   Payload in the CXL-2.0 specification.
+
+What:  /sys/bus/cxl/devices/memX/pmem/size
+Date:  December, 2020
+KernelVersion: v5.12
+Contact:   linux-...@vger.kernel.org
+Description:
+   (RO) "Persistent Only Capacity" as bytes. Represents the
+   identically named field in the Identify Memory Device Output
+   Payload in the CXL-2.0 specification.
diff --git a/Documentation/driver-api/cxl/memory-devices.rst 
b/Documentation/driver-api/cxl/memory-devices.rst
index 43177e700d62..1bad466f9167 100644
--- a/Documentation/driver-api/cxl/memory-devices.rst
+++ b/Documentation/driver-api/cxl/memory-devices.rst
@@ -27,3 +27,20 @@ CXL Memory Device
 
 .. kernel-doc:: drivers/cxl/mem.c
:internal:
+
+CXL Bus
+---
+.. kernel-doc:: drivers/cxl/bus.c
+   :doc: cxl bus
+
+External Interfaces
+===
+
+CXL IOCTL Interface
+---
+
+.. kernel-doc:: include/uapi/linux/cxl_mem.h
+   :doc: UAPI
+
+.. kernel-doc:: include/uapi/linux/cxl_mem.h
+   :internal:
diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
index 4a30f7c3fc4a..a314a1891f4d 100644
--- a/drivers/cxl/Makefile
+++ b/drivers/cxl/Makefile
@@ -1,4 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_CXL_BUS) += cxl_bus.o
 obj-$(CONFIG_CXL_MEM) += cxl_mem.o
 
+ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
+cxl_bus-y := bus.o
 cxl_mem-y := mem.o
diff --git a/drivers/cxl/bus.c b/drivers/cxl/bus.c
new file mode 100644
index ..58f74796d525
--- /dev/null
+++ b/drivers/cxl/bus.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright(c) 2020 Intel Corporation. All rights reserved. */
+#include 
+#include 
+
+/**
+ * DOC: cxl bus
+ *
+ * The CXL bus provides namespace for control devices and a rendezvous
+ * point for cross-device interleave coordination.
+ */
+struct bus_type cxl_bus_type = {
+   .name = "cxl",
+};
+EXPORT_SYMBOL_GPL(cxl_bus_type);
+
+static __init int cxl_bus_init(void)
+{
+   return bus_register(_bus_type);
+}
+
+static void cxl_bus_exit(void)
+{
+   bus_unregister(_bus_type);
+}
+
+module_init(cxl_bus_init);
+module_exit(cxl_bus_exit);
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index 0806e6bb8a90..f69313dc3b4e 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -55,6 +55,7 @@
(FIELD_GET(CXLMDEV_RESET_NEEDED_MASK, status) !=   \
 CXLMDEV_RESET_NEEDED_NOT)
 
+struct cxl_memdev;
 /**
  * struct cxl_mem - A CXL memory device
  * @pdev: The PCI device associated with this CXL device.
@@ -72,6 +73,7 @@
 struct cxl_mem {
struct pci_dev *pdev;
void __iomem *regs;
+   struct cxl_memdev *cxlmd;
 
void __iomem *status_regs;
void __iomem *mbox_regs;
@@ -85,4 +87,5 @@ struct cxl_mem {
struct range ram_range;
 };
 
+extern struct bus_type cxl_bus_type;
 #endif /* __CXL_H__ */
diff --git 

[PATCH v4 2/9] cxl/mem: Find device capabilities

[Ben Widawsky]

Provide enough functionality to utilize the mailbox of a memory device.
The mailbox is used to interact with the firmware running on the memory
device. The flow is proven with one implemented command, "identify".
Because the class code has already told the driver this is a memory
device and the identify command is mandatory.

CXL devices contain an array of capabilities that describe the
interactions software can have with the device or firmware running on
the device. A CXL compliant device must implement the device status and
the mailbox capability. Additionally, a CXL compliant memory device must
implement the memory device capability. Each of the capabilities can
[will] provide an offset within the MMIO region for interacting with the
CXL device.

The capabilities tell the driver how to find and map the register space
for CXL Memory Devices. The registers are required to utilize the CXL
spec defined mailbox interface. The spec outlines two mailboxes, primary
and secondary. The secondary mailbox is earmarked for system firmware,
and not handled in this driver.

Primary mailboxes are capable of generating an interrupt when submitting
a background command. That implementation is saved for a later time.

Link: https://www.computeexpresslink.org/download-the-specification
Signed-off-by: Ben Widawsky 
Reviewed-by: Dan Williams  (v2)
---
 drivers/cxl/cxl.h |  88 
 drivers/cxl/mem.c | 543 +-
 drivers/cxl/pci.h |  14 ++
 3 files changed, 643 insertions(+), 2 deletions(-)
 create mode 100644 drivers/cxl/cxl.h

diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
new file mode 100644
index ..0806e6bb8a90
--- /dev/null
+++ b/drivers/cxl/cxl.h
@@ -0,0 +1,88 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* Copyright(c) 2020 Intel Corporation. */
+
+#ifndef __CXL_H__
+#define __CXL_H__
+
+#include 
+#include 
+#include 
+
+/* CXL 2.0 8.2.8.1 Device Capabilities Array Register */
+#define CXLDEV_CAP_ARRAY_OFFSET 0x0
+#define   CXLDEV_CAP_ARRAY_CAP_ID 0
+#define   CXLDEV_CAP_ARRAY_ID_MASK GENMASK_ULL(15, 0)
+#define   CXLDEV_CAP_ARRAY_COUNT_MASK GENMASK_ULL(47, 32)
+/* CXL 2.0 8.2.8.2.1 CXL Device Capabilities */
+#define CXLDEV_CAP_CAP_ID_DEVICE_STATUS 0x1
+#define CXLDEV_CAP_CAP_ID_PRIMARY_MAILBOX 0x2
+#define CXLDEV_CAP_CAP_ID_SECONDARY_MAILBOX 0x3
+#define CXLDEV_CAP_CAP_ID_MEMDEV 0x4000
+
+/* CXL 2.0 8.2.8.4 Mailbox Registers */
+#define CXLDEV_MBOX_CAPS_OFFSET 0x00
+#define   CXLDEV_MBOX_CAP_PAYLOAD_SIZE_MASK GENMASK(4, 0)
+#define CXLDEV_MBOX_CTRL_OFFSET 0x04
+#define   CXLDEV_MBOX_CTRL_DOORBELL BIT(0)
+#define CXLDEV_MBOX_CMD_OFFSET 0x08
+#define   CXLDEV_MBOX_CMD_COMMAND_OPCODE_MASK GENMASK_ULL(15, 0)
+#define   CXLDEV_MBOX_CMD_PAYLOAD_LENGTH_MASK GENMASK_ULL(36, 16)
+#define CXLDEV_MBOX_STATUS_OFFSET 0x10
+#define   CXLDEV_MBOX_STATUS_RET_CODE_MASK GENMASK_ULL(47, 32)
+#define CXLDEV_MBOX_BG_CMD_STATUS_OFFSET 0x18
+#define CXLDEV_MBOX_PAYLOAD_OFFSET 0x20
+
+/* CXL 2.0 8.2.8.5.1.1 Memory Device Status Register */
+#define CXLMDEV_STATUS_OFFSET 0x0
+#define   CXLMDEV_DEV_FATAL BIT(0)
+#define   CXLMDEV_FW_HALT BIT(1)
+#define   CXLMDEV_STATUS_MEDIA_STATUS_MASK GENMASK(3, 2)
+#define CXLMDEV_MS_NOT_READY 0
+#define CXLMDEV_MS_READY 1
+#define CXLMDEV_MS_ERROR 2
+#define CXLMDEV_MS_DISABLED 3
+#define CXLMDEV_READY(status)  
\
+   (FIELD_GET(CXLMDEV_STATUS_MEDIA_STATUS_MASK, status) ==\
+CXLMDEV_MS_READY)
+#define   CXLMDEV_MBOX_IF_READY BIT(4)
+#define   CXLMDEV_RESET_NEEDED_MASK GENMASK(7, 5)
+#define CXLMDEV_RESET_NEEDED_NOT 0
+#define CXLMDEV_RESET_NEEDED_COLD 1
+#define CXLMDEV_RESET_NEEDED_WARM 2
+#define CXLMDEV_RESET_NEEDED_HOT 3
+#define CXLMDEV_RESET_NEEDED_CXL 4
+#define CXLMDEV_RESET_NEEDED(status)   
\
+   (FIELD_GET(CXLMDEV_RESET_NEEDED_MASK, status) !=   \
+CXLMDEV_RESET_NEEDED_NOT)
+
+/**
+ * struct cxl_mem - A CXL memory device
+ * @pdev: The PCI device associated with this CXL device.
+ * @regs: IO mappings to the device's MMIO
+ * @status_regs: CXL 2.0 8.2.8.3 Device Status Registers
+ * @mbox_regs: CXL 2.0 8.2.8.4 Mailbox Registers
+ * @memdev_regs: CXL 2.0 8.2.8.5 Memory Device Registers
+ * @payload_size: Size of space for payload
+ *(CXL 2.0 8.2.8.4.3 Mailbox Capabilities Register)
+ * @mbox_mutex: Mutex to synchronize mailbox access.
+ * @firmware_version: Firmware version for the memory device.
+ * @pmem: Persistent memory capacity information.
+ * @ram: Volatile memory capacity information.
+ */
+struct cxl_mem {
+   struct pci_dev *pdev;
+   void __iomem *regs;
+
+   void __iomem *status_regs;
+   void __iomem *mbox_regs;
+   void __iomem *memdev_regs;
+
+   size_t payload_size;
+   struct mutex mbox_mutex; /* Protects device mailbox and firmware */
+   char firmware_version[0x10];
+
+   

[PATCH v4 1/9] cxl/mem: Introduce a driver for CXL-2.0-Type-3 endpoints

[Ben Widawsky]

From: Dan Williams 

The CXL.mem protocol allows a device to act as a provider of "System
RAM" and/or "Persistent Memory" that is fully coherent as if the memory
was attached to the typical CPU memory controller.

With the CXL-2.0 specification a PCI endpoint can implement a "Type-3"
device interface and give the operating system control over "Host
Managed Device Memory". See section 2.3 Type 3 CXL Device.

The memory range exported by the device may optionally be described by
the platform firmware memory map, or by infrastructure like LIBNVDIMM to
provision persistent memory capacity from one, or more, CXL.mem devices.

A pre-requisite for Linux-managed memory-capacity provisioning is this
cxl_mem driver that can speak the mailbox protocol defined in section
8.2.8.4 Mailbox Registers.

For now just land the initial driver boiler-plate and Documentation/
infrastructure.

Link: https://www.computeexpresslink.org/download-the-specification
Cc: Jonathan Corbet 
Signed-off-by: Dan Williams 
Signed-off-by: Ben Widawsky 
Acked-by: David Rientjes  (v1)
Reviewed-by: Jonathan Cameron 
---
 Documentation/driver-api/cxl/index.rst| 12 
 .../driver-api/cxl/memory-devices.rst | 29 +
 Documentation/driver-api/index.rst|  1 +
 drivers/Kconfig   |  1 +
 drivers/Makefile  |  1 +
 drivers/cxl/Kconfig   | 35 +++
 drivers/cxl/Makefile  |  4 ++
 drivers/cxl/mem.c | 62 +++
 drivers/cxl/pci.h | 17 +
 include/linux/pci_ids.h   |  1 +
 10 files changed, 163 insertions(+)
 create mode 100644 Documentation/driver-api/cxl/index.rst
 create mode 100644 Documentation/driver-api/cxl/memory-devices.rst
 create mode 100644 drivers/cxl/Kconfig
 create mode 100644 drivers/cxl/Makefile
 create mode 100644 drivers/cxl/mem.c
 create mode 100644 drivers/cxl/pci.h

diff --git a/Documentation/driver-api/cxl/index.rst 
b/Documentation/driver-api/cxl/index.rst
new file mode 100644
index ..036e49553542
--- /dev/null
+++ b/Documentation/driver-api/cxl/index.rst
@@ -0,0 +1,12 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Compute Express Link
+
+
+.. toctree::
+   :maxdepth: 1
+
+   memory-devices
+
+.. only::  subproject and html
diff --git a/Documentation/driver-api/cxl/memory-devices.rst 
b/Documentation/driver-api/cxl/memory-devices.rst
new file mode 100644
index ..43177e700d62
--- /dev/null
+++ b/Documentation/driver-api/cxl/memory-devices.rst
@@ -0,0 +1,29 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: 
+
+===
+Compute Express Link Memory Devices
+===
+
+A Compute Express Link Memory Device is a CXL component that implements the
+CXL.mem protocol. It contains some amount of volatile memory, persistent 
memory,
+or both. It is enumerated as a PCI device for configuration and passing
+messages over an MMIO mailbox. Its contribution to the System Physical
+Address space is handled via HDM (Host Managed Device Memory) decoders
+that optionally define a device's contribution to an interleaved address
+range across multiple devices underneath a host-bridge or interleaved
+across host-bridges.
+
+Driver Infrastructure
+=
+
+This section covers the driver infrastructure for a CXL memory device.
+
+CXL Memory Device
+-
+
+.. kernel-doc:: drivers/cxl/mem.c
+   :doc: cxl mem
+
+.. kernel-doc:: drivers/cxl/mem.c
+   :internal:
diff --git a/Documentation/driver-api/index.rst 
b/Documentation/driver-api/index.rst
index 2456d0a97ed8..d246a18fd78f 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -35,6 +35,7 @@ available subsections can be seen below.
usb/index
firewire
pci/index
+   cxl/index
spi
i2c
ipmb
diff --git a/drivers/Kconfig b/drivers/Kconfig
index dcecc9f6e33f..62c753a73651 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -6,6 +6,7 @@ menu "Device Drivers"
 source "drivers/amba/Kconfig"
 source "drivers/eisa/Kconfig"
 source "drivers/pci/Kconfig"
+source "drivers/cxl/Kconfig"
 source "drivers/pcmcia/Kconfig"
 source "drivers/rapidio/Kconfig"
 
diff --git a/drivers/Makefile b/drivers/Makefile
index fd11b9ac4cc3..678ea810410f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_NVM) += lightnvm/
 obj-y  += base/ block/ misc/ mfd/ nfc/
 obj-$(CONFIG_LIBNVDIMM)+= nvdimm/
 obj-$(CONFIG_DAX)  += dax/
+obj-$(CONFIG_CXL_BUS)  += cxl/
 obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/
 obj-$(CONFIG_NUBUS)+= nubus/
 obj-y  += macintosh/
diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
new file mode 100644
index ..9e80b311e928
--- 

[PATCH v4 5/9] cxl/mem: Add a "RAW" send command

[Ben Widawsky]

The CXL memory device send interface will have a number of supported
commands. The raw command is not such a command. Raw commands allow
userspace to send a specified opcode to the underlying hardware and
bypass all driver checks on the command. The primary use for this
command is to [begrudgingly] allow undocumented vendor specific hardware
commands.

While not the main motivation, it also allows prototyping new hardware
commands without a driver patch and rebuild.

While this all sounds very powerful it comes with a couple of caveats:
1. Bug reports using raw commands will not get the same level of
   attention as bug reports using supported commands (via taint).
2. Supported commands will be rejected by the RAW command.

With this comes new debugfs knob to allow full access to your toes with
your weapon of choice.

Cc: Ariel Sibley 
Signed-off-by: Ben Widawsky 
Reviewed-by: Dan Williams  (v2)
---
 drivers/cxl/Kconfig  |  18 +
 drivers/cxl/mem.c| 132 +++
 include/uapi/linux/cxl_mem.h |  12 +++-
 3 files changed, 161 insertions(+), 1 deletion(-)

diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
index 9e80b311e928..97dc4d751651 100644
--- a/drivers/cxl/Kconfig
+++ b/drivers/cxl/Kconfig
@@ -32,4 +32,22 @@ config CXL_MEM
  Chapter 2.3 Type 3 CXL Device in the CXL 2.0 specification.
 
  If unsure say 'm'.
+
+config CXL_MEM_RAW_COMMANDS
+   bool "RAW Command Interface for Memory Devices"
+   depends on CXL_MEM
+   help
+ Enable CXL RAW command interface.
+
+ The CXL driver ioctl interface may assign a kernel ioctl command
+ number for each specification defined opcode. At any given point in
+ time the number of opcodes that the specification defines and a device
+ may implement may exceed the kernel's set of associated ioctl function
+ numbers. The mismatch is either by omission, specification is too new,
+ or by design. When prototyping new hardware, or developing / debugging
+ the driver it is useful to be able to submit any possible command to
+ the hardware, even commands that may crash the kernel due to their
+ potential impact to memory currently in use by the kernel.
+
+ If developing CXL hardware or the driver say Y, otherwise say N.
 endif
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index a4298cb1182d..6b4feb0ce47d 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -1,6 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /* Copyright(c) 2020 Intel Corporation. All rights reserved. */
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -42,7 +44,14 @@
 
 enum opcode {
CXL_MBOX_OP_INVALID = 0x,
+   CXL_MBOX_OP_RAW = CXL_MBOX_OP_INVALID,
+   CXL_MBOX_OP_ACTIVATE_FW = 0x0202,
CXL_MBOX_OP_IDENTIFY= 0x4000,
+   CXL_MBOX_OP_SET_PARTITION_INFO  = 0x4101,
+   CXL_MBOX_OP_SET_LSA = 0x4103,
+   CXL_MBOX_OP_SET_SHUTDOWN_STATE  = 0x4204,
+   CXL_MBOX_OP_SCAN_MEDIA  = 0x4304,
+   CXL_MBOX_OP_GET_SCAN_MEDIA  = 0x4305,
CXL_MBOX_OP_MAX = 0x1
 };
 
@@ -92,6 +101,8 @@ struct cxl_memdev {
 
 static int cxl_mem_major;
 static DEFINE_IDA(cxl_memdev_ida);
+static struct dentry *cxl_debugfs;
+static bool cxl_raw_allow_all;
 
 /**
  * struct cxl_mem_command - Driver representation of a memory device command
@@ -128,6 +139,49 @@ struct cxl_mem_command {
  */
 static struct cxl_mem_command mem_commands[] = {
CXL_CMD(IDENTIFY, 0, 0x43),
+#ifdef CONFIG_CXL_MEM_RAW_COMMANDS
+   CXL_CMD(RAW, ~0, ~0),
+#endif
+};
+
+/*
+ * Commands that RAW doesn't permit. The rationale for each:
+ *
+ * CXL_MBOX_OP_ACTIVATE_FW: Firmware activation requires adjustment /
+ * coordination of transaction timeout values at the root bridge level.
+ *
+ * CXL_MBOX_OP_SET_PARTITION_INFO: The device memory map may change live
+ * and needs to be coordinated with HDM updates.
+ *
+ * CXL_MBOX_OP_SET_LSA: The label storage area may be cached by the
+ * driver and any writes from userspace invalidates those contents.
+ *
+ * CXL_MBOX_OP_SET_SHUTDOWN_STATE: Set shutdown state assumes no writes
+ * to the device after it is marked clean, userspace can not make that
+ * assertion.
+ *
+ * CXL_MBOX_OP_[GET_]SCAN_MEDIA: The kernel provides a native error list that
+ * is kept up to date with patrol notifications and error management.
+ */
+static u16 cxl_disabled_raw_commands[] = {
+   CXL_MBOX_OP_ACTIVATE_FW,
+   CXL_MBOX_OP_SET_PARTITION_INFO,
+   CXL_MBOX_OP_SET_LSA,
+   CXL_MBOX_OP_SET_SHUTDOWN_STATE,
+   CXL_MBOX_OP_SCAN_MEDIA,
+   CXL_MBOX_OP_GET_SCAN_MEDIA,
+};
+
+/*
+ * Command sets that RAW doesn't permit. All opcodes in this set are
+ * disabled because they pass plain text security payloads over the
+ * user/kernel boundary. This functionality is intended to be wrapped

Re: usb: dwc3: gadget: Change runtime pm function for DWC3 runtime suspend

[Jung Daehwan]

Hello, Alan

On Mon, Feb 15, 2021 at 12:41:45PM -0500, Alan Stern wrote:
> On Mon, Feb 15, 2021 at 11:38:58AM +0900, Daehwan Jung wrote:
> > It seems pm_runtime_put calls runtime_idle callback not runtime_suspend 
> > callback.
> 
> How is this fact related to your patch?

I think we should cause dwc3_runtime_suspend at the time.
That's why I use pm_runtime_put_sync_suspend.

> 
> > It's better to use pm_runtime_put_sync_suspend to allow DWC3 runtime 
> > suspend.
> 
> Why do you think it is better?  The advantage of pm_runtime_put is that 
> it allows the suspend to occur at a later time in a workqueue thread, so 
> the caller doesn't have to wait for the device to go into suspend.
> 

We can assume DWC3 was already in suspend state if pm_runtime_get_sync
returns 0. DWC3 resumes due to pm_rumtime_get_sync but it doesn't
re-enter runtime_suspend but runtime_idle. pm_runtime_put decreases
usage_count but doesn't cause runtime_suspend.

1. USB disconnected
2. UDC unbinded
3. DWC3 runtime suspend
4. UDC binded unexpectedly
5. DWC3 runtime resume (pm_runtime_get_sync)
6. DWC3 runtime idle (pm_runtime_put)
   -> DWC3 runtime suspend again (pm_runtime_put_sync_suspend)

I've talked with Wesley in other patch.

usbb: dwc3: gadget: skip pullup and set_speed after suspend
patchwork.kernel.org/project/linux-usb/patch/163968-102424-1-git-send-email-dh10.j...@samsung.com

@ Wesley

I think We should guarantee DWC3 enters suspend again at the time.
How do you think?

Best Regards,
Jung Daehwan

> Alan Stern
> 


> > Signed-off-by: Daehwan Jung 
> > ---
> >  drivers/usb/dwc3/gadget.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > index aebcf8e..4a4b93b 100644
> > --- a/drivers/usb/dwc3/gadget.c
> > +++ b/drivers/usb/dwc3/gadget.c
> > @@ -2229,7 +2229,7 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, 
> > int is_on)
> >  */
> > ret = pm_runtime_get_sync(dwc->dev);
> > if (!ret || ret < 0) {
> > -   pm_runtime_put(dwc->dev);
> > +   pm_runtime_put_sync_suspend(dwc->dev);
> > return 0;
> > }
> >  
> > -- 
> > 2.7.4
> > 
> 

Re: [PATCH v8 10/22] counter: Standardize to ERANGE for limit exceeded errors

[William Breathitt Gray]

On Sun, Feb 14, 2021 at 05:10:21PM +, Jonathan Cameron wrote:
> On Fri, 12 Feb 2021 21:13:34 +0900
> William Breathitt Gray  wrote:
> 
> > ERANGE is a semantically better error code to return when an argument
> > value falls outside the supported limit range of a device.
> 
> #define   ERANGE  34  /* Math result not representable */
> 
> Not generally applicable to a parameter being out of range
> despite the name.
> #define   EINVAL  22  /* Invalid argument */
> Is probably closer to what we want to describe here.
> 
> Jonathan

The comment for ERANGE in error-base.h may be terse to a fault. I
believe there's a connotation here provided by ERANGE that is absent
from EINVAL: primarily that the device buffer is incapable of supporting
the desired value (i.e. there is a hardware limitation).

This is why strtoul() returns ERANGE if the correct value is outside the
range of representable values: the result of the operation is valid in
theory (it would be an unsigned integer), but it cannot be returned to
the user due to a limitation of the hardware to support that value (e.g.
32-bit registers) [1].

The changes in this patch follow the same logic: these are arguments
that are valid in theory (e.g. they are unsigned integers), but the
underlying devices are incapable of processing such a value (e.g. the
104-QUAD-8 can only handle 24-bit values).

[1] https://stackoverflow.com/a/34981398/1806289

William Breathitt Gray


signature.asc
Description: PGP signature

Re: [PATCH] USB: gadget: Fix a configfs return code

[Lorenzo Colitti]

On Tue, Feb 16, 2021 at 12:57 AM Dan Carpenter  wrote:
> {   \
> struct f_##_f_##_opts *opts = to_f_##_f_##_opts(item);  \
> -   int ret;\
> +   int ret = -EINVAL;  \
> u8 val; \
> \
> mutex_lock(>lock);\
> -   ret = sscanf(page, "%02hhx", ); \
> -   if (ret > 0) {  \
> +   if (sscanf(page, "%02hhx", ) > 0) { \
> opts->_n_ = val;\
> ret = len;  \
> }   \

Acked-by: Lorenzo Colitti 

[PATCH v2 0/1] s390/vfio-ap: fix circular lockdep when staring SE guest

[Tony Krowiak]

Commit f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM
pointer invalidated") introduced a change that results in a circular
lockdep when a Secure Execution guest that is configured with
crypto devices is started. The problem resulted due to the fact that the
patch moved the setting of the guest's AP masks within the protection of
the matrix_dev->lock when the vfio_ap driver is notified that the KVM 
pointer has been set. Since it is not critical that setting/clearing of
the guest's AP masks be done under the matrix_dev->lock when the driver is
notified, the masks will not be updated under the matrix_dev->lock. The
lock is necessary for the setting/unsetting of the KVM pointer, however,
so that will remain in place. 

The dependency chain for the circular lockdep resolved by this patch 
is (in reverse order):

2:  vfio_ap_mdev_group_notifier:kvm->lock
matrix_dev->lock

1:  handle_pqap:matrix_dev->lock
kvm_vcpu_ioctl: vcpu->mutex

0:  kvm_s390_cpus_to_pv:vcpu->mutex
kvm_vm_ioctl:   kvm->lock

Please note that if checkpatch is run against this patch series, you may
get a "WARNING: Unknown commit id 'f21916ec4826', maybe rebased or not 
pulled?" message. The commit 'f21916ec4826', however, is definitely
in the master branch on top of which this patch series was built, so I'm
not sure why this message is being output by checkpatch. 

Change log v1=> v2:
--
* No longer holding the matrix_dev->lock prior to setting/clearing the
  masks supplying the AP configuration to a KVM guest.
* Make all updates to the data in the matrix mdev that is used to manage
  AP resources used by the KVM guest in the vfio_ap_mdev_set_kvm() function
  instead of the group notifier callback.
* Check for the matrix mdev's KVM pointer in the vfio_ap_mdev_unset_kvm()
  function instead of the vfio_ap_mdev_release() function.

Tony Krowiak (1):
  s390/vfio-ap: fix circular lockdep when setting/clearing crypto masks

 drivers/s390/crypto/vfio_ap_ops.c | 119 +-
 1 file changed, 84 insertions(+), 35 deletions(-)

-- 
2.21.1

[PATCH v2 1/1] s390/vfio-ap: fix circular lockdep when setting/clearing crypto masks

[Tony Krowiak]

This patch fixes a circular locking dependency in the CI introduced by
commit f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM
pointer invalidated"). The lockdep only occurs when starting a Secure
Execution guest. Crypto virtualization (vfio_ap) is not yet supported for
SE guests; however, in order to avoid CI errors, this fix is being
provided.

The circular lockdep was introduced when the masks in the guest's APCB
were taken under the matrix_dev->lock. While the lock is definitely
needed to protect the setting/unsetting of the KVM pointer, it is not
necessarily critical for setting the masks, so this will not be done under
protection of the matrix_dev->lock.

Fixes: f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer 
invalidated")
Cc: sta...@vger.kernel.org
Signed-off-by: Tony Krowiak 
---
 drivers/s390/crypto/vfio_ap_ops.c | 119 +-
 1 file changed, 84 insertions(+), 35 deletions(-)

diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
b/drivers/s390/crypto/vfio_ap_ops.c
index 41fc2e4135fe..8574b6ecc9c5 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -1027,8 +1027,21 @@ static const struct attribute_group 
*vfio_ap_mdev_attr_groups[] = {
  * @matrix_mdev: a mediated matrix device
  * @kvm: reference to KVM instance
  *
- * Verifies no other mediated matrix device has @kvm and sets a reference to
- * it in @matrix_mdev->kvm.
+ * Sets all data for @matrix_mdev that are needed to manage AP resources
+ * for the guest whose state is represented by @kvm:
+ * 1. Verifies no other mediated device has a reference to @kvm.
+ * 2. Increments the ref count for @kvm so it doesn't disappear until the
+ *vfio_ap driver is notified the pointer is being nullified.
+ * 3. Sets a reference to the PQAP hook (i.e., handle_pqap() function) into
+ *@kvm to handle interception of the PQAP(AQIC) instruction.
+ * 4. Sets the masks supplying the AP configuration to the KVM guest.
+ * 5. Sets the KVM pointer into @kvm so the vfio_ap driver can access it.
+ *
+ * Note: The matrix_dev->lock must be taken prior to calling
+ * this function; however, the lock will be temporarily released to avoid a
+ * potential circular lock dependency with other asynchronous processes that
+ * lock the kvm->lock mutex which is also needed to supply the guest's AP
+ * configuration.
  *
  * Return 0 if no other mediated matrix device has a reference to @kvm;
  * otherwise, returns an -EPERM.
@@ -1043,9 +1056,17 @@ static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev 
*matrix_mdev,
return -EPERM;
}
 
-   matrix_mdev->kvm = kvm;
-   kvm_get_kvm(kvm);
-   kvm->arch.crypto.pqap_hook = _mdev->pqap_hook;
+   if (kvm->arch.crypto.crycbd) {
+   kvm_get_kvm(kvm);
+   kvm->arch.crypto.pqap_hook = _mdev->pqap_hook;
+   mutex_unlock(_dev->lock);
+   kvm_arch_crypto_set_masks(kvm,
+ matrix_mdev->matrix.apm,
+ matrix_mdev->matrix.aqm,
+ matrix_mdev->matrix.adm);
+   mutex_lock(_dev->lock);
+   matrix_mdev->kvm = kvm;
+   }
 
return 0;
 }
@@ -1079,51 +1100,80 @@ static int vfio_ap_mdev_iommu_notifier(struct 
notifier_block *nb,
return NOTIFY_DONE;
 }
 
+/**
+ * vfio_ap_mdev_unset_kvm
+ *
+ * @matrix_mdev: a matrix mediated device
+ *
+ * Performs clean-up of resources no longer needed by @matrix_mdev.
+ *
+ * Note: The matrix_dev->lock must be taken prior to calling this
+ * function; however,  the lock will be temporarily released to avoid a
+ * potential circular lock dependency with other asynchronous processes that
+ * lock the kvm->lock mutex which is also needed to update the guest's AP
+ * configuration as follows:
+ * 1.  Grab a reference to the KVM pointer stored in @matrix_mdev.
+ * 2.  Set the KVM pointer in @matrix_mdev to NULL so no other asynchronous
+ * process uses it (e.g., assign_adapter store function) after
+ * unlocking the matrix_dev->lock mutex.
+ * 3.  Set the PQAP hook to NULL so it will not be invoked after unlocking
+ * the matrix_dev->lock mutex.
+ * 4.  Unlock the matrix_dev->lock mutex to avoid circular lock
+ * dependencies.
+ * 5.  Clear the masks in the guest's APCB to remove guest access to AP
+ * resources assigned to @matrix_mdev.
+ * 6.  Lock the matrix_dev->lock mutex to prevent access to resources
+ * assigned to @matrix_mdev while the remainder of the cleanup
+ * operations take place.
+ * 7.  Decrement the reference counter incremented in #1.
+ * 8.  Set the reference to the KVM pointer grabbed in #1 into @matrix_mdev
+ * (set to NULL in #2) because it will be needed when the queues are
+ * reset to clean up any IRQ resources being held.
+ * 9.  

[PATCH net-next v3 5/5] TEST ONLY: lan743x: skb_trim failure test

[Sven Van Asbroeck]

From: Sven Van Asbroeck 

Simulate low-memory in lan743x_rx_trim_skb(): fail one allocation
in every 100.

Signed-off-by: Sven Van Asbroeck 
---

To: Bryan Whitehead 
To: unglinuxdri...@microchip.com
To: "David S. Miller" 
To: Jakub Kicinski 
Cc: Andrew Lunn 
Cc: Alexey Denisov 
Cc: Sergej Bauer 
Cc: Tim Harvey 
Cc: Anders Rønningen 
Cc: Hillf Danton 
Cc: Christoph Hellwig 
Cc: Willem de Bruijn 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

 drivers/net/ethernet/microchip/lan743x_main.c | 28 ---
 1 file changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan743x_main.c 
b/drivers/net/ethernet/microchip/lan743x_main.c
index 6e1b3c996bd7..4751626f4c0f 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -1963,20 +1963,7 @@ static void lan743x_rx_update_tail(struct lan743x_rx 
*rx, int index)
  index);
 }
 
-static struct sk_buff *
-lan743x_alloc_skb(struct net_device *netdev, int length, bool can_fail)
-{
-   static int rx_alloc;
-   int counter = rx_alloc++ % 100;
-
-   if (can_fail && counter >= 20 && counter < 30)
-   return NULL;
-
-   return __netdev_alloc_skb(netdev, length, GFP_ATOMIC | GFP_DMA);
-}
-
-static int
-lan743x_rx_init_ring_element(struct lan743x_rx *rx, int index, bool can_fail)
+static int lan743x_rx_init_ring_element(struct lan743x_rx *rx, int index)
 {
struct net_device *netdev = rx->adapter->netdev;
struct device *dev = >adapter->pdev->dev;
@@ -1990,7 +1977,7 @@ lan743x_rx_init_ring_element(struct lan743x_rx *rx, int 
index, bool can_fail)
 
descriptor = >ring_cpu_ptr[index];
buffer_info = >buffer_info[index];
-   skb = lan743x_alloc_skb(netdev, buffer_length, can_fail);
+   skb = __netdev_alloc_skb(netdev, buffer_length, GFP_ATOMIC | GFP_DMA);
if (!skb)
return -ENOMEM;
dma_ptr = dma_map_single(dev, skb->data, buffer_length, 
DMA_FROM_DEVICE);
@@ -2078,6 +2065,13 @@ static void lan743x_rx_release_ring_element(struct 
lan743x_rx *rx, int index)
 static struct sk_buff *
 lan743x_rx_trim_skb(struct sk_buff *skb, int frame_length)
 {
+   static int trim_cnt;
+
+   if ((trim_cnt++ % 100) == 77) {
+   dev_kfree_skb_irq(skb);
+   return NULL;
+   }
+
if (skb_linearize(skb)) {
dev_kfree_skb_irq(skb);
return NULL;
@@ -2152,7 +2146,7 @@ static int lan743x_rx_process_buffer(struct lan743x_rx 
*rx)
 
/* save existing skb, allocate new skb and map to dma */
skb = buffer_info->skb;
-   if (lan743x_rx_init_ring_element(rx, rx->last_head, true)) {
+   if (lan743x_rx_init_ring_element(rx, rx->last_head)) {
/* failed to allocate next skb.
 * Memory is very low.
 * Drop this packet and reuse buffer.
@@ -2357,7 +2351,7 @@ static int lan743x_rx_ring_init(struct lan743x_rx *rx)
 
rx->last_head = 0;
for (index = 0; index < rx->ring_size; index++) {
-   ret = lan743x_rx_init_ring_element(rx, index, false);
+   ret = lan743x_rx_init_ring_element(rx, index);
if (ret)
goto cleanup;
}
-- 
2.17.1