Re: [PATCH] Add PCI device IDs for family 17h, model 70h

[Borislav Petkov]

On Fri, Sep 06, 2019 at 11:21:38PM +, Isaac Vaughn wrote:
> Add the new Family 17h Model 70h PCI IDs (device 18h functions 0 and 6)
> to the AMD64 EDAC module.
> 
> Cc: Borislav Petkov  (maintainer:EDAC-AMD64)
> Cc: Mauro Carvalho Chehab  (supporter:EDAC-CORE)
> Cc: James Morse  (reviewer:EDAC-CORE)
> Cc: linux-e...@vger.kernel.org (open list:EDAC-AMD64)
> Cc: linux-kernel@vger.kernel.org (open list)
> Signed-off-by: Isaac Vaughn 
> ---
>  drivers/edac/amd64_edac.c | 13 +
>  drivers/edac/amd64_edac.h |  3 +++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 873437be86d9..a35c97f9100a 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -2253,6 +2253,15 @@ static struct amd64_family_type family_types[] = {
>   .dbam_to_cs = f17_base_addr_to_cs_size,
>   }
>   },
> + [F17_M70H_CPUS] = {
> + .ctl_name = "F17h_M70h",
> + .f0_id = PCI_DEVICE_ID_AMD_17H_M70H_DF_F0,
> + .f6_id = PCI_DEVICE_ID_AMD_17H_M70H_DF_F6,
> + .ops = {
> + .early_channel_count= f17_early_channel_count,
> + .dbam_to_cs = f17_base_addr_to_cs_size,

You still have f17_base_addr_to_cs_size here. If you'd built it against
the branch I pointed you at:

https://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git/log/?h=edac-for-next

it would have failed.

Anyway, I fixed it up and applied it.

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [GIT PULL] compiler-attributes for v5.3-rc8

[Sedat Dilek]

On Sat, Sep 7, 2019 at 12:59 AM Linus Torvalds
 wrote:
>
> On Fri, Sep 6, 2019 at 5:45 PM Nick Desaulniers  
> wrote:
> >
> > > Yes. With the appropriate test cycle
> >
> > Sedat reported the issue and already tested/verified the fix.  How
> > long should it sit in -next before sending a PR for inclusion to 5.3
> > (as opposed to letting it ride out to 5.4)?
>
> If the original patch was already in -next, I wouldn't worry about it,
> as long as you do enough local testing that there's nothing stupid
> going on.
>

I am the original reporter and tester of the ClangBuiltLinux issue
#619 and highly appreciate to have the single fix in Linux v5.3 final.

The compiler-attribute patchset sit for some weeks in linux-next, so I
have not seen any complains.

What I still prefer is to re-integrate the arm64 and sh arch related
patches which went through maintainer's trees in linux-next.
AFAICS some massage of the commit messages were missing, too.

devil's OMG dileks used compiler and linker: LLVM/Clang and LLD v9.0.0-rc3

> The -next cycle is a few days, and even with an rc8 we're getting
> close enough to release that I'd rather get it earlier than later.  So
> I'd rather get a pull request this weekend than then have to deal with
> it when traveling next week.
>

+1 for ASAPISSIMO

Thanks for taking care.

- Sedat -

Re: [PATCH] mostpost: don't warn about symbols from another file

[Denis Efremov]

On 07.09.2019 01:39, Denis Efremov wrote:
> Hi,
> 
> On 06.09.2019 18:10, Arnd Bergmann wrote:
>> On architectures such as ARM that have a list of symbols exported from
>> assembler in a separate C file, we get a lot of new warnings:
>>
>> WARNING: "__ashrdi3" [vmlinux] is a static (unknown)
>> WARNING: "__lshrdi3" [vmlinux] is a static (unknown)
>> WARNING: "__aeabi_llsr" [vmlinux] is a static (unknown)
>> WARNING: "__aeabi_lasr" [vmlinux] is a static (unknown)
>> WARNING: "__aeabi_uidivmod" [vmlinux] is a static (unknown)
>> WARNING: "__udivsi3" [vmlinux] is a static (unknown)
>> WARNING: "_change_bit" [vmlinux] is a static (unknown)
>> WARNING: "__aeabi_idiv" [vmlinux] is a static (unknown)
>> WARNING: "__umodsi3" [vmlinux] is a static (unknown)
>> WARNING: "__aeabi_uidiv" [vmlinux] is a static (unknown)
>> WARNING: "__aeabi_idivmod" [vmlinux] is a static (unknown)
>> WARNING: "__muldi3" [vmlinux] is a static (unknown)
>> WARNING: "__aeabi_ulcmp" [vmlinux] is a static (unknown)
>> WARNING: "__raw_writesb" [vmlinux] is a static (unknown)
>> WARNING: "__raw_readsb" [vmlinux] is a static (unknown)
>> ...
>>
>> This is not helpful, as these are clearly not static symbols
>> at all. Suppress the warning in a case like this.
>>
> 
> It looks very similar to this discussion https://lkml.org/lkml/2019/7/30/112
> 
> Could you please write the steps to reproduce the warnings?
> Now, I'm trying to build linux-next (host Ubuntu 19.04 x86_64) with:
> $ make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-
> But I can't get these warnings.

Tried defconfig, allyesconfig.
 
> 
> I would like to check the type of this asm symbols. It seems like they
> are STT_NOTYPE. In this case the fix could also involve ELF_ST_TYPE check.
> 

Ah, I forgot that we don't check the type at all, so this is not the case.
But still, I would like to test what if the remove binding check at all?
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 76c221dd9b2b..97dbcebf2338 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1987,14 +1987,12 @@ static void read_symbols(const char *modname)
for (sym = info.symtab_start; sym < info.symtab_stop; sym++) {
unsigned char bind = ELF_ST_BIND(sym->st_info);
 
-   if (bind == STB_GLOBAL || bind == STB_WEAK) {
struct symbol *s =
find_symbol(remove_dot(info.strtab +
   sym->st_name));
 
if (s)
s->is_static = 0;
-   }
}
 
if (!is_vmlinux(modname) || vmlinux_section_warnings)


Thanks,
Denis

> 
>> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
>> Signed-off-by: Arnd Bergmann 
>> ---
>>  scripts/mod/modpost.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
>> index 76c221dd9b2b..4265dd924933 100644
>> --- a/scripts/mod/modpost.c
>> +++ b/scripts/mod/modpost.c
>> @@ -2543,7 +2543,7 @@ int main(int argc, char **argv)
>>  struct symbol *s = symbolhash[n];
>>  
>>  while (s) {
>> -if (s->is_static)
>> +if (s->is_static && s->export != export_unknown)
>>  warn("\"%s\" [%s] is a static %s\n",
>>   s->name, s->module->name,
>>   export_str(s->export));
>>

Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc

[Christoph Hellwig]

On Fri, Sep 06, 2019 at 03:33:02PM -0700, Paul Walmsley wrote:
> If that's your primary concern, then in the short term, how about just 
> sending a single-line patch to the arch/riscv/mm Makefile to skip building 
> it if !CONFIG_SOC_SIFIVE?  Assuming, that is, you won't be enabling EDAC 
> support for those low-end SoCs.  Then you won't need to get the ack 
> from the EDAC folks in the short term.  

Paul, stop it.  The patch that meged this was complete crap and fucked up.
And instead of just fixing up this mess ASAP you just keep arguing even
when I finally get hold of a RISC-V maintainer after weeks of waiting.

If this isn't going to get any better I'm just going to bypass you for
RISC-V patches and will send patches straight to Linus.

Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc

[Christoph Hellwig]

On Fri, Sep 06, 2019 at 03:36:09PM -0700, Paul Walmsley wrote:
> One other comment on this patch:
> 
> On Fri, 6 Sep 2019, Paul Walmsley wrote:
> 
> > On Sun, 18 Aug 2019, Christoph Hellwig wrote:
> >
> > > diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> > > index 200c04ce5b0e..9241b3e7a050 100644
> > > --- a/drivers/edac/Kconfig
> > > +++ b/drivers/edac/Kconfig
> > > @@ -462,7 +462,7 @@ config EDAC_ALTERA_SDMMC
> > >  
> > >  config EDAC_SIFIVE
> > >   bool "Sifive platform EDAC driver"
> > > - depends on EDAC=y && RISCV
> > > + depends on EDAC=y && SIFIVE_L2
> 
> Since the guidance from the EDAC maintainers is that this driver is to be 
> a platform driver -- which would, for example, also include EDAC support for 
> other IP blocks (e.g., DRAM controllers) on SiFive SoCs -- this should 
> depend on SOC_SIFIVE, not SIFIVE_L2.

But as-is without major changes it depends on SIFIVE_L2.  And given that
it supports nothing else as-is there is no point in making the code
conditional either.

Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc

[Christoph Hellwig]

On Fri, Sep 06, 2019 at 03:27:44PM -0700, Paul Walmsley wrote:
> - Since the patch doesn't fix any bugs, there shouldn't be a Fixes: line.  
> Please let me know whether I can drop the line locally before I apply the 
> patch, or whether you'd like to resend it.

It fixes the bug that we build code into a default RISC-V image that
we absolutely should not.  And it fixes the bug that the patch placed
code in absolutely the wrong place.

Re: [PATCH net-next, 2/2] hv_netvsc: Sync offloading features to VF NIC

[Jakub Kicinski]

On Thu, 5 Sep 2019 23:07:32 +, Haiyang Zhang wrote:
> > On Fri, 30 Aug 2019 03:45:38 +, Haiyang Zhang wrote:  
> > > VF NIC may go down then come up during host servicing events. This
> > > causes the VF NIC offloading feature settings to roll back to the
> > > defaults. This patch can synchronize features from synthetic NIC to
> > > the VF NIC during ndo_set_features (ethtool -K), and
> > > netvsc_register_vf when VF comes back after host events.
> > >
> > > Signed-off-by: Haiyang Zhang 
> > > Cc: Mark Bloch   
> > 
> > If we want to make this change in behaviour we should change net_failover
> > at the same time.  
> 
> After checking the net_failover, I found it's for virtio based SRIOV, and 
> very 
> different from what we did for Hyper-V based SRIOV.
> 
> We let the netvsc driver acts as both the synthetic (PV) driver and the 
> transparent 
> bonding master for the VF NIC. But net_failover acts as a master device on 
> top 
> of both virtio PV NIC, and VF NIC. And the net_failover doesn't implemented 
> operations, like ndo_set_features.
> So the code change for our netvsc driver cannot be applied to net_failover 
> driver.
> 
> I will re-submit my two patches (fixing the extra tab in the 1st one as you 
> pointed 
> out). Thanks!

I think it stands to reason that two modules which implement the same
functionality behave the same.

Re: [PATCH 9/9] sunxi_defconfig: add new crypto options

[Maxime Ripard]

On Fri, Sep 06, 2019 at 08:45:51PM +0200, Corentin Labbe wrote:
> This patch adds the new allwinner crypto configs to sunxi_defconfig
>
> Signed-off-by: Corentin Labbe 
> ---
>  arch/arm/configs/sunxi_defconfig | 2 ++
>  1 file changed, 2 insertions(+)

Can you also enable it in arm64's defconfig as a module?

>
> diff --git a/arch/arm/configs/sunxi_defconfig 
> b/arch/arm/configs/sunxi_defconfig
> index df433abfcb02..d0ab8ba7710a 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -150,4 +150,6 @@ CONFIG_NLS_CODEPAGE_437=y
>  CONFIG_NLS_ISO8859_1=y
>  CONFIG_PRINTK_TIME=y
>  CONFIG_DEBUG_FS=y
> +CONFIG_CRYPTO_DEV_ALLWINNER=y
> +CONFIG_CRYPTO_DEV_SUN8I_CE=y
>  CONFIG_CRYPTO_DEV_SUN4I_SS=y
> --
> 2.21.0
>

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 6/9] ARM64: dts: allwinner: sun50i: Add Crypto Engine node on A64

[Maxime Ripard]

On Fri, Sep 06, 2019 at 08:45:48PM +0200, Corentin Labbe wrote:
> The Crypto Engine is a hardware cryptographic accelerator that supports
> many algorithms.
> It could be found on most Allwinner SoCs.
>
> This patch enables the Crypto Engine on the Allwinner A64 SoC Device-tree.
>
> Signed-off-by: Corentin Labbe 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 69128a6dfc46..c9e30d462ab1 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -487,6 +487,17 @@
>   reg = <0x1c14000 0x400>;
>   };
>
> + crypto: crypto@1c15000 {
> + compatible = "allwinner,sun50i-a64-crypto";
> + reg = <0x01c15000 0x1000>;
> + interrupts = ;
> + interrupt-names = "ce_ns";

You didn't document that property

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 4/9] ARM: dts: sun8i: r40: add crypto engine node

[Maxime Ripard]

On Fri, Sep 06, 2019 at 08:45:46PM +0200, Corentin Labbe wrote:
> The Crypto Engine is a hardware cryptographic offloader that supports
> many algorithms.
> It could be found on most Allwinner SoCs.
>
> This patch enables the Crypto Engine on the Allwinner R40 SoC Device-tree.
>
> Signed-off-by: Corentin Labbe 
> ---
>  arch/arm/boot/dts/sun8i-r40.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi 
> b/arch/arm/boot/dts/sun8i-r40.dtsi
> index bde068111b85..7eb649cea163 100644
> --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> @@ -266,6 +266,17 @@
>   #phy-cells = <1>;
>   };
>
> + crypto: crypto-engine@1c15000 {
> + compatible = "allwinner,sun8i-r40-crypto";
> + reg = <0x01c15000 0x1000>;
> + interrupts = ;
> + clocks = < CLK_BUS_CE>, < CLK_CE>;
> + clock-names = "ahb", "mod";
> + resets = < RST_BUS_CE>;
> + reset-names = "ahb";
> + status = "okay";

The driver will probe if status is not declared, so if you want it
always enabled you should simply remove status

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 3/9] dt-bindings: crypto: Add DT bindings documentation for sun8i-ce Crypto Engine

[Maxime Ripard]

On Fri, Sep 06, 2019 at 08:45:45PM +0200, Corentin Labbe wrote:
> This patch adds documentation for Device-Tree bindings for the
> Crypto Engine cryptographic accelerator driver.
>
> Signed-off-by: Corentin Labbe 
> ---
>  .../bindings/crypto/allwinner,sun8i-ce.yaml   | 84 +++
>  1 file changed, 84 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
>
> diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml 
> b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
> new file mode 100644
> index ..bd8ccedd6059
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml

So, usually we're using the first compatible supported here as the
name.

> @@ -0,0 +1,84 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/crypto/allwinner,sun8i-ce.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Allwinner Crypto Engine driver
> +
> +maintainers:
> +  - Corentin Labbe 
> +
> +properties:
> +  compatible:
> +oneOf:
> +  - const: allwinner,sun8i-h3-crypto
> +  - const: allwinner,sun8i-r40-crypto
> +  - const: allwinner,sun50i-a64-crypto
> +  - const: allwinner,sun50i-h5-crypto
> +  - const: allwinner,sun50i-h6-crypto

An enum would be better here, it provides a more obvious error
message.

> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 1
> +
> +if:
> +  properties:
> +compatible:
> +  contains:
> +const: allwinner,sun50i-h6-crypto
> +then:
> +  clocks:
> +items:
> +  - description: Bus clock
> +  - description: Module clock
> +  - description: MBus clock
> +
> +  clock-names:
> +items:
> +  - const: ahb
> +  - const: mod
> +  - const: mbus

It looks like there's a reset line on the H6 as well for that
controller (register 0x68c of the CCU, "CE_BGR_REG").

> +else:
> +  clocks:
> +items:
> +  - description: Bus clock
> +  - description: Module clock
> +
> +  clock-names:
> +items:
> +  - const: ahb
> +  - const: mod
> +
> +  resets:
> +maxItems: 1
> +
> +  reset-names:
> +const: ahb

This prevents the usage of the additionalProperties property, which
you should really use.

What you can do instead is moving the clocks and clock-names
description under properties, with a minItems of 2 and a maxItems of
3. Then you can restrict the length of that property to either 2 or 3
depending on the case here.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 1/9] crypto: Add allwinner subdirectory

[Maxime Ripard]

On Fri, Sep 06, 2019 at 08:45:43PM +0200, Corentin Labbe wrote:
> Since a second Allwinner crypto driver will be added, it is better to
> create a dedicated subdirectory.
>
> Signed-off-by: Corentin Labbe 
> ---
>  MAINTAINERS  | 6 ++
>  drivers/crypto/Kconfig   | 2 ++
>  drivers/crypto/Makefile  | 1 +
>  drivers/crypto/allwinner/Kconfig | 6 ++

I guess it would make sense to move the sun4i driver there too?

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [RFC][PATCH v1 0/1] Add support for arm64 to carry ima measurement log in kexec_file_load

[Stephen Boyd]

Quoting Prakhar Srivastava (2019-09-06 16:51:09)
> Add support for arm64 to carry ima measurement log
> to the next kexec'ed session triggered via kexec_file_load.
> - Top of Linux 5.3-rc6
> 
> Currently during kexec the kernel file signatures are/can be validated
> prior to actual load, the information(PE/ima signature) is not carried
> to the next session. This lead to loss of information.
> 
> Carrying forward the ima measurement log to the next kexec'ed session.
> This allows a verifying party to get the entire runtime event log since
> the last full reboot since that is when PCRs were last reset.
> 
> Prakhar Srivastava (1):
>   Add support for arm64 to carry ima measurement log in kexec_file_load

Did anything change from the last round? Please include changelogs so we
know what to look for.

Re: [PATCH v8 0/7] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Fri, Sep 6, 2019 at 8:23 AM Michael S. Tsirkin  wrote:
>
> On Fri, Sep 06, 2019 at 07:53:21AM -0700, Alexander Duyck wrote:
> > This series provides an asynchronous means of reporting to a hypervisor
> > that a guest page is no longer in use and can have the data associated
> > with it dropped. To do this I have implemented functionality that allows
> > for what I am referring to as unused page reporting
> >
> > The functionality for this is fairly simple. When enabled it will allocate
> > statistics to track the number of reported pages in a given free area.
> > When the number of free pages exceeds this value plus a high water value,
> > currently 32, it will begin performing page reporting which consists of
> > pulling pages off of free list and placing them into a scatter list. The
> > scatterlist is then given to the page reporting device and it will perform
> > the required action to make the pages "reported", in the case of
> > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > and as such they are forced out of the guest. After this they are placed
> > back on the free list, and an additional bit is added if they are not
> > merged indicating that they are a reported buddy page instead of a
> > standard buddy page. The cycle then repeats with additional non-reported
> > pages being pulled until the free areas all consist of reported pages.
> >
> > I am leaving a number of things hard-coded such as limiting the lowest
> > order processed to PAGEBLOCK_ORDER, and have left it up to the guest to
> > determine what the limit is on how many pages it wants to allocate to
> > process the hints. The upper limit for this is based on the size of the
> > queue used to store the scattergather list.
>
> I queued this  so this gets tested on linux-next but the mm core changes
> need acks from appropriate people.

Looks like there was a couple issues on arm64 and ia64 architectures.
I believe I have those fixed up and will submit a v9 in the morning
after my test runs have completed.

Thanks.

- Alex

Re: [PATCH v2 14/19] MIPS: Loongson64: Add generic dts

[Jiaxun Yang]

On 2019/9/7 上午10:53, Huacai Chen wrote:

On Thu, Sep 5, 2019 at 10:47 PM Jiaxun Yang  wrote:

Add generic device dts for Loongson-3 devices.
They seems identical but will be different later.

Signed-off-by: Jiaxun Yang 

Hi, Jiaxun,

I'm very glad to see that dts files become less in this version, but I
think we also don't need to distinguish cpu types (i.e.,
3a1000/3b1500/3a2000/3a3000). Then, we only need three dts files
(loongson3_ls2h.dts, loongson3_ls7a.dts, loongson3_rs780.dts) which is
the same as in our own git repository. If we really need to
distinguish cpu type, PRID or CPUCFG in Loongson-3A4000 is more
suitable than dts. In other words, I want dts only do as minimal as
possible.


Hi Huacai,

I have the  same consideration with you. However, the reason why I split 
this dts is that these chips have significant differences.


For example, 3B1x00 have different memory and config registers layout, 
Their HT config space is a delicate node, HTMSI interrupts is not 
functional until 3A3000, and their syscon registers are not identical.


You may say they can be identified by PRID, but I'm not intend to spread 
PRID all the way in other subsystems, thus I think dts is still the best 
way to tell these differences.


Thanks

--

Jiaxun Yang



Huacai

Re: [PATCH] ethernet: micrel: Use DIV_ROUND_CLOSEST directly to make it readable

[zhong jiang]

On 2019/9/7 3:40, Andrew Lunn wrote:
> On Thu, Sep 05, 2019 at 11:53:48PM +0800, zhong jiang wrote:
>> The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d
>> but is perhaps more readable.
> Hi Zhong
>
> Did you find this by hand, or did you use a tool. If a tool is used,
> it is normal to give some credit to the tool.
With the following help of Coccinelle. 
-(((x) + ((__divisor) / 2)) / (__divisor))
+ DIV_ROUND_CLOSEST(x,__divisor)

Sometimes, I will add the information in the description. Sometimes, I desn't 
do that.

I will certainly add the description when I send an series of patches to modify 
the case.

Thanks,
zhong jiang

> Thanks
>   Andrew
>
> .
>

Re: [PATCH v2 00/19] Modernize Loongson64 Machine

[Huacai Chen]

Hi, Jiaxun,

All of us think that Loongson Technology Co. Ltd's naming is very
confusing. They call  both their processors and their bridge-chipset
as "Loongson", so Loongson-3A is processor, Loongson-7A is bridge, and
Loongson-2H can be both processor and bridge.

We all think this is a bad thing, so let's do something in our code to
make life easier:
1, Don't use raw "ls" to stand for loongson anywhere.
2, To describe CPU please use "loongson". E.g., Loongson, Loongson-3,
Loongson-2H, Loongson-3A, Loongson-3B, Loongson-3A4000.
3, To describe bridge (chipset, or PCH) please use LS2H, LS2K and
LS7A, and we can use LS2X to cover them all in some drivers.
4, In file names use their lower-case names. E.g., loongson,
loongson3, ls2h, ls7a.

Don't be afraid of long names. Long names is harmless, but disordered
abbreviation is a nightmare.

Huacai

On Thu, Sep 5, 2019 at 10:44 PM Jiaxun Yang  wrote:
>
> v1:
> - dt-bindings fixup according to Rob's comments
> - irqchip fixup according to Marc's comments
> - ls3-iointc: Make Core map per-IRQ
> - Regenerate kconfigs
> - Typo & style improvements
>
> v2:
> - dt-bindings: Fix IOINTC, collect Rob's review tag
> - dtbs: Drop CPU Node, merge different ways according to Huacai and Paul's 
> comments
>
> Jiaxun Yang (19):
>   MIPS: Loongson64: Rename CPU TYPES
>   MIPS: Loongson64: separate loongson2ef/loongson64 code
>   MAINTAINERS: Fix entries for new loongson64 path
>   irqchip: Export generic chip domain map/unmap functions
>   irqchip: Add driver for Loongson-3 I/O interrupt controller
>   dt-bindings: interrupt-controller: Add Loongson-3 IOINTC
>   irqchip: Add driver for Loongson-3 HyperTransport interrupt controller
>   dt-bindings: interrupt-controller: Add Loongson-3 HTINTC
>   irqchip: i8259: Add plat-poll support
>   irqchip: mips-cpu: Convert to simple domain
>   MIPS: Loongson64: Drop legacy IRQ code
>   dt-bindings: mips: Add loongson boards
>   dt-bindings: Document loongson vendor-prefix
>   MIPS: Loongson64: Add generic dts
>   MIPS: Loongson64: Load built-in dtbs
>   GPIO: loongson: Drop Loongson-3A/3B support
>   MIPS: Loongson: Regenerate defconfigs
>   MAINTAINERS: Add new pathes to LOONGSON64 ARCHITECTURE
>   MAINTAINERS: Add myself as maintainer of LOONGSON64
>
>  .../loongson,ls3-htintc.yaml  |  55 
>  .../loongson,ls3-iointc.yaml  |  79 +
>  .../bindings/mips/loongson/devices.yaml   |  39 +++
>  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
>  MAINTAINERS   |  13 +-
>  arch/mips/Kbuild.platforms|   1 +
>  arch/mips/Kconfig |  83 --
>  arch/mips/boot/dts/Makefile   |   1 +
>  arch/mips/boot/dts/loongson/3a-package.dtsi   |  69 +
>  arch/mips/boot/dts/loongson/3a1000_780e.dts   |  10 +
>  arch/mips/boot/dts/loongson/3a2000_780e.dts   |  10 +
>  arch/mips/boot/dts/loongson/3a3000_780e.dts   |  10 +
>  arch/mips/boot/dts/loongson/3b-package.dtsi   |  69 +
>  arch/mips/boot/dts/loongson/3b1x00_780e.dts   |  10 +
>  arch/mips/boot/dts/loongson/Makefile  |   5 +
>  arch/mips/boot/dts/loongson/rs780e-pch.dtsi   |  35 +++
>  arch/mips/configs/fuloong2e_defconfig |   8 +-
>  arch/mips/configs/lemote2f_defconfig  |   8 +-
>  arch/mips/configs/loongson3_defconfig |  13 +-
>  arch/mips/include/asm/bootinfo.h  |   1 -
>  arch/mips/include/asm/cop2.h  |   2 +-
>  arch/mips/include/asm/cpu-type.h  |   6 +-
>  arch/mips/include/asm/cpu.h   |   4 +-
>  arch/mips/include/asm/hazards.h   |   2 +-
>  arch/mips/include/asm/io.h|   2 +-
>  arch/mips/include/asm/irqflags.h  |   2 +-
>  .../mach-loongson2ef/cpu-feature-overrides.h  |  45 +++
>  .../cs5536/cs5536.h   |   0
>  .../cs5536/cs5536_mfgpt.h |   0
>  .../cs5536/cs5536_pci.h   |   0
>  .../cs5536/cs5536_vsm.h   |   0
>  .../loongson2ef.h}|  31 +-
>  .../machine.h |   6 -
>  .../mc146818rtc.h |   5 +-
>  .../mem.h |   6 +-
>  arch/mips/include/asm/mach-loongson2ef/pci.h  |  43 +++
>  .../include/asm/mach-loongson2ef/spaces.h |  10 +
>  .../asm/mach-loongson64/builtin_dtbs.h|  16 +
>  .../mach-loongson64/cpu-feature-overrides.h   |   8 +-
>  arch/mips/include/asm/mach-loongson64/irq.h   |   6 +-
>  .../asm/mach-loongson64/kernel-entry-init.h   |  74 -
>  .../include/asm/mach-loongson64/loongson64.h  |  50 
>  .../mips/include/asm/mach-loongson64/mmzone.h |  16 -
>  arch/mips/include/asm/mach-loongson64/pci.h   |  41 +--
>  .../include/asm/mach-loongson64/workarounds.h |   4 +-
>  arch/mips/include/asm/module.h|   8 +-
>  arch/mips/include/asm/processor.h |   2 +-
>  

[PATCH v2] kbuild: allow Clang to find unused static inline functions for W=1 build

[Masahiro Yamada]

