Re: [PATCH 1/1] tg3: fix meaningless hw_stats reading after tg3_halt memset 0 hw_stats

[Zumeng Chen]

On 2018年04月29日 02:36, Michael Chan wrote:

On Fri, Apr 27, 2018 at 8:15 PM, Zumeng Chen  wrote:


diff --git a/drivers/net/ethernet/broadcom/tg3.h 
b/drivers/net/ethernet/broadcom/tg3.h
index 3b5e98e..6727d93 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -3352,6 +3352,7 @@ struct tg3 {
 struct pci_dev  *pdev_peer;

 struct tg3_hw_stats *hw_stats;
+   boolhw_stats_flag;

You can just add another bit to enum TG3_FLAGS for this purpose.


Right, it's a good idea, I didn't notice it, I'll send V2 with that later.



While this scheme will probably work, I think a better and more
elegant way to fix this is to use RCU.


IMHO, RCU is not necessary for this simple two consumers, and no 
frequent ops

on tg3_halt, plus no new locker involved either.

Cheers,
Zumeng



 dma_addr_t  stats_mapping;
 struct work_struct  reset_task;

--
2.9.3

Re: [PATCH v2 0/6] arm64: provide pseudo NMI with GICv3

[Joel Fernandes]

On Wed, Jan 17, 2018 at 4:10 AM, Julien Thierry  wrote:
> Hi,
>
> On 17/01/18 11:54, Julien Thierry wrote:
>>
>> This series is a continuation of the work started by Daniel [1]. The goal
>> is to use GICv3 interrupt priorities to simulate an NMI.
>>
>
>
> I have submitted a separate series making use of this feature for the ARM
> PMUv3 interrupt [1].

I guess the hard lockup detector using NMI could be a nice next step
to see how well it works with lock up detection. That's the main
usecase for my interest. However, perf profiling is also a strong one.

thanks,

- Joel

Re: [PATCH v2 0/6] arm64: provide pseudo NMI with GICv3

[Joel Fernandes]

Hi Julien,

I am interested in evaluating if using this is feasible for our
Android devices. There is quite a usecase for lockup detection that it
seems worthwhile if it works well. Atleast I feel this can be used a
debug option considering the performance downgrade.

Do you have more details of if any GICv3 based system will work, or is
there a way an SoC can be misconfigured so that this series will not
work? I think Marc told me that's possible, but I wasn't sure. I will
be quite happy if it works on SoC as long as they have the requisite
GIC version.

Some more questions below:

On Wed, Jan 17, 2018 at 3:54 AM, Julien Thierry  wrote:
> Hi,
>
> This series is a continuation of the work started by Daniel [1]. The goal
> is to use GICv3 interrupt priorities to simulate an NMI.
>
> To achieve this, set two priorities, one for standard interrupts and
> another, higher priority, for NMIs. Whenever we want to disable interrupts,
> we mask the standard priority instead so NMIs can still be raised. Some
> corner cases though still require to actually mask all interrupts
> effectively disabling the NMI.
>
> Of course, using priority masking instead of PSR.I comes at some cost. On
> hackbench, the drop of performance seems to be >1% on average for this
> version. I can only attribute that to recent changes in the kernel as

Do you have more specific performance data on the performance overhead
with this series?

> hackbench seems slightly slower compared to my other benchmarks while the
> runs with the use of GICv3 priorities have stayed in the same time frames.
> KVM Guests do not seem to be affected preformance-wise by the host using
> PMR to mask interrupts or not.
>
> Currently, only PPIs and SPIs can be set as NMIs. IPIs being currently
> hardcoded IRQ numbers, there isn't a generic interface to set SGIs as NMI
> for now. I don't think there is any reason LPIs should be allowed to be set
> as NMI as they do not have an active state.
> When an NMI is active on a CPU, no other NMI can be triggered on the CPU.
>
>
> Requirements to use this:
> - Have GICv3
> - SCR_EL3.FIQ is set to 1 when linux runs

Ah I see it mentioned here. Again, can you clarify if this is
something that can be misconfigured? Is it something that the
bootloader sets?

Sorry if these questions sound premature, I haven't yet taken a closer
look at the series.

thanks,

- Joel

Re: [PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation

[Thierry Reding]

On Fri, Apr 27, 2018 at 03:59:56PM -0700, Wesley W. Terpstra wrote:
> Document new PWM device tree bindings for SiFive SoCs.
> 
> Signed-off-by: Wesley W. Terpstra 
> ---
>  .../devicetree/bindings/pwm/pwm-sifive.txt | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> 
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt 
> b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> new file mode 100644
> index 000..7cea20d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
> @@ -0,0 +1,28 @@
> +SiFive PWM controller
> +
> +Unlike most other PWM controllers, the SiFive PWM controller currently only
> +supports one period for all channels in the PWM. This is set globally in DTS.
> +The period also has significant restrictions on the values it can achieve,
> +which the driver rounds to the nearest achievable frequency.

How about you encode this in the driver rather than DT? We have several
drivers with similar restrictions and they usually allow the first PWM
channel to choose an arbitrary period and return an error if subsequent
channels request a period that can't be supported.

I think something similar could work with that second restriction. Why
not return an error if the exact period can't be set? Or perhaps allow
some percentage of deviation.

If the exact period is achieved in a deterministic way, it should be
possible for board designers to specify it exactly, so the consumer's
pwms property can simply take the correct period.

> +Required properties:
> +- compatible: should be "sifive,pwm0"

Why not simply "sifive,pwm"? If this is supposed to be some sort of
version number, then it is more customary to use the name of the first
SoC that integrates the IP. There are some exceptions, like for example
when the IP is third-party and is integrated in a number of different
SoCs. In such cases the IP is often properly versioned. But that doesn't
seem to be the case here.

Thierry


signature.asc
Description: PGP signature

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Greg Kroah-Hartman]

On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote:
> Hi,
> 
> Due to some maintainers *preferring* BSD-compatible license for DTS
> files [0], I was writing mine using ISC. I had no very special reason
> for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
> ISC as I read about its "removal of language deemed unnecessary".
> 
> I took a moment to look at the new SPDX thing and noticed that:
> 1) File license-rules.rst provides "LICENSES/other/ISC" as an example

Yeah, bad example, we should fix that text up.  Care to send a patch? :)

> 2) License file LICENSES/other/ISC doesn't exist
> 3) ISC is listed as an *example* under the "Not recommended licenses"

Yes, please don't use it if at all possible.

> First of all, as ISC is used by some files in the Linux kernel, I
> think it's worth adding to the LICENSE/*/ISC.

I see it is only used in a very small number of dts files.  Why not just
use BSD-2-Clause instead?  What do you find in ISC that is not available
to you with just BSD?

> Secondly, it isn't 100% clear to me if ISC is preferred or not
> recommended. File license-rules.rst suggests the later by listing it
> as an example for "Not recommended". It's just an example though, so
> I'm not 100% sure without seeing it in either: "preferred" or "other"
> directories. Also if anyone finds it "Not recommended", can we get a
> short explanation why is it so, please?

The license is functionally equalivant to BSD-2, so why would you want
to add more complexity here and have two licenses that are the same be
"recommended"?

thanks,

greg k-h

Re: [RFD] x86: The future of MPX

[Eric W. Biederman]

Ingo Molnar  writes:

> * Linus Torvalds  wrote:
>
>> On Sat, Apr 28, 2018 at 2:18 AM Ingo Molnar  wrote:
>> 
>> > I just tried the MPX testcases with the latest kernel:
>> 
>> >   deimos:~/tip/tools/testing/selftests/x86> ./mpx-mini-test_64
>> 
>> They need to be run as root. They try to access
>> 
>>  /sys/kernel/debug/tracing/set_ftrace_pid
>>  /sys/kernel/debug/tracing/trace
>> 
>> and that's root-only.
>
> Indeed - but note that they are crashing as root as well here:
>
>   root@deimos:/home/mingo/tip/tools/testing/selftests/x86# ./mpx-mini-test_64 
>   [...]
>   Aborted (core dumped)
>
> ... because I don't even have /sys/kernel/debug/tracing/set_ftrace_pid... :-/
>
> That's despite having ftrace enabled.
>
> After some digging I found out that 'set_ftrace_pid' is dependent on 
> CONFIG_FUNCTION_TRACING=y (not just CONFIG_TRACING=y), which I didn't
> have enabled on this kernel.
>
> After enabling it I got the 64-bit testcase to work:
>
>   #
>   ...
>   ./mpx-mini-test_64 completed successfully
>
> But the 32-bit testcase is erroring out:
>
>   root@deimos:/home/mingo/tip/tools/testing/selftests/x86# ./mpx-mini-test_32 
>   XSAVE is supported by HW & OS
>   XSAVE processor supported state mask: 0x21f
>   XSAVE OS supported state mask: 0x21f
>BNDREGS: size: 64 user: 1 supervisor: 0 aligned: 0
> BNDCSR: size: 64 user: 1 supervisor: 0 aligned: 0
>   executing unmaptest
>   mpx dig (  1) complete, SUCCESS (   0 /0)
>   #BR status == 2, missing bounds table,kernel should have handled!!
>
> v4.17-rc2 based kernel, so it should have the latest MPX code.

If you remove this which tree will this be going into?

I have some refactoring and cleanups of the x86 siginfo code I am
hoping to get in later this development cycle and part of that was
refactoring the mpx code so it works more like everything else.

If the codes away I can just that part of the patchset.

Eric

Re: [PATCH 2/2] hwmon: (k10temp) Use API function to access System Management Network

[Gabriel C]

2018-04-29 3:54 GMT+02:00 Guenter Roeck :
> The SMN (System Management Network) on Family 17h AMD CPUs is also accessed
> from other drivers, specifically EDAC. Accessing it directly is racy.
> On top of that, accessing the SMN through root bridge 00:00 is wrong on
> multi-die CPUs and may result in reading the temperature from the wrong
> die. Use available API functions to fix the problem.
>
> For this to work, also change the Raven Ridge PCI device ID to point to
> Data Fabric Function 3, since this ID is used by the API functions to
> find the CPU node.
>
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/hwmon/k10temp.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
> index b06bb1f90853..00e785afae0d 100644
> --- a/drivers/hwmon/k10temp.c
> +++ b/drivers/hwmon/k10temp.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  MODULE_DESCRIPTION("AMD Family 10h+ CPU core temperature monitor");
> @@ -40,8 +41,8 @@ static DEFINE_MUTEX(nb_smu_ind_mutex);
>  #define PCI_DEVICE_ID_AMD_17H_DF_F30x1463
>  #endif
>
> -#ifndef PCI_DEVICE_ID_AMD_17H_RR_NB
> -#define PCI_DEVICE_ID_AMD_17H_RR_NB0x15d0
> +#ifndef PCI_DEVICE_ID_AMD_17H_RR_DF_F3
> +#define PCI_DEVICE_ID_AMD_17H_RR_DF_F3 0x14eb
>  #endif
>
>  /* CPUID function 0x8001, ebx */
> @@ -136,8 +137,8 @@ static void read_tempreg_nb_f15(struct pci_dev *pdev, u32 
> *regval)
>
>  static void read_tempreg_nb_f17(struct pci_dev *pdev, u32 *regval)
>  {
> -   amd_nb_index_read(pdev, PCI_DEVFN(0, 0), 0x60,
> - F17H_M01H_REPORTED_TEMP_CTRL_OFFSET, regval);
> +   amd_smn_read(amd_pci_dev_to_node_id(pdev),
> +F17H_M01H_REPORTED_TEMP_CTRL_OFFSET, regval);
>  }
>
>  static ssize_t temp1_input_show(struct device *dev,
> @@ -323,7 +324,7 @@ static const struct pci_device_id k10temp_id_table[] = {
> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
> -   { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_RR_NB) },
> +   { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_RR_DF_F3) },
> {}
>  };
>  MODULE_DEVICE_TABLE(pci, k10temp_id_table);
> --
> 2.7.4
>

Works fine for me on top stable and on top v4.17-rc2-398-gcdface520934

Tested-by: Gabriel Craciunescu 

Regards

Re: [PATCH net-next 0/2 v4] netns: uevent filtering

[Eric W. Biederman]

Christian Brauner  writes:

> Hey everyone,
>
> This is the new approach to uevent filtering as discussed (see the
> threads in [1], [2], and [3]). It only contains *non-functional
> changes*.
>
> This series deals with with fixing up uevent filtering logic:
> - uevent filtering logic is simplified
> - locking time on uevent_sock_list is minimized
> - tagged and untagged kobjects are handled in separate codepaths
> - permissions for userspace are fixed for network device uevents in
>   network namespaces owned by non-initial user namespaces
>   Udev is now able to see those events correctly which it wasn't before.
>   For example, moving a physical device into a network namespace not
>   owned by the initial user namespaces before gave:
>
>   root@xen1:~# udevadm --debug monitor -k
>   calling: monitor
>   monitor will print the received events for:
>   KERNEL - the kernel uevent
>
>   sender uid=65534, message ignored
>   sender uid=65534, message ignored
>   sender uid=65534, message ignored
>   sender uid=65534, message ignored
>   sender uid=65534, message ignored
>
>   and now after the discussion and solution in [3] correctly gives:
>
>   root@xen1:~# udevadm --debug monitor -k
>   calling: monitor
>   monitor will print the received events for:
>   KERNEL - the kernel uevent
>
>   KERNEL[625.301042] add  
> /devices/pci:00/:00:02.0/:01:00.1/net/enp1s0f1 (net)
>   KERNEL[625.301109] move 
> /devices/pci:00/:00:02.0/:01:00.1/net/enp1s0f1 (net)
>   KERNEL[625.301138] move 
> /devices/pci:00/:00:02.0/:01:00.1/net/eth1 (net)
>   KERNEL[655.333272] remove 
> /devices/pci:00/:00:02.0/:01:00.1/net/eth1 (net)
>
> Thanks!
> Christian
>
> [1]: https://lkml.org/lkml/2018/4/4/739
> [2]: https://lkml.org/lkml/2018/4/26/767
> [3]: https://lkml.org/lkml/2018/4/26/738

Again ovearall ack.  One last nit that might be worth addressing.

Acked-by: "Eric W. Biederman" 

Eric

Re: [PATCH net-next 2/2 v4] netns: restrict uevents

[Eric W. Biederman]

> + /* fix credentials */
> + if (owning_user_ns != &init_user_ns) {
> + struct netlink_skb_parms *parms = &NETLINK_CB(skb);
> + kuid_t root_uid;
> + kgid_t root_gid;
> +
> + /* fix uid */
> + root_uid = make_kuid(owning_user_ns, 0);
> + if (!uid_valid(root_uid))
> + root_uid = GLOBAL_ROOT_UID;
> + parms->creds.uid = root_uid;
> +
> + /* fix gid */
> + root_gid = make_kgid(owning_user_ns, 0);
> + if (!gid_valid(root_gid))
> + root_gid = GLOBAL_ROOT_GID;
> + parms->creds.gid = root_gid;

One last nit:

You can only make the assignment if the uid is valid.
Leaving it GLBOAL_ROOT_UID if the composed uid is invalid.
AKA

/* fix uid */
root_uid = make_kuid(owning_user_ns, 0);
if (uid_valid(root_uid))
parms->creds.uid = root_uid;

/* fix gid */
root_gid = make_kgid(owning_user_ns, 0);
if (gid_valid(root_gid))
params->creds.gid = root_gid;


One line shorter and I think a little clearer.  I suspect
it even results in better code.

Eric

Re: [PATCH 1/2] x86/amd_nb: Add support for Raven Ridge CPUs

[Gabriel C]

2018-04-29 3:54 GMT+02:00 Guenter Roeck :
> Add Raven Ridge root bridge and data fabric PCI IDs.
> This is required for amd_pci_dev_to_node_id() and amd_smn_read().
>
> Signed-off-by: Guenter Roeck 
> ---
> This patch is a prerequisite for the second patch in the series.
> I'll be happy to apply both patches through hwmon if that is acceptable
> (and Cc: stable for 4.16+). If not, I'll be happy to wait for this patch
> to be available upstream.
>
> Since that there is no public documentation available for Raven Ridge,
> PCI IDs are derived from output of lspci.
>
>  arch/x86/kernel/amd_nb.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
> index c88e0b127810..bd33613ecb7c 100644
> --- a/arch/x86/kernel/amd_nb.c
> +++ b/arch/x86/kernel/amd_nb.c
> @@ -14,8 +14,11 @@
>  #include 
>
>  #define PCI_DEVICE_ID_AMD_17H_ROOT 0x1450
> +#define PCI_DEVICE_ID_AMD_17H_RR_ROOT  0x15d0
>  #define PCI_DEVICE_ID_AMD_17H_DF_F30x1463
>  #define PCI_DEVICE_ID_AMD_17H_DF_F40x1464
> +#define PCI_DEVICE_ID_AMD_17H_RR_DF_F3 0x15eb
> +#define PCI_DEVICE_ID_AMD_17H_RR_DF_F4 0x15ec
>
>  /* Protect the PCI config register pairs used for SMN and DF indirect 
> access. */
>  static DEFINE_MUTEX(smn_mutex);
> @@ -24,6 +27,7 @@ static u32 *flush_words;
>
>  static const struct pci_device_id amd_root_ids[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_ROOT) },
> +   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_RR_ROOT) },
> {}
>  };
>
> @@ -39,6 +43,7 @@ const struct pci_device_id amd_nb_misc_ids[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
> +   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_RR_DF_F3) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) },
> {}
>  };
> @@ -51,6 +56,7 @@ static const struct pci_device_id amd_nb_link_ids[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F4) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F4) },
> +   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_RR_DF_F4) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F4) },
> {}
>  };
> --
> 2.7.4
>

Works fine for me on top stable and on top v4.17-rc2-398-gcdface520934

Tested-by: Gabriel Craciunescu 


Regards

Re: [PATCH 1/2] x86/amd_nb: Add support for Raven Ridge CPUs

[Gabriel C]

2018-04-29 3:54 GMT+02:00 Guenter Roeck :
> Add Raven Ridge root bridge and data fabric PCI IDs.
> This is required for amd_pci_dev_to_node_id() and amd_smn_read().
>
> Signed-off-by: Guenter Roeck 
> ---
> This patch is a prerequisite for the second patch in the series.
> I'll be happy to apply both patches through hwmon if that is acceptable
> (and Cc: stable for 4.16+). If not, I'll be happy to wait for this patch
> to be available upstream.
>
> Since that there is no public documentation available for Raven Ridge,
> PCI IDs are derived from output of lspci.
>
>  arch/x86/kernel/amd_nb.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
> index c88e0b127810..bd33613ecb7c 100644
> --- a/arch/x86/kernel/amd_nb.c
> +++ b/arch/x86/kernel/amd_nb.c
> @@ -14,8 +14,11 @@
>  #include 
>
>  #define PCI_DEVICE_ID_AMD_17H_ROOT 0x1450
> +#define PCI_DEVICE_ID_AMD_17H_RR_ROOT  0x15d0
>  #define PCI_DEVICE_ID_AMD_17H_DF_F30x1463
>  #define PCI_DEVICE_ID_AMD_17H_DF_F40x1464
> +#define PCI_DEVICE_ID_AMD_17H_RR_DF_F3 0x15eb
> +#define PCI_DEVICE_ID_AMD_17H_RR_DF_F4 0x15ec
>
>  /* Protect the PCI config register pairs used for SMN and DF indirect 
> access. */
>  static DEFINE_MUTEX(smn_mutex);
> @@ -24,6 +27,7 @@ static u32 *flush_words;
>
>  static const struct pci_device_id amd_root_ids[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_ROOT) },
> +   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_RR_ROOT) },
> {}
>  };
>
> @@ -39,6 +43,7 @@ const struct pci_device_id amd_nb_misc_ids[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
> +   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_RR_DF_F3) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) },
> {}
>  };
> @@ -51,6 +56,7 @@ static const struct pci_device_id amd_nb_link_ids[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F4) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F4) },
> +   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_RR_DF_F4) },
> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F4) },
> {}
>  };
> --
> 2.7.4
>

Works fine for me on top stable and on top v4.17-rc2-398-gcdface520934

Tested-by: Gabriel Craciunescu 

Regards

Re: [PATCH 3/3] genalloc: selftest

[Randy Dunlap]

On 04/28/2018 07:45 PM, Igor Stoppa wrote:
> Introduce a set of macros for writing concise test cases for genalloc.
> 
> The test cases are meant to provide regression testing, when working on
> new functionality for genalloc.
> 
> Primarily they are meant to confirm that the various allocation strategy
> will continue to work as expected.
> 
> The execution of the self testing is controlled through a Kconfig option.
> 
> The testing takes place in the very early stages of main.c, to ensure
> that failures in genalloc are caught before they can cause unexplained
> erratic behavior in any of genalloc users.
> 
> Therefore, it would not be advisable to implement it as module.
> 
> Signed-off-by: Igor Stoppa 

Hi,

> ---
>  init/main.c |   2 +
>  lib/Kconfig |  15 ++
>  lib/Makefile|   1 +
>  lib/test_genalloc.c | 410 
> 
>  4 files changed, 428 insertions(+)
>  create mode 100644 lib/test_genalloc.c
> 
> diff --git a/init/main.c b/init/main.c
> index b795aa341a3a..b3b319d91b0e 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -91,6 +91,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -679,6 +680,7 @@ asmlinkage __visible void __init start_kernel(void)
>*/
>   mem_encrypt_init();
>  
> + test_genalloc();

Is there a stub for test_genalloc() when its config option is not enabled?
I don't see it.

