Re: linux-next: build failure after merge of the hid tree

[Hans de Goede]

Hi Stephen, Jiri,

On 10/4/19 2:28 AM, Stephen Rothwell wrote:

Hi all,

After merging the hid tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ld: drivers/hid/hid-lg-g15.o: in function `.lg_g15_probe':
hid-lg-g15.c:(.text+0x1a1c): undefined reference to 
`.devm_led_classdev_register_ext'
ld: hid-lg-g15.c:(.text+0x1c68): undefined reference to 
`.devm_led_classdev_register_ext'

Caused by commit

   3a0275384c27 ("HID: Add driver for Logitech gaming keyboards (G15, G15 v2)")

For this build, CONFIG_HID_LOGITECH=y and CONFIG_LEDS_CLASS=m.


My bad, thank you for reporting this. I will try to come up with a fix for this
today.

Regards,

Hans

[PATCH] lib/generic-radix-tree.c: add kmemleak annotations

[Eric Biggers]

From: Eric Biggers 

Kmemleak is falsely reporting a leak of the slab allocation in
sctp_stream_init_ext():

BUG: memory leak
unreferenced object 0x8881114f5d80 (size 96):
   comm "syz-executor934", pid 7160, jiffies 4294993058 (age 31.950s)
   hex dump (first 32 bytes):
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
   backtrace:
 [] kmemleak_alloc_recursive  include/linux/kmemleak.h:55 
[inline]
 [] slab_post_alloc_hook mm/slab.h:439 [inline]
 [] slab_alloc mm/slab.c:3326 [inline]
 [] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
 [<7abb7ac9>] kmalloc include/linux/slab.h:547 [inline]
 [<7abb7ac9>] kzalloc include/linux/slab.h:742 [inline]
 [<7abb7ac9>] sctp_stream_init_ext+0x2b/0xa0  net/sctp/stream.c:157
 [<48ecb9c1>] sctp_sendmsg_to_asoc+0x946/0xa00  
net/sctp/socket.c:1882
 [<4483ca2b>] sctp_sendmsg+0x2a8/0x990 net/sctp/socket.c:2102
 [...]

But it's freed later.  Kmemleak misses the allocation because its
pointer is stored in the generic radix tree sctp_stream::out, and the
generic radix tree uses raw pages which aren't tracked by kmemleak.

Fix this by adding the kmemleak hooks to the generic radix tree code.

Reported-by: syzbot+7f3b6b106be8dcdcd...@syzkaller.appspotmail.com
Signed-off-by: Eric Biggers 
---
 lib/generic-radix-tree.c | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/lib/generic-radix-tree.c b/lib/generic-radix-tree.c
index ae25e2fa2187..f25eb111c051 100644
--- a/lib/generic-radix-tree.c
+++ b/lib/generic-radix-tree.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define GENRADIX_ARY   (PAGE_SIZE / sizeof(struct genradix_node *))
 #define GENRADIX_ARY_SHIFT ilog2(GENRADIX_ARY)
@@ -75,6 +76,27 @@ void *__genradix_ptr(struct __genradix *radix, size_t offset)
 }
 EXPORT_SYMBOL(__genradix_ptr);
 
+static inline struct genradix_node *genradix_alloc_node(gfp_t gfp_mask)
+{
+   struct genradix_node *node;
+
+   node = (struct genradix_node *)__get_free_page(gfp_mask|__GFP_ZERO);
+
+   /*
+* We're using pages (not slab allocations) directly for kernel data
+* structures, so we need to explicitly inform kmemleak of them in order
+* to avoid false positive memory leak reports.
+*/
+   kmemleak_alloc(node, PAGE_SIZE, 1, gfp_mask);
+   return node;
+}
+
+static inline void genradix_free_node(struct genradix_node *node)
+{
+   kmemleak_free(node);
+   free_page((unsigned long)node);
+}
+
 /*
  * Returns pointer to the specified byte @offset within @radix, allocating it 
if
  * necessary - newly allocated slots are always zeroed out:
@@ -97,8 +119,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t 
offset,
break;
 
if (!new_node) {
-   new_node = (void *)
-   __get_free_page(gfp_mask|__GFP_ZERO);
+   new_node = genradix_alloc_node(gfp_mask);
if (!new_node)
return NULL;
}
@@ -121,8 +142,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t 
offset,
n = READ_ONCE(*p);
if (!n) {
if (!new_node) {
-   new_node = (void *)
-   __get_free_page(gfp_mask|__GFP_ZERO);
+   new_node = genradix_alloc_node(gfp_mask);
if (!new_node)
return NULL;
}
@@ -133,7 +153,7 @@ void *__genradix_ptr_alloc(struct __genradix *radix, size_t 
offset,
}
 
if (new_node)
-   free_page((unsigned long) new_node);
+   genradix_free_node(new_node);
 
return &n->data[offset];
 }
@@ -191,7 +211,7 @@ static void genradix_free_recurse(struct genradix_node *n, 
unsigned level)
genradix_free_recurse(n->children[i], level - 
1);
}
 
-   free_page((unsigned long) n);
+   genradix_free_node(n);
 }
 
 int __genradix_prealloc(struct __genradix *radix, size_t size,
-- 
2.23.0

Re: [PATCH 4.4 00/99] 4.4.195-stable review

[kernelci.org bot]

stable-rc/linux-4.4.y boot: 90 boots: 1 failed, 80 passed with 8 offline, 1 
untried/unknown (v4.4.194-100-g9a8d8139a7e5)

Full Boot Summary: 
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.194-100-g9a8d8139a7e5/
Full Build Summary: 
https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.194-100-g9a8d8139a7e5/

Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.194-100-g9a8d8139a7e5
Git Commit: 9a8d8139a7e557ce81c19f467a2a873371e3deba
Git URL: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 45 unique boards, 17 SoC families, 12 builds out of 190

Boot Failure Detected:

arm64:
defconfig:
gcc-8:
qcom-qdf2400: 1 failed lab

Offline Platforms:

arm:

qcom_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab

davinci_all_defconfig:
gcc-8
dm365evm,legacy: 1 offline lab

sunxi_defconfig:
gcc-8
sun5i-r8-chip: 1 offline lab

multi_v7_defconfig:
gcc-8
qcom-apq8064-cm-qs600: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab
sun5i-r8-chip: 1 offline lab

arm64:

defconfig:
gcc-8
apq8016-sbc: 1 offline lab

---
For more info write to 

Re: [PATCH 1/3] regulator: core: fix boot-on regulators use_count usage

[Matti Vaittinen]

Hi dee Ho Peeps,

Long time no hear =)

On Tue, Oct 01, 2019 at 12:57:31PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Sep 27, 2019 at 1:47 AM Marco Felsch  wrote:
> > > > > > It should be possible to do a regulator_disable() though I'm not
> > > > > > sure anyone actually uses that.  The pattern for a regular
> > > > > > consumer should be the normal enable/disable pair to handle
> > > > > > shared usage, only an exclusive consumer should be able to use
> > > > > > just a straight disable.
> >
> > In my case it is a regulator-fixed which uses the enable/disable pair.
> > But as my descriptions says this will not work currently because boot-on
> > marked regulators can't be disabled right now (using the same logic as
> > always-on regulators).
> >

I was developing driver for yet-another ROHM PMIC when I hit the
phenomena you have been discussing here (I think) :) I used regulator-boot-on
flag from DT in my test setup and then did a test consumer who does

regulator_get()
regulator_enable()
regulator_disable() pair.

As this 'test consumer' was only user for the regulator I expected the
regulator to be disabled after call to regulator_disable. But it was
not.

It seems to me that the use_count is incremented for boot-on regulators
before first call to regulator_enable(). So when the consumer does first
regulator_enable() the use_count will actually go to 2. Hence the
corresponding regulator_disable() won't actually disable the regulator
even though the consumer is actually only known user.

I did unbalanced regulator_disable() - which does disable the regulator
but it also spills the warning.

I did instrument the regmap helpers and regulator_enable/disable to
dump out the actual i2c accesses and use_counts. Regulator enable prints
use_count _before_ incrementing it.


Check enable state after regulator_get (calls regulator_is_enabled)
root@arm:/sys/kernel/mva_test/regulators# cat buck3_en 
[  123.251499] dbg_regulator_is_enabled_regmap: called for 'buck3'
[  123.257524] regulator_is_enabled_regmap_dbg: Reading reg 0x1c
[  123.267386] regulator_is_enabled_regmap_dbg: read succeeded, val 0xe

Enable regulator by test consumer (no i2c access as regulator is on)
1root@arm:/sys/kernel/mva_test/regulators# echo 1 > buck3_en 
[  171.438524] Calling regulator_enable
[  171.446324] Enable requested, use-count 1

/* disable regulator by consumer */
root@arm:/sys/kernel/mva_test/regulators# echo 0 > buck3_en 

[  187.799956] Calling regulator_disable
[  187.805935] regulator disable requested, use-count 2, always-on 0

/* Unbalanced disble */
root@arm:/sys/kernel/mva_test/regulators# echo 0 > buck3_en 
[  207.832682] Calling regulator_disable
[  207.842949] regulator disable requested, use-count 1, always-on 0
[  207.849237] regulator do disable
[  207.852502] dbg_regulator_disable_regmap: called for 'buck3'
[  207.858272] regulator_disable_regmap_dbg: reg 0x1c mask 0x8 val 0x0, 
masked_val 0x0
[  207.909942] buck3: Underflow of regulator enable count
[  207.915189] Failed to toggle regulator state. error(-22)
bash: echo: write error: Invalid argument
root@arm:/sys/kernel/mva_test/regulators# 

> > > > > Ah, I see, I wasn't aware of the "exclusive" special case!  Marco: is
> > > > > this working for you?  I wonder if we need to match
> > > > > "regulator->enable_count" to "rdev->use_count" at the end of
> > > > > _regulator_get() in the exclusive case...
> >
> > So my fix isn't correct to fix this in general?
> 
> I don't think your fix is correct.  It sounds as if the intention of
> "regulator-boot-on" is to have the OS turn the regulator on at bootup
> and it keep an implicit reference until someone explicitly tells the
> OS to drop the reference.

Hmm.. What is the intended way to explicitly tell the OS to drop the
reference? I would assume we should still use same logic as with other
regulators - if last user calls regulator_disable() we should disable
the regulator? (I may not understand all this well enough though)
 
> > > > Yes, I think that case has been missed when adding the enable
> > > > counts - I've never actually had a system myself that made any
> > > > use of this stuff.  It probably needs an audit of the users to
> > > > make sure nobody's relying on the current behaviour though I
> > > > can't think how they would.
> > >
> > > Marco: I'm going to assume you'll tackle this since I don't actually
> > > have any use cases that need this.
> >
> > My use case is a simple regulator-fixed which is turned on by the
> > bootloader or to be more precise by the pmic-rom. To map that correctly
> > I marked this regulator as boot-on. Unfortunately as I pointed out above
> > this is handeld the same way as always-on.

Here I am again just a man in the middle as I am "only a component vendor"
and lack of complete system information. But I _think_ some of the users
of BD71827 and BD71847 PMICs do use setup where regulator-boot-

Re: [PATCH V6 2/3] mmc: mmci: add busy_complete callback

[Ulf Hansson]

On Thu, 5 Sep 2019 at 14:22, Ludovic Barre  wrote:
>
> From: Ludovic Barre 
>
> This patch adds busy_completion callback at mmci_host_ops
> to allow to define a specific busy completion by variant.
>
> The legacy code corresponding to busy completion used
> by ux500 variants is moved to ux500_busy_complete function.
>
> The busy_detect boolean property is replaced by
> busy_complete callback definition.

At this point I prefer to keep th busy_detect boolean property. It
makes the code a bit more consistent.

Although, I think in case busy_detect is set for the variant, the
variant also needs to assign the new ->busy_completion() callback. In
other words, we don't need to check for a valid callback in code if
busy_detect is set.

Otherwise, this looks good to me!

Kind regards
Uffe

>
> Signed-off-by: Ludovic Barre 
> ---
>  drivers/mmc/host/mmci.c | 142 +---
>  drivers/mmc/host/mmci.h |   3 +-
>  2 files changed, 76 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index c30319255dc2..e20164f4354d 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -44,6 +44,7 @@
>  #define DRIVER_NAME "mmci-pl18x"
>
>  static void mmci_variant_init(struct mmci_host *host);
> +static void ux500_variant_init(struct mmci_host *host);
>  static void ux500v2_variant_init(struct mmci_host *host);
>
>  static unsigned int fmax = 515633;
> @@ -175,7 +176,6 @@ static struct variant_data variant_ux500 = {
> .f_max  = 1,
> .signal_direction   = true,
> .pwrreg_clkgate = true,
> -   .busy_detect= true,
> .busy_dpsm_flag = MCI_DPSM_ST_BUSYMODE,
> .busy_detect_flag   = MCI_ST_CARDBUSY,
> .busy_detect_mask   = MCI_ST_BUSYENDMASK,
> @@ -184,7 +184,7 @@ static struct variant_data variant_ux500 = {
> .irq_pio_mask   = MCI_IRQ_PIO_MASK,
> .start_err  = MCI_STARTBITERR,
> .opendrain  = MCI_OD,
> -   .init   = mmci_variant_init,
> +   .init   = ux500_variant_init,
>  };
>
>  static struct variant_data variant_ux500v2 = {
> @@ -208,7 +208,6 @@ static struct variant_data variant_ux500v2 = {
> .f_max  = 1,
> .signal_direction   = true,
> .pwrreg_clkgate = true,
> -   .busy_detect= true,
> .busy_dpsm_flag = MCI_DPSM_ST_BUSYMODE,
> .busy_detect_flag   = MCI_ST_CARDBUSY,
> .busy_detect_mask   = MCI_ST_BUSYENDMASK,
> @@ -610,6 +609,67 @@ static u32 ux500v2_get_dctrl_cfg(struct mmci_host *host)
> return MCI_DPSM_ENABLE | (host->data->blksz << 16);
>  }
>
> +static bool ux500_busy_complete(struct mmci_host *host, u32 status, u32 
> err_msk)
> +{
> +   void __iomem *base = host->base;
> +
> +   /*
> +* Before unmasking for the busy end IRQ, confirm that the
> +* command was sent successfully. To keep track of having a
> +* command in-progress, waiting for busy signaling to end,
> +* store the status in host->busy_status.
> +*
> +* Note that, the card may need a couple of clock cycles before
> +* it starts signaling busy on DAT0, hence re-read the
> +* MMCISTATUS register here, to allow the busy bit to be set.
> +* Potentially we may even need to poll the register for a
> +* while, to allow it to be set, but tests indicates that it
> +* isn't needed.
> +*/
> +   if (!host->busy_status && !(status & err_msk) &&
> +   (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
> +   writel(readl(base + MMCIMASK0) |
> +  host->variant->busy_detect_mask,
> +  base + MMCIMASK0);
> +
> +   host->busy_status = status & (MCI_CMDSENT | MCI_CMDRESPEND);
> +   return false;
> +   }
> +
> +   /*
> +* If there is a command in-progress that has been successfully
> +* sent, then bail out if busy status is set and wait for the
> +* busy end IRQ.
> +*
> +* Note that, the HW triggers an IRQ on both edges while
> +* monitoring DAT0 for busy completion, but there is only one
> +* status bit in MMCISTATUS for the busy state. Therefore
> +* both the start and the end interrupts needs to be cleared,
> +* one after the other. So, clear the busy start IRQ here.
> +*/
> +   if (host->busy_status &&
> +   (status & host->variant->busy_detect_flag)) {
> +   writel(host->variant->busy_detect_mask, base + MMCICLEAR);
> +   return false;
> +   }
> +
> +   /*
> +* If there is a command in-progress that has been successfully
> +* sent and the busy bit isn't set, it means we have received
> +* the busy e

Re: linux-next: Fixes tag needs some work in the amdgpu tree

[S, Shirish]

Hi Stephen,


On 10/3/2019 3:41 AM, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
>8c9f69bc5cc4 ("drm/amdgpu: fix build error without CONFIG_HSA_AMD")
>
> Fixes tag
>
>Fixes: 1abb680ad371 ("drm/amdgpu: disable gfxoff while use no H/W 
> scheduling policy")
>
> has these problem(s):
>
>- Target SHA1 does not exist
>
> Did you mean
>
> Fixes: aa978594cf7f ("drm/amdgpu: disable gfxoff while use no H/W scheduling 
> policy")

Yes, I meant "aa978594cf7f".

Regards,

Shirish S

-- 
Regards,
Shirish S

Re: [PATCH] pwm: stm32: Fix the usage of uninitialized variable in stm32_pwm_config()

[Uwe Kleine-König]

Hello,

On Thu, Oct 03, 2019 at 09:46:49PM -0700, Yizhuo wrote:
> Inside function stm32_pwm_config(), variable "psc" and " arr"
> could be uninitialized if regmap_read() returns -EINVALs.
> However, they are used later in the if statement to decide
> the return value which is potentially unsafe.
> 
> The same case happens in function stm32_pwm_detect_channels()
> with variable "ccer", but we cannot just return -EINVAL because
> the error code is not acceptable by the caller. Aslo, the variable

s/Aslo/Also/

> "ccer" in functionstm32_pwm_detect_complementary() could also be

s/functionstm32_pwm_detect_/function stm32_pwm_detect_/

> uninitialized, since stm32_pwm_detect_complementary() returns void,
> the patch is not easy.

active_channels() is also affected. Also there are calls to
regmap_update_bits which should have their return values checked.

While a patch to fix these all is not trivial it is certainly possible
and I would prefer to fix the problem completely.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH V6 1/3] mmc: mmci: add hardware busy timeout feature

[Ulf Hansson]

On Fri, 4 Oct 2019 at 08:12, Ulf Hansson  wrote:
>
> On Thu, 5 Sep 2019 at 14:21, Ludovic Barre  wrote:
> >
> > From: Ludovic Barre 
> >
> > In some variants, the data timer starts and decrements
> > when the DPSM enters in Wait_R or Busy state
> > (while data transfer or MMC_RSP_BUSY), and generates a
> > data timeout error if the counter reach 0.
>
>
> >
> > -Define max_busy_timeout (in ms) according to clock.
> > -Set data timer register if the command has rsp_busy flag.
> >  If busy_timeout is not defined by framework, the busy
> >  length after Data Burst is defined as 1 second
> >  (refer: 4.6.2.2 Write of sd specification part1 v6-0).
>
> How about re-phrasing this as below:
>
> -
> In the stm32_sdmmc variant, the datatimer is active not only during
> data transfers with the DPSM, but also while waiting for the busyend
> IRQs from commands having the MMC_RSP_BUSY flag set. This leads to an
> incorrect IRQ being raised to signal MCI_DATATIMEOUT error, which
> simply breaks the behaviour.
>
> Address this by updating the datatimer value before sending a command
> having the MMC_RSP_BUSY flag set. To inform the mmc core about the
> maximum supported busy timeout, which also depends on the current
> clock rate, set ->max_busy_timeout (in ms).
> -
>
> Regarding the busy_timeout, the core should really assign it a value
> for all commands having the RSP_BUSY flag set. However, I realize the
> core needs to be improved to cover all these cases - and I am looking
> at that, but not there yet.
>
> I would also suggest to use a greater value than 1s, as that seems a
> bit low for the "undefined" case. Perhaps use the max_busy_timeout,
> which would be nice a simple or 10s, which I think is used by some
> other drivers.
>
> > -Add MCI_DATATIMEOUT error management in mmci_cmd_irq.
> >
> > Signed-off-by: Ludovic Barre 
> > ---
> >  drivers/mmc/host/mmci.c | 42 -
> >  drivers/mmc/host/mmci.h |  3 +++
> >  2 files changed, 40 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> > index c37e70dbe250..c30319255dc2 100644
> > --- a/drivers/mmc/host/mmci.c
> > +++ b/drivers/mmc/host/mmci.c
> > @@ -1075,6 +1075,7 @@ static void
> >  mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
> >  {
> > void __iomem *base = host->base;
> > +   unsigned long long clks;
> >
> > dev_dbg(mmc_dev(host->mmc), "op %02x arg %08x flags %08x\n",
> > cmd->opcode, cmd->arg, cmd->flags);
> > @@ -1097,6 +1098,16 @@ mmci_start_command(struct mmci_host *host, struct 
> > mmc_command *cmd, u32 c)
> > else
> > c |= host->variant->cmdreg_srsp;
> > }
> > +
> > +   if (host->variant->busy_timeout && cmd->flags & MMC_RSP_BUSY) {
> > +   if (!cmd->busy_timeout)
> > +   cmd->busy_timeout = 1000;
> > +
> > +   clks = (unsigned long long)cmd->busy_timeout * host->cclk;
> > +   do_div(clks, MSEC_PER_SEC);
> > +   writel_relaxed(clks, host->base + MMCIDATATIMER);
> > +   }
> > +
> > if (/*interrupt*/0)
> > c |= MCI_CPSM_INTERRUPT;
> >
> > @@ -1201,6 +1212,7 @@ static void
> >  mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> >  unsigned int status)
> >  {
> > +   u32 err_msk = MCI_CMDCRCFAIL | MCI_CMDTIMEOUT;
> > void __iomem *base = host->base;
> > bool sbc, busy_resp;
> >
> > @@ -1215,8 +1227,11 @@ mmci_cmd_irq(struct mmci_host *host, struct 
> > mmc_command *cmd,
> >  * handling. Note that we tag on any latent IRQs postponed
> >  * due to waiting for busy status.
> >  */
> > -   if (!((status|host->busy_status) &
> > - (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|MCI_CMDSENT|MCI_CMDRESPEND)))
> > +   if (host->variant->busy_timeout && busy_resp)
> > +   err_msk |= MCI_DATATIMEOUT;
> > +
> > +   if (!((status | host->busy_status) &
> > + (err_msk | MCI_CMDSENT | MCI_CMDRESPEND)))
> > return;
> >
> > /* Handle busy detection on DAT0 if the variant supports it. */
> > @@ -1235,8 +1250,7 @@ mmci_cmd_irq(struct mmci_host *host, struct 
> > mmc_command *cmd,
> >  * while, to allow it to be set, but tests indicates that it
> >  * isn't needed.
> >  */
> > -   if (!host->busy_status &&
> > -   !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
> > +   if (!host->busy_status && !(status & err_msk) &&
> > (readl(base + MMCISTATUS) & 
> > host->variant->busy_detect_flag)) {
> >
> > writel(readl(base + MMCIMASK0) |
> > @@ -1290,6 +1304,9 @@ mmci_cmd_irq(struct mmci_host *host, struct 
> > mmc_command *cmd,
> > cmd->error = -ETIMEDOUT;
> > } else if (status & MCI_CMDCRCFAIL && cmd->flags & MMC_

Re: [PATCH v1] base: soc: Handle custom soc information sysfs entries

[Stephen Boyd]

Quoting Bjorn Andersson (2019-10-03 22:50:57)
> On Thu 03 Oct 22:38 PDT 2019, Stephen Boyd wrote:
> 
> > Quoting Murali Nalajala (2019-10-03 16:51:50)
> > > @@ -151,14 +156,16 @@ struct soc_device *soc_device_register(struct 
> > > soc_device_attribute *soc_dev_attr
> > >  
> > > ret = device_register(&soc_dev->dev);
> > > if (ret)
> > > -   goto out3;
> > > +   goto out4;
> > >  
> > > return soc_dev;
> > >  
> > > -out3:
> > > +out4:
> > > ida_simple_remove(&soc_ida, soc_dev->soc_dev_num);
> > > put_device(&soc_dev->dev);
> > > soc_dev = NULL;
> > > +out3:
> > > +   kfree(soc_attr_groups);
> > 
> > This code is tricky. put_device(&soc_dev->dev) will call soc_release()
> > so we set soc_dev to NULL before calling kfree() on the error path. This
> > way we don't doubly free a pointer that the release function will take
> > care of. I wonder if the release function could free the ida as well,
> > and then we could just make the device_register() failure path call
> > put_device() and return ERR_PTR(ret) directly. Then the error path is
> > simpler because we can avoid changing two pointers to NULL to avoid the
> > double free twice. Or just inline the ida remove and put_device() call
> > in the if and then goto out1 to consolidate the error pointer
> > conversion.
> > 
> 
> But if we instead allocates the ida before the soc_dev, wouldn't the
> error path be something like?:
> 
> foo:
> put_device(&soc_dev->dev);
> bar:
> ida_simple_remove(&soc_ida, soc_num);
> return err;
> 
> 
> I think we still need two exit paths from soc_device_register()
> regardless of moving the ida_simple_remove() into the release, but we
> could drop it from the unregister(). So not sure if this is cleaner...
> 

It doesn't seem "safe" to let the number be reused before the device is
destroyed by put_device(). It would be clearer to do all the cleanup
from the release function so that the soc_device_unregister() path isn't
racy with another device being registered and reusing the same ID.

Of course this probably doesn't matter because the race I'm talking
about is extremely unlikely given there's only ever one soc device.
Reordering the put and remove would be fine too.

Re: [PATCH 5.3 000/344] 5.3.4-stable review

[Greg Kroah-Hartman]

On Thu, Oct 03, 2019 at 05:49:29PM -0600, shuah wrote:
> On 10/3/19 9:49 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.3.4 release.
> > There are 344 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 Sat 05 Oct 2019 03:37:47 PM UTC.
> > 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.3.4-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.3.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH V6 1/3] mmc: mmci: add hardware busy timeout feature

[Ulf Hansson]

On Thu, 5 Sep 2019 at 14:21, Ludovic Barre  wrote:
>
> From: Ludovic Barre 
>
> In some variants, the data timer starts and decrements
> when the DPSM enters in Wait_R or Busy state
> (while data transfer or MMC_RSP_BUSY), and generates a
> data timeout error if the counter reach 0.


>
> -Define max_busy_timeout (in ms) according to clock.
> -Set data timer register if the command has rsp_busy flag.
>  If busy_timeout is not defined by framework, the busy
>  length after Data Burst is defined as 1 second
>  (refer: 4.6.2.2 Write of sd specification part1 v6-0).

How about re-phrasing this as below:

-
In the stm32_sdmmc variant, the datatimer is active not only during
data transfers with the DPSM, but also while waiting for the busyend
IRQs from commands having the MMC_RSP_BUSY flag set. This leads to an
incorrect IRQ being raised to signal MCI_DATATIMEOUT error, which
simply breaks the behaviour.

Address this by updating the datatimer value before sending a command
having the MMC_RSP_BUSY flag set. To inform the mmc core about the
maximum supported busy timeout, which also depends on the current
clock rate, set ->max_busy_timeout (in ms).
-

Regarding the busy_timeout, the core should really assign it a value
for all commands having the RSP_BUSY flag set. However, I realize the
core needs to be improved to cover all these cases - and I am looking
at that, but not there yet.

I would also suggest to use a greater value than 1s, as that seems a
bit low for the "undefined" case. Perhaps use the max_busy_timeout,
which would be nice a simple or 10s, which I think is used by some
other drivers.

> -Add MCI_DATATIMEOUT error management in mmci_cmd_irq.
>
> Signed-off-by: Ludovic Barre 
> ---
>  drivers/mmc/host/mmci.c | 42 -
>  drivers/mmc/host/mmci.h |  3 +++
>  2 files changed, 40 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index c37e70dbe250..c30319255dc2 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -1075,6 +1075,7 @@ static void
>  mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
>  {
> void __iomem *base = host->base;
> +   unsigned long long clks;
>
> dev_dbg(mmc_dev(host->mmc), "op %02x arg %08x flags %08x\n",
> cmd->opcode, cmd->arg, cmd->flags);
> @@ -1097,6 +1098,16 @@ mmci_start_command(struct mmci_host *host, struct 
> mmc_command *cmd, u32 c)
> else
> c |= host->variant->cmdreg_srsp;
> }
> +
> +   if (host->variant->busy_timeout && cmd->flags & MMC_RSP_BUSY) {
> +   if (!cmd->busy_timeout)
> +   cmd->busy_timeout = 1000;
> +
> +   clks = (unsigned long long)cmd->busy_timeout * host->cclk;
> +   do_div(clks, MSEC_PER_SEC);
> +   writel_relaxed(clks, host->base + MMCIDATATIMER);
> +   }
> +
> if (/*interrupt*/0)
> c |= MCI_CPSM_INTERRUPT;
>
> @@ -1201,6 +1212,7 @@ static void
>  mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>  unsigned int status)
>  {
> +   u32 err_msk = MCI_CMDCRCFAIL | MCI_CMDTIMEOUT;
> void __iomem *base = host->base;
> bool sbc, busy_resp;
>
> @@ -1215,8 +1227,11 @@ mmci_cmd_irq(struct mmci_host *host, struct 
> mmc_command *cmd,
>  * handling. Note that we tag on any latent IRQs postponed
>  * due to waiting for busy status.
>  */
> -   if (!((status|host->busy_status) &
> - (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|MCI_CMDSENT|MCI_CMDRESPEND)))
> +   if (host->variant->busy_timeout && busy_resp)
> +   err_msk |= MCI_DATATIMEOUT;
> +
> +   if (!((status | host->busy_status) &
> + (err_msk | MCI_CMDSENT | MCI_CMDRESPEND)))
> return;
>
> /* Handle busy detection on DAT0 if the variant supports it. */
> @@ -1235,8 +1250,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command 
> *cmd,
>  * while, to allow it to be set, but tests indicates that it
>  * isn't needed.
>  */
> -   if (!host->busy_status &&
> -   !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
> +   if (!host->busy_status && !(status & err_msk) &&
> (readl(base + MMCISTATUS) & 
> host->variant->busy_detect_flag)) {
>
> writel(readl(base + MMCIMASK0) |
> @@ -1290,6 +1304,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command 
> *cmd,
> cmd->error = -ETIMEDOUT;
> } else if (status & MCI_CMDCRCFAIL && cmd->flags & MMC_RSP_CRC) {
> cmd->error = -EILSEQ;
> +   } else if (host->variant->busy_timeout && busy_resp &&
> +  status & MCI_DATATIMEOUT) {
> +   cmd->error = -ETIMEDOUT;

It's not really clear to me what happens with the busy detection
status 

Re: [PATCH] sched/fair: scale quota and period without losing quota/period ratio precision

[Greg KH]

On Thu, Oct 03, 2019 at 05:12:43PM -0700, Xuewei Zhang wrote:
> quota/period ratio is used to ensure a child task group won't get more
> bandwidth than the parent task group, and is calculated as:
> normalized_cfs_quota() = [(quota_us << 20) / period_us]
> 
> If the quota/period ratio was changed during this scaling due to
> precision loss, it will cause inconsistency between parent and child
> task groups. See below example:
> A userspace container manager (kubelet) does three operations:
> 1) Create a parent cgroup, set quota to 1,000us and period to 10,000us.
> 2) Create a few children cgroups.
> 3) Set quota to 1,000us and period to 10,000us on a child cgroup.
> 
> These operations are expected to succeed. However, if the scaling of
> 147/128 happens before step 3), quota and period of the parent cgroup
> will be changed:
> new_quota: 1148437ns, 1148us
> new_period: 11484375ns, 11484us
> 
> And when step 3) comes in, the ratio of the child cgroup will be 104857,
> which will be larger than the parent cgroup ratio (104821), and will
> fail.
> 
> Scaling them by a factor of 2 will fix the problem.
> 
> Fixes: 2e8e19226398 ("sched/fair: Limit sched_cfs_period_timer() loop to 
> avoid hard lockup")
> Signed-off-by: Xuewei Zhang 
> ---
>  kernel/sched/fair.c | 36 ++--
>  1 file changed, 22 insertions(+), 14 deletions(-)
> 



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

Re: [PATCH] qla2xxx: fix a potential NULL pointer dereference

[Martin Wilck]

On Wed, 2019-09-18 at 22:06 +0530, Allen Pais wrote:
> alloc_workqueue is not checked for errors and as a result,
> a potential NULL dereference could occur.
> 
> Signed-off-by: Allen Pais 
> ---
>  drivers/scsi/qla2xxx/qla_os.c | 4 
>  1 file changed, 4 insertions(+)

Reviewed-by: Martin Wilck 

Re: [PATCH v2 0/4] Enable Hantro G1 post-processor

[Tomasz Figa]

Hi Ezequiel,

On Fri, Oct 4, 2019 at 4:09 AM Ezequiel Garcia  wrote:
>
> Hi all,
>
> The Hantro G1 VPU post-processor block can be pipelined with
> the decoder hardware, allowing to perform operations such as
> color conversion, scaling, rotation, cropping, among others.
>
> When the post-processor is enabled, the decoder hardware
> gets its own set of NV12 buffers (the native decoder format),
> and the post-processor is the owner of the CAPTURE buffers.
>
> This allows the application get processed
> (scaled, converted, etc) buffers, completely transparently.
>
> This feature is implemented by exposing the post-processed pixel
> formats on ENUM_FMT. When the application sets a pixel format
> other than NV12, and if the post-processor is MC-linked,
> the driver will make use of it, transparently.
>
> On this v2, the media controller API is now required
> to "enable" (aka link, in topology jargon) the post-processor.
> Therefore, applications now have to explicitly request this feature.
>
> For instance, the post-processor is enabled using the media-ctl
> tool:
>
> media-ctl -l "'decoder':1 -> 'rockchip,rk3288-vpu-dec':0[0]"
> media-ctl -l "'postproc':1 -> 'rockchip,rk3288-vpu-dec':0[1]"
>
> v4l2-ctl -d 1 --list-formats
> ioctl: VIDIOC_ENUM_FMT
> Type: Video Capture Multiplanar
>
> [0]: 'NV12' (Y/CbCr 4:2:0)
> [1]: 'YUYV' (YUYV 4:2:2)
>
> Patches 1 and 2 are simply cleanups needed to easier integrate the
> post-processor. Patch 2 is a bit invasive, but it's a step
> forward towards merging the implementation for RK3399 and RK3288.
>
> Patch 3 re-works the media-topology, making the decoder
> a v4l2_subdevice, instead of a bare entity. This allows
> to introduce a more accurate of the decoder+post-processor complex.
>
> Patch 4 introduces the post-processing support.
>
> This is tested on RK3288 platforms with MPEG-2, VP8 and
> H264 streams, decoding to YUY2 surfaces. For now, this series
> is only adding support for NV12-to-YUY2 conversion.
>
> The design and implementation is quite different from v1:
>
> * The decoder->post-processor topology is now exposed
>   explicitly and applications need to configure the pipeline.
>   By default, the decoder is enabled and the post-processor
>   is disabled.
>

First of all, thanks for working on this. While from Chromium point of
view there isn't any practical use case for this feature, it could
possibly be valuable for some other platforms.

I still see a problem with the current design. Mem-to-mem decoders are
commonly used in a multi-instance fashion, but media topology is
global. That means that when having two applications on the system
decoding their own videos, one might be stepping on the other by
changing the topology.

I believe that if we want this to be really usable, we would need to
make the media topology per instance, but that's a significant change
to the media subsystem. Maybe we could pursue the other options I
suggested in the previous revision instead, like ordering the formats
returned by enum_fmt by native first and adding format flags that
would tell the userspace that the format can have some performance
and/or power penalty?

Best regards,
Tomasz

linux-next: Fixes tag needs some work in the kbuild-current tree

[Stephen Rothwell]

Hi all,

In commit

  b2b94fe85175 ("scripts/setlocalversion: clear local variable to make it work 
for sh")

Fixes tag

  Fixes: commit 858805b336be ("kbuild: add $(BASH) to run scripts with 
bash-extension")

has these problem(s):

  - leading word 'commit' unexpected

-- 
Cheers,
Stephen Rothwell


pgp8rEX2meQF7.pgp
Description: OpenPGP digital signature

linux-next: Tree for Oct 4

[Stephen Rothwell]

Hi all,

Changes since 20191003:

My fixes tree contains:

  04e6dac68d9b ("powerpc/64s/radix: fix for "tidy up TLB flushing code" and 
!CONFIG_PPC_RADIX_MMU")

The hid tree gained a build failure so I used the version from
next-20191003.

The drm-misc tree gained a conflict against the admgpu tree.

The rtc tree gained a build failure for which I have reverted a commit.

Non-merge commits (relative to Linus' tree): 1817
 2061 files changed, 52286 insertions(+), 23364 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 314 trees (counting Linus' and 78 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (cc3a7bfe62b9 vfs: Fix EOVERFLOW testing in 
put_compat_statfs64)
Merging fixes/master (04e6dac68d9b powerpc/64s/radix: fix for "tidy up TLB 
flushing code" and !CONFIG_PPC_RADIX_MMU)
Merging kbuild-current/fixes (d159d87700e9 namespace: fix namespace.pl script 
to support relative paths)
Merging arc-current/for-curr (41277ba7eb4e ARC: mm: tlb flush optim: elide 
redundant uTLB invalidates for MMUv3)
Merging arm-current/fixes (5b3efa4f1479 ARM: 8901/1: add a criteria for 
pfn_valid of arm)
Merging arm-soc-fixes/arm/fixes (bcec1221c945 Merge tag 
'omap-for-v5.4/fixes-rc1-signed' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging arm64-fixes/for-next/fixes (a2b99dcac36c docs: arm64: Fix indentation 
and doc formatting)
Merging m68k-current/for-linus (0f1979b402df m68k: Remove ioremap_fullcache())
Merging powerpc-fixes/fixes (253c892193ab powerpc/eeh: Fix eeh 
eeh_debugfs_break_device() with SRIOV devices)
Merging s390-fixes/fixes (9f494438d4bc s390/qdio: clarify size of the QIB parm 
area)
Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (3afb09618840 tcp: fix slab-out-of-bounds in 
tcp_zerocopy_receive())
Merging bpf/master (98beb3edeb97 samples/bpf: Add a workaround for asm_inline)
Merging ipsec/master (68ce6688a5ba net: sched: taprio: Fix potential integer 
overflow in taprio_set_picos_per_byte)
Merging netfilter/master (134cc4cefad3 net: stmmac: Avoid deadlock on 
suspend/resume)
Merging ipvs/master (34a4c95abd25 netfilter: nft_connlimit: disable bh on 
garbage collection)
Merging wireless-drivers/master (c91a9cfe9f6d rt2x00: initialize last_reset)
Merging mac80211/master (569aad4fcd82 net: ag71xx: fix mdio subnode support)
Merging rdma-fixes/for-rc (b66f31efbdad RDMA/iwcm: Fix a lock inversion issue)
Merging sound-current/for-linus (f41f900568d9 ALSA: usb-audio: Add DSD support 
for EVGA NU Audio)
Merging sound-asoc-fixes/for-linus (bbb90c4ed03b Merge branch 'asoc-5.4' into 
asoc-linus)
Merging regmap-fixes/for-linus (54ecb8f7028c Linux 5.4-rc1)
Merging regulator-fixes/for-linus (c3f1e312854c Merge branch 'regulator-5.4' 
into regulator-linus)
Merging spi-fixes/for-linus (6efab62559b1 Merge branch 'spi-5.4' into spi-linus)
Merging pci-current/for-linus (54ecb8f7028c Linux 5.4-rc1)
Merging driver-core.current/driver-core-linus (82af5b660967 sysfs: Fixes 
__BIN_ATTR_WO() macro)
Merging tty.current/tty-linus (54ecb8f7028c Linux 5.4-rc1)
Merging usb.current/usb-

Re: [PATCH v1] base: soc: Handle custom soc information sysfs entries

[Bjorn Andersson]

On Thu 03 Oct 22:38 PDT 2019, Stephen Boyd wrote:

> Quoting Murali Nalajala (2019-10-03 16:51:50)
> > @@ -151,14 +156,16 @@ struct soc_device *soc_device_register(struct 
> > soc_device_attribute *soc_dev_attr
> >  
> > ret = device_register(&soc_dev->dev);
> > if (ret)
> > -   goto out3;
> > +   goto out4;
> >  
> > return soc_dev;
> >  
> > -out3:
> > +out4:
> > ida_simple_remove(&soc_ida, soc_dev->soc_dev_num);
> > put_device(&soc_dev->dev);
> > soc_dev = NULL;
> > +out3:
> > +   kfree(soc_attr_groups);
> 
> This code is tricky. put_device(&soc_dev->dev) will call soc_release()
> so we set soc_dev to NULL before calling kfree() on the error path. This
> way we don't doubly free a pointer that the release function will take
> care of. I wonder if the release function could free the ida as well,
> and then we could just make the device_register() failure path call
> put_device() and return ERR_PTR(ret) directly. Then the error path is
> simpler because we can avoid changing two pointers to NULL to avoid the
> double free twice. Or just inline the ida remove and put_device() call
> in the if and then goto out1 to consolidate the error pointer
> conversion.
> 

But if we instead allocates the ida before the soc_dev, wouldn't the
error path be something like?:

foo:
put_device(&soc_dev->dev);
bar:
ida_simple_remove(&soc_ida, soc_num);
return err;


I think we still need two exit paths from soc_device_register()
regardless of moving the ida_simple_remove() into the release, but we
could drop it from the unregister(). So not sure if this is cleaner...

Regards,
Bjorn

> >  out2:
> > kfree(soc_dev);
> >  out1:

[PATCH] ARM: dts: vf610-zii-scu4-aib: Specify 'i2c-mux-idle-disconnect'

[Andrey Smirnov]

Specify 'i2c-mux-idle-disconnect' for both I2C switches present on the
board, since both are connected to the same parent bus and all of
their children have the same I2C address.

Fixes: ca4b4d373fcc ("ARM: dts: vf610: Add ZII SCU4 AIB board")
Signed-off-by: Andrey Smirnov 
Cc: Shawn Guo 
Cc: Chris Healy 
Cc: Cory Tusar 
Cc: Jeff White 
Cc: Rick Ramstetter 
Cc: Lucas Stach 
Cc: Fabio Estevam 
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Shawn:

If this is possible, I'd like this one to go into 5.4.

Thanks,
Andrey Smirnov

 arch/arm/boot/dts/vf610-zii-scu4-aib.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts 
b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
index dc8a5f37a1ef..c8ebb23c4e02 100644
--- a/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
+++ b/arch/arm/boot/dts/vf610-zii-scu4-aib.dts
@@ -602,6 +602,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
+   i2c-mux-idle-disconnect;
 
sff0_i2c: i2c@1 {
#address-cells = <1>;
@@ -640,6 +641,7 @@
reg = <0x71>;
#address-cells = <1>;
#size-cells = <0>;
+   i2c-mux-idle-disconnect;
 
sff5_i2c: i2c@1 {
#address-cells = <1>;
-- 
2.21.0

Re: [PATCH v1] base: soc: Handle custom soc information sysfs entries

[Stephen Boyd]

Quoting Murali Nalajala (2019-10-03 16:51:50)
> @@ -151,14 +156,16 @@ struct soc_device *soc_device_register(struct 
> soc_device_attribute *soc_dev_attr
>  
> ret = device_register(&soc_dev->dev);
> if (ret)
> -   goto out3;
> +   goto out4;
>  
> return soc_dev;
>  
> -out3:
> +out4:
> ida_simple_remove(&soc_ida, soc_dev->soc_dev_num);
> put_device(&soc_dev->dev);
> soc_dev = NULL;
> +out3:
> +   kfree(soc_attr_groups);

This code is tricky. put_device(&soc_dev->dev) will call soc_release()
so we set soc_dev to NULL before calling kfree() on the error path. This
way we don't doubly free a pointer that the release function will take
care of. I wonder if the release function could free the ida as well,
and then we could just make the device_register() failure path call
put_device() and return ERR_PTR(ret) directly. Then the error path is
simpler because we can avoid changing two pointers to NULL to avoid the
double free twice. Or just inline the ida remove and put_device() call
in the if and then goto out1 to consolidate the error pointer
conversion.

>  out2:
> kfree(soc_dev);
>  out1:

Re: memory leak in sctp_get_port_local (2)

[Eric Biggers]

On Fri, Aug 09, 2019 at 04:33:11PM +0800, Xin Long wrote:
> On Thu, Aug 8, 2019 at 11:01 PM syzbot
>  wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:0eb0ce0a Merge tag 'spi-fix-v5.3-rc3' of git://git.kernel...
> > git tree:   upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1234588c60
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=39113f5c48aea971
> > dashboard link: https://syzkaller.appspot.com/bug?extid=2d7ecdf99f15689032b3
> > compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=160e190660
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=140ab90660
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+2d7ecdf99f1568903...@syzkaller.appspotmail.com
> >
> > executing program
> > executing program
> > executing program
> > executing program
> > executing program
> > BUG: memory leak
> > unreferenced object 0x88810fa4b380 (size 64):
> >comm "syz-executor900", pid 7117, jiffies 4294946947 (age 16.560s)
> >hex dump (first 32 bytes):
> >  20 4e 00 00 89 e7 4c 8d 00 00 00 00 00 00 00 00   NL.
> >  58 40 dd 16 82 88 ff ff 00 00 00 00 00 00 00 00  X@..
> >backtrace:
> >  [] kmemleak_alloc_recursive
> > include/linux/kmemleak.h:43 [inline]
> >  [] slab_post_alloc_hook mm/slab.h:522 [inline]
> >  [] slab_alloc mm/slab.c:3319 [inline]
> >  [] kmem_cache_alloc+0x13f/0x2c0 mm/slab.c:3483
> >  [] sctp_bucket_create net/sctp/socket.c:8374 [inline]
> >  [] sctp_get_port_local+0x189/0x5b0
> > net/sctp/socket.c:8121
> >  [] sctp_do_bind+0xcc/0x1e0 net/sctp/socket.c:402
> >  [<2bf65239>] sctp_bind+0x44/0x70 net/sctp/socket.c:302
> >  [] inet_bind+0x40/0xc0 net/ipv4/af_inet.c:441
> >  [] __sys_bind+0x11c/0x140 net/socket.c:1647
> >  [<679cfe3c>] __do_sys_bind net/socket.c:1658 [inline]
> >  [<679cfe3c>] __se_sys_bind net/socket.c:1656 [inline]
> >  [<679cfe3c>] __x64_sys_bind+0x1e/0x30 net/socket.c:1656
> >  [<2aac3ac2>] do_syscall_64+0x76/0x1a0
> > arch/x86/entry/common.c:296
> >  [<0c38e074>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >
> > BUG: memory leak
> > unreferenced object 0x88810fa4b380 (size 64):
> >comm "syz-executor900", pid 7117, jiffies 4294946947 (age 19.260s)
> >hex dump (first 32 bytes):
> >  20 4e 00 00 89 e7 4c 8d 00 00 00 00 00 00 00 00   NL.
> >  58 40 dd 16 82 88 ff ff 00 00 00 00 00 00 00 00  X@..
> >backtrace:
> >  [] kmemleak_alloc_recursive
> > include/linux/kmemleak.h:43 [inline]
> >  [] slab_post_alloc_hook mm/slab.h:522 [inline]
> >  [] slab_alloc mm/slab.c:3319 [inline]
> >  [] kmem_cache_alloc+0x13f/0x2c0 mm/slab.c:3483
> >  [] sctp_bucket_create net/sctp/socket.c:8374 [inline]
> >  [] sctp_get_port_local+0x189/0x5b0
> > net/sctp/socket.c:8121
> >  [] sctp_do_bind+0xcc/0x1e0 net/sctp/socket.c:402
> >  [<2bf65239>] sctp_bind+0x44/0x70 net/sctp/socket.c:302
> >  [] inet_bind+0x40/0xc0 net/ipv4/af_inet.c:441
> >  [] __sys_bind+0x11c/0x140 net/socket.c:1647
> >  [<679cfe3c>] __do_sys_bind net/socket.c:1658 [inline]
> >  [<679cfe3c>] __se_sys_bind net/socket.c:1656 [inline]
> >  [<679cfe3c>] __x64_sys_bind+0x1e/0x30 net/socket.c:1656
> >  [<2aac3ac2>] do_syscall_64+0x76/0x1a0
> > arch/x86/entry/common.c:296
> >  [<0c38e074>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >
> > BUG: memory leak
> > unreferenced object 0x88810fa4b380 (size 64):
> >comm "syz-executor900", pid 7117, jiffies 4294946947 (age 21.990s)
> >hex dump (first 32 bytes):
> >  20 4e 00 00 89 e7 4c 8d 00 00 00 00 00 00 00 00   NL.
> >  58 40 dd 16 82 88 ff ff 00 00 00 00 00 00 00 00  X@..
> >backtrace:
> >  [] kmemleak_alloc_recursive
> > include/linux/kmemleak.h:43 [inline]
> >  [] slab_post_alloc_hook mm/slab.h:522 [inline]
> >  [] slab_alloc mm/slab.c:3319 [inline]
> >  [] kmem_cache_alloc+0x13f/0x2c0 mm/slab.c:3483
> >  [] sctp_bucket_create net/sctp/socket.c:8374 [inline]
> >  [] sctp_get_port_local+0x189/0x5b0
> > net/sctp/socket.c:8121
> >  [] sctp_do_bind+0xcc/0x1e0 net/sctp/socket.c:402
> >  [<2bf65239>] sctp_bind+0x44/0x70 net/sctp/socket.c:302
> >  [<

4*/5*: ppp0: recursion detected

[Udo van den Heuvel]

Hello,

To fix the 'ppp0: recursion detected' messages we see on our firewall I
found a solution at:

https://forum.openwrt.org/t/pptp-recursion-detected-system-reboot-itself/12585

Can we please implement this solution if deemed OK?


Kind regards,
Udo

[BUGFIX PATCH] selftests: Use real temporary working directory for archiving

[Masami Hiramatsu]

Use real temporary working directory for generating kselftest
archive.

tools/testing/selftests/kselftest directory has been used for
the temporary working directory for making a tar archive from
gen_kselftest_tar.sh, and it removes the directory for cleanup.

However, since the kselftest directory became a part of the
repository, it must not be used as a working dir.

Introduce mktemp to prepare a temporary working directory
for archiving kselftests.

Signed-off-by: Masami Hiramatsu 
---
 tools/testing/selftests/gen_kselftest_tar.sh |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/gen_kselftest_tar.sh 
b/tools/testing/selftests/gen_kselftest_tar.sh
index a27e2eec3586..eba1e9987ffc 100755
--- a/tools/testing/selftests/gen_kselftest_tar.sh
+++ b/tools/testing/selftests/gen_kselftest_tar.sh
@@ -38,16 +38,16 @@ main()
esac
fi
 
-   install_dir=./kselftest
+   tmpdir=`mktemp -d ./install-XX` || exit 1
 
 # Run install using INSTALL_KSFT_PATH override to generate install
 # directory
-./kselftest_install.sh
-tar $copts kselftest${ext} $install_dir
+./kselftest_install.sh $tmpdir
+tar $copts kselftest${ext} -C $tmpdir kselftest
 echo "Kselftest archive kselftest${ext} created!"
 
 # clean up install directory
-rm -rf kselftest
+rm -rf $tmpdir
 }
 
 main "$@"

Re: 4*/5*: ppp0: recursion detected

[Udo van den Heuvel]

On 04-10-2019 06:57, Udo van den Heuvel wrote:
> To fix the 'ppp0: recursion detected' messages we see on our firewall I
> found a solution at:
> 
> https://forum.openwrt.org/t/pptp-recursion-detected-system-reboot-itself/12585
> 
> Can we please implement this solution if deemed OK?

Or perhaps this variant:
https://bugzilla.kernel.org/show_bug.cgi?id=199109 which does not appear
to be implemented in 4.19 yet...


Udo

[GIT PULL] xen: fixes and cleanups for 5.4-rc2

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.4-rc2-tag

xen: fixes and cleanups for 5.4-rc2

It contains the following patches:

- a fix in the Xen balloon driver avoiding hitting a BUG_ON() in some
  cases, plus a follow-on cleanup series for that driver

- a patch for introducing non-blocking EFI callbacks in Xen's EFI driver,
  plu a cleanup patch for Xen EFI handling merging the x86 and ARM arch
  specific initialization into the Xen EFI driver

- a fix of the Xen xenbus driver avoiding a self-deadlock when cleaning
  up after a user process has died

- a fix for Xen on ARM after removal of ZONE_DMA

- a cleanup patch for avoiding build warnings for Xen on ARM


Thanks.

Juergen

 arch/arm/include/asm/xen/xen-ops.h   |  6 ---
 arch/arm/xen/Makefile|  1 -
 arch/arm/xen/efi.c   | 28 ---
 arch/arm/xen/enlighten.c |  3 +-
 arch/arm/xen/mm.c|  5 +-
 arch/arm64/include/asm/xen/xen-ops.h |  7 ---
 arch/arm64/xen/Makefile  |  1 -
 arch/x86/xen/efi.c   | 14 +-
 drivers/xen/balloon.c| 24 +++--
 drivers/xen/efi.c| 84 ++--
 drivers/xen/xenbus/xenbus_dev_frontend.c | 20 +++-
 include/xen/xen-ops.h| 25 +-
 12 files changed, 79 insertions(+), 139 deletions(-)

David Hildenbrand (4):
  xen/balloon: Set pages PageOffline() in balloon_add_region()
  xen/balloon: Drop __balloon_append()
  xen/balloon: Mark pages PG_offline in balloon_append()
  xen/balloon: Clear PG_offline in balloon_retrieve()

Juergen Gross (2):
  xen/efi: have a common runtime setup function
  xen/xenbus: fix self-deadlock after killing user process

Peng Fan (1):
  arm: xen: mm: use __GPF_DMA32 for arm64

Ross Lagerwall (1):
  xen/efi: Set nonblocking callbacks

Stefano Stabellini (1):
  ARM: xen: unexport HYPERVISOR_platform_op function

Re: nsdeps not working on modules in 5.4-rc1

[Steve French]

ok - so to sum up, it sounds like you are saying the 350 false
positives (see attached file) that happen on building cifs.ko .will be
fixed by a
future change to modpost?  This is  a typical module build ...
download and install current kernel package (in this case Ubuntu
5.4-rc1). which saves huge amount of build time, then build just the
module of interest (in my case cifs.ko)

   cd fs/cifs
   make C=1 -C /usr/src/linux-headers-`uname -r` M=`pwd` modules

If nsdeps is not needed to fixup some namespace issue then shouldn't
be a problem, just trying to avoid the distraction of 300+
warning messages every time I build just this one module.  Is there a
workaround?

On Thu, Oct 3, 2019 at 11:51 PM Masahiro Yamada
 wrote:
>
> Hi Steve,
>
> On Fri, Oct 4, 2019 at 1:28 PM Steve French  wrote:
> >
> > On Thu, Oct 3, 2019 at 10:41 PM Masahiro Yamada
> >  wrote:
> > >
> > > Hi Steve,
> > >
> > > On Fri, Oct 4, 2019 at 1:07 AM Steve French  wrote:
> > > >
> > > > On Thu, Oct 3, 2019 at 10:24 AM Masahiro Yamada
> > > >  wrote:
> > > > >
> > > > > Hi Steve,
> > > > >
> > > > > On Fri, Oct 4, 2019 at 12:15 AM Steve French  
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Oct 3, 2019 at 5:43 AM Matthias Maennich 
> > > > > >  wrote:
> > > > > > >
> > > > > > > Hi Steve!
> > > > > > >
> > > > > > > On Wed, Oct 02, 2019 at 06:54:26PM -0500, Steve French wrote:
> > > > > > > >And running the build differently, from the root of the git tree
> > > > > > > >(5.4-rc1) rather than using the Ubuntu 5.4-rc1 headers also fails
> > > > > > > >
> > > > > > > >e.g. "make  M=fs/cifs modules nsdeps"
> > > > > > > >
> > > > > > > >...
> > > > > > > >  LD [M]  fs/cifs/cifs.o
> > > > > > > >  Building modules, stage 2.
> > > > > > > >  MODPOST 1 modules
> > > > > > > >WARNING: module cifs uses symbol sigprocmask from namespace
> > > > > > > >_fs/cifs/cache.o), but does not import it.
> > > > > > > >...
> > > > > > > >WARNING: module cifs uses symbol posix_test_lock from namespace
> > > > > > > >cifs/cache.o), but does not import it.
> > > > > > > >  CC [M]  fs/cifs/cifs.mod.o
> > > > > > > >  LD [M]  fs/cifs/cifs.ko
> > > > > > > >  Building modules, stage 2.
> > > > > > > >  MODPOST 1 modules
> > > > > > > >./scripts/nsdeps: 34: local: ./fs/cifs/cifsfs.c: bad variable 
> > > > > > > >name
> > > > > > > >make: *** [Makefile:1710: nsdeps] Error 2
> > > > > > >
> > > > > > > Thanks for reporting this. It appears to me you hit a bug that was
> > > > > > > recently discovered: when building with `make 
> > > > > > > M=some/subdirectory`,
> > > > > > > modpost is misbehaving. Can you try whether this patch series 
> > > > > > > solves
> > > > > > > your problems:
> > > > > > > https://lore.kernel.org/lkml/20191003075826.7478-1-yamada.masah...@socionext.com/
> > > > > > > In particular patch 2/6 out of the series.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Matthias
> > > > > >
> > > > > >
> > > > > > Applying just patch 2 and doing "make" from the root of the git tree
> > > > > > (5.4-rc1), at the tail end of the build I got
> > > > > >
> > > > > > ...
> > > > > > Kernel: arch/x86/boot/bzImage is ready  (#87)
> > > > > >   Building modules, stage 2.
> > > > > >   MODPOST 5340 modules
> > > > > > free(): invalid pointer
> > > > > > Aborted (core dumped)
> > > > >
> > > > >
> > > > > Right.
> > > > >
> > > > > Since 2/6 depends on 1/6,
> > > > > applying only the second one does not work.
> > > >
> > > > Applying both 1 and 2 I get the following error doing make (although
> > > > it makes it a long way into the build)
> > > >
> > > > 
> > > > WARNING: drivers/usb/storage/usb-storage: 'USB_STORAGE' exported
> > > > twice. Previous export was in drivers/usb/storage/usb-storage.ko
> > > > ERROR: "usb_stor_set_xfer_buf" [drivers/usb/storage/ums-usbat.ko] 
> > > > undefined!
> > > > ERROR: "usb_stor_access_xfer_buf" [drivers/usb/storage/ums-usbat.ko] 
> > > > undefined!
> > > > ERROR: "usb_stor_post_reset" [drivers/usb/storage/ums-usbat.ko] 
> > > > undefined!
> > > > ERROR: "usb_stor_disconnect" [drivers/usb/storage/ums-usbat.ko] 
> > > > undefined!
> > > > 
> > > > ERROR: "usb_stor_adjust_quirks" [drivers/usb/storage/uas.ko] undefined!
> > > > ERROR: "usb_stor_sense_invalidCDB" [drivers/usb/storage/uas.ko] 
> > > > undefined!
> > > > WARNING: "USB_STORAGE" [drivers/usb/storage/usb-storage] is a static
> > > > EXPORT_SYMBOL_GPL
> > > > make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
> > > > make: *** [Makefile:1303: modules] Error 2
> > >
> > >
> > > Hmm, I do not see those error.
> > > I was able to build the kernel successfully.
> > > (I asked the 0-day bot to test whole of my patch set
> > > in case I am missing something.)
> > >
> > >
> > > Could you share the steps to reproduce the errors and your .config file?
> >
> > From the root of git tree - at exactly 5.4-rc1
> >
> > ~/cifs-2.6$ make nsdeps
> >   CALLscripts/checksyscalls.sh
> >   CALLscripts/atomic/check-atomics.sh
> >   DESC

Potential uninitialized variables in regulator: ltc3589

[Yizhuo Zhai]

Hi All:

drivers/regulator/ltc3589.c

Variable "irqstat" in function ltc3589_isr() could be uninitialized if
regmap_read() returns -EINVAL. But it's directly used later without
the return check, which is potentially unsafe.

Also, we cannot simply return -EINVAL in ltc3589_isr() because
the error code is out of the return type: irqreturn_t.

Thanks for your time to check this case.

-- 
Kind Regards,

Yizhuo Zhai

Computer Science, Graduate Student
University of California, Riverside

Potential uninitialized variables in pwm: stm32-lp

[Yizhuo Zhai]

Hi All:

drivers/pwm/pwm-stm32-lp.c:

Variable "val" and "prd" in function stm32_pwm_lp_get_state() could be
uninitialized
if regmap_read() returns -EINVAL. But it's directly used later without
the return check,
which is potentially unsafe.

Also, we cannot simply return -EINVAL in stm32_pwm_lp_get_state() because the
return type is void.

Thanks for your time to check this case.
-- 
Kind Regards,

Yizhuo Zhai

Computer Science, Graduate Student
University of California, Riverside

[PATCH] net/velocity: fix -Wunused-but-set-variable warnings

[Austin Kim]

'curr_status' is declared as u32.
But this variable is not used after below statement.
   curr_status = vptr->mii_status & (~VELOCITY_LINK_FAIL);

This variable could be dropped to mute below warning message:

   drivers/net/ethernet/via/via-velocity.c:868:6:
   warning: variable ‘curr_status’ set but not used 
   [-Wunused-but-set-variable]

Signed-off-by: Austin Kim 
---
 drivers/net/ethernet/via/via-velocity.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/via/via-velocity.c 
b/drivers/net/ethernet/via/via-velocity.c
index 346e441..36d402c 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -865,11 +865,9 @@ static u32 check_connection_type(struct mac_regs __iomem 
*regs)
  */
 static int velocity_set_media_mode(struct velocity_info *vptr, u32 mii_status)
 {
-   u32 curr_status;
struct mac_regs __iomem *regs = vptr->mac_regs;
 
vptr->mii_status = mii_check_media_mode(vptr->mac_regs);
-   curr_status = vptr->mii_status & (~VELOCITY_LINK_FAIL);
 
/* Set mii link status */
set_mii_flow_control(vptr);
-- 
2.6.2

Re: nsdeps not working on modules in 5.4-rc1

[Masahiro Yamada]

Hi Steve,

On Fri, Oct 4, 2019 at 1:28 PM Steve French  wrote:
>
> On Thu, Oct 3, 2019 at 10:41 PM Masahiro Yamada
>  wrote:
> >
> > Hi Steve,
> >
> > On Fri, Oct 4, 2019 at 1:07 AM Steve French  wrote:
> > >
> > > On Thu, Oct 3, 2019 at 10:24 AM Masahiro Yamada
> > >  wrote:
> > > >
> > > > Hi Steve,
> > > >
> > > > On Fri, Oct 4, 2019 at 12:15 AM Steve French  wrote:
> > > > >
> > > > > On Thu, Oct 3, 2019 at 5:43 AM Matthias Maennich 
> > > > >  wrote:
> > > > > >
> > > > > > Hi Steve!
> > > > > >
> > > > > > On Wed, Oct 02, 2019 at 06:54:26PM -0500, Steve French wrote:
> > > > > > >And running the build differently, from the root of the git tree
> > > > > > >(5.4-rc1) rather than using the Ubuntu 5.4-rc1 headers also fails
> > > > > > >
> > > > > > >e.g. "make  M=fs/cifs modules nsdeps"
> > > > > > >
> > > > > > >...
> > > > > > >  LD [M]  fs/cifs/cifs.o
> > > > > > >  Building modules, stage 2.
> > > > > > >  MODPOST 1 modules
> > > > > > >WARNING: module cifs uses symbol sigprocmask from namespace
> > > > > > >_fs/cifs/cache.o), but does not import it.
> > > > > > >...
> > > > > > >WARNING: module cifs uses symbol posix_test_lock from namespace
> > > > > > >cifs/cache.o), but does not import it.
> > > > > > >  CC [M]  fs/cifs/cifs.mod.o
> > > > > > >  LD [M]  fs/cifs/cifs.ko
> > > > > > >  Building modules, stage 2.
> > > > > > >  MODPOST 1 modules
> > > > > > >./scripts/nsdeps: 34: local: ./fs/cifs/cifsfs.c: bad variable name
> > > > > > >make: *** [Makefile:1710: nsdeps] Error 2
> > > > > >
> > > > > > Thanks for reporting this. It appears to me you hit a bug that was
> > > > > > recently discovered: when building with `make M=some/subdirectory`,
> > > > > > modpost is misbehaving. Can you try whether this patch series solves
> > > > > > your problems:
> > > > > > https://lore.kernel.org/lkml/20191003075826.7478-1-yamada.masah...@socionext.com/
> > > > > > In particular patch 2/6 out of the series.
> > > > > >
> > > > > > Cheers,
> > > > > > Matthias
> > > > >
> > > > >
> > > > > Applying just patch 2 and doing "make" from the root of the git tree
> > > > > (5.4-rc1), at the tail end of the build I got
> > > > >
> > > > > ...
> > > > > Kernel: arch/x86/boot/bzImage is ready  (#87)
> > > > >   Building modules, stage 2.
> > > > >   MODPOST 5340 modules
> > > > > free(): invalid pointer
> > > > > Aborted (core dumped)
> > > >
> > > >
> > > > Right.
> > > >
> > > > Since 2/6 depends on 1/6,
> > > > applying only the second one does not work.
> > >
> > > Applying both 1 and 2 I get the following error doing make (although
> > > it makes it a long way into the build)
> > >
> > > 
> > > WARNING: drivers/usb/storage/usb-storage: 'USB_STORAGE' exported
> > > twice. Previous export was in drivers/usb/storage/usb-storage.ko
> > > ERROR: "usb_stor_set_xfer_buf" [drivers/usb/storage/ums-usbat.ko] 
> > > undefined!
> > > ERROR: "usb_stor_access_xfer_buf" [drivers/usb/storage/ums-usbat.ko] 
> > > undefined!
> > > ERROR: "usb_stor_post_reset" [drivers/usb/storage/ums-usbat.ko] undefined!
> > > ERROR: "usb_stor_disconnect" [drivers/usb/storage/ums-usbat.ko] undefined!
> > > 
> > > ERROR: "usb_stor_adjust_quirks" [drivers/usb/storage/uas.ko] undefined!
> > > ERROR: "usb_stor_sense_invalidCDB" [drivers/usb/storage/uas.ko] undefined!
> > > WARNING: "USB_STORAGE" [drivers/usb/storage/usb-storage] is a static
> > > EXPORT_SYMBOL_GPL
> > > make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
> > > make: *** [Makefile:1303: modules] Error 2
> >
> >
> > Hmm, I do not see those error.
> > I was able to build the kernel successfully.
> > (I asked the 0-day bot to test whole of my patch set
> > in case I am missing something.)
> >
> >
> > Could you share the steps to reproduce the errors and your .config file?
>
> From the root of git tree - at exactly 5.4-rc1
>
> ~/cifs-2.6$ make nsdeps
>   CALLscripts/checksyscalls.sh
>   CALLscripts/atomic/check-atomics.sh
>   DESCEND  objtool
>   CHK include/generated/compile.h
>   CHK kernel/kheaders_data.tar.xz
>   Building modules, stage 2.
>   MODPOST 5340 modules
>   Building modules, stage 2.
>   MODPOST 5340 modules
> ./scripts/nsdeps: 34: local: ./fs/cifs/cifsfs.c: bad variable name
> make: *** [Makefile:1710: nsdeps] Error 2
>
> I get the same error doing "rm fs/cifs/*.o" and repeating the "make
> nsdeps" command
>
> I will send you the .config



You need to clarify your problem.

In the first post from you, you pointed out
"hundreds of new warnings introduced by namespaces in 5.4-rc1 when
building my module"

So, 1/6 and 2/6 should address that problem.
https://lore.kernel.org/patchwork/patch/1133628/
https://lore.kernel.org/patchwork/patch/1133626/


Then, in the previous email ("Applying both 1 and 2 I get the
following error doing make")
it looks like you were talking about in-kernel building
instead of the external module.


Then, in this email, you are talking about "make nsdeps".
"make nsdeps" obviously does not support M=.


I am afraid you are 

[PATCH] pwm: stm32: Fix the usage of uninitialized variable in stm32_pwm_config()

[Yizhuo]

Inside function stm32_pwm_config(), variable "psc" and " arr"
could be uninitialized if regmap_read() returns -EINVALs.
However, they are used later in the if statement to decide
the return value which is potentially unsafe.

The same case happens in function stm32_pwm_detect_channels()
with variable "ccer", but we cannot just return -EINVAL because
the error code is not acceptable by the caller. Aslo, the variable
"ccer" in functionstm32_pwm_detect_complementary() could also be
uninitialized, since stm32_pwm_detect_complementary() returns void,
the patch is not easy.

Signed-off-by: Yizhuo 
---
 drivers/pwm/pwm-stm32.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 359b08596d9e..22c54df52977 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -346,9 +346,15 @@ static int stm32_pwm_config(struct stm32_pwm *priv, int ch,
 */
if (active_channels(priv) & ~(1 << ch * 4)) {
u32 psc, arr;
+   int ret;
 
-   regmap_read(priv->regmap, TIM_PSC, &psc);
-   regmap_read(priv->regmap, TIM_ARR, &arr);
+   ret = regmap_read(priv->regmap, TIM_PSC, &psc);
+   if (ret)
+   return ret;
+
+   ret = regmap_read(priv->regmap, TIM_ARR, &arr);
+   if (ret)
+   return ret;
 
if ((psc != prescaler) || (arr != prd - 1))
return -EBUSY;
-- 
2.17.1

Re: [PATCH] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y

[Walter Wu]

On Thu, 2019-10-03 at 16:53 +0200, Dmitry Vyukov wrote:
> On Thu, Oct 3, 2019 at 3:51 PM Walter Wu  wrote:>
> > how about this?
> >
> > commit fd64691026e7ccb8d2946d0804b0621ac177df38
> > Author: Walter Wu 
> > Date:   Fri Sep 27 09:54:18 2019 +0800
> >
> > kasan: detect invalid size in memory operation function
> >
> > It is an undefined behavior to pass a negative value to
> > memset()/memcpy()/memmove()
> > , so need to be detected by KASAN.
> >
> > KASAN report:
> >
> >  BUG: KASAN: invalid size 18446744073709551614 in
> > kmalloc_memmove_invalid_size+0x70/0xa0
> >
> >  CPU: 1 PID: 91 Comm: cat Not tainted
> > 5.3.0-rc1ajb-1-g31943bbc21ce-dirty #7
> >  Hardware name: linux,dummy-virt (DT)
> >  Call trace:
> >   dump_backtrace+0x0/0x278
> >   show_stack+0x14/0x20
> >   dump_stack+0x108/0x15c
> >   print_address_description+0x64/0x368
> >   __kasan_report+0x108/0x1a4
> >   kasan_report+0xc/0x18
> >   check_memory_region+0x15c/0x1b8
> >   memmove+0x34/0x88
> >   kmalloc_memmove_invalid_size+0x70/0xa0
> >
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=199341
> >
> > Signed-off-by: Walter Wu 
> > Reported-by: Dmitry Vyukov 
> >
> > diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> > index b63b367a94e8..e4e517a51860 100644
> > --- a/lib/test_kasan.c
> > +++ b/lib/test_kasan.c
> > @@ -280,6 +280,23 @@ static noinline void __init
> > kmalloc_oob_in_memset(void)
> > kfree(ptr);
> >  }
> >
> > +static noinline void __init kmalloc_memmove_invalid_size(void)
> > +{
> > +   char *ptr;
> > +   size_t size = 64;
> > +
> > +   pr_info("invalid size in memmove\n");
> > +   ptr = kmalloc(size, GFP_KERNEL);
> > +   if (!ptr) {
> > +   pr_err("Allocation failed\n");
> > +   return;
> > +   }
> > +
> > +   memset((char *)ptr, 0, 64);
> > +   memmove((char *)ptr, (char *)ptr + 4, -2);
> > +   kfree(ptr);
> > +}
> > +
> >  static noinline void __init kmalloc_uaf(void)
> >  {
> > char *ptr;
> > @@ -734,6 +751,7 @@ static int __init kmalloc_tests_init(void)
> > kmalloc_oob_memset_4();
> > kmalloc_oob_memset_8();
> > kmalloc_oob_memset_16();
> > +   kmalloc_memmove_invalid_size;
> > kmalloc_uaf();
> > kmalloc_uaf_memset();
> > kmalloc_uaf2();
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 2277b82902d8..5fd377af7457 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -102,7 +102,8 @@ EXPORT_SYMBOL(__kasan_check_write);
> >  #undef memset
> >  void *memset(void *addr, int c, size_t len)
> >  {
> > -   check_memory_region((unsigned long)addr, len, true, _RET_IP_);
> > +   if(!check_memory_region((unsigned long)addr, len, true, _RET_IP_))
> > +   return NULL;
> 
> Overall approach looks good to me.
> A good question is what we should return here. All bets are off after
> a report, but we still try to "minimize damage". One may argue for
> returning addr here and in other functions. But the more I think about
> this, the more I think it does not matter.
> 
agreed

> 
> > return __memset(addr, c, len);
> >  }
> > @@ -110,7 +111,8 @@ void *memset(void *addr, int c, size_t len)
> >  #undef memmove
> >  void *memmove(void *dest, const void *src, size_t len)
> >  {
> > -   check_memory_region((unsigned long)src, len, false, _RET_IP_);
> > +   if(!check_memory_region((unsigned long)src, len, false, _RET_IP_))
> > +   return NULL;
> > check_memory_region((unsigned long)dest, len, true, _RET_IP_);
> >
> > return __memmove(dest, src, len);
> > @@ -119,7 +121,8 @@ void *memmove(void *dest, const void *src, size_t
> > len)
> >  #undef memcpy
> >  void *memcpy(void *dest, const void *src, size_t len)
> >  {
> > -   check_memory_region((unsigned long)src, len, false, _RET_IP_);
> > +   if(!check_memory_region((unsigned long)src, len, false, _RET_IP_))
> > +   return NULL;
> > check_memory_region((unsigned long)dest, len, true, _RET_IP_);
> >
> > return __memcpy(dest, src, len);
> > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > index 616f9dd82d12..02148a317d27 100644
> > --- a/mm/kasan/generic.c
> > +++ b/mm/kasan/generic.c
> > @@ -173,6 +173,11 @@ static __always_inline bool
> > check_memory_region_inline(unsigned long addr,
> > if (unlikely(size == 0))
> > return true;
> >
> > +   if (unlikely((long)size < 0)) {
> > +   kasan_report(addr, size, write, ret_ip);
> > +   return false;
> > +   }
> > +
> > if (unlikely((void *)addr <
> > kasan_shadow_to_mem((void *)KASAN_SHADOW_START))) {
> > kasan_report(addr, size, write, ret_ip);
> > diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> > index 0e5f965f1882..0cd317ef30f5 100644
> > --- a/mm/kasan/report.c
> > +++ b/mm/kasan/report.c
> > @@ -68,1

linux-next: build failure after merge of the rtc tree

[Stephen Rothwell]

Hi all,

After merging the rtc tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/rtc/rtc-mc146818-lib.c: In function 'mc146818_set_time':
drivers/rtc/rtc-mc146818-lib.c:176:6: error: 'boot_cpu_data' undeclared (first 
use in this function); did you mean 'bootmem_data'?
  176 |  if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
  |  ^
  |  bootmem_data
drivers/rtc/rtc-mc146818-lib.c:176:6: note: each undeclared identifier is 
reported only once for each function it appears in
drivers/rtc/rtc-mc146818-lib.c:176:34: error: 'X86_VENDOR_AMD' undeclared 
(first use in this function); did you mean 'X86_VENDOR_ANY'?
  176 |  if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
  |  ^~
  |  X86_VENDOR_ANY
drivers/rtc/rtc-mc146818-lib.c:177:34: error: 'X86_VENDOR_HYGON' undeclared 
(first use in this function); did you mean 'X86_VENDOR_ANY'?
  177 |  boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
  |  ^~~~
  |  X86_VENDOR_ANY

Caused by commit

  1e2c8aadedbe ("rtc: cmos: fix the AltCentury value on AMD/Hygon platform")

This driver file is built for several different architecture, but
the added code is X86 specific :-(

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell


pgp5I6MXvm5fz.pgp
Description: OpenPGP digital signature

Re: [PATCH v2] x86/xen: Return from panic notifier

[Jürgen Groß]

On 03.10.19 20:12, Boris Ostrovsky wrote:

Currently execution of panic() continues until Xen's panic notifier
(xen_panic_event()) is called at which point we make a hypercall that
never returns.

This means that any notifier that is supposed to be called later as
well as significant part of panic() code (such as pstore writes from
kmsg_dump()) is never executed.

There is no reason for xen_panic_event() to be this last point in
execution since panic()'s emergency_restart() will call into
xen_emergency_restart() from where we can perform our hypercall.

Nevertheless, we will provide xen_legacy_crash boot option that will
preserve original behavior during crash. This option could be used,
for example, if running kernel dumper (which happens after panic
notifiers) is undesirable.

Reported-by: James Dingwall 
Signed-off-by: Boris Ostrovsky 


Reviewed-by: Juergen Gross 


Juergen

Re: [PATCHv3 RESEND-next 0/3] Odroid c2 missing regulator linking

[Anand Moon]

Hi Kevin,

On Thu, 3 Oct 2019 at 23:14, Kevin Hilman  wrote:
>
> Anand Moon  writes:
>
> > Looks like this changes got lost so resend these changes again.
>
> Yeah, sorry about that.  Your cover letter subjects were quite similar,
> and several versions of this series and the previoius series arrived
> close together, so some stuff fell through the cracks.  Sorry about
> that.
I will keep this in my mind and do not repeat my silly mistakes.

>
> Queued for v5.5 now,
>
> Thanks,
No worries, thanks for the update!

>
> Kevin

Best Regards
-Anand

Re: nsdeps not working on modules in 5.4-rc1

[Steve French]

On Thu, Oct 3, 2019 at 10:41 PM Masahiro Yamada
 wrote:
>
> Hi Steve,
>
> On Fri, Oct 4, 2019 at 1:07 AM Steve French  wrote:
> >
> > On Thu, Oct 3, 2019 at 10:24 AM Masahiro Yamada
> >  wrote:
> > >
> > > Hi Steve,
> > >
> > > On Fri, Oct 4, 2019 at 12:15 AM Steve French  wrote:
> > > >
> > > > On Thu, Oct 3, 2019 at 5:43 AM Matthias Maennich  
> > > > wrote:
> > > > >
> > > > > Hi Steve!
> > > > >
> > > > > On Wed, Oct 02, 2019 at 06:54:26PM -0500, Steve French wrote:
> > > > > >And running the build differently, from the root of the git tree
> > > > > >(5.4-rc1) rather than using the Ubuntu 5.4-rc1 headers also fails
> > > > > >
> > > > > >e.g. "make  M=fs/cifs modules nsdeps"
> > > > > >
> > > > > >...
> > > > > >  LD [M]  fs/cifs/cifs.o
> > > > > >  Building modules, stage 2.
> > > > > >  MODPOST 1 modules
> > > > > >WARNING: module cifs uses symbol sigprocmask from namespace
> > > > > >_fs/cifs/cache.o), but does not import it.
> > > > > >...
> > > > > >WARNING: module cifs uses symbol posix_test_lock from namespace
> > > > > >cifs/cache.o), but does not import it.
> > > > > >  CC [M]  fs/cifs/cifs.mod.o
> > > > > >  LD [M]  fs/cifs/cifs.ko
> > > > > >  Building modules, stage 2.
> > > > > >  MODPOST 1 modules
> > > > > >./scripts/nsdeps: 34: local: ./fs/cifs/cifsfs.c: bad variable name
> > > > > >make: *** [Makefile:1710: nsdeps] Error 2
> > > > >
> > > > > Thanks for reporting this. It appears to me you hit a bug that was
> > > > > recently discovered: when building with `make M=some/subdirectory`,
> > > > > modpost is misbehaving. Can you try whether this patch series solves
> > > > > your problems:
> > > > > https://lore.kernel.org/lkml/20191003075826.7478-1-yamada.masah...@socionext.com/
> > > > > In particular patch 2/6 out of the series.
> > > > >
> > > > > Cheers,
> > > > > Matthias
> > > >
> > > >
> > > > Applying just patch 2 and doing "make" from the root of the git tree
> > > > (5.4-rc1), at the tail end of the build I got
> > > >
> > > > ...
> > > > Kernel: arch/x86/boot/bzImage is ready  (#87)
> > > >   Building modules, stage 2.
> > > >   MODPOST 5340 modules
> > > > free(): invalid pointer
> > > > Aborted (core dumped)
> > >
> > >
> > > Right.
> > >
> > > Since 2/6 depends on 1/6,
> > > applying only the second one does not work.
> >
> > Applying both 1 and 2 I get the following error doing make (although
> > it makes it a long way into the build)
> >
> > 
> > WARNING: drivers/usb/storage/usb-storage: 'USB_STORAGE' exported
> > twice. Previous export was in drivers/usb/storage/usb-storage.ko
> > ERROR: "usb_stor_set_xfer_buf" [drivers/usb/storage/ums-usbat.ko] undefined!
> > ERROR: "usb_stor_access_xfer_buf" [drivers/usb/storage/ums-usbat.ko] 
> > undefined!
> > ERROR: "usb_stor_post_reset" [drivers/usb/storage/ums-usbat.ko] undefined!
> > ERROR: "usb_stor_disconnect" [drivers/usb/storage/ums-usbat.ko] undefined!
> > 
> > ERROR: "usb_stor_adjust_quirks" [drivers/usb/storage/uas.ko] undefined!
> > ERROR: "usb_stor_sense_invalidCDB" [drivers/usb/storage/uas.ko] undefined!
> > WARNING: "USB_STORAGE" [drivers/usb/storage/usb-storage] is a static
> > EXPORT_SYMBOL_GPL
> > make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
> > make: *** [Makefile:1303: modules] Error 2
>
>
> Hmm, I do not see those error.
> I was able to build the kernel successfully.
> (I asked the 0-day bot to test whole of my patch set
> in case I am missing something.)
>
>
> Could you share the steps to reproduce the errors and your .config file?

>From the root of git tree - at exactly 5.4-rc1

~/cifs-2.6$ make nsdeps
  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND  objtool
  CHK include/generated/compile.h
  CHK kernel/kheaders_data.tar.xz
  Building modules, stage 2.
  MODPOST 5340 modules
  Building modules, stage 2.
  MODPOST 5340 modules
./scripts/nsdeps: 34: local: ./fs/cifs/cifsfs.c: bad variable name
make: *** [Makefile:1710: nsdeps] Error 2

I get the same error doing "rm fs/cifs/*.o" and repeating the "make
nsdeps" command

I will send you the .config

[PATCH] arm64/mm: Poison initmem while freeing with free_reserved_area()

[Anshuman Khandual]

Platform implementation for free_initmem() should poison the memory while
freeing it up. Hence pass across POISON_FREE_INITMEM while calling into
free_reserved_area(). The same is being followed in the generic fallback
for free_initmem() and some other platforms overriding it.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mark Rutland 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
 arch/arm64/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 45c00a54909c..ea7d38011e83 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -571,7 +571,7 @@ void free_initmem(void)
 {
free_reserved_area(lm_alias(__init_begin),
   lm_alias(__init_end),
-  0, "unused kernel");
+  POISON_FREE_INITMEM, "unused kernel");
/*
 * Unmap the __init region but leave the VM area in place. This
 * prevents the region from being reused for kernel modules, which
-- 
2.20.1

Potential uninitialized variables in power: supply: rt5033_battery:

[Yizhuo Zhai]

Hi:

drivers/power/supply/rt5033_battery.c:

In function rt5033_battery_get_present(), variable "val" could be
uninitialized if regmap_read() returns -EINVAL. However, "val" is
used to decide the return value, which is potentially unsafe.

Also, we cannot simply return -EINVAL in rt5033_battery_get_present()
because it's not an acceptable return value.

Thanks for your time to check this case.

-- 
Kind Regards,

Yizhuo Zhai

Computer Science, Graduate Student
University of California, Riverside

[PATCH v3] PCI: mobiveil: Fix csr_read/write build issue

[Kefeng Wang]

The riscv has csr_read/write macro, see arch/riscv/include/asm/csr.h,
the same function naming will cause build error, using such generic names
in a driver is bad, rename csr_[read,write][l,] to mobiveil_csr_read/write
to fix it.

drivers/pci/controller/pcie-mobiveil.c:238:69: error: macro "csr_read" passed 3 
arguments, but takes just 1
 static u32 csr_read(struct mobiveil_pcie *pcie, u32 off, size_t size)

drivers/pci/controller/pcie-mobiveil.c:253:80: error: macro "csr_write" passed 
4 arguments, but takes just 2
 static void csr_write(struct mobiveil_pcie *pcie, u32 val, u32 off, size_t 
size)

Cc: Hou Zhiqiang 
Cc: Lorenzo Pieralisi 
Cc: Minghuan Lian 
Cc: Subrahmanya Lingappa 
Cc: Andrew Murray  
Fixes: bcbe0d9a8d93 ("PCI: mobiveil: Unify register accessors")
Signed-off-by: Kefeng Wang 
---
v3:
- reduce line lengths suggested by Andrew

v2:
- using mobiveil prefix suggested by Andrew and Christoph 

 drivers/pci/controller/pcie-mobiveil.c | 119 +
 1 file changed, 62 insertions(+), 57 deletions(-)

diff --git a/drivers/pci/controller/pcie-mobiveil.c 
b/drivers/pci/controller/pcie-mobiveil.c
index a45a6447b01d..32f37d08d5bc 100644
--- a/drivers/pci/controller/pcie-mobiveil.c
+++ b/drivers/pci/controller/pcie-mobiveil.c
@@ -235,7 +235,7 @@ static int mobiveil_pcie_write(void __iomem *addr, int 
size, u32 val)
return PCIBIOS_SUCCESSFUL;
 }
 
-static u32 csr_read(struct mobiveil_pcie *pcie, u32 off, size_t size)
+static u32 mobiveil_csr_read(struct mobiveil_pcie *pcie, u32 off, size_t size)
 {
void *addr;
u32 val;
@@ -250,7 +250,8 @@ static u32 csr_read(struct mobiveil_pcie *pcie, u32 off, 
size_t size)
return val;
 }
 
-static void csr_write(struct mobiveil_pcie *pcie, u32 val, u32 off, size_t 
size)
+static void mobiveil_csr_write(struct mobiveil_pcie *pcie, u32 val, u32 off,
+  size_t size)
 {
void *addr;
int ret;
@@ -262,19 +263,19 @@ static void csr_write(struct mobiveil_pcie *pcie, u32 
val, u32 off, size_t size)
dev_err(&pcie->pdev->dev, "write CSR address failed\n");
 }
 
-static u32 csr_readl(struct mobiveil_pcie *pcie, u32 off)
+static u32 mobiveil_csr_readl(struct mobiveil_pcie *pcie, u32 off)
 {
-   return csr_read(pcie, off, 0x4);
+   return mobiveil_csr_read(pcie, off, 0x4);
 }
 
-static void csr_writel(struct mobiveil_pcie *pcie, u32 val, u32 off)
+static void mobiveil_csr_writel(struct mobiveil_pcie *pcie, u32 val, u32 off)
 {
-   csr_write(pcie, val, off, 0x4);
+   mobiveil_csr_write(pcie, val, off, 0x4);
 }
 
 static bool mobiveil_pcie_link_up(struct mobiveil_pcie *pcie)
 {
-   return (csr_readl(pcie, LTSSM_STATUS) &
+   return (mobiveil_csr_readl(pcie, LTSSM_STATUS) &
LTSSM_STATUS_L0_MASK) == LTSSM_STATUS_L0;
 }
 
@@ -323,7 +324,7 @@ static void __iomem *mobiveil_pcie_map_bus(struct pci_bus 
*bus,
PCI_SLOT(devfn) << PAB_DEVICE_SHIFT |
PCI_FUNC(devfn) << PAB_FUNCTION_SHIFT;
 
-   csr_writel(pcie, value, PAB_AXI_AMAP_PEX_WIN_L(WIN_NUM_0));
+   mobiveil_csr_writel(pcie, value, PAB_AXI_AMAP_PEX_WIN_L(WIN_NUM_0));
 
return pcie->config_axi_slave_base + where;
 }
@@ -353,13 +354,14 @@ static void mobiveil_pcie_isr(struct irq_desc *desc)
chained_irq_enter(chip, desc);
 
/* read INTx status */
-   val = csr_readl(pcie, PAB_INTP_AMBA_MISC_STAT);
-   mask = csr_readl(pcie, PAB_INTP_AMBA_MISC_ENB);
+   val = mobiveil_csr_readl(pcie, PAB_INTP_AMBA_MISC_STAT);
+   mask = mobiveil_csr_readl(pcie, PAB_INTP_AMBA_MISC_ENB);
intr_status = val & mask;
 
/* Handle INTx */
if (intr_status & PAB_INTP_INTX_MASK) {
-   shifted_status = csr_readl(pcie, PAB_INTP_AMBA_MISC_STAT);
+   shifted_status = mobiveil_csr_readl(pcie,
+   PAB_INTP_AMBA_MISC_STAT);
shifted_status &= PAB_INTP_INTX_MASK;
shifted_status >>= PAB_INTX_START;
do {
@@ -373,12 +375,13 @@ static void mobiveil_pcie_isr(struct irq_desc *desc)
bit);
 
/* clear interrupt handled */
-   csr_writel(pcie, 1 << (PAB_INTX_START + bit),
-  PAB_INTP_AMBA_MISC_STAT);
+   mobiveil_csr_writel(pcie,
+   1 << (PAB_INTX_START + bit),
+   PAB_INTP_AMBA_MISC_STAT);
}
 
-   shifted_status = csr_readl(pcie,
-  PAB_INTP_AMBA_MISC_STAT);
+   shifted_status = mobiveil_csr_readl(pcie,
+   
PAB_INTP_AMBA_MISC_STAT);
shifted_status &= P

Re: [PATCH] arm64: dts: qcom: msm8998-clamshell: Remove retention idle state

[Amit Kucheria]

On Thu, Oct 3, 2019 at 12:44 AM Jeffrey Hugo  wrote:
>
> The retention idle state does not appear to be supported by the firmware
> present on the msm8998 laptops since the state is advertised as disabled
> in ACPI, and attempting to enable the state in DT is observed to result
> in boot hangs.  Therefore, remove the state from use to address the
> observed issues.
>
> Fixes: 2c6d2d3a580a (arm64: dts: qcom: Add Lenovo Miix 630)
> Signed-off-by: Jeffrey Hugo 

Reviewed-by: Amit Kucheria 

> ---
>  .../boot/dts/qcom/msm8998-clamshell.dtsi  | 37 +++
>  1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> index 9682d4dd7496..1bae90705746 100644
> --- a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> @@ -23,6 +23,43 @@
> };
>  };
>
> +/*
> + * The laptop FW does not appear to support the retention state as it is
> + * not advertised as enabled in ACPI, and enabling it in DT can cause boot
> + * hangs.
> + */
> +&CPU0 {
> +   cpu-idle-states = <&LITTLE_CPU_SLEEP_1>;
> +};
> +
> +&CPU1 {
> +   cpu-idle-states = <&LITTLE_CPU_SLEEP_1>;
> +};
> +
> +&CPU2 {
> +   cpu-idle-states = <&LITTLE_CPU_SLEEP_1>;
> +};
> +
> +&CPU3 {
> +   cpu-idle-states = <&LITTLE_CPU_SLEEP_1>;
> +};
> +
> +&CPU4 {
> +   cpu-idle-states = <&BIG_CPU_SLEEP_1>;
> +};
> +
> +&CPU5 {
> +   cpu-idle-states = <&BIG_CPU_SLEEP_1>;
> +};
> +
> +&CPU6 {
> +   cpu-idle-states = <&BIG_CPU_SLEEP_1>;
> +};
> +
> +&CPU7 {
> +   cpu-idle-states = <&BIG_CPU_SLEEP_1>;
> +};
> +
>  &qusb2phy {
> status = "okay";
>
> --
> 2.17.1
>

Re: nsdeps not working on modules in 5.4-rc1

[Masahiro Yamada]

Hi Steve,

On Fri, Oct 4, 2019 at 1:07 AM Steve French  wrote:
>
> On Thu, Oct 3, 2019 at 10:24 AM Masahiro Yamada
>  wrote:
> >
> > Hi Steve,
> >
> > On Fri, Oct 4, 2019 at 12:15 AM Steve French  wrote:
> > >
> > > On Thu, Oct 3, 2019 at 5:43 AM Matthias Maennich  
> > > wrote:
> > > >
> > > > Hi Steve!
> > > >
> > > > On Wed, Oct 02, 2019 at 06:54:26PM -0500, Steve French wrote:
> > > > >And running the build differently, from the root of the git tree
> > > > >(5.4-rc1) rather than using the Ubuntu 5.4-rc1 headers also fails
> > > > >
> > > > >e.g. "make  M=fs/cifs modules nsdeps"
> > > > >
> > > > >...
> > > > >  LD [M]  fs/cifs/cifs.o
> > > > >  Building modules, stage 2.
> > > > >  MODPOST 1 modules
> > > > >WARNING: module cifs uses symbol sigprocmask from namespace
> > > > >_fs/cifs/cache.o), but does not import it.
> > > > >...
> > > > >WARNING: module cifs uses symbol posix_test_lock from namespace
> > > > >cifs/cache.o), but does not import it.
> > > > >  CC [M]  fs/cifs/cifs.mod.o
> > > > >  LD [M]  fs/cifs/cifs.ko
> > > > >  Building modules, stage 2.
> > > > >  MODPOST 1 modules
> > > > >./scripts/nsdeps: 34: local: ./fs/cifs/cifsfs.c: bad variable name
> > > > >make: *** [Makefile:1710: nsdeps] Error 2
> > > >
> > > > Thanks for reporting this. It appears to me you hit a bug that was
> > > > recently discovered: when building with `make M=some/subdirectory`,
> > > > modpost is misbehaving. Can you try whether this patch series solves
> > > > your problems:
> > > > https://lore.kernel.org/lkml/20191003075826.7478-1-yamada.masah...@socionext.com/
> > > > In particular patch 2/6 out of the series.
> > > >
> > > > Cheers,
> > > > Matthias
> > >
> > >
> > > Applying just patch 2 and doing "make" from the root of the git tree
> > > (5.4-rc1), at the tail end of the build I got
> > >
> > > ...
> > > Kernel: arch/x86/boot/bzImage is ready  (#87)
> > >   Building modules, stage 2.
> > >   MODPOST 5340 modules
> > > free(): invalid pointer
> > > Aborted (core dumped)
> >
> >
> > Right.
> >
> > Since 2/6 depends on 1/6,
> > applying only the second one does not work.
>
> Applying both 1 and 2 I get the following error doing make (although
> it makes it a long way into the build)
>
> 
> WARNING: drivers/usb/storage/usb-storage: 'USB_STORAGE' exported
> twice. Previous export was in drivers/usb/storage/usb-storage.ko
> ERROR: "usb_stor_set_xfer_buf" [drivers/usb/storage/ums-usbat.ko] undefined!
> ERROR: "usb_stor_access_xfer_buf" [drivers/usb/storage/ums-usbat.ko] 
> undefined!
> ERROR: "usb_stor_post_reset" [drivers/usb/storage/ums-usbat.ko] undefined!
> ERROR: "usb_stor_disconnect" [drivers/usb/storage/ums-usbat.ko] undefined!
> 
> ERROR: "usb_stor_adjust_quirks" [drivers/usb/storage/uas.ko] undefined!
> ERROR: "usb_stor_sense_invalidCDB" [drivers/usb/storage/uas.ko] undefined!
> WARNING: "USB_STORAGE" [drivers/usb/storage/usb-storage] is a static
> EXPORT_SYMBOL_GPL
> make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
> make: *** [Makefile:1303: modules] Error 2


Hmm, I do not see those error.
I was able to build the kernel successfully.
(I asked the 0-day bot to test whole of my patch set
in case I am missing something.)


Could you share the steps to reproduce the errors and your .config file?






> Running "make M=fs/cifs nsdeps" I still get the error

Sorry, I do not understand why you are doing this.


>
>   Building modules, stage 2.
>   MODPOST 1 modules
> ./scripts/nsdeps: 34: local: ./fs/cifs/cifsfs.c: bad variable name
> make: *** [Makefile:1710: nsdeps] Error 2
>
>
>
> --
> Thanks,
>
> Steve



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings【请注意，邮件由linux-rockchip-bounces+shawn.lin=rock-chips....@lists.infradead.org代发】

[Soeren Moch]

On 04.10.19 04:13, Shawn Lin wrote:
> On 2019/10/4 8:53, Soeren Moch wrote:
>>
>>
>> On 04.10.19 02:01, Robin Murphy wrote:
>>> On 2019-10-03 10:50 pm, Soeren Moch wrote:
 According to the RockPro64 schematic [1] the rk3399 sdmmc
 controller is
 connected to a microSD (TF card) slot, which cannot be switched to
 1.8V.
>>>
>>> Really? AFAICS the SDMMC0 wiring looks pretty much identical to the
>>> NanoPC-T4 schematic (it's the same reference design, after all), and I
>>> know that board can happily drive a UHS-I microSD card with 1.8v I/Os,
>>> because mine's doing so right now.
>>>
>>> Robin.
>> OK, the RockPro64 does not allow a card reset (power cycle) since
>> VCC3V0_SD is directly connected to VCC3V3_SYS (via R89555), the
>> SDMMC0_PWH_H signal is not connected. So the card fails to identify
>> itself after suspend or reboot when switched to 1.8V operation.
>>
>
> I believe we addressed this issue long time ago, please check:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6a11fc47f175c8d87018e89cb58e2d36c66534cb
>
Thanks for the pointer.
In this case I guess I should use following patch instead:

--- rk3399-rockpro64.dts.bak    2019-10-03 22:14:00.067745799 +0200
+++ rk3399-rockpro64.dts    2019-10-04 00:02:50.047892366 +0200
@@ -619,6 +619,8 @@
 max-frequency = <15000>;
 pinctrl-names = "default";
 pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
+    sd-uhs-sdr104;
+    vqmmc-supply = <&vcc_sdio>;
 status = "okay";
 };
 
When I do so, the sd card is detected as SDR104, but a reboot hangs:

Boot1: 2018-06-26, version: 1.14
CPUId = 0x0
ChipType = 0x10, 286
Spi_ChipId = c84018
no find rkpartition
SpiBootInit:
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
SdmmcInit=2 1
mmc0:cmd5,32
mmc0:cmd7,32
mmc0:cmd5,32
mmc0:cmd7,32
mmc0:cmd5,32
mmc0:cmd7,32
SdmmcInit=0 1

So I guess I should use a different miniloader for this reboot to work!?
Or what else could be wrong here?

Thanks,
Soeren

>> Regards,
>> Soeren
>>>
 So also configure the vcc_sdio regulator, which drives the i/o voltage
 of the sdmmc controller, accordingly.

 While at it, also remove the cap-mmc-highspeed property of the sdmmc
 controller, since no mmc card can be connected here.

 [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf

 Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support
 for Rockpro64")
 Signed-off-by: Soeren Moch 
 ---
 Cc: Heiko Stuebner 
 Cc: linux-rockc...@lists.infradead.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-kernel@vger.kernel.org
 ---
    arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts | 3 +--
    1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
 b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
 index 2e44dae4865a..084f1d994a50 100644
 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
 +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
 @@ -353,7 +353,7 @@
    regulator-name = "vcc_sdio";
    regulator-always-on;
    regulator-boot-on;
 -    regulator-min-microvolt = <180>;
 +    regulator-min-microvolt = <300>;
    regulator-max-microvolt = <300>;
    regulator-state-mem {
    regulator-on-in-suspend;
 @@ -624,7 +624,6 @@

    &sdmmc {
    bus-width = <4>;
 -    cap-mmc-highspeed;
    cap-sd-highspeed;
    cd-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
    disable-wp;
 -- 
 2.17.1


 ___
 Linux-rockchip mailing list
 linux-rockc...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-rockchip

>>
>> ___
>> Linux-rockchip mailing list
>> linux-rockc...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>
>
>

Potential uninitialized variables in subsys net: hisilicon

[Yizhuo Zhai]

Hi All:

drivers/net/ethernet/hisilicon/hip04_eth.c:

In function hip04_reset_ppe(), variable "val" could be uninitialized
if regmap_read() returns -EINVAL. However, "val" is used to decide
the control flow, which is potentially unsafe.

Also, we cannot simply return -EINVAL in hip04_reset_ppe() because
the return type is void.

Thanks for your time to check this case.

-- 
Kind Regards,

Yizhuo Zhai

Computer Science, Graduate Student
University of California, Riverside

Re: [PATCH v2 2/2] cpufreq: intel_pstate: Conditional frequency invariant accounting

[Srinivas Pandruvada]

On Thu, 2019-10-03 at 20:05 +0200, Rafael J. Wysocki wrote:
> On Wednesday, October 2, 2019 2:29:26 PM CEST Giovanni Gherdovich
> wrote:
> > From: Srinivas Pandruvada 
> > 
> > intel_pstate has two operating modes: active and passive. In
> > "active"
> > mode, the in-built scaling governor is used and in "passive" mode,
> > the driver can be used with any governor like "schedutil". In
> > "active"
> > mode the utilization values from schedutil is not used and there is
> > a requirement from high performance computing use cases, not to
> > readas well
> > any APERF/MPERF MSRs.
> 
> Well, this isn't quite convincing.
> 
> In particular, I don't see why the "don't read APERF/MPERF MSRs"
> argument
> applies *only* to intel_pstate in the "active" mode.  What about
> intel_pstate
> in the "passive" mode combined with the "performance" governor?  Or
> any other
> governor different from "schedutil" for that matter?
> 
> And what about acpi_cpufreq combined with any governor different from
> "schedutil"?
> 
> Scale invariance is not really needed in all of those cases right now
> AFAICS,
> or is it?
Correct. This is just part of the patch to disable in active mode
(particularly in HWP and performance mode). 

But this patch is 2 years old. The folks who wanted this, disable
intel-pstate and use userspace governor with acpi-cpufreq. So may be
better to address those cases too.

> 
> So is the real concern that intel_pstate in the "active" mode reads
> the MPERF
> and APERF MSRs by itself and that kind of duplicates what the scale
> invariance
> code does and is redundant etc?
It is redundant in non-HWP mode. In HWP and performance (active mode)
we don't use atleast at this time.

Thanks
Srinivas

Re: [PATCH 2/2] gpio: Add xgs-iproc driver

[kbuild test robot]

Hi Chris,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on gpio/for-next]
[cannot apply to v5.4-rc1 next-20191003]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Chris-Packham/gpio-brcm-XGS-iProc-GPIO-driver/20191004-093320
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=m68k 

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

All warnings (new ones prefixed by >>):

>> WARNING: drivers/gpio/gpio-xgs-iproc.o(.data+0x2a): Section mismatch in 
>> reference from the variable bcm_iproc_gpio_driver to the variable 
>> .init.rodata:bcm_iproc_gpio_of_match
   The variable bcm_iproc_gpio_driver references
   the variable __initconst bcm_iproc_gpio_of_match
   If the reference is valid then annotate the
   variable with or __refdata (see linux/init.h) or name the variable:
   

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 7/9] arm64: dts: qcom: msm8998: Add PSCI cpuidle low power states

[Jeffrey Hugo]

On Thu, Oct 3, 2019 at 7:36 PM Amit Kucheria  wrote:
>
> On Wed, Oct 2, 2019 at 11:48 PM Jeffrey Hugo  wrote:
> >
> > On Wed, Oct 2, 2019 at 3:27 AM Niklas Cassel  
> > wrote:
> > >
> > > On Wed, Oct 02, 2019 at 11:19:50AM +0200, Niklas Cassel wrote:
> > > > On Mon, Sep 30, 2019 at 04:20:15PM -0600, Jeffrey Hugo wrote:
> > > > > Amit, the merged version of the below change causes a boot failure
> > > > > (nasty hang, sometimes with RCU stalls) on the msm8998 laptops.  Oddly
> > > > > enough, it seems to be resolved if I remove the cpu-idle-states
> > > > > property from one of the cpu nodes.
> > > > >
> > > > > I see no issues with the msm8998 MTP.
> > > >
> > > > Hello Jeffrey, Amit,
> > > >
> > > > If the PSCI idle states work properly on the msm8998 devboard (MTP),
> > > > but causes crashes on msm8998 laptops, the only logical change is
> > > > that the PSCI firmware is different between the two devices.
> > >
> > > Since the msm8998 laptops boot using ACPI, perhaps these laptops
> > > doesn't support PSCI/have any PSCI firmware at all.
> >
> > They have PSCI.  If there was no PSCI, I would expect the PSCI
> > get_version request from Linux to fail, and all PSCI functionality to
> > be disabled.
> >
> > However, your mention about ACPI sparked a thought.  ACPI describes
> > the idle states, along with the PSCI info, in the ACPI0007 devices.
> > Those exist on the laptops, and the info mostly correlates with Amit's
> > patch (ACPI seems to be a bit more conservative about the latencies,
> > and describes one additional deeper state).  However, upon a detailed
> > analysis of the ACPI description, I did find something relevant - the
> > retention state is not enabled.
> >
> > So, I hacked out the retention state from Amit's patch, and I did not
> > observe a hang.  I used sysfs, and appeared able to validate that the
> > power collapse state was being used successfully.
>
> Interesting that the shallower sleep state was causing problems.
> Usually, it is the deeper states that cause problems. So you plan to
> override the idle states table in the board-specific DT?

Yes.  Already posted.

>
> Why does the platform even rely on DT? Shouldn't we use the ACPI tables 
> instead?

In theory, yes.  However the ACPI seems to be incomplete (assumes
things are just hardcoded in the driver maybe?) and has tons of
non-standard things in it.  DT seems to be the easy path to
enablement.
>
> > I'm guessing that something is weird with the laptops, where the CPUs
> > can go into retention, but not come out, thus causing issues.
> >
> > I'll post a patch to fix up the laptops.  Thanks for all the help.

Re: [PATCH 2/2] gpio: Add xgs-iproc driver

[kbuild test robot]

Hi Chris,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on gpio/for-next]
[cannot apply to v5.4-rc1 next-20191003]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Chris-Packham/gpio-brcm-XGS-iProc-GPIO-driver/20191004-093320
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=ia64 

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

All errors (new ones prefixed by >>):

>> ERROR: "ia64_delay_loop" undefined!
>> ERROR: "ia64_delay_loop" undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

RE: [PATCH v2] x86/hyperv: make vapic support x2apic mode

[Michael Kelley]

From: Roman Kagan  Sent: Thursday, October 3, 2019 5:53 AM
> >
> > AFAIU you're trying to mirror native_x2apic_icr_write() here but this is
> > different from what hv_apic_icr_write() does
> > (SET_APIC_DEST_FIELD(id)).
> 
> Right.  In xapic mode the ICR2 aka the high 4 bytes of ICR is programmed
> with the destination id in the highest byte; in x2apic mode the whole
> ICR2 is set to the 32bit destination id.
> 
> > Is it actually correct? (I think you've tested this and it is but)
> 
> As I wrote in the commit log, I haven't tested it in the sense that I
> ran a Linux guest in a Hyper-V VM exposing x2apic to the guest, because
> I didn't manage to configure it to do so.  OTOH I did run a Windows
> guest in QEMU/KVM with hv_apic and x2apic enabled and saw it write
> destination ids unshifted to the ICR2 part of ICR, so I assume it's
> correct.
> 
> > Michael, could you please shed some light here?
> 
> Would be appreciated, indeed.
> 

The newest version of Hyper-V provides an x2apic in a guest VM when the
number of vCPUs in the VM is > 240.  This version of Hyper-V is beginning
to be deployed in Azure to enable the M416v2 VM size, but the functionality
is not yet available for the on-premises version of Hyper-V.  However, I can
test this configuration internally with the above patch -- give me a few days.

An additional complication is that when running on Intel processors that offer
vAPIC functionality, the Hyper-V "hints" value does *not* recommend using the
MSR-based APIC accesses.  In this case, memory-mapped access to the x2apic
registers is faster than the synthetic MSRs.  I've already looked at a VM that 
has
the x2apic, and indeed that is the case, so the above code wouldn't run
anyway.  But I can temporarily code around that for testing purposes and see
if everything works.

Michael

Re: [PATCH 1/3] thunderbolt: Read DP IN adapter first two dwords in one go

[Brad Campbell]

On 1/10/19 6:29 pm, Mika Westerberg wrote:

When we discover existing DP tunnels the code checks whether DP IN
adapter port is enabled by calling tb_dp_port_is_enabled() before it
continues the discovery process. On Light Ridge (gen 1) controller
reading only the first dword of the DP IN config space causes subsequent
access to the same DP IN port path config space to fail or return
invalid data as can be seen in the below splat:

   thunderbolt :07:00.0: CFG_ERROR(0:d): Invalid config space or offset
   Call Trace:
tb_cfg_read+0xb9/0xd0
__tb_path_deactivate_hop+0x98/0x210
tb_path_activate+0x228/0x7d0
tb_tunnel_restart+0x95/0x200
tb_handle_hotplug+0x30e/0x630
process_one_work+0x1b4/0x340
worker_thread+0x44/0x3d0
kthread+0xeb/0x120
? process_one_work+0x340/0x340
? kthread_park+0xa0/0xa0
ret_from_fork+0x1f/0x30

If both DP In adapter config dwords are read in one go the issue does
not reproduce. This is likely firmware bug but we can work it around by
always reading the two dwords in one go. There should be no harm for
other controllers either so can do it unconditionally.

Link: https://lkml.org/lkml/2019/8/28/160
Reported-by: Brad Campbell 


Tested-by: Brad Campbell 


Signed-off-by: Mika Westerberg 
---
  drivers/thunderbolt/switch.c | 19 +++
  1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 410bf1bc..8e712fbf8233 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -896,12 +896,13 @@ int tb_dp_port_set_hops(struct tb_port *port, unsigned 
int video,
   */
  bool tb_dp_port_is_enabled(struct tb_port *port)
  {
-   u32 data;
+   u32 data[2];
  
-	if (tb_port_read(port, &data, TB_CFG_PORT, port->cap_adap, 1))

+   if (tb_port_read(port, data, TB_CFG_PORT, port->cap_adap,
+ARRAY_SIZE(data)))
return false;
  
-	return !!(data & (TB_DP_VIDEO_EN | TB_DP_AUX_EN));

+   return !!(data[0] & (TB_DP_VIDEO_EN | TB_DP_AUX_EN));
  }
  
  /**

@@ -914,19 +915,21 @@ bool tb_dp_port_is_enabled(struct tb_port *port)
   */
  int tb_dp_port_enable(struct tb_port *port, bool enable)
  {
-   u32 data;
+   u32 data[2];
int ret;
  
-	ret = tb_port_read(port, &data, TB_CFG_PORT, port->cap_adap, 1);

+   ret = tb_port_read(port, data, TB_CFG_PORT, port->cap_adap,
+  ARRAY_SIZE(data));
if (ret)
return ret;
  
  	if (enable)

-   data |= TB_DP_VIDEO_EN | TB_DP_AUX_EN;
+   data[0] |= TB_DP_VIDEO_EN | TB_DP_AUX_EN;
else
-   data &= ~(TB_DP_VIDEO_EN | TB_DP_AUX_EN);
+   data[0] &= ~(TB_DP_VIDEO_EN | TB_DP_AUX_EN);
  
-	return tb_port_write(port, &data, TB_CFG_PORT, port->cap_adap, 1);

+   return tb_port_write(port, data, TB_CFG_PORT, port->cap_adap,
+ARRAY_SIZE(data));
  }
  
  /* switch utility functions */

We bring your gadget back to life

[Just Repair]

Hello, 

Let us repair your phone or gadget right on the spot
visit us today
https://www.justrepair.net

or come into our location
https://goo.gl/maps/k5iRbeJyggiXnZSG6
Give us a nice review and we`ll make you a big discount