GCC and Clang have different policy for -Wunused-function; GCC does not
warn unused static inline functions at all whereas Clang does if they
are defined in source files instead of included headers although it has
been suppressed since commit abb2ea7dfd82 ("compiler, clang: suppress
warning for unused static inline functions").

We often miss to delete unused functions where 'static inline' is used
in *.c files since there is no tool to detect them. Unused code remains
until somebody notices. For example, commit 075ddd75680f ("regulator:
core: remove unused rdev_get_supply()").

Let's remove __maybe_unused from the inline macro to allow Clang to
start finding unused static inline functions. For now, we do this only
for W=1 build since it is not a good idea to sprinkle warnings for the
normal build (e.g. 35 warnings for arch/x86/configs/x86_64_defconfig).

My initial attempt was to add -Wno-unused-function for no W= build
(https://lore.kernel.org/patchwork/patch/1120594/)

Nathan Chancellor pointed out that would weaken Clang's checks since
we would no longer get -Wunused-function without W=1. It is true GCC
would catch unused static non-inline functions, but it would weaken
Clang as a standalone compiler, at least.

Hence, here is a counter implementation. The current problem is, W=...
only controls compiler flags, which are globally effective. There is
no way to address only 'static inline' functions.

This commit defines KBUILD_EXTRA_WARN[123] corresponding to W=[123].
When KBUILD_EXTRA_WARN1 is defined, __maybe_unused is omitted from
the 'inline' macro.

The new macro __inline_maybe_unused makes the code a bit uglier, so I
hope we can remove it entirely after fixing most of the warnings.

If you contribute to code clean-up, please run "make CC=clang W=1"
and check -Wunused-function warnings. You will find lots of unused
functions.

Some of them are false-positives because the call-sites are disabled
by #ifdef. I do not like to abuse the inline keyword for suppressing
unused-function warnings because it is intended to be a hint for the
compiler optimization. I prefer #ifdef around the definition, or
__maybe_unused if #ifdef would make the code too ugly.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Nathan Chancellor 
Tested-by: Nathan Chancellor 
---

Changes in v2:
 - Rebase on top of https://patchwork.kernel.org/patch/11124933/

 include/linux/compiler_types.h | 20 ++--
 scripts/Makefile.extrawarn |  6 ++
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 599c27b56c29..b056a40116da 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -130,10 +130,6 @@ struct ftrace_likely_data {
 
 /*
  * Force always-inline if the user requests it so via the .config.
- * GCC does not warn about unused static inline functions for
- * -Wunused-function.  This turns out to avoid the need for complex #ifdef
- * directives.  Suppress the warning in clang as well by using "unused"
- * function attribute, which is redundant but not harmful for gcc.
  * Prefer gnu_inline, so that extern inline functions do not emit an
  * externally visible function. This makes extern inline behave as per gnu89
  * semantics rather than c99. This prevents multiple symbol definition errors
@@ -144,15 +140,27 @@ struct ftrace_likely_data {
  */
 #if !defined(CONFIG_OPTIMIZE_INLINING)
 #define inline inline __attribute__((__always_inline__)) __gnu_inline \
-   __maybe_unused notrace
+   __inline_maybe_unused notrace
 #else
 #define inline inline__gnu_inline \
-   __maybe_unused notrace
+   __inline_maybe_unused notrace
 #endif
 
 #define __inline__ inline
 #define __inline   inline
 
+/*
+ * GCC does not warn about unused static inline functions for 
-Wunused-function.
+ * Suppress the warning in clang as well by using __maybe_unused, but enable it
+ * for W=1 build. This will allow clang to find unused functions. Remove the
+ * __inline_maybe_unused entirely after fixing most of -Wunused-function 
warnings.
+ */
+#ifdef KBUILD_EXTRA_WARN1
+#define __inline_maybe_unused
+#else
+#define __inline_maybe_unused __maybe_unused
+#endif
+
 /*
  * Rather then using noinline to prevent stack consumption, use
  * noinline_for_stack instead.  For documentation reasons.
diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 53eb7e0c6a5a..ecddf83ac142 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -36,6 +36,8 @@ KBUILD_CFLAGS += $(call cc-option, -Wstringop-truncation)
 KBUILD_CFLAGS += -Wno-missing-field-initializers
 KBUILD_CFLAGS += -Wno-sign-compare
 
+KBUILD_CPPFLAGS += -DKBUILD_EXTRA_WARN1
+
 else
 
 # Some diagnostics enabled by default are noisy.
@@ -65,6 +67,8 @@ KBUILD_CFLAGS += -Wsign-compare
 KBUILD_CFLAGS += $(call cc-option, -Wmaybe-uninitialized)
 KBUILD_CFLAGS += $(call cc-option, -Wunused-macros)
 

Re: [PATCH v2 14/19] MIPS: Loongson64: Add generic dts

[Huacai Chen]

On Thu, Sep 5, 2019 at 10:47 PM Jiaxun Yang  wrote:
>
> Add generic device dts for Loongson-3 devices.
> They seems identical but will be different later.
>
> Signed-off-by: Jiaxun Yang 
> ---
>  arch/mips/Kconfig   |  4 +-
>  arch/mips/boot/dts/Makefile |  1 +
>  arch/mips/boot/dts/loongson/3a-package.dtsi | 69 +
>  arch/mips/boot/dts/loongson/3a1000_780e.dts | 10 +++
>  arch/mips/boot/dts/loongson/3a2000_780e.dts | 10 +++
>  arch/mips/boot/dts/loongson/3a3000_780e.dts | 10 +++
>  arch/mips/boot/dts/loongson/3b-package.dtsi | 69 +
>  arch/mips/boot/dts/loongson/3b1x00_780e.dts | 10 +++
>  arch/mips/boot/dts/loongson/Makefile|  5 ++
>  arch/mips/boot/dts/loongson/rs780e-pch.dtsi | 35 +++
>  10 files changed, 222 insertions(+), 1 deletion(-)
>  create mode 100644 arch/mips/boot/dts/loongson/3a-package.dtsi
>  create mode 100644 arch/mips/boot/dts/loongson/3a1000_780e.dts
>  create mode 100644 arch/mips/boot/dts/loongson/3a2000_780e.dts
>  create mode 100644 arch/mips/boot/dts/loongson/3a3000_780e.dts
>  create mode 100644 arch/mips/boot/dts/loongson/3b-package.dtsi
>  create mode 100644 arch/mips/boot/dts/loongson/3b1x00_780e.dts
>  create mode 100644 arch/mips/boot/dts/loongson/Makefile
>  create mode 100644 arch/mips/boot/dts/loongson/rs780e-pch.dtsi
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index b6bdd96ec74e..5bad9aafcbdf 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -489,6 +489,8 @@ config MACH_LOONGSON64
> select SYS_SUPPORTS_LITTLE_ENDIAN
> select ZONE_DMA32
> select SYS_SUPPORTS_ZBOOT
> +   select USE_OF
> +   select BUILTIN_DTB
> help
>   This enables the support of Loongson-3A/3B/2-series-soc processors
>
> @@ -3047,7 +3049,7 @@ endchoice
>  choice
> prompt "Kernel command line type" if !CMDLINE_OVERRIDE
> default MIPS_CMDLINE_FROM_DTB if USE_OF && !ATH79 && !MACH_INGENIC && 
> \
> -!MIPS_MALTA && \
> +!MACH_LOONGSON64 && !MIPS_MALTA && \
>  !CAVIUM_OCTEON_SOC
> default MIPS_CMDLINE_FROM_BOOTLOADER
>
> diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
> index 1e79cab8e269..d429a69bfe30 100644
> --- a/arch/mips/boot/dts/Makefile
> +++ b/arch/mips/boot/dts/Makefile
> @@ -4,6 +4,7 @@ subdir-y+= cavium-octeon
>  subdir-y   += img
>  subdir-y   += ingenic
>  subdir-y   += lantiq
> +subdir-y   += loongson
>  subdir-y   += mscc
>  subdir-y   += mti
>  subdir-y   += netlogic
> diff --git a/arch/mips/boot/dts/loongson/3a-package.dtsi 
> b/arch/mips/boot/dts/loongson/3a-package.dtsi
> new file mode 100644
> index ..739cf43c7310
> --- /dev/null
> +++ b/arch/mips/boot/dts/loongson/3a-package.dtsi
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include 
> +
> +/ {
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +
> +   cpuintc: interrupt-controller {
> +   #address-cells = <0>;
> +   #interrupt-cells = <1>;
> +   interrupt-controller;
> +   compatible = "mti,cpu-interrupt-controller";
> +   };
> +
> +   package@0 {
> +   compatible = "simple-bus";
> +   #address-cells = <2>;
> +   #size-cells = <1>;
> +   ranges = <0 0x1fe0 0 0x1fe0 0x10
> +   0 0x3ff0 0 0x3ff0 0x10
> +   0xEFD 0xFB00 0xEFD 0xFB00 0x1000 
> /* 3A HT Config Space */>;
> +
> +   iointc: interrupt-controller@3ff01400 {
> +   compatible = "loongson,ls3-iointc";
> +   reg = <0 0x3ff01400 0x64>;
> +
> +   interrupt-controller;
> +   #interrupt-cells = <2>;
> +
> +   interrupt-parent = <>;
> +   interrupts = <2>;
> +   };
> +
> +   cpu_uart0: serial@1fe001e0 {
> +   device_type = "serial";
> +   compatible = "ns16550a";
> +   reg = <0 0x1fe001e0 0x8>;
> +   clock-frequency = <3300>;
> +   interrupt-parent = <>;
> +   interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
> +   no-loopback-test;
> +   };
> +
> +   cpu_uart1: serial@1fe001e8 {
> +   status = "disabled";
> +   device_type = "serial";
> +   compatible = "ns16550a";
> +   reg = <0 0x1fe001e8 0x8>;
> +   clock-frequency = <3300>;
> +   interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
> +   interrupt-parent = <>;
> +  

[PATCH v4 4/5] doc: media: vimc: Update module parameter usage information

[Shuah Khan]

vimc driver is now a monolithic driver. Update the module parameter
usage information to reflect that.

Signed-off-by: Shuah Khan 
---
 Documentation/media/v4l-drivers/vimc.rst | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/media/v4l-drivers/vimc.rst 
b/Documentation/media/v4l-drivers/vimc.rst
index 406417680db5..a582af0509ee 100644
--- a/Documentation/media/v4l-drivers/vimc.rst
+++ b/Documentation/media/v4l-drivers/vimc.rst
@@ -76,22 +76,22 @@ vimc-capture:
* 1 Pad sink
* 1 Pad source
 
-Module options
+
+Module options
 ---
 
-Vimc has a few module parameters to configure the driver. You should pass
-those arguments to each subdevice, not to the vimc module. For example::
+Vimc has a few module parameters to configure the driver.
 
-vimc_subdevice.param=value
+param=value
 
-* ``vimc_scaler.sca_mult=``
+* ``sca_mult=``
 
 Image size multiplier factor to be used to multiply both width and
 height, so the image size will be ``sca_mult^2`` bigger than the
 original one. Currently, only supports scaling up (the default value
 is 3).
 
-* ``vimc_debayer.deb_mean_win_size=``
+* ``deb_mean_win_size=``
 
 Window size to calculate the mean. Note: the window size needs to be an
 odd number, as the main pixel stays in the center of the window,
-- 
2.20.1

[PATCH v4 0/5] Collapse vimc into single monolithic driver

[Shuah Khan]

vimc uses Component API to split the driver into functional components.
The real hardware resembles a monolith structure than component and
component structure added a level of complexity making it hard to
maintain without adding any real benefit.

The sensor is one vimc component that would makes sense to be a separate
module to closely align with the real hardware. It would be easier to
collapse vimc into single monolithic driver first and then split the
sensor off as a separate module.

This patch series removes the component API and makes minimal changes to
the code base preserving the functional division of the code structure.
Preserving the functional structure allows us to split the sensor off
as a separate module in the future.

The following configure and stream test works on all devices.

media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]'

v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440
v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81
v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81

v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1
v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2
v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3

The second patch in the series fixes a general protection fault found
when rmmod is done while stream is active.

- rmmod while streaming returns vimc is in use
- rmmod without active stream works correctly

Changed since v3: (5 patches)
Patch 1:
- Main change is adding an array of struct vimc_ent_device(s) to save
  vimc_ent_device(s), subdevs create in their "add" hooks. These
  get used to create links and removing the subdevs. vimc-core allocates
  this array which sized to number of entries in the topology defined in
  the vimc_pipeline_config structure.
- Remove links when register fails before registering the media device.
  In this case, entity links need to be removed from error paths.
Patch 2: no change.
New patch 3:
- Cleaning up duplicated IS_SRC and IS_SINK defines and moving them to
  common header.
New patch 4:
- Documentation module parameter usage updates.
New patch 5:
- Lastly adding myself as a reviewers to MAINTAINERS file for vimc

Changes since v2:
- Rebase to media master on top of vimc reverts
- Rename "vent" variable to "vcfg" to reflect config and standout
  from "ved"
- Error handling when adding subdevs fails to remove already added
  subdevs, do other clean-up and bail out.

Changes since v1:
Patch 1 & 2: (patch 1 in this series)
- Collapsed the two patches into one
- Added common defines (vimc_device and vimc_ent_config) to vimc-common.h
  based on our discussion.
- Addressed review comments from Helen and Laurent
- Use vimc-common.h instead of creating a new file.
- Other minor comments from Helen on int vs. unsigned int and
  not needing to initialize ret in vimc_add_subdevs()
Patch 3 (patch 2 in this series):
- The second patch is the fix for gpf. Updated the patch after looking
  at the test results from Andre and Helen. This problem is in a common
  code and impacts all subdevs. The fix addresses the core problem and
  fixes it. Fix removes pads release from v4l2_device_unregister_subdev()
  and pads are now released from the sd release handler with all other
  resources.

Outstanding:
- Update documentation with the correct topology.
- There is one outstanding gpf remaining in the unbind path. I will
  fix that in a separate patch. This is an existing problem and will
  be easier to fix on top of this patch series.

vimc_print_dot (--print-dot) topology after this change: (no change
compared to media master)
digraph board {
rankdir=TB
n0001 [label="{{} | Sensor A\n/dev/v4l-subdev0 | { 0}}", 
shape=Mrecord, style=filled, fillcolor=green]
n0001:port0 -> n0005:port0 [style=bold]
n0001:port0 -> n000b [style=bold]
n0003 [label="{{} | Sensor B\n/dev/v4l-subdev1 | { 0}}", 
shape=Mrecord, style=filled, fillcolor=green]
n0003:port0 -> n0008:port0 [style=bold]
n0003:port0 -> n000f [style=bold]
n0005 [label="{{ 0} | Debayer A\n/dev/v4l-subdev2 | { 
1}}", shape=Mrecord, style=filled, fillcolor=green]
n0005:port1 -> n0015:port0
n0008 [label="{{ 0} | Debayer B\n/dev/v4l-subdev3 | { 
1}}", shape=Mrecord, style=filled, fillcolor=green]
n0008:port1 -> n0015:port0 [style=dashed]
n000b [label="Raw Capture 0\n/dev/video0", shape=box, style=filled, 
fillcolor=yellow]
n000f [label="Raw Capture 1\n/dev/video1", shape=box, style=filled, 
fillcolor=yellow]
n0013 [label="{{} | RGB/YUV Input\n/dev/v4l-subdev4 | { 
0}}", shape=Mrecord, 

[PATCH v4 1/5] media: vimc: Collapse component structure into a single monolithic driver

[Shuah Khan]

vimc uses Component API to split the driver into functional components.
The real hardware resembles a monolith structure than component and
component structure added a level of complexity making it hard to
maintain without adding any real benefit.

The sensor is one vimc component that would makes sense to be a separate
module to closely align with the real hardware. It would be easier to
collapse vimc into single monolithic driver first and then split the
sensor off as a separate module.

Collapse it into a single monolithic driver removing the Component API.
This patch removes the component API and makes minimal changes to the
code base preserving the functional division of the code structure.
Preserving the functional structure allows us to split the sensor off
as a separate module in the future.

Major design elements in this change are:
- Use existing struct vimc_ent_config and struct vimc_pipeline_config
  to drive the initialization of the functional components.
- Make vimc_device and vimc_ent_config global by moving them to
  vimc-common.h
- Add two new hooks add and rm to initialize and register, unregister
  and free subdevs.
- All component API is now gone and bind and unbind hooks are modified
  to do "add" and "rm" with minimal changes to just add and rm subdevs.
- vimc-core's bind and unbind are now register and unregister.
- Add a new field to vimc_device structure for saving the pointers to
  struct vimc_ent_device(s) subdevs create in their "add" hooks. These
  get used to create links and removing the subdevs. vimc-core allocates
  this array which sized to number of entries in the topology defined in
  the vimc_pipeline_config structure.
- vimc-core invokes "add" hooks from its vimc_register_devices().
  The "add" hooks remain the same and register subdevs. They don't
  create platform devices of their own and use vimc's pdev.dev as
  their reference device. Each "add" hook returns pointer to its struct
  vimc_ent_device. This is saved in the vimc_device ent_devs array.
- vimc-core invokes "rm" hooks from its unregister to unregister subdevs
  and cleanup.
- vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device
  and the corresponding vimc_ent_device saved in the ent_devs.

The following configure and stream test works on all devices.

media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]'

v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440
v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81
v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81

v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1
v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2
v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3

Signed-off-by: Shuah Khan 
---
 drivers/media/platform/vimc/Makefile   |   7 +-
 drivers/media/platform/vimc/vimc-capture.c |  81 ++--
 drivers/media/platform/vimc/vimc-common.h  |  54 ++
 drivers/media/platform/vimc/vimc-core.c| 216 +
 drivers/media/platform/vimc/vimc-debayer.c |  69 ++-
 drivers/media/platform/vimc/vimc-scaler.c  |  73 ++-
 drivers/media/platform/vimc/vimc-sensor.c  |  73 ++-
 7 files changed, 193 insertions(+), 380 deletions(-)

diff --git a/drivers/media/platform/vimc/Makefile 
b/drivers/media/platform/vimc/Makefile
index 96d06f030c31..a53b2b532e9f 100644
--- a/drivers/media/platform/vimc/Makefile
+++ b/drivers/media/platform/vimc/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
-vimc-y := vimc-core.o vimc-common.o vimc-streamer.o
+vimc-y := vimc-core.o vimc-common.o vimc-streamer.o vimc-capture.o \
+   vimc-debayer.o vimc-scaler.o vimc-sensor.o
+
+obj-$(CONFIG_VIDEO_VIMC) += vimc.o
 
-obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc-capture.o vimc-debayer.o \
-vimc-scaler.o vimc-sensor.o
diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index 1d56b91830ba..602f80323031 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -5,10 +5,6 @@
  * Copyright (C) 2015-2017 Helen Koike 
  */
 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -16,8 +12,6 @@
 #include "vimc-common.h"
 #include "vimc-streamer.h"
 
-#define VIMC_CAP_DRV_NAME "vimc-capture"
-
 struct vimc_cap_device {
struct vimc_ent_device ved;
struct video_device vdev;
@@ -340,13 +334,11 @@ static void vimc_cap_release(struct video_device *vdev)
kfree(vcap);
 }
 
-static void vimc_cap_comp_unbind(struct device *comp, struct device *master,
-void *master_data)
+void vimc_cap_rm(struct vimc_device *vimc, struct vimc_ent_device *ved)
 {
-   struct 

[PATCH v4 5/5] MAINTAINERS: Add reviewer to vimc driver

[Shuah Khan]

After practically re-writing the driver to collpase it into a monolith,
I am adding myself as a reviewer for vimc driver.

Signed-off-by: Shuah Khan 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7c62b45201d7..4529d257f8db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17041,6 +17041,7 @@ F:  include/media/videobuf2-*
 
 VIMC VIRTUAL MEDIA CONTROLLER DRIVER
 M: Helen Koike 
+R: Shuah Khan 
 L: linux-me...@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
 W: https://linuxtv.org
-- 
2.20.1

[PATCH v4 3/5] vimc: move duplicated IS_SRC and IS_SINK to common header

[Shuah Khan]

Move duplicated IS_SRC and IS_SINK dfines to common header. Rename
them to VIMC_IS_SRC and VIM_IS_SINK.

Signed-off-by: Shuah Khan 
---
 drivers/media/platform/vimc/vimc-common.h  |  4 
 drivers/media/platform/vimc/vimc-debayer.c | 11 ---
 drivers/media/platform/vimc/vimc-scaler.c  |  8 +++-
 3 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-common.h 
b/drivers/media/platform/vimc/vimc-common.h
index 87ee84f78322..236412ad7548 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -27,6 +27,10 @@
 
 #define VIMC_FRAME_INDEX(lin, col, width, bpp) ((lin * width + col) * bpp)
 
+/* Source and sink pad checks */
+#define VIMC_IS_SRC(pad)   (pad)
+#define VIMC_IS_SINK(pad)  (!(pad))
+
 /**
  * struct vimc_colorimetry_clamp - Adjust colorimetry parameters
  *
diff --git a/drivers/media/platform/vimc/vimc-debayer.c 
b/drivers/media/platform/vimc/vimc-debayer.c
index b38b55f51a24..37f3767db469 100644
--- a/drivers/media/platform/vimc/vimc-debayer.c
+++ b/drivers/media/platform/vimc/vimc-debayer.c
@@ -22,9 +22,6 @@ MODULE_PARM_DESC(deb_mean_win_size, " the window size to 
calculate the mean.\n"
"stays in the center of the window, otherwise the next odd number "
"is considered");
 
-#define IS_SINK(pad) (!pad)
-#define IS_SRC(pad)  (pad)
-
 enum vimc_deb_rgb_colors {
VIMC_DEB_RED = 0,
VIMC_DEB_GREEN = 1,
@@ -157,7 +154,7 @@ static int vimc_deb_enum_mbus_code(struct v4l2_subdev *sd,
   struct v4l2_subdev_mbus_code_enum *code)
 {
/* We only support one format for source pads */
-   if (IS_SRC(code->pad)) {
+   if (VIMC_IS_SRC(code->pad)) {
struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
 
if (code->index)
@@ -183,7 +180,7 @@ static int vimc_deb_enum_frame_size(struct v4l2_subdev *sd,
if (fse->index)
return -EINVAL;
 
-   if (IS_SINK(fse->pad)) {
+   if (VIMC_IS_SINK(fse->pad)) {
const struct vimc_deb_pix_map *vpix =
vimc_deb_pix_map_by_code(fse->code);
 
@@ -213,7 +210,7 @@ static int vimc_deb_get_fmt(struct v4l2_subdev *sd,
  vdeb->sink_fmt;
 
/* Set the right code for the source pad */
-   if (IS_SRC(fmt->pad))
+   if (VIMC_IS_SRC(fmt->pad))
fmt->format.code = vdeb->src_code;
 
return 0;
@@ -260,7 +257,7 @@ static int vimc_deb_set_fmt(struct v4l2_subdev *sd,
 * Do not change the format of the source pad,
 * it is propagated from the sink
 */
-   if (IS_SRC(fmt->pad)) {
+   if (VIMC_IS_SRC(fmt->pad)) {
fmt->format = *sink_fmt;
/* TODO: Add support for other formats */
fmt->format.code = vdeb->src_code;
diff --git a/drivers/media/platform/vimc/vimc-scaler.c 
b/drivers/media/platform/vimc/vimc-scaler.c
index 05db5070e268..a5a0855ad9cd 100644
--- a/drivers/media/platform/vimc/vimc-scaler.c
+++ b/drivers/media/platform/vimc/vimc-scaler.c
@@ -16,8 +16,6 @@ static unsigned int sca_mult = 3;
 module_param(sca_mult, uint, );
 MODULE_PARM_DESC(sca_mult, " the image size multiplier");
 
-#define IS_SINK(pad)   (!pad)
-#define IS_SRC(pad)(pad)
 #define MAX_ZOOM   8
 
 struct vimc_sca_device {
@@ -93,7 +91,7 @@ static int vimc_sca_enum_frame_size(struct v4l2_subdev *sd,
fse->min_width = VIMC_FRAME_MIN_WIDTH;
fse->min_height = VIMC_FRAME_MIN_HEIGHT;
 
-   if (IS_SINK(fse->pad)) {
+   if (VIMC_IS_SINK(fse->pad)) {
fse->max_width = VIMC_FRAME_MAX_WIDTH;
fse->max_height = VIMC_FRAME_MAX_HEIGHT;
} else {
@@ -116,7 +114,7 @@ static int vimc_sca_get_fmt(struct v4l2_subdev *sd,
 vsca->sink_fmt;
 
/* Scale the frame size for the source pad */
-   if (IS_SRC(format->pad)) {
+   if (VIMC_IS_SRC(format->pad)) {
format->format.width = vsca->sink_fmt.width * sca_mult;
format->format.height = vsca->sink_fmt.height * sca_mult;
}
@@ -165,7 +163,7 @@ static int vimc_sca_set_fmt(struct v4l2_subdev *sd,
 * Do not change the format of the source pad,
 * it is propagated from the sink
 */
-   if (IS_SRC(fmt->pad)) {
+   if (VIMC_IS_SRC(fmt->pad)) {
fmt->format = *sink_fmt;
fmt->format.width = sink_fmt->width * sca_mult;
fmt->format.height = sink_fmt->height * sca_mult;
-- 
2.20.1

[PATCH v4 2/5] media: vimc: Fix gpf in rmmod path when stream is active

[Shuah Khan]

If vimc module is removed while streaming is in progress, sensor subdev
unregister runs into general protection fault when it tries to unregister
media entities. This is a common subdev problem related to releasing
pads from v4l2_device_unregister_subdev() before calling unregister.
Unregister references pads during unregistering subdev.

The sd release handler is the right place for releasing all sd resources
including pads. The release handlers currently release all resources
except the pads.

Fix v4l2_device_unregister_subdev() not release pads and release pads
from the sd_int_op release handlers.

kernel: [ 4136.715839] general protection fault:  [#1] SMP PTI
kernel: [ 4136.715847] CPU: 2 PID: 1972 Comm: bash Not tainted 5.3.0-rc2+ #4
kernel: [ 4136.715850] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18 
09/24/2013
kernel: [ 4136.715858] RIP: 0010:media_gobj_destroy.part.16+0x1f/0x60
kernel: [ 4136.715863] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 
48 89 fe 48 89 e5 53 48 89 fb 48 c7 c7 00 7f cf b0 e8 24 fa ff ff 48 8b 03 <48> 
83 80 a0 00 00 00 01 48 8b 43 18 48 8b 53 10 48 89 42 08 48 89
kernel: [ 4136.715866] RSP: 0018:9b2248fe3cb0 EFLAGS: 00010246
kernel: [ 4136.715870] RAX: bcf2bfbfa0d63c2f RBX: 88c3eb37e9c0 RCX: 
802a0018
kernel: [ 4136.715873] RDX: 88c3e4f6a078 RSI: 88c3eb37e9c0 RDI: 
b0cf7f00
kernel: [ 4136.715876] RBP: 9b2248fe3cb8 R08: 0102 R09: 
b0492b00
kernel: [ 4136.715879] R10: 9b2248fe3c28 R11: 0001 R12: 
0038
kernel: [ 4136.715881] R13: c09a1628 R14: 88c3e4f6a028 R15: 
fff2
kernel: [ 4136.715885] FS:  7f8389647740() GS:88c46550() 
knlGS:
kernel: [ 4136.715888] CS:  0010 DS:  ES:  CR0: 80050033
kernel: [ 4136.715891] CR2: 55d008f80fd8 CR3: 0001996ec005 CR4: 
000606e0
kernel: [ 4136.715894] Call Trace:
kernel: [ 4136.715903]  media_gobj_destroy+0x14/0x20
kernel: [ 4136.715908]  __media_device_unregister_entity+0xb3/0xe0
kernel: [ 4136.715915]  media_device_unregister_entity+0x30/0x40
kernel: [ 4136.715920]  v4l2_device_unregister_subdev+0xa8/0xe0
kernel: [ 4136.715928]  vimc_ent_sd_unregister+0x1e/0x30 [vimc]
kernel: [ 4136.715933]  vimc_sen_rm+0x16/0x20 [vimc]
kernel: [ 4136.715938]  vimc_remove+0x3e/0xa0 [vimc]
kernel: [ 4136.715945]  platform_drv_remove+0x25/0x50
kernel: [ 4136.715951]  device_release_driver_internal+0xe0/0x1b0
kernel: [ 4136.715956]  device_driver_detach+0x14/0x20
kernel: [ 4136.715960]  unbind_store+0xd1/0x130
kernel: [ 4136.715965]  drv_attr_store+0x27/0x40
kernel: [ 4136.715971]  sysfs_kf_write+0x48/0x60
kernel: [ 4136.715976]  kernfs_fop_write+0x128/0x1b0
kernel: [ 4136.715982]  __vfs_write+0x1b/0x40
kernel: [ 4136.715987]  vfs_write+0xc3/0x1d0
kernel: [ 4136.715993]  ksys_write+0xaa/0xe0
kernel: [ 4136.715999]  __x64_sys_write+0x1a/0x20
kernel: [ 4136.716005]  do_syscall_64+0x5a/0x130
kernel: [ 4136.716010]  entry_SYSCALL_64_after_hwframe+0x4
Signed-off-by: Shuah Khan 
---
 drivers/media/platform/vimc/vimc-common.c  | 3 +--
 drivers/media/platform/vimc/vimc-debayer.c | 1 +
 drivers/media/platform/vimc/vimc-scaler.c  | 1 +
 drivers/media/platform/vimc/vimc-sensor.c  | 1 +
 4 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-common.c 
b/drivers/media/platform/vimc/vimc-common.c
index 7e1ae0b12f1e..a3120f4f7a90 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -375,7 +375,7 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
 {
int ret;
 
-   /* Allocate the pads */
+   /* Allocate the pads. Should be released from the sd_int_op release */
ved->pads = vimc_pads_init(num_pads, pads_flag);
if (IS_ERR(ved->pads))
return PTR_ERR(ved->pads);
@@ -424,7 +424,6 @@ EXPORT_SYMBOL_GPL(vimc_ent_sd_register);
 void vimc_ent_sd_unregister(struct vimc_ent_device *ved, struct v4l2_subdev 
*sd)
 {
media_entity_cleanup(ved->ent);
-   vimc_pads_cleanup(ved->pads);
v4l2_device_unregister_subdev(sd);
 }
 EXPORT_SYMBOL_GPL(vimc_ent_sd_unregister);
diff --git a/drivers/media/platform/vimc/vimc-debayer.c 
b/drivers/media/platform/vimc/vimc-debayer.c
index 00850f2501ad..b38b55f51a24 100644
--- a/drivers/media/platform/vimc/vimc-debayer.c
+++ b/drivers/media/platform/vimc/vimc-debayer.c
@@ -482,6 +482,7 @@ static void vimc_deb_release(struct v4l2_subdev *sd)
struct vimc_deb_device *vdeb =
container_of(sd, struct vimc_deb_device, sd);
 
+   vimc_pads_cleanup(vdeb->ved.pads);
kfree(vdeb);
 }
 
diff --git a/drivers/media/platform/vimc/vimc-scaler.c 
b/drivers/media/platform/vimc/vimc-scaler.c
index 28a947950a0b..05db5070e268 100644
--- a/drivers/media/platform/vimc/vimc-scaler.c
+++ b/drivers/media/platform/vimc/vimc-scaler.c
@@ -338,6 +338,7 @@ static void 

Re: [PATCH] kunit: Fix '--build_dir' option

[shuah]

On 9/6/19 7:16 PM, Brendan Higgins wrote:

On Fri, Sep 6, 2019 at 9:12 AM SeongJae Park  wrote:


Running kunit with '--build_dir' option gives following error message:

```
$ ./tools/testing/kunit/kunit.py run --build_dir ../linux.out.kunit/
[00:57:24] Building KUnit Kernel ...
[00:57:29] Starting KUnit Kernel ...
Traceback (most recent call last):
   File "./tools/testing/kunit/kunit.py", line 136, in 
 main(sys.argv[1:])
   File "./tools/testing/kunit/kunit.py", line 129, in main
 result = run_tests(linux, request)
   File "./tools/testing/kunit/kunit.py", line 68, in run_tests
 test_result = kunit_parser.parse_run_tests(kunit_output)
   File "/home/sjpark/linux/tools/testing/kunit/kunit_parser.py", line
283, in parse_run_tests
 test_result =
parse_test_result(list(isolate_kunit_output(kernel_output)))
   File "/home/sjpark/linux/tools/testing/kunit/kunit_parser.py", line
54, in isolate_kunit_output
 for line in kernel_output:
   File "/home/sjpark/linux/tools/testing/kunit/kunit_kernel.py", line
145, in run_kernel
 process = self._ops.linux_bin(args, timeout, build_dir)
   File "/home/sjpark/linux/tools/testing/kunit/kunit_kernel.py", line
69, in linux_bin
 stderr=subprocess.PIPE)
   File "/usr/lib/python3.5/subprocess.py", line 947, in __init__
 restore_signals, start_new_session)
   File "/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child
 raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: './linux'
```

This error occurs because the '--build_dir' option value is not passed
to the 'run_kernel()' function.  Consequently, the function assumes
the kernel image that built for the tests, which is under the
'--build_dir' directory, is in kernel source directory and finally raises
the 'FileNotFoundError'.

This commit fixes the problem by properly passing the '--build_dir'
option value to the 'run_kernel()'.

Signed-off-by: SeongJae Park 


Reviewed-by: Brendan Higgins 
Tested-by: Brendan Higgins 

Thanks!



Thanks Brendan! I will apply the patch for 5.4-rc1.

SeongJae Park! In the future, please send tag versions. This should
have been [PATCH v2].

thanks,
-- Shuah

Re: [PATCH v3 1/2] kbuild: refactor scripts/Makefile.extrawarn

[Masahiro Yamada]

On Sun, Sep 1, 2019 at 1:26 AM Masahiro Yamada
 wrote:
>
> Instead of the warning-[123] magic, let's accumulate compiler options
> to KBUILD_CFLAGS directly as the top Makefile does. I think this makes
> easier to understand what is going on in this file.
>
> This commit slightly changes the behavior, I think all of which are OK.
>
> [1] Currently, cc-option calls are needlessly evaluated. For example,
>   warning-3 += $(call cc-option, -Wpacked-bitfield-compat)
> needs evaluating only when W=3, but it is actually evaluated for
> W=1, W=2 as well. With this commit, only relevant cc-option calls
> will be evaluated. This is a slight optimization.
>
> [2] Currently, unsupported level like W=4 is checked by:
>   $(error W=$(KBUILD_ENABLE_EXTRA_GCC_CHECKS) is unknown)
> This will no longer be checked, but I do not think it is a big
> deal.
>
> [3] Currently, 4 Clang warnings (Winitializer-overrides, Wformat,
> Wsign-compare, Wformat-zero-length) are shown by any of W=1, W=2,
> and W=3. With this commit, they will be warned only by W=1. I
> think this is a more correct behavior since each warning belongs
> to only one group.
>
> For understanding this commit correctly:
>
> We have 3 warning groups, W=1, W=2, and W=3. You may think W=3 has a
> higher level than W=1, but they are actually independent. If you like,
> you can combine them like W=13. To enable all the warnings, you can
> pass W=123. It is shown by 'make help', but not noticed much. Since we
> support W= combination, there should not exist intersection among the
> three groups. If we enable Winitializer-overrides for W=1, we do not
> need to for W=2 or W=3. This is the reason why I think the change [3]
> makes sense.
>
> The documentation says -Winitializer-overrides is enabled by default.
> (https://clang.llvm.org/docs/DiagnosticsReference.html#winitializer-overrides)
> We negate it by passing -Wno-initializer-overrides for the normal
> build, but we do not do that for W=1. This means, W=1 effectively
> enables -Winitializer-overrides by the clang's default. The same for
> the other three.
>
> Add comments in case people are confused with the code.
>
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Nathan Chancellor 
> Tested-by: Sedat Dilek 
> Acked-by: Nick Desaulniers 
> Acked-by: Miguel Ojeda 
> ---

Both applied to linux-kbuild.


> Changes in v3:
>   - Added yet more comments.
> Fix grammatical mistake 'does' -> 'do'.
>
> Changes in v2:
>   - Added comments and more commit log
>
>  scripts/Makefile.extrawarn | 106 -
>  1 file changed, 56 insertions(+), 50 deletions(-)
>
> diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
> index a74ce2e3c33e..d226c5fb13e2 100644
> --- a/scripts/Makefile.extrawarn
> +++ b/scripts/Makefile.extrawarn
> @@ -1,14 +1,9 @@
>  # SPDX-License-Identifier: GPL-2.0
>  # ==
> -#
>  # make W=... settings
>  #
> -# W=1 - warnings that may be relevant and does not occur too often
> -# W=2 - warnings that occur quite often but may still be relevant
> -# W=3 - the more obscure warnings, can most likely be ignored
> -#
> -# $(call cc-option, -W...) handles gcc -W.. options which
> -# are not supported by all versions of the compiler
> +# There are three warning groups enabled by W=1, W=2, W=3.
> +# They are independent, and can be combined like W=12 or W=123.
>  # ==
>
>  KBUILD_CFLAGS += $(call cc-disable-warning, packed-not-aligned)
> @@ -17,58 +12,69 @@ ifeq ("$(origin W)", "command line")
>export KBUILD_ENABLE_EXTRA_GCC_CHECKS := $(W)
>  endif
>
> -ifdef KBUILD_ENABLE_EXTRA_GCC_CHECKS
> -warning-  := $(empty)
> +#
> +# W=1 - warnings which may be relevant and do not occur too often
> +#
> +ifneq ($(findstring 1, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)),)
>
> -warning-1 := -Wextra -Wunused -Wno-unused-parameter
> -warning-1 += -Wmissing-declarations
> -warning-1 += -Wmissing-format-attribute
> -warning-1 += -Wmissing-prototypes
> -warning-1 += -Wold-style-definition
> -warning-1 += -Wmissing-include-dirs
> -warning-1 += $(call cc-option, -Wunused-but-set-variable)
> -warning-1 += $(call cc-option, -Wunused-const-variable)
> -warning-1 += $(call cc-option, -Wpacked-not-aligned)
> -warning-1 += $(call cc-option, -Wstringop-truncation)
> +KBUILD_CFLAGS += -Wextra -Wunused -Wno-unused-parameter
> +KBUILD_CFLAGS += -Wmissing-declarations
> +KBUILD_CFLAGS += -Wmissing-format-attribute
> +KBUILD_CFLAGS += -Wmissing-prototypes
> +KBUILD_CFLAGS += -Wold-style-definition
> +KBUILD_CFLAGS += -Wmissing-include-dirs
> +KBUILD_CFLAGS += $(call cc-option, -Wunused-but-set-variable)
> +KBUILD_CFLAGS += $(call cc-option, -Wunused-const-variable)
> +KBUILD_CFLAGS += $(call cc-option, -Wpacked-not-aligned)
> +KBUILD_CFLAGS += $(call cc-option, -Wstringop-truncation)
>  # The following turn off the 

Re: [PATCH] lz4: make LZ4HC_setExternalDict as non-static

[Masahiro Yamada]

On Sat, Sep 7, 2019 at 3:43 AM Arnd Bergmann  wrote:
>
> On Fri, Sep 6, 2019 at 6:21 PM Denis Efremov  wrote:
> >
> > Hi,
> >
> > > kbuild warns for exported static symbols. This one seems to
> > > be meant as an external API but does not have any in-kernel
> > > users:
> > >
> > > WARNING: "LZ4HC_setExternalDict" [vmlinux] is a static EXPORT_SYMBOL
> > >
> > > I suppose the function should not just get removed since it would
> > > be nice to stay close to the upstream version of lz4hc, so just
> > > make it global.

When you make the symbol global, you need to
provide a prototype declaration in a global header.
(include/linux/lz4.h in this case)

Otherwise, nobody cannot call this function anyway.

I prefer Denis's fix-up.




> > I'm not sure what is better here. But just in case, I sent a different
> > patch that removes EXPORT_SYMBOL from this function some time ago:
> > https://lkml.org/lkml/2019/7/8/842
> >
> > I checked first that this functions is indeed static in the original lib[1]
> > and this symbol is not used in kernel.
> >
> > [1] https://github.com/lz4/lz4/blob/dev/lib/lz4hc.c#L1054
>
> Ah, good. Your patch is the better fix then.
>
>   Arnd



-- 
Best Regards
Masahiro Yamada

Re: [PATCH RFC] driver core: ensure a device has valid node id in device_add()

[Yunsheng Lin]

On 2019/9/6 22:00, Greg KH wrote:
> On Fri, Sep 06, 2019 at 04:21:47PM +0800, Yunsheng Lin wrote:
>> On 2019/9/6 14:52, Greg KH wrote:
>>> On Fri, Sep 06, 2019 at 02:41:36PM +0800, Yunsheng Lin wrote:
 On 2019/9/5 15:33, Greg KH wrote:
> On Thu, Sep 05, 2019 at 02:48:24PM +0800, Yunsheng Lin wrote:
>> On 2019/9/5 13:57, Greg KH wrote:
>>> On Thu, Sep 05, 2019 at 09:33:50AM +0800, Yunsheng Lin wrote:
 Currently a device does not belong to any of the numa nodes
 (dev->numa_node is NUMA_NO_NODE) when the FW does not provide
 the node id and the device has not no parent device.

 According to discussion in [1]:
 Even if a device's numa node is not set by fw, the device
 really does belong to a node.

 This patch sets the device node to node 0 in device_add() if
 the fw has not specified the node id and it either has no
 parent device, or the parent device also does not have a valid
 node id.

 There may be explicit handling out there relying on NUMA_NO_NODE,
 like in nvme_probe().

 [1] https://lkml.org/lkml/2019/9/2/466

 Signed-off-by: Yunsheng Lin 
 ---
  drivers/base/core.c  | 17 ++---
  include/linux/numa.h |  2 ++
  2 files changed, 16 insertions(+), 3 deletions(-)

 diff --git a/drivers/base/core.c b/drivers/base/core.c
 index 1669d41..466b8ff 100644
 --- a/drivers/base/core.c
 +++ b/drivers/base/core.c
 @@ -2107,9 +2107,20 @@ int device_add(struct device *dev)
if (kobj)
dev->kobj.parent = kobj;
  
 -  /* use parent numa_node */
 -  if (parent && (dev_to_node(dev) == NUMA_NO_NODE))
 -  set_dev_node(dev, dev_to_node(parent));
 +  /* use parent numa_node or default node 0 */
 +  if (!numa_node_valid(dev_to_node(dev))) {
 +  int nid = parent ? dev_to_node(parent) : NUMA_NO_NODE;
>>>
>>> Can you expand this to be a "real" if statement please?
>>
>> Sure. May I ask why "? :" is not appropriate here?
>
> Because it is a pain to read, just spell it out and make it obvious what
> is happening.  You write code for developers first, and the compiler
> second, and in this case, either way is identical to the compiler.
>
 +
 +  if (numa_node_valid(nid)) {
 +  set_dev_node(dev, nid);
 +  } else {
 +  if (nr_node_ids > 1U)
 +  pr_err("device: '%s': has invalid NUMA 
 node(%d)\n",
 + dev_name(dev), dev_to_node(dev));
>>>
>>> dev_err() will show you the exact device properly, instead of having to
>>> rely on dev_name().
>>>
>>> And what is a user to do if this message happens?  How do they fix this?
>>> If they can not, what good is this error message?
>>
>> If user know about their system's topology well enough and node 0
>> is not the nearest node to the device, maybe user can readjust that by
>> writing the nearest node to /sys/class/pci_bus//device/numa_node,
>> if not, then maybe user need to contact the vendor for info or updates.
>>
>> Maybe print error message as below:
>>
>> dev_err(dev, FW_BUG "has invalid NUMA node(%d). Readjust it by writing 
>> to sysfs numa_node or contact your vendor for updates.\n",
>>  dev_to_node(dev));
>
> FW_BUG?
>
> Anyway, if you make this change, how many machines start reporting this
> error? 

 Any machines with more than one numa node will start reporting this error.

 1) many virtual deivces maybe do not set the node id before calling
device_register(), such as vfio, tun, etc.

 2) struct cpu has a dev, but does not set the dev' node according to
cpu_to_node().

 3) Many platform Device also do not have a node id provided by FW.
>>>
>>> Then this patch is not ok, as you are flooding the kernel log saying the
>>> system is "broken" when this is just what it always has been like.  How
>>> is anyone going to "fix" things?
>>
>> cpu->node_id does not seem to be used, maybe we can fix the cpu device:
>>
>> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
>> index cc37511d..ad0a841 100644
>> --- a/drivers/base/cpu.c
>> +++ b/drivers/base/cpu.c
>> @@ -41,7 +41,7 @@ static void change_cpu_under_node(struct cpu *cpu,
>> int cpuid = cpu->dev.id;
>> unregister_cpu_under_node(cpuid, from_nid);
>> register_cpu_under_node(cpuid, to_nid);
>> -   cpu->node_id = to_nid;
>> +   set_dev_node(>dev, to_nid);
>>  }
>>
>>  static int cpu_subsys_online(struct device *dev)
>> @@ -367,7 +367,7 @@ int 

[PATCH] samples: watch_queue: add HEADERS_INSTALL dependency

[Masahiro Yamada]

samples/watch_queue/Makefile specifies the header search path
-I$(objtree)/usr/include, which is probaby needed to include
 etc.

To make it work properly, add "depends on HEADERS_INSTALL" so that
headers are installed into $(objtree)/usr/include before building
this sample.

Fixes: 7141642ed120 ("Add sample notification program")
Reported-by: Arnd Bergmann 
Signed-off-by: Masahiro Yamada 
---

Arnd reported a build error:
https://lkml.org/lkml/2019/9/6/665

Missing "depends on HEADERS_INSTALL" is the only reason
I have in my mind.

If it still fails to build, I do not know why.


 samples/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/samples/Kconfig b/samples/Kconfig
index 2c3e07addd38..d0761f29ccb0 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -171,6 +171,7 @@ config SAMPLE_VFS
 
 config SAMPLE_WATCH_QUEUE
bool "Build example /dev/watch_queue notification consumer"
+   depends on HEADERS_INSTALL
help
  Build example userspace program to use the new mount_notify(),
  sb_notify() syscalls and the KEYCTL_WATCH_KEY keyctl() function.
-- 
2.17.1

Re: [PATCH v2 0/6] Rework REFCOUNT_FULL using atomic_fetch_* operations

[Hanjun Guo]

On 2019/9/6 21:43, Will Deacon wrote:
> On Wed, Aug 28, 2019 at 02:03:37PM -0700, Kees Cook wrote:
>> On Wed, Aug 28, 2019 at 03:14:40PM +0100, Will Deacon wrote:
>>> On Wed, Aug 28, 2019 at 09:30:52AM +0200, Peter Zijlstra wrote:
 On Tue, Aug 27, 2019 at 05:31:58PM +0100, Will Deacon wrote:
> Will Deacon (6):
>   lib/refcount: Define constants for saturation and max refcount values
>   lib/refcount: Ensure integer operands are treated as signed
>   lib/refcount: Remove unused refcount_*_checked() variants
>   lib/refcount: Move bulk of REFCOUNT_FULL implementation into header
>   lib/refcount: Improve performance of generic REFCOUNT_FULL code
>   lib/refcount: Consolidate REFCOUNT_{MAX,SATURATED} definitions
>> BTW, can you repeat the timing details into the "Improve performance of
>> generic REFCOUNT_FULL code" patch?
> Of course.
> 
 So I'm not a fan; I itch at the whole racy nature of this thing and I
 find the code less than obvious. Yet, I have to agree it is exceedingly
 unlikely the race will ever actually happen, I just don't want to be the
 one having to debug it.
>>> FWIW, I think much the same about the version under arch/x86 ;)
>>>
 I've not looked at the implementation much; does it do all the same
 checks the FULL one does? The x86-asm one misses a few iirc, so if this
 is similarly fast but has all the checks, it is in fact better.
>>> Yes, it passes all of the REFCOUNT_* tests in lkdtm [1] so I agree that
>>> it's an improvement over the asm version.
>>>
 Can't we make this a default !FULL implementation?
>>> My concern with doing that is I think it would make the FULL implementation
>>> entirely pointless. I can't see anybody using it, and it would only exist
>>> as an academic exercise in handling the theoretical races. That's a change
>>> from the current situation where it genuinely handles cases which the
>>> x86-specific code does not and, judging by the Kconfig text, that's the
>>> only reason for its existence.
>> Looking at timing details, the new implementation is close enough to the
>> x86 asm version that I would be fine to drop the x86-specific case
>> entirely as long as we could drop "FULL" entirely too -- we'd have _one_
>> refcount_t implementation: it would be both complete and fast.
> That works for me; I'll spin a new version of this series so you can see
> what it looks like.

I will wait for the new version then do the performance test on ARM64 server.

Thanks
Hanjun

Re: [PATCH v3 1/2] dt-bindings: PCI: intel: Add YAML schemas for the PCIe RC controller

[Ivan Gorinov]

On Fri, Sep 06, 2019 at 08:48:15PM +0300, Andy Shevchenko wrote:
> On Fri, Sep 06, 2019 at 07:17:11PM +0200, Martin Blumenstingl wrote:
> > On Fri, Sep 6, 2019 at 5:22 AM Chuan Hua, Lei
> >  wrote:
> 
> > >  type_index = fwspec->param[1]; // index.
> > >  if (type_index >= ARRAY_SIZE(of_ioapic_type))
> > >  return -EINVAL;
> > >
> > > I would not see this definition is user-friendly. But it is how x86
> > > handles at the moment.
> > thank you for explaining this - I had no idea x86 is different from
> > all other platforms I know
> > the only upstream x86 .dts I could find
> > (arch/x86/platform/ce4100/falconfalls.dts) also uses the magic x86
> > numbers
> > so I'm fine with this until someone else knows a better solution
> 
> Ivan, Cc'ed, had done few amendments to x86 DT support. Perhaps he may add
> something to the discussion.

I just fixed broken interrupt support in x86-specific DT implementation.

In CE4100, PCI devices are directly connected to I/O APIC input lines.
Conventional PCI devices other than bridges don't need to be described in
Device Tree or if they use standard PCI routing.
Mapping INTA .. INTD pins to inputs of the bridge's interrupt parent depends
on device number on the bus. In Device Tree, this mapping is described by
"interrupt-map-mask" and "interrupt-map" properties of the bridge device node.

Possible interrupt types described by Open Firmware Recomended Practice:

0 - Rising Edge
1 - Level triggered, active low

Re: [PATCH bpf-next 8/8] samples: bpf: Makefile: base progs build on Makefile.progs

[Ivan Khoronzhuk]

On Fri, Sep 06, 2019 at 04:34:31PM -0700, Alexei Starovoitov wrote:

On Thu, Sep 05, 2019 at 12:22:12AM +0300, Ivan Khoronzhuk wrote:

+
+If need to use environment of target board, the SYSROOT also can be set,
+pointing on FS of target board:
+
+make samples/bpf/ LLC=~/git/llvm/build/bin/llc \
+ CLANG=~/git/llvm/build/bin/clang \
+ SYSROOT=~/some_sdk/linux-devkit/sysroots/aarch64-linux-gnu


Patches 7 and 8 look quite heavy. I don't have a way to test them
which makes me a bit uneasy to accept them as-is.
Would be great if somebody could give Tested-by.


I can try to split patch 8 in v2, but not significantly.

--
Regards,
Ivan Khoronzhuk

Re: [PATCH] kunit: Fix '--build_dir' option

[Brendan Higgins]

On Fri, Sep 6, 2019 at 9:12 AM SeongJae Park  wrote:
>
> Running kunit with '--build_dir' option gives following error message:
>
> ```
> $ ./tools/testing/kunit/kunit.py run --build_dir ../linux.out.kunit/
> [00:57:24] Building KUnit Kernel ...
> [00:57:29] Starting KUnit Kernel ...
> Traceback (most recent call last):
>   File "./tools/testing/kunit/kunit.py", line 136, in 
> main(sys.argv[1:])
>   File "./tools/testing/kunit/kunit.py", line 129, in main
> result = run_tests(linux, request)
>   File "./tools/testing/kunit/kunit.py", line 68, in run_tests
> test_result = kunit_parser.parse_run_tests(kunit_output)
>   File "/home/sjpark/linux/tools/testing/kunit/kunit_parser.py", line
> 283, in parse_run_tests
> test_result =
> parse_test_result(list(isolate_kunit_output(kernel_output)))
>   File "/home/sjpark/linux/tools/testing/kunit/kunit_parser.py", line
> 54, in isolate_kunit_output
> for line in kernel_output:
>   File "/home/sjpark/linux/tools/testing/kunit/kunit_kernel.py", line
> 145, in run_kernel
> process = self._ops.linux_bin(args, timeout, build_dir)
>   File "/home/sjpark/linux/tools/testing/kunit/kunit_kernel.py", line
> 69, in linux_bin
> stderr=subprocess.PIPE)
>   File "/usr/lib/python3.5/subprocess.py", line 947, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: './linux'
> ```
>
> This error occurs because the '--build_dir' option value is not passed
> to the 'run_kernel()' function.  Consequently, the function assumes
> the kernel image that built for the tests, which is under the
> '--build_dir' directory, is in kernel source directory and finally raises
> the 'FileNotFoundError'.
>
> This commit fixes the problem by properly passing the '--build_dir'
> option value to the 'run_kernel()'.
>
> Signed-off-by: SeongJae Park 

Reviewed-by: Brendan Higgins 
Tested-by: Brendan Higgins 

Thanks!

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

[Nick Desaulniers]

On Fri, Sep 6, 2019 at 5:14 PM Segher Boessenkool
 wrote:
>
> On Fri, Sep 06, 2019 at 04:42:58PM -0700, Nick Desaulniers via gcc-patches 
> wrote:
> > Just to prove my point about version checks being brittle, it looks
> > like Rasmus' version check isn't even right.  GCC supported `asm
> > inline` back in the 8.3 release, not 9.1 as in this patch:
>
> Yes, I backported it so that it is available in 7.5, 8.3, and 9.1, so
> that more users will have this available sooner.  (7.5 has not been
> released yet, but asm inline has been supported in GCC 7 since Jan 2
> this year).

Ah, ok that makes sense.

How would you even write a version check for that?

Which looks better?

#if __GNU_MAJOR__ > 9 || __GNU_MAJOR__ == 8 && __GNU_MINOR__ >= 3 ||
__GNU_MAJOR__ == 7 && __GNU_MINOR__ >= 5 || __CLANG_MAJOR__ == 42
// make use of `asm inline`
#endif

or

#ifdef __CC_HAS_ASM_INLINE__
// make use of `asm inline`
#endif

>
> > Or was it "broken" until 9.1?  Lord knows, as `asm inline` wasn't in
> > any release notes or bug reports I can find:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01143.html
>
> It never was accepted, and I dropped the ball.

Ah, ok, that's fine, so documentation was at least written.  Tracking
when and where patches land (or don't) is difficult when patch files
are emailed around.  I try to keep track of when and where our kernel
patches land, but I frequently drop the ball there.

> > Segher, next time there's discussion about new C extensions for the
> > kernel, can you please include me in the discussions?
>
> You can lurk on gcc-patches@ and/or gcc@?

Please "interrupt" me when you're aware of such discussions, rather
than me "polling" a mailing list.  (I will buy you a tasty beverage of
your preference).  I'm already subscribed to more mailing lists than I
have time to read.

> But I'll try to remember, sure.
> Not that I am involved in all such discussions myself, mind.

But you _did_ implement `asm inline`. ;)
-- 
Thanks,
~Nick Desaulniers

[PATCH] gpio: fix build failure: gpiochip_[un]lock*() static/non-static

[John Hubbard]

While building with !CONFIG_GPIOLIB, I experienced a build failure,
because driver.h in that configuration supplies both a static and
a non-static version of these routines:

gpiochip_lock_as_irq()
gpiochip_unlock_as_irq()

Fix this by moving the non-static routines under the scope of
CONFIG_GPIOLIB.

Fixes: commit c7663fa2a663 ("gpio: Move gpiochip_lock/unlock_as_irq to 
gpio/driver.h")
Cc: YueHaibing 
Cc: Linus Walleij 
Signed-off-by: John Hubbard 
---

Hi,

This is for today's linux-next.

More background:

It *looks* like the original commit did correctly put the non-static
versions of these routines in CONFIG_GPIOLIB, and the static versions
inside !CONFIG_GPIOLIB, but my git history foo is not strong enough
to figure out how we got here, so I'm not sure if the "Fixes:" tag
really refers to the guilty commit.

thanks,
John Hubbard
NVIDIA

 include/linux/gpio/driver.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index b74a3bee85e5..39be896aad38 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -702,13 +702,11 @@ void gpiochip_free_own_desc(struct gpio_desc *desc);
 void devprop_gpiochip_set_names(struct gpio_chip *chip,
const struct fwnode_handle *fwnode);
 
-/* lock/unlock as IRQ */
-int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
-void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
-
 #ifdef CONFIG_GPIOLIB
 
 struct gpio_chip *gpiod_to_chip(const struct gpio_desc *desc);
+int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
+void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
 
 #else /* CONFIG_GPIOLIB */
 
-- 
2.23.0

Re: [GIT PULL] compiler-attributes for v5.3-rc8

[Linus Torvalds]

On Fri, Sep 6, 2019 at 5:45 PM Nick Desaulniers  wrote:
>
> > Yes. With the appropriate test cycle
>
> Sedat reported the issue and already tested/verified the fix.  How
> long should it sit in -next before sending a PR for inclusion to 5.3
> (as opposed to letting it ride out to 5.4)?

If the original patch was already in -next, I wouldn't worry about it,
as long as you do enough local testing that there's nothing stupid
going on.

The -next cycle is a few days, and even with an rc8 we're getting
close enough to release that I'd rather get it earlier than later.  So
I'd rather get a pull request this weekend than then have to deal with
it when traveling next week.

 Linus

Re: [GIT PULL] compiler-attributes for v5.3-rc8

[Nick Desaulniers]

On Fri, Sep 6, 2019 at 5:08 PM Linus Torvalds
 wrote:
>
> On Fri, Sep 6, 2019 at 5:07 PM Nick Desaulniers  
> wrote:
> >
> > So then Miguel should maybe split off a new branch, rebase to keep
> > just the relevant patch
> > (https://github.com/ojeda/linux/commit/c97e82b97f4bba00304905fe7965f923abd2d755),
> > and send a PR to you for inclusion in 5.3?
>
> Yes. With the appropriate test cycle

Sedat reported the issue and already tested/verified the fix.  How
long should it sit in -next before sending a PR for inclusion to 5.3
(as opposed to letting it ride out to 5.4)?

> , particularly obviously clang
> (which I don't test in my own minor tests).

It's the devil's compiler; wouldn't recommend.

In all seriousness, I'm missing giving an update at LPC this year
(have a much more important meeting:
https://ironmaiden.com/tours/legacy-of-the-beast-tour-2019-2019/usa-oakland-ca-oracle-arena-2019-09-10),
but I'm always happy to answer questions related to it or take a look
at bug reports.  Behan Webster is giving a talk about it at LPC
though!  Check it out if you're at LPC.
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH] kunit: add PRINTK dependency

[Brendan Higgins]

On Fri, Sep 6, 2019 at 9:08 AM Shuah Khan  wrote:
>
> On 9/6/19 10:02 AM, Arnd Bergmann wrote:
> > On Fri, Sep 6, 2019 at 5:39 PM Shuah Khan  wrote:
> >
> >>>config KUNIT
> >>>bool "Enable support for unit tests (KUnit)"
> >>> + depends on PRINTK
> >>>help
> >>>  Enables support for kernel unit tests (KUnit), a lightweight unit
> >>>  testing and mocking framework for the Linux kernel. These tests 
> >>> are
> >>>
> >>
> >> Hi Arnd,
> >>
> >> This is found and fixed already. I am just about to apply Berndan's
> >> patch that fixes this dependency. All of this vprintk_emit() stuff
> >> is redone.
> >
> > Ok, perfect. Unfortunately I only started testing the coming
> > linux-next release after Stephen went on his break, so
> > I'm missing some updates.
> >
>
> No worries. I am pushing it now - should be there in 5-10 mins.
>
> Please use linuxk-kselftest next.
>
> Let me know if you see any issues. Thanks for testing it.

Hi Arnd, Shuah accepted my version of the fix earlier today.
Nevertheless, I really appreciate you looking into this. Sorry for
wasting your time.

Please let me know if you run into any additional issues.

Thanks!

Re: [PATCH] x86/microcode: Add an option to reload microcode even if revision is unchanged

[Raj, Ashok]

On Fri, Sep 06, 2019 at 11:16:00PM +0200, Thomas Gleixner wrote:
> 
> So if we want to do late microcode loading in a sane way then there are
> only a few options and none of them exist today:
> 
>  1) Micro-code contains a description of CPUID bits which are going to be
> exposed after the load. Then the kernel can sanity check whether this
> changes anything relevant or not. If there is a relevant change it can
> reject the load and tell the admin that a reboot is required.

This is pretty much what we had in mind when we suggested to the uCode teams.

Just a process of providing a meta data file to accompany every uCode release.

IMO new cpuid bits are probably less harmful than old ones dissappearing.



> 
>  2) Rework CPUID feature handling so that it can reevaluate and reconfigure
> the running system safely. There are a lot of things you need for that:
> 
> A) Introduce a safe state for CPUs to reach which guarantees that none
>of the CPUs will return from that state via a code path which
>depends on previous state and might now go the other route with data
>on the stack which only fits the previous configuration.
> 
> B) Make all the cpufeature thingies run time switchable. That means
>that you need to keep quite some code around which is currently init
>only. That also means that you have to provide backout code for
>things which set up data corresponding to cpu feature bits and so
>forth.
> 
> So #2 might be finished in about 20 years from now with the result that
> some of the code pathes might simply still have a

Maybe we can catch the kernel side in 20 years.. user space would still be 
busted, or have a fault way to control new cpuid much like how we do for
VM's. 

> 
>  if (cpufeature_changed())
>  panic();
> 
> because there are things which you cannot back out. So the only sane
> solution is to panic. Which is not a solution as it would be much more sane
> to prevent late loading upfront and force people to reboot proper.
> 
> Now #1 is actually a sensible and feasible solution which can be pulled off
> in a reasonably short time frame, avoids all the bound to be ugly and
> failure laden attempts of fixing late loading completely and provides a
> usable and safe solution for joe user, jack admin and the super experts at
> big-cloud corporate.
> 
> That is not requiring any new format of microcode payload, as this can be
> nicely done as a metadata package which comes with the microcode
> payload. So you get the following backwards compatible states:
> 
>   Kernel  metadata  result
> 
>   old   don't care  refuse late load
> 
>   new   No  refuse late load
> 
>   new   Yes decide based on metadata
> 
> Thoughts?

This is 100% in line with what we proposed... 

Cheers,
Ashok

Re: [PATCH bpf-next 2/8] samples: bpf: Makefile: remove target for native build

[Ivan Khoronzhuk]

On Fri, Sep 06, 2019 at 05:04:08PM -0700, Alexei Starovoitov wrote:

On Fri, Sep 6, 2019 at 4:52 PM Ivan Khoronzhuk
 wrote:


On Fri, Sep 06, 2019 at 04:31:39PM -0700, Alexei Starovoitov wrote:
>On Thu, Sep 05, 2019 at 12:22:06AM +0300, Ivan Khoronzhuk wrote:
>> No need to set --target for native build, at least for arm, the
>> default target will be used anyway. In case of arm, for at least
>> clang 5 - 10 it causes error like:
>>
>> clang: warning: unknown platform, assuming -mfloat-abi=soft
>> LLVM ERROR: Unsupported calling convention
>> make[2]: *** [/home/root/snapshot/samples/bpf/Makefile:299:
>> /home/root/snapshot/samples/bpf/sockex1_kern.o] Error 1
>>
>> Only set to real triple helps: --target=arm-linux-gnueabihf
>> or just drop the target key to use default one. Decision to just
>> drop it and thus default target will be used (wich is native),
>> looks better.
>>
>> Signed-off-by: Ivan Khoronzhuk 
>> ---
>>  samples/bpf/Makefile | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index 61b7394b811e..a2953357927e 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -197,8 +197,6 @@ BTF_PAHOLE ?= pahole
>>  ifdef CROSS_COMPILE
>>  HOSTCC = $(CROSS_COMPILE)gcc
>>  CLANG_ARCH_ARGS = --target=$(notdir $(CROSS_COMPILE:%-=%))
>> -else
>> -CLANG_ARCH_ARGS = -target $(ARCH)
>>  endif
>
>I don't follow here.
>Didn't you introduce this bug in patch 1 and now fixing it in patch 2?
>

It looks like but that's not true.
Previous patch adds target only for cross compiling,
before the patch the target was used for both, cross compiling and w/o cc.

This patch removes target only for native build (it's not cross compiling).

By fact, it's two separate significant changes.


How so?
before first patch CLANG_ARCH_ARGS is only used under CROSS_COMPILE.
After the first patch CLANG_ARCH_ARGS is now suddenly defined w/o CROSS_COMPILE
and second patch brings it to the state before first patch.


Oh sorry ), messed with my local exp with target bpf, after rebase, even forgot
that's mine. Will drop it, with removing "else" for previous patch.

--
Regards,
Ivan Khoronzhuk

Re: [GIT PULL] SCSI fixes for 5.3-rc7

[James Smart]

On 9/6/2019 4:18 PM, Linus Torvalds wrote:

On Fri, Sep 6, 2019 at 1:39 PM James Bottomley
 wrote:


diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 8d8c495b5b60..d65558619ab0 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -5715,7 +5715,7 @@ LPFC_ATTR_RW(nvme_embed_cmd, 1, 0, 2,
   *  0= Set nr_hw_queues by the number of CPUs or HW queues.
   *  1,128 = Manually specify the maximum nr_hw_queue value to be set,
   *
- * Value range is [0,128]. Default value is 8.
+ * Value range is [0,256]. Default value is 8.
   */

Shouldn't that "1,128 = Manually specify.." line also have been updated?

Not that I really care, and I'll pul this, but..

   Linus


Yes - thanks

-- james

Re: [GIT PULL] compiler-attributes for v5.3-rc8

[Linus Torvalds]

On Fri, Sep 6, 2019 at 5:07 PM Nick Desaulniers  wrote:
>
> So then Miguel should maybe split off a new branch, rebase to keep
> just the relevant patch
> (https://github.com/ojeda/linux/commit/c97e82b97f4bba00304905fe7965f923abd2d755),
> and send a PR to you for inclusion in 5.3?

Yes. With the appropriate test cycle, particularly obviously clang
(which I don't test in my own minor tests).

Linus

Re: [GIT PULL] compiler-attributes for v5.3-rc8

[Nick Desaulniers]

On Fri, Sep 6, 2019 at 4:11 PM Linus Torvalds
 wrote:
>
> On Fri, Sep 6, 2019 at 3:47 PM Nick Desaulniers  
> wrote:
> >
> > Sedat reported 
> > (https://github.com/ClangBuiltLinux/linux/issues/619#issuecomment-520042577,
> > https://github.com/ClangBuiltLinux/linux/issues/619#issuecomment-520065525)
> > that only the bottom two hunks of that patch
> > (https://github.com/ojeda/linux/commit/c97e82b97f4bba00304905fe7965f923abd2d755)
>
> [ missing "matters" or something here? ]

(Yes; I must have pasted the link over it, or I'm having an episode)

>
> If fixing two of the __section() uses in that tracing header file is
> needed, then just fix all four there. I'm ok with that.

So then Miguel should maybe split off a new branch, rebase to keep
just the relevant patch
(https://github.com/ojeda/linux/commit/c97e82b97f4bba00304905fe7965f923abd2d755),
and send a PR to you for inclusion in 5.3?
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH bpf-next 2/8] samples: bpf: Makefile: remove target for native build

[Alexei Starovoitov]

On Fri, Sep 6, 2019 at 4:52 PM Ivan Khoronzhuk
 wrote:
>
> On Fri, Sep 06, 2019 at 04:31:39PM -0700, Alexei Starovoitov wrote:
> >On Thu, Sep 05, 2019 at 12:22:06AM +0300, Ivan Khoronzhuk wrote:
> >> No need to set --target for native build, at least for arm, the
> >> default target will be used anyway. In case of arm, for at least
> >> clang 5 - 10 it causes error like:
> >>
> >> clang: warning: unknown platform, assuming -mfloat-abi=soft
> >> LLVM ERROR: Unsupported calling convention
> >> make[2]: *** [/home/root/snapshot/samples/bpf/Makefile:299:
> >> /home/root/snapshot/samples/bpf/sockex1_kern.o] Error 1
> >>
> >> Only set to real triple helps: --target=arm-linux-gnueabihf
> >> or just drop the target key to use default one. Decision to just
> >> drop it and thus default target will be used (wich is native),
> >> looks better.
> >>
> >> Signed-off-by: Ivan Khoronzhuk 
> >> ---
> >>  samples/bpf/Makefile | 2 --
> >>  1 file changed, 2 deletions(-)
> >>
> >> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> >> index 61b7394b811e..a2953357927e 100644
> >> --- a/samples/bpf/Makefile
> >> +++ b/samples/bpf/Makefile
> >> @@ -197,8 +197,6 @@ BTF_PAHOLE ?= pahole
> >>  ifdef CROSS_COMPILE
> >>  HOSTCC = $(CROSS_COMPILE)gcc
> >>  CLANG_ARCH_ARGS = --target=$(notdir $(CROSS_COMPILE:%-=%))
> >> -else
> >> -CLANG_ARCH_ARGS = -target $(ARCH)
> >>  endif
> >
> >I don't follow here.
> >Didn't you introduce this bug in patch 1 and now fixing it in patch 2?
> >
>
> It looks like but that's not true.
> Previous patch adds target only for cross compiling,
> before the patch the target was used for both, cross compiling and w/o cc.
>
> This patch removes target only for native build (it's not cross compiling).
>
> By fact, it's two separate significant changes.

How so?
before first patch CLANG_ARCH_ARGS is only used under CROSS_COMPILE.
After the first patch CLANG_ARCH_ARGS is now suddenly defined w/o CROSS_COMPILE
and second patch brings it to the state before first patch.

Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism

[Ming Lei]

On Fri, Sep 06, 2019 at 11:30:57AM -0700, Sagi Grimberg wrote:
> 
> > 
> > Ok, so the real problem is per-cpu bounded tasks.
> > 
> > I share Thomas opinion about a NAPI like approach.
> 
> We already have that, its irq_poll, but it seems that for this
> use-case, we get lower performance for some reason. I'm not
> entirely sure why that is, maybe its because we need to mask interrupts
> because we don't have an "arm" register in nvme like network devices
> have?

Long observed that IOPS drops much too by switching to threaded irq. If
softirqd is waken up for handing softirq, the performance shouldn't
be better than threaded irq. Especially, Long found that context
switch is increased a lot after applying your irq poll patch.

http://lists.infradead.org/pipermail/linux-nvme/2019-August/026788.html

Thanks,
Ming

Re: [GIT PULL] libnvdimm fix for v5.3-rc8

[pr-tracker-bot]

The pull request you sent on Fri, 6 Sep 2019 13:00:00 -0700:

> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm 
> tags/libnvdimm-fix-5.3-rc8

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7641033e17efe472c0e2fd6da00f1b75dc6788f3

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [git pull] Input updates for v5.3-rc7

[pr-tracker-bot]

The pull request you sent on Fri, 6 Sep 2019 15:48:27 -0700:

> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9772152b4b3cd32a1aadf75e3d1a16a072d3e4a5

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] SCSI fixes for 5.3-rc7

[pr-tracker-bot]

The pull request you sent on Fri, 06 Sep 2019 16:39:12 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1e3778cb223e861808ae0daccf353536e7573eed

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [RFC][PATCH 1/1] Carry ima measurement log for arm64 via kexec_file_load

[prsriva]

On 8/30/19 5:11 PM, Thiago Jung Bauermann wrote:

Hello Prakhar,

Answering this part from the cover letter:


The code is in most part same as powerpc, i want to get feedback as to
how/correct way to refactor the code so that cross architecture
partial helpers can be put in a common place.


I started refactoring code to bring helpers under drivers/of, but

i soon reliazed the current implementation can be changed a bit

so that some of the additional functions can be sourced from

existing fdt_*/of_* functions since the fdt_ima was seeming to be

an overkill. I have done so in the V1 patch and also addressed

comments you have.

Hopefully its(v1) is a cleaner approach.

- Thanks for the review, and guidance.

Thanks,

Prakhar Srivastava


That's a great idea. If it could go to drivers/of/ as Stephen Boyd
mentioned in the other email that would be great.

More comments below.
-Addressed those in the v1 patch
Prakhar Srivastava  writes:

Re: [PATCH bpf-next 2/8] samples: bpf: Makefile: remove target for native build

[Ivan Khoronzhuk]

On Fri, Sep 06, 2019 at 04:31:39PM -0700, Alexei Starovoitov wrote:

On Thu, Sep 05, 2019 at 12:22:06AM +0300, Ivan Khoronzhuk wrote:

No need to set --target for native build, at least for arm, the
default target will be used anyway. In case of arm, for at least
clang 5 - 10 it causes error like:

clang: warning: unknown platform, assuming -mfloat-abi=soft
LLVM ERROR: Unsupported calling convention
make[2]: *** [/home/root/snapshot/samples/bpf/Makefile:299:
/home/root/snapshot/samples/bpf/sockex1_kern.o] Error 1

Only set to real triple helps: --target=arm-linux-gnueabihf
or just drop the target key to use default one. Decision to just
drop it and thus default target will be used (wich is native),
looks better.

Signed-off-by: Ivan Khoronzhuk 
---
 samples/bpf/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 61b7394b811e..a2953357927e 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -197,8 +197,6 @@ BTF_PAHOLE ?= pahole
 ifdef CROSS_COMPILE
 HOSTCC = $(CROSS_COMPILE)gcc
 CLANG_ARCH_ARGS = --target=$(notdir $(CROSS_COMPILE:%-=%))
-else
-CLANG_ARCH_ARGS = -target $(ARCH)
 endif


I don't follow here.
Didn't you introduce this bug in patch 1 and now fixing it in patch 2?



It looks like but that's not true.
Previous patch adds target only for cross compiling,
before the patch the target was used for both, cross compiling and w/o cc.

This patch removes target only for native build (it's not cross compiling).

By fact, it's two separate significant changes.

--
Regards,
Ivan Khoronzhuk

[RFC][PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load

[Prakhar Srivastava]

During kexec_file_load, carrying forward the ima measurement log allows
a verifying party to get the entire runtime event log since the last
full reboot since that is when PCRs were last reset.

Signed-off-by: Prakhar Srivastava 
---
 arch/arm64/Kconfig |   7 +
 arch/arm64/include/asm/ima.h   |  29 
 arch/arm64/include/asm/kexec.h |   5 +
 arch/arm64/kernel/Makefile |   3 +-
 arch/arm64/kernel/ima_kexec.c  | 213 +
 arch/arm64/kernel/machine_kexec_file.c |   6 +
 6 files changed, 262 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/include/asm/ima.h
 create mode 100644 arch/arm64/kernel/ima_kexec.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3adcec05b1f6..f39b12dbf9e8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -976,6 +976,13 @@ config KEXEC_VERIFY_SIG
  verification for the corresponding kernel image type being
  loaded in order for this to work.
 
+config HAVE_IMA_KEXEC
+   bool "Carry over IMA measurement log during kexec_file_load() syscall"
+   depends on KEXEC_FILE
+   help
+ Select this option to carry over IMA measurement log during
+ kexec_file_load.
+
 config KEXEC_IMAGE_VERIFY_SIG
bool "Enable Image signature verification support"
default y
diff --git a/arch/arm64/include/asm/ima.h b/arch/arm64/include/asm/ima.h
new file mode 100644
index ..e23cee84729f
--- /dev/null
+++ b/arch/arm64/include/asm/ima.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ARM64_IMA_H
+#define _ASM_ARM64_IMA_H
+
+struct kimage;
+
+int ima_get_kexec_buffer(void **addr, size_t *size);
+int ima_free_kexec_buffer(void);
+
+#ifdef CONFIG_IMA
+void remove_ima_buffer(void *fdt, int chosen_node);
+#else
+static inline void remove_ima_buffer(void *fdt, int chosen_node) {}
+#endif
+
+#ifdef CONFIG_IMA_KEXEC
+int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
+ size_t size);
+
+int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node);
+#else
+static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
+  int chosen_node)
+{
+   remove_ima_buffer(fdt, chosen_node);
+   return 0;
+}
+#endif /* CONFIG_IMA_KEXEC */
+#endif /* _ASM_ARM64_IMA_H */
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 12a561a54128..e8d2412066e7 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -96,6 +96,11 @@ static inline void crash_post_resume(void) {}
 struct kimage_arch {
void *dtb;
unsigned long dtb_mem;
+
+#ifdef CONFIG_IMA_KEXEC
+   phys_addr_t ima_buffer_addr;
+   size_t ima_buffer_size;
+#endif
 };
 
 extern const struct kexec_file_ops kexec_image_ops;
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 478491f07b4f..580238f2e9a7 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -55,7 +55,8 @@ obj-$(CONFIG_RANDOMIZE_BASE)  += kaslr.o
 obj-$(CONFIG_HIBERNATION)  += hibernate.o hibernate-asm.o
 obj-$(CONFIG_KEXEC_CORE)   += machine_kexec.o relocate_kernel.o
\
   cpu-reset.o
-obj-$(CONFIG_KEXEC_FILE)   += machine_kexec_file.o kexec_image.o
+obj-$(CONFIG_KEXEC_FILE)   += machine_kexec_file.o kexec_image.o   
\
+  ima_kexec.o
 obj-$(CONFIG_ARM64_RELOC_TEST) += arm64-reloc-test.o
 arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
 obj-$(CONFIG_CRASH_DUMP)   += crash_dump.o
diff --git a/arch/arm64/kernel/ima_kexec.c b/arch/arm64/kernel/ima_kexec.c
new file mode 100644
index ..b14326d541f3
--- /dev/null
+++ b/arch/arm64/kernel/ima_kexec.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Microsoft Corporation.
+ *
+ * Authors:
+ * Prakhar Srivastava 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+/**
+ * delete_fdt_mem_rsv - delete memory reservation with given address and size
+ * @fdt - pointer to the fdt.
+ * @start - start address of the memory.
+ * @size - number of cells to be deletd.
+ * 
+ * Return: 0 on success, or negative errno on error.
+ */
+int delete_fdt_mem_rsv(void *fdt, unsigned long start, unsigned long size)
+{
+   int i, ret, num_rsvs = fdt_num_mem_rsv(fdt);
+
+   for (i = 0; i < num_rsvs; i++) {
+   uint64_t rsv_start, rsv_size;
+
+   ret = fdt_get_mem_rsv(fdt, i, _start, _size);
+   if (ret) {
+   pr_err("Malformed device tree\n");
+   return -EINVAL;
+   }
+
+   if (rsv_start == start && rsv_size == size) {
+   ret = fdt_del_mem_rsv(fdt, i);
+   if (ret) {
+

[RFC][PATCH v1 0/1] Add support for arm64 to carry ima measurement log in kexec_file_load

[Prakhar Srivastava]

Add support for arm64 to carry ima measurement log
to the next kexec'ed session triggered via kexec_file_load.
- Top of Linux 5.3-rc6

Currently during kexec the kernel file signatures are/can be validated
prior to actual load, the information(PE/ima signature) is not carried
to the next session. This lead to loss of information.

Carrying forward the ima measurement log to the next kexec'ed session.
This allows a verifying party to get the entire runtime event log since
the last full reboot since that is when PCRs were last reset.

Prakhar Srivastava (1):
  Add support for arm64 to carry ima measurement log in kexec_file_load

 arch/arm64/Kconfig |   7 +
 arch/arm64/include/asm/ima.h   |  29 
 arch/arm64/include/asm/kexec.h |   5 +
 arch/arm64/kernel/Makefile |   3 +-
 arch/arm64/kernel/ima_kexec.c  | 213 +
 arch/arm64/kernel/machine_kexec_file.c |   6 +
 6 files changed, 262 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/include/asm/ima.h
 create mode 100644 arch/arm64/kernel/ima_kexec.c

-- 
2.17.1

Re: [PATCH v3 11/16] ARM: mmp: add support for MMP3 SoC

[Stephen Boyd]

Quoting Lubomir Rintel (2019-08-30 15:07:38)
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 801fa1cd03217..8bb2ac83a1fcc 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -301,6 +301,11 @@ config COMMON_CLK_STM32H7
> ---help---
>   Support for stm32h7 SoC family clocks
>  
> +config COMMON_CLK_MMP2
> +   def_bool COMMON_CLK && (MACH_MMP2_DT || MACH_MMP3_DT)

Does it need to depend on COMMON_CLK? I thought that by being part of
the menuconfig (even if it's a hidden symbol) mean that it wouldn't be
evaulated unless the COMMON_CLK define is =Y.

> +   help
> + Support for Marvell MMP2 and MMP3 SoC clocks
> +
>  config COMMON_CLK_BD718XX
> tristate "Clock driver for ROHM BD718x7 PMIC"
> depends on MFD_ROHM_BD718XX || MFD_ROHM_BD70528

Re: [PATCH 1/2] power: sysfs: Add link to wakeup class device.

[Matthias Kaehlcke]

Hi Ravi,

On Wed, Jul 24, 2019 at 10:43:54AM -0700, Ravi Chandra Sadineni wrote:
> https://patchwork.kernel.org/patch/11045069/ creates a virtual
> device

To refer to unsubmitted patches in the commit message it is
probably better to use the subject ("PM / wakeup: show wakeup
sources stats in sysfs") and add a link after '---', or say
"${subject}" [1] and put the link at the bottom of the commit message

You might want to try again now that the patch has landed :)

> under wakeup class for each wake capable device exposing all related
> sysfs attributes. But there isn't a symlink from the actual device
> node to these virtual devices. This patch creates a symlink from the
> actual device to the corresponding wakeup_source device under wakeup
> class.

> Signed-off-by: Ravi Chandra Sadineni 
> ---
>  drivers/base/power/power.h  |  2 ++
>  drivers/base/power/sysfs.c  | 25 +
>  drivers/base/power/wakeup.c |  2 ++
>  3 files changed, 29 insertions(+)
> 
> diff --git a/drivers/base/power/power.h b/drivers/base/power/power.h
> index c511def48b48..32b0f5c080a9 100644
> --- a/drivers/base/power/power.h
> +++ b/drivers/base/power/power.h
> @@ -67,6 +67,8 @@ extern void dpm_sysfs_remove(struct device *dev);
>  extern void rpm_sysfs_remove(struct device *dev);
>  extern int wakeup_sysfs_add(struct device *dev);
>  extern void wakeup_sysfs_remove(struct device *dev);
> +extern void wakeup_source_sysfs_link_add(struct device *dev);
> +extern void wakeup_source_sysfs_link_remove(struct device *dev);

the names seem a bit clunky, how about wakeup_sysfs_add/remove_link()?

>  extern int pm_qos_sysfs_add_resume_latency(struct device *dev);
>  extern void pm_qos_sysfs_remove_resume_latency(struct device *dev);
>  extern int pm_qos_sysfs_add_flags(struct device *dev);
> diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
> index d713738ce796..fbbdb7b16ac5 100644
> --- a/drivers/base/power/sysfs.c
> +++ b/drivers/base/power/sysfs.c
> @@ -95,6 +95,7 @@
>  const char power_group_name[] = "power";
>  EXPORT_SYMBOL_GPL(power_group_name);
>  
> +static const char wakeup_source_symlink_name[] = "wakeup_source";
>  static const char ctrl_auto[] = "auto";
>  static const char ctrl_on[] = "on";
>  
> @@ -679,6 +680,30 @@ int dpm_sysfs_add(struct device *dev)
>   return rc;
>  }
>  
> +void wakeup_source_sysfs_link_add(struct device *dev)
> +{
> + struct wakeup_source *ws;
> + int err;
> +
> + ws = dev->power.wakeup;
> + if (ws && ws->dev) {
> + err = sysfs_add_link_to_group(>kobj, power_group_name,
> + >dev->kobj, wakeup_source_symlink_name);
> + if (err) {
> + dev_err(dev,
> + "could not add %s symlink err %d\n",

I'd suggest

"could not add '%s' symlink: %d\n",

or

"could not add 'wakeup_source' symlink: %d\n",

the latter is easier to grep.

> + wakeup_source_symlink_name,
> + err);
> + }
> + }
> +}
> +
> +void wakeup_source_sysfs_link_remove(struct device *dev)
> +{
> + sysfs_remove_link_from_group(>kobj, power_group_name,
> + wakeup_source_symlink_name);
> +}
> +
>  int wakeup_sysfs_add(struct device *dev)
>  {
>   return sysfs_merge_group(>kobj, _wakeup_attr_group);
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index fe779fe13a7f..87dfe401b035 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -270,6 +270,7 @@ static int device_wakeup_attach(struct device *dev, 
> struct wakeup_source *ws)
>   if (dev->power.wakeirq)
>   device_wakeup_attach_irq(dev, dev->power.wakeirq);
>   spin_unlock_irq(>power.lock);
> + wakeup_source_sysfs_link_add(dev);
>   return 0;
>  }
>  
> @@ -391,6 +392,7 @@ static struct wakeup_source *device_wakeup_detach(struct 
> device *dev)
>   ws = dev->power.wakeup;
>   dev->power.wakeup = NULL;
>   spin_unlock_irq(>power.lock);
> + wakeup_source_sysfs_link_remove(dev);

you want to do this before the wakeup source is detached.

Re: [PATCH bpf-next 8/8] samples: bpf: Makefile: base progs build on Makefile.progs

[Alexei Starovoitov]

On Thu, Sep 05, 2019 at 12:22:12AM +0300, Ivan Khoronzhuk wrote:
> +
> +If need to use environment of target board, the SYSROOT also can be set,
> +pointing on FS of target board:
> +
> +make samples/bpf/ LLC=~/git/llvm/build/bin/llc \
> + CLANG=~/git/llvm/build/bin/clang \
> + SYSROOT=~/some_sdk/linux-devkit/sysroots/aarch64-linux-gnu

Patches 7 and 8 look quite heavy. I don't have a way to test them
which makes me a bit uneasy to accept them as-is.
Would be great if somebody could give Tested-by.

Re: [PATCH bpf-next 2/8] samples: bpf: Makefile: remove target for native build

[Alexei Starovoitov]

On Thu, Sep 05, 2019 at 12:22:06AM +0300, Ivan Khoronzhuk wrote:
> No need to set --target for native build, at least for arm, the
> default target will be used anyway. In case of arm, for at least
> clang 5 - 10 it causes error like:
> 
> clang: warning: unknown platform, assuming -mfloat-abi=soft
> LLVM ERROR: Unsupported calling convention
> make[2]: *** [/home/root/snapshot/samples/bpf/Makefile:299:
> /home/root/snapshot/samples/bpf/sockex1_kern.o] Error 1
> 
> Only set to real triple helps: --target=arm-linux-gnueabihf
> or just drop the target key to use default one. Decision to just
> drop it and thus default target will be used (wich is native),
> looks better.
> 
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  samples/bpf/Makefile | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 61b7394b811e..a2953357927e 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -197,8 +197,6 @@ BTF_PAHOLE ?= pahole
>  ifdef CROSS_COMPILE
>  HOSTCC = $(CROSS_COMPILE)gcc
>  CLANG_ARCH_ARGS = --target=$(notdir $(CROSS_COMPILE:%-=%))
> -else
> -CLANG_ARCH_ARGS = -target $(ARCH)
>  endif

I don't follow here.
Didn't you introduce this bug in patch 1 and now fixing it in patch 2?

Re: [PATCH v2] net: enable wireless core features with LEGACY_WEXT_ALLCONFIG

[Greg KH]

On Fri, Sep 06, 2019 at 12:24:00PM -0700, Mark Salyzyn wrote:
> In embedded environments the requirements are to be able to pick and
> chose which features one requires built into the kernel.  If an
> embedded environment wants to supports loading modules that have been
> kbuilt out of tree, there is a need to enable hidden configurations
> for legacy wireless core features to provide the API surface for
> them to load.
> 
> Introduce CONFIG_LEGACY_WEXT_ALLCONFIG to select all legacy wireless
> extension core features by activating in turn all the associated
> hidden configuration options, without having to specifically select
> any wireless module(s).
> 
> Signed-off-by: Mark Salyzyn 
> Cc: kernel-t...@android.com
> Cc: Johannes Berg 
> Cc: "David S. Miller" 
> Cc: Marcel Holtmann 
> Cc: linux-wirel...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org # 4.19
> ---
> v2: change name and documentation to CONFIG_LEGACY_WEXT_ALLCONFIG
> ---
>  net/wireless/Kconfig | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 67f8360dfcee..0d646cf28de5 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -17,6 +17,20 @@ config WEXT_SPY
>  config WEXT_PRIV
>   bool
>  
> +config LEGACY_WEXT_ALLCONFIG
> + bool "allconfig for legacy wireless extensions"
> + select WIRELESS_EXT
> + select WEXT_CORE
> + select WEXT_PROC
> + select WEXT_SPY
> + select WEXT_PRIV
> + help
> +   Config option used to enable all the legacy wireless extensions to
> +   the core functionality used by add-in modules.
> +
> +   If you are not building a kernel to be used for a variety of
> +   out-of-kernel built wireless modules, say N here.
> +
>  config CFG80211
>   tristate "cfg80211 - wireless configuration API"
>   depends on RFKILL || !RFKILL
> -- 
> 2.23.0.187.g17f5b7556c-goog
> 

How is this patch applicable to stable kernels???

Re: [v5 PATCH] RISC-V: Fix unsupported isa string info.

[Atish Patra]

On Tue, 2019-08-20 at 00:59 -0700, Atish Patra wrote:
> On Sun, 2019-08-18 at 11:16 -0700, h...@infradead.org wrote:
> > On Fri, Aug 16, 2019 at 07:21:52PM +, Atish Patra wrote:
> > > > > + if (isa[0] != '\0') {
> > > > > + /* Add remainging isa strings */
> > > > > + for (e = isa; *e != '\0'; ++e) {
> > > > > +#if !defined(CONFIG_VIRTUALIZATION)
> > > > > + if (e[0] != 'h')
> > > > > +#endif
> > > > > + seq_write(f, e, 1);
> > > > > + }
> > > > > + }
> > > > 
> > > > This one I don't get.  Why do we want to check
> > > > CONFIG_VIRTUALIZATION?
> > > > 
> > > 
> > > If CONFIG_VIRTUALIZATION is not enabled, it shouldn't print that
> > > hypervisor extension "h" in isa extensions.
> > 
> > CONFIG_VIRTUALIZATION doesn't change anything in the kernels
> > capabilities, it just enables other config options. 
> 
> Yes. But it must be enabled if virtualization is supported in kernel.
> The idea was to let userspace know that if virtualization can be used
> or not. 
> 
> 
> >  But more
> > importantly the 'h' extension is only relevant for S-mode software
> > anyway.
> > 
> 
> Do you think we should just print all the extensions available in isa
> string as it is ?
> 
> > > This is just an information to the userspace that some of the
> > > mandatory
> > > ISA extensions ("mafdcsu") are not supported in kernel which may
> > > lead
> > > to undesirable results.
> > 
> > I think we need to sit down decide what the purpose of
> > /proc/cpuinfo
> > is.  IIRC on other architectures is just prints what the hardware
> > supports, not what you can actually make use of.  How else would
> > you
> > find out that you'd need to enable more kernel options to fully
> > utilize the hardware?
> > 
> > Also printing this warning to the kernel log when someone reads the
> > procfs file is very strange.
> 
> Agreed. May be something like this ?
> 
> Let's say f/d is enabled in kernel but cpu doesn't support it.
> "unsupported isa" will only appear if there are any unsupported isa.
> 
> processor   : 3
> hart: 4
> isa : rv64imac
> unsupported isa   : fd
> mmu : sv39
> uarch   : sifive,u54-mc
> 
> May be I am just trying over optimize one corner case :) :).
> /proc/cpuinfo should just print all the isa string. That's it.
> 

Ping ?

> Regards,
> Atish

-- 
Regards,
Atish

[PATCH] clk: qcom: fix QCS404 TuringCC regmap

[Jorge Ramirez-Ortiz]

The max register is 0x23004 as per the manual (the current
max_register that this commit is fixing is actually out of bounds).

Signed-off-by: Jorge Ramirez-Ortiz 
---
 drivers/clk/qcom/turingcc-qcs404.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/qcom/turingcc-qcs404.c 
b/drivers/clk/qcom/turingcc-qcs404.c
index aa859e6ec9bd..4cfbbf5bf4d9 100644
--- a/drivers/clk/qcom/turingcc-qcs404.c
+++ b/drivers/clk/qcom/turingcc-qcs404.c
@@ -96,7 +96,7 @@ static const struct regmap_config turingcc_regmap_config = {
.reg_bits   = 32,
.reg_stride = 4,
.val_bits   = 32,
-   .max_register   = 0x3,
+   .max_register   = 0x23004,
.fast_io= true,
 };
 
-- 
2.23.0

[PATCH] Add PCI device IDs for family 17h, model 70h

[Isaac Vaughn]

Add the new Family 17h Model 70h PCI IDs (device 18h functions 0 and 6)
to the AMD64 EDAC module.

Cc: Borislav Petkov  (maintainer:EDAC-AMD64)
Cc: Mauro Carvalho Chehab  (supporter:EDAC-CORE)
Cc: James Morse  (reviewer:EDAC-CORE)
Cc: linux-e...@vger.kernel.org (open list:EDAC-AMD64)
Cc: linux-kernel@vger.kernel.org (open list)
Signed-off-by: Isaac Vaughn 
---
 drivers/edac/amd64_edac.c | 13 +
 drivers/edac/amd64_edac.h |  3 +++
 2 files changed, 16 insertions(+)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 873437be86d9..a35c97f9100a 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2253,6 +2253,15 @@ static struct amd64_family_type family_types[] = {
.dbam_to_cs = f17_base_addr_to_cs_size,
}
},
+   [F17_M70H_CPUS] = {
+   .ctl_name = "F17h_M70h",
+   .f0_id = PCI_DEVICE_ID_AMD_17H_M70H_DF_F0,
+   .f6_id = PCI_DEVICE_ID_AMD_17H_M70H_DF_F6,
+   .ops = {
+   .early_channel_count= f17_early_channel_count,
+   .dbam_to_cs = f17_base_addr_to_cs_size,
+   }
+   },
 };
 
 /*
@@ -3241,6 +3250,10 @@ static struct amd64_family_type *per_family_init(struct 
amd64_pvt *pvt)
fam_type = _types[F17_M30H_CPUS];
pvt->ops = _types[F17_M30H_CPUS].ops;
break;
+   } else if (pvt->model >= 0x70 && pvt->model <= 0x7f) {
+   fam_type = _types[F17_M70H_CPUS];
+   pvt->ops = _types[F17_M70H_CPUS].ops;
+   break;
}
/* fall through */
case 0x18:
diff --git a/drivers/edac/amd64_edac.h b/drivers/edac/amd64_edac.h
index 8f66472f7adc..1adf7ddbf744 100644
--- a/drivers/edac/amd64_edac.h
+++ b/drivers/edac/amd64_edac.h
@@ -119,6 +119,8 @@
 #define PCI_DEVICE_ID_AMD_17H_M10H_DF_F6 0x15ee
 #define PCI_DEVICE_ID_AMD_17H_M30H_DF_F0 0x1490
 #define PCI_DEVICE_ID_AMD_17H_M30H_DF_F6 0x1496
+#define PCI_DEVICE_ID_AMD_17H_M70H_DF_F0 0x1440
+#define PCI_DEVICE_ID_AMD_17H_M70H_DF_F6 0x1446
 
 /*
  * Function 1 - Address Map
@@ -285,6 +287,7 @@ enum amd_families {
F17_CPUS,
F17_M10H_CPUS,
F17_M30H_CPUS,
+   F17_M70H_CPUS,
NUM_FAMILIES,
 };
 
-- 
2.23.0

Re: [GIT PULL] SCSI fixes for 5.3-rc7

[Linus Torvalds]

On Fri, Sep 6, 2019 at 1:39 PM James Bottomley
 wrote:
>
>
> diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
> index 8d8c495b5b60..d65558619ab0 100644
> --- a/drivers/scsi/lpfc/lpfc_attr.c
> +++ b/drivers/scsi/lpfc/lpfc_attr.c
> @@ -5715,7 +5715,7 @@ LPFC_ATTR_RW(nvme_embed_cmd, 1, 0, 2,
>   *  0= Set nr_hw_queues by the number of CPUs or HW queues.
>   *  1,128 = Manually specify the maximum nr_hw_queue value to be set,
>   *
> - * Value range is [0,128]. Default value is 8.
> + * Value range is [0,256]. Default value is 8.
>   */

Shouldn't that "1,128 = Manually specify.." line also have been updated?

Not that I really care, and I'll pul this, but..

  Linus

[PATCH v2] powerpc/lockdep: fix a false positive warning

[Qian Cai]

The commit 108c14858b9e ("locking/lockdep: Add support for dynamic
keys") introduced a boot warning on powerpc below, because since the
commit 2d4f567103ff ("KVM: PPC: Introduce kvm_tmp framework") adds
kvm_tmp[] into the .bss section and then free the rest of unused spaces
back to the page allocator.

kernel_init
  kvm_guest_init
kvm_free_tmp
  free_reserved_area
free_unref_page
  free_unref_page_prepare

Later, alloc_workqueue() happens to allocate some pages from there and
trigger the warning at,

if (WARN_ON_ONCE(static_obj(key)))

Fix it by adding a generic helper arch_is_bss_hole() to skip those areas
in static_obj(). Since kvm_free_tmp() is only done early during the
boot, just go lockless to make the implementation simple for now.

WARNING: CPU: 0 PID: 13 at kernel/locking/lockdep.c:1120
Workqueue: events work_for_cpu_fn
Call Trace:
  lockdep_register_key+0x68/0x200
  wq_init_lockdep+0x40/0xc0
  trunc_msg+0x385f9/0x4c30f (unreliable)
  wq_init_lockdep+0x40/0xc0
  alloc_workqueue+0x1e0/0x620
  scsi_host_alloc+0x3d8/0x490
  ata_scsi_add_hosts+0xd0/0x220 [libata]
  ata_host_register+0x178/0x400 [libata]
  ata_host_activate+0x17c/0x210 [libata]
  ahci_host_activate+0x84/0x250 [libahci]
  ahci_init_one+0xc74/0xdc0 [ahci]
  local_pci_probe+0x78/0x100
  work_for_cpu_fn+0x40/0x70
  process_one_work+0x388/0x750
  process_scheduled_works+0x50/0x90
  worker_thread+0x3d0/0x570
  kthread+0x1b8/0x1e0
  ret_from_kernel_thread+0x5c/0x7c

Fixes: 108c14858b9e ("locking/lockdep: Add support for dynamic keys")
Signed-off-by: Qian Cai 
---

v2: No need to actually define arch_is_bss_hole() powerpc64 only.

 arch/powerpc/include/asm/sections.h | 11 +++
 arch/powerpc/kernel/kvm.c   |  5 +
 include/asm-generic/sections.h  |  7 +++
 kernel/locking/lockdep.c|  3 +++
 4 files changed, 26 insertions(+)

diff --git a/arch/powerpc/include/asm/sections.h 
b/arch/powerpc/include/asm/sections.h
index 4a1664a8658d..4f5d69c42017 100644
--- a/arch/powerpc/include/asm/sections.h
+++ b/arch/powerpc/include/asm/sections.h
@@ -5,8 +5,19 @@
 
 #include 
 #include 
+
+#define arch_is_bss_hole arch_is_bss_hole
+
 #include 
 
+extern void *bss_hole_start, *bss_hole_end;
+
+static inline int arch_is_bss_hole(unsigned long addr)
+{
+   return addr >= (unsigned long)bss_hole_start &&
+  addr < (unsigned long)bss_hole_end;
+}
+
 extern char __head_end[];
 
 #ifdef __powerpc64__
diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
index b7b3a5e4e224..89e0e522e125 100644
--- a/arch/powerpc/kernel/kvm.c
+++ b/arch/powerpc/kernel/kvm.c
@@ -66,6 +66,7 @@
 static bool kvm_patching_worked = true;
 char kvm_tmp[1024 * 1024];
 static int kvm_tmp_index;
+void *bss_hole_start, *bss_hole_end;
 
 static inline void kvm_patch_ins(u32 *inst, u32 new_inst)
 {
@@ -707,6 +708,10 @@ static __init void kvm_free_tmp(void)
 */
kmemleak_free_part(_tmp[kvm_tmp_index],
   ARRAY_SIZE(kvm_tmp) - kvm_tmp_index);
+
+   bss_hole_start = _tmp[kvm_tmp_index];
+   bss_hole_end = _tmp[ARRAY_SIZE(kvm_tmp)];
+
free_reserved_area(_tmp[kvm_tmp_index],
   _tmp[ARRAY_SIZE(kvm_tmp)], -1, NULL);
 }
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index d1779d442aa5..4d8b1f2c5fd9 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -91,6 +91,13 @@ static inline int arch_is_kernel_initmem_freed(unsigned long 
addr)
 }
 #endif
 
+#ifndef arch_is_bss_hole
+static inline int arch_is_bss_hole(unsigned long addr)
+{
+   return 0;
+}
+#endif
+
 /**
  * memory_contains - checks if an object is contained within a memory region
  * @begin: virtual address of the beginning of the memory region
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 4861cf8e274b..cd75b51f15ce 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -675,6 +675,9 @@ static int static_obj(const void *obj)
if (arch_is_kernel_initmem_freed(addr))
return 0;
 
+   if (arch_is_bss_hole(addr))
+   return 0;
+
/*
 * static variable?
 */
-- 
2.20.1 (Apple Git-117)

Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism

[Ming Lei]

On Fri, Sep 06, 2019 at 04:25:55PM -0600, Keith Busch wrote:
> On Sat, Sep 07, 2019 at 06:19:21AM +0800, Ming Lei wrote:
> > On Fri, Sep 06, 2019 at 05:50:49PM +, Long Li wrote:
> > > >Subject: Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism
> > > >
> > > >Why are all 8 nvmes sharing the same CPU for interrupt handling?
> > > >Shouldn't matrix_find_best_cpu_managed() handle selecting the least used
> > > >CPU from the cpumask for the effective interrupt handling?
> > > 
> > > The tests run on 10 NVMe disks on a system of 80 CPUs. Each NVMe disk has 
> > > 32 hardware queues.
> > 
> > Then there are total 320 NVMe MSI/X vectors, and 80 CPUs, so irq matrix
> > can't avoid effective CPUs overlapping at all.
> 
> Sure, but it's at most half, meanwhile the CPU that's dispatching requests
> would naturally be throttled by the other half who's completions are
> interrupting that CPU, no?

The root cause is that multiple submission vs. single completion.

Let's see two cases:

1) 10 NVMe, each 8 queues, 80 CPU cores
- suppose genriq matrix can avoid effective cpu overlap, each cpu
  only handles one nvme interrupt
- there can be concurrent submissions from 10 CPUs, and all may be
  completed on one CPU
- IRQ flood couldn't happen for this case, given each CPU is only
  handling completion from one NVMe drive, which shouldn't be fast
  than CPU.

2) 10 NVMe, each 32 queues, 80 CPU cores
- one CPU may handle 4 NVMe interrupts, each from different NVMe drive
- then there may be 4*3 submissions aimed at single completion, then IRQ
  flood should be easy triggered on CPU for handing 4 NVMe interrupts.
  Because IO from 4 NVMe drive may be quicker than one CPU.

I can observe IRQ flood on the case #1, but there are still CPUs for
handling 2 NVMe interrupt, as the reason mentioned by Long. We could
improve for this case.

Thanks,
Ming

Re: [GIT PULL] compiler-attributes for v5.3-rc8

[Linus Torvalds]

On Fri, Sep 6, 2019 at 3:47 PM Nick Desaulniers  wrote:
>
> Sedat reported 
> (https://github.com/ClangBuiltLinux/linux/issues/619#issuecomment-520042577,
> https://github.com/ClangBuiltLinux/linux/issues/619#issuecomment-520065525)
> that only the bottom two hunks of that patch
> (https://github.com/ojeda/linux/commit/c97e82b97f4bba00304905fe7965f923abd2d755)

[ missing "matters" or something here? ]

If fixing two of the __section() uses in that tracing header file is
needed, then just fix all four there. I'm ok with that.

Linus

Re: general protection fault in dev_map_hash_update_elem

[Toke Høiland-Jørgensen]

Jesper Dangaard Brouer  writes:

> On Thu, 5 Sep 2019 14:44:37 -0700
> Alexei Starovoitov  wrote:
>
>> On Thu, Sep 5, 2019 at 1:08 PM syzbot
>>  wrote:
>> >
>> > Hello,
>> >
>> > syzbot found the following crash on:
>> >
>> > HEAD commit:6d028043 Add linux-next specific files for 20190830
>> > git tree:   linux-next
>> > console output: https://syzkaller.appspot.com/x/log.txt?x=135c1a9260
>> > kernel config:  https://syzkaller.appspot.com/x/.config?x=82a6bec43ab0cb69
>> > dashboard link: 
>> > https://syzkaller.appspot.com/bug?extid=4e7a85b1432052e8d6f8
>> > compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
>> > syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=109124e160
>> >
>> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> > Reported-by: syzbot+4e7a85b1432052e8d...@syzkaller.appspotmail.com
>> >
>> > kasan: CONFIG_KASAN_INLINE enabled
>> > kasan: GPF could be caused by NULL-ptr deref or user memory access
>> > general protection fault:  [#1] PREEMPT SMP KASAN
>> > CPU: 1 PID: 10235 Comm: syz-executor.0 Not tainted 5.3.0-rc6-next-20190830
>> > #75
>> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> > Google 01/01/2011
>> > RIP: 0010:__write_once_size include/linux/compiler.h:203 [inline]
>> > RIP: 0010:__hlist_del include/linux/list.h:795 [inline]
>> > RIP: 0010:hlist_del_rcu include/linux/rculist.h:475 [inline]
>> > RIP: 0010:__dev_map_hash_update_elem kernel/bpf/devmap.c:668 [inline]
>> > RIP: 0010:dev_map_hash_update_elem+0x3c8/0x6e0 kernel/bpf/devmap.c:691
>> > Code: 48 89 f1 48 89 75 c8 48 c1 e9 03 80 3c 11 00 0f 85 d3 02 00 00 48 b9
>> > 00 00 00 00 00 fc ff df 48 8b 53 10 48 89 d6 48 c1 ee 03 <80> 3c 0e 00 0f
>> > 85 97 02 00 00 48 85 c0 48 89 02 74 38 48 89 55 b8
>> > RSP: 0018:88808d607c30 EFLAGS: 00010046
>> > RAX:  RBX: 8880a7f14580 RCX: dc00
>> > RDX:  RSI:  RDI: 8880a7f14588
>> > RBP: 88808d607c78 R08: 0004 R09: ed1011ac0f73
>> > R10: ed1011ac0f72 R11: 0003 R12: 88809f4e9400
>> > R13: 88809b06ba00 R14:  R15: 88809f4e9528
>> > FS:  7f3a3d50c700() GS:8880ae90() 
>> > knlGS:
>> > CS:  0010 DS:  ES:  CR0: 80050033
>> > CR2: 7feb3fcd CR3: 986b9000 CR4: 001406e0
>> > DR0:  DR1:  DR2: 
>> > DR3:  DR6: fffe0ff0 DR7: 0400
>> > Call Trace:
>> >   map_update_elem+0xc82/0x10b0 kernel/bpf/syscall.c:966
>> >   __do_sys_bpf+0x8b5/0x3350 kernel/bpf/syscall.c:2854
>> >   __se_sys_bpf kernel/bpf/syscall.c:2825 [inline]
>> >   __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:2825
>> >   do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
>> >   entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> > RIP: 0033:0x459879
>> > Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
>> > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
>> > ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
>> > RSP: 002b:7f3a3d50bc78 EFLAGS: 0246 ORIG_RAX: 0141
>> > RAX: ffda RBX: 0003 RCX: 00459879
>> > RDX: 0020 RSI: 2040 RDI: 0002
>> > RBP: 0075bf20 R08:  R09: 
>> > R10:  R11: 0246 R12: 7f3a3d50c6d4
>> > R13: 004bfc86 R14: 004d1960 R15: 
>> > Modules linked in:
>> > ---[ end trace 083223e21dbd0ae5 ]---
>> > RIP: 0010:__write_once_size include/linux/compiler.h:203 [inline]
>> > RIP: 0010:__hlist_del include/linux/list.h:795 [inline]
>> > RIP: 0010:hlist_del_rcu include/linux/rculist.h:475 [inline]
>> > RIP: 0010:__dev_map_hash_update_elem kernel/bpf/devmap.c:668 [inline]
>> > RIP: 0010:dev_map_hash_update_elem+0x3c8/0x6e0 kernel/bpf/devmap.c:691  
>> 
>> Toke,
>> please take a look.
>> Thanks!
>
> Hi Toke,
>
> I think the problem is that you read:
>  old_dev = __dev_map_hash_lookup_elem(map, idx);
>
> Before holding the lock dtab->index_lock... 
>
> I'm not sure this is the correct fix, but I think below change should
> solve the issue (not even compile tested):
>
> [bpf-next]$ git diff
>
> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index 9af048a932b5..c41854a68e9e 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
> @@ -664,6 +664,9 @@ static int __dev_map_hash_update_elem(struct net *net, 
> struct bpf_map *map,
>  
> spin_lock_irqsave(>index_lock, flags);
>  
> +   /* Re-read old_dev while holding lock*/
> +   old_dev = __dev_map_hash_lookup_elem(map, idx);
> +
> if (old_dev) {
> hlist_del_rcu(_dev->index_hlist);
> } else {

I think you're right that it's a race between reading the old_dev ptr
and the removal, leading to attempts to remove the same 

Re: [PATCH] xen/pci: try to reserve MCFG areas earlier

[Igor Druzhinin]

On 06/09/2019 23:30, Boris Ostrovsky wrote:
> On 9/3/19 8:20 PM, Igor Druzhinin wrote:
>> If MCFG area is not reserved in E820, Xen by default will defer its usage
>> until Dom0 registers it explicitly after ACPI parser recognizes it as
>> a reserved resource in DSDT. Having it reserved in E820 is not
>> mandatory according to "PCI Firmware Specification, rev 3.2" (par. 4.1.2)
>> and firmware is free to keep a hole E820 in that place. Xen doesn't know
>> what exactly is inside this hole since it lacks full ACPI view of the
>> platform therefore it's potentially harmful to access MCFG region
>> without additional checks as some machines are known to provide
>> inconsistent information on the size of the region.
>>
>> Now xen_mcfg_late() runs after acpi_init() which is too late as some basic
>> PCI enumeration starts exactly there. Trying to register a device prior
>> to MCFG reservation causes multiple problems with PCIe extended
>> capability initializations in Xen (e.g. SR-IOV VF BAR sizing). There are
>> no convenient hooks for us to subscribe to so try to register MCFG
>> areas earlier upon the first invocation of xen_add_device(). 
> 
> 
> Where is MCFG parsed? pci_arch_init()?

It happens twice:
1) first time early one in pci_arch_init() that is arch_initcall - that
time pci_mmcfg_list will be freed immediately there because MCFG area is
not reserved in E820;
2) second time late one in acpi_init() which is subsystem_initcall right
before where PCI enumeration starts - this time ACPI tables will be
checked for a reserved resource and pci_mmcfg_list will be finally
populated.

The problem is that on a system that doesn't have MCFG area reserved in
E820 pci_mmcfg_list is empty before acpi_init() and our PCI hooks are
called in the same place. So MCFG is still not in use by Xen at this
point since we haven't reached our xen_mcfg_late().

Igor

Re: [RFC PATCH 1/9] sched,cgroup: Add interface for latency-nice

[Valentin Schneider]

On 06/09/2019 18:10, Parth Shah wrote:
> Right, CPU capacity can solve the problem of indicating the thermal throttle 
> to the scheduler.
> AFAIU, the patchset from Thara changes CPU capacity to reflect Thermal 
> headroom of the CPU.
> This is a nice mitigation but,
> 1. Sometimes a single task is responsible for the Thermal heatup of the core, 
> reducing the
>CPU capacity of all the CPUs in the core is not optimal when just moving 
> such single
>task to other core can allow us to remain within thermal headroom. This is 
> important
>for the servers especially where there are upto 8 threads.> 2. Given the 
> implementation in the patches and its integration with EAS, it seems difficult
>to adapt to servers, where CPU capacity itself is in doubt.
>https://lkml.org/lkml/2019/5/15/1402
> 

I'd nuance this to *SMT* capacity (which isn't just servers). The thing is
that it's difficult to come up with a sensible scheme to describe the base
capacity of a single logical CPU. But yeah, valid point.

>>
>> For active balance, we actually already have a condition that moves a task
>> to a less capacity-pressured CPU (although it is somewhat specific). So if
>> thermal pressure follows that task (e.g. it's doing tons of vector/float),
>> it will be rotated around.
> 
> Agree. But this should break in certain conditions like when we have multiple 
> tasks
> in a core with almost equal utilization among which one is just doing vector 
> operations.
> LB can pick and move any task with equal probability if the capacity is 
> reduced here.
> 

Right, if/when we get things like per-unit signals (wasn't there something
about tracking AVX a few months back?) then we'll be able to make
more informed decisions, for now we'll need some handholding (read: task
classification).

>>
>> However there should be a point made on latency vs throughput. If you
>> care about latency you probably do not want to active balance your task. If
> 
> Can you please elaborate on why not to consider active balance for latency 
> sensitive tasks?
> Because, sometimes finding a thermally cool core is beneficial when Turbo 
> frequency
> range is around 20% above rated ones.
> 

This goes back to my reply to Patrick further up the thread.

Right now active balance can happen just because we've been imbalanced for
some time and repeatedly failed to migrate anything. After 3 (IIRC) successive
failed attempts, we'll active balance the running task of the remote rq we
decided was busiest.

If that happens to be a latency sensitive task, that's not great - active
balancing means stopping that task's execution, so we're going to add some
latency to this latency-sensitive task. My proposal was to further ratelimit
active balance (e.g. require more failed attempts) when the task that would be
preempted is latency-sensitive.

My point is: if that task is doing fine where it is, why preempt it? That's
just introducing latency IMO (keeping in mind that those balance attempts
could happen despite not having any thermal pressure).

If you care about performance (e.g. a minimum level of throughput), to me
that is a separate (though perhaps not entirely distinct) property.

>> you care about throughput, it should be specified in some way (util-clamp
>> says hello!).
>>
> 
> yes I do care for latency and throughput both. :-)

Don't we all!

> but I'm wondering how uclamp can solve the problem for throughput.
> If I make the thermally hot tasks to appear bigger than other tasks then 
> reducing
> CPU capacity can allow such tasks to move around the chip.
> But this will require the utilization value to be relatively large compared 
> to the other
> tasks in the core. Or other task's uclamp.max can be lowered to make such 
> task rotate.
> If I got it right, then this will be a difficult UCLAMP usecase from user 
> perspective, right?
> I feel like I'm missing something here.
> 

Hmm perhaps I was jumping the gun here. What I was getting to is if you have
something like misfit that migrates tasks to CPUs of higher capacity than the
one they are on, you could use uclamp to flag them.

You could translate your throughput requirement as a uclamp.min of e.g. 80%,
and if the CPU capacity goes below that (or close within a margin) then you'd
try to migrate the task to a CPU of higher capacity (i.e. not or less 
thermally pressured).

This doesn't have to involve your less throughput-sensitive tasks, since you
would only tag and take action for your throughput-sensitive tasks.

[git pull] Input updates for v5.3-rc7

[Dmitry Torokhov]

Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem - a tiny update from Benjamin
removing mistakenly added Elan PNP ID so that device is again handled by
hid-multitouch.

Changelog:
-

Benjamin Tissoires (1):
  Input: elan_i2c - remove Lenovo Legion Y7000 PnpID

Diffstat:


 include/linux/input/elan-i2c-ids.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Thanks.


-- 
Dmitry

Re: [RFC PATCH v4 0/9] printk: new ringbuffer implementation

[John Ogness]

On 2019-09-06, Peter Zijlstra  wrote:
>> I wish it was that simple. It is possible that I see it too
>> complicated. But this comes to my mind:
>> 
>> 1. The simple printk_buffer_store(buf, n) is not NMI safe. For this,
>>we might need the reserve-store approach.
>
> Of course it is, and sure it has a reserve+commit internally. I'm sure
> I posted an implenentation of something like this at some point.
>
> It is lockless (wait-free in fact, which is stronger) and supports
> multi-readers. I'm sure I posted something like that before, and ISTR
> John has something like that around somewhere too.

Yes. It was called RFCv1[0].

> The only thing I'm omitting is doing vscnprintf() twice, first to
> determine the length, and then into the reservation. Partly because I
> think that is silly and 256 chars should be plenty for everyone,
> partly because that avoids having vscnprintf() inside the cpu_lock()
> and partly because it is simpler to not do that.

Yes, this approach is more straight forward and was suggested in the
feedback to RFCv1. Although I think the current limit (1024) should
still be OK. Then we have 1 dedicated page per CPU for vscnprintf().

>> 2. The simple approach works only with lockless consoles. We need
>>something else for the rest at least for NMI. Simle offloading
>>to a kthread has been blocked for years. People wanted the
>>trylock-and-flush-immediately approach.
>
> Have an irq_work to wake up a kthread that will print to shit
> consoles.

This is the approach in all the RFC versions.

>> 5. John planed to use the cpu_lock in the lockless consoles.
>>I wonder if it was only in the console->write() callback
>>or if it would spread the lock more widely.

The 8250 driver in RFCv1 uses the cpu-lock in console->write() on a
per-character basis and in console->write_atomic() on a per-line
basis. This is necessary because the 8250 driver cannot run lockless. It
requires synchronization for its UART_IER clearing/setting before/after
transmit.

IMO the existing early console implementations are _not_ safe for
preemption. This was the reason for the new write_atomic() callback in
RFCv1.

> Right, I'm saying that since you need it anyway, lift it up one layer.
> It makes everything simpler. More simpler is more better.

This was my reasoning for using the cpu-lock in RFCv1. Moving to a
lockless ringbuffer for RFCv2 was because there was too much
resistance/concern surrounding the cpu-lock. But yes, if we want to
support atomic consoles, the cpu-lock will still be needed.

The cpu-lock (and the related concerns) were discussed here[1].

>> 7. People would complain when continuous lines become less
>>reliable. It might be most visible when mixing backtraces
>>from all CPUs. Simple sorting by prefix will not make
>>it readable. The historic way was to synchronize CPUs
>>by a spin lock. But then the cpu_lock() could cause
>>deadlock.
>
> Why? I'm running with that thing on, I've never seen a deadlock ever
> because of it.

As was discussed in the thread I just mentioned, introducing the
cpu-lock means that _all_ NMI functions taking spinlocks need to use the
cpu-lock. Even though Peter has never seen a deadlock, a deadlock is
possible if a BUG is triggered while one such spinlock is held. Also
note that it is not allowed to have 2 cpu-locks in the system. This is
where the BKL references started showing up.

Spinlocks in NMI context are rare, but they have existed in the past and
could exist again in the future. My suggestion was to create the policy
that any needed locking in NMI context must be done using the one
cpu-lock.

John Ogness

[0] https://lkml.kernel.org/r/20190212143003.48446-1-john.ogn...@linutronix.de
[1] https://lkml.kernel.org/r/20190227094655.ecdwhsc2bf5sp...@pathway.suse.cz

Re: [GIT PULL] compiler-attributes for v5.3-rc8

[Nick Desaulniers]

On Fri, Sep 6, 2019 at 1:11 PM Miguel Ojeda
 wrote:
>
> On Thu, Sep 5, 2019 at 10:53 PM Linus Torvalds
>  wrote:
> >
> > That's probably what we should have done originally, avoiding all the
> > issues with "what if we have multi-part strings" etc.
> >
> > But it's not what we did, probably because it looked slightly simpler
> > to do the stringification in the macro for the usual case.
> >
> > So now we have (according to a quick grep) eight users that have a
> > constant string, and about one hundred users that use the unquoted
> > section name and expect the automatic stringification. I say "about",
> > because I didn't check if any of them might be doing tricks, I really
> > just did a stupid grep.
> >
> > And we have that _one_ insane KENTRY thing that was apparently never
> > actually used.
> >
> > So I think the minimal fix is to just accept that it's what it is,
> > remove the unnecessary quotes from the 8 existing users, and _if_
> > somebody wants to build the string  by hand (like the KENTRY code
> > did), then just use "__attribute__((section(x)))" for that.
> >
> > But yeah, we could just remove the stringification and make the users do it.
> >
> > But for the current late rc (and presumably -stable?), I definitely
> > want the absolute minimal thing that fixes the oops.
>
> Then I will send a PR with that patch only (Nick, do you know if the
> entire patch is needed or we could further reduce it?).

Sedat reported 
(https://github.com/ClangBuiltLinux/linux/issues/619#issuecomment-520042577,
https://github.com/ClangBuiltLinux/linux/issues/619#issuecomment-520065525)
that only the bottom two hunks of that patch
(https://github.com/ojeda/linux/commit/c97e82b97f4bba00304905fe7965f923abd2d755)

>
> Then for 5.4 I will prepare a new series moving to non-stringification
> (unless Nick wants to do it himself).

Technically, it's not a regression, just something that would be nice
to have sooner rather than later.  The whole series can wait for 5.4,
IMO.  I'll look into updating the patchset next week.
-- 
Thanks,
~Nick Desaulniers

RE: [PATCH v5 0/9] Enhance the hv_vmbus driver to support hibernation

[Dexuan Cui]

> From: Sasha Levin 
> Sent: Friday, September 6, 2019 1:03 PM
> On Thu, Sep 05, 2019 at 11:01:14PM +, Dexuan Cui wrote:
> >This patchset (consisting of 9 patches) was part of the v4 patchset 
> >(consisting
> >of 12 patches):
> >
> >The other 3 patches in v4 are posted in another patchset, which will go
> >through the tip.git tree.
> >
> >All the 9 patches here are now rebased to the hyperv tree's hyperv-next
> branch, and all the 9 patches have Michael Kelley's Signed-off-by's.
> >
> >Please review.
> 
> Given that these two series depend on each other, I'd much prefer for
> them to go through one tree.

Hi Sasha,
Yeah, that would be ideal. The problem here is: the other patchset conflicts
with the existing patches in the tip.git tree's timers/core branch, so IMO 
the 3 patches have to go through the tip tree:

[PATCH v5 1/3] x86/hyper-v: Suspend/resume the hypercall page for hibernation
[PATCH v5 2/3] x86/hyper-v: Implement hv_is_hibernation_supported()
[PATCH v5 3/3] clocksource/drivers: Suspend/resume Hyper-V clocksource for 
hibernation

> But, I may be wrong, and I'm going to see if a scenario such as this
> make sense. I've queued this one to the hyperv-next, but I'll wait for
> the x86 folks to send their pull request to Linus first before I do it
> for these patches.

Actually IMHO you don't need to wait, because there is not a build
dependency, so either patchset can go into the Linus's tree first.

The 2 patchsets are just the first step to make hibernation work for Linux VM
running on Hyper-V. Next I'm going to post some high-level VSC patches for
hv_balloon, hv_utils, hv_netvsc, hid_hyperv, hv_storvsc, hyperv_keyboard, 
hyperv_fb,etc. All of these should go through the hyperv tree, since they're
pure hyper-v changes, and they depend on this 9-patch patchset. I'll make
a note in every patch so the subsystem maintainers will be aware and ack it.

Among the VSC patches, the hv_balloon patch does depend on the 2nd patch:
[PATCH v5 2/3] x86/hyper-v: Implement hv_is_hibernation_supported().
I think I'll wait for the aforementioned 2 patchsets to be in first, before 
posting
the hv_balloon patch.

> Usually cases such as these are the exception, but for Hyper-V it seems
> to be the norm, so I'm curious to see how this will unfold.
> 
> Thanks,
> Sasha

Thanks for taking care all the patches!

Thanks,
-- Dexuan

Re: [PATCH v2 0/5] Add support for O_MAYEXEC

[Aleksa Sarai]

On 2019-09-06, Andy Lutomirski  wrote:
> > On Sep 6, 2019, at 12:07 PM, Steve Grubb  wrote:
> > 
> >> On Friday, September 6, 2019 2:57:00 PM EDT Florian Weimer wrote:
> >> * Steve Grubb:
> >>> Now with LD_AUDIT
> >>> $ LD_AUDIT=/home/sgrubb/test/openflags/strip-flags.so.0 strace ./test
> >>> 2>&1 | grep passwd openat(3, "passwd", O_RDONLY)   = 4
> >>> 
> >>> No O_CLOEXEC flag.
> >> 
> >> I think you need to explain in detail why you consider this a problem.
> > 
> > Because you can strip the O_MAYEXEC flag from being passed into the kernel. 
> > Once you do that, you defeat the security mechanism because it never gets 
> > invoked. The issue is that the only thing that knows _why_ something is 
> > being 
> > opened is user space. With this mechanism, you can attempt to pass this 
> > reason to the kernel so that it may see if policy permits this. But you can 
> > just remove the flag.
> 
> I’m with Florian here. Once you are executing code in a process, you
> could just emulate some other unapproved code. This series is not
> intended to provide the kind of absolute protection you’re imagining.

I also agree, though I think that there is a separate argument to be
made that there are two possible problems with O_MAYEXEC (which might
not be really big concerns):

  * It's very footgun-prone if you didn't call O_MAYEXEC yourself and
you pass the descriptor elsewhere. You need to check f_flags to see
if it contains O_MAYEXEC. Maybe there is an argument to be made that
passing O_MAYEXECs around isn't a valid use-case, but in that case
there should be some warnings about that.

  * There's effectively a TOCTOU flaw (even if you are sure O_MAYEXEC is
in f_flags) -- if the filesystem becomes re-mounted noexec (or the
file has a-x permissions) after you've done the check you won't get
hit with an error when you go to use the file descriptor later.

To fix both you'd need to do what you mention later:

> What the kernel *could* do is prevent mmapping a non-FMODE_EXEC file
> with PROT_EXEC, which would indeed have a real effect (in an iOS-like
> world, for example) but would break many, many things.

And I think this would be useful (with the two possible ways of
executing .text split into FMODE_EXEC and FMODE_MAP_EXEC, as mentioned
in a sister subthread), but would have to be opt-in for the obvious
reason you outlined. However, we could make it the default for
openat2(2) -- assuming we can agree on what the semantics of a
theoretical FMODE_EXEC should be.

And of course we'd need to do FMODE_UPGRADE_EXEC (which would need to
also permit fexecve(2) though probably not PROT_EXEC -- I don't think
you can mmap() an O_PATH descriptor).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

Re: Linux 5.2.13

[Bhaskar Chowdhury]

On 15:49 Fri 06 Sep 2019, Greg KH wrote:

I'm announcing the release of the 5.2.13 kernel.

Only users of the elantech driver need to update to fix a regression in
a previous release.

The updated 5.2.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-5.2.y
and can be browsed at the normal kernel.org git web browser:

https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



Makefile   |2 -
drivers/input/mouse/elantech.c |   54 ++---
2 files changed, 30 insertions(+), 26 deletions(-)

Benjamin Tissoires (1):
 Revert "Input: elantech - enable SMBus on new (2018+) systems"

Greg Kroah-Hartman (1):
 Linux 5.2.13



Thanks, a bunch Greg! :)

Thanks,
Bhaskar


signature.asc
Description: PGP signature

Re: [PATCH] mostpost: don't warn about symbols from another file

[Denis Efremov]

Hi,

On 06.09.2019 18:10, Arnd Bergmann wrote:
> On architectures such as ARM that have a list of symbols exported from
> assembler in a separate C file, we get a lot of new warnings:
> 
> WARNING: "__ashrdi3" [vmlinux] is a static (unknown)
> WARNING: "__lshrdi3" [vmlinux] is a static (unknown)
> WARNING: "__aeabi_llsr" [vmlinux] is a static (unknown)
> WARNING: "__aeabi_lasr" [vmlinux] is a static (unknown)
> WARNING: "__aeabi_uidivmod" [vmlinux] is a static (unknown)
> WARNING: "__udivsi3" [vmlinux] is a static (unknown)
> WARNING: "_change_bit" [vmlinux] is a static (unknown)
> WARNING: "__aeabi_idiv" [vmlinux] is a static (unknown)
> WARNING: "__umodsi3" [vmlinux] is a static (unknown)
> WARNING: "__aeabi_uidiv" [vmlinux] is a static (unknown)
> WARNING: "__aeabi_idivmod" [vmlinux] is a static (unknown)
> WARNING: "__muldi3" [vmlinux] is a static (unknown)
> WARNING: "__aeabi_ulcmp" [vmlinux] is a static (unknown)
> WARNING: "__raw_writesb" [vmlinux] is a static (unknown)
> WARNING: "__raw_readsb" [vmlinux] is a static (unknown)
> ...
> 
> This is not helpful, as these are clearly not static symbols
> at all. Suppress the warning in a case like this.
> 

It looks very similar to this discussion https://lkml.org/lkml/2019/7/30/112

Could you please write the steps to reproduce the warnings?
Now, I'm trying to build linux-next (host Ubuntu 19.04 x86_64) with:
$ make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-
But I can't get these warnings.

I would like to check the type of this asm symbols. It seems like they
are STT_NOTYPE. In this case the fix could also involve ELF_ST_TYPE check.

Thanks,
Denis

> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
> Signed-off-by: Arnd Bergmann 
> ---
>  scripts/mod/modpost.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 76c221dd9b2b..4265dd924933 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -2543,7 +2543,7 @@ int main(int argc, char **argv)
>   struct symbol *s = symbolhash[n];
>  
>   while (s) {
> - if (s->is_static)
> + if (s->is_static && s->export != export_unknown)
>   warn("\"%s\" [%s] is a static %s\n",
>s->name, s->module->name,
>export_str(s->export));
> 

Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc

[Paul Walmsley]

One other comment on this patch:

On Fri, 6 Sep 2019, Paul Walmsley wrote:

> On Sun, 18 Aug 2019, Christoph Hellwig wrote:
>
> > diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> > index 200c04ce5b0e..9241b3e7a050 100644
> > --- a/drivers/edac/Kconfig
> > +++ b/drivers/edac/Kconfig
> > @@ -462,7 +462,7 @@ config EDAC_ALTERA_SDMMC
> >  
> >  config EDAC_SIFIVE
> > bool "Sifive platform EDAC driver"
> > -   depends on EDAC=y && RISCV
> > +   depends on EDAC=y && SIFIVE_L2

Since the guidance from the EDAC maintainers is that this driver is to be 
a platform driver -- which would, for example, also include EDAC support for 
other IP blocks (e.g., DRAM controllers) on SiFive SoCs -- this should 
depend on SOC_SIFIVE, not SIFIVE_L2.


- Paul

Re: [PATCH v2 4/6] compiler-gcc.h: add asm_inline definition

[Nick Desaulniers]

On Fri, Sep 6, 2019 at 3:03 PM Segher Boessenkool
 wrote:
>
> On Fri, Sep 06, 2019 at 11:14:08AM -0700, Nick Desaulniers wrote:
> > Here's the case that I think is perfect:
> > https://developers.redhat.com/blog/2016/02/25/new-asm-flags-feature-for-x86-in-gcc-6/
> >
> > Specifically the feature test preprocessor define __GCC_ASM_FLAG_OUTPUTS__.
> >
> > See exactly how we handle it in the kernel:
> > - 
> > https://github.com/ClangBuiltLinux/linux/blob/0445971000375859008414f87e7c72fa0d809cf8/arch/x86/include/asm/asm.h#L112-L118
> > - 
> > https://github.com/ClangBuiltLinux/linux/blob/0445971000375859008414f87e7c72fa0d809cf8/arch/x86/include/asm/rmwcc.h#L14-L30
> >
> > Feature detection of the feature makes it trivial to detect when the
> > feature is supported, rather than brittle compiler version checks.
> > Had it been a GCC version check, it wouldn't work for clang out of the
> > box when clang added support for __GCC_ASM_FLAG_OUTPUTS__.  But since
> > we had the helpful __GCC_ASM_FLAG_OUTPUTS__, and wisely based our use
> > of the feature on that preprocessor define, the code ***just worked***
> > for compilers that didn't support the feature ***and*** compilers when
> > they did support the feature ***without changing any of the source
> > code*** being compiled.
>
> And if instead you tested whether the actual feature you need works as
> you need it to, it would even work fine if there was a bug we fixed that
> breaks things for the kernel.  Without needing a new compiler.

That assumes a feature is broken out of the gate and is putting the
cart before the horse.  If a feature is available, it should work.  If
you later find it to be unsatisfactory, sure go out of your way to add
ugly compiler-specific version checks or upgrade your minimally
supported toolchain; until then feature detection is much cleaner (see
again __GCC_ASM_FLAG_OUTPUTS__).

>
> Or as another example, if we added support for some other flags. (x86
> has only a few flags; many other archs have many more, and in some cases
> newer hardware actually has more flags than older).

I think compiler flags are orthogonal to GNU C extensions we're discussing here.

>
> With the "macro" scheme we would need to add new macros in all these
> cases.  And since those are target-specific macros, that quickly expands
> beyond reasonable bounds.

I don't think so.  Can you show me an example codebase that proves me wrong?

>
> If you want to know if you can do X in some environment, just try to do X.

That's a very autoconf centric viewpoint.  Why doesn't the kernel take
that approach for __GCC_ASM_FLAG_OUTPUTS__?  Why not repeatedly invoke
$CC to find if every compiler __attribute__ is supported?  Do you
think it's faster for the C preprocessor to check for a few #ifdefs,
or to repeatedly invoke $CC at build or compile time to detect new
features?
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH 1/3] software node: implement reference properties

[Dmitry Torokhov]

On Fri, Sep 06, 2019 at 03:27:43PM +0300, Andy Shevchenko wrote:
> On Thu, Sep 05, 2019 at 09:38:07PM -0700, Dmitry Torokhov wrote:
> > It is possible to store references to software nodes in the same fashion as
> > other static properties, so that users do not need to define separate
> > structures:
> > 
> > const struct software_node gpio_bank_b_node = {
> > .name = "B",
> > };
> 
> Why this can't be __initconst?

It may or it may not. I'll remove __inticonst from below as well to not
confuse things.

> 
> > const struct property_entry simone_key_enter_props[] __initconst = {
> > PROPERTY_ENTRY_U32("linux,code", KEY_ENTER),
> > PROPERTY_ENTRY_STRING("label", "enter"),
> > PROPERTY_ENTRY_REF("gpios", _bank_b_node, 123, GPIO_ACTIVE_LOW),
> > { }
> > };
> 
> So it's basically mimics the concept of phandle, right?

Yes.

> 
> > +   ref_args = prop->is_array ?
> > +   >pointer.ref[index] : >value.ref;
> 
> Better to do if with explicit 'if ()' as it's done in the rest of the code.
> 
>   if (prop->is_array)
>   ref_args = ...;
>   else
>   ref_args = ...;

OK, it will be gone actually.

> 
> > -   DEV_PROP_MAX,
> > +   DEV_PROP_MAX
> 
> It seems it wasn't ever used, so, can be dropped completely.

OK.

> 
> > @@ -240,6 +255,7 @@ struct property_entry {
> > const u32 *u32_data;
> > const u64 *u64_data;
> > const char * const *str;
> > +   const struct software_node_ref_args *ref;
> > } pointer;
> > union {
> > u8 u8_data;
> > @@ -247,6 +263,7 @@ struct property_entry {
> > u32 u32_data;
> > u64 u64_data;
> > const char *str;
> > +   struct software_node_ref_args ref;
> 
> Hmm... This bumps the size of union a lot for each existing property_entry.
> Is there any other way? Maybe we can keep pointer and allocate memory for it
> when copying?

Right, I think we can always store references as arrays, even when we
only need single entry, thus we do not need to increase the size of the
structure.

I just posted v2 implementing that, please take another look.

Thanks.

-- 
Dmitry

Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism

[Keith Busch]

On Sat, Sep 07, 2019 at 06:19:21AM +0800, Ming Lei wrote:
> On Fri, Sep 06, 2019 at 05:50:49PM +, Long Li wrote:
> > >Subject: Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism
> > >
> > >Why are all 8 nvmes sharing the same CPU for interrupt handling?
> > >Shouldn't matrix_find_best_cpu_managed() handle selecting the least used
> > >CPU from the cpumask for the effective interrupt handling?
> > 
> > The tests run on 10 NVMe disks on a system of 80 CPUs. Each NVMe disk has 
> > 32 hardware queues.
> 
> Then there are total 320 NVMe MSI/X vectors, and 80 CPUs, so irq matrix
> can't avoid effective CPUs overlapping at all.

Sure, but it's at most half, meanwhile the CPU that's dispatching requests
would naturally be throttled by the other half who's completions are
interrupting that CPU, no?

Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc

[Paul Walmsley]

On Mon, 19 Aug 2019, Christoph Hellwig wrote:

> On Mon, Aug 19, 2019 at 08:09:04AM +0200, Borislav Petkov wrote:
> > On Sun, Aug 18, 2019 at 10:29:35AM +0200, Christoph Hellwig wrote:
> > > The sifive_l2_cache.c is in no way related to RISC-V architecture
> > > memory management.  It is a little stub driver working around the fact
> > > that the EDAC maintainers prefer their drivers to be structured in a
> > > certain way
> > 
> > That changed recently so I guess we can do the per-IP block driver after
> > all, if people would still prefer it.
> 
> That would seem like the best idea.  But I don't really know this code
> well enough myself, and I really need to get this code out of the
> forced on RISC-V codebase as some SOCs I'm working with simply don't
> have the memory for it..

If that's your primary concern, then in the short term, how about just 
sending a single-line patch to the arch/riscv/mm Makefile to skip building 
it if !CONFIG_SOC_SIFIVE?  Assuming, that is, you won't be enabling EDAC 
support for those low-end SoCs.  Then you won't need to get the ack 
from the EDAC folks in the short term.  

Then a patch to make the SiFive platform EDAC driver build contingent on 
CONFIG_SOC_SIFIVE could be sent separately.


- Paul

Re: [PATCH] xen/pci: try to reserve MCFG areas earlier

[Boris Ostrovsky]

On 9/3/19 8:20 PM, Igor Druzhinin wrote:
> If MCFG area is not reserved in E820, Xen by default will defer its usage
> until Dom0 registers it explicitly after ACPI parser recognizes it as
> a reserved resource in DSDT. Having it reserved in E820 is not
> mandatory according to "PCI Firmware Specification, rev 3.2" (par. 4.1.2)
> and firmware is free to keep a hole E820 in that place. Xen doesn't know
> what exactly is inside this hole since it lacks full ACPI view of the
> platform therefore it's potentially harmful to access MCFG region
> without additional checks as some machines are known to provide
> inconsistent information on the size of the region.
>
> Now xen_mcfg_late() runs after acpi_init() which is too late as some basic
> PCI enumeration starts exactly there. Trying to register a device prior
> to MCFG reservation causes multiple problems with PCIe extended
> capability initializations in Xen (e.g. SR-IOV VF BAR sizing). There are
> no convenient hooks for us to subscribe to so try to register MCFG
> areas earlier upon the first invocation of xen_add_device(). 


Where is MCFG parsed? pci_arch_init()?

-boris


> Keep the
> existing initcall in case information of MCFG areas is updated later
> in acpi_init().
>

Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc

[Paul Walmsley]

On Sun, 18 Aug 2019, Christoph Hellwig wrote:

> The sifive_l2_cache.c is in no way related to RISC-V architecture
> memory management.  It is a little stub driver working around the fact
> that the EDAC maintainers prefer their drivers to be structured in a
> certain way that doesn't fit the SiFive SOCs.
> 
> Move the file to drivers/soc and add a Kconfig option for it, as well
> as the whole drivers/soc boilerplate for CONFIG_SOC_SIFIVE.

The code in the patch looks OK to me.  However, two topics that need 
action:

- Since the patch doesn't fix any bugs, there shouldn't be a Fixes: line.  
Please let me know whether I can drop the line locally before I apply the 
patch, or whether you'd like to resend it.

- Since the patch touches drivers/edac/Kconfig, it needs to be acked by 
the EDAC maintainers.  I've added them to this message, but I need you to 
do the work of chasing down the ack, as is standard Linux practice.

If we can get those within the next few days, I'll add it to the queue for 
v5.4-rc1.

thanks -

- Paul

> 
> Fixes: a967a289f169 ("RISC-V: sifive_l2_cache: Add L2 cache controller driver 
> for SiFive SoCs")
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/riscv/mm/Makefile |  1 -
>  drivers/edac/Kconfig   |  2 +-
>  drivers/soc/Kconfig|  1 +
>  drivers/soc/Makefile   |  1 +
>  drivers/soc/sifive/Kconfig | 10 ++
>  drivers/soc/sifive/Makefile|  4 
>  .../riscv/mm => drivers/soc/sifive}/sifive_l2_cache.c  |  0
>  7 files changed, 17 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/soc/sifive/Kconfig
>  create mode 100644 drivers/soc/sifive/Makefile
>  rename {arch/riscv/mm => drivers/soc/sifive}/sifive_l2_cache.c (100%)
> 
> diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
> index 74055e1d6f21..d2101d0741d4 100644
> --- a/arch/riscv/mm/Makefile
> +++ b/arch/riscv/mm/Makefile
> @@ -11,6 +11,5 @@ obj-y += extable.o
>  obj-y += ioremap.o
>  obj-y += cacheflush.o
>  obj-y += context.o
> -obj-y += sifive_l2_cache.o
>  
>  obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 200c04ce5b0e..9241b3e7a050 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -462,7 +462,7 @@ config EDAC_ALTERA_SDMMC
>  
>  config EDAC_SIFIVE
>   bool "Sifive platform EDAC driver"
> - depends on EDAC=y && RISCV
> + depends on EDAC=y && SIFIVE_L2
>   help
> Support for error detection and correction on the SiFive SoCs.
>  
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 833e04a7835c..1778f8c62861 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -14,6 +14,7 @@ source "drivers/soc/qcom/Kconfig"
>  source "drivers/soc/renesas/Kconfig"
>  source "drivers/soc/rockchip/Kconfig"
>  source "drivers/soc/samsung/Kconfig"
> +source "drivers/soc/sifive/Kconfig"
>  source "drivers/soc/sunxi/Kconfig"
>  source "drivers/soc/tegra/Kconfig"
>  source "drivers/soc/ti/Kconfig"
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 2ec355003524..8b49d782a1ab 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -20,6 +20,7 @@ obj-y   += qcom/
>  obj-y+= renesas/
>  obj-$(CONFIG_ARCH_ROCKCHIP)  += rockchip/
>  obj-$(CONFIG_SOC_SAMSUNG)+= samsung/
> +obj-$(CONFIG_SOC_SIFIVE) += sifive/
>  obj-y+= sunxi/
>  obj-$(CONFIG_ARCH_TEGRA) += tegra/
>  obj-y+= ti/
> diff --git a/drivers/soc/sifive/Kconfig b/drivers/soc/sifive/Kconfig
> new file mode 100644
> index ..9ffb2e8a48cd
> --- /dev/null
> +++ b/drivers/soc/sifive/Kconfig
> @@ -0,0 +1,10 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +if SOC_SIFIVE
> +
> +config SIFIVE_L2
> + tristate "Sifive L2 Cache controller"
> + help
> +   Support for the L2 cache controller on SiFive platforms.
> +
> +endif
> diff --git a/drivers/soc/sifive/Makefile b/drivers/soc/sifive/Makefile
> new file mode 100644
> index ..9b4a85558347
> --- /dev/null
> +++ b/drivers/soc/sifive/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_SIFIVE_L2)  += sifive_l2_cache.o
> +
> diff --git a/arch/riscv/mm/sifive_l2_cache.c 
> b/drivers/soc/sifive/sifive_l2_cache.c
> similarity index 100%
> rename from arch/riscv/mm/sifive_l2_cache.c
> rename to drivers/soc/sifive/sifive_l2_cache.c
> -- 
> 2.20.1
> 
> 

[PATCH v2 3/3] software node: remove separate handling of references

[Dmitry Torokhov]

Now that all users of references have moved to reference properties,
we can remove separate handling of references.

Signed-off-by: Dmitry Torokhov 
---

v1->v2:

- dropped rename of struct software_node_ref_args ->
struct software_node_reference

 drivers/base/swnode.c| 44 +++-
 include/linux/property.h | 14 -
 2 files changed, 16 insertions(+), 42 deletions(-)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index bd720d995123..5dc113de0cae 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -570,8 +570,7 @@ software_node_get_reference_args(const struct fwnode_handle 
*fwnode,
 struct fwnode_reference_args *args)
 {
struct swnode *swnode = to_swnode(fwnode);
-   const struct software_node_reference *ref;
-   const struct software_node_ref_args *ref_args;
+   const struct software_node_ref_args *ref;
const struct property_entry *prop;
struct fwnode_handle *refnode;
int i;
@@ -580,36 +579,25 @@ software_node_get_reference_args(const struct 
fwnode_handle *fwnode,
return -ENOENT;
 
prop = property_entry_get(swnode->node->properties, propname);
-   if (prop) {
-   if (prop->type != DEV_PROP_REF)
-   return -EINVAL;
-
-   /*
-* We expect all references to be stored as arrays via
-* a pointer, even single ones.
-*/
-   if (!prop->is_array)
-   return -EINVAL;
-
-   if (index * sizeof(*ref_args) >= prop->length)
-   return -ENOENT;
+   if (!prop)
+   return -ENOENT;
 
-   ref_args = >pointer.ref[index];
-   } else {
-   if (!swnode->node->references)
-   return -ENOENT;
+   if (prop->type != DEV_PROP_REF)
+   return -EINVAL;
 
-   for (ref = swnode->node->references; ref->name; ref++)
-   if (!strcmp(ref->name, propname))
-   break;
+   /*
+* We expect all references to be stored as arrays via
+* a pointer, even single ones.
+*/
+   if (!prop->is_array)
+   return -EINVAL;
 
-   if (!ref->name || index > (ref->nrefs - 1))
-   return -ENOENT;
+   if (index * sizeof(*ref) >= prop->length)
+   return -ENOENT;
 
-   ref_args = >refs[index];
-   }
+   ref = >pointer.ref[index];
 
-   refnode = software_node_fwnode(ref_args->node);
+   refnode = software_node_fwnode(ref->node);
if (!refnode)
return -ENOENT;
 
@@ -628,7 +616,7 @@ software_node_get_reference_args(const struct fwnode_handle 
*fwnode,
args->nargs = nargs;
 
for (i = 0; i < nargs; i++)
-   args->args[i] = ref_args->args[i];
+   args->args[i] = ref->args[i];
 
return 0;
 }
diff --git a/include/linux/property.h b/include/linux/property.h
index 6658403f6fa9..5e4adccd6404 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -415,30 +415,16 @@ int fwnode_graph_parse_endpoint(const struct 
fwnode_handle *fwnode,
 /* -- 
*/
 /* Software fwnode support - when HW description is incomplete or missing */
 
-/**
- * struct software_node_reference - Named software node reference property
- * @name: Name of the property
- * @nrefs: Number of elements in @refs array
- * @refs: Array of references with optional arguments
- */
-struct software_node_reference {
-   const char *name;
-   unsigned int nrefs;
-   const struct software_node_ref_args *refs;
-};
-
 /**
  * struct software_node - Software node description
  * @name: Name of the software node
  * @parent: Parent of the software node
  * @properties: Array of device properties
- * @references: Array of software node reference properties
  */
 struct software_node {
const char *name;
const struct software_node *parent;
const struct property_entry *properties;
-   const struct software_node_reference *references;
 };
 
 bool is_software_node(const struct fwnode_handle *fwnode);
-- 
2.23.0.187.g17f5b7556c-goog

[PATCH v2 2/3] platform/x86: intel_cht_int33fe: use inline reference properties

[Dmitry Torokhov]

Now that static device properties allow defining reference properties
together with all other types of properties, instead of managing them
separately, let's adjust the driver.

Signed-off-by: Dmitry Torokhov 
---

v1-v2:

- rebased on top of linux-next-20190904

 drivers/platform/x86/intel_cht_int33fe.c | 81 
 1 file changed, 41 insertions(+), 40 deletions(-)

diff --git a/drivers/platform/x86/intel_cht_int33fe.c 
b/drivers/platform/x86/intel_cht_int33fe.c
index 1d5d877b9582..4177c5424931 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -46,30 +46,6 @@ struct cht_int33fe_data {
struct fwnode_handle *dp;
 };
 
-static const struct software_node nodes[];
-
-static const struct software_node_ref_args pi3usb30532_ref = {
-   [INT33FE_NODE_PI3USB30532]
-};
-
-static const struct software_node_ref_args dp_ref = {
-   [INT33FE_NODE_DISPLAYPORT]
-};
-
-static struct software_node_ref_args mux_ref;
-
-static const struct software_node_reference usb_connector_refs[] = {
-   { "orientation-switch", 1, _ref},
-   { "mode-switch", 1, _ref},
-   { "displayport", 1, _ref},
-   { }
-};
-
-static const struct software_node_reference fusb302_refs[] = {
-   { "usb-role-switch", 1, _ref},
-   { }
-};
-
 /*
  * Grrr I severly dislike buggy BIOS-es. At least one BIOS enumerates
  * the max17047 both through the INT33FE ACPI device (it is right there
@@ -105,8 +81,18 @@ static const struct property_entry max17047_props[] = {
{ }
 };
 
+/*
+ * We are not using inline property here because those are constant,
+ * and we need to adjust this one at runtime to point to real
+ * software node.
+ */
+static struct software_node_ref_args fusb302_mux_refs[] = {
+   { .node = NULL },
+};
+
 static const struct property_entry fusb302_props[] = {
PROPERTY_ENTRY_STRING("linux,extcon-name", "cht_wcove_pwrsrc"),
+   PROPERTY_ENTRY_REF_ARRAY("usb-role-switch", fusb302_mux_refs),
{ }
 };
 
@@ -122,6 +108,8 @@ static const u32 snk_pdo[] = {
PDO_VAR(5000, 12000, 3000),
 };
 
+static const struct software_node nodes[];
+
 static const struct property_entry usb_connector_props[] = {
PROPERTY_ENTRY_STRING("data-role", "dual"),
PROPERTY_ENTRY_STRING("power-role", "dual"),
@@ -129,15 +117,21 @@ static const struct property_entry usb_connector_props[] 
= {
PROPERTY_ENTRY_U32_ARRAY("source-pdos", src_pdo),
PROPERTY_ENTRY_U32_ARRAY("sink-pdos", snk_pdo),
PROPERTY_ENTRY_U32("op-sink-microwatt", 250),
+   PROPERTY_ENTRY_REF("orientation-switch",
+  [INT33FE_NODE_PI3USB30532]),
+   PROPERTY_ENTRY_REF("mode-switch",
+  [INT33FE_NODE_PI3USB30532]),
+   PROPERTY_ENTRY_REF("displayport",
+  [INT33FE_NODE_DISPLAYPORT]),
{ }
 };
 
 static const struct software_node nodes[] = {
-   { "fusb302", NULL, fusb302_props, fusb302_refs },
+   { "fusb302", NULL, fusb302_props },
{ "max17047", NULL, max17047_props },
{ "pi3usb30532" },
{ "displayport" },
-   { "connector", [0], usb_connector_props, usb_connector_refs },
+   { "connector", [0], usb_connector_props },
{ }
 };
 
@@ -173,9 +167,10 @@ static void cht_int33fe_remove_nodes(struct 
cht_int33fe_data *data)
 {
software_node_unregister_nodes(nodes);
 
-   if (mux_ref.node) {
-   fwnode_handle_put(software_node_fwnode(mux_ref.node));
-   mux_ref.node = NULL;
+   if (fusb302_mux_refs[0].node) {
+   fwnode_handle_put(
+   software_node_fwnode(fusb302_mux_refs[0].node));
+   fusb302_mux_refs[0].node = NULL;
}
 
if (data->dp) {
@@ -187,25 +182,31 @@ static void cht_int33fe_remove_nodes(struct 
cht_int33fe_data *data)
 
 static int cht_int33fe_add_nodes(struct cht_int33fe_data *data)
 {
+   const struct software_node *mux_ref_node;
int ret;
 
-   ret = software_node_register_nodes(nodes);
-   if (ret)
-   return ret;
-
-   /* The devices that are not created in this driver need extra steps. */
-
/*
 * There is no ACPI device node for the USB role mux, so we need to wait
 * until the mux driver has created software node for the mux device.
 * It means we depend on the mux driver. This function will return
 * -EPROBE_DEFER until the mux device is registered.
 */
-   mux_ref.node = software_node_find_by_name(NULL, "intel-xhci-usb-sw");
-   if (!mux_ref.node) {
-   ret = -EPROBE_DEFER;
-   goto err_remove_nodes;
-   }
+   mux_ref_node = software_node_find_by_name(NULL, "intel-xhci-usb-sw");
+   if (!mux_ref_node)
+   return -EPROBE_DEFER;
+
+   /*
+* Update node used in "usb-role-switch" property. Note that we
+* rely on 

[PATCH v2 1/3] software node: implement reference properties

[Dmitry Torokhov]

It is possible to store references to software nodes in the same fashion as
other static properties, so that users do not need to define separate
structures:

static const struct software_node gpio_bank_b_node = {
.name = "B",
};

static const struct property_entry simone_key_enter_props[] = {
PROPERTY_ENTRY_U32("linux,code", KEY_ENTER),
PROPERTY_ENTRY_STRING("label", "enter"),
PROPERTY_ENTRY_REF("gpios", _bank_b_node, 123, GPIO_ACTIVE_LOW),
{ }
};

Signed-off-by: Dmitry Torokhov 
---

v1->v2:

- reworked code so that even single-entry reference properties are
  stored as arrays (i.e. the software_node_ref_args instances are
  not part of property_entry structure) to avoid size increase.
  From user's POV nothing is changed, one can still use PROPERTY_ENTRY_REF
  macro to define reference "inline".

- dropped unused DEV_PROP_MAX


 drivers/base/swnode.c| 43 ++--
 include/linux/property.h | 54 +---
 2 files changed, 74 insertions(+), 23 deletions(-)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index ee2a405cca9a..bd720d995123 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -387,6 +387,9 @@ static int property_entry_copy_data(struct property_entry 
*dst,
new = kstrdup(src->value.str, GFP_KERNEL);
if (!new && src->value.str)
return -ENOMEM;
+   } else if (src->type == DEV_PROP_REF) {
+   /* All reference properties must be arrays */
+   return -EINVAL;
} else {
new = pointer;
}
@@ -568,21 +571,45 @@ software_node_get_reference_args(const struct 
fwnode_handle *fwnode,
 {
struct swnode *swnode = to_swnode(fwnode);
const struct software_node_reference *ref;
+   const struct software_node_ref_args *ref_args;
const struct property_entry *prop;
struct fwnode_handle *refnode;
int i;
 
-   if (!swnode || !swnode->node->references)
+   if (!swnode)
return -ENOENT;
 
-   for (ref = swnode->node->references; ref->name; ref++)
-   if (!strcmp(ref->name, propname))
-   break;
+   prop = property_entry_get(swnode->node->properties, propname);
+   if (prop) {
+   if (prop->type != DEV_PROP_REF)
+   return -EINVAL;
 
-   if (!ref->name || index > (ref->nrefs - 1))
-   return -ENOENT;
+   /*
+* We expect all references to be stored as arrays via
+* a pointer, even single ones.
+*/
+   if (!prop->is_array)
+   return -EINVAL;
+
+   if (index * sizeof(*ref_args) >= prop->length)
+   return -ENOENT;
+
+   ref_args = >pointer.ref[index];
+   } else {
+   if (!swnode->node->references)
+   return -ENOENT;
+
+   for (ref = swnode->node->references; ref->name; ref++)
+   if (!strcmp(ref->name, propname))
+   break;
+
+   if (!ref->name || index > (ref->nrefs - 1))
+   return -ENOENT;
+
+   ref_args = >refs[index];
+   }
 
-   refnode = software_node_fwnode(ref->refs[index].node);
+   refnode = software_node_fwnode(ref_args->node);
if (!refnode)
return -ENOENT;
 
@@ -601,7 +628,7 @@ software_node_get_reference_args(const struct fwnode_handle 
*fwnode,
args->nargs = nargs;
 
for (i = 0; i < nargs; i++)
-   args->args[i] = ref->refs[index].args[i];
+   args->args[i] = ref_args->args[i];
 
return 0;
 }
diff --git a/include/linux/property.h b/include/linux/property.h
index 9b3d4ca3a73a..6658403f6fa9 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -22,7 +22,7 @@ enum dev_prop_type {
DEV_PROP_U32,
DEV_PROP_U64,
DEV_PROP_STRING,
-   DEV_PROP_MAX,
+   DEV_PROP_REF,
 };
 
 enum dev_dma_attr {
@@ -219,6 +219,20 @@ static inline int fwnode_property_count_u64(const struct 
fwnode_handle *fwnode,
return fwnode_property_read_u64_array(fwnode, propname, NULL, 0);
 }
 
+struct software_node;
+
+/**
+ * struct software_node_ref_args - Reference property with additional arguments
+ * @node: Reference to a software node
+ * @nargs: Number of elements in @args array
+ * @args: Integer arguments
+ */
+struct software_node_ref_args {
+   const struct software_node *node;
+   unsigned int nargs;
+   u64 args[NR_FWNODE_REFERENCE_ARGS];
+};
+
 /**
  * struct property_entry - "Built-in" device property representation.
  * @name: Name of the property.
@@ -240,6 +254,7 @@ struct property_entry {
const u32 *u32_data;
const u64 *u64_data;
const char * 

Re: [PATCH v2 2/2] clk: Add support for AST2600 SoC

[Stephen Boyd]

Quoting Joel Stanley (2019-08-25 07:18:48)
> The ast2600 is a new BMC SoC from ASPEED. It contains many more clocks
> than the previous iterations, so support is broken out into it's own
> driver.
> 
> Signed-off-by: Joel Stanley 
> ---

Applied to clk-next

Re: [PATCH v2 1/2] clk: aspeed: Move structures to header

[Stephen Boyd]

Quoting Joel Stanley (2019-08-25 07:18:47)
> They will be reused by the ast2600 driver.
> 
> Signed-off-by: Joel Stanley 
> ---

Applied to clk-next

Re: [PATCH] platform/chrome: wilco_ec: Add debugfs test_event file

[Nick Crews]

Thanks for the patch Daniel! A few thoughts that I didn't
have on the review on Gerrit, sorry :) After those changes,

Reviewed-by: Nick Crews 

On Fri, Sep 6, 2019 at 4:42 PM Daniel Campello  wrote:
>
> This change introduces a new debugfs file 'test_event' that when written
> to causes the EC to generate a test event.
>
> Signed-off-by: Daniel Campello 
> ---
>
>  drivers/platform/chrome/wilco_ec/debugfs.c | 33 +-
>  1 file changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/platform/chrome/wilco_ec/debugfs.c 
> b/drivers/platform/chrome/wilco_ec/debugfs.c
> index 8d65a1e2f1a3..2103c3ed8385 100644
> --- a/drivers/platform/chrome/wilco_ec/debugfs.c
> +++ b/drivers/platform/chrome/wilco_ec/debugfs.c
> @@ -160,29 +160,29 @@ static const struct file_operations fops_raw = {
>
>  #define CMD_KB_CHROME  0x88
>  #define SUB_CMD_H1_GPIO0x0A
> +#define SUB_CMD_TEST_EVENT 0x0B
>
> -struct h1_gpio_status_request {
> +struct ec_request {
> u8 cmd; /* Always CMD_KB_CHROME */
> u8 reserved;
> u8 sub_cmd; /* Always SUB_CMD_H1_GPIO */

This comment should be removed.

>  } __packed;
>
> -struct hi_gpio_status_response {
> +struct ec_response {
> u8 status;  /* 0 if allowed */
> u8 val; /* BIT(0)=ENTRY_TO_FACT_MODE, BIT(1)=SPI_CHROME_SEL */

This comment should be moved to h1_gpio_get().

>  } __packed;
>
> -static int h1_gpio_get(void *arg, u64 *val)
> +static int write_to_mailbox(struct wilco_ec_device *ec, u8 sub_cmd, u64 *val)

What about send_ec_cmd() or similar? Something that communicates that
we are sometimes telling the EC to do something, and sometimes reading something
back. Also, since we are adding in another layer in here, we can fix
the signature from
the one required by a debugfs attribute. Use "ret" instead of "val"
and make it a u8*.

>  {
> -   struct wilco_ec_device *ec = arg;
> -   struct h1_gpio_status_request rq;
> -   struct hi_gpio_status_response rs;
> +   struct ec_request rq;
> +   struct ec_response rs;
> struct wilco_ec_message msg;
> int ret;
>
> memset(, 0, sizeof(rq));
> rq.cmd = CMD_KB_CHROME;
> -   rq.sub_cmd = SUB_CMD_H1_GPIO;
> +   rq.sub_cmd = sub_cmd;
>
> memset(, 0, sizeof(msg));
> msg.type = WILCO_EC_MSG_LEGACY;
> @@ -201,8 +201,25 @@ static int h1_gpio_get(void *arg, u64 *val)
> return 0;
>  }
>
> +static int h1_gpio_get(void *arg, u64 *val)
> +{
> +   return write_to_mailbox(arg, SUB_CMD_H1_GPIO, val);
> +}
> +
>  DEFINE_DEBUGFS_ATTRIBUTE(fops_h1_gpio, h1_gpio_get, NULL, "0x%02llx\n");
>

A one line comment as to what test_event does?

> +static int test_event_set(void *arg, u64 val)
> +{
> +   u64 ret;
> +
> +   return write_to_mailbox(arg, SUB_CMD_TEST_EVENT, );
> +}
> +
> +/* Format set to NULL since it is only used on read operations which are
> + * forbidden by file permissions.
> + */
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_test_event, NULL, test_event_set, NULL);
> +
>  /**
>   * wilco_ec_debugfs_probe() - Create the debugfs node
>   * @pdev: The platform device, probably created in core.c
> @@ -226,6 +243,8 @@ static int wilco_ec_debugfs_probe(struct platform_device 
> *pdev)
> debugfs_create_file("raw", 0644, debug_info->dir, NULL, _raw);
> debugfs_create_file("h1_gpio", 0444, debug_info->dir, ec,
> _h1_gpio);
> +   debugfs_create_file("test_event", 0200, debug_info->dir, ec,
> +   _test_event);
>
> return 0;
>  }
> --
> 2.23.0.162.g0b9fbb3734-goog
>

Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism

[Ming Lei]

On Fri, Sep 06, 2019 at 05:50:49PM +, Long Li wrote:
> >Subject: Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism
> >
> >On Fri, Sep 06, 2019 at 09:48:21AM +0800, Ming Lei wrote:
> >> When one IRQ flood happens on one CPU:
> >>
> >> 1) softirq handling on this CPU can't make progress
> >>
> >> 2) kernel thread bound to this CPU can't make progress
> >>
> >> For example, network may require softirq to xmit packets, or another
> >> irq thread for handling keyboards/mice or whatever, or rcu_sched may
> >> depend on that CPU for making progress, then the irq flood stalls the
> >> whole system.
> >>
> >> >
> >> > AFAIU, there are fast medium where the responses to requests are
> >> > faster than the time to process them, right?
> >>
> >> Usually medium may not be faster than CPU, now we are talking about
> >> interrupts, which can be originated from lots of devices concurrently,
> >> for example, in Long Li'test, there are 8 NVMe drives involved.
> >
> >Why are all 8 nvmes sharing the same CPU for interrupt handling?
> >Shouldn't matrix_find_best_cpu_managed() handle selecting the least used
> >CPU from the cpumask for the effective interrupt handling?
> 
> The tests run on 10 NVMe disks on a system of 80 CPUs. Each NVMe disk has 32 
> hardware queues.

Then there are total 320 NVMe MSI/X vectors, and 80 CPUs, so irq matrix
can't avoid effective CPUs overlapping at all.

> It seems matrix_find_best_cpu_managed() has done its job, but we may still 
> have CPUs that service several hardware queues mapped from other issuing CPUs.
> Another thing to consider is that there may be other managed interrupts on 
> the system, so NVMe interrupts may not end up evenly distributed on such a 
> system.

Another improvement could be to try to not overlap effective CPUs among
vectors of fast device first, meantime allow the overlap between slow
vectors and fast vectors.

This way could improve in case that total fast vectors are <= nr_cpu_cores.

thanks,
Ming

Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()

[Aleksa Sarai]

On 2019-09-07, Aleksa Sarai  wrote:
> On 2019-09-06, Jeff Layton  wrote:
> > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > On 2019-09-06, Jeff Layton  wrote:
> > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > > Let's assume I want to add support for this to the glibc dynamic 
> > > > > > loader,
> > > > > > while still being able to run on older kernels.
> > > > > > 
> > > > > > Is it safe to try the open call first, with O_MAYEXEC, and if that 
> > > > > > fails
> > > > > > with EINVAL, try again without O_MAYEXEC?
> > > > > 
> > > > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > > > > older kernel to use O_MAYEXEC.
> > > > > 
> > > > 
> > > > Well...maybe. What about existing programs that are sending down bogus
> > > > open flags? Once you turn this on, they may break...or provide a way to
> > > > circumvent the protections this gives.
> > > 
> > > It should be noted that this has been a valid concern for every new O_*
> > > flag introduced (and yet we still introduced new flags, despite the
> > > concern) -- though to be fair, O_TMPFILE actually does have a
> > > work-around with the O_DIRECTORY mask setup.
> > > 
> > > The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> > > backwards compatible because empty path strings have always given ENOENT
> > > (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> > > 
> > > > Maybe this should be a new flag that is only usable in the new openat2()
> > > > syscall that's still under discussion? That syscall will enforce that
> > > > all flags are recognized. You presumably wouldn't need the sysctl if you
> > > > went that route too.
> > > 
> > > I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> > > how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> > > it, since I'd heard about this work through the grape-vine).
> > > 
> > 
> > I rather like the idea of having openat2 fds be non-executable by
> > default, and having userland request it specifically via O_MAYEXEC (or
> > some similar openat2 flag) if it's needed. Then you could add an
> > UPGRADE_EXEC flag instead?
> > 
> > That seems like something reasonable to do with a brand new API, and
> > might be very helpful for preventing certain classes of attacks.
> 
> In that case, maybe openat2(2) should default to not allowing any
> upgrades by default? The reason I pitched UPGRADE_NOEXEC is because
> UPGRADE_NO{READ,WRITE} are the existing @how->upgrade_mask flags.

Sorry, another issue is that there isn't a current way to really
restrict fexecve() permissions (from my [limited] understanding,
__FMODE_EXEC isn't the right thing to use) -- so we can't blanket block
exec through openat2() O_PATH descriptors and add UPGRADE_EXEC later.

We would have to implement FMODE_EXEC (and FMODE_MAP_EXEC as you
suggested) in order to implement FMODE_UPGRADE_EXEC before we could even
get a first version of openat2(2) in. Though, I do (a little
begrudgingly) agree that we should have a safe default if possible
(magical O_PATH reopening trickery is something that most people don't
know about and probably wouldn't want to happen if they did).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

Re: [RFC PATCH v3 00/16] Core scheduling v3

[Tim Chen]

On 9/4/19 6:44 PM, Julien Desfossez wrote:


>@@ -3853,7 +3880,7 @@ pick_next_task(struct rq *rq, struct task_struct *prev, 
>struct rq_flags *rf)
>   goto done;
>   }
> 
>-  if (!is_idle_task(p))
>+  if (!is_force_idle_task(p))

Should this be  if (!is_core_idle_task(p))
instead?

>   occ++;
> 


Tim

Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()

[Aleksa Sarai]

On 2019-09-06, Jeff Layton  wrote:
> On Fri, 2019-09-06 at 13:06 -0700, Andy Lutomirski wrote:
> > > On Sep 6, 2019, at 12:43 PM, Jeff Layton  wrote:
> > > 
> > > > On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > > > > On 2019-09-06, Jeff Layton  wrote:
> > > > > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > > > Let's assume I want to add support for this to the glibc dynamic 
> > > > > > > loader,
> > > > > > > while still being able to run on older kernels.
> > > > > > > 
> > > > > > > Is it safe to try the open call first, with O_MAYEXEC, and if 
> > > > > > > that fails
> > > > > > > with EINVAL, try again without O_MAYEXEC?
> > > > > > 
> > > > > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > > > > > older kernel to use O_MAYEXEC.
> > > > > > 
> > > > > 
> > > > > Well...maybe. What about existing programs that are sending down bogus
> > > > > open flags? Once you turn this on, they may break...or provide a way 
> > > > > to
> > > > > circumvent the protections this gives.
> > > > 
> > > > It should be noted that this has been a valid concern for every new O_*
> > > > flag introduced (and yet we still introduced new flags, despite the
> > > > concern) -- though to be fair, O_TMPFILE actually does have a
> > > > work-around with the O_DIRECTORY mask setup.
> > > > 
> > > > The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> > > > backwards compatible because empty path strings have always given ENOENT
> > > > (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> > > > 
> > > > > Maybe this should be a new flag that is only usable in the new 
> > > > > openat2()
> > > > > syscall that's still under discussion? That syscall will enforce that
> > > > > all flags are recognized. You presumably wouldn't need the sysctl if 
> > > > > you
> > > > > went that route too.
> > > > 
> > > > I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> > > > how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> > > > it, since I'd heard about this work through the grape-vine).
> > > > 
> > > 
> > > I rather like the idea of having openat2 fds be non-executable by
> > > default, and having userland request it specifically via O_MAYEXEC (or
> > > some similar openat2 flag) if it's needed. Then you could add an
> > > UPGRADE_EXEC flag instead?
> > > 
> > > That seems like something reasonable to do with a brand new API, and
> > > might be very helpful for preventing certain classes of attacks.
> > > 
> > > 
> > 
> > There are at least four concepts of executability here:
> > 
> > - Just check the file mode and any other relevant permissions. Return a 
> > normal fd.  Makes sense for script interpreters, perhaps.
> > 
> > - Make the fd fexecve-able.
> > 
> > - Make the resulting fd mappable PROT_EXEC.
> > 
> > - Make the resulting fd upgradable.
> > 
> > I’m not at all convinced that the kernel needs to distinguish all these, 
> > but at least upgradability should be its own thing IMO.
> 
> Good point. Upgradability is definitely orthogonal, though the idea
> there is to alter the default behavior. If the default is NOEXEC then
> UPGRADE_EXEC would make sense.
> 
> In any case, I was mostly thinking about the middle two in your list
> above. After more careful reading of the patches, I now get get that
> Mickaël is more interested in the first, and that's really a different
> sort of use-case.
> 
> Most opens never result in the fd being fed to fexecve or mmapped with
> PROT_EXEC, so having userland explicitly opt-in to allowing that during
> the open sounds like a reasonable thing to do.
> 
> But I get that preventing execution via script interpreters of files
> that are not executable might be something nice to have.

My first glance at the patch lead me to believe that this was about
blocking at fexecve()-time (which was what my first attempt at this
problem looked like) -- hence why I mentioned the upgrade_mask stuff
(because of the dances you can do with O_PATH, if blocking at
fexecve()-time was the goal then you seriously do need the upgrade_mask
and "O_PATH mask" in order for it to be even slightly secure).

But I also agree this is useful, and we can always add FMODE_EXEC,
FMODE_MAP_EXEC, and FMODE_UPGRADE_EXEC (and the related bits) at a later
date.

> Perhaps we need two flags for openat2?
> 
> OA2_MAYEXEC : test that permissions allow execution and that the file
> doesn't reside on a noexec mount before allowing the open
> 
> OA2_EXECABLE : only allow fexecve or mmapping with PROT_EXEC if the fd
> was opened with this

That seems reasonable to me. The only thing is that there currently
isn't any code to restrict fexecve() or PROT_EXEC in that fashion
(doubly so when you consider binfmt_script). So if we want to make
certain things default behaviour (such as disallowing exec by default)
we'd need to get the PROT_EXEC restriction work 

Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()

[Aleksa Sarai]

On 2019-09-06, Jeff Layton  wrote:
> On Sat, 2019-09-07 at 03:13 +1000, Aleksa Sarai wrote:
> > On 2019-09-06, Jeff Layton  wrote:
> > > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
> > > > On 06/09/2019 17:56, Florian Weimer wrote:
> > > > > Let's assume I want to add support for this to the glibc dynamic 
> > > > > loader,
> > > > > while still being able to run on older kernels.
> > > > > 
> > > > > Is it safe to try the open call first, with O_MAYEXEC, and if that 
> > > > > fails
> > > > > with EINVAL, try again without O_MAYEXEC?
> > > > 
> > > > The kernel ignore unknown open(2) flags, so yes, it is safe even for
> > > > older kernel to use O_MAYEXEC.
> > > > 
> > > 
> > > Well...maybe. What about existing programs that are sending down bogus
> > > open flags? Once you turn this on, they may break...or provide a way to
> > > circumvent the protections this gives.
> > 
> > It should be noted that this has been a valid concern for every new O_*
> > flag introduced (and yet we still introduced new flags, despite the
> > concern) -- though to be fair, O_TMPFILE actually does have a
> > work-around with the O_DIRECTORY mask setup.
> > 
> > The openat2() set adds O_EMPTYPATH -- though in fairness it's also
> > backwards compatible because empty path strings have always given ENOENT
> > (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings.
> > 
> > > Maybe this should be a new flag that is only usable in the new openat2()
> > > syscall that's still under discussion? That syscall will enforce that
> > > all flags are recognized. You presumably wouldn't need the sysctl if you
> > > went that route too.
> > 
> > I'm also interested in whether we could add an UPGRADE_NOEXEC flag to
> > how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for
> > it, since I'd heard about this work through the grape-vine).
> > 
> 
> I rather like the idea of having openat2 fds be non-executable by
> default, and having userland request it specifically via O_MAYEXEC (or
> some similar openat2 flag) if it's needed. Then you could add an
> UPGRADE_EXEC flag instead?
> 
> That seems like something reasonable to do with a brand new API, and
> might be very helpful for preventing certain classes of attacks.

In that case, maybe openat2(2) should default to not allowing any
upgrades by default? The reason I pitched UPGRADE_NOEXEC is because
UPGRADE_NO{READ,WRITE} are the existing @how->upgrade_mask flags.

However, I just noticed something else about this series -- if you do
O_PATH|O_MAYEXEC the new flag gets ignored. Given that you can do
fexecve(2) on an O_PATH (and O_PATHs have some other benefits), is this
something that we'd want to have?

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

Re: [PATCH 2/2] clk: Add support for AST2600 SoC

[Stephen Boyd]

Quoting Joel Stanley (2019-08-18 19:03:54)
> On Fri, 16 Aug 2019 at 17:14, Stephen Boyd  wrote:
> >
> > Quoting Joel Stanley (2019-08-16 08:58:06)
> > > +static const char * const vclk_parent_names[] = {
> >
> > Can you use the new way of specifying clk parents instead of just using
> > strings?
> 
> How does this work? I had a browse of the APIs in clk-provider.h and
> it appeared the functions all take char *s still.

Sorry I didn't reply earlier. I'm going to write a kernel-doc to
describe how to write a "modern" clk driver which should hopefully help
here.

The gist is that you can fill out a clk_parent_data array or a clk_hw
array and set the .name and .fw_name and .index in the clk_parent_data
array to indicate which clks to get from the DT node's "clocks" and
"clock-names" properties.

> 
> > > +   hw = clk_hw_register_fixed_factor(NULL, "ahb", "hpll", 0, 1, 
> > > axi_div * ahb_div);

Take this one for example. If 'hpll' is actually a clk_hw pointer in
hand, then you could do something like:

clk_hw_register_fixed_factor_parent_hw(NULL, "ahb", , 0, 1, 
axi_div * ahb_div);

And if it's something like a clock from DT you could do

struct clk_parent_data pdata = {
.name = "hpll",
.fw_name = ,
.index = 
};

clk_hw_register_fixed_factor_parent_data(NULL, "ahb", , 0, 1, 
axi_div * ahb_div);

I haven't actually written the clk_hw_register_fixed_factor_*() APIs,
because I'm thinking that it would be better to register the pdata with
some more parameters so that the
clk_hw_register_fixed_factor_parent_data() API becomes more like:

clk_hw_register_fixed_factor_parent_data(NULL, "ahb", "hpll",
, , 0, 1,
axi_div * ahb_div);

Because there's only one parent. For the mux clk it will be a pointer to
parent_data because I don't see a way around it.

> >
> > There aren't checks for if these things fail. I guess it doesn't matter
> > and just let it fail hard?
> 
> I think that's sensible here. If the system has run out of memory this
> early on then there's not going to be much that works.
> 
> Thanks for the review. I've fixed all of the style issues you
> mentioned, but would appreciate some guidance on the parent API.
> 

Cool! Thanks.

Re: [PATCH] gpio/mpc8xxx: change irq handler from chained to normal

[Li Yang]

On Fri, Sep 6, 2019 at 10:20 AM Hui Song  wrote:
>
> From: Song Hui 
>

The English below need to be fixed.

> more one gpio controller use share one interrupt,
> make request interrupt to be shared.

More than one gpio controllers can share one interrupt, change the
driver to request shared irq.

>
> Signed-off-by: Laurentiu Tudor 
> Signed-off-by: Alex Marginean 
> Signed-off-by: Song Hui 
> ---
>  drivers/gpio/gpio-mpc8xxx.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
> index 16a47de..4006250 100644
> --- a/drivers/gpio/gpio-mpc8xxx.c
> +++ b/drivers/gpio/gpio-mpc8xxx.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #define MPC8XXX_GPIO_PINS  32
>
> @@ -127,10 +128,9 @@ static int mpc8xxx_gpio_to_irq(struct gpio_chip *gc, 
> unsigned offset)
> return -ENXIO;
>  }
>
> -static void mpc8xxx_gpio_irq_cascade(struct irq_desc *desc)
> +static irqreturn_t mpc8xxx_gpio_irq_cascade(int irq, void *data)
>  {
> -   struct mpc8xxx_gpio_chip *mpc8xxx_gc = 
> irq_desc_get_handler_data(desc);
> -   struct irq_chip *chip = irq_desc_get_chip(desc);
> +   struct mpc8xxx_gpio_chip *mpc8xxx_gc = (struct mpc8xxx_gpio_chip 
> *)data;
> struct gpio_chip *gc = _gc->gc;
> unsigned int mask;
>
> @@ -139,8 +139,8 @@ static void mpc8xxx_gpio_irq_cascade(struct irq_desc 
> *desc)
> if (mask)
> generic_handle_irq(irq_linear_revmap(mpc8xxx_gc->irq,
>  32 - ffs(mask)));
> -   if (chip->irq_eoi)
> -   chip->irq_eoi(>irq_data);
> +
> +   return IRQ_HANDLED;
>  }
>
>  static void mpc8xxx_irq_unmask(struct irq_data *d)
> @@ -409,8 +409,14 @@ static int mpc8xxx_probe(struct platform_device *pdev)
> if (devtype->gpio_dir_in_init)
> devtype->gpio_dir_in_init(gc);
>
> -   irq_set_chained_handler_and_data(mpc8xxx_gc->irqn,
> -mpc8xxx_gpio_irq_cascade, 
> mpc8xxx_gc);
> +   ret = request_irq(mpc8xxx_gc->irqn, mpc8xxx_gpio_irq_cascade,
> +   IRQF_NO_THREAD | IRQF_SHARED, "gpio-cascade", mpc8xxx_gc);
> +   if (ret) {
> +   pr_err("%s: failed to request_irq(%d), ret = %d\n",
> +   np->full_name, mpc8xxx_gc->irqn, ret);
> +   goto err;
> +   }
> +
> return 0;
>  err:
> iounmap(mpc8xxx_gc->regs);
> --
> 2.9.5
>

Re: [PATCH net-next 3/3] net: dsa: microchip: remove NET_DSA_TAG_KSZ_COMMON

[Marek Vasut]

On 9/6/19 11:30 PM, George McCollister wrote:
> Remove the superfluous NET_DSA_TAG_KSZ_COMMON and just use the existing
> NET_DSA_TAG_KSZ. Update the description to mention the three switch
> families it supports. No functional change.
> 
> Signed-off-by: George McCollister 

Reviewed-by: Marek Vasut 

-- 
Best regards,
Marek Vasut

Re: [PATCH net-next 2/3] net: dsa: microchip: add ksz9567 to ksz9477 driver

[Marek Vasut]

On 9/6/19 11:30 PM, George McCollister wrote:
> Add support for the KSZ9567 7-Port Gigabit Ethernet Switch to the
> ksz9477 driver. The KSZ9567 supports both SPI and I2C. Oddly the
> ksz9567 is already in the device tree binding documentation.
> 
> Signed-off-by: George McCollister 
> ---
>  drivers/net/dsa/microchip/ksz9477.c | 9 +
>  drivers/net/dsa/microchip/ksz9477_i2c.c | 1 +
>  drivers/net/dsa/microchip/ksz9477_spi.c | 1 +
>  3 files changed, 11 insertions(+)
> 
> diff --git a/drivers/net/dsa/microchip/ksz9477.c 
> b/drivers/net/dsa/microchip/ksz9477.c
> index 187be42de5f1..50ffc63d6231 100644
> --- a/drivers/net/dsa/microchip/ksz9477.c
> +++ b/drivers/net/dsa/microchip/ksz9477.c
> @@ -1529,6 +1529,15 @@ static const struct ksz_chip_data 
> ksz9477_switch_chips[] = {
>   .cpu_ports = 0x07,  /* can be configured as cpu port */
>   .port_cnt = 3,  /* total port count */
>   },
> + {
> + .chip_id = 0x00956700,
> + .dev_name = "KSZ9567",
> + .num_vlans = 4096,
> + .num_alus = 4096,
> + .num_statics = 16,
> + .cpu_ports = 0x7F,  /* can be configured as cpu port */
> + .port_cnt = 7,  /* total physical port count */

I might be wrong, and this is just an idea for future improvement, but
is .cpu_ports = GEN_MASK(.port_cnt, 0) always ?

> + },
>  };
>  
>  static int ksz9477_switch_init(struct ksz_device *dev)
> diff --git a/drivers/net/dsa/microchip/ksz9477_i2c.c 
> b/drivers/net/dsa/microchip/ksz9477_i2c.c
> index 85fd0fb43941..c1548a43b60d 100644
> --- a/drivers/net/dsa/microchip/ksz9477_i2c.c
> +++ b/drivers/net/dsa/microchip/ksz9477_i2c.c
> @@ -77,6 +77,7 @@ MODULE_DEVICE_TABLE(i2c, ksz9477_i2c_id);
>  static const struct of_device_id ksz9477_dt_ids[] = {
>   { .compatible = "microchip,ksz9477" },
>   { .compatible = "microchip,ksz9897" },
> + { .compatible = "microchip,ksz9567" },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, ksz9477_dt_ids);
> diff --git a/drivers/net/dsa/microchip/ksz9477_spi.c 
> b/drivers/net/dsa/microchip/ksz9477_spi.c
> index 2e402e4d866f..f4198d6f72be 100644
> --- a/drivers/net/dsa/microchip/ksz9477_spi.c
> +++ b/drivers/net/dsa/microchip/ksz9477_spi.c
> @@ -81,6 +81,7 @@ static const struct of_device_id ksz9477_dt_ids[] = {
>   { .compatible = "microchip,ksz9893" },
>   { .compatible = "microchip,ksz9563" },
>   { .compatible = "microchip,ksz8563" },
> + { .compatible = "microchip,ksz9567" },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, ksz9477_dt_ids);
> 

Reviewed-by: Marek Vasut 

-- 
Best regards,
Marek Vasut

Re: [PATCH net-next 1/3] net: dsa: microchip: add KSZ9477 I2C driver

[Marek Vasut]

On 9/6/19 11:30 PM, George McCollister wrote:

[...]

> --- /dev/null
> +++ b/drivers/net/dsa/microchip/ksz9477_i2c.c
> @@ -0,0 +1,100 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Microchip KSZ9477 series register access through I2C
> + *
> + * Copyright (C) 2018-2019 Microchip Technology Inc.

Doesn't the copyright need update ?

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 

Please keep the headers sorted.

> +#include "ksz_common.h"
> +
> +KSZ_REGMAP_TABLE(ksz9477, not_used, 16, 0, 0);
> +

The rest looks good.

[...]

-- 
Best regards,
Marek Vasut

Re: [PATCH 02/11] mmc: dw_mmc: Re-store SDIO IRQs mask at system resume

[Doug Anderson]

Hi,

On Fri, Sep 6, 2019 at 2:20 AM Ulf Hansson  wrote:
>
> On Fri, 6 Sep 2019 at 01:47, Doug Anderson  wrote:
> >
> > Hi,
> >
> > On Tue, Sep 3, 2019 at 7:22 AM Ulf Hansson  wrote:
> > >
> > > In cases when SDIO IRQs have been enabled, runtime suspend is prevented by
> > > the driver. However, this still means dw_mci_runtime_suspend|resume() gets
> > > called during system suspend/resume, via 
> > > pm_runtime_force_suspend|resume().
> > > This means during system suspend/resume, the register context of the 
> > > dw_mmc
> > > device most likely loses its register context, even in cases when SDIO 
> > > IRQs
> > > have been enabled.
> >
> > Even if they weren't lost the resume code currently has this statement:
> >
> > mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
> >SDMMC_INT_TXDR | SDMMC_INT_RXDR |
> >DW_MCI_ERROR_FLAGS);
> >
> > ...so that would have clobbered any existing state even if register
> > state wasn't lost.  ;-)
> >
> > > To re-enable the SDIO IRQs during system resume, the dw_mmc driver
> > > currently relies on the mmc core to re-enable the SDIO IRQs when it 
> > > resumes
> > > the SDIO card, but this isn't the recommended solution. Instead, it's
> > > better to deal with this locally in the dw_mmc driver, so let's do that.
> > >
> > > Signed-off-by: Ulf Hansson 
> > > ---
> > >  drivers/mmc/host/dw_mmc.c | 4 
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> > > index eea52e2c5a0c..f114710e82b4 100644
> > > --- a/drivers/mmc/host/dw_mmc.c
> > > +++ b/drivers/mmc/host/dw_mmc.c
> > > @@ -3460,6 +3460,10 @@ int dw_mci_runtime_resume(struct device *dev)
> > > /* Force setup bus to guarantee available clock output */
> > > dw_mci_setup_bus(host->slot, true);
> > >
> > > +   /* Re-enable SDIO interrupts. */
> > > +   if (sdio_irq_enabled(host->slot->mmc))
> > > +   __dw_mci_enable_sdio_irq(host->slot, 1);
> > > +
> >
> > There's a slight bit of subtleness here and I guess we need to figure
> > out if it matters.  From testing things seem to work OK so maybe we're
> > fine, but just to explain what's bugging me:
> >
> > If we got an SDIO interrupt that was never ACKed then this is going to
> > act like an implicit ACK.  Notice that dw_mci_ack_sdio_irq() is
> > exactly this call because when the SDIO IRQ fires we mask it out.
> > ...then unmask when Acked.
> >
> > Specifically after your series is applied, I think this is what
> > happens if an interrupt fires while the SDIO bus is officially
> > suspended:
> >
> > 1. dw_mci_interrupt() will get called which will mask the SDIO IRQ and
> > then call sdio_signal_irq()
> >
> > 2. sdio_signal_irq() will queue some delayed work.
> >
> > 3. The work will call sdio_run_irqs()
> >
> > 4. sdio_run_irqs() _won't_ ack the IRQ, so it will stay disabled.
> >
> > 5. When we get to the resume we'll re-enable the interrupt.
>
> Correct.
>
> >
> > I guess that's fine, but it is a little weird that we might not really
> > be restoring it simply because it got disabled due to the clobbering
> > of INTMASK but also because we implicitly skipped Acking an interrupt
> > that fired.
>
> Let me comment on that, because there is actually two cases that are
> relevant here to be covered.
>
> 1. After the SDIO card has been system suspended, sdio_run_irqs()
> doesn't call the ->ack_sdio_irq() callback, as to prevents the host
> driver from re-enabling the SDIO irq (acking). This is to avoid the
> host from re-signalling the same SDIO IRQ over and over again when the
> SDIO card is suspended.
>
> 2. Dealing with the SDIO IRQ bit-mask when the host driver system
> suspends/resumes. This is host specific, but a common behavior is that
> the driver can't allow any IRQ to be managed by its IRQ handler in a
> suspended state. This is because the device (MMC controller) may be
> put into a low power state (no clocks enabled, register context is
> lost and not accessible, etc), which makes the device non-functional.

Yeah, if you look at dw_mci_runtime_suspend() you can actually see
that (at least in many cases) we actually disable the "BIU" clock.  I
believe this fully turns the clock off the controller and it can't
fire interrupts.

If I remember correctly the problem I actually saw before was that the
moment we turned the BIU back on in resume the SDIO interrupt fired.
:-P


> > I wonder if the correct fix is to just add an explit zeroing of the
> > INTMASK (so mask all interrupts) in dw_mmc's suspend callback.  Then
> > there's no possible way we could get an interrupt during suspend...
>
> Exactly. Other host drivers do this as well.
>
> Although note that the host device gets system suspended after the
> sdio card device, so there is still a window when an SDIO IRQ can be
> signaled. This is covered by 1) above.
>
> Also note that, in general it also depends on whether there is wakeup
> IRQ configured and how that wakeup might be 

RE: [Patch v4] storvsc: setup 1:1 mapping between hardware queue and CPU queue

[Long Li]

>Subject: Re: [Patch v4] storvsc: setup 1:1 mapping between hardware queue
>and CPU queue
>
>On Fri, Sep 06, 2019 at 10:24:20AM -0700, lon...@linuxonhyperv.com wrote:
>>From: Long Li 
>>
>>storvsc doesn't use a dedicated hardware queue for a given CPU queue.
>>When issuing I/O, it selects returning CPU (hardware queue) dynamically
>>based on vmbus channel usage across all channels.
>>
>>This patch advertises num_present_cpus() as number of hardware queues.
>>This will have upper layer setup 1:1 mapping between hardware queue and
>>CPU queue and avoid unnecessary locking when issuing I/O.
>>
>>Signed-off-by: Long Li 
>>---
>>
>>Changes:
>>v2: rely on default upper layer function to map queues. (suggested by
>>Ming Lei
>>)
>>v3: use num_present_cpus() instead of num_online_cpus(). Hyper-v
>>doesn't support hot-add CPUs. (suggested by Michael Kelley
>>)
>>v4: move change logs to after Signed-of-by
>>
>> drivers/scsi/storvsc_drv.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>>diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
>>index b89269120a2d..cf987712041a 100644
>>--- a/drivers/scsi/storvsc_drv.c
>>+++ b/drivers/scsi/storvsc_drv.c
>>@@ -1836,8 +1836,7 @@ static int storvsc_probe(struct hv_device *device,
>>  /*
>>   * Set the number of HW queues we are supporting.
>>   */
>>- if (stor_device->num_sc != 0)
>>- host->nr_hw_queues = stor_device->num_sc + 1;
>>+ host->nr_hw_queues = num_present_cpus();
>
>Just looking at the change notes for v3: why isn't this
>num_active_cpus() then? One can still isolate CPUs on hyper-v, no?

The isolated CPU can be made online at run time. For example, even maxcpus=x is 
put on the boot line, individual CPUs can still be made online/offline.

>
>--
>Thanks,
>Sasha