>  #ifdef CONFIG_BLK_DEV_INITRD
>   if (initrd_start && !initrd_below_start_ok &&
>   page_to_pfn(virt_to_page((void *)initrd_start)) < min_low_pfn) {
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 09565d779324..2bf89af50728 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -303,6 +303,21 @@ config DECOMPRESS_LZ4
>  config GENERIC_ALLOCATOR
>   bool
>  

These TEST_ kconfig symbols should be in lib/Kconfig.debug, not lib/Kconfig.


> +config TEST_GENERIC_ALLOCATOR
> + bool "genalloc tester"
> + default n
> + select GENERIC_ALLOCATOR

This should depend on GENERIC_ALLOCATOR, not select it.

See TEST_PARMAN, TEST_BPF, TEST_FIRMWARE, TEST_SYSCTL, TEST_DEBUG_VIRTUAL
in lib/Kconfig.debug.


> + help
> +   Enable automated testing of the generic allocator.
> +   The testing is primarily for the tracking of allocated space.
> +
> +config TEST_GENERIC_ALLOCATOR_VERBOSE
> + bool "make the genalloc tester more verbose"
> + default n
> + select TEST_GENERIC_ALLOCATOR

depends on TEST_GENERIC_ALLOCATOR

> + help
> +   More information will be displayed during the self-testing.
> +
>  #
>  # reed solomon support is select'ed if needed
>  #

> diff --git a/lib/test_genalloc.c b/lib/test_genalloc.c
> new file mode 100644
> index ..ab9984861517
> --- /dev/null
> +++ b/lib/test_genalloc.c
> @@ -0,0 +1,410 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * test_genalloc.c
> + *
> + * (C) Copyright 2017 Huawei Technologies Co. Ltd.
> + * Author: Igor Stoppa 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +
> +/*
> + * In case of failure of any of these tests, memory corruption is almost
> + * guarranteed; allowing the boot to continue means risking to corrupt

  guaranteed;

> + * also any filesystem/block device accessed write mode.
> + * Therefore, BUG_ON() is used, when testing.
> + */


-- 
~Randy

Re: [llc_ui_release] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004

[Linus Torvalds]

On Sat, Apr 28, 2018 at 7:12 PM Fengguang Wu  wrote:

> FYI this happens in mainline kernel 4.17.0-rc2.
> It looks like a new regression.

> It occurs in 5 out of 5 boots.

> [main] 375 sockets created based on info from socket cachefile.
> [main] Generating file descriptors
> [main] Added 83 filenames from /dev
> udevd[507]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv
platform:regulatory': No such file or directory
> [  372.057947] caif:caif_disconnect_client(): nothing to disconnect
> [  372.082415] BUG: unable to handle kernel NULL pointer dereference at
0004

I think this is fixed by commit 3a04ce7130a7 ("llc: fix NULL pointer deref
for SOCK_ZAPPED")

Liunus

drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to `extcon_unregister_notifier'

[kbuild test robot]

Hi Maciej,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   19b9ad67310ed2f685062a00aec602bec33835f0
commit: 688838442147d9dd94c2ef7c2c31a35cf150c5fa drm/bridge/sii8620: use 
micro-USB cable detection logic to detect MHL
date:   7 weeks ago
config: x86_64-randconfig-s4-04290805 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 688838442147d9dd94c2ef7c2c31a35cf150c5fa
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_remove':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to 
>> `extcon_unregister_notifier'
   drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_init':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to 
>> `extcon_find_edev_by_node'
>> drivers/gpu/drm/bridge/sil-sii8620.c:2241: undefined reference to 
>> `extcon_register_notifier'
   drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_extcon_work':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2189: undefined reference to 
>> `extcon_get_state'

vim +2405 drivers/gpu/drm/bridge/sil-sii8620.c

  2212  
  2213  static int sii8620_extcon_init(struct sii8620 *ctx)
  2214  {
  2215  struct extcon_dev *edev;
  2216  struct device_node *musb, *muic;
  2217  int ret;
  2218  
  2219  /* get micro-USB connector node */
  2220  musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
  2221  /* next get micro-USB Interface Controller node */
    muic = of_get_next_parent(musb);
  2223  
  2224  if (!muic) {
  2225  dev_info(ctx->dev, "no extcon found, switching to 
'always on' mode\n");
  2226  return 0;
  2227  }
  2228  
> 2229  edev = extcon_find_edev_by_node(muic);
  2230  of_node_put(muic);
  2231  if (IS_ERR(edev)) {
  2232  if (PTR_ERR(edev) == -EPROBE_DEFER)
  2233  return -EPROBE_DEFER;
  2234  dev_err(ctx->dev, "Invalid or missing extcon\n");
  2235  return PTR_ERR(edev);
  2236  }
  2237  
  2238  ctx->extcon = edev;
  2239  ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
  2240  INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work);
> 2241  ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, 
> &ctx->extcon_nb);
  2242  if (ret) {
  2243  dev_err(ctx->dev, "failed to register notifier for 
MHL\n");
  2244  return ret;
  2245  }
  2246  
  2247  return 0;
  2248  }
  2249  
  2250  static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge 
*bridge)
  2251  {
  2252  return container_of(bridge, struct sii8620, bridge);
  2253  }
  2254  
  2255  static int sii8620_attach(struct drm_bridge *bridge)
  2256  {
  2257  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2258  
  2259  sii8620_init_rcp_input_dev(ctx);
  2260  
  2261  return sii8620_clear_error(ctx);
  2262  }
  2263  
  2264  static void sii8620_detach(struct drm_bridge *bridge)
  2265  {
  2266  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2267  
  2268  rc_unregister_device(ctx->rc_dev);
  2269  }
  2270  
  2271  static enum drm_mode_status sii8620_mode_valid(struct drm_bridge 
*bridge,
  2272   const struct drm_display_mode 
*mode)
  2273  {
  2274  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2275  bool can_pack = ctx->devcap[MHL_DCAP_VID_LINK_MODE] &
  2276  MHL_DCAP_VID_LINK_PPIXEL;
  2277  unsigned int max_pclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK :
  2278 MHL1_MAX_LCLK;
  2279  max_pclk /= can_pack ? 2 : 3;
  2280  
  2281  return (mode->clock > max_pclk) ? MODE_CLOCK_HIGH : MODE_OK;
  2282  }
  2283  
  2284  static bool sii8620_mode_fixup(struct drm_bridge *bridge,
  2285 const struct drm_display_mode *mode,
  2286 struct drm_display_mode *adjusted_mode)
  2287  {
  2288  struct sii8620 *ctx = bridge_to_sii8620(bridge);
  2289  int max_lclk;
  2290  bool ret = true;
  2291  
  2292  mutex_lock(&ctx->lock);
  2293  
  2294  max_lclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK : MHL1_MAX_LCLK;
  2295  if (max_lclk > 3 * adjusted_mode->clock) {
  2296  ctx->use_packed_pixel = 0;
  2297  goto end;
  2298  }
  2299  if ((ctx->devcap[MHL_DCAP_VID_LINK_MODE] & 
MHL_DCAP_VID_LINK_PPIXEL) &&
  2300  max_lclk > 2 * adjusted_mode->clock) {
  2301  ctx->use_packed_pixel

Re: [PATCH 0/3] linux-next: mm: hardening: Track genalloc allocations

[Matthew Wilcox]

On Sun, Apr 29, 2018 at 06:45:39AM +0400, Igor Stoppa wrote:
> This patchset was created as part of an older version of pmalloc, however
> it has value per-se, as it hardens the memory management for the generic
> allocator genalloc.
> 
> Genalloc does not currently track the size of the allocations it hands out.
> 
> Either by mistake, or due to an attack, it is possible that more memory
> than what was initially allocated is freed, leaving behind dangling
> pointers, ready for an use-after-free attack.

This is a good point.  It is worth hardening genalloc.
But I still don't like the cost of the bitmap.  I've been
reading about allocators and I found Bonwick's paper from 2001:
https://www.usenix.org/legacy/event/usenix01/full_papers/bonwick/bonwick.pdf
Section 4 describes the vmem allocator which would seem to have superior
performance and lower memory overhead than the current genalloc allocator,
never mind the hardened allocator.

Maybe there's been an advnace in resource allocator technology since
then that someone more familiar with CS research can point out.

Re: [crng_reseed] WARNING: inconsistent lock state

[Linus Torvalds]

On Sat, Apr 28, 2018 at 7:26 PM Fengguang Wu  wrote:

> FYI this happens in mainline kernel 4.17.0-rc2.
> It looks like a new regression.

> It occurs in 3 out of 3 boots.

> There is another "[  294.642506] BUG: sleeping function called from
> invalid context at mm/slab.h:421" at the bottom of this long dmesg:

This should be fixed by commit 6c1e851c4edc ("random: fix possible sleeping
allocation from irq context").

 Linus

[GIT PULL] ext4 fixes for 4.17-rc3

[Theodore Y. Ts'o]

The following changes since commit e40ff213898502d299351cc2fe1e350cd186f0d3:

  ext4: force revalidation of directory pointer after seekdir(2) (2018-04-01 
23:21:03 -0400)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
tags/for_linus_stable

for you to fetch changes up to 7ef79ad52136712172eb0525bf0b462516bf2f93:

  ext4: add MODULE_SOFTDEP to ensure crc32c is included in the initramfs 
(2018-04-26 00:44:46 -0400)


Fix misc. bugs and a regression for ext4.


Eric Biggers (1):
  ext4: prevent right-shifting extents beyond EXT_MAX_BLOCKS

Lukas Czerner (1):
  ext4: fix bitmap position validation

Theodore Ts'o (2):
  ext4: set h_journal if there is a failure starting a reserved handle
  ext4: add MODULE_SOFTDEP to ensure crc32c is included in the initramfs

 fs/ext4/balloc.c  |  9 +
 fs/ext4/extents.c | 16 +++-
 fs/ext4/super.c   |  1 +
 fs/jbd2/transaction.c |  1 +
 4 files changed, 18 insertions(+), 9 deletions(-)

[PATCH 3/3] genalloc: selftest

[Igor Stoppa]

Introduce a set of macros for writing concise test cases for genalloc.

The test cases are meant to provide regression testing, when working on
new functionality for genalloc.

Primarily they are meant to confirm that the various allocation strategy
will continue to work as expected.

The execution of the self testing is controlled through a Kconfig option.

The testing takes place in the very early stages of main.c, to ensure
that failures in genalloc are caught before they can cause unexplained
erratic behavior in any of genalloc users.

Therefore, it would not be advisable to implement it as module.

Signed-off-by: Igor Stoppa 
---
 init/main.c |   2 +
 lib/Kconfig |  15 ++
 lib/Makefile|   1 +
 lib/test_genalloc.c | 410 
 4 files changed, 428 insertions(+)
 create mode 100644 lib/test_genalloc.c

diff --git a/init/main.c b/init/main.c
index b795aa341a3a..b3b319d91b0e 100644
--- a/init/main.c
+++ b/init/main.c
@@ -91,6 +91,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -679,6 +680,7 @@ asmlinkage __visible void __init start_kernel(void)
 */
mem_encrypt_init();
 
+   test_genalloc();
 #ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start && !initrd_below_start_ok &&
page_to_pfn(virt_to_page((void *)initrd_start)) < min_low_pfn) {
diff --git a/lib/Kconfig b/lib/Kconfig
index 09565d779324..2bf89af50728 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -303,6 +303,21 @@ config DECOMPRESS_LZ4
 config GENERIC_ALLOCATOR
bool
 
+config TEST_GENERIC_ALLOCATOR
+   bool "genalloc tester"
+   default n
+   select GENERIC_ALLOCATOR
+   help
+ Enable automated testing of the generic allocator.
+ The testing is primarily for the tracking of allocated space.
+
+config TEST_GENERIC_ALLOCATOR_VERBOSE
+   bool "make the genalloc tester more verbose"
+   default n
+   select TEST_GENERIC_ALLOCATOR
+   help
+ More information will be displayed during the self-testing.
+
 #
 # reed solomon support is select'ed if needed
 #
diff --git a/lib/Makefile b/lib/Makefile
index 384713ff70d3..2c66346ab246 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -114,6 +114,7 @@ obj-$(CONFIG_LIBCRC32C) += libcrc32c.o
 obj-$(CONFIG_CRC8) += crc8.o
 obj-$(CONFIG_XXHASH)   += xxhash.o
 obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o
+obj-$(CONFIG_TEST_GENERIC_ALLOCATOR) += test_genalloc.o
 
 obj-$(CONFIG_842_COMPRESS) += 842/
 obj-$(CONFIG_842_DECOMPRESS) += 842/
diff --git a/lib/test_genalloc.c b/lib/test_genalloc.c
new file mode 100644
index ..ab9984861517
--- /dev/null
+++ b/lib/test_genalloc.c
@@ -0,0 +1,410 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * test_genalloc.c
+ *
+ * (C) Copyright 2017 Huawei Technologies Co. Ltd.
+ * Author: Igor Stoppa 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+
+/*
+ * In case of failure of any of these tests, memory corruption is almost
+ * guarranteed; allowing the boot to continue means risking to corrupt
+ * also any filesystem/block device accessed write mode.
+ * Therefore, BUG_ON() is used, when testing.
+ */
+
+
+/*
+ * Keep the bitmap small, while including case of cross-ulong mapping.
+ * For simplicity, the test cases use only 1 chunk of memory.
+ */
+#define BITMAP_SIZE_C 16
+#define ALLOC_ORDER 0
+
+#define ULONG_SIZE (sizeof(unsigned long))
+#define BITMAP_SIZE_UL (BITMAP_SIZE_C / ULONG_SIZE)
+#define MIN_ALLOC_SIZE (1 << ALLOC_ORDER)
+#define ENTRIES (BITMAP_SIZE_C * 8)
+#define CHUNK_SIZE  (MIN_ALLOC_SIZE * ENTRIES)
+
+#ifndef CONFIG_TEST_GENERIC_ALLOCATOR_VERBOSE
+
+static inline void print_first_chunk_bitmap(struct gen_pool *pool) {}
+
+#else
+
+static void print_first_chunk_bitmap(struct gen_pool *pool)
+{
+   struct gen_pool_chunk *chunk;
+   char bitmap[BITMAP_SIZE_C * 2 + 1];
+   unsigned long i;
+   char *bm = bitmap;
+   char *entry;
+
+   if (unlikely(pool == NULL || pool->chunks.next == NULL))
+   return;
+
+   chunk = container_of(pool->chunks.next, struct gen_pool_chunk,
+next_chunk);
+   entry = (void *)chunk->entries;
+   for (i = 1; i <= BITMAP_SIZE_C; i++)
+   bm += snprintf(bm, 3, "%02hhx", entry[BITMAP_SIZE_C - i]);
+   *bm = '\0';
+   pr_notice("chunk: %pbitmap: 0x%s\n", chunk, bitmap);
+
+}
+
+#endif
+
+enum test_commands {
+   CMD_ALLOCATOR,
+   CMD_ALLOCATE,
+   CMD_FLUSH,
+   CMD_FREE,
+   CMD_NUMBER,
+   CMD_END = CMD_NUMBER,
+};
+
+struct null_struct {
+   void *null;
+};
+
+struct test_allocator {
+   genpool_algo_t algo;
+   union {
+   struct genpool_data_align align;
+   struct genpool_data_fixed offset;
+   struct null_struct null;
+   } data;
+};
+
+struct test_action {
+   unsigned int location;
+   char p

[PATCH 2/3] Add label and license to genalloc.rst

[Igor Stoppa]

Add SPDX license to genalloc.rst, then a label, to allow cross-referencing.

Signed-off-by: Igor Stoppa 
---
 Documentation/core-api/genalloc.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/core-api/genalloc.rst 
b/Documentation/core-api/genalloc.rst
index 6b38a39fab24..0b5ade832ee8 100644
--- a/Documentation/core-api/genalloc.rst
+++ b/Documentation/core-api/genalloc.rst
@@ -1,3 +1,7 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _genalloc:
+
 The genalloc/genpool subsystem
 ==
 
-- 
2.14.1

[PATCH 1/3] genalloc: track beginning of allocations

[Igor Stoppa]

The genalloc library is only capable of tracking if a certain unit of
allocation is in use or not.

It is not capable of discerning where the memory associated to an
allocation request begins and where it ends.

The reason is that units of allocations are tracked by using a bitmap,
where each bit represents that the unit is either allocated (1) or
available (0).

The user of the API must keep track of how much space was requested, if
it ever needs to be freed.

This can cause errors being undetected.
Examples:
* Only a subset of the memory provided to an allocation request is freed
* The memory from a subsequent allocation is freed
* The memory being freed doesn't start at the beginning of an
  allocation.

The bitmap is used because it allows to perform lockless read/write
access, where this is supported by hw through cmpxchg.
Similarly, it is possible to scan the bitmap for a sufficiently long
sequence of zeros, to identify zones available for allocation.

This patch doubles the space reserved in the bitmap for each allocation,
to track their beginning.

For details, see the documentation inside lib/genalloc.c

The primary effect of this patch is that code using the gen_alloc
library does not need anymore to keep track of the size of the
allocations it makes.

Prior to this patch, it was necessary to keep track of the size of the
allocation, so that it would be possible, later on, to know how much
space should be freed.

Now, users of the api can choose to etiher still specify explicitly the
size, or let the library determine it, by giving a value of 0.

However, even when the value is specified, the library still uses its on
understanding of the space associated with a certain allocation, to
confirm that they are consistent.

This verification also confirms that the patch works correctly.

Eventually, the extra parameter (and the corresponding verification)
could be dropped, in favor of a simplified API.

Signed-off-by: Igor Stoppa 
---
 include/linux/genalloc.h | 112 +++
 lib/genalloc.c   | 742 ++-
 2 files changed, 599 insertions(+), 255 deletions(-)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 872f930f1b06..ff7229520656 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -32,7 +32,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 struct device;
 struct device_node;
@@ -76,7 +76,7 @@ struct gen_pool_chunk {
phys_addr_t phys_addr;  /* physical starting address of memory 
chunk */
unsigned long start_addr;   /* start address of memory chunk */
unsigned long end_addr; /* end address of memory chunk 
(inclusive) */
-   unsigned long bits[0];  /* bitmap for allocating memory chunk */
+   unsigned long entries[0];   /* bitmap for allocating memory chunk */
 };
 
 /*
@@ -93,74 +93,82 @@ struct genpool_data_fixed {
unsigned long offset;   /* The offset of the specific region */
 };
 
-extern struct gen_pool *gen_pool_create(int, int);
-extern phys_addr_t gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long);
-extern int gen_pool_add_virt(struct gen_pool *, unsigned long, phys_addr_t,
-size_t, int);
-/**
- * gen_pool_add - add a new chunk of special memory to the pool
- * @pool: pool to add new memory chunk to
- * @addr: starting address of memory chunk to add to pool
- * @size: size in bytes of the memory chunk to add to pool
- * @nid: node id of the node the chunk structure and bitmap should be
- *   allocated on, or -1
- *
- * Add a new chunk of special memory to the specified pool.
- *
- * Returns 0 on success or a -ve errno on failure.
- */
+struct gen_pool *gen_pool_create(int min_alloc_order, int nid);
+
+int gen_pool_add_virt(struct gen_pool *pool, unsigned long virt,
+ phys_addr_t phys, size_t size, int nid);
+
+
 static inline int gen_pool_add(struct gen_pool *pool, unsigned long addr,
   size_t size, int nid)
 {
return gen_pool_add_virt(pool, addr, -1, size, nid);
 }
-extern void gen_pool_destroy(struct gen_pool *);
-extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
-extern unsigned long gen_pool_alloc_algo(struct gen_pool *, size_t,
-   genpool_algo_t algo, void *data);
-extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
-   dma_addr_t *dma);
-extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
-extern void gen_pool_for_each_chunk(struct gen_pool *,
-   void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
-extern size_t gen_pool_avail(struct gen_pool *);
-extern size_t gen_pool_size(struct gen_pool *);
 
-extern void gen_pool_set_algo(struct gen_pool *pool, genpool_algo_t algo,
-   void *data);
+phys_addr_t gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long addr);
 
-extern unsigned long gen_pool_first_fit(unsi

[PATCH 0/3] linux-next: mm: hardening: Track genalloc allocations

[Igor Stoppa]

This patchset was created as part of an older version of pmalloc, however
it has value per-se, as it hardens the memory management for the generic
allocator genalloc.

Genalloc does not currently track the size of the allocations it hands out.

Either by mistake, or due to an attack, it is possible that more memory
than what was initially allocated is freed, leaving behind dangling
pointers, ready for an use-after-free attack.

With this patch, genalloc becomes capable of tracking the size of each
allocation it has handed out, when it's time to free it.

It can either verify that the size received, when free is invoked, is
correct, or it can decide autonomously how much memory to free, if the
value received for the size parameter is 0.

These patches are proposed for beign merged into linux-next, to verify
that they do not introduce regressions, by comparing the value received
from the callers of the free function with the internal tracking.

Later on, the "size" parameter can be dropped, and each caller can be
adjusted accordingly.

Signed-off-by: Igor Stoppa 

Igor Stoppa (3):
  genalloc: track beginning of allocations
  Add label and license to genalloc.rst
  genalloc: selftest

 Documentation/core-api/genalloc.rst |   4 +
 include/linux/genalloc.h| 112 +++---
 init/main.c |   2 +
 lib/Kconfig |  15 +
 lib/Makefile|   1 +
 lib/genalloc.c  | 742 ++--
 lib/test_genalloc.c | 410 
 7 files changed, 1031 insertions(+), 255 deletions(-)
 create mode 100644 lib/test_genalloc.c

-- 
2.14.1

Re: ed74ae0342 ("blk-mq: Avoid that a completion can be ignored .."): BUG: kernel hang in test stage

[Fengguang Wu]

Hi Jens,

On Fri, Apr 27, 2018 at 06:52:58PM -0600, Jens Axboe wrote:

On 4/24/18 3:00 PM, kernel test robot wrote:

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-linus

commit ed74ae03424684a6ad8a973c3fa727c6b4162432
Author: Bart Van Assche 
AuthorDate: Thu Apr 19 09:43:53 2018 -0700
Commit: Jens Axboe 
CommitDate: Thu Apr 19 14:21:47 2018 -0600

blk-mq: Avoid that a completion can be ignored for BLK_EH_RESET_TIMER



Any chance you can try with the newer version?

https://github.com/bvanassche/linux/commit/4acd555fa13087


That works!

Tested-by: Fengguang Wu 

[RFC patch] Documenation: don't build media .rst files when not building Documentation/media/

[Randy Dunlap]

Don't build media .rst files from header files when Documentation/media/
is not in the target SPHINXDIRS.

It looks like the dependencies in Documentation/media/Makefile should
take care of running parse-headers.pl to generated .rst files from the
header files, but it's not happening and I don't see why not.

---
 Documentation/Makefile |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- linux-next-20180426.orig/Documentation/Makefile
+++ linux-next-20180426/Documentation/Makefile
@@ -52,8 +52,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1)) || ex
 #e.g. "media" for the linux-tv book-set at ./Documentation/media
 
 quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
-  cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) 
$(build)=Documentation/media $2 && \
-   PYTHONDONTWRITEBYTECODE=1 \
+  cmd_sphinx = PYTHONDONTWRITEBYTECODE=1 \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
$(srctree)/$(src)/$5/$(SPHINX_CONF)) \
$(SPHINXBUILD) \
-b $2 \

[PATCH 1/2] x86/amd_nb: Add support for Raven Ridge CPUs

[Guenter Roeck]

Add Raven Ridge root bridge and data fabric PCI IDs.
This is required for amd_pci_dev_to_node_id() and amd_smn_read().

Signed-off-by: Guenter Roeck 
---
This patch is a prerequisite for the second patch in the series.
I'll be happy to apply both patches through hwmon if that is acceptable
(and Cc: stable for 4.16+). If not, I'll be happy to wait for this patch
to be available upstream.

Since that there is no public documentation available for Raven Ridge,
PCI IDs are derived from output of lspci.

 arch/x86/kernel/amd_nb.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
index c88e0b127810..bd33613ecb7c 100644
--- a/arch/x86/kernel/amd_nb.c
+++ b/arch/x86/kernel/amd_nb.c
@@ -14,8 +14,11 @@
 #include 
 
 #define PCI_DEVICE_ID_AMD_17H_ROOT 0x1450
+#define PCI_DEVICE_ID_AMD_17H_RR_ROOT  0x15d0
 #define PCI_DEVICE_ID_AMD_17H_DF_F30x1463
 #define PCI_DEVICE_ID_AMD_17H_DF_F40x1464
+#define PCI_DEVICE_ID_AMD_17H_RR_DF_F3 0x15eb
+#define PCI_DEVICE_ID_AMD_17H_RR_DF_F4 0x15ec
 
 /* Protect the PCI config register pairs used for SMN and DF indirect access. 
*/
 static DEFINE_MUTEX(smn_mutex);
@@ -24,6 +27,7 @@ static u32 *flush_words;
 
 static const struct pci_device_id amd_root_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_ROOT) },
+   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_RR_ROOT) },
{}
 };
 
@@ -39,6 +43,7 @@ const struct pci_device_id amd_nb_misc_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
+   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_RR_DF_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) },
{}
 };
@@ -51,6 +56,7 @@ static const struct pci_device_id amd_nb_link_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F4) },
+   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_RR_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F4) },
{}
 };
-- 
2.7.4

[PATCH 2/2] hwmon: (k10temp) Use API function to access System Management Network

[Guenter Roeck]

The SMN (System Management Network) on Family 17h AMD CPUs is also accessed
from other drivers, specifically EDAC. Accessing it directly is racy.
On top of that, accessing the SMN through root bridge 00:00 is wrong on
multi-die CPUs and may result in reading the temperature from the wrong
die. Use available API functions to fix the problem.

For this to work, also change the Raven Ridge PCI device ID to point to
Data Fabric Function 3, since this ID is used by the API functions to
find the CPU node.

Signed-off-by: Guenter Roeck 
---
 drivers/hwmon/k10temp.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index b06bb1f90853..00e785afae0d 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 MODULE_DESCRIPTION("AMD Family 10h+ CPU core temperature monitor");
@@ -40,8 +41,8 @@ static DEFINE_MUTEX(nb_smu_ind_mutex);
 #define PCI_DEVICE_ID_AMD_17H_DF_F30x1463
 #endif
 
-#ifndef PCI_DEVICE_ID_AMD_17H_RR_NB
-#define PCI_DEVICE_ID_AMD_17H_RR_NB0x15d0
+#ifndef PCI_DEVICE_ID_AMD_17H_RR_DF_F3
+#define PCI_DEVICE_ID_AMD_17H_RR_DF_F3 0x14eb
 #endif
 
 /* CPUID function 0x8001, ebx */
@@ -136,8 +137,8 @@ static void read_tempreg_nb_f15(struct pci_dev *pdev, u32 
*regval)
 
 static void read_tempreg_nb_f17(struct pci_dev *pdev, u32 *regval)
 {
-   amd_nb_index_read(pdev, PCI_DEVFN(0, 0), 0x60,
- F17H_M01H_REPORTED_TEMP_CTRL_OFFSET, regval);
+   amd_smn_read(amd_pci_dev_to_node_id(pdev),
+F17H_M01H_REPORTED_TEMP_CTRL_OFFSET, regval);
 }
 
 static ssize_t temp1_input_show(struct device *dev,
@@ -323,7 +324,7 @@ static const struct pci_device_id k10temp_id_table[] = {
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
-   { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_RR_NB) },
+   { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_RR_DF_F3) },
{}
 };
 MODULE_DEVICE_TABLE(pci, k10temp_id_table);
-- 
2.7.4

Re: FROM: "MRS PATRICIA WILLIAMS" linux-kernel@vger.kernel.org

[Mrs Patricia Williams]

FYI: About My Previous Message

Hi,

Am Mrs Patricia William, i just want to know if you receive my 
previous email i sent to you last three (3) days ago.

Is your email still Active? If YES; please can you email me back, 
i have something very important to discuss with you.

Awaits your reply soon..


Best Regard
Mrs. Patricia Williams

Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE

[Ilia Mirkin]

On Sat, Apr 28, 2018 at 7:02 PM, Michel Dänzer  wrote:
> On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
>> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer  wrote:
>>> From: Michel Dänzer 
>>>
>>> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled)
>>> try to allocate huge pages. However, not all drivers can take advantage
>>> of huge pages, but they would incur the overhead for allocating and
>>> freeing them anyway.
>>>
>>> Now, drivers which can take advantage of huge pages need to set the new
>>> flag TTM_PAGE_FLAG_TRANSHUGE to get them. Drivers not setting this flag
>>> no longer incur any overhead for allocating or freeing huge pages.
>>>
>>> v2:
>>> * Also guard swapping of consecutive pages in ttm_get_pages
>>> * Reword commit log, hopefully clearer now
>>>
>>> Cc: sta...@vger.kernel.org
>>> Signed-off-by: Michel Dänzer 
>>
>> Both I and lots of other people, based on reports, are still seeing
>> plenty of issues with this as late as 4.16.4.
>
> "lots of other people", "plenty of issues" sounds a bit exaggerated from
> what I've seen. FWIW, while I did see the original messages myself, I
> haven't seen any since Christian's original fix (see below), neither
> with amdgpu nor radeon, even before this patch you followed up to.

Probably a half-dozen reports of it with nouveau, in addition to
another bunch of people talking about it on the bug you mention below,
along with email threads on dri-devel.

I figured I didn't have to raise my own since it was identical to the
others, and, I assumed, was being handled.

>> Admittedly I'm on nouveau, but others have reported issues with
>> radeon/amdgpu as well. It's been going on since the feature was merged
>> in v4.15, with what seems like little investigation from the authors
>> introducing the feature.
>
> That's not a fair assessment. See
> https://bugs.freedesktop.org/show_bug.cgi?id=104082#c40 and following
> comments.
>
> Christian fixed the original issue in
> d0bc0c2a31c95002d37c3cc511ffdcab851b3256 "swiotlb: suppress warning when
> __GFP_NOWARN is set". Christian did his best to try and get the fix in
> before 4.15 final, but for reasons beyond his control, it was delayed
> until 4.16-rc1 and then backported to 4.15.5.

In case it's unclear, let me state this explicitly -- I totally get
that despite best intentions, bugs get introduced. I do it myself.
What I'm having trouble with is the handling once the issue is
discovered.

>
> Unfortunately, there was an swiotlb regression (not directly related to
> Christian's work) shortly after this fix, also in 4.16-rc1, which is now
> fixed in 4.17-rc1 and will be backported to 4.16.y.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.16.5&id=2c9dacf5bfe1e45d96dfe97cb71d2b717786a7b9

This guy? Didn't help. I'm running 4.16.4 right now.

> It looks like there's at least one more bug left, but it's not clear yet
> when that was introduced, whether it's directly related to Christian's
> work, or indeed what the impact is. Let's not get ahead of ourselves.

Whether it is directly related to that work or not, the issue
persists. There are two options:

 - When declaring things fixed, no serious attempt was actually made
at reproducing the underlying issues.
 - The authors truly can't reproduce the underlying issues users are
seeing and are taking stabs in the dark.

Given that a number of people are reporting problems, in either
scenario, the reasonable thing is to disable the feature, and figure
out what is going on. Maybe condition it on !CONFIG_SWIOTLB.

>> We now have *two* broken releases, v4.15 and v4.16 (anything that
>> spews error messages and stack traces ad-infinitum in dmesg is, by
>> definition, broken).
>
> I haven't seen any evidence that there's still an issue in 4.15, is
> there any?

Well, I did have a late 4.15 rc kernel in addition to the 'suppress
warning' patch. Now I'm questioning my memory of whether the issue was
resolved there or not. I'm pretty sure that 'not', but no longer 100%.
Either way, I think we all agree v4.15 was broken and more importantly
was *known* to be broken well in advance of the release. A reasonable
option would have been to disable the feature until the other bits
fell into place.

>> You're putting this behind a flag now (finally),
>
> I wrote this patch because I realized due to some remark I happened to
> see you make this week on IRC that the huge page support in TTM was
> enabled for all drivers. Instead of making that kind of remark on IRC,
> it would have been more constructive, and more conducive to quick
> implementation, to suggest making the feature not active for drivers
> which don't need it in a mailing list post.

I see IRC as a much faster and direct way of reaching the authors
and/or people who need to know an issue. As there was already a bug
filed about it and the issue was known about, I didn't really see a
reason to pile on (until now).

> At least, please do more research before making this k

[PATCH] media: staging: atomisp: fix a potential missing-check bug

[Wenwen Wang]

At the end of atomisp_subdev_set_selection(), the function
atomisp_subdev_get_rect() is invoked to get the pointer to v4l2_rect. Since
this function may return a NULL pointer, it is firstly invoked to check
the returned pointer. If the returned pointer is not NULL, then the
function is invoked again to obtain the pointer and the memory content
at the location of the returned pointer is copied to the memory location of
r. In most cases, the pointers returned by the two invocations are same.
However, given that the pointer returned by the function
atomisp_subdev_get_rect() is not a constant, it is possible that the two
invocations return two different pointers. For example, another thread may
race to modify the related pointers during the two invocations. In that
case, even if the first returned pointer is not null, the second returned
pointer might be null, which will cause issues such as null pointer
dereference.

This patch saves the pointer returned by the first invocation and removes
the second invocation. If the returned pointer is not NULL, the memory
content is copied according to the original code.

Signed-off-by: Wenwen Wang 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
index 49a9973..d5fa513 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
@@ -366,6 +366,7 @@ int atomisp_subdev_set_selection(struct v4l2_subdev *sd,
unsigned int i;
unsigned int padding_w = pad_w;
unsigned int padding_h = pad_h;
+   struct v4l2_rect *p;
 
stream_id = atomisp_source_pad_to_stream_id(isp_sd, vdev_pad);
 
@@ -536,9 +537,10 @@ int atomisp_subdev_set_selection(struct v4l2_subdev *sd,
ffmt[pad]->height = comp[pad]->height;
}
 
-   if (!atomisp_subdev_get_rect(sd, cfg, which, pad, target))
+   p = atomisp_subdev_get_rect(sd, cfg, which, pad, target);
+   if (!p)
return -EINVAL;
-   *r = *atomisp_subdev_get_rect(sd, cfg, which, pad, target);
+   *r = *p;
 
dev_dbg(isp->dev, "sel actual: l %d t %d w %d h %d\n",
r->left, r->top, r->width, r->height);
-- 
2.7.4

Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE

[Michel Dänzer]

On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer  wrote:
>> From: Michel Dänzer 
>>
>> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled)
>> try to allocate huge pages. However, not all drivers can take advantage
>> of huge pages, but they would incur the overhead for allocating and
>> freeing them anyway.
>>
>> Now, drivers which can take advantage of huge pages need to set the new
>> flag TTM_PAGE_FLAG_TRANSHUGE to get them. Drivers not setting this flag
>> no longer incur any overhead for allocating or freeing huge pages.
>>
>> v2:
>> * Also guard swapping of consecutive pages in ttm_get_pages
>> * Reword commit log, hopefully clearer now
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Michel Dänzer 
> 
> Both I and lots of other people, based on reports, are still seeing
> plenty of issues with this as late as 4.16.4.

"lots of other people", "plenty of issues" sounds a bit exaggerated from
what I've seen. FWIW, while I did see the original messages myself, I
haven't seen any since Christian's original fix (see below), neither
with amdgpu nor radeon, even before this patch you followed up to.


> Admittedly I'm on nouveau, but others have reported issues with
> radeon/amdgpu as well. It's been going on since the feature was merged
> in v4.15, with what seems like little investigation from the authors
> introducing the feature.

That's not a fair assessment. See
https://bugs.freedesktop.org/show_bug.cgi?id=104082#c40 and following
comments.

Christian fixed the original issue in
d0bc0c2a31c95002d37c3cc511ffdcab851b3256 "swiotlb: suppress warning when
__GFP_NOWARN is set". Christian did his best to try and get the fix in
before 4.15 final, but for reasons beyond his control, it was delayed
until 4.16-rc1 and then backported to 4.15.5.

Unfortunately, there was an swiotlb regression (not directly related to
Christian's work) shortly after this fix, also in 4.16-rc1, which is now
fixed in 4.17-rc1 and will be backported to 4.16.y.

It looks like there's at least one more bug left, but it's not clear yet
when that was introduced, whether it's directly related to Christian's
work, or indeed what the impact is. Let's not get ahead of ourselves.


> We now have *two* broken releases, v4.15 and v4.16 (anything that
> spews error messages and stack traces ad-infinitum in dmesg is, by
> definition, broken).

I haven't seen any evidence that there's still an issue in 4.15, is
there any?


> You're putting this behind a flag now (finally),

I wrote this patch because I realized due to some remark I happened to
see you make this week on IRC that the huge page support in TTM was
enabled for all drivers. Instead of making that kind of remark on IRC,
it would have been more constructive, and more conducive to quick
implementation, to suggest making the feature not active for drivers
which don't need it in a mailing list post.


At least, please do more research before making this kind of negative
post.

P.S. You might also want to look into whether nouveau really should be
hitting swiotlb in these cases.

-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH v2] spi: meson-spicc: Fix error handling in meson_spicc_probe()

[Alexey Khoroshilov]

If devm_spi_register_master() fails in meson_spicc_probe(),
spicc->core is left undisabled. The patch fixes that.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Reviewed-by: Neil Armstrong 
---
v2: Fix subject as Neil Armstrong noted.

 drivers/spi/spi-meson-spicc.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-meson-spicc.c b/drivers/spi/spi-meson-spicc.c
index 5c82910e3480..7fe4488ace57 100644
--- a/drivers/spi/spi-meson-spicc.c
+++ b/drivers/spi/spi-meson-spicc.c
@@ -574,10 +574,15 @@ static int meson_spicc_probe(struct platform_device *pdev)
master->max_speed_hz = rate >> 2;
 
ret = devm_spi_register_master(&pdev->dev, master);
-   if (!ret)
-   return 0;
+   if (ret) {
+   dev_err(&pdev->dev, "spi master registration failed\n");
+   goto out_clk;
+   }
 
-   dev_err(&pdev->dev, "spi master registration failed\n");
+   return 0;
+
+out_clk:
+   clk_disable_unprepare(spicc->core);
 
 out_master:
spi_master_put(master);
-- 
2.7.4

[PATCH] power: supply: ltc2941-battery-gauge: Release device_node in ltc294x_i2c_probe()

[Alexey Khoroshilov]

There is of_node_get(client->dev.of_node) in ltc294x_i2c_probe(),
but these is no of_node_put() somethere in the driver.

The patch adds one on error and normal paths.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/power/supply/ltc2941-battery-gauge.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/power/supply/ltc2941-battery-gauge.c 
b/drivers/power/supply/ltc2941-battery-gauge.c
index 4f129bb4c972..7854a89b3332 100644
--- a/drivers/power/supply/ltc2941-battery-gauge.c
+++ b/drivers/power/supply/ltc2941-battery-gauge.c
@@ -481,7 +481,7 @@ static int ltc294x_i2c_probe(struct i2c_client *client,
if (ret < 0) {
dev_err(&client->dev,
"Could not find lltc,resistor-sense in devicetree\n");
-   return ret;
+   goto err_node_put;
}
info->r_sense = r_sense;
 
@@ -511,7 +511,7 @@ static int ltc294x_i2c_probe(struct i2c_client *client,
if (ret < 0) {
dev_err(&client->dev,
"Could not read status register\n");
-   return ret;
+   goto err_node_put;
}
if (status & LTC2941_REG_STATUS_CHIP_ID)
info->id = LTC2941_ID;
@@ -550,19 +550,25 @@ static int ltc294x_i2c_probe(struct i2c_client *client,
ret = ltc294x_reset(info, prescaler_exp);
if (ret < 0) {
dev_err(&client->dev, "Communication with chip failed\n");
-   return ret;
+   goto err_node_put;
}
 
info->supply = power_supply_register(&client->dev, &info->supply_desc,
 &psy_cfg);
if (IS_ERR(info->supply)) {
dev_err(&client->dev, "failed to register ltc2941\n");
-   return PTR_ERR(info->supply);
+   ret = PTR_ERR(info->supply);
+   goto err_node_put;
} else {
schedule_delayed_work(&info->work, LTC294X_WORK_DELAY * HZ);
}
 
+   of_node_put(np);
return 0;
+
+err_node_put:
+   of_node_put(np);
+   return ret;
 }
 
 static void ltc294x_i2c_shutdown(struct i2c_client *client)
-- 
2.7.4

[PATCH] kbuild: "make tools/help" does not need syncconfig

[Randy Dunlap]

From: Randy Dunlap 

Fix "make tools/help" to skip "make syncconfig".

"make tools/help" currently tries to run "make syncconfig" even
though there is no .config file and one is not needed just to get
help text output.  With no .config file, make says:

*** Configuration file ".config" not found!
*** Please run some configurator (e.g. "make oldconfig" or
*** "make menuconfig" or "make xconfig").
scripts/kconfig/Makefile:40: recipe for target 'syncconfig' failed
make[2]: *** [syncconfig] Error 1
Makefile:525: recipe for target 'syncconfig' failed

and then goes on to run:
make LDFLAGS= MAKEFLAGS=" " O=/linux/linux-next-20180426 subdir=tools -C 
./tools/ help

which produces the requested help text.  However, the "syncconfig"
efforts are not needed, so skip them by making "tools/help" be part
of the no-dot-config-targets rule.

Signed-off-by: Randy Dunlap 
---
 Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20180426.orig/Makefile
+++ linux-next-20180426/Makefile
@@ -224,7 +224,7 @@ clean-targets := %clean mrproper cleando
 no-dot-config-targets := $(clean-targets) \
 cscope gtags TAGS tags help% %docs check% coccicheck \
 $(version_h) headers_% archheaders archscripts \
-kernelversion %src-pkg
+kernelversion %src-pkg tools/help
 
 config-targets := 0
 mixed-targets  := 0

[PATCH] wireless: ipw2100: fix spelling mistake: "decsribed" -> "described"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in comment and in the ord_data text

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
 drivers/net/wireless/intel/ipw2x00/ipw2100.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c 
b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index 236b52423506..7c4f550a1475 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -3732,7 +3732,7 @@ IPW2100_ORD(STAT_TX_HOST_REQUESTS, "requested Host Tx's 
(MSDU)"),
IPW2100_ORD(ASSOCIATED_AP_PTR,
"0 if not associated, else pointer to AP table 
entry"),
IPW2100_ORD(AVAILABLE_AP_CNT,
-   "AP's decsribed in the AP table"),
+   "AP's described in the AP table"),
IPW2100_ORD(AP_LIST_PTR, "Ptr to list of available APs"),
IPW2100_ORD(STAT_AP_ASSNS, "associations"),
IPW2100_ORD(STAT_ASSN_FAIL, "association failures"),
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.h 
b/drivers/net/wireless/intel/ipw2x00/ipw2100.h
index 193947865efd..ce3e35f6b60f 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.h
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.h
@@ -1009,7 +1009,7 @@ typedef enum _ORDINAL_TABLE_1 {   // NS - means Not 
Supported by FW
IPW_ORD_STAT_PERCENT_RETRIES,   // current calculation of % missed tx 
retries
IPW_ORD_ASSOCIATED_AP_PTR,  // If associated, this is ptr to the 
associated
// AP table entry. set to 0 if not associated
-   IPW_ORD_AVAILABLE_AP_CNT,   // # of AP's decsribed in the AP table
+   IPW_ORD_AVAILABLE_AP_CNT,   // # of AP's described in the AP table
IPW_ORD_AP_LIST_PTR,// Ptr to list of available APs
IPW_ORD_STAT_AP_ASSNS,  // # of associations
IPW_ORD_STAT_ASSN_FAIL, // # of association failures
-- 
2.17.0

[PATCH] drm/amd/powerplay: fix spelling mistake: "contruct" -> "construct"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in PP_ASSERT_WITH_CODE message text

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 26fbeafc3c96..726994cf03ea 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -1229,7 +1229,7 @@ static int smu7_enable_dpm_tasks(struct pp_hwmgr *hwmgr)
 
tmp_result = smu7_construct_voltage_tables(hwmgr);
PP_ASSERT_WITH_CODE((0 == tmp_result),
-   "Failed to contruct voltage tables!",
+   "Failed to construct voltage tables!",
result = tmp_result);
}
smum_initialize_mc_reg_table(hwmgr);
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 7cbb56ba6fab..ced1c2aab7a9 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -2829,7 +2829,7 @@ static int vega10_enable_dpm_tasks(struct pp_hwmgr *hwmgr)
 
tmp_result = vega10_construct_voltage_tables(hwmgr);
PP_ASSERT_WITH_CODE(!tmp_result,
-   "Failed to contruct voltage tables!",
+   "Failed to construct voltage tables!",
result = tmp_result);
 
tmp_result = vega10_init_smc_table(hwmgr);
-- 
2.17.0

[PATCH] can: cc770: fix spelling mistake: "comptibility" -> "compatibility"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in module parameter description text

Signed-off-by: Colin Ian King 
---
 drivers/net/can/cc770/cc770.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/cc770/cc770.c b/drivers/net/can/cc770/cc770.c
index d4dd4da23997..da636a22c542 100644
--- a/drivers/net/can/cc770/cc770.c
+++ b/drivers/net/can/cc770/cc770.c
@@ -73,7 +73,7 @@ MODULE_PARM_DESC(msgobj15_eff, "Extended 29-bit frames for 
message object 15 "
 
 static int i82527_compat;
 module_param(i82527_compat, int, 0444);
-MODULE_PARM_DESC(i82527_compat, "Strict Intel 82527 comptibility mode "
+MODULE_PARM_DESC(i82527_compat, "Strict Intel 82527 compatibility mode "
 "without using additional functions");
 
 /*
-- 
2.17.0

[PATCH] [media] media/usbvision: fix spelling mistake: "compresion" -> "compression"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in proc text string

Signed-off-by: Colin Ian King 
---
 drivers/media/usb/usbvision/usbvision-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/usbvision/usbvision-core.c 
b/drivers/media/usb/usbvision/usbvision-core.c
index 3f87fbc80be2..7138c2b606cc 100644
--- a/drivers/media/usb/usbvision/usbvision-core.c
+++ b/drivers/media/usb/usbvision/usbvision-core.c
@@ -1857,7 +1857,7 @@ int usbvision_stream_interrupt(struct usb_usbvision 
*usbvision)
 
 static int usbvision_set_compress_params(struct usb_usbvision *usbvision)
 {
-   static const char proc[] = "usbvision_set_compresion_params: ";
+   static const char proc[] = "usbvision_set_compression_params: ";
int rc;
unsigned char *value = usbvision->ctrl_urb_buffer;
 
-- 
2.17.0

[PATCH][V2] dmaengine: stm32-mdma: fix spelling mistake: "avalaible" -> "available"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in dev_err error message text and make
channel plural.

Signed-off-by: Colin Ian King 
---
 drivers/dma/stm32-mdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/stm32-mdma.c b/drivers/dma/stm32-mdma.c
index 1ac775f93d9e..90d9f6bd905b 100644
--- a/drivers/dma/stm32-mdma.c
+++ b/drivers/dma/stm32-mdma.c
@@ -1521,7 +1521,7 @@ static struct dma_chan *stm32_mdma_of_xlate(struct 
of_phandle_args *dma_spec,
 
c = dma_get_any_slave_channel(&dmadev->ddev);
if (!c) {
-   dev_err(mdma2dev(dmadev), "No more channel avalaible\n");
+   dev_err(mdma2dev(dmadev), "No more channels available\n");
return NULL;
}
 
-- 
2.17.0

Re: PROBLEM: error due to conflicting types during build of kselftests

[Randy Dunlap]

On 04/28/2018 02:42 PM, Jeffrin Thalakkottoor wrote:
> anyway my current is gcc (Debian 7.3.0-16) 7.3.0
> 
> may be you can try ... make -C tools/testing/selftests 2> error.txt

I have a much older gcc, so newer must be better.  :)


> On Sat, Apr 28, 2018 at 5:08 AM, Randy Dunlap  wrote:
>> On 04/20/2018 11:03 AM, Jeffrin Thalakkottoor wrote:
>>> hello,
>>>
>>> the following is the error found...
>>> ---
>>> protection_keys.c:421:5: error: conflicting types for ‘pkey_set’
>>>  int pkey_set(int pkey, unsigned long rights, unsigned long flags)
>>>  ^~~~
>>> 
>>>
>>> to reproduce this error...
>>> make -C tools/testing/selftests
>>
>> Hi,
>>
>> I can't reproduce this problem.  What is your gcc --version?
>>
>> Thanks.
>>
>>> Details about software:
>>>
>>> Linux debian 4.17.0-rc1+ #1 SMP Thu Apr 19 18:59:45 IST 2018 x86_64 
>>> GNU/Linux
>>>
>>> GNU Make 4.2.1
>>> Binutils 2.30
>>> Util-linux   2.31.1
>>> Mount2.31.1
>>> Linux C Library  2.27
>>> Dynamic linker (ldd) 2.27
>>> readlink: missing operand
>>> Try 'readlink --help' for more information.
>>> Procps   3.3.14
>>> Kbd  2.0.4
>>> Console-tools2.0.4
>>> Sh-utils 8.28
>>> Udev 238


-- 
~Randy

[PATCH] Revert "dmaengine: pl330: add DMA_PAUSE feature"

[Frank Mori Hess]

This reverts commit 88987d2c7534a0269f567fb101e6d71a08f0f01d.

The pl330.c pause implementation violates the dmaengine requirement
for no data loss, since it relies on the DMAKILL
instruction.  However, DMAKILL discards in-flight data from the
dma controller's fifo.  This is documented in the dma-330 manual
and I have observed it with hardware doing device-to-memory burst
transfers.  The discarded data may or may not show up in the
residue count, depending on timing (resulting in data corruption
effectively).

Signed-off-by: Frank Mori Hess 
---
 drivers/dma/pl330.c | 28 
 1 file changed, 28 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 6237069001c4..f802bd3b0481 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2290,33 +2290,6 @@ static int pl330_terminate_all(struct dma_chan *chan)
return 0;
 }
 
-/*
- * We don't support DMA_RESUME command because of hardware
- * limitations, so after pausing the channel we cannot restore
- * it to active state. We have to terminate channel and setup
- * DMA transfer again. This pause feature was implemented to
- * allow safely read residue before channel termination.
- */
-static int pl330_pause(struct dma_chan *chan)
-{
-   struct dma_pl330_chan *pch = to_pchan(chan);
-   struct pl330_dmac *pl330 = pch->dmac;
-   unsigned long flags;
-
-   pm_runtime_get_sync(pl330->ddma.dev);
-   spin_lock_irqsave(&pch->lock, flags);
-
-   spin_lock(&pl330->lock);
-   _stop(pch->thread);
-   spin_unlock(&pl330->lock);
-
-   spin_unlock_irqrestore(&pch->lock, flags);
-   pm_runtime_mark_last_busy(pl330->ddma.dev);
-   pm_runtime_put_autosuspend(pl330->ddma.dev);
-
-   return 0;
-}
-
 static void pl330_free_chan_resources(struct dma_chan *chan)
 {
struct dma_pl330_chan *pch = to_pchan(chan);
@@ -3027,7 +3000,6 @@ pl330_probe(struct amba_device *adev, const struct 
amba_id *id)
pd->device_tx_status = pl330_tx_status;
pd->device_prep_slave_sg = pl330_prep_slave_sg;
pd->device_config = pl330_config;
-   pd->device_pause = pl330_pause;
pd->device_terminate_all = pl330_terminate_all;
pd->device_issue_pending = pl330_issue_pending;
pd->src_addr_widths = PL330_DMA_BUSWIDTHS;
-- 
2.11.0

Re: PROBLEM: error due to conflicting types during build of kselftests

[Jeffrin Thalakkottoor]

anyway my current is gcc (Debian 7.3.0-16) 7.3.0

may be you can try ... make -C tools/testing/selftests 2> error.txt

On Sat, Apr 28, 2018 at 5:08 AM, Randy Dunlap  wrote:
> On 04/20/2018 11:03 AM, Jeffrin Thalakkottoor wrote:
>> hello,
>>
>> the following is the error found...
>> ---
>> protection_keys.c:421:5: error: conflicting types for ‘pkey_set’
>>  int pkey_set(int pkey, unsigned long rights, unsigned long flags)
>>  ^~~~
>> 
>>
>> to reproduce this error...
>> make -C tools/testing/selftests
>
> Hi,
>
> I can't reproduce this problem.  What is your gcc --version?
>
> Thanks.
>
>> Details about software:
>>
>> Linux debian 4.17.0-rc1+ #1 SMP Thu Apr 19 18:59:45 IST 2018 x86_64 GNU/Linux
>>
>> GNU Make 4.2.1
>> Binutils 2.30
>> Util-linux   2.31.1
>> Mount2.31.1
>> Linux C Library  2.27
>> Dynamic linker (ldd) 2.27
>> readlink: missing operand
>> Try 'readlink --help' for more information.
>> Procps   3.3.14
>> Kbd  2.0.4
>> Console-tools2.0.4
>> Sh-utils 8.28
>> Udev 238
>>
>
>
> --
> ~Randy



-- 
software engineer
rajagiri school of engineering and technology

Re: [PATCH 3.18 18/52] HID: i2c-hid: fix size check and type usage

[John Smith]

> - if (ret_size > size) {
> + if ((ret_size > size) || (ret_size <= 2)) {
> dev_err(&ihid->client->dev, "%s: incomplete report (%d/%d)\n",
> __func__, size, ret_size);
> return;


This change spams in the dmesg output. Could you please undo this change? Or

- if ((ret_size > size) || (ret_size <= 2)) {
+ if ((ret_size > size) || (ret_size < 2)) {


$ dmesg

[ 1781.266353] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report 
(30/2)
[ 1781.273898] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report 
(30/2)
[ 1781.281464] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report 
(30/2)
[ 1781.289064] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report 
(30/2)
[ 1781.296607] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report 
(30/2)
[ 1781.304131] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report 
(30/2)
[ 1781.311751] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report 
(30/2)
[ 1781.319315] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report 
(30/2)
[ 1781.326882] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report 
(30/2)

LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

[Rafał Miłecki]

Hi,

Due to some maintainers *preferring* BSD-compatible license for DTS
files [0], I was writing mine using ISC. I had no very special reason
for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen
ISC as I read about its "removal of language deemed unnecessary".

I took a moment to look at the new SPDX thing and noticed that:
1) File license-rules.rst provides "LICENSES/other/ISC" as an example
2) License file LICENSES/other/ISC doesn't exist
3) ISC is listed as an *example* under the "Not recommended licenses"

First of all, as ISC is used by some files in the Linux kernel, I
think it's worth adding to the LICENSE/*/ISC.

Secondly, it isn't 100% clear to me if ISC is preferred or not
recommended. File license-rules.rst suggests the later by listing it
as an example for "Not recommended". It's just an example though, so
I'm not 100% sure without seeing it in either: "preferred" or "other"
directories. Also if anyone finds it "Not recommended", can we get a
short explanation why is it so, please?

[0] https://lkml.org/lkml/2016/5/4/707

-- 
Rafał

Re: [PATCH v2 2/2] x86/mm: implement free pmd/pte page interfaces

[Kani, Toshi]

On Sat, 2018-04-28 at 11:02 +0200, j...@8bytes.org wrote:
> On Fri, Apr 27, 2018 at 02:31:51PM +, Kani, Toshi wrote:
> > So, we can add the step 2 on top of this patch.
> >  1. Clear pud/pmd entry.
> >  2. System wide TLB flush <-- TO BE ADDED BY NEW PATCH
> >  3. Free its underlining pmd/pte page.
> 
> This still lacks the page-table synchronization and will thus not fix
> the BUG_ON being triggered.

The BUG_ON issue is specific to PAE that it syncs at the pmd level.
x86/64 does not have this issue since it syncs at the pgd or p4d level.

> > We do not need to revert this patch.  We can make the above change I
> > mentioned.
> 
> Please note that we are not in the merge window anymore and that any fix
> needs to be simple and obviously correct.

Understood.  Changing the x86/32 sync point is risky.  So, I am going to
revert the free page handling for PAE.   

Thanks,
-Toshi

Re: [PATCH net-next v2 4/7] net: mscc: Add initial Ocelot switch support

[kbuild test robot]

Hi Alexandre,

I love your patch! Yet something to improve:

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Alexandre-Belloni/Microsemi-Ocelot-Ethernet-switch-support/20180429-024136
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/net/ethernet/mscc/ocelot_board.c:23:26: sparse: Expected ) at end of 
cast operator
   drivers/net/ethernet/mscc/ocelot_board.c:23:26: sparse: got _be32
   drivers/net/ethernet/mscc/ocelot_board.c:23:26: sparse: cast from unknown 
type
   In file included from include/linux/swab.h:5:0,
from include/uapi/linux/byteorder/little_endian.h:13,
from include/linux/byteorder/little_endian.h:5,
from arch/x86/include/uapi/asm/byteorder.h:5,
from include/asm-generic/bitops/le.h:6,
from arch/x86/include/asm/bitops.h:521,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/interrupt.h:6,
from drivers/net/ethernet/mscc/ocelot_board.c:7:
   drivers/net/ethernet/mscc/ocelot_board.c: In function 'ocelot_parse_ifh':
>> drivers/net/ethernet/mscc/ocelot_board.c:23:27: error: '_be32' undeclared 
>> (first use in this function); did you mean '__be32'?
  ifh[i] = ntohl((__force _be32)ifh[i]);
  ^
   include/uapi/linux/swab.h:114:54: note: in definition of macro '__swab32'
#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
 ^
>> include/linux/byteorder/generic.h:136:21: note: in expansion of macro 
>> '__be32_to_cpu'
#define ___ntohl(x) __be32_to_cpu(x)
^
>> include/linux/byteorder/generic.h:140:18: note: in expansion of macro 
>> '___ntohl'
#define ntohl(x) ___ntohl(x)
 ^~~~
>> drivers/net/ethernet/mscc/ocelot_board.c:23:12: note: in expansion of macro 
>> 'ntohl'
  ifh[i] = ntohl((__force _be32)ifh[i]);
   ^
   drivers/net/ethernet/mscc/ocelot_board.c:23:27: note: each undeclared 
identifier is reported only once for each function it appears in
  ifh[i] = ntohl((__force _be32)ifh[i]);
  ^
   include/uapi/linux/swab.h:114:54: note: in definition of macro '__swab32'
#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
 ^
>> include/linux/byteorder/generic.h:136:21: note: in expansion of macro 
>> '__be32_to_cpu'
#define ___ntohl(x) __be32_to_cpu(x)
^
>> include/linux/byteorder/generic.h:140:18: note: in expansion of macro 
>> '___ntohl'
#define ntohl(x) ___ntohl(x)
 ^~~~
>> drivers/net/ethernet/mscc/ocelot_board.c:23:12: note: in expansion of macro 
>> 'ntohl'
  ifh[i] = ntohl((__force _be32)ifh[i]);
   ^
>> drivers/net/ethernet/mscc/ocelot_board.c:23:33: error: expected ')' before 
>> 'ifh'
  ifh[i] = ntohl((__force _be32)ifh[i]);
^
   include/uapi/linux/swab.h:114:54: note: in definition of macro '__swab32'
#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
 ^
>> include/linux/byteorder/generic.h:136:21: note: in expansion of macro 
>> '__be32_to_cpu'
#define ___ntohl(x) __be32_to_cpu(x)
^
>> include/linux/byteorder/generic.h:140:18: note: in expansion of macro 
>> '___ntohl'
#define ntohl(x) ___ntohl(x)
 ^~~~
>> drivers/net/ethernet/mscc/ocelot_board.c:23:12: note: in expansion of macro 
>> 'ntohl'
  ifh[i] = ntohl((__force _be32)ifh[i]);
   ^
--
   In file included from include/linux/swab.h:5:0,
from include/uapi/linux/byteorder/little_endian.h:13,
from include/linux/byteorder/little_endian.h:5,
from arch/x86/include/uapi/asm/byteorder.h:5,
from include/asm-generic/bitops/le.h:6,
from arch/x86/include/asm/bitops.h:521,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/interrupt.h:6,
from drivers/net//ethernet/mscc/ocelot_board.c:7:
   drivers/net//ethernet/mscc/ocelot_board.c: In function 'ocelot_parse_ifh':
   drivers/net//ethernet/mscc/ocelot_board.c:23:27: error: '_be32' undeclared 
(first use in this function); did you mean '__be32'?
  ifh[i] = ntohl((__force _be32)ifh[i]);
  ^
   include/uapi/linux/swab.h:114:54: note: in definition of macro '__swab32'
#

Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

[Matthew Wilcox]

On Sat, Apr 28, 2018 at 09:46:52PM +0200, Julia Lawall wrote:
> FWIW, here is my semantic patch and the output - it reports on things that
> appear to be too small and things that it doesn't know about.
> 
> What are the relevant pci wrappers?  I didn't find them.

Basically all of the functions in include/linux/pci-dma-compat.h

> too small: drivers/gpu/drm/i915/i915_drv.c:1138: 30
> too small: drivers/net/wireless/broadcom/b43/dma.c:1068: 30
> unknown: sound/pci/ctxfi/cthw20k2.c:2033: DMA_BIT_MASK(dma_bits)
> unknown: sound/pci/ctxfi/cthw20k2.c:2034: DMA_BIT_MASK(dma_bits)

This one's good:

const unsigned int dma_bits = BITS_PER_LONG;

> unknown: drivers/scsi/megaraid/megaraid_sas_base.c:6036: consistent_mask

and this one:
consistent_mask = (instance->adapter_type == VENTURA_SERIES) ?
DMA_BIT_MASK(64) : DMA_BIT_MASK(32);

> unknown: drivers/net/wireless/ath/wil6210/txrx.c:200: 
> DMA_BIT_MASK(wil->dma_addr_size)

if (wil->dma_addr_size > 32)
dma_set_mask_and_coherent(dev,
  DMA_BIT_MASK(wil->dma_addr_size));

> unknown: drivers/net/ethernet/netronome/nfp/nfp_main.c:452: 
> DMA_BIT_MASK(NFP_NET_MAX_DMA_BITS)

drivers/net/ethernet/netronome/nfp/nfp_net.h:#define NFP_NET_MAX_DMA_BITS   
40

> unknown: drivers/gpu/host1x/dev.c:199: host->info->dma_mask

Looks safe ...

drivers/gpu/host1x/bus.c:   device->dev.coherent_dma_mask = 
host1x->dev->coherent_dma_mask;
drivers/gpu/host1x/bus.c:   device->dev.dma_mask = 
&device->dev.coherent_dma_mask;
drivers/gpu/host1x/dev.c:   .dma_mask = DMA_BIT_MASK(32),
drivers/gpu/host1x/dev.c:   .dma_mask = DMA_BIT_MASK(32),
drivers/gpu/host1x/dev.c:   .dma_mask = DMA_BIT_MASK(34),
drivers/gpu/host1x/dev.c:   .dma_mask = DMA_BIT_MASK(34),
drivers/gpu/host1x/dev.c:   .dma_mask = DMA_BIT_MASK(34),
drivers/gpu/host1x/dev.c:   dma_set_mask_and_coherent(host->dev, 
host->info->dma_mask);
drivers/gpu/host1x/dev.h:   u64 dma_mask; /* mask of addressable memory */

... but that reminds us that maybe some drivers aren't using dma_set_mask()
but rather touching dma_mask directly.

... 57 more to look at ...

Re: [PATCH v2] efi: Ignore unrealistically large option roms

[Hans de Goede]

Hi,

On 28-04-18 08:40, Ard Biesheuvel wrote:

Hi Hans,

On 27 April 2018 at 23:35, Hans de Goede  wrote:

setup_efi_pci() tries to save a copy of each PCI option ROM as this may
be necessary for the device driver for the PCI device to have access too.

On some systems the efi_pci_io_protocol_64's romimage and romsize fields
contain invalid data, which looks a bit like pointers pointing back into
other EFI code or data. Interpreting these pointers as romsize leads to
a very large value and if we then try to alloc this amount of memory to
save a copy the alloc call fails.

This leads to a "Failed to alloc mem for rom" error being printed on the
EFI console for each PCI device.

This commit avoids the printing of these errors, by checking romsize
before doing the alloc and if it is larger then 256M silently ignore the
ROM fields instead of trying to alloc mem and fail.



The UEFI spec limits the size of option ROMs to 16 MiB, so I'd prefer
we use that as the upper bound instead.

With that changed,

Reviewed-by: Ard Biesheuvel 


Thanks for the review, fixed for v3 which I'm about to send.


or I can take it via the EFI tree if desired.


I've no preference for how this goes upstream. x86 folks, please let
us know if you will take this, or if you would prefer for this to
go upstream through the EFI tree.

Regards,

Hans

[PATCH v3] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

[Moritz Fischer]

Request IRQ with IRQF_SHARED flag to enable setups with multiple
instances of the core sharing a single IRQ line.
This works out since the IRQ handler already checks if there is
an actual IRQ pending and returns IRQ_NONE otherwise.

Acked-by: Lars-Peter Clausen 
Signed-off-by: Moritz Fischer 
---

Changes from v2:
- Reworded commit message

Changes from v1:
- Added Lars' Acked-by
- Dropped patch [1/2] and changed accordingly

---
 drivers/dma/dma-axi-dmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
index 2419fe524daa..15b2453d2647 100644
--- a/drivers/dma/dma-axi-dmac.c
+++ b/drivers/dma/dma-axi-dmac.c
@@ -687,7 +687,7 @@ static int axi_dmac_probe(struct platform_device *pdev)
if (ret)
goto err_unregister_device;
 
-   ret = request_irq(dmac->irq, axi_dmac_interrupt_handler, 0,
+   ret = request_irq(dmac->irq, axi_dmac_interrupt_handler, IRQF_SHARED,
dev_name(&pdev->dev), dmac);
if (ret)
goto err_unregister_of;
-- 
2.17.0

Re: [greybus-dev] [PATCH v2] staging: greybus: Use gpio_is_valid()

[Alex Elder]

On 04/27/2018 11:35 PM, Arvind Yadav wrote:
> Replace the manual validity checks for the GPIO with the
> gpio_is_valid().
> 
> Signed-off-by: Arvind Yadav 

Looks good.

Reviewed-by: Alex Elder 

> ---
> chnage in v2 :
>  Returning invalid gpio as error instead of -ENODEV.
> 
>  drivers/staging/greybus/arche-platform.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/greybus/arche-platform.c 
> b/drivers/staging/greybus/arche-platform.c
> index 83254a7..c3a7da5 100644
> --- a/drivers/staging/greybus/arche-platform.c
> +++ b/drivers/staging/greybus/arche-platform.c
> @@ -448,7 +448,7 @@ static int arche_platform_probe(struct platform_device 
> *pdev)
>   arche_pdata->svc_reset_gpio = of_get_named_gpio(np,
>   "svc,reset-gpio",
>   0);
> - if (arche_pdata->svc_reset_gpio < 0) {
> + if (!gpio_is_valid(arche_pdata->svc_reset_gpio)) {
>   dev_err(dev, "failed to get reset-gpio\n");
>   return arche_pdata->svc_reset_gpio;
>   }
> @@ -468,7 +468,7 @@ static int arche_platform_probe(struct platform_device 
> *pdev)
>   arche_pdata->svc_sysboot_gpio = of_get_named_gpio(np,
> "svc,sysboot-gpio",
> 0);
> - if (arche_pdata->svc_sysboot_gpio < 0) {
> + if (!gpio_is_valid(arche_pdata->svc_sysboot_gpio)) {
>   dev_err(dev, "failed to get sysboot gpio\n");
>   return arche_pdata->svc_sysboot_gpio;
>   }
> @@ -487,7 +487,7 @@ static int arche_platform_probe(struct platform_device 
> *pdev)
>   arche_pdata->svc_refclk_req = of_get_named_gpio(np,
>   "svc,refclk-req-gpio",
>   0);
> - if (arche_pdata->svc_refclk_req < 0) {
> + if (!gpio_is_valid(arche_pdata->svc_refclk_req)) {
>   dev_err(dev, "failed to get svc clock-req gpio\n");
>   return arche_pdata->svc_refclk_req;
>   }
> 

[PATCH] ext4: add crc32c soft dependency

[Dmitry V. Levin]

Starting with commit a45403b51582, ext4 unconditionally requires
a crc32c provider, which broke certain mkinitrd setups.

Add a soft dependency on crc32c so that mkinitrd, dracut, and other
initrd image generators could include the required helper module.

The dependency on crc32c is quite hard but there seems to be no
mechanism to specify a dependency on an alias, so let's use this
soft dependency as a workaround.

Suggested-by: Alexey Gladkov 
Fixes: a45403b51582 ("ext4: always initialize the crc32c checksum driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry V. Levin 
---
 fs/ext4/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 185f7e6..eb104e8 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -5886,5 +5886,6 @@ static void __exit ext4_exit_fs(void)
 MODULE_AUTHOR("Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, 
Theodore Ts'o and others");
 MODULE_DESCRIPTION("Fourth Extended Filesystem");
 MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: crc32c");
 module_init(ext4_init_fs)
 module_exit(ext4_exit_fs)

-- 
ldv

Re: [PATCH] thunderbolt: Handle NULL boot ACL entries properly

[Yehezkel Bernat]

On Fri, Apr 27, 2018 at 6:58 PM Mika Westerberg <
mika.westerb...@linux.intel.com> wrote:

> If the boot ACL entry is already NULL we should not fill in the upper
> two DWs with 0xf. Otherwise they are not shown as empty entries
> when the sysfs attribute is read.
> Fixes: 9aaa3b8b4c56 ("thunderbolt: Add support for preboot ACL")
> Signed-off-by: Mika Westerberg 
> ---
>drivers/thunderbolt/icm.c | 2 +-
>1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/drivers/thunderbolt/icm.c b/drivers/thunderbolt/icm.c
> index 2d2ceda9aa26..aec6a82989d8 100644
> --- a/drivers/thunderbolt/icm.c
> +++ b/drivers/thunderbolt/icm.c
> @@ -1255,7 +1255,7 @@ static int icm_ar_get_boot_acl(struct tb *tb,
uuid_t *uuids, size_t nuuids)
>   /* Map empty entries to null UUID */
>   uuid[0] = 0;
>   uuid[1] = 0;
> -   } else {
> +   } else if (uuid[0] != 0 && uuid[1] != 0) {

Maybe || instead of &&?
I'd think it's enough for one of them to be non-zero to be a valid UUID.

>   /* Upper two DWs are always one's */
>   uuid[2] = 0x;
>   uuid[3] = 0x;
> --
> 2.17.0

Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

[Julia Lawall]

On Sat, 28 Apr 2018, Luis R. Rodriguez wrote:

> On Sat, Apr 28, 2018 at 01:42:21AM -0700, Christoph Hellwig wrote:
> > On Fri, Apr 27, 2018 at 04:14:56PM +, Luis R. Rodriguez wrote:
> > > Do we have a list of users for x86 with a small DMA mask?
> > > Or, given that I'm not aware of a tool to be able to look
> > > for this in an easy way, would it be good to find out which
> > > x86 drivers do have a small mask?
> >
> > Basically you'll have to grep for calls to dma_set_mask/
> > dma_set_coherent_mask/dma_set_mask_and_coherent and their pci_*
> > wrappers with masks smaller 32-bit.  Some use numeric values,
> > some use DMA_BIT_MASK and various places uses local variables
> > or struct members to parse them, so finding them will be a bit
> > more work.  Nothing a coccinelle expert couldn't solve, though :)
>
> Thing is unless we have a specific flag used consistently I don't believe we
> can do this search with Coccinelle. ie, if we have local variables and based 
> on
> some series of variables things are set, this makes the grammatical expression
> difficult to express.  So Cocinelle is not designed for this purpose.
>
> But I believe smatch [0] is intended exactly for this sort of purpose, is that
> right Dan? I gave a cursory look and I think it'd take me significant time to
> get such hunt down.
>
> [0] https://lwn.net/Articles/691882/

FWIW, here is my semantic patch and the output - it reports on things that
appear to be too small and things that it doesn't know about.

What are the relevant pci wrappers?  I didn't find them.

julia

@initialize:ocaml@
@@

let clean s = String.concat "" (Str.split (Str.regexp " ") s)

let shorten s = List.nth (Str.split (Str.regexp "linux-next/") s) 1

@bad1 exists@
identifier i,x;
expression e;
position p;
@@

x = DMA_BIT_MASK(i)
...
\(dma_set_mask@p\|dma_set_coherent_mask@p\|dma_set_mask_and_coherent@p\)(e,x)

@bad2@
identifier i;
expression e;
position p;
@@

\(dma_set_mask@p\|dma_set_coherent_mask@p\|dma_set_mask_and_coherent@p\)
   (e,DMA_BIT_MASK(i))

@ok1 exists@
identifier x;
expression e;
constant c;
position p != bad1.p;
@@

x = \(DMA_BIT_MASK(c)\|0x\)
...
\(dma_set_mask@p\|dma_set_coherent_mask@p\|dma_set_mask_and_coherent@p\)(e,x)

@script:ocaml@
p << ok1.p;
c << ok1.c;
@@

let c = int_of_string c in
if c < 32
then
  let p = List.hd p in
  Printf.printf "too small: %s:%d: %d\n" (shorten p.file) p.line c

@ok2@
expression e;
constant c;
position p != bad2.p;
@@

\(dma_set_mask@p\|dma_set_coherent_mask@p\|dma_set_mask_and_coherent@p\)
   (e,\(DMA_BIT_MASK(c)\|0x\))

@script:ocaml@
p << ok2.p;
c << ok2.c;
@@

let c = int_of_string c in
if c < 32
then
  let p = List.hd p in
  Printf.printf "too small: %s:%d: %d\n" (shorten p.file) p.line c

@unk@
expression e,e1 != ATA_DMA_MASK;
position p != {ok1.p,ok2.p};
@@

\(dma_set_mask@p\|dma_set_coherent_mask@p\|dma_set_mask_and_coherent@p\)(e,e1)

@script:ocaml@
p << unk.p;
e1 << unk.e1;
@@

let p = List.hd p in
Printf.printf "unknown: %s:%d: %s\n" (shorten p.file) p.line (clean e1)

-

too small: drivers/gpu/drm/i915/i915_drv.c:1138: 30
too small: drivers/net/wireless/broadcom/b43/dma.c:1068: 30
unknown: sound/pci/ctxfi/cthw20k2.c:2033: DMA_BIT_MASK(dma_bits)
unknown: sound/pci/ctxfi/cthw20k2.c:2034: DMA_BIT_MASK(dma_bits)
unknown: drivers/scsi/megaraid/megaraid_sas_base.c:6036: consistent_mask
unknown: drivers/net/wireless/ath/wil6210/txrx.c:200: 
DMA_BIT_MASK(wil->dma_addr_size)
unknown: drivers/net/ethernet/netronome/nfp/nfp_main.c:452: 
DMA_BIT_MASK(NFP_NET_MAX_DMA_BITS)
unknown: drivers/gpu/host1x/dev.c:199: host->info->dma_mask
unknown: drivers/iommu/arm-smmu-v3.c:2691: DMA_BIT_MASK(smmu->oas)
too small: sound/pci/es1968.c:2692: 28
too small: sound/pci/es1968.c:2693: 28
too small: drivers/net/wireless/broadcom/b43legacy/dma.c:809: 30
unknown: drivers/virtio/virtio_mmio.c:573: DMA_BIT_MASK(32+PAGE_SHIFT)
unknown: drivers/ata/sata_nv.c:762: pp->adma_dma_mask
unknown: drivers/dma/mmp_pdma.c:1094: pdev->dev->coherent_dma_mask
too small: sound/pci/maestro3.c:2557: 28
too small: sound/pci/maestro3.c:2558: 28
too small: sound/pci/ice1712/ice1712.c:2533: 28
too small: sound/pci/ice1712/ice1712.c:2534: 28
unknown: drivers/net/wireless/ath/wil6210/pmc.c:132: 
DMA_BIT_MASK(wil->dma_addr_size)
unknown: drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c:313: 
DMA_BIT_MASK(tdev->func->iommu_bit)
unknown: drivers/net/ethernet/synopsys/dwc-xlgmac-common.c:96: 
DMA_BIT_MASK(pdata->hw_feat.dma_width)
too small: sound/pci/als4000.c:874: 24
too small: sound/pci/als4000.c:875: 24
unknown: drivers/hwtracing/coresight/coresight-tmc.c:335: DMA_BIT_MASK(dma_mask)
unknown: drivers/dma/xilinx/xilinx_dma.c:2634: DMA_BIT_MASK(addr_width)
too small: sound/pci/sonicvibes.c:1262: 24
too small: sound/pci/sonicvibes.c:1263: 24
too small: sound/pci/es1938.c:1600: 24
too small: sound/pci/es1938.c:1601: 24
unknown: drivers/crypto/ccree/cc_driver.c:260: dma_mask
unknown: sound/pci/hda/hda_intel.c:1888: DMA_B

Re: [PATCH net-next v2 4/7] net: mscc: Add initial Ocelot switch support

[kbuild test robot]

Hi Alexandre,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Alexandre-Belloni/Microsemi-Ocelot-Ethernet-switch-support/20180429-024136
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

All warnings (new ones prefixed by >>):

   In file included from include/linux/swab.h:5:0,
from include/uapi/linux/byteorder/little_endian.h:13,
from include/linux/byteorder/little_endian.h:5,
from arch/sh/include/uapi/asm/byteorder.h:6,
from arch/sh/include/asm/bitops.h:12,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/interrupt.h:6,
from drivers/net/ethernet/mscc/ocelot_board.c:7:
   drivers/net/ethernet/mscc/ocelot_board.c: In function 'ocelot_parse_ifh':
   drivers/net/ethernet/mscc/ocelot_board.c:23:27: error: '_be32' undeclared 
(first use in this function); did you mean '__be32'?
  ifh[i] = ntohl((__force _be32)ifh[i]);
  ^
   include/uapi/linux/swab.h:117:32: note: in definition of macro '__swab32'
 (__builtin_constant_p((__u32)(x)) ? \
   ^
   include/linux/byteorder/generic.h:136:21: note: in expansion of macro 
'__be32_to_cpu'
#define ___ntohl(x) __be32_to_cpu(x)
^
   include/linux/byteorder/generic.h:140:18: note: in expansion of macro 
'___ntohl'
#define ntohl(x) ___ntohl(x)
 ^~~~
   drivers/net/ethernet/mscc/ocelot_board.c:23:12: note: in expansion of macro 
'ntohl'
  ifh[i] = ntohl((__force _be32)ifh[i]);
   ^
   drivers/net/ethernet/mscc/ocelot_board.c:23:27: note: each undeclared 
identifier is reported only once for each function it appears in
  ifh[i] = ntohl((__force _be32)ifh[i]);
  ^
   include/uapi/linux/swab.h:117:32: note: in definition of macro '__swab32'
 (__builtin_constant_p((__u32)(x)) ? \
   ^
   include/linux/byteorder/generic.h:136:21: note: in expansion of macro 
'__be32_to_cpu'
#define ___ntohl(x) __be32_to_cpu(x)
^
   include/linux/byteorder/generic.h:140:18: note: in expansion of macro 
'___ntohl'
#define ntohl(x) ___ntohl(x)
 ^~~~
   drivers/net/ethernet/mscc/ocelot_board.c:23:12: note: in expansion of macro 
'ntohl'
  ifh[i] = ntohl((__force _be32)ifh[i]);
   ^
   drivers/net/ethernet/mscc/ocelot_board.c:23:33: error: expected ')' before 
'ifh'
  ifh[i] = ntohl((__force _be32)ifh[i]);
^
   include/uapi/linux/swab.h:117:32: note: in definition of macro '__swab32'
 (__builtin_constant_p((__u32)(x)) ? \
   ^
   include/linux/byteorder/generic.h:136:21: note: in expansion of macro 
'__be32_to_cpu'
#define ___ntohl(x) __be32_to_cpu(x)
^
   include/linux/byteorder/generic.h:140:18: note: in expansion of macro 
'___ntohl'
#define ntohl(x) ___ntohl(x)
 ^~~~
   drivers/net/ethernet/mscc/ocelot_board.c:23:12: note: in expansion of macro 
'ntohl'
  ifh[i] = ntohl((__force _be32)ifh[i]);
   ^
   drivers/net/ethernet/mscc/ocelot_board.c:23:33: error: expected ')' before 
'ifh'
  ifh[i] = ntohl((__force _be32)ifh[i]);
^
   include/uapi/linux/swab.h:18:12: note: in definition of macro 
'___constant_swab32'
 (((__u32)(x) & (__u32)0x00ffUL) << 24) |  \
   ^
>> include/uapi/linux/byteorder/little_endian.h:40:26: note: in expansion of 
>> macro '__swab32'
#define __be32_to_cpu(x) __swab32((__force __u32)(__be32)(x))
 ^~~~
   include/linux/byteorder/generic.h:136:21: note: in expansion of macro 
'__be32_to_cpu'
#define ___ntohl(x) __be32_to_cpu(x)
^
   include/linux/byteorder/generic.h:140:18: note: in expansion of macro 
'___ntohl'
#define ntohl(x) ___ntohl(x)
 ^~~~
   drivers/net/ethernet/mscc/ocelot_board.c:23:12: note: in expansion of macro 
'ntohl'
  ifh[i] = ntohl((__force _be32)ifh[i]);
   ^
   drivers/net/ethernet/mscc/ocelot_board.c:23:33: error: expected ')' before 
'ifh'
  ifh[i] = ntohl((__force _be32)ifh[i]);
^
   include/uapi/linux/swab.h:19:12: note: in definition of macro 
'___constant_swab32'
 (((__u32)(x) & (__u32)0xff00

Re: [PATCH v2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

[Moritz Fischer]

On Sat, Apr 28, 2018 at 10:40:43AM +0530, Vinod Koul wrote:
> On Fri, Apr 27, 2018 at 05:18:29PM +0200, Lars-Peter Clausen wrote:
> > On 04/27/2018 05:15 PM, Moritz Fischer wrote:
> > > Hi Vinod,
> > > 
> > > On Fri, Apr 27, 2018 at 12:08 AM, Vinod Koul  wrote:
> > >> On Fri, Apr 27, 2018 at 08:53:39AM +0200, Lars-Peter Clausen wrote:
> > >>> On 04/27/2018 07:11 AM, Vinod Koul wrote:
> >  On Thu, Apr 26, 2018 at 10:40:00AM -0700, Moritz Fischer wrote:
> > > Request IRQ with IRQF_SHARED flag. This works since the interrupt
> > > handler already checks if there is an actual IRQ pending and returns
> > > IRQ_NONE otherwise.
> > 
> >  hmmm what are we trying to fix here? Is your device on a shared line 
> >  or not?
> > >>>
> > >>> IRQF_SHARED does not mean that the IRQ is on a shared line. It means 
> > >>> that
> > >>> the driver can handle it if the IRQ is on a shared line. Since the 
> > >>> driver
> > >>> can handle it setting the flag is a good idea since this enables 
> > >>> usecases
> > >>> where the line is shared.
> > >>
> > >> Yes that is correct indeed, but what is the motivation for the change.
> > >>
> > >> If you never expect this to be in shared environment why to do this?
> > >> Sorry but "it works" is not a good enough reason for this change, to 
> > >> enable
> > >> usecases where the line is shared is a good reason :)
> > > 
> > > Remember, this is an FPGA soft core. I happen to have a design [1] where 
> > > it
> > > is hooked up with multiple of them on one IRQ line, so to make this work,
> > > I need this change.
> > 
> > I think what Vinod is asking for is a change to the commit message saying
> > that "this change enables the driver to be used with devices where the
> > interrupt line is shared".
> 
> Correct, changelog need to reflect why a change was made, down the line
> people need to know the reasons, sometimes it might be even you..

Ok, communication is hard :) Will resubmit with fixed commit message,

Thanks for your feedback,

Moritz

Re: [PATCH v2 0/3] Rework write error handling in pblk

[Matias Bjørling]

On 4/23/18 10:45 PM, Hans Holmberg wrote:

From: Hans Holmberg 

This patch series fixes the(currently incomplete) write error handling
in pblk by:

  * queuing and re-submitting failed writes in the write buffer
  * evacuating valid data data in lines with write failures, so the
chunk(s) with write failures can be reset to a known state by the fw

Lines with failures in smeta are put back on the free list.
Failed chunks will be reset on the next use.

If a write failes in emeta, the lba list is cached so the line can be
garbage collected without scanning the out-of-band area.

Changes in V2:
- Added the recov_writes counter increase to the new path
- Moved lba list emeta reading during gc to a separate function
- Allocating the saved lba list with pblk_malloc instead of kmalloc
- Fixed formatting issues
- Removed dead code

Hans Holmberg (3):
   lightnvm: pblk: rework write error recovery path
   lightnvm: pblk: garbage collect lines with failed writes
   lightnvm: pblk: fix smeta write error path

  drivers/lightnvm/pblk-core.c |  52 +++-
  drivers/lightnvm/pblk-gc.c   | 102 +--
  drivers/lightnvm/pblk-init.c |  47 ---
  drivers/lightnvm/pblk-rb.c   |  39 --
  drivers/lightnvm/pblk-recovery.c |  91 -
  drivers/lightnvm/pblk-rl.c   |  29 -
  drivers/lightnvm/pblk-sysfs.c|  15 ++-
  drivers/lightnvm/pblk-write.c| 269 ++-
  drivers/lightnvm/pblk.h  |  36 --
  9 files changed, 384 insertions(+), 296 deletions(-)



Thanks Hans. I've applied 1 & 3. The second did not apply cleanly to 
for-4.18/core. Could you please resend a rebased version?

[PATCH net-next 1/2 v4] uevent: add alloc_uevent_skb() helper

[Christian Brauner]

This patch adds alloc_uevent_skb() in preparation for follow up patches.

Signed-off-by: Christian Brauner 
---
v3->v4:
* non-functional changes:
  initialize some variables again explicitly to make it obvious to
  readers that they are correctly set
v2->v3:
* new approach: patch added
v1->v2:
* different approach in different patchset
v0->v1:
* different approach in different patchset
---
 lib/kobject_uevent.c | 47 
 1 file changed, 34 insertions(+), 13 deletions(-)

diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index 15ea216a67ce..649bf60a9440 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -296,6 +297,38 @@ static void cleanup_uevent_env(struct subprocess_info 
*info)
 }
 #endif
 
+#ifdef CONFIG_NET
+static struct sk_buff *alloc_uevent_skb(struct kobj_uevent_env *env,
+   const char *action_string,
+   const char *devpath)
+{
+   struct netlink_skb_parms *parms;
+   struct sk_buff *skb = NULL;
+   char *scratch;
+   size_t len;
+
+   /* allocate message with maximum possible size */
+   len = strlen(action_string) + strlen(devpath) + 2;
+   skb = alloc_skb(len + env->buflen, GFP_KERNEL);
+   if (!skb)
+   return NULL;
+
+   /* add header */
+   scratch = skb_put(skb, len);
+   sprintf(scratch, "%s@%s", action_string, devpath);
+
+   skb_put_data(skb, env->buf, env->buflen);
+
+   parms = &NETLINK_CB(skb);
+   parms->creds.uid = GLOBAL_ROOT_UID;
+   parms->creds.gid = GLOBAL_ROOT_GID;
+   parms->dst_group = 1;
+   parms->portid = 0;
+
+   return skb;
+}
+#endif
+
 static int kobject_uevent_net_broadcast(struct kobject *kobj,
struct kobj_uevent_env *env,
const char *action_string,
@@ -314,22 +347,10 @@ static int kobject_uevent_net_broadcast(struct kobject 
*kobj,
continue;
 
if (!skb) {
-   /* allocate message with the maximum possible size */
-   size_t len = strlen(action_string) + strlen(devpath) + 
2;
-   char *scratch;
-
retval = -ENOMEM;
-   skb = alloc_skb(len + env->buflen, GFP_KERNEL);
+   skb = alloc_uevent_skb(env, action_string, devpath);
if (!skb)
continue;
-
-   /* add header */
-   scratch = skb_put(skb, len);
-   sprintf(scratch, "%s@%s", action_string, devpath);
-
-   skb_put_data(skb, env->buf, env->buflen);
-
-   NETLINK_CB(skb).dst_group = 1;
}
 
retval = netlink_broadcast_filtered(uevent_sock, skb_get(skb),
-- 
2.17.0

[PATCH net-next 2/2 v4] netns: restrict uevents

[Christian Brauner]

commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces")

enabled sending hotplug events into all network namespaces back in 2010.
Over time the set of uevents that get sent into all network namespaces has
shrunk. We have now reached the point where hotplug events for all devices
that carry a namespace tag are filtered according to that namespace.
Specifically, they are filtered whenever the namespace tag of the kobject
does not match the namespace tag of the netlink socket.
Currently, only network devices carry namespace tags (i.e. network
namespace tags). Hence, uevents for network devices only show up in the
network namespace such devices are created in or moved to.

However, any uevent for a kobject that does not have a namespace tag
associated with it will not be filtered and we will broadcast it into all
network namespaces. This behavior stopped making sense when user namespaces
were introduced.

This patch simplifies and fixes couple of things:
- Split codepath for sending uevents by kobject namespace tags:
  1. Untagged kobjects - uevent_net_broadcast_untagged():
 Untagged kobjects will be broadcast into all uevent sockets recorded
 in uevent_sock_list, i.e. into all network namespacs owned by the
 intial user namespace.
  2. Tagged kobjects - uevent_net_broadcast_tagged():
 Tagged kobjects will only be broadcast into the network namespace they
 were tagged with.
  Handling of tagged kobjects in 2. does not cause any semantic changes.
  This is just splitting out the filtering logic that was handled by
  kobj_bcast_filter() before.
  Handling of untagged kobjects in 1. will cause a semantic change. The
  reasons why this is needed and ok have been discussed in [1]. Here is a
  short summary:
  - Userspace ignores uevents from network namespaces that are not owned by
the intial user namespace:
Uevents are filtered by userspace in a user namespace because the
received uid != 0. Instead the uid associated with the event will be
65534 == "nobody" because the global root uid is not mapped.
This means we can safely and without introducing regressions modify the
kernel to not send uevents into all network namespaces whose owning
user namespace is not the initial user namespace because we know that
userspace will ignore the message because of the uid anyway.
I have a) verified that is is true for every udev implementation out
there b) that this behavior has been present in all udev
implementations from the very beginning.
  - Thundering herd:
Broadcasting uevents into all network namespaces introduces significant
overhead.
All processes that listen to uevents running in non-initial user
namespaces will end up responding to uevents that will be meaningless
to them. Mainly, because non-initial user namespaces cannot easily
manage devices unless they have a privileged host-process helping them
out. This means that there will be a thundering herd of activity when
there shouldn't be any.
  - Removing needless overhead/Increasing performance:
Currently, the uevent socket for each network namespace is added to the
global variable uevent_sock_list. The list itself needs to be protected
by a mutex. So everytime a uevent is generated the mutex is taken on
the list. The mutex is held *from the creation of the uevent (memory
allocation, string creation etc. until all uevent sockets have been
handled*. This is aggravated by the fact that for each uevent socket
that has listeners the mc_list must be walked as well which means we're
talking O(n^2) here. Given that a standard Linux workload usually has
quite a lot of network namespaces and - in the face of containers - a
lot of user namespaces this quickly becomes a performance problem (see
"Thundering herd" above). By just recording uevent sockets of network
namespaces that are owned by the initial user namespace we
significantly increase performance in this codepath.
  - Injecting uevents:
There's a valid argument that containers might be interested in
receiving device events especially if they are delegated to them by a
privileged userspace process. One prime example are SR-IOV enabled
devices that are explicitly designed to be handed of to other users
such as VMs or containers.
This use-case can now be correctly handled since
commit 692ec06d7c92 ("netns: send uevent messages"). This commit
introduced the ability to send uevents from userspace. As such we can
let a sufficiently privileged (CAP_SYS_ADMIN in the owning user
namespace of the network namespace of the netlink socket) userspace
process make a decision what uevents should be sent. This removes the
need to blindly broadcast uevents into all user namespaces and provides
a performant and safe solution to this problem.
  - Filtering logic:
This patch filters by *owning user namespace of the 

[PATCH net-next 0/2 v4] netns: uevent filtering

[Christian Brauner]

Hey everyone,

This is the new approach to uevent filtering as discussed (see the
threads in [1], [2], and [3]). It only contains *non-functional
changes*.

This series deals with with fixing up uevent filtering logic:
- uevent filtering logic is simplified
- locking time on uevent_sock_list is minimized
- tagged and untagged kobjects are handled in separate codepaths
- permissions for userspace are fixed for network device uevents in
  network namespaces owned by non-initial user namespaces
  Udev is now able to see those events correctly which it wasn't before.
  For example, moving a physical device into a network namespace not
  owned by the initial user namespaces before gave:

  root@xen1:~# udevadm --debug monitor -k
  calling: monitor
  monitor will print the received events for:
  KERNEL - the kernel uevent

  sender uid=65534, message ignored
  sender uid=65534, message ignored
  sender uid=65534, message ignored
  sender uid=65534, message ignored
  sender uid=65534, message ignored

  and now after the discussion and solution in [3] correctly gives:

  root@xen1:~# udevadm --debug monitor -k
  calling: monitor
  monitor will print the received events for:
  KERNEL - the kernel uevent

  KERNEL[625.301042] add  
/devices/pci:00/:00:02.0/:01:00.1/net/enp1s0f1 (net)
  KERNEL[625.301109] move 
/devices/pci:00/:00:02.0/:01:00.1/net/enp1s0f1 (net)
  KERNEL[625.301138] move 
/devices/pci:00/:00:02.0/:01:00.1/net/eth1 (net)
  KERNEL[655.333272] remove 
/devices/pci:00/:00:02.0/:01:00.1/net/eth1 (net)

Thanks!
Christian

[1]: https://lkml.org/lkml/2018/4/4/739
[2]: https://lkml.org/lkml/2018/4/26/767
[3]: https://lkml.org/lkml/2018/4/26/738

Christian Brauner (2):
  uevent: add alloc_uevent_skb() helper
  netns: restrict uevents

 lib/kobject_uevent.c | 180 ++-
 1 file changed, 128 insertions(+), 52 deletions(-)

-- 
2.17.0

Re: [PATCH net-next 2/2 v3] netns: restrict uevents

[Christian Brauner]

On Fri, Apr 27, 2018 at 11:30:26AM -0500, Eric W. Biederman wrote:
> Christian Brauner  writes:
> > ---
> >  lib/kobject_uevent.c | 140 ++-
> >  1 file changed, 99 insertions(+), 41 deletions(-)
> >
> > diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
> > index c3cb110f663b..d8ce5e6d83af 100644
> > --- a/lib/kobject_uevent.c
> > +++ b/lib/kobject_uevent.c
> >  
> > +static int uevent_net_broadcast_tagged(struct sock *usk,
> > +  struct kobj_uevent_env *env,
> > +  const char *action_string,
> > +  const char *devpath)
> > +{
> > +   struct user_namespace *owning_user_ns = sock_net(usk)->user_ns;
> > +   struct sk_buff *skb = NULL;
> > +   int ret;
> > +
> > +   skb = alloc_uevent_skb(env, action_string, devpath);
> > +   if (!skb)
> > +   return -ENOMEM;
> > +
> > +   /* fix credentials */
> > +   if (owning_user_ns != &init_user_ns) {
> 
> Nit: This test is just a performance optimization as such is not
>   necessary.  That is we can safely unconditionally set the
>   credentials this way.

alloc_uevent_skb() will now set

parms = &NETLINK_CB(skb);
parms->creds.uid = GLOBAL_ROOT_UID;
parms->creds.gid = GLOBAL_ROOT_GID;
parms->dst_group = 1;
parms->portid = 0;

explicitly. So repeating that initialization unconditionally here does
not make sense to me. Also, this hits map_uid_down() in user_namespace.c
which is a known-hotpath (Remember the extensive testing we did back for
uidmap limit bumping from 5 to 340.). And even though it might not
matter much in this case there's no need to hit this code. The condition
also make it obvious that only non-initial user namespace uevent sockets
need fixing.

Christian

> 
> > +   struct netlink_skb_parms *parms = &NETLINK_CB(skb);
> > +   kuid_t root_uid;
> > +   kgid_t root_gid;
> > +
> > +   /* fix uid */
> > +   root_uid = make_kuid(owning_user_ns, 0);
> > +   if (!uid_valid(root_uid))
> > +   root_uid = GLOBAL_ROOT_UID;
> > +   parms->creds.uid = root_uid;
> > +
> > +   /* fix gid */
> > +   root_gid = make_kgid(owning_user_ns, 0);
> > +   if (!gid_valid(root_gid))
> > +   root_gid = GLOBAL_ROOT_GID;
> > +   parms->creds.gid = root_gid;
> > +   }
> > +
> > +   ret = netlink_broadcast(usk, skb, 0, 1, GFP_KERNEL);
> > +   /* ENOBUFS should be handled in userspace */
> > +   if (ret == -ENOBUFS || ret == -ESRCH)
> > +   ret = 0;
> > +
> > +   return ret;
> > +}
> > +#endif

Re: [PATCH net-next 1/2 v3] uevent: add alloc_uevent_skb() helper

[Christian Brauner]

On Fri, Apr 27, 2018 at 11:39:44AM -0500, Eric W. Biederman wrote:
> Christian Brauner  writes:
> 
> > This patch adds alloc_uevent_skb() in preparation for follow up patches.
> >
> > Signed-off-by: Christian Brauner 
> > ---
> >  lib/kobject_uevent.c | 39 ++-
> >  1 file changed, 26 insertions(+), 13 deletions(-)
> >
> > diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
> > index 15ea216a67ce..c3cb110f663b 100644
> > --- a/lib/kobject_uevent.c
> > +++ b/lib/kobject_uevent.c
> > @@ -296,6 +296,31 @@ static void cleanup_uevent_env(struct subprocess_info 
> > *info)
> >  }
> >  #endif
> >  
> > +static struct sk_buff *alloc_uevent_skb(struct kobj_uevent_env *env,
> > +   const char *action_string,
> > +   const char *devpath)
> > +{
> > +   struct sk_buff *skb = NULL;
> > +   char *scratch;
> > +   size_t len;
> > +
> > +   /* allocate message with maximum possible size */
> > +   len = strlen(action_string) + strlen(devpath) + 2;
> > +   skb = alloc_skb(len + env->buflen, GFP_KERNEL);
> > +   if (!skb)
> > +   return NULL;
> > +
> > +   /* add header */
> > +   scratch = skb_put(skb, len);
> > +   sprintf(scratch, "%s@%s", action_string, devpath);
> > +
> > +   skb_put_data(skb, env->buf, env->buflen);
> > +
> > +   NETLINK_CB(skb).dst_group = 1;
> 
> nit:
>  We might want to explicitly set NETLINK_CB(skb).portid to 0 and
>  NETLINK_CB(skb).creds.uid to GLOBAL_ROOT_UID and
>  NETLINK_CB(skb).creds.gid to GLOBAL_ROOT_GID here
>  just to make it clear this is happening.
> 
>  It is not a problem because they __alloc_skb memsets to 0 the
>  fields of struct sk_buff that it does not initialize.  And these
>  are the zero values.
> 
>  Still it would be nice to be able to look at the code and quickly
>  see these are the values being set.

Don't really mind adding it. Ok, non-functional changes added to the new
version. But then let's set "portid" too:

parms = &NETLINK_CB(skb);
parms->creds.uid = GLOBAL_ROOT_UID;
parms->creds.gid = GLOBAL_ROOT_GID;
parms->dst_group = 1;
parms->portid = 0;

Christian

objdump: arch/x86/entry/.tmp_common.o: File format not recognized

[noisyb]

Hello,

4.1.51 compiles fine
4.16.1+ give me errors like in the subject... randomly...

I cant find a clue in Changes what is causing this... tools are all new 
enough...


Dirk

Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

[Luis R. Rodriguez]

On Sat, Apr 28, 2018 at 01:42:21AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 27, 2018 at 04:14:56PM +, Luis R. Rodriguez wrote:
> > Do we have a list of users for x86 with a small DMA mask?
> > Or, given that I'm not aware of a tool to be able to look
> > for this in an easy way, would it be good to find out which
> > x86 drivers do have a small mask?
> 
> Basically you'll have to grep for calls to dma_set_mask/
> dma_set_coherent_mask/dma_set_mask_and_coherent and their pci_*
> wrappers with masks smaller 32-bit.  Some use numeric values,
> some use DMA_BIT_MASK and various places uses local variables
> or struct members to parse them, so finding them will be a bit
> more work.  Nothing a coccinelle expert couldn't solve, though :)

Thing is unless we have a specific flag used consistently I don't believe we
can do this search with Coccinelle. ie, if we have local variables and based on
some series of variables things are set, this makes the grammatical expression
difficult to express.  So Cocinelle is not designed for this purpose.

But I believe smatch [0] is intended exactly for this sort of purpose, is that
right Dan? I gave a cursory look and I think it'd take me significant time to
get such hunt down.

[0] https://lwn.net/Articles/691882/

  Luis

Re: [PATCH 1/1] tg3: fix meaningless hw_stats reading after tg3_halt memset 0 hw_stats

[Michael Chan]

On Fri, Apr 27, 2018 at 8:15 PM, Zumeng Chen  wrote:

> diff --git a/drivers/net/ethernet/broadcom/tg3.h 
> b/drivers/net/ethernet/broadcom/tg3.h
> index 3b5e98e..6727d93 100644
> --- a/drivers/net/ethernet/broadcom/tg3.h
> +++ b/drivers/net/ethernet/broadcom/tg3.h
> @@ -3352,6 +3352,7 @@ struct tg3 {
> struct pci_dev  *pdev_peer;
>
> struct tg3_hw_stats *hw_stats;
> +   boolhw_stats_flag;

You can just add another bit to enum TG3_FLAGS for this purpose.

While this scheme will probably work, I think a better and more
elegant way to fix this is to use RCU.

> dma_addr_t  stats_mapping;
> struct work_struct  reset_task;
>
> --
> 2.9.3
>

Re: [PATCH] MAINTAINERS: add myself as maintainer of AFFS

[David Sterba]

On Sat, Apr 28, 2018 at 05:33:57PM +, Linus Torvalds wrote:
> On Sat, Apr 28, 2018 at 10:07 AM David Sterba  wrote:
> 
> > I volunteer to act as a maintainer of AFFS to collect any fixes that
> > might show up and to guard fs/affs/ against another spring cleaning.
> 
> Hmm. Please be more careful.
> 
> > @@ -564,8 +564,10 @@ S: Maintained
> 
> The above says it adds two lines (8 -> 10), but the actual patch itself
> only adds one, and modifies another:
> 
> > +M: David Sterba 
> > -S: Orphan
> > +S: Odd Fixes
> 
> I'm used to editing patches for things like this, because I have years and
> years of just hand-editing patches I didn't like for some reason, but it
> looks like you tried to edit a patch without knowing all the rules for how
> unified patches work.
> 
> So please don't edit patches by hand.  It's a skill nobody should have.
> 
> Anyway, I fixed the patch and applied it, but let's not make a habit of it.

Sorry, it was a last minute change. There was a T: line with a git tree
reference, but this looked odd and I deleted it, but did not realize the
patch would not apply. Too excited to send it.

Re: [RFD] x86: The future of MPX

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Sat, Apr 28, 2018 at 2:18 AM Ingo Molnar  wrote:
> 
> > I just tried the MPX testcases with the latest kernel:
> 
> >   deimos:~/tip/tools/testing/selftests/x86> ./mpx-mini-test_64
> 
> They need to be run as root. They try to access
> 
>  /sys/kernel/debug/tracing/set_ftrace_pid
>  /sys/kernel/debug/tracing/trace
> 
> and that's root-only.

Indeed - but note that they are crashing as root as well here:

  root@deimos:/home/mingo/tip/tools/testing/selftests/x86# ./mpx-mini-test_64 
  [...]
  Aborted (core dumped)

... because I don't even have /sys/kernel/debug/tracing/set_ftrace_pid... :-/

That's despite having ftrace enabled.

After some digging I found out that 'set_ftrace_pid' is dependent on 
CONFIG_FUNCTION_TRACING=y (not just CONFIG_TRACING=y), which I didn't
have enabled on this kernel.

After enabling it I got the 64-bit testcase to work:

  #
  ...
  ./mpx-mini-test_64 completed successfully

But the 32-bit testcase is erroring out:

  root@deimos:/home/mingo/tip/tools/testing/selftests/x86# ./mpx-mini-test_32 
  XSAVE is supported by HW & OS
  XSAVE processor supported state mask: 0x21f
  XSAVE OS supported state mask: 0x21f
   BNDREGS: size: 64 user: 1 supervisor: 0 aligned: 0
BNDCSR: size: 64 user: 1 supervisor: 0 aligned: 0
  executing unmaptest
  mpx dig (  1) complete, SUCCESS (   0 /0)
  #BR status == 2, missing bounds table,kernel should have handled!!

v4.17-rc2 based kernel, so it should have the latest MPX code.

Thanks,

Ingo

Re: [PATCH] MAINTAINERS: add myself as maintainer of AFFS

[Linus Torvalds]

On Sat, Apr 28, 2018 at 10:07 AM David Sterba  wrote:

> I volunteer to act as a maintainer of AFFS to collect any fixes that
> might show up and to guard fs/affs/ against another spring cleaning.

Hmm. Please be more careful.

> @@ -564,8 +564,10 @@ S: Maintained

The above says it adds two lines (8 -> 10), but the actual patch itself
only adds one, and modifies another:

> +M: David Sterba 
> -S: Orphan
> +S: Odd Fixes

I'm used to editing patches for things like this, because I have years and
years of just hand-editing patches I didn't like for some reason, but it
looks like you tried to edit a patch without knowing all the rules for how
unified patches work.

So please don't edit patches by hand.  It's a skill nobody should have.

Anyway, I fixed the patch and applied it, but let's not make a habit of it.

   Linus

Hello Dear Friend!

[From Mr Kabiru Wahid]

-- 
Hello Dear Friend! I have a business proposal for you which involves a
huge amount of money that run into millions of US dollars that i want
to move or transfer to your country for safe keeping and investment,
please this is not a spam, its a real business that will benefit both
of us. Please try as much as possible to get back to me on this, i
will explain more to you when you finally respond.Yours truly,prove
your integrity together with your full Information.
Your  Name..
Your Home Address.
Your Age..
Sex...
Your Home Telephone..
Your Personal Number.
Fax Number..
Receiving Country
Occupation...
I am waiting for your urgent respond to enable us proceed further for
the transfer of this fund into your account.
Yours faithfully,
Mr.Kabiru Wahid

Re: [PATCH RESEND] PCI/AER: Use a common function to print AER error bits

[Alex G.]

On 04/28/2018 11:46 AM, Alex G. wrote:

On 04/27/2018 05:43 PM, Bjorn Helgaas wrote:

On Tue, Apr 17, 2018 at 12:09:43PM -0500, Alexandru Gagniuc wrote:

(snip)

+    memset(&info, 0, sizeof(info));
+    info.severity = aer_severity;
+    info.status = status;
+    info.mask = mask;
+    info.first_error = 0x1f;


I like this patch a lot, but where does this "first_error = 0x1f" come
from?


aer_(un)correctable_error_string don't go to [0x1f], so this guarantees 
us we don't print "(First)".



I assume this is supposed to be the "First Error Pointer" in the
Advanced Error Capabilities and Control register (PCIe r4.0, sec
7.8.4.7).  There is a "cap_control" field in struct
aer_capability_regs; should we be using that here?


There is a way to extract it from the PCI regs, and it's quite simple. 
IIRC, it should be all f's when the capability is not implemented. I 
wanted to avoid any further parsing of PCI regs in this patch.


I could update the offending line to say:
 +  info.first_error = PCI_ERR_CAP_FEP(aer->cap_control);

Though I still have the concerns with validating CPER data:

I can see a way to use even more common printk code, but that requires 
validating the PCI regs we get from firmware. That means we need to make 
a guarantee about CPER that is beyond the scope of this patch.


Alex

[PATCH] MAINTAINERS: add myself as maintainer of AFFS

[David Sterba]

The AFFS filesystem is still in use by m68k community (Link #2), but as
there was no code activity and no maintainer, the filesystem appeared on
the list of candidates for staging/removal (Link #1).

I volunteer to act as a maintainer of AFFS to collect any fixes that
might show up and to guard fs/affs/ against another spring cleaning.

Link: https://lkml.kernel.org/r/20180425154602.ga8...@bombadil.infradead.org
Link: https://lkml.kernel.org/r/1613268.lKBQxPXt8J@merkaba
CC: Martin Steigerwald 
CC: John Paul Adrian Glaubitz 
Signed-off-by: David Sterba 
---
 MAINTAINERS | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index dd66ae9a847e..9d268895bd56 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -564,8 +564,10 @@ S: Maintained
 F: drivers/media/dvb-frontends/af9033*
 
 AFFS FILE SYSTEM
+M: David Sterba 
 L: linux-fsde...@vger.kernel.org
-S: Orphan
+S: Odd Fixes
 F: Documentation/filesystems/affs.txt
 F: fs/affs/
 
-- 
2.16.2

Re: [PATCH v4 4/4] iio: afe: rescale: new driver

[Jonathan Cameron]

On Mon, 23 Apr 2018 23:08:09 +0200
Peter Rosin  wrote:

> If an ADC channel measures the midpoint of a voltage divider, the
> interesting voltage is often the voltage over the full resistance.
> E.g. if the full voltage is too big for the ADC to handle.
> Likewise, if an ADC channel measures the voltage across a shunt
> resistor, with or without amplification, the interesting value is
> often the current through the resistor.
> 
> This driver solves these problems by allowing to linearly scale a channel
> and/or by allowing changes to the type of the channel.
> 
> Signed-off-by: Peter Rosin 

Great work.

Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  MAINTAINERS   |   1 +
>  drivers/iio/Kconfig   |   1 +
>  drivers/iio/Makefile  |   1 +
>  drivers/iio/afe/Kconfig   |  19 +++
>  drivers/iio/afe/Makefile  |   6 +
>  drivers/iio/afe/iio-rescale.c | 359 
> ++
>  6 files changed, 387 insertions(+)
>  create mode 100644 drivers/iio/afe/Kconfig
>  create mode 100644 drivers/iio/afe/Makefile
>  create mode 100644 drivers/iio/afe/iio-rescale.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1b23e9ebff9c..73b8fc5dd2a1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6896,6 +6896,7 @@ S:  Maintained
>  F:   Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt
>  F:   Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
>  F:   Documentation/devicetree/bindings/iio/afe/voltage-divider.txt
> +F:   drivers/iio/afe/iio-rescale.c
>  
>  IKANOS/ADI EAGLE ADSL USB DRIVER
>  M:   Matthieu Castet 
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index b3c8c6ef0dff..d69e85a8bdc3 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -70,6 +70,7 @@ config IIO_TRIGGERED_EVENT
>  
>  source "drivers/iio/accel/Kconfig"
>  source "drivers/iio/adc/Kconfig"
> +source "drivers/iio/afe/Kconfig"
>  source "drivers/iio/amplifiers/Kconfig"
>  source "drivers/iio/chemical/Kconfig"
>  source "drivers/iio/common/Kconfig"
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index b16b2e9ddc40..d8cba9c229c0 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_IIO_TRIGGERED_EVENT) += 
> industrialio-triggered-event.o
>  
>  obj-y += accel/
>  obj-y += adc/
> +obj-y += afe/
>  obj-y += amplifiers/
>  obj-y += buffer/
>  obj-y += chemical/
> diff --git a/drivers/iio/afe/Kconfig b/drivers/iio/afe/Kconfig
> new file mode 100644
> index ..c91eef04825a
> --- /dev/null
> +++ b/drivers/iio/afe/Kconfig
> @@ -0,0 +1,19 @@
> +#
> +# Analog Front End drivers
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +menu "Analog Front Ends"
> +
> +config IIO_RESCALE
> + tristate "IIO rescale"
> + depends on OF || COMPILE_TEST
> + help
> +   Say yes here to build support for the IIO rescaling
> +   that handles voltage dividers, current sense shunts and
> +   current sense amplifiers.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called iio-rescale.
> +
> +endmenu
> diff --git a/drivers/iio/afe/Makefile b/drivers/iio/afe/Makefile
> new file mode 100644
> index ..5fabb7bcac47
> --- /dev/null
> +++ b/drivers/iio/afe/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for industrial I/O Analog Front Ends (AFE)
> +#
> +
> +# When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_IIO_RESCALE) += iio-rescale.o
> diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c
> new file mode 100644
> index ..e9ceee66d1e7
> --- /dev/null
> +++ b/drivers/iio/afe/iio-rescale.c
> @@ -0,0 +1,359 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * IIO rescale driver
> + *
> + * Copyright (C) 2018 Axentia Technologies AB
> + *
> + * Author: Peter Rosin 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct rescale;
> +
> +struct rescale_cfg {
> + enum iio_chan_type type;
> + int (*props)(struct device *dev, struct rescale *rescale);
> +};
> +
> +struct rescale {
> + const struct rescale_cfg *cfg;
> + struct iio_channel *source;
> + struct iio_chan_spec chan;
> + struct iio_chan_spec_ext_info *ext_info;
> + s32 numerator;
> + s32 denominator;
> +};
> +
> +static int rescale_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct rescale *rescale = iio_priv(indio_dev);
> + unsigned long long tmp;
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + return iio_read_channel_raw(rescale->source, val);
> +
> + case IIO_CHAN_INFO_SCALE:
> + ret = iio_

Re: [PATCH v4 3/4] dt-bindings: iio: afe: add binding for current-sense-amplifier

[Jonathan Cameron]

On Fri, 27 Apr 2018 09:30:25 -0500
Rob Herring  wrote:

> On Mon, Apr 23, 2018 at 11:08:08PM +0200, Peter Rosin wrote:
> > Similar to current sense shunts, but an amplifier enables the use
> > of a smaller sense resistance.
> > 
> > Signed-off-by: Peter Rosin 
> > ---
> >  .../bindings/iio/afe/current-sense-amplifier.txt   | 26 
> > ++
> >  MAINTAINERS|  1 +
> >  2 files changed, 27 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/iio/afe/current-sense-amplifier.txt  
> 
> Reviewed-by: Rob Herring 
> 
Applied

Thanks,

Jonathan

Re: [PATCH v4 2/4] dt-bindings: iio: afe: add binding for voltage-divider

[Jonathan Cameron]

On Fri, 27 Apr 2018 09:29:17 -0500
Rob Herring  wrote:

> On Mon, Apr 23, 2018 at 11:08:07PM +0200, Peter Rosin wrote:
> > An ADC is often used to measure other quantities indirectly. This
> > binding describe one cases, a "big" voltage measured with the help
> > of a voltage divider.
> > 
> > Signed-off-by: Peter Rosin 
> > ---
> >  .../bindings/iio/afe/voltage-divider.txt   | 53 
> > ++
> >  MAINTAINERS|  1 +
> >  2 files changed, 54 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/iio/afe/voltage-divider.txt  
> 
> Reviewed-by: Rob Herring 

Same white space issue. Fixed.

Applied to the togreg branch of iio.git and pushed out as testing.

Thanks,

Jonathan

Re: [PATCH v4 1/4] dt-bindings: iio: afe: add binding for current-sense-shunt

[Jonathan Cameron]

On Mon, 23 Apr 2018 23:08:06 +0200
Peter Rosin  wrote:

> An ADC is often used to measure other quantities indirectly. This
> binding describe one cases, a current through a shunt resistor
> measured by the voltage over it.
> 
> Reviewed-by: Rob Herring 
> Signed-off-by: Peter Rosin 
One small whitespace issue inline that git am pointed out.

I fixed it.

Thanks,

Jonathan

> ---
>  .../bindings/iio/afe/current-sense-shunt.txt   | 41 
> ++
>  MAINTAINERS|  6 
>  2 files changed, 47 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt 
> b/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
> new file mode 100644
> index ..4d842aa85040
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
> @@ -0,0 +1,41 @@
> +Current Sense Shunt
> +===
> +
> +When an io-channel measures the voltage over a current sense shunt,
> +the interesting mesaurement is almost always the current through the
> +shunt, not the voltage over it. This binding describes such a current
> +sense circuit.
> +
> +Required properties:
> +- compatible : "current-sense-shunt"
> +- io-channels : Channel node of a voltage io-channel.
> +- shunt-resistor-micro-ohms : The shunt resistance in microohms.
> +
> +Example:
> +The system current is measured by measuring the voltage over a
> +3.3 ohms shunt resistor.
> +
> +sysi {
> + compatible = "current-sense-shunt";
> + io-channels = <&tiadc 0>;
> +
> + /* Divide the voltage by 330/100 (or 3.3) for the current. */
> + shunt-resistor-micro-ohms = <330>;
> +};
> +
> +&i2c {
> + tiadc: adc@48 {
> + compatible = "ti,ads1015";
> + reg = <0x48>;

The line above has some stray spaces - cleaned up.

> + #io-channel-cells = <1>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@0 { /* IN0,IN1 differential */
> + reg = <0>;
> + ti,gain = <1>;
> + ti,datarate = <4>;
> + };
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 36a28e979e9a..0f7bec878919 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6889,6 +6889,12 @@ F: drivers/staging/iio/
>  F:   include/linux/iio/
>  F:   tools/iio/
>  
> +IIO UNIT CONVERTER
> +M:   Peter Rosin 
> +L:   linux-...@vger.kernel.org
> +S:   Maintained
> +F:   Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
> +
>  IKANOS/ADI EAGLE ADSL USB DRIVER
>  M:   Matthieu Castet 
>  M:   Stanislaw Gruszka 

Re: [PATCH RESEND] PCI/AER: Use a common function to print AER error bits

[Alex G.]

On 04/27/2018 05:43 PM, Bjorn Helgaas wrote:

On Tue, Apr 17, 2018 at 12:09:43PM -0500, Alexandru Gagniuc wrote:

On errors reported from CPER, cper_print_bits() was used to log the
AER bits. This resulted in hard-to-understand messages, without a
prefix. Instead use __aer_print_error() for both native AER and CPER
to provide a more consistent log format.

Signed-off-by: Alexandru Gagniuc 
---
  drivers/pci/pcie/aer/aerdrv_errprint.c | 16 +---
  1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c 
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index cfc89dd57831..cfae4d52f848 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -216,28 +216,30 @@ EXPORT_SYMBOL_GPL(cper_severity_to_aer);
  void cper_print_aer(struct pci_dev *dev, int aer_severity,
struct aer_capability_regs *aer)
  {
-   int layer, agent, status_strs_size, tlp_header_valid = 0;
+   int layer, agent, tlp_header_valid = 0;
u32 status, mask;
-   const char **status_strs;
+   struct aer_err_info info;
  
  	if (aer_severity == AER_CORRECTABLE) {

status = aer->cor_status;
mask = aer->cor_mask;
-   status_strs = aer_correctable_error_string;
-   status_strs_size = ARRAY_SIZE(aer_correctable_error_string);
} else {
status = aer->uncor_status;
mask = aer->uncor_mask;
-   status_strs = aer_uncorrectable_error_string;
-   status_strs_size = ARRAY_SIZE(aer_uncorrectable_error_string);
tlp_header_valid = status & AER_LOG_TLP_MASKS;
}
  
  	layer = AER_GET_LAYER_ERROR(aer_severity, status);

agent = AER_GET_AGENT(aer_severity, status);
  
+	memset(&info, 0, sizeof(info));

+   info.severity = aer_severity;
+   info.status = status;
+   info.mask = mask;
+   info.first_error = 0x1f;


I like this patch a lot, but where does this "first_error = 0x1f" come
from?


aer_(un)correctable_error_string don't go to [0x1f], so this guarantees 
us we don't print "(First)".



I assume this is supposed to be the "First Error Pointer" in the
Advanced Error Capabilities and Control register (PCIe r4.0, sec
7.8.4.7).  There is a "cap_control" field in struct
aer_capability_regs; should we be using that here?


There is a way to extract it from the PCI regs, and it's quite simple. 
IIRC, it should be all f's when the capability is not implemented. I 
wanted to avoid any further parsing of PCI regs in this patch.


I can see a way to use even more common printk code, but that requires 
validating the PCI regs we get from firmware. That means we need to make 
a guarantee about CPER that is beyond the scope of this patch.


Alex


+
pci_err(dev, "aer_status: 0x%08x, aer_mask: 0x%08x\n", status, mask);
-   cper_print_bits("", status, status_strs, status_strs_size);
+   __aer_print_error(dev, &info);
pci_err(dev, "aer_layer=%s, aer_agent=%s\n",
aer_error_layer[layer], aer_agent_string[agent]);
  
--

2.14.3

Re: [RFD] x86: The future of MPX

[Linus Torvalds]

On Sat, Apr 28, 2018 at 9:36 AM Linus Torvalds <
torva...@linux-foundation.org> wrote:

> They need to be run as root.

Side note: don't get me wrong. If the MPX stuff isn't supported by gcc,
then there is little point in us supporting it in the kernel either.

So I'm just saying that the test-case is root-only and the crash doesn't
necessarily mean anything else than "badly written test".

   Linus

Re: [RFD] x86: The future of MPX

[Linus Torvalds]

On Sat, Apr 28, 2018 at 2:18 AM Ingo Molnar  wrote:

> I just tried the MPX testcases with the latest kernel:

>   deimos:~/tip/tools/testing/selftests/x86> ./mpx-mini-test_64

They need to be run as root. They try to access

 /sys/kernel/debug/tracing/set_ftrace_pid
 /sys/kernel/debug/tracing/trace

and that's root-only.

> ... and both of them crashed.

That's just because they use "assert()" to check that the file open worked.

"assert()" is evil and bad bad bad.

  Linus

[PATCH v5 1/7] gpio: pca953x: convert register constants to hex

[H. Nikolaus Schaller]

which makes it easier to match them with the data sheets.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpio/gpio-pca953x.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index d02964983b5b..508d0f6dceb7 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -25,25 +25,25 @@
 
 #include 
 
-#define PCA953X_INPUT  0
-#define PCA953X_OUTPUT 1
-#define PCA953X_INVERT 2
-#define PCA953X_DIRECTION  3
+#define PCA953X_INPUT  0x00
+#define PCA953X_OUTPUT 0x01
+#define PCA953X_INVERT 0x02
+#define PCA953X_DIRECTION  0x03
 
 #define REG_ADDR_AI0x80
 
-#define PCA957X_IN 0
-#define PCA957X_INVRT  1
-#define PCA957X_BKEN   2
-#define PCA957X_PUPD   3
-#define PCA957X_CFG4
-#define PCA957X_OUT5
-#define PCA957X_MSK6
-#define PCA957X_INTS   7
-
-#define PCAL953X_IN_LATCH  34
-#define PCAL953X_INT_MASK  37
-#define PCAL953X_INT_STAT  38
+#define PCA957X_IN 0x00
+#define PCA957X_INVRT  0x01
+#define PCA957X_BKEN   0x02
+#define PCA957X_PUPD   0x03
+#define PCA957X_CFG0x04
+#define PCA957X_OUT0x05
+#define PCA957X_MSK0x06
+#define PCA957X_INTS   0x07
+
+#define PCAL953X_IN_LATCH  0x22
+#define PCAL953X_INT_MASK  0x25
+#define PCAL953X_INT_STAT  0x26
 
 #define PCA_GPIO_MASK  0x00FF
 #define PCA_INT0x0100
-- 
2.12.2

[PATCH v5 7/7] DTS: Bindings: pca953x: add example how to use interrupt-controller and gpio-controller

[H. Nikolaus Schaller]

It is not completely obvious that these are required and
how to use them. So we provide a tested example.

Signed-off-by: H. Nikolaus Schaller 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/gpio/gpio-pca953x.txt  | 33 ++
 1 file changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt 
b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
index 6a7cddb187c1..88f228665507 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
@@ -31,6 +31,10 @@ Required properties:
ti,tca9554
onnn,pca9654
exar,xra1202
+ - gpio-controller: if used as gpio expander.
+ - #gpio-cells: if used as gpio expander.
+ - interrupt-controller: if to be used as interrupt expander.
+ - #interrupt-cells: if to be used as interrupt expander.
 
 Optional properties:
  - reset-gpios: GPIO specification for the RESET input. This is an
@@ -48,3 +52,32 @@ Example:
interrupt-parent = <&gpio3>;
interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
};
+
+
+Example with Interrupts:
+
+
+   gpio99: gpio@22 {
+   compatible = "nxp,pcal6524";
+   reg = <0x22>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <1 IRQ_TYPE_EDGE_FALLING>; /* gpio6_161 */
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   vcc-supply = <&vdds_1v8_main>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-line-names =
+   "hdmi-ct-hpd", "hdmi.ls-oe", "p02", "p03", "vibra", 
"fault2", "p06", "p07",
+   "en-usb", "en-host1", "en-host2", "chg-int", "p14", 
"p15", "mic-int", "en-modem",
+   "shdn-hs-amp", "chg-status+red", "green", "blue", 
"en-esata", "fault1", "p26", "p27";
+   };
+
+   ts3a227@3b {
+   compatible = "ti,ts3a227e";
+   reg = <0x3b>;
+   interrupt-parent = <&gpio99>;
+   interrupts = <14 IRQ_TYPE_EDGE_RISING>;
+   ti,micbias = <0>;   /* 2.1V */
+   };
+
-- 
2.12.2

[PATCH v5 0/7] pcal6524 extensions and fixes for pca953x driver

[H. Nikolaus Schaller]

V5:
* fix wrong split up between patches 1/7and 2/7.

2018-04-26 19:35:07: V4:
* introduced PCA_LATCH_INT constant to make of_table more
  readable (suggested by Andy Shevchenko)
* converted all register constants to hex in a separate
  patch (suggested by Andy Shevchenko)
* separated additional pcal953x and pcal6524 register
  definitions into separate patches (suggested by Andy Shevchenko)
* made special pcal6524 address adjustment more readable
  (suggested by Andy Shevchenko)
* moved gpio-controller and interrupt-controller to the
  "required" section (reviewed by Rob Herring)

2018-04-10 18:07:07: V3:
* add Reported-by: and Reviewed-by:
* fix wording for bindings description and example
* convert all register offsets to hex
* omit the LEVEL-IRQ RFC/hack commit

2018-04-04 21:00:27: V2:
* added PCA_PCAL flags if matched through of-table
* fix address calculation for extended PCAL6524 registers
* hack to map LEVEL_LOW to EDGE_FALLING to be able to
  test in combination with ts3a227e driver
* improve description of bindings for optional vcc-supply
  and interrupt-controller;

2018-03-10 09:32:53: no initial description

H. Nikolaus Schaller (7):
  gpio: pca953x: convert register constants to hex
  gpio: pca953x: add more register definitions for pcal953x
  gpio: pca953x: add more register definitions for pcal6524
  gpio: pca953x: define masks for addressing common and extended
registers
  gpio: pca953x: fix address calculation for pcal6524
  DTS: Bindings: pca953x add an optional vcc-supply property
  DTS: Bindings: pca953x: add example how to use interrupt-controller
and gpio-controller

 .../devicetree/bindings/gpio/gpio-pca953x.txt  | 34 ++
 drivers/gpio/gpio-pca953x.c| 53 ++
 2 files changed, 69 insertions(+), 18 deletions(-)

-- 
2.12.2

[PATCH v5 3/7] gpio: pca953x: add more register definitions for pcal6524

[H. Nikolaus Schaller]

The pcal6524 has another set of registers to fine control
the interrupt handling.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpio/gpio-pca953x.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index fecd0e0aba93..2b667166e855 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -49,6 +49,12 @@
 #define PCAL953X_INT_STAT  0x26
 #define PCAL953X_OUT_CONF  0x27
 
+#define PCAL6524_INT_EDGE  0x28
+#define PCAL6524_INT_CLR   0x2a
+#define PCAL6524_IN_STATUS 0x2b
+#define PCAL6524_OUT_INDCONF   0x2c
+#define PCAL6524_DEBOUNCE  0x2d
+
 #define PCA_GPIO_MASK  0x00FF
 #define PCA_INT0x0100
 #define PCA_PCAL   0x0200
-- 
2.12.2

[PATCH v5 4/7] gpio: pca953x: define masks for addressing common and extended registers

[H. Nikolaus Schaller]

These mask bits are to be used to map the extended register
addreseses (which are defined for an unsupported 8-bit pcal chip)
to 16 and 24 bit chips (pcal6524).

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpio/gpio-pca953x.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 2b667166e855..fc863faa3ce4 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -56,6 +56,9 @@
 #define PCAL6524_DEBOUNCE  0x2d
 
 #define PCA_GPIO_MASK  0x00FF
+#define PCAL_GPIO_MASK GENMASK(4, 0)
+#define PCAL_PINCTRL_MASK  (~PCAL_GPIO_MASK)
+
 #define PCA_INT0x0100
 #define PCA_PCAL   0x0200
 #define PCA_LATCH_INT (PCA_PCAL | PCA_INT)
-- 
2.12.2

[PATCH v5 2/7] gpio: pca953x: add more register definitions for pcal953x

[H. Nikolaus Schaller]

PCAL chips ("L" seems to stand for "latched") have additional
registers starting at address 0x40 to control the latches,
interrupt mask, pull-up and pull down etc.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpio/gpio-pca953x.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 508d0f6dceb7..fecd0e0aba93 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -41,9 +41,13 @@
 #define PCA957X_MSK0x06
 #define PCA957X_INTS   0x07
 
+#define PCAL953X_OUT_STRENGTH  0x20
 #define PCAL953X_IN_LATCH  0x22
+#define PCAL953X_PULL_EN   0x23
+#define PCAL953X_PULL_SEL  0x24
 #define PCAL953X_INT_MASK  0x25
 #define PCAL953X_INT_STAT  0x26
+#define PCAL953X_OUT_CONF  0x27
 
 #define PCA_GPIO_MASK  0x00FF
 #define PCA_INT0x0100
-- 
2.12.2

[PATCH v5 6/7] DTS: Bindings: pca953x add an optional vcc-supply property

[H. Nikolaus Schaller]

Hardware can have a switchable Vcc supply, so let's add it to
the bindings (the current Linux driver code already supports it).

Signed-off-by: H. Nikolaus Schaller 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt 
b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
index d2a937682836..6a7cddb187c1 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
@@ -35,6 +35,7 @@ Required properties:
 Optional properties:
  - reset-gpios: GPIO specification for the RESET input. This is an
active low signal to the PCA953x.
+ - vcc-supply: power supply regulator.
 
 Example:
 
-- 
2.12.2

[PATCH v5 5/7] gpio: pca953x: fix address calculation for pcal6524

[H. Nikolaus Schaller]

The register constants are so far defined in a way that they fit
for the pcal9555a when shifted by the number of banks, i.e. are
multiplied by 2 in the accessor function.

Now, the pcal6524 has 3 banks which means the relative offset
is multiplied by 4 for the standard registers.

Simply applying the bit shift to the extended registers gives
a wrong result, since the base offset is already included in
the offset.

Therefore, we add code to the 24 bit accessor functions to
adjust the register number for these exended registers.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpio/gpio-pca953x.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index fc863faa3ce4..4194495a7990 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -221,9 +221,11 @@ static int pca957x_write_regs_16(struct pca953x_chip 
*chip, int reg, u8 *val)
 static int pca953x_write_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
 {
int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+   int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
+   int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
 
return i2c_smbus_write_i2c_block_data(chip->client,
- (reg << bank_shift) | REG_ADDR_AI,
+ pinctrl | addr | REG_ADDR_AI,
  NBANK(chip), val);
 }
 
@@ -263,9 +265,11 @@ static int pca953x_read_regs_16(struct pca953x_chip *chip, 
int reg, u8 *val)
 static int pca953x_read_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
 {
int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+   int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
+   int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
 
return i2c_smbus_read_i2c_block_data(chip->client,
-(reg << bank_shift) | REG_ADDR_AI,
+pinctrl | addr | REG_ADDR_AI,
 NBANK(chip), val);
 }
 
-- 
2.12.2

Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE

[Ilia Mirkin]

On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled)
> try to allocate huge pages. However, not all drivers can take advantage
> of huge pages, but they would incur the overhead for allocating and
> freeing them anyway.
>
> Now, drivers which can take advantage of huge pages need to set the new
> flag TTM_PAGE_FLAG_TRANSHUGE to get them. Drivers not setting this flag
> no longer incur any overhead for allocating or freeing huge pages.
>
> v2:
> * Also guard swapping of consecutive pages in ttm_get_pages
> * Reword commit log, hopefully clearer now
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Michel Dänzer 

Both I and lots of other people, based on reports, are still seeing
plenty of issues with this as late as 4.16.4. Admittedly I'm on
nouveau, but others have reported issues with radeon/amdgpu as well.
It's been going on since the feature was merged in v4.15, with what
seems like little investigation from the authors introducing the
feature.

We now have *two* broken releases, v4.15 and v4.16 (anything that
spews error messages and stack traces ad-infinitum in dmesg is, by
definition, broken). You're putting this behind a flag now (finally),
but should it be enabled anywhere? Why is it being flipped on for
amdgpu by default, despite the still-existing problems?

Reverting this feature without just resetting back to the code in
v4.14 is painful, but why make Joe User suffer by enabling it while
you're still working out the kinks?

  -ilia

Re: [PATCH v4 1/7] gpio: pca953x: convert register constants to hex

[H. Nikolaus Schaller]

> Am 26.04.2018 um 19:34 schrieb H. Nikolaus Schaller :
> 
> which makes it easier to match them with the data sheets.
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
> drivers/gpio/gpio-pca953x.c | 32 
> 1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index d02964983b5b..bd0593afdae3 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -25,25 +25,25 @@
> 
> #include 
> 
> -#define PCA953X_INPUT0
> -#define PCA953X_OUTPUT   1
> -#define PCA953X_INVERT   2
> -#define PCA953X_DIRECTION3
> +#define PCA953X_INPUT0x00
> +#define PCA953X_OUTPUT   0x01
> +#define PCA953X_INVERT   0x02
> +#define PCA953X_DIRECTION0x03
> 
> #define REG_ADDR_AI   0x80
> 
> -#define PCA957X_IN   0
> -#define PCA957X_INVRT1
> -#define PCA957X_BKEN 2
> -#define PCA957X_PUPD 3
> -#define PCA957X_CFG  4
> -#define PCA957X_OUT  5
> -#define PCA957X_MSK  6
> -#define PCA957X_INTS 7
> -
> -#define PCAL953X_IN_LATCH34
> -#define PCAL953X_INT_MASK37
> -#define PCAL953X_INT_STAT38
> +#define PCA957X_IN   0x00
> +#define PCA957X_INVRT0x01
> +#define PCA957X_BKEN 0x02
> +#define PCA957X_PUPD 0x03
> +#define PCA957X_CFG  0x04
> +#define PCA957X_OUT  0x05
> +#define PCA957X_MSK  0x06
> +#define PCA957X_INTS 0x07
> +
> +#define PCAL953X_IN_LATCH0x22
> +#define PCAL953X_PULL_EN 0x23
> +#define PCAL953X_PULL_SEL0x24

oops, just spotted a bug above.

Here, we should update the registers PCAL953X_INT_MASK and
PCAL953X_INT_STAT. And add PCAL953X_PULL_EN and PCAL953X_PULL_SEL
in the next patch.

Sorry. I will send an update for the patch set.

> 
> #define PCA_GPIO_MASK 0x00FF
> #define PCA_INT   0x0100
> -- 
> 2.12.2
> 

BR,
Nikolaus

Re: [PATCH v1 1/4] mhi_bus: core: Add support for MHI host interface

[Sujeev Dias]

On 04/27/2018 05:18 AM, Arnd Bergmann wrote:

On Fri, Apr 27, 2018 at 4:23 AM, Sujeev Dias  wrote:


diff --git a/Documentation/devicetree/bindings/bus/mhi.txt 
b/Documentation/devicetree/bindings/bus/mhi.txt
new file mode 100644
index 000..ea1b620
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mhi.txt
@@ -0,0 +1,141 @@
+MHI Host Interface
+
+MHI used by the host to control and communicate with modem over
+high speed peripheral bus.
+
+==
+Node Structure
+==
+
+Main node properties:
+
+- mhi,max-channels
+  Usage: required
+  Value type: 
+  Definition: Maximum number of channels supported by this controller
+
+- mhi,chan-cfg
+  Usage: required
+  Value type: Array of 
+  Definition: Array of tuples describe channel configuration.
+   1st element: Physical channel number
+   2nd element: Transfer ring length in elements
+   3rd element: Event ring associated with this channel
+   4th element: Channel direction as defined by enum dma_data_direction
+   1 = UL data transfer
+   2 = DL data transfer
+   5th element: Channel doorbell mode configuration as defined by
+   enum MHI_BRSTMODE
+   2 = burst mode disabled
+   3 = burst mode enabled
+   6th element: mhi doorbell configuration, valid only when burst mode
+   enabled.
+   0 = Use default (device specific) polling configuration
+   For UL channels, value specifies the timer to poll MHI context
+   in milliseconds.
+   For DL channels, the threshold to poll the MHI context
+   in multiple of eight ring element.
+   7th element: Channel execution enviornment as defined by enum MHI_EE
+   1 = Bootloader stage
+   2 = AMSS mode
+   8th element: data transfer type accepted as defined by enum
+   MHI_XFER_TYPE
+   0 = accept cpu address for buffer
+   1 = accept skb
+   2 = accept scatterlist
+   3 = offload channel, does not accept any transfer type
+   9th element: Bitwise configuration settings for the channel
+   Bit mask:
+   BIT(0) : LPM notify, this channel master requre lpm enter/exit
+   notifications.
+   BIT(1) : Offload channel, MHI host only involved in setting up
+   the data pipe. Not involved in active data transfer.
+   BIT(2) : Must switch to doorbell mode whenever MHI M0 state
+   transition happens.
+   BIT(3) : MHI bus driver pre-allocate buffer for this channel.
+   If set, clients not allowed to queue buffers. Valid only for DL
+   direction.
+
+- mhi,chan-names
+  Usage: required
+  Value type: Array of 
+  Definition: Channel names configured in mhi,chan-cfg.

I think the top-level structure would be better done by requiring
a child for each channel and moving the mhi,chan-cfg
into the children nodes, either as separate properties, or
some of the fields combined into a 'reg' property.


+- mhi,fw-name
+  Usage: optional
+  Value type: 
+  Definition: Firmware image name to upload

The device tree should have no knowledge of a firmware file name.

What you should do instead is to have the driver generate the file
name from the "compatible" property. You could use a lookup table
in the driver, or have some algorithmic way of doing that, but you
want the driver to have some form of intelligence to let it pick
a different firmware image, e.g. when you have added new
capabilities to the driver and the firmware but want to use an
existing device tree.


+Data structures
+---
+Host memory : Directly accessed by the host to manage the MHI data structures
+and buffers. The device accesses the host memory over the PCIe interface.
+
+Channel context array : All channel configurations are organized in channel
+context data array.
+
+struct __packed mhi_chan_ctxt;
+struct mhi_ctxt.chan_ctxt;
+
+Transfer rings : Used by host to schedule work items for a channel and 
organized
+as a circular queue of transfer descriptors (TD).
+
+struct __packed mhi_tre;
+struct mhi_chan.tre_ring;
+

This looks like you reinvented virtio. What are the reasons for not just
using virtio directly as we do for other modem interfaces?


+static int mhi_fw_load_sbl(struct mhi_controller *mhi_cntrl,
+  void *buf,
+  size_t size)
+{
+   u32 tx_status, val;
+   int i, ret;
+   void __iomem *base = mhi_cntrl->bhi;
+   rwlock_t *pm_lock = &mhi_cntrl->pm_lock;
+   dma_addr_t phys = dma_map_single(mhi_cntrl->dev, buf, size,
+DMA_TO_DEVICE);

Please don't name a dma address 'phys', it's very confusing ;-)


+struct mhi_bus mhi_bus;

One global instance? I suspec this duplicates data that is already
in the bus_type structure, so just use that instead.


+void mhi_init_debugfs(struc

Re: [PATCH] staging: luster: llite: fix a potential missing-check bug when copying lumv

[Dilger, Andreas]

On Apr 27, 2018, at 17:45, Wenwen Wang  wrote:
> [PATCH] staging: luster: llite: fix potential missing-check bug when copying 
> lumv

(typo) s/luster/lustre/

> In ll_dir_ioctl(), the object lumv3 is firstly copied from the user space
> using Its address, i.e., lumv1 = &lumv3. If the lmm_magic field of lumv3 is
> LOV_USER_MAGIV_V3, lumv3 will be modified by the second copy from the user

(typo) s/MAGIV/MAGIC/

> space. The second copy is necessary, because the two versions (i.e.,
> lov_user_md_v1 and lov_user_md_v3) have different data formats and lengths.
> However, given that the user data resides in the user space, a malicious
> user-space process can race to change the data between the two copies. By
> doing so, the attacker can provide a data with an inconsistent version,
> e.g., v1 version + v3 data. This can lead to logical errors in the
> following execution in ll_dir_setstripe(), which performs different actions
> according to the version specified by the field lmm_magic.

This isn't a serious bug in the end.  The LOV_USER_MAGIC_V3 check just copies
a bit more data from userspace (the lmm_pool field).  It would be more of a
problem if the reverse was possible (copy smaller V1 buffer, but change the
magic to LOV_USER_MAGIC_V3 afterward), but this isn't possible since the second
copy is not done if there is a V1 magic.  If the user changes from V3 magic
to V1 in a racy manner it means less data will be used than copied, which
is harmless.

> This patch rechecks the version field lmm_magic in the second copy.  If the
> version is not as expected, i.e., LOV_USER_MAGIC_V3, an error code will be
> returned: -EINVAL.

This isn't a bad idea in any case, since it verifies the data copied from
userspace is still valid.

Cheers, Andreas

> Signed-off-by: Wenwen Wang 
> ---
> drivers/staging/lustre/lustre/llite/dir.c | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/lustre/lustre/llite/dir.c 
> b/drivers/staging/lustre/lustre/llite/dir.c
> index d10d272..80d44ca 100644
> --- a/drivers/staging/lustre/lustre/llite/dir.c
> +++ b/drivers/staging/lustre/lustre/llite/dir.c
> @@ -1185,6 +1185,8 @@ static long ll_dir_ioctl(struct file *file, unsigned 
> int cmd, unsigned long arg)
>   if (lumv1->lmm_magic == LOV_USER_MAGIC_V3) {
>   if (copy_from_user(&lumv3, lumv3p, sizeof(lumv3)))
>   return -EFAULT;
> + if (lumv3.lmm_magic != LOV_USER_MAGIC_V3)
> + return -EINVAL;
>   }
> 
>   if (is_root_inode(inode))
> -- 
> 2.7.4
> 

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Re: [PATCH 4.16 00/81] 4.16.6-stable review

[Greg Kroah-Hartman]

On Sat, Apr 28, 2018 at 07:32:18AM -0700, Guenter Roeck wrote:
> On 04/27/2018 06:58 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.16.6 release.
> > There are 81 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Apr 29 13:57:21 UTC 2018.
> > Anything received after that time might be too late.
> 
> Build results:
>   total: 143 pass: 143 fail: 0
> Qemu test results:
>   total: 139 pass: 139 fail: 0
> 
> Details are available at http://kerneltests.org/builders/.

Wonderful, thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH v1 1/4] mhi_bus: core: Add support for MHI host interface

[Greg Kroah-Hartman]

On Sat, Apr 28, 2018 at 07:28:17AM -0700, Sujeev Dias wrote:
> Thanks for quick feedback
> 
> 
> On 04/27/2018 12:22 AM, Greg Kroah-Hartman wrote:
> > On Thu, Apr 26, 2018 at 07:23:28PM -0700, Sujeev Dias wrote:
> > > MHI Host Interface is a communication protocol to be used by the host
> > > to control and communcate with modem over a high speed peripheral bus.
> > > This module will allow host to communicate with external devices that
> > > support MHI protocol.
> > > 
> > > Signed-off-by: Sujeev Dias 
> > No one else has ever reviewed this code before?  That's not good, please
> > at the very least, have someone else at your company go over it first.
> > I don't want to be the ones having to point out all of the "obvious"
> > issues :)
> > 
> This code has gone thru rigorous code review and testing, before I submit
> next patch I will have multiple people sign off on it.

Thank you.

> Intention was to completely compile out MHI_VERB messages because we have
> those messages in data path.  For release build, we wanted to reduce
> as much mips as possible.  However, for debugging these messages are
> extremely helpful.

That's exactly what dev_dbg() does today.  So please use it.

> I will look into tracepoints...

Or that, if you want them, they can be useful on data paths.

thanks,

greg k-h

[GIT PULL] ARM: uniphier: fixes for v4.17

[Masahiro Yamada]

Hi Arnd, Olof,

Please pull some fixes of ARM UniPhier DT.



The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
tags/uniphier-fixes-v4.17

for you to fetch changes up to 8b82b66e68b32dd8e22a04db6a0494bfdd65156f:

  arm64: dts: uniphier: stabilize ethernet of LD20 reference board
(2018-04-29 00:33:42 +0900)


UniPhier ARM SoC fixes for v4.17

- Fix input delay parameter of eMMC PHY
- Weaken drive-strength of ethernet PHY pins of LD20 reference board


Masahiro Yamada (2):
  arm64: dts: uniphier: fix input delay value for legacy mode of eMMC
  arm64: dts: uniphier: stabilize ethernet of LD20 reference board

 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi| 2 +-
 arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 8 
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi| 2 +-
 arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi| 2 +-
 4 files changed, 11 insertions(+), 3 deletions(-)




-- 
Best Regards
Masahiro Yamada

Quote Request.

[Ron Corporation]

Good morning.

We got a recommendation that your company could help us get the GRUNDFOS PUMP 
with model numbers below:

1)Grundfos SQ Flex 11 SQF-2 Part Number 95027335

2)Grundfos 10SQ10-290 PART NUMBER 96160143

3)Grundfos 10SQ07-240 PART NUMBER 96160142

4)Grundfos 10SQ15-330 PART NUMBER 96160144

If you can, please advise quote on 2 of each part and the lead-time you could 
have these turned in at your facility for in-store pick up.

Thank you.
Ron Jones
Resource Team
Ron Corporation
ronicorporat...@gmail.com

Re: [PATCH v1 2/4] mhi_bus: controller: MHI support for QCOM modems

[Sujeev Dias]

On 04/27/2018 04:32 AM, Arnd Bergmann wrote:

On Fri, Apr 27, 2018 at 4:23 AM, Sujeev Dias  wrote:

QCOM PCIe based modems uses MHI as the communication protocol.
MHI control driver is the bus master for such modems. As the bus
master driver, it oversees power management operations
such as suspend, resume, powering on and off the device.

+- compatible
+  Usage: required
+  Value type: 
+  Definition: "qcom,mhi"
+
+- qcom,pci-dev-id
+  Usage: optional
+  Value type: 
+  Definition: PCIe device id of external modem to bind. If not set, any
+   device is compatible with this node.
+
+- qcom,pci-domain
+  Usage: required
+  Value type: 
+  Definition: PCIe root complex external modem connected to
+
+- qcom,pci-bus
+  Usage: required
+  Value type: 
+  Definition: PCIe bus external modem connected to
+
+- qcom,pci-slot
+  Usage: required
+  Value type: 
+  Definition: PCIe slot as assigned by pci framework to external modem

These don't seem to make any sense: You seem to have access to
a regular pci_device already, so why do you need to duplicate the
information about it in DT?

I will remove the platform device, original hardware design we had a 
complicated power on
sequence that require platform device to come up first and follow a 
strict power on sequence to power on modem
before pci device can enumerate.  I stored the BDF in DT to correlate 
the platform device with pci device. platform device

is no longer needed so I can remove it.

+- qcom,smmu-cfg
+  Usage: required
+  Value type: 
+  Definition: Required SMMU configuration bitmask for PCIe bus.
+   BIT mask:
+   BIT(0) : Attach address mapping to endpoint device
+   BIT(1) : Set attribute S1_BYPASS
+   BIT(2) : Set attribute FAST
+   BIT(3) : Set attribute ATOMIC
+   BIT(4) : Set attribute FORCE_COHERENT
+
+- qcom,addr-win
+  Usage: required if SMMU S1 translation is enabled
+  Value type: Array of 
+  Definition: Pair of values describing iova start and stop address

Why do you need these? Can't that be handled by the PCI
layer?
I will move this to end point DT.  PCIe end point driver does the iommu 
configuration

+- qcom,msm-bus,name
+  Usage: required
+  Value type: 
+  Definition: string representing the bus scale client name to register

This probably belongs into a separate binding for the bus
scale driver, right?
Yes, this is for qcom bus scale driver which I don't think is upstreamed 
yet. Will confirm.

+static struct pci_driver mhi_pcie_driver;

Please try to reorder the symbols to avoid forward declarations.


+static int mhi_platform_probe(struct platform_device *pdev)
+{
+   struct mhi_controller *mhi_cntrl;
+   struct mhi_dev *mhi_dev;
+   struct device_node *of_node = pdev->dev.of_node;
+   u64 addr_win[2];
+   int ret;
+
+   if (!of_node)
+   return -ENODEV;
+
+   mhi_cntrl = mhi_alloc_controller(sizeof(*mhi_dev));
+   if (!mhi_cntrl)
+   return -ENOMEM;
+
+   mhi_dev = mhi_controller_get_devdata(mhi_cntrl);
+
+   /* get pci bus topology for this node */
+   ret = of_property_read_u32(of_node, "qcom,pci-dev-id",
+  &mhi_cntrl->dev_id);
+   if (ret)
+   mhi_cntrl->dev_id = PCI_ANY_ID;
+
+   ret = of_property_read_u32(of_node, "qcom,pci-domain",
+  &mhi_cntrl->domain);
+   if (ret)
+   goto error_probe;
+
+   ret = of_property_read_u32(of_node, "qcom,pci-bus", &mhi_cntrl->bus);
+   if (ret)
+   goto error_probe;
+
+   ret = of_property_read_u32(of_node, "qcom,pci-slot", &mhi_cntrl->slot);
+   if (ret)
+   goto error_probe;

Please explain what you are trying to do here, why do you register
two device drivers? It looks like they both refer to the same
hardware, so why isn't it sufficient to have the pci_driver?
As I explained earlier, it's now. Original hardware design we had 
chicken egg situation where
some driver has to come up and power on device before pcie enumeration 
can take place.




Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks again
Sujeev

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] nvme: unquiesce the queue before cleaup it

[jianchao.wang]

Hi Max

On 04/27/2018 04:51 PM, jianchao.wang wrote:
> Hi Max
> 
> On 04/26/2018 06:23 PM, Max Gurtovoy wrote:
>> Hi Jianchao,
>> I actually tried this scenario with real HW and was able to repro the hang.
>> Unfortunatly, after applying your patch I got NULL deref:
>> BUG: unable to handle kernel NULL pointer dereference at 0014
>> WARNING: CPU: 5 PID: 0 at block/blk-mq.c:526 
>> __blk_mq_complete_request+0x154/0x160
>>
> 
> Could you please share the whole backtrace here ?

I have reproduced the WARNING in __blk_mq_complete_request.

[107612.367131] RIP: 0010:__blk_mq_complete_request+0x2aa/0x2e0
[107612.367133] RSP: 0018:88036e627b68 EFLAGS: 00010202
[107612.367137] RAX: 0002 RBX: 88034708a440 RCX: 
9452df6c
[107612.367140] RDX: dc00 RSI: dc00 RDI: 
88034708a540
[107612.367142] RBP: 11006dcc4f73 R08: ed007901472f R09: 
ed007901472f
[107612.367144] R10: 0001 R11: ed007901472e R12: 
e8dc8940
[107612.367146] R13: 88034708a540 R14: 8803c51c33c0 R15: 
88032d091ea0
[107612.367149] FS:  () GS:8803c808() 
knlGS:
[107612.367151] CS:  0010 DS:  ES:  CR0: 80050033
[107612.367153] CR2: 018ee000 CR3: 0003c1e13001 CR4: 
003606e0
[107612.367155] DR0:  DR1:  DR2: 

[107612.367157] DR3:  DR6: fffe0ff0 DR7: 
0400
[107612.367159] Call Trace:
[107612.367166]  blk_mq_complete_request+0x10a/0x140
[107612.367170]  ? hctx_lock+0xe0/0xe0
[107612.367176]  ? __wait_rcu_gp+0x1b6/0x210
[107612.367184]  ? nvme_start_ctrl+0x190/0x190
[107612.367188]  bt_tags_iter+0x87/0xa0
[107612.367194]  blk_mq_tagset_busy_iter+0x1da/0x3e0
[107612.367201]  ? nvme_start_ctrl+0x190/0x190
[107612.367206]  ? __blk_mq_get_tag+0x140/0x140
[107612.367210]  ? nvme_start_ctrl+0x190/0x190
[107612.367221]  nvme_rdma_shutdown_ctrl+0x50/0xe0 [nvme_rdma]
[107612.367228]  nvme_rdma_reset_ctrl_work+0x2c/0xd0 [nvme_rdma]
[107612.367233]  process_one_work+0x3ca/0xaa0
[107612.367243]  ? pwq_dec_nr_in_flight+0x110/0x110
[107612.367246]  ? worker_thread+0x19d/0x6c0
[107612.367257]  worker_thread+0x4e2/0x6c0
[107612.367283]  kthread+0x18d/0x1e0
[107612.367286]  ? rescuer_thread+0x740/0x740
[107612.367289]  ? kthread_delayed_work_timer_fn+0xe0/0xe0
[107612.367293]  ? kthread_delayed_work_timer_fn+0xe0/0xe0
[107612.367296]  ret_from_fork+0x24/0x30

in my test, there is _no_ timeout, but just reset controller

The state of the request is COMPLETE.

This is a race reset work and normal rmda completion path.
nvme_rdma_reset_ctrl_work
  -> nvme_rdma_shutdown_ctrl
-> nvme_cancel_request
  -> blk_mq_complete_request
we don't stop the rdma completion path to be triggered before we invoke 
nvme_cancel_request.

I think it is related to a change introduced by the new blk-mq timeout 
implementation.
before it, the blk_mq_complete_request use blk_mark_rq_complete to sync with 
timeout path.
obviously, this make blk_mq_complete_request be able to sync with itself.
the blk_mq_complete_request from reset work and rdma completion path could 
dance with each other well.

however, after this new mechanism is introduced, blk_mq_complete_request cannot 
sync with itself anymore.
so we indeed have a risk that complete request twice when we reset the 
controller forcibly in rdma driver.

Thanks
Jianchao 


> 
> Thanks
> Jianchao
> 
>> I guess it's the same issue the IsraelR/Bart/Ming are trying to fix in the 
>> block layer regarding completing requests.
>> I'll add IsraelR proposed fix to nvme-rdma that is currently on hold and see 
>> what happens.
>> Nontheless, I don't like the situation that the reset and delete flows can 
>> run concurrently.
>>
>> -Max.
>>
>> On 4/26/2018 11:27 AM, jianchao.wang wrote:
>>> Hi Max
>>>
>>> I did a similar test on nvme-rdma, the underlying fabric is soft-RoCE.
>>> A io loop, reset controller loop  and a delete/create controller loop.
>>> And found io hang below:
>>>
>>> [  230.884590] WARNING: CPU: 0 PID: 150 at 
>>> /home/will/u04/source_code/linux-stable/drivers/nvme/host/rdma.c:1755 
>>> nvme_rdma_reset_ctrl_work+0x3d/0xb0 [nvme_rdma]
>>> [  230.884689] CPU: 0 PID: 150 Comm: kworker/u16:3 Not tainted 4.17.0-rc1+ 
>>> #16
>>> [  230.884690] Hardware name: LENOVO 10MLS0E339/3106, BIOS M1AKT22A 
>>> 06/27/2017
>>> [  230.884693] Workqueue: nvme-reset-wq nvme_rdma_reset_ctrl_work 
>>> [nvme_rdma]
>>> [  230.884696] RIP: 0010:nvme_rdma_reset_ctrl_work+0x3d/0xb0 [nvme_rdma]
>>> [  230.884697] RSP: 0018:a9e30255be40 EFLAGS: 00010246
>>> [  230.884699] RAX:  RBX: 9633b64c2000 RCX: 
>>> 
>>> [  230.884700] RDX: 0001 RSI:  RDI: 
>>> 9ac05516
>>> [  230.884701] RBP: 9633b64c23b8 R08: 0001 R09: 
>>> 
>>> [  230.884702] R10:  R11:  R12: 
>>>

Re: [PATCH v1 3/4] mhi_bus: dev: netdev: add network interface driver

[Sujeev Dias]

On 04/27/2018 04:19 AM, Arnd Bergmann wrote:

On Fri, Apr 27, 2018 at 4:23 AM, Sujeev Dias  wrote:

MHI based net device driver is used for transferring IP
traffic between host and modem. Driver allows clients to
transfer data using standard network interface.

Signed-off-by: Sujeev Dias 
---
  Documentation/devicetree/bindings/bus/mhi.txt |  36 ++
  drivers/bus/Kconfig   |   1 +
  drivers/bus/mhi/Makefile  |   2 +-
  drivers/bus/mhi/devices/Kconfig   |  10 +
  drivers/bus/mhi/devices/Makefile  |   1 +
  drivers/bus/mhi/devices/mhi_netdev.c  | 893 ++

Network drivers go into drivers/net/, not into the bus subsystem.
You also need to Cc the netdev mailing list for review.

will do, thanks.

  6 files changed, 942 insertions(+), 1 deletion(-)
  create mode 100644 drivers/bus/mhi/devices/Kconfig
  create mode 100644 drivers/bus/mhi/devices/Makefile
  create mode 100644 drivers/bus/mhi/devices/mhi_netdev.c

diff --git a/Documentation/devicetree/bindings/bus/mhi.txt 
b/Documentation/devicetree/bindings/bus/mhi.txt
index ea1b620..172ae7b 100644
--- a/Documentation/devicetree/bindings/bus/mhi.txt
+++ b/Documentation/devicetree/bindings/bus/mhi.txt
@@ -139,3 +139,39 @@ mhi_controller {
 
 };
  };
+
+
+Children Devices
+
+
+MHI netdev properties
+
+- mhi,chan
+  Usage: required
+  Value type: 
+  Definition: Channel name MHI netdev support

+- mhi,mru
+  Usage: required
+  Value type: 
+  Definition: Largest packet size interface can receive in bytes.
+
+- mhi,interface-name
+  Usage: optional
+  Value type: 
+  Definition: Interface name to be given so clients can identify it
+
+- mhi,recycle-buf
+  Usage: optional
+  Value type: 
+  Definition: Set true if interface support recycling buffers.



+
+Example:
+
+
+mhi_rmnet@0 {
+   mhi,chan = "IP_HW0";
+   mhi,interface-name = "rmnet_mhi";
+   mhi,mru = <0x4000>;
+};

Who defines the "IP_HW0" and "rmnet_mhi" strings?

Shouldn't there be a "compatible" property?

IP_HW0 is the a dedicated channel for IP traffic.  It's defined  by MHI 
specification.  Supported channel names are fixed and
dedicated per device. Interface name is a network iface name given so 
clients can identify the netdevice under /net/.


Similar how pci framework bind DT based on bdf with pci end point 
driver, MHI bus uses mhi,chan property to bind children

DT node before calling probe.
mhi_main.c/mhi_create_device()

mhi_main.c/mhi_create_device()
 /* add if there is a matching DT node */
controller = mhi_cntrl->of_node;
 for_each_available_child_of_node(controller, node) {
 ret = of_property_read_string(node, "mhi,chan",
   &dt_name);
 if (ret)
 continue;
 if (!strcmp(mhi_dev->chan_name, dt_name))
  mhi_dev->dev.of_node = node;

+#define MHI_NETDEV_DRIVER_NAME "mhi_netdev"
+#define WATCHDOG_TIMEOUT (30 * HZ)
+
+#ifdef CONFIG_MHI_DEBUG
+
+#define MHI_ASSERT(cond, msg) do { \
+   if (cond) \
+   panic(msg); \
+} while (0)
+
+#define MSG_VERB(fmt, ...) do { \
+   if (mhi_netdev->msg_lvl <= MHI_MSG_LVL_VERBOSE) \
+   pr_err("[D][%s] " fmt, __func__, ##__VA_ARGS__);\
+} while (0)
+
+#define MSG_LOG(fmt, ...) do { \
+   if (mhi_netdev->msg_lvl <= MHI_MSG_LVL_INFO) \
+   pr_err("[I][%s] " fmt, __func__, ##__VA_ARGS__);\
+} while (0)
+
+#define MSG_ERR(fmt, ...) do { \
+   if (mhi_netdev->msg_lvl <= MHI_MSG_LVL_ERROR) \
+   pr_err("[E][%s] " fmt, __func__, ##__VA_ARGS__); \
+} while (0)
+

Please remove these macros and use the normal kernel
helpers we have.

Will do on next patch set.

+struct mhi_stats {
+   u32 rx_int;
+   u32 tx_full;
+   u32 tx_pkts;
+   u32 rx_budget_overflow;
+   u32 rx_frag;
+   u32 alloc_failed;
+};
+
+/* important: do not exceed sk_buf->cb (48 bytes) */
+struct mhi_skb_priv {
+   void *buf;
+   size_t size;
+   struct mhi_netdev *mhi_netdev;
+};

Shouldn't all three members already be part of an skb?

You initialize them as


+   u32 cur_mru = mhi_netdev->mru;
+   skb_priv = (struct mhi_skb_priv *)skb->cb;
+   skb_priv->buf = skb->data;
+   skb_priv->size = cur_mru;
+   skb_priv->mhi_netdev = mhi_netdev;

so I think you can remove the structure completely.

Will confirm and remove it if it's not needed.

+struct mhi_netdev {
+   int alias;
+   struct mhi_device *mhi_dev;
+   spinlock_t rx_lock;
+   bool enabled;
+   rwlock_t pm_lock; /* state change lock */
+   int (*rx_queue)(struct mhi_netdev *mhi_netdev, gfp_t gfp_t);
+   struct work_struct alloc_work;
+   int wake;
+
+   struct sk_buff_head rx_allocated;
+
+   u32 mru;
+   const char *interface_name;
+   struct napi_struct napi;
+   struct net_device *ndev;
+   struct sk_buff *frag_skb;

Re: [PATCH 1/3] dt-bindings: iio: stm32-adc: add support for STM32MP1.

[Jonathan Cameron]

On Wed, 25 Apr 2018 09:22:02 +0200
Fabrice Gasnier  wrote:

> On 04/24/2018 06:27 PM, Rob Herring wrote:
> > On Wed, Apr 18, 2018 at 05:37:52PM +0200, Fabrice Gasnier wrote:  
> >> Document support for STM32MP1 ADC. It's quite similar to STM32H7 ADC.
> >> Introduce "st,stm32mp1-adc" compatible to handle variants of this
> >> hardware such as vregready flag, interrupts, clock rate.
> >>
> >> Signed-off-by: Fabrice Gasnier 
> >> ---
> >>  Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 6 +-
> >>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt 
> >> b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> >> index e8bb824..9994384 100644
> >> --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> >> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> >> @@ -24,8 +24,11 @@ Required properties:
> >>  - compatible: Should be one of:
> >>"st,stm32f4-adc-core"
> >>"st,stm32h7-adc-core"
> >> +  "st,stm32mp1-adc-core"
> >>  - reg: Offset and length of the ADC block register set.
> >> -- interrupts: Must contain the interrupt for ADC block.
> >> +- interrupts: One or more interrupts for ADC block. Some parts like 
> >> stm32f4
> >> +  and stm32h7 share a common ADC interrupt line. stm32mp1 has separate
> >> +  lines for each ADC within ADC block.  
> > 
> > How many interrupt lines is that?  
> 
> Hi Rob, Jonathan,
> 
> I should have mentioned this: stm32mp1 has two separate interrupt lines
> for each ADC within ADC block.
> 
> Do you wish I send a V2 for this ? Or a patch to fix this ?
Hmm. I haven't pushed this out as non rebasing so I'll revert this
and the associated support so you can clean this corner up.

So please send a V2.

Thanks,

Jonathan

> 
> Please let me know,
> BR,
> Fabrice
> 
> >   
> >>  - clocks: Core can use up to two clocks, depending on part used:
> >>- "adc" clock: for the analog circuitry, common to all ADCs.
> >>  It's required on stm32f4.
> >> @@ -53,6 +56,7 @@ Required properties:
> >>  - compatible: Should be one of:
> >>"st,stm32f4-adc"
> >>"st,stm32h7-adc"
> >> +  "st,stm32mp1-adc"
> >>  - reg: Offset of ADC instance in ADC block (e.g. may be 0x0, 0x100, 
> >> 0x200).
> >>  - clocks: Input clock private to this ADC instance. It's required only on
> >>stm32f4, that has per instance clock input for registers access.
> >> -- 
> >> 1.9.1
> >>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/7] iio: adc: stm32-dfsdm: add check on max filter id

[Jonathan Cameron]

On Fri, 23 Feb 2018 13:51:00 +0100
Fabrice Gasnier  wrote:

> reg property should be checked against number of available filters.
> BTW, dfsdm->num_fls wasn't used. But it can be used for this purpose.
> This prevents using data out of allocated dfsdm->fl_list array.
> 
> Signed-off-by: Fabrice Gasnier 
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/stm32-dfsdm-adc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c 
> b/drivers/iio/adc/stm32-dfsdm-adc.c
> index 57bcb45..1b78bec 100644
> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> @@ -,8 +,8 @@ static int stm32_dfsdm_adc_probe(struct platform_device 
> *pdev)
>   platform_set_drvdata(pdev, adc);
>  
>   ret = of_property_read_u32(dev->of_node, "reg", &adc->fl_id);
> - if (ret != 0) {
> - dev_err(dev, "Missing reg property\n");
> + if (ret != 0 || adc->fl_id >= adc->dfsdm->num_fls) {
> + dev_err(dev, "Missing or bad reg property\n");
>   return -EINVAL;
>   }
>  

Re: [PATCH 5/7] iio: adc: stm32-dfsdm: misc style improvements and fixes

[Jonathan Cameron]

On Mon, 23 Apr 2018 09:48:56 +0200
Fabrice Gasnier  wrote:

> On 02/24/2018 02:03 PM, Jonathan Cameron wrote:
> > On Fri, 23 Feb 2018 13:50:59 +0100
> > Fabrice Gasnier  wrote:
> >   
> >> Misc fixes & style improvements:
> >> - checkpatch warns about line over 80 characters.
> >> - remove extra spaces and a blank line (e.g. checkpatch --strict)
> >> - remove bad error message always printed in probe routine.
> >>
> >> Signed-off-by: Fabrice Gasnier   
> > I'd have preferred this as 3 patches doing one type fo fix each.
> > 
> > Anyhow, I'll need to hold this until the fixes have made there
> > way upstream.  Give me a poke if I seem to have forgotten
> > and the dependencies have made it back to my togreg branch.  
> 
> Hi Jonathan,
> 
> There are few pending patches in this series. I'm not sure everything
> have been merged yet.
> Do you wish I resend those patches as separate series ?
> 
> Please let me know,
> Thanks in advance,
> BR,
> Fabrice
Thanks for the reminder, I'll pick them up from this original series.

For this one, applied to the togreg branch of iio.git and pushed out as
testing for the autobuilders to play with it.

Thanks,

Jonathan

> 
> > 
> > Thanks,
> > 
> > Jonathan
> >   
> >> ---
> >>  drivers/iio/adc/stm32-dfsdm-adc.c | 9 -
> >>  1 file changed, 4 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c 
> >> b/drivers/iio/adc/stm32-dfsdm-adc.c
> >> index 01422d1..57bcb45 100644
> >> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> >> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> >> @@ -253,7 +253,8 @@ static int stm32_dfsdm_start_filter(struct stm32_dfsdm 
> >> *dfsdm,
> >>  DFSDM_CR1_RSWSTART(1));
> >>  }
> >>  
> >> -static void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm, unsigned 
> >> int fl_id)
> >> +static void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm,
> >> +  unsigned int fl_id)
> >>  {
> >>/* Disable conversion */
> >>regmap_update_bits(dfsdm->regmap, DFSDM_CR1(fl_id),
> >> @@ -337,7 +338,7 @@ static int stm32_dfsdm_channel_parse_of(struct 
> >> stm32_dfsdm *dfsdm,
> >>"st,adc-channel-types", chan_idx,
> >>&of_str);
> >>if (!ret) {
> >> -  val  = stm32_dfsdm_str2val(of_str, stm32_dfsdm_chan_type);
> >> +  val = stm32_dfsdm_str2val(of_str, stm32_dfsdm_chan_type);
> >>if (val < 0)
> >>return val;
> >>} else {
> >> @@ -349,7 +350,7 @@ static int stm32_dfsdm_channel_parse_of(struct 
> >> stm32_dfsdm *dfsdm,
> >>"st,adc-channel-clk-src", chan_idx,
> >>&of_str);
> >>if (!ret) {
> >> -  val  = stm32_dfsdm_str2val(of_str, stm32_dfsdm_chan_src);
> >> +  val = stm32_dfsdm_str2val(of_str, stm32_dfsdm_chan_src);
> >>if (val < 0)
> >>return val;
> >>} else {
> >> @@ -1093,7 +1094,6 @@ static int stm32_dfsdm_adc_probe(struct 
> >> platform_device *pdev)
> >>char *name;
> >>int ret, irq, val;
> >>  
> >> -
> >>dev_data = of_device_get_match_data(dev);
> >>iio = devm_iio_device_alloc(dev, sizeof(*adc));
> >>if (!iio) {
> >> @@ -1161,7 +1161,6 @@ static int stm32_dfsdm_adc_probe(struct 
> >> platform_device *pdev)
> >>if (ret < 0)
> >>goto err_cleanup;
> >>  
> >> -  dev_err(dev, "of_platform_populate\n");
> >>if (dev_data->type == DFSDM_AUDIO) {
> >>ret = of_platform_populate(np, NULL, NULL, dev);
> >>if (ret < 0) {  
> >   
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 04/12] mm: Assign memcg-aware shrinkers bitmap to memcg

[Vladimir Davydov]

On Tue, Apr 24, 2018 at 03:24:53PM +0300, Kirill Tkhai wrote:
> >> +int expand_shrinker_maps(int old_nr, int nr)
> >> +{
> >> +  int id, size, old_size, node, ret;
> >> +  struct mem_cgroup *memcg;
> >> +
> >> +  old_size = old_nr / BITS_PER_BYTE;
> >> +  size = nr / BITS_PER_BYTE;
> >> +
> >> +  down_write(&shrinkers_max_nr_rwsem);
> >> +  for_each_node(node) {
> >
> > Iterating over cgroups first, numa nodes second seems like a better idea
> > to me. I think you should fold for_each_node in memcg_expand_maps.
> >
> >> +  idr_for_each_entry(&mem_cgroup_idr, memcg, id) {
> >
> > Iterating over mem_cgroup_idr looks strange. Why don't you use
> > for_each_mem_cgroup?
> 
>  We want to allocate shrinkers maps in mem_cgroup_css_alloc(), since
>  mem_cgroup_css_online() mustn't fail (it's a requirement of currently
>  existing design of memcg_cgroup::id).
> 
>  A new memcg is added to parent's list between two of these calls:
> 
>  css_create()
>    ss->css_alloc()
>    list_add_tail_rcu(&css->sibling, &parent_css->children)
>    ss->css_online()
> 
>  for_each_mem_cgroup() does not see allocated, but not linked children.
> >>>
> >>> Why don't we move shrinker map allocation to css_online then?
> >>
> >> Because the design of memcg_cgroup::id prohibits mem_cgroup_css_online() 
> >> to fail.
> >> This function can't fail.
> > 
> > I fail to understand why it is so. Could you please elaborate?
> 
> mem_cgroup::id is freed not in mem_cgroup_css_free(), but earlier. It's freed
> between mem_cgroup_css_offline() and mem_cgroup_free(), after the last 
> reference
> is put.
> 
> In case of sometimes we want to free it in mem_cgroup_css_free(), this will
> introduce assymmetric in the logic, which makes it more difficult. There is
> already a bug, which I fixed in
> 
> "memcg: remove memcg_cgroup::id from IDR on mem_cgroup_css_alloc() failure"
> 
> new change will make this code completely not-modular and unreadable.

How is that? AFAIU all we need to do to handle css_online failure
properly is call mem_cgroup_id_remove() from mem_cgroup_css_free().
That's it, as mem_cgroup_id_remove() is already safe to call more
than once for the same cgroup - the first call will free the id
while all subsequent calls will do nothing.

>  
> >>
> >> I don't think it will be good to dive into reworking of this stuff for 
> >> this patchset,
> >> which is really already big. Also, it will be assymmetric to allocate one 
> >> part of
> >> data in css_alloc(), while another data in css_free(). This breaks cgroup 
> >> design,
> >> which specially introduces this two function to differ allocation and 
> >> onlining.
> >> Also, I've just move the allocation to alloc_mem_cgroup_per_node_info() 
> >> like it was
> >> suggested in comments to v1...
> > 
> > Yeah, but (ab)using mem_cgroup_idr for iterating over all allocated
> > memory cgroups looks rather dubious to me...
> 
> But we have to iterate over all allocated memory cgroups in any way,
> as all of them must have expanded maps. What is the problem?
> It's rather simple method, and it faster then for_each_mem_cgroup()
> cycle, since it does not have to play with get and put of refcounters.

I don't like this, because mem_cgroup_idr was initially introduced to
avoid depletion of css ids by offline cgroups. We could fix that problem
by extending swap_cgroup to UINT_MAX, in which case mem_cgroup_idr
wouldn't be needed at all. Reusing mem_cgroup_idr for iterating over
allocated cgroups deprives us of the ability to reconsider that design
decision in future, neither does it look natural IMO. Besides, in order
to use mem_cgroup_idr for your purpose, you have to reshuffle the code
of mem_cgroup_css_alloc in a rather contrived way IMO.

I agree that allocating parts of struct mem_cgroup in css_online may
look dubious, but IMHO it's better than inventing a new way to iterate
over cgroups instead of using the iterator provided by cgroup core.
May be, you should ask Tejun which way he thinks is better.

Thanks,
Vladimir

Re: [PATCH 7/7] iio: adc: stm32-dfsdm: add check on spi-max-frequency

[Jonathan Cameron]

On Fri, 23 Feb 2018 13:51:01 +0100
Fabrice Gasnier  wrote:

> spi-max-frequency is requested for SPI master mode (only), to tune output
> clock. It may happen requested frequency isn't reachable.
> Add explicit check, so probe fails with error in this case. Otherwise,
> output clock may simply be silently turned off (conversions fail).
> 
> Signed-off-by: Fabrice Gasnier 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/stm32-dfsdm-core.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/iio/adc/stm32-dfsdm-core.c 
> b/drivers/iio/adc/stm32-dfsdm-core.c
> index e50efdc..1d0d823 100644
> --- a/drivers/iio/adc/stm32-dfsdm-core.c
> +++ b/drivers/iio/adc/stm32-dfsdm-core.c
> @@ -227,6 +227,11 @@ static int stm32_dfsdm_parse_of(struct platform_device 
> *pdev,
>   }
>  
>   priv->spi_clk_out_div = div_u64_rem(clk_freq, spi_freq, &rem) - 1;
> + if (!priv->spi_clk_out_div) {
> + /* spi_clk_out_div == 0 means ckout is OFF */
> + dev_err(&pdev->dev, "spi-max-frequency not achievable\n");
> + return -EINVAL;
> + }
>   priv->dfsdm.spi_master_freq = spi_freq;
>  
>   if (rem) {

Re: [PATCH 4.16 163/196] random: fix crng_ready() test

[Dan Rue]

On Sat, Apr 28, 2018 at 08:00:03AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Apr 27, 2018 at 11:34:43AM -0500, Dan Rue wrote:
> > On Sun, Apr 22, 2018 at 03:53:03PM +0200, Greg Kroah-Hartman wrote:
> > > 4.16-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > > 
> > > --
> > > 
> > > From: Theodore Ts'o 
> > > 
> > > commit 43838a23a05fbd13e47d750d3dfd77001536dd33 upstream.
> > > 
> > > The crng_init variable has three states:
> > > 
> > > 0: The CRNG is not initialized at all
> > > 1: The CRNG has a small amount of entropy, hopefully good enough for
> > >early-boot, non-cryptographical use cases
> > > 2: The CRNG is fully initialized and we are sure it is safe for
> > >cryptographic use cases.
> > > 
> > > The crng_ready() function should only return true once we are in the
> > > last state.  This addresses CVE-2018-1108.
> > > 
> > > Reported-by: Jann Horn 
> > > Fixes: e192be9d9a30 ("random: replace non-blocking pool...")
> > > Cc: sta...@kernel.org # 4.8+
> > > Signed-off-by: Theodore Ts'o 
> > > Reviewed-by: Jann Horn 
> > > Signed-off-by: Greg Kroah-Hartman 
> > 
> > This patch has caused a regression on 4.16 using kselftest lib/printf.sh
> > - specifically, when it runs "/sbin/modprobe test_printf". This
> > regression has been detected on arm64 dragonboard 410c (not seen on
> > other arm64 or x86_64 devices).
> > 
> > /sbin/modprobe test_printf
> > [   22.725551] test_printf: hashing plain 'p' has unexpected format
> > [   22.726031] test_printf: failed 1 out of 236 tests
> > modprobe: ERROR: could not insert 'test_printf': Invalid argument
> > 
> > This problem has not been seen on 4.9 or 4.14 under the same
> > conditions.
> 
> Does 4.17-rc2 also fail like this?

No, but I did see it in v4.17-rc2-102-g3442097b765c, and it was fixed in
the subsequent build:

good: v4.17-rc2-64-g26ed24e429d8
bad: v4.17-rc2-102-g3442097b765c
good: v4.17-rc2-104-g69bfd470f462

I haven't investigated deeper though, and I do not see any changes to
random in those above revisions. This test passes on all the other
mainline builds, including v4.17-rc2.

> 
> You all are testing the -rc releases, right?  :)

We test every push to mainline and we test -next daily.

> 
> I think the random changes that will be in 4.17-rc3 should fix this, and
> if so, I'll suck them in here too.  But testing that would be good to
> see happen...

Waiting is fine with me.

Thanks,
Dan