Thank you,
Ameer

[PATCH v3 1/2] perf: support multiple debug options separated by ','

[Changbin Du]

This patch adds support for multiple debug options separated by ',' and
non-int values.
--debug verbose=2,stderr

Signed-off-by: Changbin Du 
---
 tools/perf/Documentation/perf.txt | 10 ++--
 tools/perf/util/debug.c   | 86 ---
 2 files changed, 50 insertions(+), 46 deletions(-)

diff --git a/tools/perf/Documentation/perf.txt 
b/tools/perf/Documentation/perf.txt
index 401f0ed67439..c05a94b2488e 100644
--- a/tools/perf/Documentation/perf.txt
+++ b/tools/perf/Documentation/perf.txt
@@ -19,11 +19,11 @@ OPTIONS
  --debug verbose=2 # sets verbose = 2
 
List of debug variables allowed to set:
- verbose  - general debug messages
- ordered-events   - ordered events object debug messages
- data-convert - data convert command debug messages
- stderr   - write debug output (option -v) to stderr
-in browser mode
+ verbose=level - general debug messages
+ ordered-events=level  - ordered events object debug messages
+ data-convert=level- data convert command debug messages
+ stderr- write debug output (option -v) to stderr
+ in browser mode
 
 --buildid-dir::
Setup buildid cache directory. It has higher priority than
diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c
index e55114f0336f..df82ad9cd16d 100644
--- a/tools/perf/util/debug.c
+++ b/tools/perf/util/debug.c
@@ -26,7 +26,7 @@
 int verbose;
 bool dump_trace = false, quiet = false;
 int debug_ordered_events;
-static int redirect_to_stderr;
+static bool redirect_to_stderr;
 int debug_data_convert;
 
 int veprintf(int level, int var, const char *fmt, va_list args)
@@ -172,41 +172,18 @@ void trace_event(union perf_event *event)
 trace_event_printer, event);
 }
 
-static struct debug_variable {
-   const char *name;
-   int *ptr;
-} debug_variables[] = {
-   { .name = "verbose",.ptr = &verbose },
-   { .name = "ordered-events", .ptr = &debug_ordered_events},
-   { .name = "stderr", .ptr = &redirect_to_stderr},
-   { .name = "data-convert",   .ptr = &debug_data_convert },
-   { .name = NULL, }
-};
-
-int perf_debug_option(const char *str)
+static int str2loglevel(const char *vstr)
 {
-   struct debug_variable *var = &debug_variables[0];
-   char *vstr, *s = strdup(str);
int v = 1;
-
-   vstr = strchr(s, '=');
-   if (vstr)
-   *vstr++ = 0;
-
-   while (var->name) {
-   if (!strcmp(s, var->name))
-   break;
-   var++;
-   }
-
-   if (!var->name) {
-   pr_err("Unknown debug variable name '%s'\n", s);
-   free(s);
-   return -1;
-   }
+   char *endptr;
 
if (vstr) {
-   v = atoi(vstr);
+   v = strtol(vstr, &endptr,0);
+   if (vstr == endptr) {
+   fprintf(stderr, "warning: '%s' is not a digit\n", vstr);
+   return -1;
+   }
+
/*
 * Allow only values in range (0, 10),
 * otherwise set 0.
@@ -217,20 +194,47 @@ int perf_debug_option(const char *str)
if (quiet)
v = -1;
 
-   *var->ptr = v;
-   free(s);
+   return v;
+}
+
+int perf_debug_option(const char *str)
+{
+   char *sep, *vstr;
+   char *dstr = strdup(str);
+   char *opt = dstr;
+
+   do {
+   if ((sep = strchr(opt, ',')) != NULL)
+   *sep = '\0';
+
+   vstr = strchr(opt, '=');
+   if (vstr)
+   *vstr++ = 0;
+
+   if (!strcmp(opt, "verbose"))
+   verbose = str2loglevel(vstr);
+   else if (!strcmp(opt, "ordered-events"))
+   debug_ordered_events = str2loglevel(vstr);
+   else if (!strcmp(opt, "data-convert"))
+   debug_data_convert = str2loglevel(vstr);
+   else if (!strcmp(opt, "stderr"))
+   redirect_to_stderr = true;
+   else {
+   fprintf(stderr, "unkown debug option '%s'\n", opt);
+   free(dstr);
+   return -1;
+   }
+
+   opt = sep + 1;
+   } while (sep && sep[1]);
+
+   free(dstr);
return 0;
 }
 
 int perf_quiet_option(void)
 {
-   struct debug_variable *var = &debug_variables[0];
-
-   /* disable all debug messages */
-   while (var->name) {
-   *var->ptr = -1;
-   var++;
-   }
+   verbose = debug_ordered_events = debug_data_convert = -1;
 
return 0;
 }
-- 
2.20.1

[PATCH v3 2/2] perf: add support for logging debug messages to file

[Changbin Du]

When in TUI mode, it is impossible to show all the debug messages to
console. This make it hard to debug perf issues using debug messages.
This patch adds support for logging debug messages to file to resolve
this problem.

The usage is:
perf -debug verbose=2,file=~/perf.log COMMAND

Signed-off-by: Changbin Du 

--
v3: fix a segfault issue.
---
 tools/perf/Documentation/perf.txt | 15 ++-
 tools/perf/util/debug.c   | 44 +++
 2 files changed, 48 insertions(+), 11 deletions(-)

diff --git a/tools/perf/Documentation/perf.txt 
b/tools/perf/Documentation/perf.txt
index c05a94b2488e..a6b19661e5c3 100644
--- a/tools/perf/Documentation/perf.txt
+++ b/tools/perf/Documentation/perf.txt
@@ -16,14 +16,17 @@ OPTIONS
Setup debug variable (see list below) in value
range (0, 10). Use like:
  --debug verbose   # sets verbose = 1
- --debug verbose=2 # sets verbose = 2
+ --debug verbose=2,file=~/perf.log
+   # sets verbose = 2 and save log to file
 
List of debug variables allowed to set:
- verbose=level - general debug messages
- ordered-events=level  - ordered events object debug messages
- data-convert=level- data convert command debug messages
- stderr- write debug output (option -v) to stderr
- in browser mode
+ verbose=level - general debug messages
+ ordered-events=level  - ordered events object debug messages
+ data-convert=level- data convert command debug messages
+ stderr- write debug output (option -v) to stderr
+ in browser mode
+ file=path - write debug output to log file (stderr and
+ file options are exclusive)
 
 --buildid-dir::
Setup buildid cache directory. It has higher priority than
diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c
index df82ad9cd16d..bfb0b886266f 100644
--- a/tools/perf/util/debug.c
+++ b/tools/perf/util/debug.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,7 +27,7 @@
 int verbose;
 bool dump_trace = false, quiet = false;
 int debug_ordered_events;
-static bool redirect_to_stderr;
+static FILE *log_file;
 int debug_data_convert;
 
 int veprintf(int level, int var, const char *fmt, va_list args)
@@ -34,10 +35,10 @@ int veprintf(int level, int var, const char *fmt, va_list 
args)
int ret = 0;
 
if (var >= level) {
-   if (use_browser >= 1 && !redirect_to_stderr)
+   if (use_browser >= 1 && !log_file)
ui_helpline__vshow(fmt, args);
else
-   ret = vfprintf(stderr, fmt, args);
+   ret = vfprintf(log_file, fmt, args);
}
 
return ret;
@@ -197,6 +198,24 @@ static int str2loglevel(const char *vstr)
return v;
 }
 
+static void flush_log(void)
+{
+   if (log_file)
+   fflush(log_file);
+}
+
+static void set_log_output(FILE *f)
+{
+   if (f == log_file)
+   return;
+
+   if (log_file && log_file != stderr)
+   fclose(log_file);
+
+   log_file = f;
+   atexit(flush_log);
+}
+
 int perf_debug_option(const char *str)
 {
char *sep, *vstr;
@@ -218,8 +237,23 @@ int perf_debug_option(const char *str)
else if (!strcmp(opt, "data-convert"))
debug_data_convert = str2loglevel(vstr);
else if (!strcmp(opt, "stderr"))
-   redirect_to_stderr = true;
-   else {
+   set_log_output(stderr);
+   else if (!strcmp(opt, "file")) {
+   FILE *f;
+
+   if (!vstr)
+   vstr = (char *)"perf.log";
+
+   f = fopen(vstr, "a");
+   if (!f) {
+   pr_err("Can not create log file: %s\n",
+  strerror(errno));
+   free(dstr);
+   return -1;
+   }
+   fprintf(f, "\n===perf log===\n");
+   set_log_output(f);
+   } else {
fprintf(stderr, "unkown debug option '%s'\n", opt);
free(dstr);
return -1;
-- 
2.20.1

[PATCH v3 0/2] perf: add support for logging debug messages to file

[Changbin Du]

When in TUI mode, it is impossible to show all the debug messages to
console. This make it hard to debug perf issues using debug messages.
This patch adds support for logging debug messages to file to resolve
this problem.

v3:
  o fix a segfault issue.
v2:
  o specific all debug options one time.

Changbin Du (2):
  perf: support multiple debug options separated by ','
  perf: add support for logging debug messages to file

 tools/perf/Documentation/perf.txt |  15 ++--
 tools/perf/util/debug.c   | 124 +++---
 2 files changed, 90 insertions(+), 49 deletions(-)

-- 
2.20.1

Re: [PATCH v2 0/2] perf: add support for logging debug messages to file

[Changbin Du]

On Sun, Sep 29, 2019 at 09:44:07AM +0200, Jiri Olsa wrote:
> On Sun, Sep 22, 2019 at 10:38:21AM +0800, Changbin Du wrote:
> > When in TUI mode, it is impossible to show all the debug messages to
> > console. This make it hard to debug perf issues using debug messages.
> > This patch adds support for logging debug messages to file to resolve
> > this problem.
> > 
> > v2:
> >   o specific all debug options one time.
> > 
> > Changbin Du (2):
> >   perf: support multiple debug options separated by ','
> >   perf: add support for logging debug messages to file
> 
> hi,
> getting segfault with:
> 
> [jolsa@krava perf]$ ./perf --debug verbose=2,file report
> build id event received for [kernel.kallsyms]: 
> bf6ca14c03795fd67b4d88113681ba4af2b8c18a
> Segmentation fault (core dumped)
>
Hmm, this because the va_list variable cannot be used twice. I resolve this by
making stderr and file options exclusive.

> jirka
> 
> > 
> >  tools/perf/Documentation/perf.txt |  14 ++--
> >  tools/perf/util/debug.c   | 106 ++
> >  2 files changed, 73 insertions(+), 47 deletions(-)
> > 
> > -- 
> > 2.20.1
> > 

-- 
Cheers,
Changbin Du

Re: [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings【请注意，邮件由linux-rockchip-bounces+shawn.lin=rock-chips....@lists.infradead.org代发】

[Shawn Lin]

On 2019/10/4 8:53, Soeren Moch wrote:



On 04.10.19 02:01, Robin Murphy wrote:

On 2019-10-03 10:50 pm, Soeren Moch wrote:

According to the RockPro64 schematic [1] the rk3399 sdmmc controller is
connected to a microSD (TF card) slot, which cannot be switched to 1.8V.


Really? AFAICS the SDMMC0 wiring looks pretty much identical to the
NanoPC-T4 schematic (it's the same reference design, after all), and I
know that board can happily drive a UHS-I microSD card with 1.8v I/Os,
because mine's doing so right now.

Robin.

OK, the RockPro64 does not allow a card reset (power cycle) since
VCC3V0_SD is directly connected to VCC3V3_SYS (via R89555), the
SDMMC0_PWH_H signal is not connected. So the card fails to identify
itself after suspend or reboot when switched to 1.8V operation.



I believe we addressed this issue long time ago, please check:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6a11fc47f175c8d87018e89cb58e2d36c66534cb


Regards,
Soeren



So also configure the vcc_sdio regulator, which drives the i/o voltage
of the sdmmc controller, accordingly.

While at it, also remove the cap-mmc-highspeed property of the sdmmc
controller, since no mmc card can be connected here.

[1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf

Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support
for Rockpro64")
Signed-off-by: Soeren Moch 
---
Cc: Heiko Stuebner 
Cc: linux-rockc...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
   arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
index 2e44dae4865a..084f1d994a50 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
@@ -353,7 +353,7 @@
   regulator-name = "vcc_sdio";
   regulator-always-on;
   regulator-boot-on;
-    regulator-min-microvolt = <180>;
+    regulator-min-microvolt = <300>;
   regulator-max-microvolt = <300>;
   regulator-state-mem {
   regulator-on-in-suspend;
@@ -624,7 +624,6 @@

   &sdmmc {
   bus-width = <4>;
-    cap-mmc-highspeed;
   cap-sd-highspeed;
   cd-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
   disable-wp;
--
2.17.1


___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip




--
Best Regards
Shawn Lin

Re: [PATCH] scsi: ch: add include guard to chio.h

[Masahiro Yamada]

Hi Martin,

On Fri, Oct 4, 2019 at 10:59 AM Martin K. Petersen
 wrote:
>
>
> Masahiro,
>
> >> Add a header include guard just in case.
>
> Fine with me. Is it going through your tree or should I pick it up?



Could you please apply it to your tree?

Thanks.

-- 
Best Regards
Masahiro Yamada

Re: [PATCH tip/core/rcu 4/9] drivers/scsi: Replace rcu_swap_protected() with rcu_replace()

[Martin K. Petersen]

Paul,

No objections from me.

> + vpd_pg80 = rcu_replace(sdev->vpd_pg80, vpd_pg80,
> +lockdep_is_held(&sdev->inquiry_mutex));
> + vpd_pg83 = rcu_replace(sdev->vpd_pg83, vpd_pg83,
> +lockdep_is_held(&sdev->inquiry_mutex));

Just a heads-up that we have added a couple of additional VPD pages so
my 5.5 tree will need additional calls to be updated to rcu_replace().

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] sched/fair: scale quota and period without losing quota/period ratio precision

[Xuewei Zhang]

+cc neeln...@google.com and hao...@google.com, they helped a lot
for this issue. Sorry I forgot to include them when sending out the patch.

On Thu, Oct 3, 2019 at 5:55 PM Phil Auld  wrote:
>
> Hi,
>
> On Thu, Oct 03, 2019 at 05:12:43PM -0700 Xuewei Zhang wrote:
> > quota/period ratio is used to ensure a child task group won't get more
> > bandwidth than the parent task group, and is calculated as:
> > normalized_cfs_quota() = [(quota_us << 20) / period_us]
> >
> > If the quota/period ratio was changed during this scaling due to
> > precision loss, it will cause inconsistency between parent and child
> > task groups. See below example:
> > A userspace container manager (kubelet) does three operations:
> > 1) Create a parent cgroup, set quota to 1,000us and period to 10,000us.
> > 2) Create a few children cgroups.
> > 3) Set quota to 1,000us and period to 10,000us on a child cgroup.
> >
> > These operations are expected to succeed. However, if the scaling of
> > 147/128 happens before step 3), quota and period of the parent cgroup
> > will be changed:
> > new_quota: 1148437ns, 1148us
> > new_period: 11484375ns, 11484us
> >
> > And when step 3) comes in, the ratio of the child cgroup will be 104857,
> > which will be larger than the parent cgroup ratio (104821), and will
> > fail.
> >
> > Scaling them by a factor of 2 will fix the problem.
>
> I have no issues with the concept. We went around a bit about the actual
> numbers and made it an approximation.
>
> >
> > Fixes: 2e8e19226398 ("sched/fair: Limit sched_cfs_period_timer() loop to 
> > avoid hard lockup")
> > Signed-off-by: Xuewei Zhang 
> > ---
> >  kernel/sched/fair.c | 36 ++--
> >  1 file changed, 22 insertions(+), 14 deletions(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 83ab35e2374f..b3d3d0a231cd 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -4926,20 +4926,28 @@ static enum hrtimer_restart 
> > sched_cfs_period_timer(struct hrtimer *timer)
> >   if (++count > 3) {
> >   u64 new, old = ktime_to_ns(cfs_b->period);
> >
> > - new = (old * 147) / 128; /* ~115% */
> > - new = min(new, max_cfs_quota_period);
> > -
> > - cfs_b->period = ns_to_ktime(new);
> > -
> > - /* since max is 1s, this is limited to 1e9^2, which 
> > fits in u64 */
> > - cfs_b->quota *= new;
> > - cfs_b->quota = div64_u64(cfs_b->quota, old);
> > -
> > - pr_warn_ratelimited(
> > - "cfs_period_timer[cpu%d]: period too short, scaling up (new 
> > cfs_period_us %lld, cfs_quota_us = %lld)\n",
> > - smp_processor_id(),
> > - div_u64(new, NSEC_PER_USEC),
> > - div_u64(cfs_b->quota, NSEC_PER_USEC));
> > + /*
> > +  * Grow period by a factor of 2 to avoid lossing 
> > precision.
> > +  * Precision loss in the quota/period ratio can cause 
> > __cfs_schedulable
> > +  * to fail.
> > +  */
> > + new = old * 2;
> > + if (new < max_cfs_quota_period) {
>
> I don't like this part as much. There may be a value between
> max_cfs_quota_period/2 and max_cfs_quota_period that would get us out of
> the loop. Possibly in practice it won't matter but here you trigger the
> warning and take no action to keep it from continuing.
>
> Also, if you are actually hitting this then you might want to just start at
> a higher but proportional quota and period.

I'd like to do what you suggested. A quick idea would be to scale period to
max_cfs_quota_period, and scale quota proportionally. However the naive
implementation won't work under this edge case:
original:
quota: 500,000us  period: 570,000us
after scaling:
quota: 877,192us  period: 1,000,000us
original ratio: 919803
new ratio: 919802

To do this right, the code would have to keep an eye out on the precision loss,
and increase quota by 1us sometimes to cancel out the precision loss.

Also, I think this case is not that important. Because if we are
hitting this case, that
suggests the period is already >0.5s. And if we are still hitting
timeouts with a 0.5s
period, scaling it to 1s probably won't help much.
When this happens, I'd imagine the parent cgroup would have a LOT of child
cgroups. It might make sense for the userspace to create the parent cgroup with
1s period.

If you think automatically scaling 0.5s+ to 1s is still important, I'm
happy to stash
this patch, and send in another one that handles the 0.5+s -> 1s
scaling the right
way. :) Thanks!

Best regards,
Xuewei

>
>
> Cheers,
> Phil
>
> > + cfs_b->period = ns_to_ktime(new);
> > + cfs_b->quota *= 2;
> > +
> > + pr_warn_ratelimited(
> > 

Re: [PATCH] scsi: ch: add include guard to chio.h

[Martin K. Petersen]

Masahiro,

>> Add a header include guard just in case.

Fine with me. Is it going through your tree or should I pick it up?

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] qla2xxx: fix a potential NULL pointer dereference

[Martin K. Petersen]

> alloc_workqueue is not checked for errors and as a result,
> a potential NULL dereference could occur.

Himanshu: Please review!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 05/11] of: Ratify of_dma_configure() interface

[Rob Herring]

On Tue, Oct 1, 2019 at 10:43 AM Nicolas Saenz Julienne
 wrote:
>
> On Mon, 2019-09-30 at 16:24 -0500, Rob Herring wrote:
> > On Mon, Sep 30, 2019 at 8:32 AM Nicolas Saenz Julienne
> >  wrote:
> > > On Mon, 2019-09-30 at 05:57 -0700, Christoph Hellwig wrote:
> > > > On Thu, Sep 26, 2019 at 07:24:49PM -0500, Rob Herring wrote:
> > > > > -int of_dma_configure(struct device *dev, struct device_node *np, bool
> > > > > force_dma)
> > > > > +int of_dma_configure(struct device *dev, struct device_node *parent,
> > > > > bool
> > > > > force_dma)
> > > >
> > > > This creates a > 80 char line.
> > > >
> > > > >  {
> > > > > u64 dma_addr, paddr, size = 0;
> > > > > int ret;
> > > > > bool coherent;
> > > > > unsigned long offset;
> > > > > const struct iommu_ops *iommu;
> > > > > +   struct device_node *np;
> > > > > u64 mask;
> > > > >
> > > > > +   np = dev->of_node;
> > > > > +   if (!np)
> > > > > +   np = parent;
> > > > > +   if (!np)
> > > > > +   return -ENODEV;
> > > >
> > > > I have to say I find the older calling convention simpler to understand.
> > > > If we want to enforce the invariant I'd rather do that explicitly:
> > > >
> > > >   if (dev->of_node && np != dev->of_node)
> > > >   return -EINVAL;
> > >
> > > As is, this would break Freescale Layerscape fsl-mc bus' dma_configure():
> >
> > This may break PCI too for devices that have a DT node.
> >
> > > static int fsl_mc_dma_configure(struct device *dev)
> > > {
> > > struct device *dma_dev = dev;
> > >
> > > while (dev_is_fsl_mc(dma_dev))
> > > dma_dev = dma_dev->parent;
> > >
> > > return of_dma_configure(dev, dma_dev->of_node, 0);
> > > }
> > >
> > > But I think that with this series, given the fact that we now treat the 
> > > lack
> > > of
> > > dma-ranges as a 1:1 mapping instead of an error, we could rewrite the
> > > function
> > > like this:
> >
> > Now, I'm reconsidering allowing this abuse... It's better if the code
> > which understands the bus structure in DT for a specific bus passes in
> > the right thing. Maybe I should go back to Robin's version (below).
> > OTOH, the existing assumption that 'dma-ranges' was in the immediate
> > parent was an assumption on the bus structure which maybe doesn't
> > always apply.
> >
> > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > index a45261e21144..6951450bb8f3 100644
> > --- a/drivers/of/device.c
> > +++ b/drivers/of/device.c
> > @@ -98,12 +98,15 @@ int of_dma_configure(struct device *dev, struct
> > device_node *parent, bool force_
> > u64 mask;
> >
> > np = dev->of_node;
> > -   if (!np)
> > -   np = parent;
> > +   if (np)
> > +   parent = of_get_dma_parent(np);
> > +   else
> > +   np = of_node_get(parent);
> > if (!np)
> > return -ENODEV;
> >
> > -   ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
> > +   ret = of_dma_get_range(parent, &dma_addr, &paddr, &size);
> > +   of_node_put(parent);
> > if (ret < 0) {
> > /*
> >  * For legacy reasons, we have to assume some devices need
>
> I spent some time thinking about your comments and researching. I came to the
> realization that both these solutions break the usage in
> drivers/gpu/drm/sun4i/sun4i_backend.c:805. In that specific case both
> 'dev->of_node' and 'parent' exist yet the device receiving the configuration
> and 'parent' aren't related in any way.

I knew there was some reason I didn't like those virtual DT nodes...

That does seem to be the oddest case. Several of the others are just
non-DT child platform devices. Perhaps we need a "copy the DMA config
from another struct device (or parent struct device)" function to
avoid using a DT function on a non-DT device.

> IOW we can't just use 'dev->of_node' as a starting point to walk upwards the
> tree. We always have to respect whatever DT node the bus provided, and start
> there. This clashes with the current solutions, as they are based on the fact
> that we can use dev->of_node when present.

Yes, you are right.

> My guess at this point, if we're forced to honor that behaviour, is that we
> have to create a new API for the PCI use case. Something the likes of
> of_dma_configure_parent().

I think of_dma_configure just has to work with the device_node of
either the device or the device parent and dev->of_node is never used
unless the caller sets it.

Rob

[PATCH] ARM: dts: am3874-iceboard: Fix 'i2c-mux-idle-disconnect' usage

[Andrey Smirnov]

According to
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt,
i2c-mux-idle-disconnect is a property of a parent node since it
pertains to the mux/switch as a whole, so move it there and drop all
of the concurrences in child nodes.

Fixes: d031773169df ("ARM: dts: Adds device tree file for McGill's IceBoard, 
based on TI AM3874")
Signed-off-by: Andrey Smirnov 
Cc: Benoît Cousson 
Cc: Tony Lindgren 
Cc: Graeme Smecher 
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---

This is purely a drive-by fix, since it concerns the HW I've never
heard of before. However I was working with PCA9548
(vf610-zii-scu4-aib is my HW) and looking at various users in the
kernel, when this code caught my eye. Apologies for the noise if this
fix is somehow bogus.

In case that it matters this patch is based on top of 5.4-rc1.

Thanks,
Andrey Smirnov

 arch/arm/boot/dts/am3874-iceboard.dts | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/am3874-iceboard.dts 
b/arch/arm/boot/dts/am3874-iceboard.dts
index 883fb85135d4..1b4b2b0500e4 100644
--- a/arch/arm/boot/dts/am3874-iceboard.dts
+++ b/arch/arm/boot/dts/am3874-iceboard.dts
@@ -111,13 +111,13 @@
reg = <0x70>;
#address-cells = <1>;
#size-cells = <0>;
+   i2c-mux-idle-disconnect;
 
i2c@0 {
/* FMC A */
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
-   i2c-mux-idle-disconnect;
};
 
i2c@1 {
@@ -125,7 +125,6 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
-   i2c-mux-idle-disconnect;
};
 
i2c@2 {
@@ -133,7 +132,6 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
-   i2c-mux-idle-disconnect;
};
 
i2c@3 {
@@ -141,7 +139,6 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
-   i2c-mux-idle-disconnect;
};
 
i2c@4 {
@@ -149,14 +146,12 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
-   i2c-mux-idle-disconnect;
};
 
i2c@5 {
#address-cells = <1>;
#size-cells = <0>;
reg = <5>;
-   i2c-mux-idle-disconnect;
 
ina230@40 { compatible = "ti,ina230"; reg = <0x40>; 
shunt-resistor = <5000>; };
ina230@41 { compatible = "ti,ina230"; reg = <0x41>; 
shunt-resistor = <5000>; };
@@ -182,14 +177,12 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <6>;
-   i2c-mux-idle-disconnect;
};
 
i2c@7 {
#address-cells = <1>;
#size-cells = <0>;
reg = <7>;
-   i2c-mux-idle-disconnect;
 
u41: pca9575@20 {
compatible = "nxp,pca9575";
-- 
2.21.0

RE: [PATCH 0/2] peci: aspeed: Add AST2600 compatible

[ChiaWei Wang]

Sure. We will re-submit the patches with the revision suggested.
Thanks.

Regards,
Chiawei

* Email Confidentiality Notice 
DISCLAIMER:
This message (and any attachments) may contain legally privileged and/or other 
confidential information. If you have received it in error, please notify the 
sender by reply e-mail and immediately delete the e-mail and any attachments 
without copying or disclosing the contents. Thank you.


-Original Message-
From: Jae Hyun Yoo [mailto:jae.hyun@linux.intel.com] 
Sent: Friday, October 4, 2019 12:20 AM
To: ChiaWei Wang ; Joel Stanley 
Cc: Jason M Biils ; Rob Herring 
; Mark Rutland ; Andrew Jeffery 
; linux-aspeed ; OpenBMC 
Maillist ; devicetree ; 
Linux ARM ; Linux Kernel Mailing List 
; Ryan Chen 
Subject: Re: [PATCH 0/2] peci: aspeed: Add AST2600 compatible

On 10/2/2019 7:35 PM, ChiaWei Wang wrote:
> Hi Jae Hyun,
> 
> Thanks for the feedback.
> For now should I use GitHub pull-request to submit the patches of 
> PECI-related change to OpenBMC dev-5.3 tree only?

You could submit this patch series to OpenBMC mailing list with [PATCH linux 
dev-5.3] prefix.

Thanks,

Jae

Re: [PATCH v2 7/9] arm64: dts: qcom: msm8998: Add PSCI cpuidle low power states

[Amit Kucheria]

On Wed, Oct 2, 2019 at 11:48 PM Jeffrey Hugo  wrote:
>
> On Wed, Oct 2, 2019 at 3:27 AM Niklas Cassel  wrote:
> >
> > On Wed, Oct 02, 2019 at 11:19:50AM +0200, Niklas Cassel wrote:
> > > On Mon, Sep 30, 2019 at 04:20:15PM -0600, Jeffrey Hugo wrote:
> > > > Amit, the merged version of the below change causes a boot failure
> > > > (nasty hang, sometimes with RCU stalls) on the msm8998 laptops.  Oddly
> > > > enough, it seems to be resolved if I remove the cpu-idle-states
> > > > property from one of the cpu nodes.
> > > >
> > > > I see no issues with the msm8998 MTP.
> > >
> > > Hello Jeffrey, Amit,
> > >
> > > If the PSCI idle states work properly on the msm8998 devboard (MTP),
> > > but causes crashes on msm8998 laptops, the only logical change is
> > > that the PSCI firmware is different between the two devices.
> >
> > Since the msm8998 laptops boot using ACPI, perhaps these laptops
> > doesn't support PSCI/have any PSCI firmware at all.
>
> They have PSCI.  If there was no PSCI, I would expect the PSCI
> get_version request from Linux to fail, and all PSCI functionality to
> be disabled.
>
> However, your mention about ACPI sparked a thought.  ACPI describes
> the idle states, along with the PSCI info, in the ACPI0007 devices.
> Those exist on the laptops, and the info mostly correlates with Amit's
> patch (ACPI seems to be a bit more conservative about the latencies,
> and describes one additional deeper state).  However, upon a detailed
> analysis of the ACPI description, I did find something relevant - the
> retention state is not enabled.
>
> So, I hacked out the retention state from Amit's patch, and I did not
> observe a hang.  I used sysfs, and appeared able to validate that the
> power collapse state was being used successfully.

Interesting that the shallower sleep state was causing problems.
Usually, it is the deeper states that cause problems. So you plan to
override the idle states table in the board-specific DT?

Why does the platform even rely on DT? Shouldn't we use the ACPI tables instead?

> I'm guessing that something is weird with the laptops, where the CPUs
> can go into retention, but not come out, thus causing issues.
>
> I'll post a patch to fix up the laptops.  Thanks for all the help.

[PATCH 0/2] gpio: brcm: XGS iProc GPIO driver

[Chris Packham]

This is ported this from Broadcom's XLDK. There seem to be 3 different
IP blocks for 3 separate banks of GPIOs in the iProc chips.

I've dropped everything except support for the Chip Common A GPIO
controller because the other blocks actually seem to be supportable with
other drivers. The driver itself is halfway between pinctrl-nsp-gpio.c
and pinctrl-iproc-gpio.c.

Chris Packham (2):
  dt-bindings: gpio: brcm: Add bindings for xgs-iproc
  gpio: Add xgs-iproc driver

 .../bindings/gpio/brcm,xgs-iproc.txt  |  41 ++
 drivers/gpio/Kconfig  |   9 +
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-xgs-iproc.c | 422 ++
 4 files changed, 473 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.txt
 create mode 100644 drivers/gpio/gpio-xgs-iproc.c

-- 
2.23.0

[PATCH 1/2] dt-bindings: gpio: brcm: Add bindings for xgs-iproc

[Chris Packham]

This GPIO controller is present on a number of Broadcom switch ASICs
with integrated SoCs. It is similar to the nsp-gpio and iproc-gpio
blocks but different enough to require a separate driver.

Signed-off-by: Chris Packham 
---
 .../bindings/gpio/brcm,xgs-iproc.txt  | 41 +++
 1 file changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.txt

diff --git a/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.txt 
b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.txt
new file mode 100644
index ..328b844c82dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.txt
@@ -0,0 +1,41 @@
+Broadcom XGS iProc GPIO controller
+
+This controller is the Chip Common A GPIO present on a number of Broadcom
+switch ASICs with integrated SoCs.
+
+Required properties:
+- compatible:
+Must be "brcm,iproc-gpio-cca"
+
+- reg:
+The first region defines the base I/O address containing
+the GPIO controller registers. The second region defines
+the I/O address containing the Chip Common A interrupt
+registers.
+
+Optional properties:
+
+- interrupts:
+The interrupt shared by all GPIO lines for this controller.
+
+- #interrupt-cells:
+Should be <2>.  The first cell is the GPIO number, the second should 
specify
+flags.
+
+See also 
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+- interrupt-controller:
+Marks the device node as an interrupt controller
+
+Example:
+   gpioa: gpio@1860 {
+   compatible = "brcm,iproc-gpio-cca";
+   #gpio-cells = <2>;
+   reg = <0x1860 0x50>,
+ <0x1800 0x50>;
+   ngpios = <12>;
+   gpio-controller;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   interrupts = ;
+   };
-- 
2.23.0

[PATCH 2/2] gpio: Add xgs-iproc driver

[Chris Packham]

This driver supports the Chip Common A GPIO controller present on a
number of Broadcom switch ASICs with integrated SoCs. The controller is
similar to the pinctrl-nsp-gpio and pinctrl-iproc-gpio blocks but
different enough that a separate driver is required.

This has been ported from Broadcom's XLDK 5.0.3 retaining only the CCA
support (pinctrl-iproc-gpio covers CCB).

Signed-off-by: Chris Packham 
---
 drivers/gpio/Kconfig  |   9 +
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-xgs-iproc.c | 422 ++
 3 files changed, 432 insertions(+)
 create mode 100644 drivers/gpio/gpio-xgs-iproc.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 38e096e6925f..4b3c0f8397d7 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -156,6 +156,15 @@ config GPIO_BRCMSTB
help
  Say yes here to enable GPIO support for Broadcom STB (BCM7XXX) SoCs.
 
+config GPIO_XGS_IPROC
+   tristate "BRCM XGS iProc GPIO support"
+   depends on OF_GPIO && (ARCH_BCM_IPROC || COMPILE_TEST)
+   select GPIO_GENERIC
+   select GPIOLIB_IRQCHIP
+   default ARCH_BCM_IPROC
+   help
+ Say yes here to enable GPIO support for Broadcom XGS iProc SoCs.
+
 config GPIO_CADENCE
tristate "Cadence GPIO support"
depends on OF_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index d2fd19c15bae..3783c3d43fbe 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_GPIO_BCM_KONA)   += gpio-bcm-kona.o
 obj-$(CONFIG_GPIO_BD70528) += gpio-bd70528.o
 obj-$(CONFIG_GPIO_BD9571MWV)   += gpio-bd9571mwv.o
 obj-$(CONFIG_GPIO_BRCMSTB) += gpio-brcmstb.o
+obj-$(CONFIG_GPIO_XGS_IPROC)   += gpio-xgs-iproc.o
 obj-$(CONFIG_GPIO_BT8XX)   += gpio-bt8xx.o
 obj-$(CONFIG_GPIO_CADENCE) += gpio-cadence.o
 obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o
diff --git a/drivers/gpio/gpio-xgs-iproc.c b/drivers/gpio/gpio-xgs-iproc.c
new file mode 100644
index ..12656ca7b9d4
--- /dev/null
+++ b/drivers/gpio/gpio-xgs-iproc.c
@@ -0,0 +1,422 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Broadcom Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CCA_INT_F_GPIOINT  BIT(0)
+#define CCA_INT_STS0x20
+#define CCA_INT_MASK   0x24
+
+#define GPIO_CCA_DIN   0x0
+#define GPIO_CCA_DOUT  0x4
+#define GPIO_CCA_OUT_EN0x8
+#define GPIO_CCA_INT_LEVEL 0x10
+#define GPIO_CCA_INT_LEVEL_MASK0x14
+#define GPIO_CCA_INT_EVENT 0x18
+#define GPIO_CCA_INT_EVENT_MASK0x1C
+#define GPIO_CCA_INT_EDGE  0x24
+
+struct iproc_gpio_chip {
+   struct device *dev;
+   void __iomem *base;
+   void __iomem *intr;
+   struct gpio_chip gc;
+   struct irq_chip irqchip;
+   spinlock_t lock;
+   struct irq_domain *irq_domain;
+};
+
+static u32 iproc_gpio_readl(struct iproc_gpio_chip *chip, int reg)
+{
+   return readl(chip->base + reg);
+}
+
+static void iproc_gpio_writel(struct iproc_gpio_chip *chip, u32 val, int reg)
+{
+   writel(val, chip->base + reg);
+}
+
+/* returns the corresponding gpio register bit */
+static int iproc_irq_to_gpio(struct iproc_gpio_chip *chip, u32 irq)
+{
+   struct irq_data *data = irq_domain_get_irq_data(chip->irq_domain, irq);
+
+   return data->hwirq;
+}
+
+static void iproc_gpio_irq_ack(struct irq_data *d)
+{
+   u32 irq = d->irq;
+   struct iproc_gpio_chip *chip = irq_get_chip_data(irq);
+   int pin;
+   u32 irq_type, event_status = 0;
+
+   pin = iproc_irq_to_gpio(chip, d->irq);
+   irq_type = irq_get_trigger_type(irq);
+   if (irq_type & IRQ_TYPE_EDGE_BOTH) {
+   event_status |= BIT(pin);
+   iproc_gpio_writel(chip, event_status, GPIO_CCA_INT_EVENT);
+   }
+}
+
+static void iproc_gpio_irq_unmask(struct irq_data *d)
+{
+   u32 irq = d->irq;
+   struct iproc_gpio_chip *chip = irq_get_chip_data(irq);
+   int pin;
+   u32 int_mask, irq_type, event_mask;
+
+   pin = iproc_irq_to_gpio(chip, irq);
+   irq_type = irq_get_trigger_type(irq);
+   event_mask = iproc_gpio_readl(chip, GPIO_CCA_INT_EVENT_MASK);
+   int_mask = iproc_gpio_readl(chip, GPIO_CCA_INT_LEVEL_MASK);
+
+   if (irq_type & IRQ_TYPE_EDGE_BOTH) {
+   event_mask |= 1 << pin;
+   iproc_gpio_writel(chip, event_mask, GPIO_CCA_INT_EVENT_MASK);
+   } else {
+   int_mask |= 1 << pin;
+   iproc_gpio_writel(chip, int_mask, GPIO_CCA_INT_LEVEL_MASK);
+   }
+}
+
+static void iproc_gpio_irq_mask(struct irq_data *d)
+{
+   u32 irq = d->irq;
+   struct iproc_gpio_chip *chip = irq_get_chip_data(irq);
+   int pin;

[RESEND PATCH v3 9/9] hacking: Move DEBUG_FS to 'Generic Kernel Debugging Instruments'

[Changbin Du]

DEBUG_FS does not belong to 'Compile-time checks and compiler options'.

Signed-off-by: Changbin Du 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
---
 lib/Kconfig.debug | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 12727e12a28b..82cb1bcf07a8 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -286,18 +286,6 @@ config READABLE_ASM
   to keep kernel developers who have to stare a lot at assembler 
listings
   sane.
 
-config DEBUG_FS
-   bool "Debug Filesystem"
-   help
- debugfs is a virtual file system that kernel developers use to put
- debugging files into.  Enable this option to be able to read and
- write to these files.
-
- For detailed documentation on the debugfs API, see
- Documentation/filesystems/.
-
- If unsure, say N.
-
 config HEADERS_INSTALL
bool "Install uapi headers to usr/include"
depends on !UML
@@ -445,6 +433,18 @@ config MAGIC_SYSRQ_SERIAL
  This option allows you to decide whether you want to enable the
  magic SysRq key.
 
+config DEBUG_FS
+   bool "Debug Filesystem"
+   help
+ debugfs is a virtual file system that kernel developers use to put
+ debugging files into.  Enable this option to be able to read and
+ write to these files.
+
+ For detailed documentation on the debugfs API, see
+ Documentation/filesystems/.
+
+ If unsure, say N.
+
 source "lib/Kconfig.kgdb"
 
 source "lib/Kconfig.ubsan"
-- 
2.20.1

[RESEND PATCH v3 7/9] hacking: Create a submenu for scheduler debugging options

[Changbin Du]

Create a submenu 'Scheduler Debugging' for scheduler debugging options.

Signed-off-by: Changbin Du 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
---
 lib/Kconfig.debug | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2cf52b3b5726..6db178071743 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -973,6 +973,8 @@ config WQ_WATCHDOG
 
 endmenu # "Debug lockups and hangs"
 
+menu "Scheduler Debugging"
+
 config SCHED_DEBUG
bool "Collect scheduler debugging info"
depends on DEBUG_KERNEL && PROC_FS
@@ -999,6 +1001,8 @@ config SCHEDSTATS
  application, you can say N to avoid the very slight overhead
  this adds.
 
+endmenu
+
 config DEBUG_TIMEKEEPING
bool "Enable extra timekeeping sanity checking"
help
-- 
2.20.1

[RESEND PATCH v3 1/9] hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging Instruments'

[Changbin Du]

Group generic kernel debugging instruments sysrq/kgdb/ubsan together into
a new submenu.

Signed-off-by: Changbin Du 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
---
 lib/Kconfig.debug | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index a0250e53954a..157db30e626d 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -401,6 +401,8 @@ config DEBUG_FORCE_WEAK_PER_CPU
 
 endmenu # "Compiler options"
 
+menu "Generic Kernel Debugging Instruments"
+
 config MAGIC_SYSRQ
bool "Magic SysRq key"
depends on !UML
@@ -434,6 +436,12 @@ config MAGIC_SYSRQ_SERIAL
  This option allows you to decide whether you want to enable the
  magic SysRq key.
 
+source "lib/Kconfig.kgdb"
+
+source "lib/Kconfig.ubsan"
+
+endmenu
+
 config DEBUG_KERNEL
bool "Kernel debugging"
help
@@ -2095,10 +2103,6 @@ config BUG_ON_DATA_CORRUPTION
 
 source "samples/Kconfig"
 
-source "lib/Kconfig.kgdb"
-
-source "lib/Kconfig.ubsan"
-
 config ARCH_HAS_DEVMEM_IS_ALLOWED
bool
 
-- 
2.20.1

[RESEND PATCH v3 0/9] hacking: make kconfig menu 'kernel hacking' better structurized

[Changbin Du]

This series is a trivial improvment for the layout of 'kernel hacking'
configuration menu. Now we have many items in it which makes takes
a little time to look up them since they are not well structurized yet.

Early discussion is here:
https://lkml.org/lkml/2019/9/1/39

This is a preview:

  │ ┌─┐ 
│  
  │ │printk and dmesg options  --->   │ 
│  
  │ │Compile-time checks and compiler options  --->   │ 
│  
  │ │Generic Kernel Debugging Instruments  --->   │ 
│  
  │ │-*- Kernel debugging │ 
│  
  │ │[*]   Miscellaneous debug code   │ 
│  
  │ │Memory Debugging  --->   │ 
│  
  │ │[ ] Debug shared IRQ handlers│ 
│  
  │ │Debug Oops, Lockups and Hangs  --->  │ 
│  
  │ │Scheduler Debugging  --->│ 
│  
  │ │[*] Enable extra timekeeping sanity checking │ 
│  
  │ │Lock Debugging (spinlocks, mutexes, etc...)  --->│ 
│  
  │ │-*- Stack backtrace support  │ 
│  
  │ │[ ] Warn for all uses of unseeded randomness │ 
│  
  │ │[ ] kobject debugging│ 
│  
  │ │Debug kernel data structures  --->   │ 
│  
  │ │[ ] Debug credential management  │ 
│  
  │ │RCU Debugging  --->  │ 
│  
  │ │[ ] Force round-robin CPU selection for unbound work items   │ 
│  
  │ │[ ] Force extended block device numbers and spread them  │ 
│  
  │ │[ ] Enable CPU hotplug state control │ 
│  
  │ │[*] Latency measuring infrastructure │ 
│  
  │ │[*] Tracers  --->│ 
│  
  │ │[ ] Remote debugging over FireWire early on boot │ 
│  
  │ │[*] Sample kernel code  ---> │ 
│  
  │ │[*] Filter access to /dev/mem│ 
│  
  │ │[ ]   Filter I/O access to /dev/mem  │ 
│  
  │ │[ ] Additional debug code for syzbot │ 
│  
  │ │x86 Debugging  --->  │ 
│  
  │ │Kernel Testing and Coverage  --->│ 
│  
  │ │ │ 
│  
  │ │ │ 
│  
  │ └─┘ 
│  
  
├─┤ 
 
  │  < Exit >< Help >< Save >< Load >   
│  
  
└─┘ 

v3:
  o change subject prefix.
v2:
  o rebase to linux-next.
  o move DEBUG_FS to 'Generic Kernel Debugging Instruments'
  o move DEBUG_NOTIFIERS to 'Debug kernel data structures'

Changbin Du (9):
  hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging
Instruments'
  hacking: Create submenu for arch special debugging options
  hacking: Group kernel data structures debugging together
  hacking: Move kernel testing and coverage options to same submenu
  hacking: Move Oops into 'Lockups and Hangs'
  hacking: Move SCHED_STACK_END_CHECK after DEBUG_STACK_USAGE
  hacking: Create a submenu for scheduler debugging options
  hacking: Move DEBUG_BUGVERBOSE to 'printk and dmesg options'
  hacking: Move DEBUG_FS to 'Generic Kernel Debugging Instruments'

 lib/Kconfig.debug | 663 --
 1 file changed, 342 insertions(+), 321 deletions(-)

-- 
2.20.1

[RESEND PATCH v3 6/9] hacking: Move SCHED_STACK_END_CHECK after DEBUG_STACK_USAGE

[Changbin Du]

They are both memory debug options to debug kernel stack issues.

Signed-off-by: Changbin Du 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
---
 lib/Kconfig.debug | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 389876ee49d8..2cf52b3b5726 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -634,6 +634,18 @@ config DEBUG_STACK_USAGE
 
  This option will slow down process creation somewhat.
 
+config SCHED_STACK_END_CHECK
+   bool "Detect stack corruption on calls to schedule()"
+   depends on DEBUG_KERNEL
+   default n
+   help
+ This option checks for a stack overrun on calls to schedule().
+ If the stack end location is found to be over written always panic as
+ the content of the corrupted region can no longer be trusted.
+ This is to ensure no erroneous behaviour occurs which could result in
+ data corruption or a sporadic crash at a later stage once the region
+ is examined. The runtime overhead introduced is minimal.
+
 config DEBUG_VM
bool "Debug VM"
depends on DEBUG_KERNEL
@@ -987,18 +999,6 @@ config SCHEDSTATS
  application, you can say N to avoid the very slight overhead
  this adds.
 
-config SCHED_STACK_END_CHECK
-   bool "Detect stack corruption on calls to schedule()"
-   depends on DEBUG_KERNEL
-   default n
-   help
- This option checks for a stack overrun on calls to schedule().
- If the stack end location is found to be over written always panic as
- the content of the corrupted region can no longer be trusted.
- This is to ensure no erroneous behaviour occurs which could result in
- data corruption or a sporadic crash at a later stage once the region
- is examined. The runtime overhead introduced is minimal.
-
 config DEBUG_TIMEKEEPING
bool "Enable extra timekeeping sanity checking"
help
-- 
2.20.1

[RESEND PATCH v3 3/9] hacking: Group kernel data structures debugging together

[Changbin Du]

Group these similar runtime data structures verification options together.

Signed-off-by: Changbin Du 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
---
 lib/Kconfig.debug | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b29a486db38b..f1de5e79573b 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1357,6 +1357,8 @@ config DEBUG_BUGVERBOSE
  of the BUG call as well as the EIP and oops trace.  This aids
  debugging but costs about 70-100K of memory.
 
+menu "Debug kernel data structures"
+
 config DEBUG_LIST
bool "Debug linked list manipulation"
depends on DEBUG_KERNEL || BUG_ON_DATA_CORRUPTION
@@ -1396,6 +1398,18 @@ config DEBUG_NOTIFIERS
  This is a relatively cheap check but if you care about maximum
  performance, say N.
 
+config BUG_ON_DATA_CORRUPTION
+   bool "Trigger a BUG when data corruption is detected"
+   select DEBUG_LIST
+   help
+ Select this option if the kernel should BUG when it encounters
+ data corruption in kernel memory structures when they get checked
+ for validity.
+
+ If unsure, say N.
+
+endmenu
+
 config DEBUG_CREDENTIALS
bool "Debug credential management"
depends on DEBUG_KERNEL
@@ -2091,16 +2105,6 @@ config MEMTEST
memtest=17, mean do 17 test patterns.
  If you are unsure how to answer this question, answer N.
 
-config BUG_ON_DATA_CORRUPTION
-   bool "Trigger a BUG when data corruption is detected"
-   select DEBUG_LIST
-   help
- Select this option if the kernel should BUG when it encounters
- data corruption in kernel memory structures when they get checked
- for validity.
-
- If unsure, say N.
-
 source "samples/Kconfig"
 
 config ARCH_HAS_DEVMEM_IS_ALLOWED
-- 
2.20.1

[RESEND PATCH v3 2/9] hacking: Create submenu for arch special debugging options

[Changbin Du]

The arch special options are a little long, so create a submenu for them.

Signed-off-by: Changbin Du 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
---
 lib/Kconfig.debug | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 157db30e626d..b29a486db38b 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2148,6 +2148,10 @@ config DEBUG_AID_FOR_SYZBOT
help
  This option is intended for testing by syzbot.
 
+menu "$(SRCARCH) Debugging"
+
 source "arch/$(SRCARCH)/Kconfig.debug"
 
+endmenu
+
 endmenu # Kernel hacking
-- 
2.20.1

[RESEND PATCH v3 8/9] hacking: Move DEBUG_BUGVERBOSE to 'printk and dmesg options'

[Changbin Du]

I think DEBUG_BUGVERBOSE is a dmesg option which gives more debug info
to dmesg.

Signed-off-by: Changbin Du 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
---
 lib/Kconfig.debug | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 6db178071743..12727e12a28b 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -164,6 +164,15 @@ config DYNAMIC_DEBUG
  See Documentation/admin-guide/dynamic-debug-howto.rst for additional
  information.
 
+config DEBUG_BUGVERBOSE
+   bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
+   depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+   default y
+   help
+ Say Y here to make BUG() panics output the file name and line number
+ of the BUG call as well as the EIP and oops trace.  This aids
+ debugging but costs about 70-100K of memory.
+
 endmenu # "printk and dmesg options"
 
 menu "Compile-time checks and compiler options"
@@ -1305,15 +1314,6 @@ config DEBUG_KOBJECT_RELEASE
 config HAVE_DEBUG_BUGVERBOSE
bool
 
-config DEBUG_BUGVERBOSE
-   bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-   depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
-   default y
-   help
- Say Y here to make BUG() panics output the file name and line number
- of the BUG call as well as the EIP and oops trace.  This aids
- debugging but costs about 70-100K of memory.
-
 menu "Debug kernel data structures"
 
 config DEBUG_LIST
-- 
2.20.1

[RESEND PATCH v3 4/9] hacking: Move kernel testing and coverage options to same submenu

[Changbin Du]

Move error injection, coverage, testing, kunit options to a new submenu
'Kernel Testing and Coverage'. They are all for test purpose.

Signed-off-by: Changbin Du 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
---
 lib/Kconfig.debug | 499 +++---
 1 file changed, 252 insertions(+), 247 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index f1de5e79573b..9911e5c6eafa 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -766,53 +766,6 @@ source "lib/Kconfig.kasan"
 
 endmenu # "Memory Debugging"
 
-config ARCH_HAS_KCOV
-   bool
-   help
- An architecture should select this when it can successfully
- build and run with CONFIG_KCOV. This typically requires
- disabling instrumentation for some early boot code.
-
-config CC_HAS_SANCOV_TRACE_PC
-   def_bool $(cc-option,-fsanitize-coverage=trace-pc)
-
-config KCOV
-   bool "Code coverage for fuzzing"
-   depends on ARCH_HAS_KCOV
-   depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
-   select DEBUG_FS
-   select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
-   help
- KCOV exposes kernel code coverage information in a form suitable
- for coverage-guided fuzzing (randomized testing).
-
- If RANDOMIZE_BASE is enabled, PC values will not be stable across
- different machines and across reboots. If you need stable PC values,
- disable RANDOMIZE_BASE.
-
- For more details, see Documentation/dev-tools/kcov.rst.
-
-config KCOV_ENABLE_COMPARISONS
-   bool "Enable comparison operands collection by KCOV"
-   depends on KCOV
-   depends on $(cc-option,-fsanitize-coverage=trace-cmp)
-   help
- KCOV also exposes operands of every comparison in the instrumented
- code along with operand sizes and PCs of the comparison instructions.
- These operands can be used by fuzzing engines to improve the quality
- of fuzzing coverage.
-
-config KCOV_INSTRUMENT_ALL
-   bool "Instrument all code by default"
-   depends on KCOV
-   default y
-   help
- If you are doing generic system call fuzzing (like e.g. syzkaller),
- then you will want to instrument the whole kernel and you should
- say y here. If you are doing more targeted fuzzing (like e.g.
- filesystem fuzzing with AFL) then you will want to enable coverage
- for more specific subsets of files, and should say n here.
-
 config DEBUG_SHIRQ
bool "Debug shared IRQ handlers"
depends on DEBUG_KERNEL
@@ -1482,164 +1435,6 @@ config CPU_HOTPLUG_STATE_CONTROL
 
  Say N if your are unsure.
 
-config NOTIFIER_ERROR_INJECTION
-   tristate "Notifier error injection"
-   depends on DEBUG_KERNEL
-   select DEBUG_FS
-   help
- This option provides the ability to inject artificial errors to
- specified notifier chain callbacks. It is useful to test the error
- handling of notifier call chain failures.
-
- Say N if unsure.
-
-config PM_NOTIFIER_ERROR_INJECT
-   tristate "PM notifier error injection module"
-   depends on PM && NOTIFIER_ERROR_INJECTION
-   default m if PM_DEBUG
-   help
- This option provides the ability to inject artificial errors to
- PM notifier chain callbacks.  It is controlled through debugfs
- interface /sys/kernel/debug/notifier-error-inject/pm
-
- If the notifier call chain should be failed with some events
- notified, write the error code to "actions//error".
-
- Example: Inject PM suspend error (-12 = -ENOMEM)
-
- # cd /sys/kernel/debug/notifier-error-inject/pm/
- # echo -12 > actions/PM_SUSPEND_PREPARE/error
- # echo mem > /sys/power/state
- bash: echo: write error: Cannot allocate memory
-
- To compile this code as a module, choose M here: the module will
- be called pm-notifier-error-inject.
-
- If unsure, say N.
-
-config OF_RECONFIG_NOTIFIER_ERROR_INJECT
-   tristate "OF reconfig notifier error injection module"
-   depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
-   help
- This option provides the ability to inject artificial errors to
- OF reconfig notifier chain callbacks.  It is controlled
- through debugfs interface under
- /sys/kernel/debug/notifier-error-inject/OF-reconfig/
-
- If the notifier call chain should be failed with some events
- notified, write the error code to "actions//error".
-
- To compile this code as a module, choose M here: the module will
- be called of-reconfig-notifier-error-inject.
-
- If unsure, say N.
-
-config NETDEV_NOTIFIER_ERROR_INJECT
-   tristate "Netdev notifier error injection module"
-   depends on NET && NOTIFIER_ERROR_INJECTION
-   help
- This option provides the ability to inject artificial errors to
- netdevi

[RESEND PATCH v3 5/9] hacking: Move Oops into 'Lockups and Hangs'

[Changbin Du]

They are similar options so place them together.

Signed-off-by: Changbin Du 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
---
 lib/Kconfig.debug | 58 +++
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 9911e5c6eafa..389876ee49d8 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -775,7 +775,35 @@ config DEBUG_SHIRQ
  Drivers ought to be able to handle interrupts coming in at those
  points; some don't and need to be caught.
 
-menu "Debug Lockups and Hangs"
+menu "Debug Oops, Lockups and Hangs"
+
+config PANIC_ON_OOPS
+   bool "Panic on Oops"
+   help
+ Say Y here to enable the kernel to panic when it oopses. This
+ has the same effect as setting oops=panic on the kernel command
+ line.
+
+ This feature is useful to ensure that the kernel does not do
+ anything erroneous after an oops which could result in data
+ corruption or other issues.
+
+ Say N if unsure.
+
+config PANIC_ON_OOPS_VALUE
+   int
+   range 0 1
+   default 0 if !PANIC_ON_OOPS
+   default 1 if PANIC_ON_OOPS
+
+config PANIC_TIMEOUT
+   int "panic timeout"
+   default 0
+   help
+ Set the timeout value (in seconds) until a reboot occurs when the
+ the kernel panics. If n = 0, then we wait forever. A timeout
+ value n > 0 will wait n seconds before rebooting, while a timeout
+ value n < 0 will reboot immediately.
 
 config LOCKUP_DETECTOR
bool
@@ -933,34 +961,6 @@ config WQ_WATCHDOG
 
 endmenu # "Debug lockups and hangs"
 
-config PANIC_ON_OOPS
-   bool "Panic on Oops"
-   help
- Say Y here to enable the kernel to panic when it oopses. This
- has the same effect as setting oops=panic on the kernel command
- line.
-
- This feature is useful to ensure that the kernel does not do
- anything erroneous after an oops which could result in data
- corruption or other issues.
-
- Say N if unsure.
-
-config PANIC_ON_OOPS_VALUE
-   int
-   range 0 1
-   default 0 if !PANIC_ON_OOPS
-   default 1 if PANIC_ON_OOPS
-
-config PANIC_TIMEOUT
-   int "panic timeout"
-   default 0
-   help
- Set the timeout value (in seconds) until a reboot occurs when the
- the kernel panics. If n = 0, then we wait forever. A timeout
- value n > 0 will wait n seconds before rebooting, while a timeout
- value n < 0 will reboot immediately.
-
 config SCHED_DEBUG
bool "Collect scheduler debugging info"
depends on DEBUG_KERNEL && PROC_FS
-- 
2.20.1

[v1 PATCH 0/2] Cleanup isa string access and print

[Atish Patra]

This is a cleanup series addressing issues around isa string accesses
and prints. Patch 1 is actually a revised patch as a result of discussion
in the following thread.

http://lists.infradead.org/pipermail/linux-riscv/2019-September/006702.html

Patch 2 is an additional cleanup that tries to consolidate all isa
string related checks.

Atish Patra (2):
RISC-V: Remove unsupported isa string info print
RISC-V: Consolidate isa correctness check

arch/riscv/include/asm/processor.h |  1 +
arch/riscv/kernel/cpu.c| 85 --
arch/riscv/kernel/cpufeature.c |  4 +-
arch/riscv/kernel/smpboot.c|  4 ++
4 files changed, 39 insertions(+), 55 deletions(-)

--
2.21.0

[v1 PATCH 2/2] RISC-V: Consolidate isa correctness check

[Atish Patra]

Currently, isa string is read and checked for correctness at multiple
places.

Consolidate them into one function and use it only during early bootup.
In case of a incorrect isa string, the cpu shouldn't boot at all.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/processor.h |  1 +
 arch/riscv/kernel/cpu.c| 40 ++
 arch/riscv/kernel/cpufeature.c |  4 +--
 arch/riscv/kernel/smpboot.c|  4 +++
 4 files changed, 36 insertions(+), 13 deletions(-)

diff --git a/arch/riscv/include/asm/processor.h 
b/arch/riscv/include/asm/processor.h
index f539149d04c2..189bf98f9a3f 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -74,6 +74,7 @@ static inline void wait_for_interrupt(void)
 }
 
 struct device_node;
+int riscv_read_check_isa(struct device_node *node, const char **isa);
 int riscv_of_processor_hartid(struct device_node *node);
 
 extern void riscv_fill_hwcap(void);
diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index 40a3c442ac5f..95ef5c91823d 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -8,13 +8,42 @@
 #include 
 #include 
 
+int riscv_read_check_isa(struct device_node *node, const char **isa)
+{
+   u32 hart;
+
+   if (of_property_read_u32(node, "reg", &hart)) {
+   pr_warn("Found CPU without hart ID\n");
+   return -ENODEV;
+   }
+
+   if (of_property_read_string(node, "riscv,isa", isa)) {
+   pr_warn("CPU with hartid=%d has no \"riscv,isa\" property\n",
+   hart);
+   return -ENODEV;
+   }
+
+   /*
+* Linux doesn't support rv32e or rv128i, and we only support booting
+* kernels on harts with the same ISA that the kernel is compiled for.
+*/
+#if defined(CONFIG_32BIT)
+   if (strncmp(*isa, "rv32i", 5) != 0)
+   return -ENODEV;
+#elif defined(CONFIG_64BIT)
+   if (strncmp(*isa, "rv64i", 5) != 0)
+   return -ENODEV;
+#endif
+
+   return 0;
+}
+
 /*
  * Returns the hart ID of the given device tree node, or -ENODEV if the node
  * isn't an enabled and valid RISC-V hart node.
  */
 int riscv_of_processor_hartid(struct device_node *node)
 {
-   const char *isa;
u32 hart;
 
if (!of_device_is_compatible(node, "riscv")) {
@@ -32,15 +61,6 @@ int riscv_of_processor_hartid(struct device_node *node)
return -ENODEV;
}
 
-   if (of_property_read_string(node, "riscv,isa", &isa)) {
-   pr_warn("CPU with hartid=%d has no \"riscv,isa\" property\n", 
hart);
-   return -ENODEV;
-   }
-   if (isa[0] != 'r' || isa[1] != 'v') {
-   pr_warn("CPU with hartid=%d has an invalid ISA of \"%s\"\n", 
hart, isa);
-   return -ENODEV;
-   }
-
return hart;
 }
 
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index b1ade9a49347..eaad5aa07403 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -38,10 +38,8 @@ void riscv_fill_hwcap(void)
if (riscv_of_processor_hartid(node) < 0)
continue;
 
-   if (of_property_read_string(node, "riscv,isa", &isa)) {
-   pr_warn("Unable to find \"riscv,isa\" devicetree 
entry\n");
+   if (riscv_read_check_isa(node, &isa) < 0)
continue;
-   }
 
for (i = 0; i < strlen(isa); ++i)
this_hwcap |= isa2hwcap[(unsigned char)(isa[i])];
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index 18ae6da5115e..15ee71297abf 100644
--- a/arch/riscv/kernel/smpboot.c
+++ b/arch/riscv/kernel/smpboot.c
@@ -60,12 +60,16 @@ void __init setup_smp(void)
int hart;
bool found_boot_cpu = false;
int cpuid = 1;
+   const char *isa;
 
for_each_of_cpu_node(dn) {
hart = riscv_of_processor_hartid(dn);
if (hart < 0)
continue;
 
+   if (riscv_read_check_isa(dn, &isa) < 0)
+   continue;
+
if (hart == cpuid_to_hartid_map(0)) {
BUG_ON(found_boot_cpu);
found_boot_cpu = 1;
-- 
2.21.0

[v1 PATCH 1/2] RISC-V: Remove unsupported isa string info print

[Atish Patra]

/proc/cpuinfo should just print all the isa string as an information
instead of determining what is supported or not. ELF hwcap can be
used by the userspace to figure out that.

Simplify the isa string printing by removing the unsupported isa string
print and all related code.

The relevant discussion can be found at
http://lists.infradead.org/pipermail/linux-riscv/2019-September/006702.html

Signed-off-by: Atish Patra 
---
 arch/riscv/kernel/cpu.c | 45 +++--
 1 file changed, 3 insertions(+), 42 deletions(-)

diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index 7da3c6a93abd..40a3c442ac5f 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -46,51 +46,12 @@ int riscv_of_processor_hartid(struct device_node *node)
 
 #ifdef CONFIG_PROC_FS
 
-static void print_isa(struct seq_file *f, const char *orig_isa)
+static void print_isa(struct seq_file *f, const char *isa)
 {
-   static const char *ext = "mafdcsu";
-   const char *isa = orig_isa;
-   const char *e;
-
-   /*
-* Linux doesn't support rv32e or rv128i, and we only support booting
-* kernels on harts with the same ISA that the kernel is compiled for.
-*/
-#if defined(CONFIG_32BIT)
-   if (strncmp(isa, "rv32i", 5) != 0)
-   return;
-#elif defined(CONFIG_64BIT)
-   if (strncmp(isa, "rv64i", 5) != 0)
-   return;
-#endif
-
-   /* Print the base ISA, as we already know it's legal. */
+   /* Print the entire ISA as it is */
seq_puts(f, "isa\t\t: ");
-   seq_write(f, isa, 5);
-   isa += 5;
-
-   /*
-* Check the rest of the ISA string for valid extensions, printing those
-* we find.  RISC-V ISA strings define an order, so we only print the
-* extension bits when they're in order. Hide the supervisor (S)
-* extension from userspace as it's not accessible from there.
-*/
-   for (e = ext; *e != '\0'; ++e) {
-   if (isa[0] == e[0]) {
-   if (isa[0] != 's')
-   seq_write(f, isa, 1);
-
-   isa++;
-   }
-   }
+   seq_write(f, isa, strlen(isa));
seq_puts(f, "\n");
-
-   /*
-* If we were given an unsupported ISA in the device tree then print
-* a bit of info describing what went wrong.
-*/
-   if (isa[0] != '\0')
-   pr_info("unsupported ISA \"%s\" in device tree\n", orig_isa);
 }
 
 static void print_mmu(struct seq_file *f, const char *mmu_type)
-- 
2.21.0

ulfh/next boot bisection: v5.4-rc1-17-g25812fcf7403 on bcm2837-rpi-3-b-32

[kernelci.org bot]

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis  *
* that you may be involved with the breaking commit it has  *
* found.  No manual investigation has been done to verify it,   *
* and the root cause of the problem may be somewhere else.  *
*   *
* If you do send a fix, please include this trailer:*
*   Reported-by: "kernelci.org bot"   *
*   *
* Hope this helps!  *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

ulfh/next boot bisection: v5.4-rc1-17-g25812fcf7403 on bcm2837-rpi-3-b-32

Summary:
  Start:  25812fcf7403 mmc: mmci: make unexported functions static
  Details:https://kernelci.org/boot/id/5d96538e59b514aa6fd85813
  Plain log:  
https://storage.kernelci.org//ulfh/next/v5.4-rc1-17-g25812fcf7403/arm/bcm2835_defconfig/gcc-8/lab-baylibre/boot-bcm2837-rpi-3-b.txt
  HTML log:   
https://storage.kernelci.org//ulfh/next/v5.4-rc1-17-g25812fcf7403/arm/bcm2835_defconfig/gcc-8/lab-baylibre/boot-bcm2837-rpi-3-b.html
  Result: ac7c3e4ff401 compiler: enable CONFIG_OPTIMIZE_INLINING forcibly

Checks:
  revert: PASS
  verify: PASS

Parameters:
  Tree:   ulfh
  URL:https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
  Branch: next
  Target: bcm2837-rpi-3-b-32
  CPU arch:   arm
  Lab:lab-baylibre
  Compiler:   gcc-8
  Config: bcm2835_defconfig
  Test suite: boot

Breaking commit found:

---
commit ac7c3e4ff401b304489a031938dbeaab585bfe0a
Author: Masahiro Yamada 
Date:   Wed Sep 25 16:47:42 2019 -0700

compiler: enable CONFIG_OPTIMIZE_INLINING forcibly

Commit 9012d011660e ("compiler: allow all arches to enable
CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable this
option.  A couple of build errors were reported by randconfig, but all of
them have been ironed out.

Towards the goal of removing CONFIG_OPTIMIZE_INLINING entirely (and it
will simplify the 'inline' macro in compiler_types.h), this commit changes
it to always-on option.  Going forward, the compiler will always be
allowed to not inline functions marked 'inline'.

This is not a problem for x86 since it has been long used by
arch/x86/configs/{x86_64,i386}_defconfig.

I am keeping the config option just in case any problem crops up for other
architectures.

The code clean-up will be done after confirming this is solid.

Link: 
http://lkml.kernel.org/r/20190830034304.24259-1-yamada.masah...@socionext.com
Signed-off-by: Masahiro Yamada 
Acked-by: Nick Desaulniers 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Miguel Ojeda 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 6b1b1703a646..93d97f9b0157 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -311,7 +311,7 @@ config HEADERS_CHECK
  relevant for userspace, say 'Y'.
 
 config OPTIMIZE_INLINING
-   bool "Allow compiler to uninline functions marked 'inline'"
+   def_bool y
help
  This option determines if the kernel forces gcc to inline the 
functions
  developers have marked 'inline'. Doing so takes away freedom from gcc 
to
@@ -322,8 +322,6 @@ config OPTIMIZE_INLINING
  decision will become the default in the future. Until then this option
  is there to test gcc for this.
 
- If unsure, say N.
-
 config DEBUG_SECTION_MISMATCH
bool "Enable full Section mismatch analysis"
help
---


Git bisection log:

---
git bisect start
# good: [e51df6ce668a8f75ce27f83ce0f60103c568c375] mmc: host: sdhci-pci: Add 
Genesys Logic GL975x support
git bisect good e51df6ce668a8f75ce27f83ce0f60103c568c375
# bad: [25812fcf74030d9c1be8b898573eaf28de21efee] mmc: mmci: make unexported 
functions static
git bisect bad 25812fcf74030d9c1be8b898573eaf28de21efee
# bad: [972a2bf7dfe39ebf49dd47f68d27c416392e53b1] Merge tag 'nfs-for-5.4-1' of 
git://git.linux-nfs.org/projects/anna/linux-nfs
git bisect bad 972a2bf7dfe39ebf49dd47f68d27c416392e53b1
# good: [9c9fa97a8edbc3668dfc7a25de516e80c146e86f] Merge branch 'akpm' (patches 
from Andrew)
git bisect good 9c9fa97a8edbc3668dfc7a25de516e80c146e86f
# bad: [a22fea94992a2bc5328005e62f368413ede49c14] 
arch/sparc/include/asm/pgtable_64.h: fix build
git bisect bad a22fea94992a2bc5328005e62f368413ede49c14
# good: [351c8a09b00b5c51c8f58b016fffe51f87e2d820] Merge branch 'i2c/for-5.4' 
of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
git bisect good 351c

Re: [PATCH] sched/fair: scale quota and period without losing quota/period ratio precision

[Phil Auld]

Hi,

On Thu, Oct 03, 2019 at 05:12:43PM -0700 Xuewei Zhang wrote:
> quota/period ratio is used to ensure a child task group won't get more
> bandwidth than the parent task group, and is calculated as:
> normalized_cfs_quota() = [(quota_us << 20) / period_us]
> 
> If the quota/period ratio was changed during this scaling due to
> precision loss, it will cause inconsistency between parent and child
> task groups. See below example:
> A userspace container manager (kubelet) does three operations:
> 1) Create a parent cgroup, set quota to 1,000us and period to 10,000us.
> 2) Create a few children cgroups.
> 3) Set quota to 1,000us and period to 10,000us on a child cgroup.
> 
> These operations are expected to succeed. However, if the scaling of
> 147/128 happens before step 3), quota and period of the parent cgroup
> will be changed:
> new_quota: 1148437ns, 1148us
> new_period: 11484375ns, 11484us
> 
> And when step 3) comes in, the ratio of the child cgroup will be 104857,
> which will be larger than the parent cgroup ratio (104821), and will
> fail.
> 
> Scaling them by a factor of 2 will fix the problem.

I have no issues with the concept. We went around a bit about the actual
numbers and made it an approximation. 

> 
> Fixes: 2e8e19226398 ("sched/fair: Limit sched_cfs_period_timer() loop to 
> avoid hard lockup")
> Signed-off-by: Xuewei Zhang 
> ---
>  kernel/sched/fair.c | 36 ++--
>  1 file changed, 22 insertions(+), 14 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 83ab35e2374f..b3d3d0a231cd 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4926,20 +4926,28 @@ static enum hrtimer_restart 
> sched_cfs_period_timer(struct hrtimer *timer)
>   if (++count > 3) {
>   u64 new, old = ktime_to_ns(cfs_b->period);
>  
> - new = (old * 147) / 128; /* ~115% */
> - new = min(new, max_cfs_quota_period);
> -
> - cfs_b->period = ns_to_ktime(new);
> -
> - /* since max is 1s, this is limited to 1e9^2, which 
> fits in u64 */
> - cfs_b->quota *= new;
> - cfs_b->quota = div64_u64(cfs_b->quota, old);
> -
> - pr_warn_ratelimited(
> - "cfs_period_timer[cpu%d]: period too short, scaling up (new 
> cfs_period_us %lld, cfs_quota_us = %lld)\n",
> - smp_processor_id(),
> - div_u64(new, NSEC_PER_USEC),
> - div_u64(cfs_b->quota, NSEC_PER_USEC));
> + /*
> +  * Grow period by a factor of 2 to avoid lossing 
> precision.
> +  * Precision loss in the quota/period ratio can cause 
> __cfs_schedulable
> +  * to fail.
> +  */
> + new = old * 2;
> + if (new < max_cfs_quota_period) {

I don't like this part as much. There may be a value between
max_cfs_quota_period/2 and max_cfs_quota_period that would get us out of
the loop. Possibly in practice it won't matter but here you trigger the
warning and take no action to keep it from continuing.

Also, if you are actually hitting this then you might want to just start at
a higher but proportional quota and period.


Cheers,
Phil

> + cfs_b->period = ns_to_ktime(new);
> + cfs_b->quota *= 2;
> +
> + pr_warn_ratelimited(
> + "cfs_period_timer[cpu%d]: period too short, scaling up (new 
> cfs_period_us = %lld, cfs_quota_us = %lld)\n",
> + smp_processor_id(),
> + div_u64(new, NSEC_PER_USEC),
> + div_u64(cfs_b->quota, NSEC_PER_USEC));
> + } else {
> + pr_warn_ratelimited(
> + "cfs_period_timer[cpu%d]: period too short, but cannot scale up without 
> losing precision (cfs_period_us = %lld, cfs_quota_us = %lld)\n",
> + smp_processor_id(),
> + div_u64(old, NSEC_PER_USEC),
> + div_u64(cfs_b->quota, NSEC_PER_USEC));
> + }
>  
>   /* reset count so we don't come right back in here */
>   count = 0;
> -- 
> 2.23.0.581.g78d2f28ef7-goog
> 

-- 

Re: [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings

[Soeren Moch]

On 04.10.19 02:01, Robin Murphy wrote:
> On 2019-10-03 10:50 pm, Soeren Moch wrote:
>> According to the RockPro64 schematic [1] the rk3399 sdmmc controller is
>> connected to a microSD (TF card) slot, which cannot be switched to 1.8V.
>
> Really? AFAICS the SDMMC0 wiring looks pretty much identical to the
> NanoPC-T4 schematic (it's the same reference design, after all), and I
> know that board can happily drive a UHS-I microSD card with 1.8v I/Os,
> because mine's doing so right now.
>
> Robin.
OK, the RockPro64 does not allow a card reset (power cycle) since
VCC3V0_SD is directly connected to VCC3V3_SYS (via R89555), the
SDMMC0_PWH_H signal is not connected. So the card fails to identify
itself after suspend or reboot when switched to 1.8V operation.

Regards,
Soeren
>
>> So also configure the vcc_sdio regulator, which drives the i/o voltage
>> of the sdmmc controller, accordingly.
>>
>> While at it, also remove the cap-mmc-highspeed property of the sdmmc
>> controller, since no mmc card can be connected here.
>>
>> [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
>>
>> Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support
>> for Rockpro64")
>> Signed-off-by: Soeren Moch 
>> ---
>> Cc: Heiko Stuebner 
>> Cc: linux-rockc...@lists.infradead.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>>   arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
>> b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
>> index 2e44dae4865a..084f1d994a50 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
>> @@ -353,7 +353,7 @@
>>   regulator-name = "vcc_sdio";
>>   regulator-always-on;
>>   regulator-boot-on;
>> -    regulator-min-microvolt = <180>;
>> +    regulator-min-microvolt = <300>;
>>   regulator-max-microvolt = <300>;
>>   regulator-state-mem {
>>   regulator-on-in-suspend;
>> @@ -624,7 +624,6 @@
>>
>>   &sdmmc {
>>   bus-width = <4>;
>> -    cap-mmc-highspeed;
>>   cap-sd-highspeed;
>>   cd-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
>>   disable-wp;
>> -- 
>> 2.17.1
>>
>>
>> ___
>> Linux-rockchip mailing list
>> linux-rockc...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>

linux-next: build failure after merge of the hid tree

[Stephen Rothwell]

Hi all,

After merging the hid tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ld: drivers/hid/hid-lg-g15.o: in function `.lg_g15_probe':
hid-lg-g15.c:(.text+0x1a1c): undefined reference to 
`.devm_led_classdev_register_ext'
ld: hid-lg-g15.c:(.text+0x1c68): undefined reference to 
`.devm_led_classdev_register_ext'

Caused by commit

  3a0275384c27 ("HID: Add driver for Logitech gaming keyboards (G15, G15 v2)")

For this build, CONFIG_HID_LOGITECH=y and CONFIG_LEDS_CLASS=m.

I have used the hid tree from next-20191003 for today.

-- 
Cheers,
Stephen Rothwell


pgpPq7rUQtgJb.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 1/2] tpm: Use GFP_KERNEL for allocating struct tpm_buf

[James Bottomley]

On Thu, 2019-10-03 at 21:51 +0300, Jarkko Sakkinen wrote:
> Switch from GFP_HIGHUSER to GFP_KERNEL. On 32-bit platforms kmap()
> space
> could be unnecessarily wasted because of using GFP_HIGHUSER by taking
> a
> page of from the highmem.
> 
> Suggested-by: James Bottomley 
> Signed-off-by: Jarkko Sakkinen 
> ---
>  drivers/char/tpm/tpm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index a4f74dd02a35..d20745965350 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -297,7 +297,7 @@ static inline void tpm_buf_reset(struct tpm_buf
> *buf, u16 tag, u32 ordinal)
>  
>  static inline int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32
> ordinal)
>  {
> - buf->data_page = alloc_page(GFP_HIGHUSER);
> + buf->data_page = alloc_page(GFP_KERNEL);
>   if (!buf->data_page)
>   return -ENOMEM;

The kmap/kunmap needs removing as well, and now the data_page field
isn't necessary, so it can go.  I think the result should be something
like the below (uncompiled and untested).

James

---

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index a7fea3e0ca86..b4f1cbf344b6 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -284,7 +284,6 @@ enum tpm_buf_flags {
 };
 
 struct tpm_buf {
-   struct page *data_page;
unsigned int flags;
u8 *data;
 };
@@ -300,20 +299,18 @@ static inline void tpm_buf_reset(struct tpm_buf *buf, u16 
tag, u32 ordinal)
 
 static inline int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
 {
-   buf->data_page = alloc_page(GFP_HIGHUSER);
-   if (!buf->data_page)
+   buf->data = (u8 *)__get_free_page(GFP_KERNEL);
+   if (!buf->data)
return -ENOMEM;
 
buf->flags = 0;
-   buf->data = kmap(buf->data_page);
tpm_buf_reset(buf, tag, ordinal);
return 0;
 }
 
 static inline void tpm_buf_destroy(struct tpm_buf *buf)
 {
-   kunmap(buf->data_page);
-   __free_page(buf->data_page);
+   free_page(buf->data);
 }
 
 static inline u32 tpm_buf_length(struct tpm_buf *buf)

Re: [PATCH v22 16/24] x86/vdso: Add support for exception fixup in vDSO functions

[Sean Christopherson]

I'll tackle this tomorrow.  I've been working on the feature control MSR
series and will get that sent out tomorrow as well.  I should also be able
to get you the multi-page EADD patch.

[PATCH] sched/fair: scale quota and period without losing quota/period ratio precision

[Xuewei Zhang]

quota/period ratio is used to ensure a child task group won't get more
bandwidth than the parent task group, and is calculated as:
normalized_cfs_quota() = [(quota_us << 20) / period_us]

If the quota/period ratio was changed during this scaling due to
precision loss, it will cause inconsistency between parent and child
task groups. See below example:
A userspace container manager (kubelet) does three operations:
1) Create a parent cgroup, set quota to 1,000us and period to 10,000us.
2) Create a few children cgroups.
3) Set quota to 1,000us and period to 10,000us on a child cgroup.

These operations are expected to succeed. However, if the scaling of
147/128 happens before step 3), quota and period of the parent cgroup
will be changed:
new_quota: 1148437ns, 1148us
new_period: 11484375ns, 11484us

And when step 3) comes in, the ratio of the child cgroup will be 104857,
which will be larger than the parent cgroup ratio (104821), and will
fail.

Scaling them by a factor of 2 will fix the problem.

Fixes: 2e8e19226398 ("sched/fair: Limit sched_cfs_period_timer() loop to avoid 
hard lockup")
Signed-off-by: Xuewei Zhang 
---
 kernel/sched/fair.c | 36 ++--
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 83ab35e2374f..b3d3d0a231cd 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4926,20 +4926,28 @@ static enum hrtimer_restart 
sched_cfs_period_timer(struct hrtimer *timer)
if (++count > 3) {
u64 new, old = ktime_to_ns(cfs_b->period);
 
-   new = (old * 147) / 128; /* ~115% */
-   new = min(new, max_cfs_quota_period);
-
-   cfs_b->period = ns_to_ktime(new);
-
-   /* since max is 1s, this is limited to 1e9^2, which 
fits in u64 */
-   cfs_b->quota *= new;
-   cfs_b->quota = div64_u64(cfs_b->quota, old);
-
-   pr_warn_ratelimited(
-   "cfs_period_timer[cpu%d]: period too short, scaling up (new 
cfs_period_us %lld, cfs_quota_us = %lld)\n",
-   smp_processor_id(),
-   div_u64(new, NSEC_PER_USEC),
-   div_u64(cfs_b->quota, NSEC_PER_USEC));
+   /*
+* Grow period by a factor of 2 to avoid lossing 
precision.
+* Precision loss in the quota/period ratio can cause 
__cfs_schedulable
+* to fail.
+*/
+   new = old * 2;
+   if (new < max_cfs_quota_period) {
+   cfs_b->period = ns_to_ktime(new);
+   cfs_b->quota *= 2;
+
+   pr_warn_ratelimited(
+   "cfs_period_timer[cpu%d]: period too short, scaling up (new 
cfs_period_us = %lld, cfs_quota_us = %lld)\n",
+   smp_processor_id(),
+   div_u64(new, NSEC_PER_USEC),
+   div_u64(cfs_b->quota, NSEC_PER_USEC));
+   } else {
+   pr_warn_ratelimited(
+   "cfs_period_timer[cpu%d]: period too short, but cannot scale up without 
losing precision (cfs_period_us = %lld, cfs_quota_us = %lld)\n",
+   smp_processor_id(),
+   div_u64(old, NSEC_PER_USEC),
+   div_u64(cfs_b->quota, NSEC_PER_USEC));
+   }
 
/* reset count so we don't come right back in here */
count = 0;
-- 
2.23.0.581.g78d2f28ef7-goog

[PATCH] Bluetooth: hci_core: fix init with HCI_QUIRK_NON_PERSISTENT_SETUP

[Mattijs Korpershoek]

Some HCI devices which have the HCI_QUIRK_NON_PERSISTENT_SETUP [1]
require a call to setup() to be ran after every open().

During the setup() stage, these devices expect the chip to acknowledge
its setup() completion via vendor specific frames.

If userspace opens() such HCI device in HCI_USER_CHANNEL [2] mode,
the vendor specific frames are never tranmitted to the driver, as
they are filtered in hci_rx_work().

Allow HCI devices which have HCI_QUIRK_NON_PERSISTENT_SETUP to process
frames if the HCI device is is HCI_INIT state.

[1] https://lore.kernel.org/patchwork/patch/965071/
[2] https://www.spinics.net/lists/linux-bluetooth/msg37345.html

Fixes: 740011cfe948 ("Bluetooth: Add new quirk for non-persistent setup 
settings")
Signed-off-by: Mattijs Korpershoek 
---
Some more background on the change follows:

The Android bluetooth stack (Bluedroid) also has a HAL implementation
which follows Linux's standard rfkill interface [1].

This implementation relies on the HCI_CHANNEL_USER feature to get
exclusive access to the underlying bluetooth device.

When testing this along with the btkmtksdio driver, the
chip appeared unresponsive when calling the following from userspace:

struct sockaddr_hci addr;
int fd;

fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);

memset(&addr, 0, sizeof(addr));
addr.hci_family = AF_BLUETOOTH;
addr.hci_dev = 0;
addr.hci_channel = HCI_CHANNEL_USER;

bind(fd, (struct sockaddr *) &addr, sizeof(addr)); # device hangs

In the case of bluetooth drivers exposing QUIRK_NON_PERSISTENT_SETUP
such as btmtksdio, setup() is called each multiple times.
In particular, when userspace calls bind(), the setup() is called again
and vendor specific commands might be send to re-initialize the chip.

Those commands are filtered out by hci_core in HCI_CHANNEL_USER mode,
preventing setup() from completing successfully.

This has been tested on a 4.19 kernel based on Android Common Kernel.
It has also been compile tested on bluetooth-next.

[1] 
https://android.googlesource.com/platform/system/bt/+/refs/heads/master/vendor_libs/linux/interface/

 net/bluetooth/hci_core.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 04bc79359a17..5f12e8574d54 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -4440,9 +4440,20 @@ static void hci_rx_work(struct work_struct *work)
hci_send_to_sock(hdev, skb);
}
 
+   /* If the device has been opened in HCI_USER_CHANNEL,
+* the userspace has exclusive access to device.
+* When HCI_QUIRK_NON_PERSISTENT_SETUP is set and
+* device is HCI_INIT,  we still need to process
+* the data packets to the driver in order
+* to complete its setup().
+*/
if (hci_dev_test_flag(hdev, HCI_USER_CHANNEL)) {
-   kfree_skb(skb);
-   continue;
+   if (!test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP,
+ &hdev->quirks) ||
+   !test_bit(HCI_INIT, &hdev->flags)) {
+   kfree_skb(skb);
+   continue;
+   }
}
 
if (test_bit(HCI_INIT, &hdev->flags)) {
-- 
2.20.1

Re: ptrace/strace and freezer oddities and v5.2+ kernels

[Roman Gushchin]

On Wed, Oct 02, 2019 at 05:59:36PM -0400, Bruce Ashfield wrote:
> On Wed, Oct 2, 2019 at 2:19 PM Roman Gushchin  wrote:
> >
> > On Wed, Oct 02, 2019 at 12:18:54AM -0400, Bruce Ashfield wrote:
> > > On Tue, Oct 1, 2019 at 10:01 PM Roman Gushchin  wrote:
> > > >
> > > > On Tue, Oct 01, 2019 at 12:14:18PM -0400, Bruce Ashfield wrote:
> > > > > Hi all,
> > > > >
> > > >
> > > > Hi Bruce!
> > > >
> > > > > The Yocto project has an upcoming release this fall, and I've been 
> > > > > trying to
> > > > > sort through some issues that are happening with kernel 5.2+ .. 
> > > > > although
> > > > > there is a specific yocto kernel, I'm testing and seeing this with
> > > > > normal / vanilla
> > > > > mainline kernels as well.
> > > > >
> > > > > I'm running into an issue that is *very* similar to the one discussed 
> > > > > in the
> > > > > [REGRESSION] ptrace broken from "cgroup: cgroup v2 freezer" (76f969e)
> > > > > thread from this past may: https://lkml.org/lkml/2019/5/12/272
> > > > >
> > > > > I can confirm that I have the proposed fix for the initial regression 
> > > > > report in
> > > > > my build (05b2892637 [signal: unconditionally leave the frozen state
> > > > > in ptrace_stop()]),
> > > > > but yet I'm still seeing 3 or 4 minute runtimes on a test that used 
> > > > > to take 3 or
> > > > > 4 seconds.
> > > >
> > > > So, the problem is that you're experiencing a severe performance 
> > > > regression
> > > > in some test, right?
> > >
> > > Hi Roman,
> > >
> > > Correct. In particular, running some of the tests that ship with strace 
> > > itself.
> > > The performance change is so drastic, that it definitely makes you wonder
> > > "What have I done wrong? Since everyone must be seeing this" .. and I
> > > always blame myself first.
> > >
> > > >
> > > > >
> > > > > This isn't my normal area of kernel hacking, so I've so far come up 
> > > > > empty
> > > > > at either fixing it myself, or figuring out a viable workaround. 
> > > > > (well, I can
> > > > > "fix" it by remove the cgroup_enter_frozen() call in ptrace_stop ...
> > > > > but obviously,
> > > > > that is just me trying to figure out what could be causing the issue).
> > > > >
> > > > > As part of the release, we run tests that come with various 
> > > > > applications. The
> > > > > ptrace test that is causing us issues can be boiled down to this:
> > > > >
> > > > > $ cd /usr/lib/strace/ptest/tests
> > > > > $ time ../strace -o log -qq -esignal=none -e/clock 
> > > > > ./printpath-umovestr>ttt
> > > > >
> > > > > (I can provide as many details as needed, but I wanted to keep this 
> > > > > initial
> > > > > email relatively short).
> > > > >
> > > > > I'll continue to debug and attempt to fix this myself, but I grabbed 
> > > > > the
> > > > > email list from the regression report in May to see if anyone has any 
> > > > > ideas
> > > > > or angles that I haven't covered in my search for a fix.
> > > >
> > > > I'm definitely happy to help, but it's a bit hard to say anything from 
> > > > what
> > > > you've provided. I'm not aware of any open issues with the freezer 
> > > > except
> > > > some spurious cgroup frozen<->not frozen transitions which can happen 
> > > > in some
> > > > cases. If you'll describe how can I reproduce the issue, and I'll try 
> > > > to take
> > > > a look asap.
> > >
> > > That would be great.
> > >
> > > I'll attempt to remove all of the build system specifics out of this
> > > (and Richard Purdie
> > > on the cc' of this can probably help provide more details / setup info as 
> > > well).
> > >
> > > We are running the built-in tests of strace. So here's a cut and paste of 
> > > what I
> > > did to get the tests available (ignore/skip what is common sense or isn't 
> > > needed
> > > in your test rig).
> > >
> > > % git clone https://github.com/strace/strace.git
> > > % cd strace
> > > % ./bootstrap
> > > # the --enable flag isn't strictly required, but may break on some
> > > build machines
> > > % ./configure --enable-mpers=no
> > > % make
> > > % make check-TESTS
> > >
> > > That last step will not only build the tests, but run them all .. so
> > > ^c the run once
> > > it starts, since it is a lot of noise (we carry a patch to strace that
> > > allows us to build
> > > the tests without running them).
> > >
> > > % cd tests
> > > % time strace -o log -qq -esignal=none -e/clock ./printpath-umovestr > fff
> > > real0m2.566s
> > > user0m0.284s
> > > sys 0m2.519
> > >
> > > On pre-cgroup2 freezer kernels, you see a run time similar to what I have 
> > > above.
> > > On the newer kernels we are testing, it is taking 3 or 4 minutes to
> > > run the test.
> > >
> > > I hope that is simple enough to setup and try. Since I've been seeing
> > > this on both
> > > mainline kernels and the yocto reference kernels, I don't think it is
> > > something that
> > > I'm carrying in the distro/reference kernel that is causing this (but
> > > again, I always
> > > blame myself first). If you don't see that 

RE: [RFC PATCH 00/13] vsock: add multi-transports support

[Dexuan Cui]

> From: Stefano Garzarella 
> Sent: Friday, September 27, 2019 4:27 AM
>  ...
> Patch 9 changes the hvs_remote_addr_init(). setting the
> VMADDR_CID_HOST as remote CID instead of VMADDR_CID_ANY to make
> the choice of transport to be used work properly.
> @Dexuan Could this change break anything?

This patch looks good to me.

> @Dexuan please can you test on HyperV that I didn't break anything
> even without nested VMs?

I did some quick tests with the 13 patches in a Linux VM (this is not
a nested VM) on Hyper-V and it looks nothing is broken. :-)

> I'll try to setup a Windows host where to test the nested VMs

I suppose you're going to run a Linux VM on a Hyper-V host,
and the Linux VM itself runs KVM/VmWare so it can create its own child 
VMs. IMO this is similar to the test "nested KVM ( ..., virtio-transport[L1,L2]"
you have done.
.
Thanks!
Dexuan

Re: [PATCH v22 16/24] x86/vdso: Add support for exception fixup in vDSO functions

[Sean Christopherson]

On Thu, Oct 03, 2019 at 02:18:04AM +0300, Jarkko Sakkinen wrote:
> Also there is two space bars after *every* sentence. Your text editor is
> totally broken somehow.

I completely misunderstood your earlier comment, I thought you were saying
there were random spaces at the end of lines.

It's not my editor, it's me.  I insert two spaces after full stops.  IMO,
people that use a single space are heathens. :-)

If it's a sticking point I'll make an effort to use a single space for SGX
comments and changelogs.

Re: [v1] e1000e: EEH on e1000e adapter detects io perm failure can trigger crash

[David Z. Dai]

On Thu, 2019-10-03 at 13:39 -0700, Alexander Duyck wrote:
> On Thu, Oct 3, 2019 at 11:51 AM David Z. Dai  wrote:
> >
> > On Thu, 2019-10-03 at 10:39 -0700, Alexander Duyck wrote:
> > > On Thu, Oct 3, 2019 at 9:59 AM David Dai  wrote:
> > > >
> > > > We see the behavior when EEH e1000e adapter detects io permanent 
> > > > failure,
> > > > it will crash kernel with this stack:
> > > > EEH: Beginning: 'error_detected(permanent failure)'
> > > > EEH: PE#90 (PCI 0115:90:00.1): Invoking 
> > > > e1000e->error_detected(permanent failure)
> > > > EEH: PE#90 (PCI 0115:90:00.1): e1000e driver reports: 'disconnect'
> > > > EEH: PE#90 (PCI 0115:90:00.0): Invoking 
> > > > e1000e->error_detected(permanent failure)
> > > > EEH: PE#90 (PCI 0115:90:00.0): e1000e driver reports: 'disconnect'
> > > > EEH: Finished:'error_detected(permanent failure)'
> > > > Oops: Exception in kernel mode, sig: 5 [#1]
> > > > NIP [c07b1be0] free_msi_irqs+0xa0/0x280
> > > >  LR [c07b1bd0] free_msi_irqs+0x90/0x280
> > > > Call Trace:
> > > > [c004f491ba10] [c07b1bd0] free_msi_irqs+0x90/0x280 
> > > > (unreliable)
> > > > [c004f491ba70] [c07b260c] pci_disable_msi+0x13c/0x180
> > > > [c004f491bab0] [d46381ac] e1000_remove+0x234/0x2a0 [e1000e]
> > > > [c004f491baf0] [c0783cec] pci_device_remove+0x6c/0x120
> > > > [c004f491bb30] [c088da6c] 
> > > > device_release_driver_internal+0x2bc/0x3f0
> > > > [c004f491bb80] [c076f5a8] 
> > > > pci_stop_and_remove_bus_device+0xb8/0x110
> > > > [c004f491bbc0] [c006e890] pci_hp_remove_devices+0x90/0x130
> > > > [c004f491bc50] [c004ad34] 
> > > > eeh_handle_normal_event+0x1d4/0x660
> > > > [c004f491bd10] [c004bf10] eeh_event_handler+0x1c0/0x1e0
> > > > [c004f491bdc0] [c017c4ac] kthread+0x1ac/0x1c0
> > > > [c004f491be30] [c000b75c] ret_from_kernel_thread+0x5c/0x80
> > > >
> > > > Basically the e1000e irqs haven't been freed at the time eeh is trying 
> > > > to
> > > > remove the the e1000e device.
> > > > Need to make sure when e1000e_close is called to bring down the NIC,
> > > > if adapter error_state is pci_channel_io_perm_failure, it should also
> > > > bring down the link and free irqs.
> > > >
> > > > Reported-by: Morumuri Srivalli  
> > > > Signed-off-by: David Dai 
> > > > ---
> > > >  drivers/net/ethernet/intel/e1000e/netdev.c |3 ++-
> > > >  1 files changed, 2 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
> > > > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > index d7d56e4..cf618e1 100644
> > > > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > @@ -4715,7 +4715,8 @@ int e1000e_close(struct net_device *netdev)
> > > >
> > > > pm_runtime_get_sync(&pdev->dev);
> > > >
> > > > -   if (!test_bit(__E1000_DOWN, &adapter->state)) {
> > > > +   if (!test_bit(__E1000_DOWN, &adapter->state) ||
> > > > +   (adapter->pdev->error_state == 
> > > > pci_channel_io_perm_failure)) {
> > > > e1000e_down(adapter, true);
> > > > e1000_free_irq(adapter);
> > >
> > > It seems like the issue is the fact that e1000_io_error_detected is
> > > calling e1000e_down without the e1000_free_irq() bit. Instead of doing
> > > this couldn't you simply add the following to e1000_is_slot_reset in
> > > the "result = PCI_ERS_RESULT_DISCONNECT" case:
> > > if (netif_running(netdev)
> > > e1000_free_irq(adapter);
> > >
> > > Alternatively we could look at freeing and reallocating the IRQs in
> > > the event of an error like we do for the e1000e_pm_freeze and
> > > e1000e_pm_thaw cases. That might make more sense since we are dealing
> > > with an error we might want to free and reallocate the IRQ resources
> > > assigned to the device.
> > >
> > > Thanks.
> > >
> > > - Alex
> >
> > Thanks for the quick reply and comment!
> > Looked the e1000_io_slot_reset() routine:
> > err = pci_enable_device_mem(pdev);
> > if (err) {
> > dev_err(&pdev->dev,
> > "Cannot re-enable PCI device after reset.\n");
> > result = PCI_ERS_RESULT_DISCONNECT;
> > } else {
> > I didn't see log message "Cannot re-enable PCI device after reset" at
> > the time of crash.
> >
> > I can still apply the same logic in e1000_io_error_detected() routine:
> > if (state == pci_channel_io_perm_failure) {
> > +   if (netif_running(netdev))
> > +   e1000_free_irq(adapter);
> > return PCI_ERS_RESULT_DISCONNECT;
> > }
> > Will test this once the test hardware is available again.
> 
> Are you sure this is the path you are hitting? Things aren't adding up.
> 
> I thought the issue was that the interface for the error handling was
> calling e1000e_down() but not freeing the IRQs? In the path where you
> are adding your code 

Re: [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings

[Robin Murphy]

On 2019-10-03 10:50 pm, Soeren Moch wrote:

According to the RockPro64 schematic [1] the rk3399 sdmmc controller is
connected to a microSD (TF card) slot, which cannot be switched to 1.8V.


Really? AFAICS the SDMMC0 wiring looks pretty much identical to the 
NanoPC-T4 schematic (it's the same reference design, after all), and I 
know that board can happily drive a UHS-I microSD card with 1.8v I/Os, 
because mine's doing so right now.


Robin.


So also configure the vcc_sdio regulator, which drives the i/o voltage
of the sdmmc controller, accordingly.

While at it, also remove the cap-mmc-highspeed property of the sdmmc
controller, since no mmc card can be connected here.

[1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf

Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for 
Rockpro64")
Signed-off-by: Soeren Moch 
---
Cc: Heiko Stuebner 
Cc: linux-rockc...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
  arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
index 2e44dae4865a..084f1d994a50 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
@@ -353,7 +353,7 @@
regulator-name = "vcc_sdio";
regulator-always-on;
regulator-boot-on;
-   regulator-min-microvolt = <180>;
+   regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-state-mem {
regulator-on-in-suspend;
@@ -624,7 +624,6 @@

  &sdmmc {
bus-width = <4>;
-   cap-mmc-highspeed;
cap-sd-highspeed;
cd-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
disable-wp;
--
2.17.1


___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 4.4 00/99] 4.4.195-stable review

[shuah]

On 10/3/19 9:52 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.195 release.
There are 99 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 Sat 05 Oct 2019 03:37:47 PM UTC.
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/v4.x/stable-review/patch-4.4.195-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-4.4.y
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.19 000/211] 4.19.77-stable review

[shuah]

On 10/3/19 9:51 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.19.77 release.
There are 211 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 Sat 05 Oct 2019 03:37:47 PM UTC.
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/v4.x/stable-review/patch-4.19.77-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-4.19.y
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.14 000/185] 4.14.147-stable review

[shuah]

On 10/3/19 9:51 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.14.147 release.
There are 185 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 Sat 05 Oct 2019 03:37:47 PM UTC.
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/v4.x/stable-review/patch-4.14.147-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-4.14.y
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.9 000/129] 4.9.195-stable review

[shuah]

On 10/3/19 9:52 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.9.195 release.
There are 129 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 Sat 05 Oct 2019 03:37:47 PM UTC.
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/v4.x/stable-review/patch-4.9.195-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-4.9.y
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[PATCH v1] base: soc: Handle custom soc information sysfs entries

[Murali Nalajala]

Soc framework exposed sysfs entries are not sufficient for some
of the h/w platforms. Currently there is no interface where soc
drivers can expose further information about their SoCs via soc
framework. This change address this limitation where clients can
pass their custom entries as attribute group and soc framework
would expose them as sysfs properties.

Signed-off-by: Murali Nalajala 
---
Changes in v1:
- Remove NULL initialization of "soc_attr_groups"
- Taken care of freeing "soc_attr_groups" in soc_release()
- Addressed Stephen Boyd comments on usage of "kalloc"

 drivers/base/soc.c  | 23 +++
 include/linux/sys_soc.h |  1 +
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 7c0c5ca..ad30d58 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -104,15 +104,11 @@ static ssize_t soc_info_get(struct device *dev,
.is_visible = soc_attribute_mode,
 };
 
-static const struct attribute_group *soc_attr_groups[] = {
-   &soc_attr_group,
-   NULL,
-};
-
 static void soc_release(struct device *dev)
 {
struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
 
+   kfree(soc_dev->dev.groups);
kfree(soc_dev);
 }
 
@@ -121,6 +117,7 @@ static void soc_release(struct device *dev)
 struct soc_device *soc_device_register(struct soc_device_attribute 
*soc_dev_attr)
 {
struct soc_device *soc_dev;
+   const struct attribute_group **soc_attr_groups;
int ret;
 
if (!soc_bus_type.p) {
@@ -136,10 +133,18 @@ struct soc_device *soc_device_register(struct 
soc_device_attribute *soc_dev_attr
goto out1;
}
 
+   soc_attr_groups = kcalloc(3, sizeof(*soc_attr_groups), GFP_KERNEL);
+   if (!soc_attr_groups) {
+   ret = -ENOMEM;
+   goto out2;
+   }
+   soc_attr_groups[0] = &soc_attr_group;
+   soc_attr_groups[1] = soc_dev_attr->custom_attr_group;
+
/* Fetch a unique (reclaimable) SOC ID. */
ret = ida_simple_get(&soc_ida, 0, 0, GFP_KERNEL);
if (ret < 0)
-   goto out2;
+   goto out3;
soc_dev->soc_dev_num = ret;
 
soc_dev->attr = soc_dev_attr;
@@ -151,14 +156,16 @@ struct soc_device *soc_device_register(struct 
soc_device_attribute *soc_dev_attr
 
ret = device_register(&soc_dev->dev);
if (ret)
-   goto out3;
+   goto out4;
 
return soc_dev;
 
-out3:
+out4:
ida_simple_remove(&soc_ida, soc_dev->soc_dev_num);
put_device(&soc_dev->dev);
soc_dev = NULL;
+out3:
+   kfree(soc_attr_groups);
 out2:
kfree(soc_dev);
 out1:
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 48ceea8..d9b3cf0 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -15,6 +15,7 @@ struct soc_device_attribute {
const char *serial_number;
const char *soc_id;
const void *data;
+   const struct attribute_group *custom_attr_group;
 };
 
 /**
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 5.2 000/313] 5.2.19-stable review

[Kevin Hilman]

"kernelci.org bot"  writes:

> stable-rc/linux-5.2.y boot: 136 boots: 1 failed, 126 passed with 9 offline 
> (v5.2.18-314-g2c8369f13ff8)
>
> Full Boot Summary: 
> https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.2.y/kernel/v5.2.18-314-g2c8369f13ff8/
> Full Build Summary: 
> https://kernelci.org/build/stable-rc/branch/linux-5.2.y/kernel/v5.2.18-314-g2c8369f13ff8/
>
> Tree: stable-rc
> Branch: linux-5.2.y
> Git Describe: v5.2.18-314-g2c8369f13ff8
> Git Commit: 2c8369f13ff8c1375690964c79ffdc0e41ab4f97
> Git URL: 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Tested: 80 unique boards, 27 SoC families, 16 builds out of 209

TL;DR; all is well.

> Boot Failure Detected:
>
> arm64:
> defconfig:
> gcc-8:
> rk3399-firefly: 1 failed lab

There's a known issue on this board I've been trying to debug with the
mediatek maintainers, and we're not sure yet if it's a kernel issue or
a hardware issue on my board, but for now, nothing to worry about for
stable.

Kevin

Re: [PATCH 5.2 000/313] 5.2.19-stable review

[shuah]

On 10/3/19 9:49 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.2.19 release.
There are 313 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 Sat 05 Oct 2019 03:37:47 PM UTC.
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.2.19-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.2.y
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 5.3 000/344] 5.3.4-stable review

[shuah]

On 10/3/19 9:49 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.3.4 release.
There are 344 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 Sat 05 Oct 2019 03:37:47 PM UTC.
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.3.4-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.3.y
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah