Re: [PATCH V4 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"

[Bjorn Helgaas]

On Thu, Oct 20, 2016 at 08:58:14PM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 19, 2016 at 06:21:03PM -0400, Sinan Kaya wrote:
> > The SCI penalize function was removed in two steps (first refactor
> > and then remove) and these changes are reverted here in one go.
> > 
> > The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> > refactored the original code so that SCI penalty is calculated dynamically
> > by the time get_penalty function is called. That change is partially
> > reverted here, specifically for the SCI IRQ alone.
> > 
> > The SCI penalize function was finally dropped by commit 9e5ed6d1fb87
> > ("ACPI,PCI,IRQ: remove SCI penalize function") that replaced the old SCI
> > penalty API with penalty calculation carried out dynamically and based
> > on the acpi_gbl_FADT.sci_interrupt value.
> > 
> > However, that new algorithm relies on the accurate setting of IRQ
> > types and that doesn't happen early enough on some platforms which
> > leads to incorrect penalty assignments for PCI IRQs.  In those cases,
> > irq_get_trigger_type() returns incorrect values for the IRQs in
> > question, because they have not been registered yet by the time the
> > penalties are calculated.
> > 
> > To fix this problem, we only need to fix the penalty for the SCI interrupt.
> > It seems better to add a single "sci_penalty" variable, set it to
> > PIRQ_PENALTY_PCI_USING if it's level/low or PIRQ_PENALTY_ISA_ALWAYS
> > otherwise, and add "sci_penalty" in when appropriate.  That should fix it
> > for *any* SCI IRQ, not just those less than 256, and we don't have to add
> > these extra penalty table entries that are all unused (except possibly for
> > one entry if we have an SCI in the 16-255 range).
> > 
> > For this reason, revert commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI
> > penalize function") completely to restore the correct behavior.
> 
> I like this patch fine, except for the changelog.  I don't think it's
> useful to describe this as a revert and give all the historical
> details.  I think the important part is something like this:
> 
>   We previously used irq_get_trigger_type(irq) to help compute the
>   penalty for the SCI, but that depends on the SCI having been
>   registered already.  Add acpi_penalize_sci_irq() so platforms can
>   tell us the SCI IRQ, trigger, and polarity so we can compute the
>   penalty even before the SCI has been registered.

Thanks for the pointer [1] to the issues around
acpi_penalize_sci_irq() being called before kmalloc() is available.
That begs the question of exactly *why* we need
acpi_penalize_sci_irq() so early -- I doubt we actually need to handle
SCIs that early, and obviously we don't need to look up penalties that
early (because we only look them up when enabling interrupt links,
which happens much later).

[1] http://marc.info/?l=linux-acpi=145580159209240=2)

> Acked-by: Bjorn Helgaas 

Wait a minute, I still have a question here: what about other ACPI
arches (ia64, arm64)?  Don't they need to call acpi_penalize_sci_irq()
somewhere?

> > ---
> >  arch/x86/kernel/acpi/boot.c |  1 +
> >  drivers/acpi/pci_link.c | 30 +++---
> >  include/linux/acpi.h|  1 +
> >  3 files changed, 17 insertions(+), 15 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> > index 90d84c3..0ffd26e 100644
> > --- a/arch/x86/kernel/acpi/boot.c
> > +++ b/arch/x86/kernel/acpi/boot.c
> > @@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, 
> > u16 polarity, u16 trigger,
> > polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
> >  
> > mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
> > +   acpi_penalize_sci_irq(bus_irq, trigger, polarity);
> >  
> > /*
> >  * stash over-ride to indicate we've been here
> > diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> > index 4f37938..294b190 100644
> > --- a/drivers/acpi/pci_link.c
> > +++ b/drivers/acpi/pci_link.c
> > @@ -87,6 +87,7 @@ struct acpi_pci_link {
> >  
> >  static LIST_HEAD(acpi_link_list);
> >  static DEFINE_MUTEX(acpi_link_lock);
> > +static int sci_irq = -1, sci_penalty;
> >  
> >  /* 
> > --
> >  PCI Link Device Management
> > @@ -496,25 +497,13 @@ static int acpi_irq_get_penalty(int irq)
> >  {
> > int penalty = 0;
> >  
> > -   /*
> > -   * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> > -   * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> > -   * use for PCI IRQs.
> > -   */
> > -   if (irq == acpi_gbl_FADT.sci_interrupt) {
> > -   u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
> > -
> > -   if (type != IRQ_TYPE_LEVEL_LOW)
> > -   penalty += PIRQ_PENALTY_ISA_ALWAYS;
> > -   else
> > -   penalty += PIRQ_PENALTY_PCI_USING;
> > -   }
> > +   

[RFC PATCH 06/13] ARM64: dts: meson-gxl: Add MMC/SD/SDIO nodes

[Neil Armstrong]

Add MMC/SD/SDIO nodes clock attributes for Amlogic Meson GXL.

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index b45df2a..d1bf381 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -235,3 +235,24 @@
 _C {
clocks = < CLKID_I2C>;
 };
+
+_emmc_a {
+   clocks = < CLKID_SD_EMMC_A>,
+<>,
+< CLKID_FCLK_DIV2>;
+   clock-names = "core", "clkin0", "clkin1";
+};
+
+_emmc_b {
+   clocks = < CLKID_SD_EMMC_B>,
+<>,
+< CLKID_FCLK_DIV2>;
+   clock-names = "core", "clkin0", "clkin1";
+};
+
+_emmc_c {
+   clocks = < CLKID_SD_EMMC_C>,
+<>,
+< CLKID_FCLK_DIV2>;
+   clock-names = "core", "clkin0", "clkin1";
+};
-- 
1.9.1

Re: [PATCH] drm/virtio: kconfig: Fixup white space.

[Sean Paul]

On Sat, Oct 8, 2016 at 3:55 AM, Peter Griffin  wrote:
> Use tabs instead of spaces.
>
> Signed-off-by: Peter Griffin 
> Acked-by: Lee Jones 

Applied to drm-misc, thanks

> ---
>  drivers/gpu/drm/virtio/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
> index e1afc3d..81d1807 100644
> --- a/drivers/gpu/drm/virtio/Kconfig
> +++ b/drivers/gpu/drm/virtio/Kconfig
> @@ -1,10 +1,10 @@
>  config DRM_VIRTIO_GPU
> tristate "Virtio GPU driver"
> depends on DRM && VIRTIO
> -select DRM_KMS_HELPER
> -select DRM_TTM
> +   select DRM_KMS_HELPER
> +   select DRM_TTM
> help
>This is the virtual GPU driver for virtio.  It can be used with
> -   QEMU based VMMs (like KVM or Xen).
> +  QEMU based VMMs (like KVM or Xen).
>
>If unsure say M.
> --
> 1.9.1
>

Re: [PATCH v3 2/4] ACPI / gpio: Add hogging support

[Mika Westerberg]

On Fri, Oct 21, 2016 at 05:21:30PM +0300, Mika Westerberg wrote:
> +See Documentation/devicetree/bindings/gpio/gpio.tx for more information

Andy noticed there is a typo in the above, should be .txt instead. Let
me know if you want me to resend the series with this fixed.

Re: [PATCH] shmem: avoid huge pages for small files

[Michal Hocko]

On Fri 21-10-16 18:00:07, Kirill A. Shutemov wrote:
> On Fri, Oct 21, 2016 at 04:01:18PM +1100, Dave Chinner wrote:
[...]
> > None of these aspects can be optimised sanely by a single threshold,
> > especially when considering the combination of access patterns vs file
> > layout.
> 
> I agree.
> 
> Here I tried to address the particular performance regression I see with
> huge pages enabled on tmpfs. It doesn't mean to fix all possible issues.

So can we start simple and use huge pages on shmem mappings only when
they are larger than the huge page? Without any tunable which might turn
out to be misleading/wrong later on. If I understand Dave's comments it
is really not all that clear that a mount option makes sense. I cannot
comment on those but they clearly show that there are multiple points of
view here.
-- 
Michal Hocko
SUSE Labs

[PATCH 1/3] ARM: dts: Add support for OX820 and Pogoplug V3

[Neil Armstrong]

Add device tree for the Oxford Seminconductor OX820 SoC and the
Cloud Engines PogoPlug v3 board.
Add the SoC and board compatible strings to oxnas bindings.

Acked-by: Rob Herring 
Signed-off-by: Neil Armstrong 
---
 Documentation/devicetree/bindings/arm/oxnas.txt|   5 +
 arch/arm/boot/dts/Makefile |   3 +-
 .../boot/dts/cloudengines-pogoplug-series-3.dts|  94 +++
 arch/arm/boot/dts/ox820.dtsi   | 298 +
 4 files changed, 399 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
 create mode 100644 arch/arm/boot/dts/ox820.dtsi

diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt 
b/Documentation/devicetree/bindings/arm/oxnas.txt
index b9e4971..ac64e60 100644
--- a/Documentation/devicetree/bindings/arm/oxnas.txt
+++ b/Documentation/devicetree/bindings/arm/oxnas.txt
@@ -5,5 +5,10 @@ Boards with the OX810SE SoC shall have the following 
properties:
   Required root node property:
 compatible: "oxsemi,ox810se"
 
+Boards with the OX820 SoC shall have the following properties:
+  Required root node property:
+compatible: "oxsemi,ox820"
+
 Board compatible values:
   - "wd,mbwe" (OX810SE)
+  - "cloudengines,pogoplugv3" (OX820)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..3b0c74f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -604,7 +604,8 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
 dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
 dtb-$(CONFIG_ARCH_OXNAS) += \
-   wd-mbwe.dtb
+   wd-mbwe.dtb \
+   cloudengines-pogoplug-series-3.dtb
 dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8060-dragonboard.dtb \
qcom-apq8064-arrow-sd-600eval.dtb \
diff --git a/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts 
b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
new file mode 100644
index 000..bfde32e
--- /dev/null
+++ b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
@@ -0,0 +1,94 @@
+/*
+ * cloudengines-pogoplug-series-3.dtsi - Device tree file for Cloud Engines 
PogoPlug Series 3
+ *
+ * Copyright (C) 2016 Neil Armstrong 
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+#include "ox820.dtsi"
+
+/ {
+   model = "Cloud Engines PogoPlug Series 3";
+
+   compatible = "cloudengines,pogoplugv3", "oxsemi,ox820";
+
+   chosen {
+   bootargs = "earlyprintk";
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   /* 128Mbytes DDR */
+   reg = <0x6000 0x800>;
+   };
+
+   aliases {
+   serial0 = 
+   gpio0 = 
+   gpio1 = 
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   blue {
+   label = "pogoplug:blue";
+   gpios = < 2 0>;
+   default-state = "keep";
+   };
+
+   orange {
+   label = "pogoplug:orange";
+   gpios = < 16 1>;
+   default-state = "keep";
+   };
+
+   green {
+   label = "pogoplug:green";
+   gpios = < 17 1>;
+   default-state = "keep";
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart0>;
+};
+
+ {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_nand>;
+
+   nand@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   nand-ecc-mode = "soft";
+   nand-ecc-algo = "hamming";
+
+   partition@0 {
+   label = "boot";
+   reg = <0x 0x00e0>;
+   read-only;
+   };
+
+   partition@e0 {
+   label = "ubi";
+   reg = <0x00e0 0x0720>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_etha_mdio>;
+};
diff --git a/arch/arm/boot/dts/ox820.dtsi b/arch/arm/boot/dts/ox820.dtsi
new file mode 100644
index 000..4592075
--- /dev/null
+++ b/arch/arm/boot/dts/ox820.dtsi
@@ -0,0 +1,298 @@
+/*
+ * ox820.dtsi - Device tree file for Oxford Semiconductor OX820 SoC
+ *
+ * Copyright (C) 2016 Neil Armstrong 
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "oxsemi,ox820";
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   enable-method = "oxsemi,ox820-smp";
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = 

Re: [PATCH 01/12] Documentation/HOWTO: Mark subsection in rst format

[Mauro Carvalho Chehab]

Em Sat, 22 Oct 2016 00:19:46 +0900
SeongJae Park  escreveu:

> Subsections in HOWTO is not marked in rst format.  This commit specifies
> them in rst format.
> 
> Signed-off-by: SeongJae Park 
> ---
>  Documentation/HOWTO | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)

There are already patches converting HOWTO to ReST applied upstream:

commit 1b49ecf2f3be358882bb97652ba50ae808c0ba8f
Author: Jonathan Corbet 
Date:   Tue Sep 20 18:46:36 2016 -0600

docs: Clean up bare :: lines

Mauro's patch set introduced some bare :: lines; these can be represented
by a double colon at the end of the preceding text line.  The result looks
a little less weird and is less verbose.

Signed-off-by: Jonathan Corbet 

commit f1eebe92c2653e8fc3760577e53befdc9b62ef26
Author: Mauro Carvalho Chehab 
Date:   Mon Sep 19 08:07:59 2016 -0300

Documentation/HOWTO: adjust external link references

- A few link references were missing http://
- Several sites are now redirecting to https protocol. On such
  cases, just use the https URL.

NOTE: all URLs were checked and they're pointing to the right places.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jonathan Corbet 

commit 34fed7e7e0e56f885f309e8892a3571400072e37
Author: Mauro Carvalho Chehab 
Date:   Mon Sep 19 08:07:58 2016 -0300

Documentation/HOWTO: improve some markups to make it visually better

Do a series of minor improvements at the ReST output format:

- Instead of using the quote blocks (::) for quotes, use
italics. That looks nicer on epub (and html) output, as
no scroll bar will be added. Also, it will adjust line
breaks on the text automatically.

- Add a missing reference to SubmittingPatches.rst and use
**foo** instead of _foo_.

- use bold for "The Perfect Patch" by removing a newline.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jonathan Corbet 

commit 43fb67a5258c0f3d1d869cb7d72617d87b257c62
Author: Mauro Carvalho Chehab 
Date:   Mon Sep 19 08:07:57 2016 -0300

Documentation/HOWTO: update information about generating documentation

The description there are pre-Sphinx. Update it to cover the
new way.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Jonathan Corbet 


There's also a series of patches pending merge that moves it
Documentation/process/howto.rst and add to this book:

https://mchehab.fedorapeople.org/kernel_docs/process/howto.html


Thanks,
Mauro

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Philipp Zabel]

 A. Hi Geert,

Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Hi Philipp, Mike, Stephen, Simon, Magnus,
>   (see questions *** below!)
> 
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
> 
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
> 
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module.  Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().

I think you should add a binding doc even though the DT bindings are
still trivial.

> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> 
> This series consists of 5 parts:
>   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
>  driver,
>   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
>  files,
>   C. Patches 12-17 convert the clock drivers to call into the new R-Car
>  RST driver,
>   D. Patches 18-20 remove passing mode pin state to the clock drivers
>  from the platform code,
>   E. Patches 21-23 remove dead code from the clock drivers.
> 
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
>   - The DT updates in Part B can be merged as soon as the DT bindings in
> Part A have been approved,
>   - The clock driver updates in Part C depend functionally on the driver
> code in Part A, and on the DT updates in Part B,
>   - The board code cleanups in Part D depend on the clock driver updates
> in Part C,
>   - The block driver cleanups in part E depend on the board code
> cleanups in part D.
> 
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
> 
> ***
> 
>   - Philip: While this is a driver for a reset-controller, currently it
> doesn't provide any reset-controller functionality. Hence I added it
> to drivers/soc/renesas/. Is that OK for you?

Absolutely, as long as the driver isn't even a reset controller
provider, this is the right place.

regards
Philipp

Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump

[Eric Dumazet]

On Fri, 2016-10-21 at 11:03 -0400, David Miller wrote:

> If this is changing default behavior we should approach this the other
> way around.
> 
> Keep behaving the way we do, user asks for new behavior with the attribute.
SGTM

Re: [PATCH 4.7 00/45] 4.7.10-stable review

[Shuah Khan]

On 10/21/2016 03:17 AM, Greg Kroah-Hartman wrote:
> 
> NOTE, this will be the last 4.7.y kernel to be released.  After this
> one, the 4.7.y series is end-of-life.  You should be moving to the 4.8.y
> kernel series at this point in time.
> 
> 
> This is the start of the stable review cycle for the 4.7.10 release.
> There are 45 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 Oct 23 09:14:13 UTC 2016.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.7.10-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.7.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

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

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com

Re: [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection

[Andrew Lunn]

On Fri, Oct 21, 2016 at 04:40:33PM +0200, Neil Armstrong wrote:
> The Meson GXL dwmac Glue Layer also provides switching between an external PHY
> and an internal RMII 10/100 PHY.
> Add a way to setup the correct PHY switching from a device tree attribute.

Humm, actually. Maybe PHY_IS_INTERNAL in the phydrv->flags is the
better solution. The MAC can then use phy_is_internal(ndev->phydev) to
decide if this register needs programming.

   Andrew

Re: [PATCH 0/6] ARM: sun5i: chip: Misc improvements

[Maxime Ripard]

On Fri, Oct 21, 2016 at 11:02:23AM +0800, Chen-Yu Tsai wrote:
> On Mon, Oct 17, 2016 at 7:48 PM, Maxime Ripard
>  wrote:
> > Hi,
> >
> > This is a bunch of patches I gathered for the CHIP, that enables a few
> > things, like the WiFi regulators (and its associated power sequence), a few
> > optional buses, etc.

Applied all with your Acked-by

> FYI this series makes more sense if you mention the Pocket CHIP DT overlays.

Not really, most of these patches are for the CHIP itself. The Pocket
CHIP, just like all the other DIPs so far, uses the LCD pins, but
that's pretty much the only DIP-specific patch there.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH] Staging:vt6656:main_usb: fix Block comments should align the * on each line

[Nadim Almas]

Block comments should align the * on each line as reported by checkpatch.pl

Signed-off-by: Nadim Almas 
---
 drivers/staging/vt6656/main_usb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vt6656/main_usb.c 
b/drivers/staging/vt6656/main_usb.c
index fe84da3..50d02d9 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -326,9 +326,9 @@ static int vnt_init_registers(struct vnt_private *priv)
priv->current_net_addr);
 
/*
-   * set BB and packet type at the same time
-   * set Short Slot Time, xIFS, and RSPINF
-   */
+* set BB and packet type at the same time
+* set Short Slot Time, xIFS, and RSPINF
+*/
if (priv->bb_type == BB_TYPE_11A)
priv->short_slot_time = true;
else
-- 
2.7.4

[PATCH] scripts/faddr2line: fix "size mismatch" error

[Josh Poimboeuf]

I'm not sure how we missed this problem before.  When I take a function
address and size from an oops and give it to faddr2line, it usually
complains about a size mismatch:

  $ scripts/faddr2line ~/k/vmlinux write_sysrq_trigger+0x51/0x60
  skipping write_sysrq_trigger address at 0x815731a1 due to size 
mismatch (0x60 != 83)
  no match for write_sysrq_trigger+0x51/0x60

The problem is caused by differences in how kallsyms and faddr2line
determine a function's size.

kallsyms calculates a function's size by parsing the output of 'nm -n'
and subtracting the next function's address from the current function's
address.  This means that nop instructions after the end of the function
are included in the size.

In contrast, faddr2line reads the size from the symbol table, which does
*not* include the ending nops in the function's size.

Change faddr2line to calculate the size from the output of 'nm -n' to be
consistent with kallsyms and oops outputs.

Signed-off-by: Josh Poimboeuf 
---
 scripts/faddr2line | 33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/scripts/faddr2line b/scripts/faddr2line
index 450b332..29df825 100755
--- a/scripts/faddr2line
+++ b/scripts/faddr2line
@@ -105,9 +105,18 @@ __faddr2line() {
# In rare cases there might be duplicates.
while read symbol; do
local fields=($symbol)
-   local sym_base=0x${fields[1]}
-   local sym_size=${fields[2]}
-   local sym_type=${fields[3]}
+   local sym_base=0x${fields[0]}
+   local sym_type=${fields[1]}
+   local sym_end=0x${fields[3]}
+
+   # calculate the size
+   local sym_size=$(($sym_end - $sym_base))
+   if [[ -z $sym_size ]] || [[ $sym_size -le 0 ]]; then
+   warn "bad symbol size: base: $sym_base end: $sym_end"
+   DONE=1
+   return
+   fi
+   sym_size=0x$(printf %x $sym_size)
 
# calculate the address
local addr=$(($sym_base + $offset))
@@ -116,26 +125,26 @@ __faddr2line() {
DONE=1
return
fi
-   local hexaddr=0x$(printf %x $addr)
+   addr=0x$(printf %x $addr)
 
# weed out non-function symbols
-   if [[ $sym_type != "FUNC" ]]; then
+   if [[ $sym_type != t ]] && [[ $sym_type != T ]]; then
[[ $print_warnings = 1 ]] &&
-   echo "skipping $func address at $hexaddr due to 
non-function symbol"
+   echo "skipping $func address at $addr due to 
non-function symbol of type '$sym_type'"
continue
fi
 
# if the user provided a size, make sure it matches the 
symbol's size
if [[ -n $size ]] && [[ $size -ne $sym_size ]]; then
[[ $print_warnings = 1 ]] &&
-   echo "skipping $func address at $hexaddr due to 
size mismatch ($size != $sym_size)"
+   echo "skipping $func address at $addr due to 
size mismatch ($size != $sym_size)"
continue;
fi
 
# make sure the provided offset is within the symbol's range
if [[ $offset -gt $sym_size ]]; then
[[ $print_warnings = 1 ]] &&
-   echo "skipping $func address at $hexaddr due to 
size mismatch ($offset > $sym_size)"
+   echo "skipping $func address at $addr due to 
size mismatch ($offset > $sym_size)"
continue
fi
 
@@ -143,12 +152,12 @@ __faddr2line() {
[[ $FIRST = 0 ]] && echo
FIRST=0
 
-   local hexsize=0x$(printf %x $sym_size)
-   echo "$func+$offset/$hexsize:"
-   addr2line -fpie $objfile $hexaddr | sed "s; 
$dir_prefix\(\./\)*; ;"
+   # pass real address to addr2line
+   echo "$func+$offset/$sym_size:"
+   addr2line -fpie $objfile $addr | sed "s; $dir_prefix\(\./\)*; ;"
DONE=1
 
-   done < <(readelf -sW $objfile | awk -v f=$func '$8 == f {print}')
+   done < <(nm -n $objfile | awk -v fn=$func '$3 == fn { found=1; line=$0; 
start=$1; next } found == 1 { found=0; print line, $1 }')
 }
 
 [[ $# -lt 2 ]] && usage
-- 
2.7.4

[PATCH] KVM: x86: fix wbinvd_dirty_mask use-after-free

[Ido Yariv]

vcpu->arch.wbinvd_dirty_mask may still be used after freeing it,
corrupting memory. For example, the following call trace may set a bit
in an already freed cpu mask:
kvm_arch_vcpu_load
vcpu_load
vmx_free_vcpu_nested
vmx_free_vcpu
kvm_arch_vcpu_free

Fix this by deferring freeing of wbinvd_dirty_mask.

Cc: sta...@vger.kernel.org
Signed-off-by: Ido Yariv 
---
 arch/x86/kvm/x86.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6c633de..9ec8c1d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7410,10 +7410,12 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
 
 void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
 {
+   void *wbinvd_dirty_mask = vcpu->arch.wbinvd_dirty_mask;
+
kvmclock_reset(vcpu);
 
-   free_cpumask_var(vcpu->arch.wbinvd_dirty_mask);
kvm_x86_ops->vcpu_free(vcpu);
+   free_cpumask_var(wbinvd_dirty_mask);
 }
 
 struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
-- 
2.5.5

[PATCH V7 3/4] dmaengine: qcom_hidma: protect common data structures

[Sinan Kaya]

When MSI interrupts are supported, error and the transfer interrupt can
come from multiple processor contexts.

Each error interrupt is an MSI interrupt. If the channel is disabled by
the first error interrupt, the remaining error interrupts will gracefully
return in the interrupt handler.

If an error is observed while servicing the completions in success case,
the posting of the completions will be aborted as soon as channel disabled
state is observed. The error interrupt handler will take it from there and
finish the remaining completions. We don't want to create multiple success
and error messages to be delivered to the client in mixed order.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/hidma_ll.c | 44 +++-
 1 file changed, 11 insertions(+), 33 deletions(-)

diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index 9193f46..7fe43af 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -198,13 +198,16 @@ static void hidma_ll_tre_complete(unsigned long arg)
}
 }
 
-static int hidma_post_completed(struct hidma_lldev *lldev, int tre_iterator,
-   u8 err_info, u8 err_code)
+static int hidma_post_completed(struct hidma_lldev *lldev, u8 err_info,
+   u8 err_code)
 {
struct hidma_tre *tre;
unsigned long flags;
+   u32 tre_iterator;
 
spin_lock_irqsave(>lock, flags);
+
+   tre_iterator = lldev->tre_processed_off;
tre = lldev->pending_tre_list[tre_iterator / HIDMA_TRE_SIZE];
if (!tre) {
spin_unlock_irqrestore(>lock, flags);
@@ -223,6 +226,9 @@ static int hidma_post_completed(struct hidma_lldev *lldev, 
int tre_iterator,
atomic_set(>pending_tre_count, 0);
}
 
+   HIDMA_INCREMENT_ITERATOR(tre_iterator, HIDMA_TRE_SIZE,
+lldev->tre_ring_size);
+   lldev->tre_processed_off = tre_iterator;
spin_unlock_irqrestore(>lock, flags);
 
tre->err_info = err_info;
@@ -244,13 +250,11 @@ static int hidma_post_completed(struct hidma_lldev 
*lldev, int tre_iterator,
 static int hidma_handle_tre_completion(struct hidma_lldev *lldev)
 {
u32 evre_ring_size = lldev->evre_ring_size;
-   u32 tre_ring_size = lldev->tre_ring_size;
u32 err_info, err_code, evre_write_off;
-   u32 tre_iterator, evre_iterator;
+   u32 evre_iterator;
u32 num_completed = 0;
 
evre_write_off = readl_relaxed(lldev->evca + HIDMA_EVCA_WRITE_PTR_REG);
-   tre_iterator = lldev->tre_processed_off;
evre_iterator = lldev->evre_processed_off;
 
if ((evre_write_off > evre_ring_size) ||
@@ -273,12 +277,9 @@ static int hidma_handle_tre_completion(struct hidma_lldev 
*lldev)
err_code =
(cfg >> HIDMA_EVRE_CODE_BIT_POS) & HIDMA_EVRE_CODE_MASK;
 
-   if (hidma_post_completed(lldev, tre_iterator, err_info,
-err_code))
+   if (hidma_post_completed(lldev, err_info, err_code))
break;
 
-   HIDMA_INCREMENT_ITERATOR(tre_iterator, HIDMA_TRE_SIZE,
-tre_ring_size);
HIDMA_INCREMENT_ITERATOR(evre_iterator, HIDMA_EVRE_SIZE,
 evre_ring_size);
 
@@ -302,16 +303,10 @@ static int hidma_handle_tre_completion(struct hidma_lldev 
*lldev)
if (num_completed) {
u32 evre_read_off = (lldev->evre_processed_off +
 HIDMA_EVRE_SIZE * num_completed);
-   u32 tre_read_off = (lldev->tre_processed_off +
-   HIDMA_TRE_SIZE * num_completed);
-
evre_read_off = evre_read_off % evre_ring_size;
-   tre_read_off = tre_read_off % tre_ring_size;
-
writel(evre_read_off, lldev->evca + HIDMA_EVCA_DOORBELL_REG);
 
/* record the last processed tre offset */
-   lldev->tre_processed_off = tre_read_off;
lldev->evre_processed_off = evre_read_off;
}
 
@@ -321,27 +316,10 @@ static int hidma_handle_tre_completion(struct hidma_lldev 
*lldev)
 void hidma_cleanup_pending_tre(struct hidma_lldev *lldev, u8 err_info,
   u8 err_code)
 {
-   u32 tre_iterator;
-   u32 tre_ring_size = lldev->tre_ring_size;
-   int num_completed = 0;
-   u32 tre_read_off;
-
-   tre_iterator = lldev->tre_processed_off;
while (atomic_read(>pending_tre_count)) {
-   if (hidma_post_completed(lldev, tre_iterator, err_info,
-err_code))
+   if (hidma_post_completed(lldev, err_info, err_code))
break;
-   HIDMA_INCREMENT_ITERATOR(tre_iterator, HIDMA_TRE_SIZE,
-

[PATCH V7 4/4] dmaengine: qcom_hidma: add MSI support for interrupts

[Sinan Kaya]

The interrupts can now be delivered as platform MSI interrupts on newer
platforms. The code looks for a new OF and ACPI strings in order to enable
the functionality.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/hidma.c| 143 ++--
 drivers/dma/qcom/hidma.h|   2 +
 drivers/dma/qcom/hidma_ll.c |   8 +++
 3 files changed, 147 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index e244e10..d5e7991 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -56,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../dmaengine.h"
 #include "hidma.h"
@@ -70,6 +71,7 @@
 #define HIDMA_ERR_INFO_SW  0xFF
 #define HIDMA_ERR_CODE_UNEXPECTED_TERMINATE0x0
 #define HIDMA_NR_DEFAULT_DESC  10
+#define HIDMA_MSI_INTS 11
 
 static inline struct hidma_dev *to_hidma_dev(struct dma_device *dmadev)
 {
@@ -553,6 +555,15 @@ static irqreturn_t hidma_chirq_handler(int chirq, void 
*arg)
return hidma_ll_inthandler(chirq, lldev);
 }
 
+static irqreturn_t hidma_chirq_handler_msi(int chirq, void *arg)
+{
+   struct hidma_lldev **lldevp = arg;
+   struct hidma_dev *dmadev = to_hidma_dev_from_lldev(lldevp);
+
+   return hidma_ll_inthandler_msi(chirq, *lldevp,
+  1 << (chirq - dmadev->msi_virqbase));
+}
+
 static ssize_t hidma_show_values(struct device *dev,
 struct device_attribute *attr, char *buf)
 {
@@ -590,6 +601,104 @@ static int hidma_create_sysfs_entry(struct hidma_dev 
*dev, char *name,
return device_create_file(dev->ddev.dev, attrs);
 }
 
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+static void hidma_write_msi_msg(struct msi_desc *desc, struct msi_msg *msg)
+{
+   struct device *dev = msi_desc_to_dev(desc);
+   struct hidma_dev *dmadev = dev_get_drvdata(dev);
+
+   if (!desc->platform.msi_index) {
+   writel(msg->address_lo, dmadev->dev_evca + 0x118);
+   writel(msg->address_hi, dmadev->dev_evca + 0x11C);
+   writel(msg->data, dmadev->dev_evca + 0x120);
+   }
+}
+#endif
+
+static void hidma_free_msis(struct hidma_dev *dmadev)
+{
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+   struct device *dev = dmadev->ddev.dev;
+   struct msi_desc *desc;
+
+   /* free allocated MSI interrupts above */
+   for_each_msi_entry(desc, dev)
+   devm_free_irq(dev, desc->irq, >lldev);
+
+   platform_msi_domain_free_irqs(dev);
+#endif
+}
+
+static int hidma_request_msi(struct hidma_dev *dmadev,
+struct platform_device *pdev)
+{
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+   int rc;
+   struct msi_desc *desc;
+   struct msi_desc *failed_desc = NULL;
+
+   rc = platform_msi_domain_alloc_irqs(>dev, HIDMA_MSI_INTS,
+   hidma_write_msi_msg);
+   if (rc)
+   return rc;
+
+   for_each_msi_entry(desc, >dev) {
+   if (!desc->platform.msi_index)
+   dmadev->msi_virqbase = desc->irq;
+
+   rc = devm_request_irq(>dev, desc->irq,
+  hidma_chirq_handler_msi,
+  0, "qcom-hidma-msi",
+  >lldev);
+   if (rc) {
+   failed_desc = desc;
+   break;
+   }
+   }
+
+   if (rc) {
+   /* free allocated MSI interrupts above */
+   for_each_msi_entry(desc, >dev) {
+   if (desc == failed_desc)
+   break;
+   devm_free_irq(>dev, desc->irq,
+ >lldev);
+   }
+   } else {
+   /* Add callback to free MSIs on teardown */
+   hidma_ll_setup_irq(dmadev->lldev, true);
+
+   }
+   if (rc)
+   dev_warn(>dev,
+"failed to request MSI irq, falling back to wired 
IRQ\n");
+   return rc;
+#else
+   return -EINVAL;
+#endif
+}
+
+static bool hidma_msi_capable(struct device *dev)
+{
+   struct acpi_device *adev = ACPI_COMPANION(dev);
+   const char *of_compat;
+   int ret = -EINVAL;
+
+   if (!adev || acpi_disabled) {
+   ret = device_property_read_string(dev, "compatible",
+ _compat);
+   if (ret)
+   return false;
+
+   ret = strcmp(of_compat, "qcom,hidma-1.1");
+   } else {
+#ifdef CONFIG_ACPI
+   ret = strcmp(acpi_device_hid(adev), "QCOM8062");
+#endif
+   }
+   return ret == 0;
+}
+
 static int hidma_probe(struct platform_device *pdev)
 {
struct hidma_dev *dmadev;
@@ -599,6 +708,7 @@ static int hidma_probe(struct platform_device *pdev)
  

Re: [PATCH] usb: xhci: Workaround for erratum-A010129

[Alan Stern]

On Fri, 21 Oct 2016, Sriram Dash wrote:

> For the USB3.0 controller, USB 2.0 reset not driven while
> port is in Resume state. So, do not program the USB 2.0 reset
> (PORTSC[PR]=1) while in Resume state.
> 
> Signed-off-by: Rajat Srivastava 
> Signed-off-by: Sriram Dash 
> Signed-off-by: Rajesh Bhagat 
> ---
>  drivers/usb/host/xhci-hub.c | 28 +++-
>  drivers/usb/host/xhci.h |  1 +
>  2 files changed, 28 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index 730b9fd..3def0dd 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -878,7 +878,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
> u16 wValue,
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>   int max_ports;
>   unsigned long flags;
> - u32 temp, status;
> + u32 temp, status, tmp_status = 0;
>   int retval = 0;
>   __le32 __iomem **port_array;
>   int slot_id;
> @@ -1098,6 +1098,32 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
> u16 wValue,
>   spin_lock_irqsave(>lock, flags);
>   break;
>   case USB_PORT_FEAT_RESET:
> + /*
> +  * Erratum : A010129
> +  * Synopsys STAR 9000962562.
> +  * USB 2.0 Reset Not Driven While Port in Resume
> +  * While in USB 2.0 resume state (the PORTSC.PLS
> +  * register bit is set to 4'd15), if the xHCI driver
> +  * programs the PORTSC.PR register bit to 1, the
> +  * controller does not drive a USB 2.0 reset
> +  * and it does not generate a PORTSC.PRC=1 interrupt.
> +  * So, The xHCI driver should not program a USB
> +  * 2.0 reset (PORTSC.PR=1) while in resume
> +  * (PORTSC.PLS=4'd15).
> +  */
> + if (xhci->quirks & XHCI_PORT_RST_ON_RESUME) {

It's always a bad idea to drive a reset signal while a port is 
resuming.  We don't need a quirk flag for this.  The HCD should never 
do it, and the USB core should never tell the HCD to do it.

Alan Stern

[GIT PULL] SCSI fixes for 4.9-rc1

[James Bottomley]

Five small fixes.  Some of these, like the nested spinlock overwriting
saved flags and the Kasan use after free look serious, but they seem
not to have been picked up in testing or seen in the field.  The
biggest user visible issue is probably the wrong device handler for
Clariion, which means that alua doesn't bind to the array like it
should.

The patch is available here:

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

The short changelog is:

Brian King (1):
  scsi: ipr: Fix async error WARN_ON

Dan Carpenter (1):
  scsi: zfcp: spin_lock_irqsave() is not nestable

Ming Lei (2):
  scsi: Remove one useless stack variable
  scsi: Fix use-after-free

Xose Vazquez Perez (1):
  scsi: Replace wrong device handler name for CLARiiON arrays

And the diffstat:

 drivers/s390/scsi/zfcp_dbf.c | 2 +-
 drivers/scsi/ipr.c   | 3 +--
 drivers/scsi/scsi_dh.c   | 6 +++---
 drivers/scsi/scsi_scan.c | 6 +-
 4 files changed, 6 insertions(+), 11 deletions(-)

With full diff below.

James

---

diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
index 637cf89..5810019 100644
--- a/drivers/s390/scsi/zfcp_dbf.c
+++ b/drivers/s390/scsi/zfcp_dbf.c
@@ -384,7 +384,7 @@ void zfcp_dbf_san(char *tag, struct zfcp_dbf *dbf,
/* if (len > rec_len):
 * dump data up to cap_len ignoring small duplicate in rec->payload
 */
-   spin_lock_irqsave(>pay_lock, flags);
+   spin_lock(>pay_lock);
memset(payload, 0, sizeof(*payload));
memcpy(payload->area, paytag, ZFCP_DBF_TAG_LEN);
payload->fsf_req_id = req_id;
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index a8762a3..5324741 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -2586,7 +2586,6 @@ static void ipr_process_error(struct ipr_cmnd *ipr_cmd)
struct ipr_hostrcb *hostrcb = ipr_cmd->u.hostrcb;
u32 ioasc = be32_to_cpu(ipr_cmd->s.ioasa.hdr.ioasc);
u32 fd_ioasc;
-   char *envp[] = { "ASYNC_ERR_LOG=1", NULL };
 
if (ioa_cfg->sis64)
fd_ioasc = be32_to_cpu(hostrcb->hcam.u.error64.fd_ioasc);
@@ -2607,8 +2606,8 @@ static void ipr_process_error(struct ipr_cmnd *ipr_cmd)
}
 
list_add_tail(>queue, _cfg->hostrcb_report_q);
+   schedule_work(_cfg->work_q);
hostrcb = ipr_get_free_hostrcb(ioa_cfg);
-   kobject_uevent_env(_cfg->host->shost_dev.kobj, KOBJ_CHANGE, envp);
 
ipr_send_hcam(ioa_cfg, IPR_HCAM_CDB_OP_CODE_LOG_DATA, hostrcb);
 }
diff --git a/drivers/scsi/scsi_dh.c b/drivers/scsi/scsi_dh.c
index 54d446c..b8d3b97 100644
--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -36,9 +36,9 @@ struct scsi_dh_blist {
 };
 
 static const struct scsi_dh_blist scsi_dh_blist[] = {
-   {"DGC", "RAID", "clariion" },
-   {"DGC", "DISK", "clariion" },
-   {"DGC", "VRAID","clariion" },
+   {"DGC", "RAID", "emc" },
+   {"DGC", "DISK", "emc" },
+   {"DGC", "VRAID","emc" },
 
{"COMPAQ", "MSA1000 VOLUME","hp_sw" },
{"COMPAQ", "HSV110","hp_sw" },
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 212e98d..6f7128f 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -1307,7 +1307,6 @@ static void scsi_sequential_lun_scan(struct scsi_target 
*starget,
 static int scsi_report_lun_scan(struct scsi_target *starget, int bflags,
enum scsi_scan_mode rescan)
 {
-   char devname[64];
unsigned char scsi_cmd[MAX_COMMAND_SIZE];
unsigned int length;
u64 lun;
@@ -1349,9 +1348,6 @@ static int scsi_report_lun_scan(struct scsi_target 
*starget, int bflags,
}
}
 
-   sprintf(devname, "host %d channel %d id %d",
-   shost->host_no, sdev->channel, sdev->id);
-
/*
 * Allocate enough to hold the header (the same size as one scsi_lun)
 * plus the number of luns we are requesting.  511 was the default
@@ -1470,12 +1466,12 @@ static int scsi_report_lun_scan(struct scsi_target 
*starget, int bflags,
  out_err:
kfree(lun_data);
  out:
-   scsi_device_put(sdev);
if (scsi_device_created(sdev))
/*
 * the sdev we used didn't appear in the report luns scan
 */
__scsi_remove_device(sdev);
+   scsi_device_put(sdev);
return ret;
 }
 

Re: [PATCH] iio: light: acpi-als: Add IO_CHAN_INFO_OFFSET/SCALE to mask.

[Gwendal Grignou]

On Fri, Oct 21, 2016 at 1:17 AM, Enric Balletbo i Serra
 wrote:
> According the ACPI specification (Version 5.0 Errata A) [1], the data
> coming from the sensor represent the ambient light illuminance reading
> expressed in lux. Unfortunately ACPI interface doesn't provide a
> mechanism to calibrate this value, so this raw value can be slightly
> wrong.
>
> This patch adds IIO_CHAN_INFO_OFFSET and IIO_CHAN_INFO_SCALE attributes
> to give the possibiity to the userspace to calculate a calibrated data
> by doing:
>
>  (raw_value + offset) * scale = calibrated_value (in lux)
>
> [1] http://www.acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf
>
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  drivers/iio/light/acpi-als.c | 66 
> ++--
>  1 file changed, 57 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iio/light/acpi-als.c b/drivers/iio/light/acpi-als.c
> index f0b47c5..a8093ba 100644
> --- a/drivers/iio/light/acpi-als.c
> +++ b/drivers/iio/light/acpi-als.c
> @@ -56,7 +56,9 @@ static const struct iio_chan_spec acpi_als_channels[] = {
> },
> /* _RAW is here for backward ABI compatibility */
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> - BIT(IIO_CHAN_INFO_PROCESSED),
> + BIT(IIO_CHAN_INFO_PROCESSED) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_OFFSET),
> },
>  };
>
> @@ -76,6 +78,10 @@ struct acpi_als {
> struct mutexlock;
>
> s32 evt_buffer[ACPI_ALS_EVT_BUFFER_SIZE];
> +
> +   int scale;
> +   int uscale;
> +   int offset;
>  };
>
>  /*
> @@ -154,25 +160,64 @@ static int acpi_als_read_raw(struct iio_dev *indio_dev,
> s32 temp_val;
> int ret;
>
> -   if ((mask != IIO_CHAN_INFO_PROCESSED) && (mask != IIO_CHAN_INFO_RAW))
> -   return -EINVAL;
> -
> /* we support only illumination (_ALI) so far. */
> if (chan->type != IIO_LIGHT)
> return -EINVAL;
>
> -   ret = acpi_als_read_value(als, ACPI_ALS_ILLUMINANCE, _val);
> -   if (ret < 0)
> -   return ret;
> +   switch (mask) {
> +   case IIO_CHAN_INFO_RAW:
> +   case IIO_CHAN_INFO_PROCESSED:
It seems PROCESSED is identical to RAW. Shouldn't we remove this attribute?
> +   ret = acpi_als_read_value(als, ACPI_ALS_ILLUMINANCE, 
> _val);
> +   if (ret < 0)
> +   return ret;
> +   *val = temp_val;
> +   return IIO_VAL_INT;
> +   case IIO_CHAN_INFO_OFFSET:
> +   mutex_lock(>lock);
> +   *val = als->offset;
> +   mutex_unlock(>lock);
> +   return IIO_VAL_INT;
> +   case IIO_CHAN_INFO_SCALE:
> +   mutex_lock(>lock);
> +   *val = als->scale;
> +   *val2 = als->uscale;
> +   mutex_unlock(>lock);
> +   return IIO_VAL_INT_PLUS_MICRO;
> +   default:
> +   return -EINVAL;
> +   }
> +}
>
> -   *val = temp_val;
> +static int acpi_als_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int val,
> + int val2, long mask)
> +{
> +   struct acpi_als *als = iio_priv(indio_dev);
> +
> +   if (chan->type != IIO_LIGHT)
> +   return -EINVAL;
>
> -   return IIO_VAL_INT;
> +   switch (mask) {
> +   case IIO_CHAN_INFO_OFFSET:
> +   mutex_lock(>lock);
> +   als->offset = val;
> +   mutex_unlock(>lock);
> +   return 0;
> +   case IIO_CHAN_INFO_SCALE:
> +   mutex_lock(>lock);
> +   als->scale = val;
> +   als->uscale = val2;
> +   mutex_unlock(>lock);
> +   return 0;
> +   default:
> +   return -EINVAL;
> +   }
>  }
>
>  static const struct iio_info acpi_als_info = {
> .driver_module  = THIS_MODULE,
> .read_raw   = acpi_als_read_raw,
> +   .write_raw  = acpi_als_write_raw,
>  };
>
>  static int acpi_als_add(struct acpi_device *device)
> @@ -189,6 +234,9 @@ static int acpi_als_add(struct acpi_device *device)
>
> device->driver_data = indio_dev;
> als->device = device;
> +   als->scale = 1;
> +   als->uscale = 0;
> +   als->offset = 0;
> mutex_init(>lock);
>
> indio_dev->name = ACPI_ALS_DEVICE_NAME;
> --
> 2.1.0
>

Re: [PATCH net-next] hv_netvsc: fix a race between netvsc_send() and netvsc_init_buf()

[David Miller]

From: Vitaly Kuznetsov 
Date: Fri, 21 Oct 2016 13:15:53 +0200

> David Miller  writes:
> 
>> From: Vitaly Kuznetsov 
>> Date: Thu, 20 Oct 2016 10:51:04 +0200
>>
>>> Stephen Hemminger  writes:
>>> 
 Do we need ACCESS_ONCE() here to avoid check/use issues?

>>> 
>>> I think we don't: this is the only place in the function where we read
>>> the variable so we'll get normal read. We're not trying to syncronize
>>> with netvsc_init_buf() as that would require locking, if we read stale
>>> NULL value after it was already updated on a different CPU we're fine,
>>> we'll just return -EAGAIN.
>>
>> The concern is if we race with netvsc_destroy_buf() and this pointer
>> becomes NULL after the test you are adding.
> 
> Thanks, this is interesting.
> 
> We may reach to netvsc_destroy_buf() by 3 pathes:
> 
> 1) cleanup path in netvsc_init_buf(). It is never called with
> send_section_map being not NULL so it seems we're safe.
> 
> 2) from netvsc_remove() when the device is being removed. As far as I
> understand we can't be on the transmit path after we call
> unregister_netdev() so we're safe.
> 
> 3) from netvsc_change_mtu() and netvsc_set_channels(). These pathes are
> specific to netvsc driver as basically we need to remove the device and
> add it back to change mtu/number of channels. The underligning 'struct
> net_device' stays but the rest is being removed and added back. On both
> pathes we first call netvsc_close() which does netif_tx_disable() and as
> far as I understand (I may be wrong) this guarantees that we won't be in
> netvsc_send().
> 
> So *I think* that we can't ever free send_section_map while in
> netvsc_send() and we can't even get to netvsc_send() after it is freed
> but I may have missed something.

Ok you may be right.

Can't the device be taken down by asynchronous events as well?  For example
if the peer end of the interface in the other guest disappears.

[PATCH] gpio: mcp23s08: Add option to configure pullups.

[Enric Balletbo i Serra]

Default is without pullups, but if property is specified in DT and the bit
is set, set a pullup on GPIO-n.

Signed-off-by: Enric Balletbo i Serra 
---
 Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt | 1 +
 drivers/gpio/gpio-mcp23s08.c | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt 
b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
index c934106..40306b1 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
@@ -57,6 +57,7 @@ Optional device specific properties:
 On devices with only one interrupt output this property is useless.
 - microchip,irq-active-high: Sets the INTPOL flag in the IOCON register. This
 configures the IRQ output polarity as active high.
+- microchip,pullups : If n-th bit is set, set a pullup on GPIO-n.
 
 Example I2C (with interrupt):
 gpiom1: gpio@20 {
diff --git a/drivers/gpio/gpio-mcp23s08.c b/drivers/gpio/gpio-mcp23s08.c
index 99d37b5..0cedf82 100644
--- a/drivers/gpio/gpio-mcp23s08.c
+++ b/drivers/gpio/gpio-mcp23s08.c
@@ -766,7 +766,8 @@ static int mcp230xx_probe(struct i2c_client *client,
if (match) {
pdata = _pdata;
pdata->base = -1;
-   pdata->chip[0].pullups = 0;
+   of_property_read_u32(client->dev.of_node, "microchip,pullups",
+>chip[0].pullups);
pdata->irq_controller = of_property_read_bool(
client->dev.of_node,
"interrupt-controller");
-- 
2.1.0

Re: 4.9 regression/bisection - 761ed4a94582 tty: serial_core: convert uart_close to use tty_port_close

[Rob Herring]

On Fri, Oct 21, 2016 at 9:40 AM, Mike Galbraith
 wrote:
> On Fri, 2016-10-21 at 08:51 -0500, Rob Herring wrote:
>> On Fri, Oct 21, 2016 at 7:45 AM, Mike Galbraith
>>  wrote:
>> > Greetings,
>> >
>> > My old DL980 G7 is exploding on reboot with master, with only the first
>> > couple lines actually making it to the console.  Once (and only once)
>> > during bisection it did manage to get the below emitted.
>>
>> Does this patch[1] fix things for you? Sorry, only the reply seems to
>> be in the archives.
>
> Nope, still went boom.

Can you try just removing the "port->console = uart_console(uport);"
line completely?

Rob

Re: [PATCH] shmem: avoid huge pages for small files

[Kirill A. Shutemov]

On Fri, Oct 21, 2016 at 04:01:18PM +1100, Dave Chinner wrote:
> On Thu, Oct 20, 2016 at 07:01:16PM -0700, Andi Kleen wrote:
> > > Ugh, no, please don't use mount options for file specific behaviours
> > > in filesystems like ext4 and XFS. This is exactly the sort of
> > > behaviour that should either just work automatically (i.e. be
> > > completely controlled by the filesystem) or only be applied to files
> > 
> > Can you explain what you mean? How would the file system control it?
> 
> There's no point in asking for huge pages when populating the page
> cache if the file is:
> 
>   - significantly smaller than the huge page size
>   - largely sparse
>   - being randomly accessed in small chunks
>   - badly fragmented and so takes hundreds of IO to read/write
> a huge page
>   - able to optimise delayed allocation to match huge page
> sizes and alignments
> 
> These are all constraints the filesystem knows about, but the
> application and user don't.

Really?

To me, most of things you're talking about is highly dependent on access
pattern generated by userspace:

  - we may want to allocate huge pages from byte 1 if we know that file
will grow;
  - the same for sparse file that will be filled;
  - it will be beneficial to allocate huge page even for fragmented files,
if it's read-mostly;

> None of these aspects can be optimised sanely by a single threshold,
> especially when considering the combination of access patterns vs file
> layout.

I agree.

Here I tried to address the particular performance regression I see with
huge pages enabled on tmpfs. It doesn't mean to fix all possible issues.

> Further, we are moving the IO path to a model where we use extents
> for mapping, not blocks.  We're optimising for the fact that modern
> filesystems use extents and so massively reduce the number of block
> mapping lookup calls we need to do for a given IO.
> 
> i.e. instead of doing "get page, map block to page" over and over
> again until we've alked over the entire IO range, we're doing
> "map extent for entire IO range" once, then iterating "get page"
> until we've mapped the entire range.

That's great, but it's not how IO path works *now*. And will takes a long
time (if ever) to flip it over to what you've described.

> Hence if we have a 2MB IO come in from userspace, and the iomap
> returned is a covers that entire range, it's a no-brainer to ask the
> page cache for a huge page instead of iterating 512 times to map all
> the 4k pages needed.

Yeah, it's no-brainier.

But do we want to limit huge page allocation only to such best-possible
cases? I hardly ever seen 2MB IOs in real world...

And this approach will put too much decision power on the first access to
the file range. It may or may not represent future access pattern.

> > > specifically configured with persistent hints to reliably allocate
> > > extents in a way that can be easily mapped to huge pages.
> > 
> > > e.g. on XFS you will need to apply extent size hints to get large
> > > page sized/aligned extent allocation to occur, and so this
> > 
> > It sounds like you're confusing alignment in memory with alignment
> > on disk here? I don't see why on disk alignment would be needed
> > at all, unless we're talking about DAX here (which is out of 
> > scope currently) Kirill's changes are all about making the memory
> > access for cached data more efficient, it's not about disk layout
> > optimizations.
> 
> No, I'm not confusing this with DAX. However, this automatic use
> model for huge pages fits straight into DAX as well.  Same
> mechanisms, same behaviours, slightly stricter alignment
> characteristics. All stuff the filesystem already knows about.
> 
> Mount options are, quite frankly, a terrible mechanism for
> specifying filesystem policy. Setting up DAX this way was a mistake,
> and it's a mount option I plan to remove from XFS once we get nearer
> to having DAX feature complete and stablised. We've already got
> on-disk "use DAX for this file" flags in XFS, so we can easier and
> cleanly support different methods of accessing PMEM from the same
> filesystem.
> 
> As such, there is no way we should be considering different
> interfaces and methods for configuring the /same functionality/ just
> because DAX is enabled or not. It's the /same decision/ that needs
> to be made, and the filesystem knows an awful lot more about whether
> huge pages can be used efficiently at the time of access than just
> about any other actor you can name

I'm not convinced that filesystem is in better position to see access
patterns than mm for page cache. It's not all about on-disk layout.

-- 
 Kirill A. Shutemov

[PATCH] PM / Suspend: Fix missing KERN_CONT for suspend message

[Jon Hunter]

Commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") exposed a missing KERN_CONT from one of the
messages shown on entering suspend. With v4.9-rc1, the 'done.' shown
after syncing the filesystems no longer appears as a continuation but
a new message with its own timestamp.

[9.259566] PM: Syncing filesystems ... [9.264119] done.

Fix this by adding the KERN_CONT log level for the 'done.' part of the
message seen after syncing filesystems. While we are at it, convert
these suspend printks to pr_info and pr_cont, respectively.

Signed-off-by: Jon Hunter 
---
 kernel/power/suspend.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 1e7f5da648d9..6ccb08f57fcb 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -498,9 +498,9 @@ static int enter_state(suspend_state_t state)
 
 #ifndef CONFIG_SUSPEND_SKIP_SYNC
trace_suspend_resume(TPS("sync_filesystems"), 0, true);
-   printk(KERN_INFO "PM: Syncing filesystems ... ");
+   pr_info("PM: Syncing filesystems ... ");
sys_sync();
-   printk("done.\n");
+   pr_cont("done.\n");
trace_suspend_resume(TPS("sync_filesystems"), 0, false);
 #endif
 
-- 
1.9.1

Re: 4.9 regression/bisection - 761ed4a94582 tty: serial_core: convert uart_close to use tty_port_close

[Mike Galbraith]

On Fri, 2016-10-21 at 10:00 -0500, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 9:40 AM, Mike Galbraith
>  wrote:
> > On Fri, 2016-10-21 at 08:51 -0500, Rob Herring wrote:
> > > On Fri, Oct 21, 2016 at 7:45 AM, Mike Galbraith
> > >  wrote:
> > > > Greetings,
> > > > 
> > > > My old DL980 G7 is exploding on reboot with master, with only the first
> > > > couple lines actually making it to the console.  Once (and only once)
> > > > during bisection it did manage to get the below emitted.
> > > 
> > > Does this patch[1] fix things for you? Sorry, only the reply seems to
> > > be in the archives.
> > 
> > Nope, still went boom.
> 
> Can you try just removing the "port->console = uart_console(uport);"
> line completely?

That worked.

-Mike

[PATCH v5 1/2] timers: Fix usleep_range() in the context of wake_up_process()

[Douglas Anderson]

Users of usleep_range() expect that it will _never_ return in less time
than the minimum passed parameter.  However, nothing in any of the code
ensures this.  Specifically:

usleep_range() => do_usleep_range() => schedule_hrtimeout_range() =>
schedule_hrtimeout_range_clock() just ends up calling schedule() with an
appropriate timeout set using the hrtimer.  If someone else happens to
wake up our task then we'll happily return from usleep_range() early.

msleep() already has code to handle this case since it will loop as long
as there was still time left.  usleep_range() had no such loop.

The problem is is easily demonstrated with a small bit of test code:

  static int usleep_test_task(void *data)
  {
atomic_t *done = data;
ktime_t start, end;

start = ktime_get();
usleep_range(5, 10);
end = ktime_get();
pr_info("Requested 5 - 10 us.  Actually slept for %llu us\n",
  (unsigned long long)ktime_to_us(ktime_sub(end, start)));
atomic_set(done, 1);

return 0;
  }

  static void run_usleep_test(void)
  {
struct task_struct *t;
atomic_t done;

atomic_set(, 0);

t = kthread_run(usleep_test_task, , "usleep_test_task");
while (!atomic_read()) {
  wake_up_process(t);
  udelay(1000);
}
kthread_stop(t);
  }

If you run the above code without this patch you get things like:
  Requested 5 - 10 us.  Actually slept for 967 us

If you run the above code _with_ this patch, you get:
  Requested 5 - 10 us.  Actually slept for 98896 us

Presumably this problem was not detected before because:
- It's not terribly common to use wake_up_process() directly.
- Other ways for processes to wake up are not typically mixed with
  usleep_range().
- There aren't lots of places that use usleep_range(), since many people
  call either msleep() or udelay().

NOTES:
- An effort was made to look for users relying on the old behavior by
  looking for usleep_range() in the same file as wake_up_process().
  No problems was found by this search, though it is conceivable that
  someone could have put the sleep and wakeup in two different files.
- An effort was made to ask several upstream maintainers if they were
  aware of people relying on wake_up_process() to wake up
  usleep_range().  No maintainers were aware of that but they were aware
  of many people relying on usleep_range() never returning before the
  minimum.

Reported-by: Tao Huang 
Signed-off-by: Douglas Anderson 
---
Changes in v5:
- Don't accidentally busy wait after first wakeup (Thomas Gleixner)
- Removed Reviewed-by tags

Changes in v4: None
Changes in v3:
- Add Reviewed-by tags
- Add notes about validation

Changes in v2:
- Fixed stupid bug that snuck in before posting
- Use ktime_before
- Remove delta from the loop

 kernel/time/timer.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 32bf6f75a8fe..ab65e7bcc2c2 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1896,16 +1896,6 @@ unsigned long msleep_interruptible(unsigned int msecs)
 
 EXPORT_SYMBOL(msleep_interruptible);
 
-static void __sched do_usleep_range(unsigned long min, unsigned long max)
-{
-   ktime_t kmin;
-   u64 delta;
-
-   kmin = ktime_set(0, min * NSEC_PER_USEC);
-   delta = (u64)(max - min) * NSEC_PER_USEC;
-   schedule_hrtimeout_range(, delta, HRTIMER_MODE_REL);
-}
-
 /**
  * usleep_range - Sleep for an approximate time
  * @min: Minimum time in usecs to sleep
@@ -1919,7 +1909,15 @@ static void __sched do_usleep_range(unsigned long min, 
unsigned long max)
  */
 void __sched usleep_range(unsigned long min, unsigned long max)
 {
-   __set_current_state(TASK_UNINTERRUPTIBLE);
-   do_usleep_range(min, max);
+   ktime_t expires = ktime_add_us(ktime_get(), min);
+   u64 delta = (u64)(max - min) * NSEC_PER_USEC;
+
+   for (;;) {
+   __set_current_state(TASK_UNINTERRUPTIBLE);
+   /* Do not return before the requested sleep time has elapsed */
+   if (!schedule_hrtimeout_range(, delta,
+ HRTIMER_MODE_ABS))
+   break;
+   }
 }
 EXPORT_SYMBOL(usleep_range);
-- 
2.8.0.rc3.226.g39d4020

[PATCH 4/5] irqchip: st: remove STiH415/416 irqchip support

[patrice.chotard]

From: Patrice Chotard 

Support for STiH415/6 SoCs is being removed from the
kernel because the platforms are obsolete. This patch removes
the irqchip for these SoC's.

Signed-off-by: Patrice Chotard 
Cc: 
Cc: 
Cc: 
---
 drivers/irqchip/irq-st.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/irqchip/irq-st.c b/drivers/irqchip/irq-st.c
index 9af48a8..3ac9226 100644
--- a/drivers/irqchip/irq-st.c
+++ b/drivers/irqchip/irq-st.c
@@ -18,8 +18,6 @@
 #include 
 #include 
 
-#define STIH415_SYSCFG_642 0x0a8
-#define STIH416_SYSCFG_75430x87c
 #define STIH407_SYSCFG_51020x198
 #define STID127_SYSCFG_734 0x088
 
@@ -48,14 +46,6 @@ struct st_irq_syscfg {
 
 static const struct of_device_id st_irq_syscfg_match[] = {
{
-   .compatible = "st,stih415-irq-syscfg",
-   .data = (void *)STIH415_SYSCFG_642,
-   },
-   {
-   .compatible = "st,stih416-irq-syscfg",
-   .data = (void *)STIH416_SYSCFG_7543,
-   },
-   {
.compatible = "st,stih407-irq-syscfg",
.data = (void *)STIH407_SYSCFG_5102,
},
-- 
1.9.1

Re: [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection

[Andrew Lunn]

Hi Neil

> Yes this would be a good idea if we were able to scan the internal
> and external PHYs at the same time, but with our limited knowledge
> the values we write in the register seems to switch a mux for the
> whole RMII and MDIO signals to either interface.

Ah, O.K. So you need something like:

drivers/net/phy/mdio-mux-mmioreg.c

This seems to be limited to a single byte for the mux register, so you
might need to make some extensions.

  Andrew

Re: [PATCH V3 2/2] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

[Lorenzo Pieralisi]

On Fri, Oct 21, 2016 at 02:12:44PM +0800, Dongdong Liu wrote:

[...]

> >>+static int hisi_pcie_init(struct pci_config_window *cfg)
> >>+{
> >>+   int ret;
> >>+   struct acpi_device *adev = to_acpi_device(cfg->parent);
> >
> >Why is this expected to be struct acpi_device?
> 
> I use this acpi device(Device (PCI2)) to get it's child acpi device(Device 
> (RES2)), then
> obtain rc base addresses from PNP0C02 as subdevice of PNP0A03.
> 
> The procedure to get the value of cfg->parent is as the below.
> arch/arm64/kernel/pci.c
> pci_acpi_scan_root(struct acpi_pci_root *root)
>   --->pci_acpi_setup_ecam_mapping(root, ri);
>   --->pci_ecam_create(>device->dev, , bus_res, 
> ecam_ops);
>   --->cfg->parent = dev
> ;
> PCIe DSDT table defines as below.
> Device (PCI2)
> {
>   Name (_HID, "PNP0A08") // PCI Express Root Bridge
>   Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
>   ..
>   Device (RES2)
>   {
>   Name (_HID, "HISI0081") // HiSi PCIe RC config base address
>   Name (_CID, "PNP0C02") // Motherboard reserved resource
>   Name (_CRS, ResourceTemplate (){
>   Memory32Fixed (ReadWrite, 0xa00a , 0x1)
>   })
>   ..
> }
> >
> >Shouldn't it be a "physical" device whose companion is an ACPI device object?
> 
> Sorry, I don't understand.  What do you mean ?

I think Rafael meant the physical node (that in this case is the pci
bridge device) that is associated with the acpi device (the struct
pci_config_window.parent pointer points at the PNP0A03/PNP0A08 acpi
device object though, not the RES2 acpi device that's what you need).

Have a look at:

Documentation/acpi/enumeration.txt
Documentation/acpi/namespace.txt

> It should be a "physical" device. but I have not saw about
> ACPI_COMPANION_SET() of this device.

The PNP0A08 acpi_device (that is what is pointed at by
struct acpi_device = to_acpi_device(pci_config_window.parent)
is the respective pci bridge device companion.

arch/arm64/kernel/pci.c (pcibios_root_bridge_prepare()).

Now for something completely different :), your RES2 pseudo-device.

IIUC platform device (physical node) is created by the ACPI enumeration
code for your RES2 pseudo-device and its resources are already
initialized (by parsing its _CRS) in acpi_create_platform_device().

This means that by the time you match the PNP0A03/PNP0A08 child with an
acpi_device with _HID == "HISI0081", you can get its associated
physical node and get its resources IOMEM through the physical
node (ie platform device and related resources) instead of re-parsing
the _CRS if I am not mistaken (and that's an IF because I did not
test it).

Regardless, I am not entirely sure there are kernel drivers/control
paths already using this mechanism to handle child devices (keeping in
mind that RES2 is not a real device at all, it is there to represent
PNP0A03 sub-address space for PCI quirks), so it would be good to get
Rafael's agreement on this approach to prevent abusing the current ACPI
platform devices glue code assumptions.

It would also be good to agree on the whole approach soundness.

Thanks,
Lorenzo

[PATCH 1/5] thermal: st_thermal_syscfg: Remove obsolete STiH415/416 platform support.

[patrice.chotard]

From: Patrice Chotard 

STiH415/6 SoC support is being removed from the kernel.
This patch removes support from the syscfg thermal driver.

This driver also supports STiD127 SoC which has never been
upstreamed.

Signed-off-by: Patrice Chotard 
Cc: 
Cc: 
---
 drivers/thermal/st/Kconfig |   4 -
 drivers/thermal/st/Makefile|   1 -
 drivers/thermal/st/st_thermal_syscfg.c | 178 -
 3 files changed, 183 deletions(-)
 delete mode 100644 drivers/thermal/st/st_thermal_syscfg.c

diff --git a/drivers/thermal/st/Kconfig b/drivers/thermal/st/Kconfig
index 490fdbe..ce84267 100644
--- a/drivers/thermal/st/Kconfig
+++ b/drivers/thermal/st/Kconfig
@@ -3,10 +3,6 @@ config ST_THERMAL
help
  Support for thermal sensors on STMicroelectronics STi series of SoCs.
 
-config ST_THERMAL_SYSCFG
-   select ST_THERMAL
-   tristate "STi series syscfg register access based thermal sensors"
-
 config ST_THERMAL_MEMMAP
select ST_THERMAL
tristate "STi series memory mapped access based thermal sensors"
diff --git a/drivers/thermal/st/Makefile b/drivers/thermal/st/Makefile
index b388789..27197e1 100644
--- a/drivers/thermal/st/Makefile
+++ b/drivers/thermal/st/Makefile
@@ -1,3 +1,2 @@
 obj-$(CONFIG_ST_THERMAL)   := st_thermal.o
-obj-$(CONFIG_ST_THERMAL_SYSCFG)+= st_thermal_syscfg.o
 obj-$(CONFIG_ST_THERMAL_MEMMAP)+= st_thermal_memmap.o
diff --git a/drivers/thermal/st/st_thermal_syscfg.c 
b/drivers/thermal/st/st_thermal_syscfg.c
deleted file mode 100644
index 3df5b789..000
--- a/drivers/thermal/st/st_thermal_syscfg.c
+++ /dev/null
@@ -1,178 +0,0 @@
-/*
- * ST Thermal Sensor Driver for syscfg based sensors.
- * Author: Ajit Pal Singh 
- *
- * Copyright (C) 2003-2014 STMicroelectronics (R) Limited
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include 
-#include 
-#include 
-
-#include "st_thermal.h"
-
-/* STiH415 */
-#define STIH415_SYSCFG_FRONT(num)  ((num - 100) * 4)
-#define STIH415_SAS_THSENS_CONF
STIH415_SYSCFG_FRONT(178)
-#define STIH415_SAS_THSENS_STATUS  STIH415_SYSCFG_FRONT(198)
-#define STIH415_SYSCFG_MPE(num)((num - 600) * 4)
-#define STIH415_MPE_THSENS_CONFSTIH415_SYSCFG_MPE(607)
-#define STIH415_MPE_THSENS_STATUS  STIH415_SYSCFG_MPE(667)
-
-/* STiH416 */
-#define STIH416_SYSCFG_FRONT(num)  ((num - 1000) * 4)
-#define STIH416_SAS_THSENS_CONF
STIH416_SYSCFG_FRONT(1552)
-#define STIH416_SAS_THSENS_STATUS1 STIH416_SYSCFG_FRONT(1554)
-#define STIH416_SAS_THSENS_STATUS2 STIH416_SYSCFG_FRONT(1594)
-
-/* STiD127 */
-#define STID127_SYSCFG_CPU(num)((num - 700) * 4)
-#define STID127_THSENS_CONFSTID127_SYSCFG_CPU(743)
-#define STID127_THSENS_STATUS  STID127_SYSCFG_CPU(767)
-
-static const struct reg_field st_415sas_regfields[MAX_REGFIELDS] = {
-   [TEMP_PWR] = REG_FIELD(STIH415_SAS_THSENS_CONF,   9,  9),
-   [DCORRECT] = REG_FIELD(STIH415_SAS_THSENS_CONF,   4,  8),
-   [OVERFLOW] = REG_FIELD(STIH415_SAS_THSENS_STATUS, 8,  8),
-   [DATA] = REG_FIELD(STIH415_SAS_THSENS_STATUS, 10, 16),
-};
-
-static const struct reg_field st_415mpe_regfields[MAX_REGFIELDS] = {
-   [TEMP_PWR] = REG_FIELD(STIH415_MPE_THSENS_CONF,   8,  8),
-   [DCORRECT] = REG_FIELD(STIH415_MPE_THSENS_CONF,   3,  7),
-   [OVERFLOW] = REG_FIELD(STIH415_MPE_THSENS_STATUS, 9,  9),
-   [DATA] = REG_FIELD(STIH415_MPE_THSENS_STATUS, 11, 18),
-};
-
-static const struct reg_field st_416sas_regfields[MAX_REGFIELDS] = {
-   [TEMP_PWR] = REG_FIELD(STIH416_SAS_THSENS_CONF,9,  9),
-   [DCORRECT] = REG_FIELD(STIH416_SAS_THSENS_CONF,4,  8),
-   [OVERFLOW] = REG_FIELD(STIH416_SAS_THSENS_STATUS1, 8,  8),
-   [DATA] = REG_FIELD(STIH416_SAS_THSENS_STATUS2, 10, 16),
-};
-
-static const struct reg_field st_127_regfields[MAX_REGFIELDS] = {
-   [TEMP_PWR] = REG_FIELD(STID127_THSENS_CONF,   7,  7),
-   [DCORRECT] = REG_FIELD(STID127_THSENS_CONF,   2,  6),
-   [OVERFLOW] = REG_FIELD(STID127_THSENS_STATUS, 9,  9),
-   [DATA] = REG_FIELD(STID127_THSENS_STATUS, 11, 18),
-};
-
-/* Private OPs for System Configuration Register based thermal sensors */
-static int st_syscfg_power_ctrl(struct st_thermal_sensor *sensor,
-   enum st_thermal_power_state power_state)
-{
-   return regmap_field_write(sensor->pwr, power_state);
-}
-
-static int st_syscfg_alloc_regfields(struct st_thermal_sensor *sensor)
-{

Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers

[Sebastian Reichel]

Hi,

On Thu, Oct 20, 2016 at 01:55:22PM -0400, Jarod Wilson wrote:
> hsi/clients/ssi_protocol:
> - use core MTU range checking
> - remove now redundant ssip_pn_set_mtu

Acked-By: Sebastian Reichel 

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] x86/AMD: Apply erratum 688 on machines without a BIOS fix

[Borislav Petkov]

Hi Ioannis,

first of all, when you reply to a mail on lkml, please use the "reply-to-all"
functionality of your mail client - otherwise replies might get missed on such a
high volume mailing list.

On Fri, Oct 21, 2016 at 07:19:07PM +0300, sonofa...@openmailbox.org wrote:
> Sorry for the late reply! This machine has caused nothing but trouble. HP
> will not fix it and we will not choose their laptops anymore...

You're not the only one making this experience.

> My brother told me that we apply a quirk to the last Ontario APUs that do
> not need it but I did not think it would be an issue since they have fixed
> the error.

No, you need to apply the fix only on the models which need it.

> It seems better this way so that only affected APUs are patched. Be patient,
> we are compiling the new patch right now but compiling is run on a different
> high end AMD machine of my brother. Tomorrow I will have access to the
> laptop and I will update the kernel and send you the V2 patch. Compiling to
> that laptop would possibly need a whole day even with AC power!

You can build somewhere else and copy the kernel to the laptop. That's
how I do it.

> Do you want /proc/cpuinfo on the V2 patch e-mail? Both CPUs needed?

No, I just wanted to see them and you've pasted them here. Thanks.

> Here is a dump from an older installation some months ago I kept on my
> disk(tomorrow I will dump it again if you want):

No need, one is enough :)

> > Then, keep that *whole* changelog above when sending v2 of the patch
> What do you mean? It is not clear to me, Do you mean all the info we wrote
> on the e-mail, your comments or both?

All the info you wrote in the first mail.

> We have many AMD machines and we will need your help next week to patch our
> Phenom(tm) II X6.

Why, what's wrong with that one? That one should be all fixed! :-)

I have such box too and it runs fine.

> Let's finish this patch first and we will fix that too but it appears
> to be much more difficult...

Don't hesitate to ask if you need help...

HTH.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

Re: PROBLEM: OHCI watchdog timeouts inside VirtualBox, probably due to timer wheel rework

[Alan Stern]

On Fri, 21 Oct 2016, Michael Thayer wrote:

> Hello Alan (LKML on CC),
> 
> Contacting you about this on Thomas Gleixner's (also on CC) suggestion. 
> The short summary is that when Linux 4.8.0 (also tested with a few later 
> kernels) is run on a VirtualBox virtual machine with USB enabled, OHCI 
> fails with the log messages "frame counter not updated; disabled" and 
> "HC died; cleaning up".  This seems to be due to the 250 ms interval 
> watchdog running with far too short intervals, which we think is a 
> consequence of the timer wheel code rework.  I will refer you to a bug 
> filed in Launchpad<1> for a longer description.
> 
> Hope this is of interest to you.
> 
> Regards,
> 
> Michael
> 
> <1> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1634737

That bug description says the watchdog timer routine can be called
twice in a 4-ms period, even though it requests a 250-ms delay.  Is
this really true?  If it is, it sounds like a real bug in the timer 
core.

Bryan Paluch reported a similar problem and said that increasing the
timeout value to 275 ms fixed it:

http://marc.info/?l=linux-usb=147670889009451=2

Does that patch also fix the "frame counter not updating" problem?

Alan Stern

Re: [3.8 Regression] backporting "[PATCH stable pre 3.9] mm, gup: close FOLL MAP_PRIVATE race"

[Brian Norris]

Hi Michal,

On Fri, Oct 21, 2016 at 08:46:02AM +0200, Michal Hocko wrote:
> On Thu 20-10-16 23:39:39, Brian Norris wrote:
> > I'm not sure the best way to report this, but the Chrome OS test
> > infrastructure noticed some problems when testing the following patch
> > backported to our 3.8 kernels:
> > 
> > http://www.spinics.net/lists/stable/msg147998.html
> > 
> > Specifically (if you can hold your nose and stand Gerrit), this change:
> > 
> > https://chromium-review.googlesource.com/#/c/401041/

To be clear to any other readers, the above link has been updated with a
new version. The version in question at the time of the original writing
(and Michal's response) is preserved at this URL:

https://chromium-review.googlesource.com/#/c/401041/2

> This is not correct. You have
> https://chromium-review.googlesource.com/#/c/401041/2/mm/memory.c
> 
> f ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, page, flags)) {
>   pte_unmap_unlock(ptep, ptl);
>   goto no_page;
>   }
> 
> so you do a double unlock. See how my patch does
> + if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, page, flags)) {
> + pte_unmap_unlock(ptep, ptl);
> + return NULL;
> + }

Wow, indeed we do have a double unlock. Sorry for not reading the
backport more closely :( But thanks a bunch for the tip -- obvious in
retrospect. Will give that a go.

Also, I could have inferred that if it was so simple to crash the
system, that there *had* to simply be something wrong with our patch,
not with the patch you had (presumably tested and) posted.

Sorry for the noise, and thanks again.

Brian

Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump

[David Miller]

From: Eric Dumazet 
Date: Fri, 21 Oct 2016 04:36:57 -0700

> I guess we'll need to not pull this patch in our kernels.

Eric, quite frankly, this whole "we won't pull this patch into Google
kernels" threat is getting _REALLY_ _OLD_.

If you have a valid technical argument as to why a change should or
should not be applied, make it.  But don't add all of this unnecessary
information, it's simply irrelevant to the technical discussion and
is just emotionally charged.

Thank you.

Re: [PATCH 02/26] fscrypto: Constify struct inode pointer

[Richard Weinberger]

Ted,

On 21.10.2016 16:57, Theodore Ts'o wrote:
> On Fri, Oct 21, 2016 at 02:48:17PM +0200, Richard Weinberger wrote:
>> Some filesystems, such as UBIFS, maintain a const pointer
>> for struct inode.
>>
>>  /* fname.c */
>> -extern int fscrypt_setup_filename(struct inode *, const struct qstr *,
>> -int lookup, struct fscrypt_name *);
>> +extern int fscrypt_setup_filename(struct inode *dir, const struct qstr 
>> *iname,
>> +   int lookup, struct fscrypt_name *fname);
> 
> Was it deliberate that you didn't add a const pointer here?

Erm, no. Either I forgot or while rebasing my mess to something
sane the change got lost.

> I take it that ubifs is basically using const in certain places to
> essentially promise that those functions don't actually modify the
> inode structure?

Yes.

Thanks,
//richard

[PATCH 0/3] ARM: dts: oxnas: Update support for OX820 and use dt-bindings

[Neil Armstrong]

This patchset updates the ARM DTS for the Oxnas platform by :
- Add support for the Oxford Semicondutor OX820 and the PogoPlug V3
- Update the OX810SE to use the dt-bindings includes files introduced in [1] 
and [2]
- Fix the MAINTAINERS entry and add the PogoPlug V3 file maintainance

This patchset depends on dt-bindings include headers posted at [1] and [2],
that were accepted/merged in the subsystem trees.

How could I manage this dependency for 4.10 ?

[1] 
https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg8.html
[2] 
https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg7.html

Neil Armstrong (3):
  ARM: dts: Add support for OX820 and Pogoplug V3
  ARM: dts: OX810: Update with dt-bindings includes
  MAINTAINERS: oxnas: Add new files definitions

 Documentation/devicetree/bindings/arm/oxnas.txt|   5 +
 MAINTAINERS|   3 +-
 arch/arm/boot/dts/Makefile |   3 +-
 .../boot/dts/cloudengines-pogoplug-series-3.dts|  94 +++
 arch/arm/boot/dts/ox810se.dtsi |  10 +-
 arch/arm/boot/dts/ox820.dtsi   | 298 +
 6 files changed, 407 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
 create mode 100644 arch/arm/boot/dts/ox820.dtsi

-- 
2.7.0

[PATCH 3/3] MAINTAINERS: oxnas: Add new files definitions

[Neil Armstrong]

Fix the dts files maintained by the OXNAS platform, add a new board.

Signed-off-by: Neil Armstrong 
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..29d8853 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1478,8 +1478,9 @@ L:linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
 L: linux-ox...@lists.tuxfamily.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-oxnas/
-F: arch/arm/boot/dts/oxnas*
+F: arch/arm/boot/dts/ox8*.dtsi
 F: arch/arm/boot/dts/wd-mbwe.dts
+F: arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
 N: oxnas
 
 ARM/Mediatek RTC DRIVER
-- 
2.7.0

Re: [PATCH] cpufreq: intel_pstate: Set P-state upfront in performance mode

[Srinivas Pandruvada]

On Wed, 2016-10-19 at 02:57 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> After commit a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with
> utilization update callbacks) the cpufreq governor callbacks may not
> be invoked on NOHZ_FULL CPUs and, in particular, switching to the
> "performance" policy via sysfs may not have any effect on them.  That
> is a problem, because it usually is desirable to squeeze the last
> bit of performance out of those CPUs, so work around it by setting
> the maximum P-state (within the limits) in intel_pstate_set_policy()
> upfront when the policy is CPUFREQ_POLICY_PERFORMANCE.
> 
> Fixes: a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with
> utilization update callbacks)
> Signed-off-by: Rafael J. Wysocki 
Acked-by: Srinivas Pandruvada 

> ---
>  drivers/cpufreq/intel_pstate.c |   29 +
>  1 file changed, 25 insertions(+), 4 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -1137,10 +1137,8 @@ static void intel_pstate_get_min_max(str
>   *min = clamp_t(int, min_perf, cpu->pstate.min_pstate,
> max_perf);
>  }
>  
> -static void intel_pstate_set_min_pstate(struct cpudata *cpu)
> +static void intel_pstate_set_pstate(struct cpudata *cpu, int pstate)
>  {
> - int pstate = cpu->pstate.min_pstate;
> -
>   trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
>   cpu->pstate.current_pstate = pstate;
>   /*
> @@ -1152,6 +1150,20 @@ static void intel_pstate_set_min_pstate(
>     pstate_funcs.get_val(cpu, pstate));
>  }
>  
> +static void intel_pstate_set_min_pstate(struct cpudata *cpu)
> +{
> + intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate);
> +}
> +
> +static void intel_pstate_max_within_limits(struct cpudata *cpu)
> +{
> + int min_pstate, max_pstate;
> +
> + update_turbo_state();
> + intel_pstate_get_min_max(cpu, _pstate, _pstate);
> + intel_pstate_set_pstate(cpu, max_pstate);
> +}
> +
>  static void intel_pstate_get_cpu_pstates(struct cpudata *cpu)
>  {
>   cpu->pstate.min_pstate = pstate_funcs.get_min();
> @@ -1485,7 +1497,7 @@ static int intel_pstate_set_policy(struc
>   pr_debug("set_policy cpuinfo.max %u policy->max %u\n",
>    policy->cpuinfo.max_freq, policy->max);
>  
> - cpu = all_cpu_data[0];
> + cpu = all_cpu_data[policy->cpu];
>   if (cpu->pstate.max_pstate_physical > cpu->pstate.max_pstate 
> &&
>   policy->max < policy->cpuinfo.max_freq &&
>   policy->max > cpu->pstate.max_pstate * cpu-
> >pstate.scaling) {
> @@ -1529,6 +1541,15 @@ static int intel_pstate_set_policy(struc
>   limits->max_perf = round_up(limits->max_perf, FRAC_BITS);
>  
>   out:
> + if (policy->policy == CPUFREQ_POLICY_PERFORMANCE) {
> + /*
> +  * NOHZ_FULL CPUs need this as the governor callback
> may not
> +  * be invoked on them.
> +  */
> + intel_pstate_clear_update_util_hook(policy->cpu);
> + intel_pstate_max_within_limits(cpu);
> + }
> +
>   intel_pstate_set_update_util_hook(policy->cpu);
>  
>   intel_pstate_hwp_set_policy(policy);
> 

[PATCH 2/3] ARM: dts: OX810: Update with dt-bindings includes

[Neil Armstrong]

Add OX810SE dt-bindings includes files for clocks and resets, replace
resets numbers by human readable defines.

Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/ox810se.dtsi | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/ox810se.dtsi b/arch/arm/boot/dts/ox810se.dtsi
index ce13705..46aa6db 100644
--- a/arch/arm/boot/dts/ox810se.dtsi
+++ b/arch/arm/boot/dts/ox810se.dtsi
@@ -7,6 +7,8 @@
  */
 
 /include/ "skeleton.dtsi"
+#include 
+#include 
 
 / {
compatible = "oxsemi,ox810se";
@@ -242,7 +244,7 @@
   current-speed = <115200>;
   no-loopback-test;
   status = "disabled";
-  resets = < 17>;
+  resets = < RESET_UART1>;
};
 
uart1: serial@30 {
@@ -256,7 +258,7 @@
   current-speed = <115200>;
   no-loopback-test;
   status = "disabled";
-  resets = < 18>;
+  resets = < RESET_UART2>;
};
 
uart2: serial@90 {
@@ -270,7 +272,7 @@
   current-speed = <115200>;
   no-loopback-test;
   status = "disabled";
-  resets = < 22>;
+  resets = < RESET_UART3>;
};
 
uart3: serial@a0 {
@@ -284,7 +286,7 @@
   current-speed = <115200>;
   no-loopback-test;
   status = "disabled";
-  resets = < 23>;
+  resets = < RESET_UART4>;
};
};
 
-- 
2.7.0

Re: [PATCH] cpufreq: intel_pstate: Drop boost_iowait flag

[Srinivas Pandruvada]

On Wed, 2016-10-19 at 02:53 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The "IOwait boosting" mechanism is only used by the
> get_target_pstate_use_cpu_load() governor function and the
> boost_iowait flag in pid_params is always set when that function
> is in use (and it is never set otherwise).  This means that the
> boost_iowait flag is in fact redundant and may be dropped.
> 
> For this reason, replace the boost_iowait flag check in
> intel_pstate_update_util() with an equivalent check against
> pstate_funcs.get_target_pstate and drop that flag.
> 
> Signed-off-by: Rafael J. Wysocki 
Acked-by: Srinivas Pandruvada 

> ---
>  drivers/cpufreq/intel_pstate.c |7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -233,7 +233,6 @@ static struct cpudata **all_cpu_data;
>   * @p_gain_pct:  PID proportional gain
>   * @i_gain_pct:  PID integral gain
>   * @d_gain_pct:  PID derivative gain
> - * @boost_iowait:Whether or not to use iowait boosting.
>   *
>   * Stores per CPU model static PID configuration data.
>   */
> @@ -245,7 +244,6 @@ struct pstate_adjust_policy {
>   int p_gain_pct;
>   int d_gain_pct;
>   int i_gain_pct;
> - bool boost_iowait;
>  };
>  
>  /**
> @@ -1043,7 +1041,6 @@ static const struct cpu_defaults silverm
>   .p_gain_pct = 14,
>   .d_gain_pct = 0,
>   .i_gain_pct = 4,
> - .boost_iowait = true,
>   },
>   .funcs = {
>   .get_max = atom_get_max_pstate,
> @@ -1065,7 +1062,6 @@ static const struct cpu_defaults airmont
>   .p_gain_pct = 14,
>   .d_gain_pct = 0,
>   .i_gain_pct = 4,
> - .boost_iowait = true,
>   },
>   .funcs = {
>   .get_max = atom_get_max_pstate,
> @@ -1107,7 +1103,6 @@ static const struct cpu_defaults bxt_par
>   .p_gain_pct = 14,
>   .d_gain_pct = 0,
>   .i_gain_pct = 4,
> - .boost_iowait = true,
>   },
>   .funcs = {
>   .get_max = core_get_max_pstate,
> @@ -1346,7 +1341,7 @@ static void intel_pstate_update_util(str
>   struct cpudata *cpu = container_of(data, struct cpudata,
> update_util);
>   u64 delta_ns;
>  
> - if (pid_params.boost_iowait) {
> + if (pstate_funcs.get_target_pstate ==
> get_target_pstate_use_cpu_load) {
>   if (flags & SCHED_CPUFREQ_IOWAIT) {
>   cpu->iowait_boost = int_tofp(1);
>   } else if (cpu->iowait_boost) {
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [tpmdd-devel] [PATCH] tpm, tpm_crb: remove redundant CRB_FL_CRB_START flag

[Jarkko Sakkinen]

On Thu, Oct 20, 2016 at 02:24:21PM -0600, Jason Gunthorpe wrote:
> On Thu, Oct 20, 2016 at 05:00:11PM +0300, Jarkko Sakkinen wrote:
> 
> > > > I have a 4th Gen Core NUC where I experienced this issue. It reported
> > > > requiring only ACPI start but actually required ACPI + CRB start. The
> > > > comment could have been better.
> 
> Shouldn't bios work arounds be keyed on something? What happens if a
> system rolls around that cannot do ACPI + CRB start? How does this
> system work in windows?

I didn't find anything better to key it on at the time and it has been
working for two years now without any problems.

/Jarkko

Re: [PATCH/RFC 0/5] cpu_relax: introduce yield, remove lowlatency

[David Miller]

From: Christian Borntraeger 
Date: Fri, 21 Oct 2016 17:08:54 +0200

> On 10/21/2016 04:57 PM, David Miller wrote:
>> From: Christian Borntraeger 
>> Date: Fri, 21 Oct 2016 13:58:53 +0200
>> 
>>> For spinning loops people did often use barrier() or cpu_relax().
>>> For most architectures cpu_relax and barrier are the same, but on
>>> some architectures cpu_relax can add some latency. For example on s390
>>> cpu_relax gives up the time slice to the hypervisor. On power cpu_relax
>>> tries to give some of the CPU to the neighbor threads. To reduce the
>>> latency another variant cpu_relax_lowlatency was introduced. Before this
>>> is used in more and more places, lets revert the logic of provide a new
>>> function cpu_relax_yield that can spend some time and for s390 yields
>>> the guest CPU.
>> 
>> Sparc64, fwiw, behaves similarly to powerpc.
> 
> As sparc currently defines cpu_relax_lowlatency to cpu_relax, this patch set
> should be a no-op then for sparc, correct?
> 
> My intend was that cpu_relax should not add a huge latency but can certainly
> push some cpu power to hardware threads of the same core. This seems to be
> the case for sparc/power and some arc variants. 

Agreed.

Re: [PATCH v2 1/2] watchdog: Introduce arch_watchdog_nmi_enable and arch_watchdog_nmi_disable

[Don Zickus]

On Thu, Oct 20, 2016 at 08:25:27PM -0700, Andrew Morton wrote:
> On Thu, 20 Oct 2016 12:14:14 -0400 Don Zickus  wrote:
> 
> > > > -static int watchdog_nmi_enable(unsigned int cpu) { return 0; }
> > > > -static void watchdog_nmi_disable(unsigned int cpu) { return; }
> > > > +/*
> > > > + * These two functions are mostly architecture specific
> > > > + * defining them as weak here.
> > > > + */
> > > > +int __weak arch_watchdog_nmi_enable(unsigned int cpu) { return 0; }
> > > > +void __weak arch_watchdog_nmi_disable(unsigned int cpu) { return; }
> > > > +
> > > >  #endif /* CONFIG_HARDLOCKUP_DETECTOR */
> > > 
> > > This is a strange way of using __weak.
> > > 
> > > Take a look at (one of many examples) kernel/module.c:module_alloc(). 
> > > We simply provide a default implementation and some other compilation
> > > unit can override (actually replace) that at link time.  No strange
> > > ifdeffing needed.
> > 
> > Yeah, this is mostly because of how we enable the hardlockup detector.
> > 
> > Some arches use the perf hw and enable CONFIG_HARDLOCKUP_DETECTOR.  Other
> > arches just use their own variant of nmi and set CONFIG_HAVE_NMI_WATCHDOG 
> > and
> > the rest of the arches do not use this.
> > 
> > So the thought was if CONFIG_HARDLOCKUP_DETECTOR use that implementation,
> > everyone else use the __weak version.  Then the arches like sparc can 
> > override
> > the weak version with their own nmi enablement.
> > 
> > I don't know how to represent those 3 states correctly and the above is what
> > we end up with.
> 
> 
> 
> Is there a suitable site where we could capture these considerations in
> a code comment?

Hi Andrew,

I am not sure I understand your question.  When you say 'site', are you
referring to the kernel/watchdog.c file?

The other approach that might help de-clutter this file, is to pull out the
HARDLOCKUP_DETECTOR changes (as they are arch specific) and move it to say
kernel/watchdog_hw_ld.c.  Then all the nmi hooks in kernel/watchdog.c can be
__weak and overridden by the kernel_watchdog_hw_ld.c file or the sparc
files.

This would leave kernel/watchdog.c with just a framework and the
arch-agnostic softlockup detector.  Probably easier to read and digest.

Thoughts?

Cheers,
Don

[PATCH 12/12] ko_KR/HOWTO: Mark subsection in rst format

[SeongJae Park]

Subsections in HOWTO is not marked in rst format.  This commit specifies
them in rst format.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index a3f54c23f61d..1407c01277c0 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -259,7 +259,8 @@ Postscript 나 man page 로도 만들어질 수 있다::
   - 4.x - 통합 테스트를 위한 next 커널 트리
 
 4.x 커널 트리
--
+~
+
 4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org 의
 pub/linux/kernel/v4.x/ 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
 
@@ -292,7 +293,8 @@ Andrew Morton의 글이 있다.
  배포되는 것은 아니기 때문이다."*
 
 4.x.y - 안정 커널 트리
---
+~~
+
 3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 4.x
 커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을
 포함한다.
@@ -311,14 +313,16 @@ Andrew Morton의 글이 있다.
 진행되는지를 설명한다.
 
 4.x -git 패치들

+~~~
+
 git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의
 커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며
 Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도
 살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다.
 
 서브시스템 커널 트리들과 패치들

+~~~
+
 다양한 커널 서브시스템의 메인테이너들 --- 그리고 많은 커널 서브시스템 개발자들
 --- 은 그들의 현재 개발 상태를 소스 저장소로 노출한다. 이를 통해 다른 사람들도
 커널의 다른 영역에 어떤 변화가 이루어지고 있는지 알 수 있다. 급속히 개발이
-- 
2.10.0

[PATCH 03/12] ko_KR/HOWTO: Fix subtitles style

[SeongJae Park]

This commit fixes subtitles style.  It aligns them with their header,
adjust blank lines between them properly.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index f14ccada9465..0b13d0a78446 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -229,8 +229,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
   - 4.x - 통합 테스트를 위한 next 커널 트리
 
 4.x 커널 트리

-
+-
 4.x 커널들은 Linus Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v4.x/
 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
   - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
@@ -261,8 +260,7 @@ Andrew Morton의 글이 있다.
  배포되는 것은 아니기 때문이다."
 
 4.x.y - 안정 커널 트리
-
-
+--
 3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 4.x
 커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을
 포함한다.
@@ -280,9 +278,8 @@ Andrew Morton의 글이 있다.
 종류의 변경들이 -stable 트리로 들어왔는지와 배포 프로세스가 어떻게
 진행되는지를 설명한다.
 
-
 4.x -git 패치들
---
+---
 git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의
 커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며
 Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도
@@ -311,7 +308,7 @@ Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인
 http://patchwork.ozlabs.org/ 에 나열되어 있다.
 
 4.x - 통합 테스트를 위한 next 커널 트리
--
+---
 서브시스템 트리들의 변경사항들은 mainline 4.x 트리로 들어오기 전에 통합
 테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의
 매일 받아가는 특수한 테스트 저장소가 존재한다:
@@ -321,8 +318,10 @@ http://patchwork.ozlabs.org/ 에 나열되어 있다.
 가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 -next 커널에서 테스트를
 수행하는 것도 좋을 것이다.
 
+
 버그 보고
 -
+
 bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 곳이다.
 사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 권장한다.
 kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
@@ -405,7 +404,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
 
 
 커뮤니티와 협력하는 법
-
+--
 
 커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이
 받아들여질 패치를 제출하게 되면 그 패치의 기술적인 이점으로 검토될 것이다.
@@ -443,7 +442,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
 
 
 커널 커뮤니티와 기업 조직간의 차이점
--
+
 커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의
 문제를 피하기 위한 목록이 있다.
   여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 :
-- 
2.10.0

[PATCH 06/12] ko_KR/HOWTO: Add cross-references to other documents

[SeongJae Park]

This commit applies commit 609d99a3b72e ("Documentation/HOWTO: add
cross-references to other documents") to Korean translation.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 78dab436a926..a8991333790f 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -104,17 +104,17 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 빌드하기 위해 필요한 것을 설명한다. 커널에 입문하는 사람들은 여기서
 시작해야 한다.
 
-  Documentation/Changes
+  :ref:`Documentation/Changes `
 이 파일은 커널을 성공적으로 빌드하고 실행시키기 위해 필요한 다양한
 소프트웨어 패키지들의 최소 버젼을 나열한다.
 
-  Documentation/CodingStyle
+  :ref:`Documentation/CodingStyle `
 이 문서는 리눅스 커널 코딩 스타일과 그렇게 한 몇몇 이유를 설명한다.
 모든 새로운 코드는 이 문서에 가이드라인들을 따라야 한다. 대부분의
 메인테이너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이
 그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다.
 
-  Documentation/SubmittingPatches 와 Documentation/SubmittingDrivers
+  :ref:`Documentation/SubmittingPatches ` 와 
:ref:`Documentation/SubmittingDrivers `
 이 파일들은 성공적으로 패치를 만들고 보내는 법을 다음의 내용들로
 굉장히 상세히 설명하고 있다(그러나 다음으로 한정되진 않는다).
 
@@ -137,7 +137,7 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 
 http://linux.yyz.us/patch-format.html
 
-   Documentation/stable_api_nonsense.txt
+   :ref:`Documentation/stable_api_nonsense.txt `
 이 문서는 의도적으로 커널이 불변하는 API를 갖지 않도록 결정한
 이유를 설명하며 다음과 같은 것들을 포함한다.
 
@@ -149,12 +149,12 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 리눅스로 전향하는 사람들에게는 매우 중요하다.
 
 
-  Documentation/SecurityBugs
+  :ref:`Documentation/SecurityBugs `
 여러분들이 리눅스 커널의 보안 문제를 발견했다고 생각한다면 이 문서에
 나온 단계에 따라서 커널 개발자들에게 알리고 그 문제를 해결할 수 있도록
 도와 달라.
 
-  Documentation/ManagementStyle
+  :ref:`Documentation/ManagementStyle `
 이 문서는 리눅스 커널 메인테이너들이 그들의 방법론에 녹아 있는
 정신을 어떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는
 모든 사람들(또는 커널 개발에 작은 호기심이라도 있는 사람들)이
@@ -162,17 +162,17 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 독특한 행동에 관하여 흔히 있는 오해들과 혼란들을 해소하고 있기
 때문이다.
 
-  Documentation/stable_kernel_rules.txt
+  :ref:`Documentation/stable_kernel_rules.txt `
 이 문서는 안정적인 커널 배포가 이루어지는 규칙을 설명하고 있으며
 여러분들이 이러한 배포들 중 하나에 변경을 하길 원한다면
 무엇을 해야 하는지를 설명한다.
 
-  Documentation/kernel-docs.txt
+  :ref:`Documentation/kernel-docs.txt `
 커널 개발에 관계된 외부 문서의 리스트이다. 커널 내의 포함된 문서들
 중에 여러분이 찾고 싶은 문서를 발견하지 못할 경우 이 리스트를
 살펴보라.
 
-  Documentation/applying-patches.txt
+  :ref:`Documentation/applying-patches.txt `
 패치가 무엇이며 그것을 커널의 다른 개발 브랜치들에 어떻게
 적용하는지에 관하여 자세히 설명하고 있는 좋은 입문서이다.
 
-- 
2.10.0

[PATCH 05/12] ko_KR/HOWTO: Convert to ReST notation

[SeongJae Park]

This commit applies commit 022e04d6f555 ("Documentation/HOWTO: convert
to ReST notation") to Korean translation and fix a trivial ReST build
failure problem.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 58 +++
 1 file changed, 53 insertions(+), 5 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 4048297e48aa..78dab436a926 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -9,17 +9,20 @@ read for non English (read: korean) speakers and is not 
intended as
 a fork. So if you have any comments or updates for this file please
 try to update the original English file first.
 
-==
+--
+
 이 문서는
 Documentation/HOWTO
 의 한글 번역입니다.
 
 역자： 김민찬 
 감수： 이제이미 
-==
+
+--
+
 
 어떻게 리눅스 커널 개발을 하는가
--
+
 
 이 문서는 커널 개발에 있어 가장 중요한 문서이다. 이 문서는
 리눅스 커널 개발자가 되는 법과 리눅스 커널 개발 커뮤니티와 일하는
@@ -46,6 +49,7 @@ Documentation/HOWTO
 어셈블리(특정 아키텍쳐)는 잘 알아야 할 필요는 없다.
 다음의 참고서적들은 기본에 충실한 C 교육이나 수년간의 경험에 견주지는
 못하지만 적어도 참고 용도로는 좋을 것이다
+
  - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
  - "Practical C Programming" by Steve Oualline [O'Reilly]
  - "C:  A Reference Manual" by Harbison and Steele [Prentice Hall]
@@ -79,6 +83,7 @@ Documentation/HOWTO
 그들의 말에 의지해서는 안된다.
 
 GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
+
 http://www.gnu.org/licenses/gpl-faq.html
 
 
@@ -93,6 +98,7 @@ GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
 mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 
 다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다.
+
   README
 이 파일은 리눅스 커널에 관하여 간단한 배경 설명과 커널을 설정하고
 빌드하기 위해 필요한 것을 설명한다. 커널에 입문하는 사람들은 여기서
@@ -108,30 +114,37 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 메인테이너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이
 그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다.
 
-  Documentation/SubmittingPatches
-  Documentation/SubmittingDrivers
+  Documentation/SubmittingPatches 와 Documentation/SubmittingDrivers
 이 파일들은 성공적으로 패치를 만들고 보내는 법을 다음의 내용들로
 굉장히 상세히 설명하고 있다(그러나 다음으로 한정되진 않는다).
+
- Email 내용들
- Email 양식
- 그것을 누구에게 보낼지
+
 이러한 규칙들을 따르는 것이 성공(역자주: 패치가 받아들여 지는 것)을
 보장하진 않는다(왜냐하면 모든 패치들은 내용과 스타일에 관하여
 면밀히 검토되기 때문이다). 그러나 규칙을 따르지 않는다면 거의
 성공하지도 못할 것이다.
 
 올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다.
+
 "The Perfect Patch"
+
 http://www.ozlabs.org/~akpm/stuff/tpp.txt
+
 "Linux kernel patch submission format"
+
 http://linux.yyz.us/patch-format.html
 
Documentation/stable_api_nonsense.txt
 이 문서는 의도적으로 커널이 불변하는 API를 갖지 않도록 결정한
 이유를 설명하며 다음과 같은 것들을 포함한다.
+
- 서브시스템 shim-layer(호환성을 위해?)
- 운영체제들간의 드라이버 이식성
- 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것)
+
 이 문서는 리눅스 개발 철학을 이해하는데 필수적이며 다른 운영체제에서
 리눅스로 전향하는 사람들에게는 매우 중요하다.
 
@@ -168,10 +181,14 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 올바르게 처리하는 법에 관한 규칙을 포함하고 있다. 이 문서는
 Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, HTML,
 그리고 man 페이지들로 다음과 같이 실행하여 만들어 진다.
+
+::
+
  make pdfdocs
  make psdocs
  make htmldocs
  make mandocs
+
 각각의 명령을 메인 커널 소스 디렉토리로부터 실행한다.
 
 
@@ -180,7 +197,9 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 
 여러분이 리눅스 커널 개발에 관하여 아무것도 모른다면 Linux KernelNewbies
 프로젝트를 봐야 한다.
+
 http://kernelnewbies.org
+
 그곳은 거의 모든 종류의 기본적인 커널 개발 질문들(질문하기 전에 먼저
 아카이브를 찾아봐라. 과거에 이미 답변되었을 수도 있다)을 할 수 있는 도움이
 될만한 메일링 리스트가 있다. 또한 실시간으로 질문 할 수 있는 IRC 채널도
@@ -192,7 +211,9 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 
 여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수
 있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라.
+
http://kernelnewbies.org/KernelJanitors
+
 그곳은 시작하기에 훌륭한 장소이다. 그곳은 리눅스 커널 소스 트리내에
 간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이
 프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에
@@ -204,6 +225,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 올바른 포맷으로 포장하는데 도움이 필요하다면 그러한 문제를 돕기 위해
 만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며
 다음에서 참조할 수 있다.
+
  http://selenic.com/mailman/listinfo/kernel-mentors
 
 리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게
@@ -213,6 +235,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며
 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
 코드 저장소는 다음을 통하여 참조할 수 있다.
+
   http://lxr.free-electrons.com/
 
 
@@ -222,6 +245,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 리눅스 커널 개발 프로세스는 현재 몇몇 다른 메인 커널 "브랜치들"과
 서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인
 브랜치들은 다음과 같다.
+
   - main 4.x 커널 트리
   - 4.x.y - 안정된 커널 트리
   - 4.x -git 커널 패치들
@@ -232,6 +256,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 -
 4.x 커널들은 Linus Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v4.x/
 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
+
   - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
 메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
  

[PATCH 01/12] Documentation/HOWTO: Mark subsection in rst format

[SeongJae Park]

Subsections in HOWTO is not marked in rst format.  This commit specifies
them in rst format.

Signed-off-by: SeongJae Park 
---
 Documentation/HOWTO | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 5f042349f987..5cf6ea84a6f8 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -254,7 +254,8 @@ branches.  These different branches are:
   - the 4.x -next kernel tree for integration tests
 
 4.x kernel tree
--
+~~~
+
 4.x kernels are maintained by Linus Torvalds, and can be found on
 https://kernel.org in the pub/linux/kernel/v4.x/ directory.  Its development
 process is as follows:
@@ -289,7 +290,8 @@ mailing list about kernel releases:
preconceived timeline."*
 
 4.x.y -stable kernel tree
--
+~
+
 Kernels with 3-part versions are -stable kernels. They contain
 relatively small and critical fixes for security problems or significant
 regressions discovered in a given 4.x kernel.
@@ -312,7 +314,8 @@ documents what kinds of changes are acceptable for the 
-stable tree, and
 how the release process works.
 
 4.x -git patches
-
+
+
 These are daily snapshots of Linus' kernel tree which are managed in a
 git repository (hence the name.) These patches are usually released
 daily and represent the current state of Linus' tree.  They are more
@@ -320,7 +323,8 @@ experimental than -rc kernels since they are generated 
automatically
 without even a cursory glance to see if they are sane.
 
 Subsystem Specific kernel trees and patches

+~~~
+
 The maintainers of the various kernel subsystems --- and also many
 kernel subsystem developers --- expose their current state of
 development in source repositories.  That way, others can see what is
@@ -344,7 +348,8 @@ accepted, or rejected.  Most of these patchwork sites are 
listed at
 https://patchwork.kernel.org/.
 
 4.x -next kernel tree for integration tests

+~~~
+
 Before updates from subsystem trees are merged into the mainline 4.x
 tree, they need to be integration-tested.  For this purpose, a special
 testing repository exists into which virtually all subsystem trees are
-- 
2.10.0

[PATCH 11/12] ko_KR/HOWTO: Add whitespace between URL and text

[SeongJae Park]

Because few sentences has no whitespace between URL and text, document
fails to parse the URL from it.  This commit adds whitespace between
them to fix the problem.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 33d9f0fcd7ed..a3f54c23f61d 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -260,7 +260,7 @@ Postscript 나 man page 로도 만들어질 수 있다::
 
 4.x 커널 트리
 -
-4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org의
+4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org 의
 pub/linux/kernel/v4.x/ 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
 
   - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
@@ -377,8 +377,8 @@ https://bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그
 점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은
 다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다.
 
-이미 보고된 버그 리포트들을 가지고 작업하기 위해서 https://bugzilla.kernel.org를
-참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면
+이미 보고된 버그 리포트들을 가지고 작업하기 위해서 https://bugzilla.kernel.org
+를 참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면
 bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다)
 bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다)
 에 등록하면 된다.
-- 
2.10.0

[GIT PULL] PCI fixes for v4.9

[Bjorn Helgaas]

This includes:

  - Fix for a Layerscape driver issue that causes a use-before-set crash
  - Maintainer update for the Synopsis prototyping device driver

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
tags/pci-v4.9-fixes-1

for you to fetch changes up to 02a1b8f4167eac709d269341f7c3c340984c28a6:

  PCI: designware-plat: Update author email address (2016-10-21 09:54:46 -0500)


pci-v4.9-fixes-1


Joao Pinto (2):
  PCI: designware-plat: Change maintainer to Jose Abreu
  PCI: designware-plat: Update author email address

Marc Zyngier (1):
  PCI: layerscape: Fix drvdata usage before assignment

 MAINTAINERS | 2 +-
 drivers/pci/host/pci-layerscape.c   | 2 +-
 drivers/pci/host/pcie-designware-plat.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

[PATCH 09/12] ko_KR/HOWTO: Adjust external link references

[SeongJae Park]

This commit appplies commit f1eebe92c265 ("Documentation/HOWTO: adjust
external link references") to Korean translation.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 39 ++-
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 19a19c5baa72..9898e14c9cc3 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -84,7 +84,7 @@ Documentation/HOWTO
 
 GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
 
-http://www.gnu.org/licenses/gpl-faq.html
+https://www.gnu.org/licenses/gpl-faq.html
 
 
 문서
@@ -130,11 +130,9 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다.
 
 "The Perfect Patch"
-
-http://www.ozlabs.org/~akpm/stuff/tpp.txt
+https://www.ozlabs.org/~akpm/stuff/tpp.txt
 
 "Linux kernel patch submission format"
-
 http://linux.yyz.us/patch-format.html
 
:ref:`Documentation/stable_api_nonsense.txt `
@@ -212,7 +210,7 @@ Postscript 나 man page 로도 만들어질 수 있다:
 여러분이 리눅스 커널 개발에 관하여 아무것도 모른다면 Linux KernelNewbies
 프로젝트를 봐야 한다.
 
-http://kernelnewbies.org
+https://kernelnewbies.org
 
 그곳은 거의 모든 종류의 기본적인 커널 개발 질문들(질문하기 전에 먼저
 아카이브를 찾아봐라. 과거에 이미 답변되었을 수도 있다)을 할 수 있는 도움이
@@ -226,7 +224,7 @@ Postscript 나 man page 로도 만들어질 수 있다:
 여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수
 있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라.
 
-   http://kernelnewbies.org/KernelJanitors
+   https://kernelnewbies.org/KernelJanitors
 
 그곳은 시작하기에 훌륭한 장소이다. 그곳은 리눅스 커널 소스 트리내에
 간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이
@@ -240,7 +238,7 @@ Postscript 나 man page 로도 만들어질 수 있다:
 만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며
 다음에서 참조할 수 있다.
 
- http://selenic.com/mailman/listinfo/kernel-mentors
+ https://selenic.com/mailman/listinfo/kernel-mentors
 
 리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게
 동작하는지 이해하고 있어야 한다. 코드를 분석하기 위하여 특정한 툴의
@@ -268,14 +266,14 @@ Postscript 나 man page 로도 만들어질 수 있다:
 
 4.x 커널 트리
 -
-4.x 커널들은 Linus Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v4.x/
-디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
+4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org의
+pub/linux/kernel/v4.x/ 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
 
   - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
 메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
 몇 주 동안 -next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데
 선호되는 방법은  git(커널의 소스 관리 툴, 더 많은 정보들은
-http://git-scm.com/ 에서 참조할 수 있다)를 사용하는 것이지만 순수한
+https://git-scm.com/ 에서 참조할 수 있다)를 사용하는 것이지만 순수한
 패치파일의 형식으로 보내는 것도 무관하다.
   - 2주 후에 -rc1 커널이 배포되며 지금부터는 전체 커널의 안정성에 영향을
 미칠수 있는 새로운 기능들을 포함하지 않는 패치들만이 추가될 수 있다.
@@ -337,14 +335,14 @@ Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인
 
 대부분의 이러한 저장소는 git 트리지만, git이 아닌 SCM으로 관리되거나, quilt
 시리즈로 제공되는 패치들도 존재한다. 이러한 서브시스템 저장소들은 MAINTAINERS
-파일에 나열되어 있다. 대부분은 http://git.kernel.org 에서 볼 수 있다.
+파일에 나열되어 있다. 대부분은 https://git.kernel.org 에서 볼 수 있다.
 
 제안된 패치는 서브시스템 트리에 커밋되기 전에 메일링 리스트를 통해
 리뷰된다(아래의 관련 섹션을 참고하기 바란다). 일부 커널 서브시스템의 경우, 이
 리뷰 프로세스는 patchwork라는 도구를 통해 추적된다. patchwork은 등록된 패치와
 패치에 대한 코멘트, 패치의 버전을 볼 수 있는 웹 인터페이스를 제공하고,
 메인테이너는 패치를 리뷰 중, 리뷰 통과, 또는 반려됨으로 표시할 수 있다.
-대부분의 이러한 patchwork 사이트는 http://patchwork.kernel.org/ 또는
+대부분의 이러한 patchwork 사이트는 https://patchwork.kernel.org/ 또는
 http://patchwork.ozlabs.org/ 에 나열되어 있다.
 
 4.x - 통합 테스트를 위한 next 커널 트리
@@ -353,7 +351,7 @@ http://patchwork.ozlabs.org/ 에 나열되어 있다.
 테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의
 매일 받아가는 특수한 테스트 저장소가 존재한다:
 
-   http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
+   https://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
 
 이런 식으로, -next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤 변경이
 가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 -next 커널에서 테스트를
@@ -363,11 +361,11 @@ http://patchwork.ozlabs.org/ 에 나열되어 있다.
 버그 보고
 -
 
-bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 곳이다.
-사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 권장한다.
-kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
+https://bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는
+곳이다. 사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을
+권장한다.  kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
 
-http://bugzilla.kernel.org/page.cgi?id=faq.html
+https://bugzilla.kernel.org/page.cgi?id=faq.html
 
 메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그라고 생각되는
 것을 보고하는 방법에 관한 좋은 템플릿이며 문제를 추적하기 위해서 커널
@@ -385,13 +383,14 @@ kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
 점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은
 다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다.
 
-이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernel.org를
+이미 보고된 버그 리포트들을 가지고 작업하기 위해서 https://bugzilla.kernel.org를
 참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면
 bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다)
 bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다)
 에 등록하면 된다.
 
   https://lists.linux-foundation.org/mailman/listinfo/bugme-new
+
   https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
 
 
@@ -615,8 +614,6 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
 http://www.ozlabs.org/~akpm/stuff/tpp.txt
 
 
-
-
 이 모든 것을 하는 것은 매우 어려운 일이다. 

[PATCH 02/12] ko_KR/HOWTO: Fix a typo: s/Linux Torvalds/Linus Torvalds

[SeongJae Park]

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 9a3e65924d54..f14ccada9465 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -231,7 +231,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 4.x 커널 트리
 ---
 
-4.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v4.x/
+4.x 커널들은 Linus Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v4.x/
 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
   - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
 메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
-- 
2.10.0

[PATCH 04/12] ko_KR/HOWTO: Update obsolete link to bugzilla faq

[SeongJae Park]

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 0b13d0a78446..4048297e48aa 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -325,7 +325,7 @@ http://patchwork.ozlabs.org/ 에 나열되어 있다.
 bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 곳이다.
 사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 권장한다.
 kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
-http://test.kernel.org/bugzilla/faq.html
+http://bugzilla.kernel.org/page.cgi?id=faq.html
 
 메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그라고 생각되는
 것을 보고하는 방법에 관한 좋은 템플릿이며 문제를 추적하기 위해서 커널
-- 
2.10.0

[PATCH 10/12] ko_KR/HOWTO: Clean up bare :: lines

[SeongJae Park]

This commit applies commit 1b49ecf2f3be ("docs: Clean up bare :: lines")
to Korean translation.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 9898e14c9cc3..33d9f0fcd7ed 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -180,26 +180,20 @@ API에 대한 모든 설명, 그리고 락킹을 올바르게 처리하는 법
 있다.
 
 모든 그런 문서들은 커널 소스 디렉토리에서 다음 커맨드를 실행하는 것을 통해 PDF
-나 HTML 의 형태로 만들어질 수 있다.
-
-::
+나 HTML 의 형태로 만들어질 수 있다::
 
  make pdfdocs
  make htmldocs
 
 ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된다.  해당
-문서들은 다음의 커맨드를 사용하면 LaTeX 이나 ePub 로도 만들어질 수 있다:
-
-::
+문서들은 다음의 커맨드를 사용하면 LaTeX 이나 ePub 로도 만들어질 수 있다::
 
  make latexdocs
  make epubdocs
 
 현재, ReST 로의 변환이 진행중인, DocBook 으로 쓰인 문서들이 존재한다. 그런
 문서들은 Documentation/DocBook/ 디렉토리 안에 생성될 것이고 다음 커맨드를 통해
-Postscript 나 man page 로도 만들어질 수 있다:
-
-::
+Postscript 나 man page 로도 만들어질 수 있다::
 
  make psdocs
  make mandocs
-- 
2.10.0

Re: [PATCH v5 4/4] drm/fence: add out-fences support

[Brian Starkey]

Hi,

Sorry, I hit another couple of bugs that originated from my hastebin
patch - see below.

On Thu, Oct 20, 2016 at 12:50:05PM -0200, Gustavo Padovan wrote:

From: Gustavo Padovan 

Support DRM out-fences by creating a sync_file with a fence for each CRTC
that sets the OUT_FENCE_PTR property.

We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
the sync_file fd back to userspace.

The sync_file and fd are allocated/created before commit, but the
fd_install operation only happens after we know that commit succeed.

In case of error userspace should receive a fd number of -1.

v2: Comment by Rob Clark:
- Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.

   Comment by Daniel Vetter:
- Add clean up code for out_fences

v3: Comments by Daniel Vetter:
- create DRM_MODE_ATOMIC_EVENT_MASK
- userspace should fill out_fences_ptr with the crtc_ids for which
it wants fences back.

v4: Create OUT_FENCE_PTR properties and remove old approach.

Signed-off-by: Gustavo Padovan 
---
drivers/gpu/drm/drm_atomic.c | 116 ++-
drivers/gpu/drm/drm_crtc.c   |   8 +++
include/drm/drm_crtc.h   |  19 +++
3 files changed, 119 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b3284b2..07775fc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -490,6 +490,8 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
);
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == config->prop_out_fence_ptr) {
+   state->out_fence_ptr = u64_to_user_ptr(val);
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
@@ -532,6 +534,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->ctm) ? state->ctm->base.id : 0;
else if (property == config->gamma_lut_property)
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
+   else if (property == config->prop_out_fence_ptr)
+   *val = 0;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
@@ -1474,11 +1478,9 @@ EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
 */

static struct drm_pending_vblank_event *create_vblank_event(
-   struct drm_device *dev, struct drm_file *file_priv,
-   struct fence *fence, uint64_t user_data)
+   struct drm_device *dev, uint64_t user_data)
{
struct drm_pending_vblank_event *e = NULL;
-   int ret;

e = kzalloc(sizeof *e, GFP_KERNEL);
if (!e)
@@ -1488,17 +1490,6 @@ static struct drm_pending_vblank_event 
*create_vblank_event(
e->event.base.length = sizeof(e->event);
e->event.user_data = user_data;

-   if (file_priv) {
-   ret = drm_event_reserve_init(dev, file_priv, >base,
->event.base);
-   if (ret) {
-   kfree(e);
-   return NULL;
-   }
-   }
-
-   e->base.fence = fence;
-
return e;
}

@@ -1603,6 +1594,40 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_atomic_clean_old_fb);

+static int crtc_setup_out_fence(struct drm_crtc *crtc,
+   struct drm_crtc_state *crtc_state,
+   struct drm_out_fence_state *fence_state)
+{
+   struct fence *fence;
+
+   fence_state->fd = get_unused_fd_flags(O_CLOEXEC);
+   if (fence_state->fd < 0) {
+   return fence_state->fd;
+   }
+
+   fence_state->out_fence_ptr = crtc_state->out_fence_ptr;
+   crtc_state->out_fence_ptr = NULL;
+
+   if (put_user(fence_state->fd, fence_state->out_fence_ptr))
+   return -EFAULT;
+
+   fence = kzalloc(sizeof(*fence), GFP_KERNEL);
+   if (!fence)
+   return -ENOMEM;
+
+   fence_init(fence, _crtc_fence_ops, >fence_lock,
+  crtc->fence_context, ++crtc->fence_seqno);
+
+   fence_state->sync_file = sync_file_create(fence);
+   if(!fence_state->sync_file) {
+   fence_put(fence);
+   return -ENOMEM;
+   }
+
+   crtc_state->event->base.fence = fence_get(fence);
+   return 0;
+}
+
int drm_mode_atomic_ioctl(struct drm_device *dev,
  void *data, struct drm_file *file_priv)
{
@@ -1617,9 +1642,10 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
struct drm_plane *plane;
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
+   struct drm_out_fence_state *fence_state;
unsigned 

[PATCH] usb: xhci: Workaround for erratum-A010129

[Sriram Dash]

For the USB3.0 controller, USB 2.0 reset not driven while
port is in Resume state. So, do not program the USB 2.0 reset
(PORTSC[PR]=1) while in Resume state.

Signed-off-by: Rajat Srivastava 
Signed-off-by: Sriram Dash 
Signed-off-by: Rajesh Bhagat 
---
 drivers/usb/host/xhci-hub.c | 28 +++-
 drivers/usb/host/xhci.h |  1 +
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 730b9fd..3def0dd 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -878,7 +878,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 
wValue,
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
int max_ports;
unsigned long flags;
-   u32 temp, status;
+   u32 temp, status, tmp_status = 0;
int retval = 0;
__le32 __iomem **port_array;
int slot_id;
@@ -1098,6 +1098,32 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
u16 wValue,
spin_lock_irqsave(>lock, flags);
break;
case USB_PORT_FEAT_RESET:
+   /*
+* Erratum : A010129
+* Synopsys STAR 9000962562.
+* USB 2.0 Reset Not Driven While Port in Resume
+* While in USB 2.0 resume state (the PORTSC.PLS
+* register bit is set to 4'd15), if the xHCI driver
+* programs the PORTSC.PR register bit to 1, the
+* controller does not drive a USB 2.0 reset
+* and it does not generate a PORTSC.PRC=1 interrupt.
+* So, The xHCI driver should not program a USB
+* 2.0 reset (PORTSC.PR=1) while in resume
+* (PORTSC.PLS=4'd15).
+*/
+   if (xhci->quirks & XHCI_PORT_RST_ON_RESUME) {
+   tmp_status = readl(port_array[wIndex]);
+   spin_unlock_irqrestore(>lock, flags);
+   if (!DEV_SUPERSPEED(tmp_status)
+   && (tmp_status & PORT_PLS_MASK)
+   == XDEV_RESUME) {
+   xhci_err(xhci, "skip port reset\n");
+   spin_lock_irqsave(>lock, flags);
+   break;
+   }
+   spin_lock_irqsave(>lock, flags);
+   }
+
temp = (temp | PORT_RESET);
writel(temp, port_array[wIndex]);
 
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index b2c1dc5..c07e267 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1653,6 +1653,7 @@ struct xhci_hcd {
 #define XHCI_MTK_HOST  (1 << 21)
 #define XHCI_SSIC_PORT_UNUSED  (1 << 22)
 #define XHCI_NO_64BIT_SUPPORT  (1 << 23)
+#define XHCI_PORT_RST_ON_RESUME(1 << 24)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
-- 
2.1.0

Re: [PATCH 4.4 00/25] 4.4.27-stable review

[Shuah Khan]

On 10/21/2016 03:15 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.27 release.
> There are 25 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 Oct 23 09:13:58 UTC 2016.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.27-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

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

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com

Re: console issue since 3.6, console=ttyS1 hangs

[Nathan Zimmer]

It didn't seem to make a difference as far as output.
Did I miss a config option? or something else?

[0.00] Linux version 3.6.0 (root@r1i2n0) (gcc version 4.3.4 
[gcc-4_3-branch revision 152973] (SUSE Linux) ) #3 SMP Mon Oct 17 
20:43:34 EDT 2016
[0.00] Command line: 
root=/dev/disk/by-id/ata-WDC_WD5000BHTZ-04JCPV1_WD-WXA1E54KKR60-part2 
resume=/dev/disk/by-id/ata-WDC_WD5000BHTZ-04JCPV1_WD-WXA1E54KKR60-part1 
crashkernel=256M-:128M loglevel=8 pnp.debug=1

...
[2.076084] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[2.097001] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[2.097844] serial 00:04: unable to assign resources
[2.098303] serial: probe of 00:04 failed with error -16


On 10/20/2016 03:10 PM, Sean Young wrote:

On Wed, Oct 19, 2016 at 05:13:41PM -0500, Nathan Zimmer wrote:

On 10/19/2016 04:07 AM, Sean Young wrote:

So with 3.6.0:


[2.079980] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[2.100887] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[2.101715] serial 00:04: unable to assign resources
[2.102174] serial: probe of 00:04 failed with error -16

The pnp probe fails for some reason. I don't understand why.

With 3.7.0:


[2.062700] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[2.063250] serial 00:04: [io  0x02f8-0x02ff]
[2.063875] serial 00:04: [irq 12]
[2.064345] serial 00:04: [dma 18446744073709551615 disabled]
[2.065540] serial 00:04: activated
[2.086442] 00:04: ttyS1 at I/O 0x2f8 (irq = 12) is a 16550A

Now the pnp probe succeeds (with broken irq from pnp).

Can you please check if there is a wrong irq configured in the bios setup
or if there is a bios update available? I don't know why this worked in
the first place.

Apparently this is the latest bios available for these nodes.
Also in the bios setup screens I don't see anything for changing irq numbers
for serial console.
But this is a cluster so sometimes thing get hidden to keep everything
uniform as possible.

If you want to point me to the pnp probe code you would be suspicious of I
can try to debug and see what is going there.

That would be great, thanks. A good start would be to boot 3.6.0 with
"loglevel=7 pnp.debug=1" and hopefully that will show why the probe
used to fail.

Also, does the issue still exist with a more contemporary kernel?


Sean

Re: [PATCH v2] mailbox: PCC: Fix lockdep warning when request PCC channel

[Prakash, Prashanth]

Hi Hoan,

On 10/18/2016 1:00 AM, Hoan Tran wrote:
> This patch fixes the lockdep warning below
>
> [7.229767] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> [7.229776] [ cut here ]
> [7.229787] WARNING: CPU: 1 PID: 1 at 
> linux-next/kernel/locking/lockdep.c:2876 loc
> kdep_trace_alloc+0xe0/0xf0
> [7.229790] Modules linked in:
> [7.229793]
> [7.229798] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-11756-g86c5152 
> #46
> ...
> [7.229900] Call trace:
> [7.229903] Exception stack(0x8007da837890 to 0x8007da8379c0)
> [7.229906] 7880:   8007da834000 
> 0001
> [7.229909] 78a0: 8007da837a70 08a0 60c5 
> 003d
> [7.229912] 78c0: 9374bc6a7f3c7832 00381878 09db7ab8 
> 002f
> [7.229915] 78e0: 0811aabc 08be2548 8007da837990 
> 0811adf8
> [7.229918] 7900: 8007da834000 024080c0 00c0 
> 09021000
> [7.229921] 7920:   08c8f7c8 
> 8007da579810
> [7.229923] 7940: 002f 8007da858000  
> 0001
> [7.229926] 7960: 0001  0811a468 
> 0002
> [7.229929] 7980: 656c62617369645f 00038187 00ee 
> 8007da837850
> [7.229932] 79a0: 09db50c0 09db569d 0006 
> 89db568f
> [7.229936] [] lockdep_trace_alloc+0xe0/0xf0
> [7.229940] [] __kmalloc_track_caller+0x50/0x250
> [7.229945] [] devres_alloc_node+0x28/0x60
> [7.229949] [] devm_request_threaded_irq+0x50/0xe0
> [7.229955] [] pcc_mbox_request_channel+0x110/0x170
> [7.229960] [] acpi_cppc_processor_probe+0x264/0x414
> [7.229963] [] __acpi_processor_start+0x28/0xa0
> [7.229966] [] acpi_processor_start+0x44/0x54
> [7.229970] [] driver_probe_device+0x1fc/0x2b0
> [7.229974] [] __driver_attach+0xb4/0xc0
> [7.229977] [] bus_for_each_dev+0x5c/0xa0
> [7.229980] [] driver_attach+0x20/0x30
> [7.229983] [] bus_add_driver+0x110/0x230
> [7.229987] [] driver_register+0x60/0x100
> [7.229991] [] acpi_processor_driver_init+0x2c/0xb0
> [7.229996] [] do_one_initcall+0x38/0x130
> [7.23] [] kernel_init_freeable+0x210/0x2b4
> [7.230004] [] kernel_init+0x10/0x110
> [7.230007] [] ret_from_fork+0x10/0x50
>
> It's because the spinlock inside pcc_mbox_request_channel() is
> kept too long. This patch releases spinlock before request_irq()
> and free_irq() to fix this issue  as spinlock is only needed to
> protect the channel data.
>
> Signed-off-by: Hoan Tran 
> ---
> v2
>  * Release spinlock before request_irq() and free_irq() instead of
> using mutex
>
>  drivers/mailbox/pcc.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 08c87fa..b5275a8 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -267,6 +267,8 @@ struct mbox_chan *pcc_mbox_request_channel(struct 
> mbox_client *cl,
>   if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
>   chan->txdone_method |= TXDONE_BY_ACK;
>  
> + spin_unlock_irqrestore(>lock, flags);
> +
>   if (pcc_doorbell_irq[subspace_id] > 0) {
>   int rc;
>  
> @@ -279,8 +281,6 @@ struct mbox_chan *pcc_mbox_request_channel(struct 
> mbox_client *cl,
>   }
>   }
>  
> - spin_unlock_irqrestore(>lock, flags);
> -
>   return chan;
>  }
>  EXPORT_SYMBOL_GPL(pcc_mbox_request_channel);
> @@ -310,10 +310,10 @@ void pcc_mbox_free_channel(struct mbox_chan *chan)
>   if (chan->txdone_method == (TXDONE_BY_POLL | TXDONE_BY_ACK))
>   chan->txdone_method = TXDONE_BY_POLL;
>  
> + spin_unlock_irqrestore(>lock, flags);
> +
>   if (pcc_doorbell_irq[id] > 0)
>   devm_free_irq(chan->mbox->dev, pcc_doorbell_irq[id], chan);
Shouldn't we free the irq first and then reset the channel state?
To avoid the scenario where an interrupt might get triggered after
we reset the channel state but before we release the interrupt

--
Thanks,
Prashanth

[PATCH 5/5] irqchip: st: Remove obsolete platforms from dt binding doc

[patrice.chotard]

From: Patrice Chotard 

STiH415/6 SoC support is being removed from the kernel.
This patch updates the sti irchip and removes
references to these obsolete platforms.

Signed-off-by: Patrice Chotard 
Cc: 
Cc: 
Cc: 
---
 .../devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt  | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt 
b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
index ced6014..23d1e1c 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
@@ -7,8 +7,6 @@ This driver is used to unmask them prior to use.
 
 Required properties:
 - compatible   : Should be set to one of:
-   "st,stih415-irq-syscfg"
-   "st,stih416-irq-syscfg"
"st,stih407-irq-syscfg"
"st,stid127-irq-syscfg"
 - st,syscfg: Phandle to Cortex-A9 IRQ system config registers
@@ -25,8 +23,8 @@ Optional properties:
 Example:
 
 irq-syscfg {
-   compatible= "st,stih416-irq-syscfg";
-   st,syscfg = <_cpu>;
+   compatible= "st,stih407-irq-syscfg";
+   st,syscfg = <_core>;
st,irq-device = ,
;
st,fiq-device = ,
-- 
1.9.1

Re: [PATCH V4 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"

[Sinan Kaya]

On 10/21/2016 7:45 AM, Bjorn Helgaas wrote:
> [1] http://marc.info/?l=linux-acpi=145580159209240=2)
> 
>> > Acked-by: Bjorn Helgaas 
> Wait a minute, I still have a question here: what about other ACPI
> arches (ia64, arm64)?  Don't they need to call acpi_penalize_sci_irq()
> somewhere?
> 

ACPI ARM64 architecture implements reduced ACPI profile which doesn't
have GED object. Instead, ARM64 architecture uses onchip peripherals
for similar functionality. If there is a need to signal interrupts,
this is done by ACPI Notify in ASL or if absolutely needed using
ACPI Generic Event Device (GED).

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[RFC][PATCH] Add EXPORT_MACRO_SYMBOL() for asm

[Steven Rostedt]

Commit 784d5699eddc5 ("x86: move exports to actual definitions") removed the
EXPORT_SYMBOL(__fentry__) and EXPORT_SYMBOL(mcount) from x8664_ksyms_64.c,
and added EXPORT_SYMBOL(function_hook) in mcount_64.S instead. The problem
is that function_hook isn't a function at all, but a macro that is defined
as eithe mcount or __fentry__ depending on the support from gcc. But instead
of adding more #ifdefs like x8684_ksyms_64.c had, I suggest having another
export that can handle this similar to the way __string() works with
converting macros to strings. By having:

 EXPORT_MACRO_SYMBOL(function_hook)

Where we have:

 #define EXPORT_MACRO_SYMBOL(x) EXPORT_SYMBOL(x)

It will convert the macro into what it is defined as before calling
EXPORT_SYMBOL(), and this will just work properly again.

Cc: sta...@vger.kernel.org
Fixes: Commit 784d5699eddc5 ("x86: move exports to actual definitions")
Signed-off-by: Steven Rostedt 
---
 arch/x86/kernel/mcount_64.S  | 2 +-
 include/asm-generic/export.h | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/mcount_64.S b/arch/x86/kernel/mcount_64.S
index efe73aacf966..ccd9d912af27 100644
--- a/arch/x86/kernel/mcount_64.S
+++ b/arch/x86/kernel/mcount_64.S
@@ -295,7 +295,7 @@ trace:
jmp fgraph_trace
 END(function_hook)
 #endif /* CONFIG_DYNAMIC_FTRACE */
-EXPORT_SYMBOL(function_hook)
+EXPORT_MACRO_SYMBOL(function_hook)
 #endif /* CONFIG_FUNCTION_TRACER */
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
index 43199a049da5..cb86e746865e 100644
--- a/include/asm-generic/export.h
+++ b/include/asm-generic/export.h
@@ -90,5 +90,10 @@
__EXPORT_SYMBOL(name, KSYM(name),)
 #define EXPORT_DATA_SYMBOL_GPL(name)   \
__EXPORT_SYMBOL(name, KSYM(name),_gpl)
+/*
+ * If "name" is a macro of a function and not a function itself,
+ * it needs a second pass.
+ */
+#define EXPORT_MACRO_SYMBOL(x) EXPORT_SYMBOL(x)
 
 #endif
-- 
1.9.3

Re: [PATCH][manpages 1/2] perf_event_open.2: Document PERF_EVENT_IOC_PAUSE_OUTPUT

[Michael Kerrisk (man-pages)]

Hi Vince,

On 21 October 2016 at 16:37, Vince Weaver  wrote:
> On Fri, 21 Oct 2016, Michael Kerrisk (man-pages) wrote:
>
>> Thanks for this patch, Wangnan.
>>
>> Vince, do you have any comments?
>>
>
> I was catching up chronologically and was still at 4.4, and this was
> still in my queue as a 4.6 change.  I think I thought the patches looked
> good at the time, but I'll revisit them (and write some sample code to
> test out the interface) and get back to you soon.

Note that Wang Nan sent out new patches today -- not sure if there
were any changes though.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH] pci: pcie-designware-plat: changing driver authors e-mail

[Bjorn Helgaas]

On Fri, Oct 21, 2016 at 10:31:48AM +0100, Joao Pinto wrote:
> Although I am leaving Synopsys, I would like to keep working with the
> linux kernel community and help in what you might find useful. For that
> I am sending this patch to change my contact e-mail. 
> 
> Signed-off-by: Joao Pinto 

Applied to for-linus for v4.9, thanks, Joao!  Best wishes in your next
adventure.  Thanks for all your work and I hope you keep contributing to
PCI!

> ---
>  drivers/pci/host/pcie-designware-plat.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pcie-designware-plat.c 
> b/drivers/pci/host/pcie-designware-plat.c
> index 537f58a..8df6312 100644
> --- a/drivers/pci/host/pcie-designware-plat.c
> +++ b/drivers/pci/host/pcie-designware-plat.c
> @@ -3,7 +3,7 @@
>   *
>   * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com)
>   *
> - * Authors: Joao Pinto 
> + * Authors: Joao Pinto 
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 as
> -- 
> 1.8.1.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] acpi/apei: Fix in-correct return value

[Punit Agrawal]

"Baicar, Tyler"  writes:

> On 10/18/2016 10:07 AM, Punit Agrawal wrote:
>> Although ghes_proc tests for error while reading the error status, it
>> always return success (0). Fix this by propagating the return value.
>>
>> Fixes: d334a49113a4a33 ("ACPI, APEI, Generic Hardware Error Source memory 
>> error support")
>> Signed-of-by: Punit Agrawal 
>> Cc: "Rafael J. Wysocki" 
>> Cc: Len Brown 
> Tested-by: Tyler Baicar 

Thanks for taking the patch for a spin.

Hopefully Rafael can pick the patch as a fixes for the next rc.


>
> Thanks,
> Tyler
>> ---
>>   drivers/acpi/apei/ghes.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index f0a029e..0d099a2 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -662,7 +662,7 @@ static int ghes_proc(struct ghes *ghes)
>>  ghes_do_proc(ghes, ghes->estatus);
>>   out:
>>  ghes_clear_estatus(ghes);
>> -return 0;
>> +return rc;
>>   }
>> static void ghes_add_timer(struct ghes *ghes)

Re: [PATCH] dt-bindings: video: exynos7-decon: Remove obsolete samsung,power-domain property

[Javier Martinez Canillas]

On 10/21/2016 11:36 AM, Sylwester Nawrocki wrote:
> On 10/21/2016 04:05 PM, Krzysztof Kozlowski wrote:
>> The samsung,power-domain property is obsolete since commit 0da658704136
>> ("ARM: dts: convert to generic power domain bindings for exynos DT").
>> Replace it with generic one.
>>
>> Signed-off-by: Krzysztof Kozlowski 
> 
> Reviewed-by: Sylwester Nawrocki 
> 

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [RFC] ARM: dts: exynos: Remove exynos4415.dtsi

[Javier Martinez Canillas]

On 10/21/2016 11:33 AM, Sylwester Nawrocki wrote:
> On 10/21/2016 04:15 PM, Krzysztof Kozlowski wrote:
>> There are no boards in mainline using exynos4415.dtsi.  This is DTS
>> was not tested for long.  I am also not aware of any popular out-of-tree
>> boards using this (except consumer devices released by Samsung but those
>> cannot use mainline).
>>
>> Keeping Exynos4415 costs some useless effort so remove it.
>>
>> Signed-off-by: Krzysztof Kozlowski 
> 
> It seems a sane thing to do, I don't know of any active platform that
> uses Exynos4415.
> 
> Acked-by: Sylwester Nawrocki 
> 

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[PATCH]: Staging: Greybus: Fix trailing */ in block comments

[Rahul Krishnan]

This patch fixes the following checkpath.pl warning
WARNING: Block comments use a trailing */ on a separate line

Signed-off-by: Rahul Krishnan  
---
 drivers/staging/greybus/log.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/greybus/log.c b/drivers/staging/greybus/log.c
index 70dd9e5..1a18ab1 100644
--- a/drivers/staging/greybus/log.c
+++ b/drivers/staging/greybus/log.c
@@ -55,8 +55,10 @@ static int gb_log_request_handler(struct gb_operation *op)
/* Ensure the buffer is 0 terminated */
receive->msg[len - 1] = '\0';
 
-   /* Print with dev_dbg() so that it can be easily turned off using
-* dynamic debugging (and prevent any DoS) */
+   /*
+* Print with dev_dbg() so that it can be easily turned off using
+* dynamic debugging (and prevent any DoS)
+*/
dev_dbg(dev, "%s", receive->msg);
 
return 0;
-- 
1.9.1

PROBLEM: OHCI watchdog timeouts inside VirtualBox, probably due to timer wheel rework

[Michael Thayer]

Hello Alan (LKML on CC),

Contacting you about this on Thomas Gleixner's (also on CC) suggestion. 
The short summary is that when Linux 4.8.0 (also tested with a few later 
kernels) is run on a VirtualBox virtual machine with USB enabled, OHCI 
fails with the log messages "frame counter not updated; disabled" and 
"HC died; cleaning up".  This seems to be due to the 250 ms interval 
watchdog running with far too short intervals, which we think is a 
consequence of the timer wheel code rework.  I will refer you to a bug 
filed in Launchpad<1> for a longer description.


Hope this is of interest to you.

Regards,

Michael

<1> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1634737
--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister 
der Handelskammer Midden-Nederland, Nr. 30143697

Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

Re: [PATCH] char/tpm: Check return code of wait_for_tpm_stat

[Jarkko Sakkinen]

On Wed, Oct 12, 2016 at 03:16:06PM +0300, Jarkko Sakkinen wrote:
> On Tue, Oct 11, 2016 at 08:01:09PM +0200, Peter Huewe wrote:
> > 
> > 
> > Hi
> > Am 11. Oktober 2016 19:13:13 MESZ, schrieb Jason Gunthorpe 
> > :
> > >On Tue, Oct 11, 2016 at 03:01:01PM +0300, Jarkko Sakkinen wrote:
> > >> From: Peter Huewe 
> > >> 
> > >> In some weird cases it might be possible that the TPM does not set
> > >> STS.VALID within the given timeout time (or ever) but sets STS.EXPECT
> > >> (STS=0x0C) In this case the driver gets stuck in the while loop of
> > >> tpm_tis_send_data and loops endlessly.
> > >
> > >Doesn't that exchange mean the TPM has lost synchronization with the
> > >driver? Or maybe it crashed executing a command or something..
> > 
> > I saw that in the field on quite a few (similar) systems with our lpc tpms 
> > - so it affects end users.
> > Yes it is caused by some desynchronization or something similar.
> > 
> > If you manually send a commandReady by mmaping the memory region you can 
> > un-stuck the driver and the situation was never seen again on that system.
> > 
> > The exact reason how this happens is yet unknown, but the driver should 
> > definitely not be stuck in an endless loop (which zombies the application 
> > too) in that case but bail out as defined in the TIS protocol. The next 
> > access sends the cr which cures the unsynchronization.
> 
> Even as a sanity check return codes should be checked so in
> any case I leaned towards applying this patch. It makes the
> driver more robust.

I applied this.

/Jarkko

Re: [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL pointer

[Bjorn Helgaas]

On Mon, Oct 17, 2016 at 04:44:06PM -0500, Li Yang wrote:
> Commit fefe6733e added reference to the pcie->drvdata before it is
> initialized which causes a kernel panic.  Fix the problem by
> initializing the pcie->drvdata earlier before it is used.
> 
> Reported-by: Stuart Yoder 
> Signed-off-by: Li Yang 

I applied Marc Zyngier's identical patch to for-linus for v4.9.  I don't
know which was posted first, but I saw Marc's first.  Sorry I didn't at
least credit you when I applied it.

> ---
>  drivers/pci/host/pci-layerscape.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pci-layerscape.c 
> b/drivers/pci/host/pci-layerscape.c
> index 2cb7315..958187f 100644
> --- a/drivers/pci/host/pci-layerscape.c
> +++ b/drivers/pci/host/pci-layerscape.c
> @@ -245,6 +245,7 @@ static int __init ls_pcie_probe(struct platform_device 
> *pdev)
>   if (!pcie)
>   return -ENOMEM;
>  
> + pcie->drvdata = match->data;
>   pp = >pp;
>   pp->dev = dev;
>   pp->ops = pcie->drvdata->ops;
> @@ -256,7 +257,6 @@ static int __init ls_pcie_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(pcie->pp.dbi_base);
>   }
>  
> - pcie->drvdata = match->data;
>   pcie->lut = pcie->pp.dbi_base + pcie->drvdata->lut_offset;
>  
>   if (!ls_pcie_is_bridge(pcie))
> -- 
> 1.9.0
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V7 1/4] dmaengine: qcom_hidma: make pending_tre_count atomic

[Sinan Kaya]

Getting ready for the MSI interrupts. The pending_tre_count is used
in the interrupt handler to make sure all outstanding requests are
serviced.

The driver will allocate 11 MSI interrupts. Each MSI interrupt can be
assigned to a different CPU. Then, we have a race condition for common
variables as they share the same interrupt handler with a different
cause bit and they can potentially be executed in parallel. Making this
variable atomic so that it can be updated from multiple processor
contexts.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/hidma.h |  2 +-
 drivers/dma/qcom/hidma_dbg.c |  3 ++-
 drivers/dma/qcom/hidma_ll.c  | 13 ++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index de61764..181f7e0 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -59,7 +59,7 @@ struct hidma_lldev {
void __iomem *evca; /* Event Channel address  */
struct hidma_tre
**pending_tre_list; /* Pointers to pending TREs   */
-   s32 pending_tre_count;  /* Number of TREs pending */
+   atomic_t pending_tre_count; /* Number of TREs pending */
 
void *tre_ring; /* TRE ring   */
dma_addr_t tre_dma; /* TRE ring to be shared with HW  */
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
index 3d83b99..3bdcb80 100644
--- a/drivers/dma/qcom/hidma_dbg.c
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -74,7 +74,8 @@ static void hidma_ll_devstats(struct seq_file *s, void 
*llhndl)
seq_printf(s, "tre_ring_handle=%pap\n", >tre_dma);
seq_printf(s, "tre_ring_size = 0x%x\n", lldev->tre_ring_size);
seq_printf(s, "tre_processed_off = 0x%x\n", lldev->tre_processed_off);
-   seq_printf(s, "pending_tre_count=%d\n", lldev->pending_tre_count);
+   seq_printf(s, "pending_tre_count=%d\n",
+   atomic_read(>pending_tre_count));
seq_printf(s, "evca=%p\n", lldev->evca);
seq_printf(s, "evre_ring=%p\n", lldev->evre_ring);
seq_printf(s, "evre_ring_handle=%pap\n", >evre_dma);
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index e605c90..114409e 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -218,10 +218,9 @@ static int hidma_post_completed(struct hidma_lldev *lldev, 
int tre_iterator,
 * Keep track of pending TREs that SW is expecting to receive
 * from HW. We got one now. Decrement our counter.
 */
-   lldev->pending_tre_count--;
-   if (lldev->pending_tre_count < 0) {
+   if (atomic_dec_return(>pending_tre_count) < 0) {
dev_warn(lldev->dev, "tre count mismatch on completion");
-   lldev->pending_tre_count = 0;
+   atomic_set(>pending_tre_count, 0);
}
 
spin_unlock_irqrestore(>lock, flags);
@@ -328,7 +327,7 @@ void hidma_cleanup_pending_tre(struct hidma_lldev *lldev, 
u8 err_info,
u32 tre_read_off;
 
tre_iterator = lldev->tre_processed_off;
-   while (lldev->pending_tre_count) {
+   while (atomic_read(>pending_tre_count)) {
if (hidma_post_completed(lldev, tre_iterator, err_info,
 err_code))
break;
@@ -555,7 +554,7 @@ void hidma_ll_queue_request(struct hidma_lldev *lldev, u32 
tre_ch)
tre->err_code = 0;
tre->err_info = 0;
tre->queued = 1;
-   lldev->pending_tre_count++;
+   atomic_inc(>pending_tre_count);
lldev->tre_write_offset = (lldev->tre_write_offset + HIDMA_TRE_SIZE)
% lldev->tre_ring_size;
spin_unlock_irqrestore(>lock, flags);
@@ -650,7 +649,7 @@ int hidma_ll_setup(struct hidma_lldev *lldev)
u32 val;
u32 nr_tres = lldev->nr_tres;
 
-   lldev->pending_tre_count = 0;
+   atomic_set(>pending_tre_count, 0);
lldev->tre_processed_off = 0;
lldev->evre_processed_off = 0;
lldev->tre_write_offset = 0;
@@ -831,7 +830,7 @@ int hidma_ll_uninit(struct hidma_lldev *lldev)
tasklet_kill(>task);
memset(lldev->trepool, 0, required_bytes);
lldev->trepool = NULL;
-   lldev->pending_tre_count = 0;
+   atomic_set(>pending_tre_count, 0);
lldev->tre_write_offset = 0;
 
rc = hidma_ll_reset(lldev);
-- 
1.9.1

Disabling an interrupt in the handler locks the system up

[Mason]

Hello,

On my platform, one HW block pulls the interrupt line high
as long as it remains idle, and low when it is busy.

The device tree node is:

test@2 {
compatible = "vendor,testme";
interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
};

I wrote a minimal driver which registers the irq.
And in the interrupt handler, I disable said irq.

Since the irq is IRQ_TYPE_LEVEL_HIGH, it will fire as soon as
it is registered (because the block is idle).

Here is the code I've been running, request_irq doesn't return.

#include 
#include 
#include 
#include 

static irqreturn_t test_isr(int irq, void *dev)
{
printk("irq=%d dev=%p\n", irq, dev);
disable_irq_nosync(irq);
printk("IRQ %d NOW DISABLED\n", irq);
return IRQ_HANDLED;
}

static int test_probe(struct platform_device *pdev)
{
unsigned res, virq;
printk("ENTER %s\n", __func__);

virq = irq_of_parse_and_map(pdev->dev.of_node, 0);
printk("virq = %u\n", virq);

res = request_irq(virq, test_isr, 0, "testme", (void *)0x42);
printk("request_irq = %d\n", res);

return 0;
}

static const struct of_device_id test_ids[] = {
{ .compatible = "vendor,testme" },
{ /* sentinel */ }
};

static struct platform_driver test_driver = {
.probe  = test_probe,
.driver = {
.name   = "test",
.of_match_table = test_ids,
},
};

module_platform_driver(test_driver);
MODULE_LICENSE("GPL");


And here's what I get when I try to load the module:
(I'm using the default CONFIG_RCU_CPU_STALL_TIMEOUT=21)

$ insmod test.ko
[   91.571065] ENTER test_probe
[   91.574208] virq = 21
[   91.576902] irq=21 dev=0042
[   91.580061] IRQ 21 NOW DISABLED
[  102.038544] nfs: server 172.27.64.1 not responding, still trying
[  112.571855] INFO: rcu_preempt self-detected stall on CPU
[  112.577201]  0-...: (6298 ticks this GP) idle=c45/142/0 
softirq=1295/1295 fqs=2045 
[  112.585942]   (t=6300 jiffies g=208 c=207 q=20)
[  112.590497] Task dump for CPU 0:
[  112.593735] insmod  R running  0   951929 0x0002
[  112.600124] Backtrace: 
[  112.602601] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)
[  112.610207]  r7:c0702434[  112.612571]  r6:c07024c8
 r5:03a1[  112.616163]  r4:df570dc0
[  112.618701] 
[  112.620202] [] (show_stack) from [] 
(sched_show_task+0xbc/0x110)
[  112.627989] [] (sched_show_task) from [] 
(dump_cpu_task+0x40/0x48)
[  112.635943]  r5:[  112.638307]  r4:
[  112.640845] 
[  112.642347] [] (dump_cpu_task) from [] 
(rcu_dump_cpu_stacks+0xb0/0xcc)
[  112.650651]  r5:[  112.653014]  r4:c070a840
[  112.63] 
[  112.657055] [] (rcu_dump_cpu_stacks) from [] 
(rcu_check_callbacks+0x8f8/0x9b0)
[  112.666058]  r10:c07024c0[  112.668509]  r9:c0702518
 r8:1f5a3000[  112.672100]  r7:c070a840
 r6:c0702100[  112.675691]  r5:c0637f40
[  112.678230]  r4:dfbdaf40[  112.680592]  r3:2458
[  112.683130] 
[  112.684629] [] (rcu_check_callbacks) from [] 
(update_process_times+0x3c/0x64)
[  112.693545]  r10:c0188c54[  112.695995]  r9:0001
 r8:dfbd870c[  112.699588]  r7:001a
 r6:[  112.703178]  r5:df570dc0
[  112.705717]  r4:e000[  112.708080] 
[  112.709581] [] (update_process_times) from [] 
(tick_sched_handle+0x50/0x54)
[  112.718322]  r7:001a[  112.720684]  r6:35192494
 r5:def2dab8[  112.724274]  r4:dfbd88f8
[  112.726812] 
[  112.728309] [] (tick_sched_handle) from [] 
(tick_sched_timer+0x5c/0xa0)
[  112.736705] [] (tick_sched_timer) from [] 
(__hrtimer_run_queues+0x11c/0x1ac)
[  112.745533]  r7:[  112.747896]  r6:dfbd8700
 r5:dfbd88f8[  112.751486]  r4:dfbd86c0
[  112.754025] 
[  112.755519] [] (__hrtimer_run_queues) from [] 
(hrtimer_interrupt+0xbc/0x20c)
[  112.764347]  r10:dfbd8738[  112.766798]  r9:dfbd8778
 r8:dfbd8758[  112.770389]  r7:dfbd86d4
 r6:[  112.773979]  r5:0003
[  112.776518]  r4:dfbd86c0[  112.778881] 
[  112.780378] [] (hrtimer_interrupt) from [] 
(twd_handler+0x38/0x48)
[  112.788332]  r10:def2dab8[  112.790782]  r9:df402400
 r8:0001[  112.794373]  r7:df408700
 r6:0013[  112.797964]  r5:c0702744
[  112.800504]  r4:0001[  112.802866] 
[  112.804362] [] (twd_handler) from [] 
(handle_percpu_devid_irq+0x94/0x14c)
[  112.812928]  r5:c0702744[  112.815291]  r4:df405300
[  112.817829] 
[  112.819327] [] (handle_percpu_devid_irq) from [] 
(generic_handle_irq+0x2c/0x3c)
[  112.828417]  r7:def2dbd0[  112.830780]  r6:0013
 r5:[  112.834370]  r4:c0635ec4
[  112.836909] 
[  112.838404] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x84/0xf4)
[  112.847150] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x50/0x94)
[  112.855541]  r10:def2dbd0[  112.857992]  r9:e0803100
 r8:e0802100[  112.861583]  r7:def2dab8
 r6:e080210c[  112.865173]  r5:c0702744
[  112.867712]  r4:c070ff50[  112.870076]  r3:def2dab8
[  112.872614] 

[PATCH V7 2/4] dmaengine: qcom_hidma: bring out interrupt cause

[Sinan Kaya]

Bring out the interrupt cause to the top level so that MSI interrupts
can be hooked at a later stage.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/hidma_ll.c | 62 -
 1 file changed, 33 insertions(+), 29 deletions(-)

diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index 114409e..9193f46 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -418,12 +418,24 @@ static int hidma_ll_reset(struct hidma_lldev *lldev)
  * requests traditionally to the destination, this concept does not apply
  * here for this HW.
  */
-irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
+static void hidma_ll_int_handler_internal(struct hidma_lldev *lldev, int cause)
 {
-   struct hidma_lldev *lldev = arg;
-   u32 status;
-   u32 enable;
-   u32 cause;
+   if (cause & HIDMA_ERR_INT_MASK) {
+   dev_err(lldev->dev, "error 0x%x, disabling...\n",
+   cause);
+
+   /* Clear out pending interrupts */
+   writel(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+
+   /* No further submissions. */
+   hidma_ll_disable(lldev);
+
+   /* Driver completes the txn and intimates the client.*/
+   hidma_cleanup_pending_tre(lldev, 0xFF,
+ HIDMA_EVRE_STATUS_ERROR);
+
+   return;
+   }
 
/*
 * Fine tuned for this HW...
@@ -432,35 +444,28 @@ irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
 * read and write accessors are used for performance reasons due to
 * interrupt delivery guarantees. Do not copy this code blindly and
 * expect that to work.
+*
+* Try to consume as many EVREs as possible.
 */
+   hidma_handle_tre_completion(lldev);
+
+   /* We consumed TREs or there are pending TREs or EVREs. */
+   writel_relaxed(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+}
+
+irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
+{
+   struct hidma_lldev *lldev = arg;
+   u32 status;
+   u32 enable;
+   u32 cause;
+
status = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_STAT_REG);
enable = readl_relaxed(lldev->evca + HIDMA_EVCA_IRQ_EN_REG);
cause = status & enable;
 
while (cause) {
-   if (cause & HIDMA_ERR_INT_MASK) {
-   dev_err(lldev->dev, "error 0x%x, disabling...\n",
-   cause);
-
-   /* Clear out pending interrupts */
-   writel(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
-
-   /* No further submissions. */
-   hidma_ll_disable(lldev);
-
-   /* Driver completes the txn and intimates the client.*/
-   hidma_cleanup_pending_tre(lldev, 0xFF,
- HIDMA_EVRE_STATUS_ERROR);
-   goto out;
-   }
-
-   /*
-* Try to consume as many EVREs as possible.
-*/
-   hidma_handle_tre_completion(lldev);
-
-   /* We consumed TREs or there are pending TREs or EVREs. */
-   writel_relaxed(cause, lldev->evca + HIDMA_EVCA_IRQ_CLR_REG);
+   hidma_ll_int_handler_internal(lldev, cause);
 
/*
 * Another interrupt might have arrived while we are
@@ -471,7 +476,6 @@ irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
cause = status & enable;
}
 
-out:
return IRQ_HANDLED;
 }
 
-- 
1.9.1

Re: [PATCH 01/12] Documentation/HOWTO: Mark subsection in rst format

[SeongJae Park]

On Sat, Oct 22, 2016 at 12:45 AM, Mauro Carvalho Chehab
 wrote:
> Em Sat, 22 Oct 2016 00:19:46 +0900
> SeongJae Park  escreveu:
>
>> Subsections in HOWTO is not marked in rst format.  This commit specifies
>> them in rst format.
>>
>> Signed-off-by: SeongJae Park 
>> ---
>>  Documentation/HOWTO | 15 ++-
>>  1 file changed, 10 insertions(+), 5 deletions(-)
>
> There are already patches converting HOWTO to ReST applied upstream:

This patchset is not to replace the patches but to be applied on top of the
patches.

>
> commit 1b49ecf2f3be358882bb97652ba50ae808c0ba8f
> Author: Jonathan Corbet 
> Date:   Tue Sep 20 18:46:36 2016 -0600
>
> docs: Clean up bare :: lines
>
> Mauro's patch set introduced some bare :: lines; these can be represented
> by a double colon at the end of the preceding text line.  The result looks
> a little less weird and is less verbose.
>
> Signed-off-by: Jonathan Corbet 
>
> commit f1eebe92c2653e8fc3760577e53befdc9b62ef26
> Author: Mauro Carvalho Chehab 
> Date:   Mon Sep 19 08:07:59 2016 -0300
>
> Documentation/HOWTO: adjust external link references
>
> - A few link references were missing http://
> - Several sites are now redirecting to https protocol. On such
>   cases, just use the https URL.
>
> NOTE: all URLs were checked and they're pointing to the right places.
>
> Signed-off-by: Mauro Carvalho Chehab 
> Signed-off-by: Jonathan Corbet 
>
> commit 34fed7e7e0e56f885f309e8892a3571400072e37
> Author: Mauro Carvalho Chehab 
> Date:   Mon Sep 19 08:07:58 2016 -0300
>
> Documentation/HOWTO: improve some markups to make it visually better
>
> Do a series of minor improvements at the ReST output format:
>
> - Instead of using the quote blocks (::) for quotes, use
> italics. That looks nicer on epub (and html) output, as
> no scroll bar will be added. Also, it will adjust line
> breaks on the text automatically.
>
> - Add a missing reference to SubmittingPatches.rst and use
> **foo** instead of _foo_.
>
> - use bold for "The Perfect Patch" by removing a newline.
>
> Signed-off-by: Mauro Carvalho Chehab 
> Signed-off-by: Jonathan Corbet 
>
> commit 43fb67a5258c0f3d1d869cb7d72617d87b257c62
> Author: Mauro Carvalho Chehab 
> Date:   Mon Sep 19 08:07:57 2016 -0300
>
> Documentation/HOWTO: update information about generating documentation
>
> The description there are pre-Sphinx. Update it to cover the
> new way.
>
> Signed-off-by: Mauro Carvalho Chehab 
> Signed-off-by: Jonathan Corbet 
>
>
> There's also a series of patches pending merge that moves it
> Documentation/process/howto.rst and add to this book:
>
> https://mchehab.fedorapeople.org/kernel_docs/process/howto.html

AFAIU, `The development process` section has subsections but they are marked as
sections.  That's what this patchset is trying to solve.  Looks like the
problem is still in the pending patches, too.  If you would like, I will resend
this patch after merging of the pending patches, though it would be no big
problem to merge this little patch before it.


Thanks,
SeongJae Park

>
>
> Thanks,
> Mauro

Re: [PATCH] clk: fix link error for rcar-gen2

[Sergei Shtylyov]

Hello.

On 10/21/2016 06:47 PM, Arnd Bergmann wrote:


The addition of one more rcar-gen2 based SoC caused a build error (again)
in my randconfig builds:

arch/arm/mach-shmobile/setup-rcar-gen2.o: In function `rcar_gen2_timer_init':
setup-rcar-gen2.c:(.init.text+0x200): undefined reference to 
`rcar_gen2_clocks_init'


   OK, seeing how you got this -- I should have tested the kernel build with 
only R8A7743 enabled... sorry about that. :-<

   I probably shouldn't have used rcar_gen2_timer_init() in the 1st place...


I think this has happened twice in the past. Instead of adding each SoC
one at a time, this changes the existing list to always build the
rcar-gen2 related clk files whenever the generic symbol is selected.


   The problem is we're not going to use this driver on RZ/G SoCs... The 
newer rcar2-cpg-mssr.c will be used instead -- I submitted the patches for 
that before ELC-E...



Fixes: 1254f607fc3d ("ARM: shmobile: r8a7743: basic SoC support")
Signed-off-by: Arnd Bergmann 

[...]

MBR, Sergei

[RESEND PATCH] usb: chipidea: Configure DMA properties and ops from DT

[Bjorn Andersson]

hcd_alloc_coherent() and usb_alloc_coherent() ends up allocating coherent
memory on behalf of ci_hdrc driver. But as the ci_hdrc is instantiated manually
it will not have any dma_mem or dma_ops assigned, which makes the
dma_alloc_coherent() fail on some platforms (e.g. arm64). This patch solves
this by assigning the dma_mem and dma_ops based on the parent's DeviceTree
node.

Cc: Stephen Boyd 
Signed-off-by: Bjorn Andersson 
---

Hi Peter,

After (once more) debugging why USB doesn't work up on the 64-bit Qualcomm
systems I realized that we never concluded on this patch. Unfortunately I can't
find it in my mailbox either, so resending it to restart the discussion.

Regards,
Bjorn

 drivers/usb/chipidea/core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e644d17..6218d83cca25 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -62,6 +62,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -837,6 +838,9 @@ struct platform_device *ci_hdrc_add_device(struct device 
*dev,
pdev->dev.dma_parms = dev->dma_parms;
dma_set_coherent_mask(>dev, dev->coherent_dma_mask);
 
+   if (IS_ENABLED(CONFIG_OF) && dev->of_node)
+   of_dma_configure(>dev, dev->of_node);
+
ret = platform_device_add_resources(pdev, res, nres);
if (ret)
goto err;
-- 
2.5.0

[RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions

[Neil Armstrong]

Add support for the Amlogic Meson GXL SoC, this is a partially complete
definition only based on the Amlogic Vendor tree.

This definition differs a lot from the GXBB and needs a separate entry.

Signed-off-by: Neil Armstrong 
---
 .../devicetree/bindings/pinctrl/meson,pinctrl.txt  |   2 +
 drivers/pinctrl/meson/Makefile |   3 +-
 drivers/pinctrl/meson/pinctrl-meson-gxl.c  | 589 +
 drivers/pinctrl/meson/pinctrl-meson.c  |   8 +
 drivers/pinctrl/meson/pinctrl-meson.h  |   2 +
 include/dt-bindings/gpio/meson-gxl-gpio.h  | 131 +
 6 files changed, 734 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson-gxl.c
 create mode 100644 include/dt-bindings/gpio/meson-gxl-gpio.h

diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
index fe7fe0b..2392557 100644
--- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
@@ -7,6 +7,8 @@ Required properties for the root node:
  "amlogic,meson8b-aobus-pinctrl"
  "amlogic,meson-gxbb-periphs-pinctrl"
  "amlogic,meson-gxbb-aobus-pinctrl"
+ "amlogic,meson-gxl-periphs-pinctrl"
+ "amlogic,meson-gxl-aobus-pinctrl"
  - reg: address and size of registers controlling irq functionality
 
 === GPIO sub-nodes ===
diff --git a/drivers/pinctrl/meson/Makefile b/drivers/pinctrl/meson/Makefile
index 24434f1..27c5b51 100644
--- a/drivers/pinctrl/meson/Makefile
+++ b/drivers/pinctrl/meson/Makefile
@@ -1,2 +1,3 @@
-obj-y  += pinctrl-meson8.o pinctrl-meson8b.o pinctrl-meson-gxbb.o
+obj-y  += pinctrl-meson8.o pinctrl-meson8b.o
+obj-y  += pinctrl-meson-gxbb.o pinctrl-meson-gxl.o
 obj-y  += pinctrl-meson.o
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxl.c 
b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
new file mode 100644
index 000..25694f7
--- /dev/null
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
@@ -0,0 +1,589 @@
+/*
+ * Pin controller and GPIO driver for Amlogic Meson GXL.
+ *
+ * Copyright (C) 2016 Endless Mobile, Inc.
+ * Author: Carlo Caione 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include "pinctrl-meson.h"
+
+#define EE_OFF 10
+
+static const struct pinctrl_pin_desc meson_gxl_periphs_pins[] = {
+   MESON_PIN(GPIOZ_0, EE_OFF),
+   MESON_PIN(GPIOZ_1, EE_OFF),
+   MESON_PIN(GPIOZ_2, EE_OFF),
+   MESON_PIN(GPIOZ_3, EE_OFF),
+   MESON_PIN(GPIOZ_4, EE_OFF),
+   MESON_PIN(GPIOZ_5, EE_OFF),
+   MESON_PIN(GPIOZ_6, EE_OFF),
+   MESON_PIN(GPIOZ_7, EE_OFF),
+   MESON_PIN(GPIOZ_8, EE_OFF),
+   MESON_PIN(GPIOZ_9, EE_OFF),
+   MESON_PIN(GPIOZ_10, EE_OFF),
+   MESON_PIN(GPIOZ_11, EE_OFF),
+   MESON_PIN(GPIOZ_12, EE_OFF),
+   MESON_PIN(GPIOZ_13, EE_OFF),
+   MESON_PIN(GPIOZ_14, EE_OFF),
+   MESON_PIN(GPIOZ_15, EE_OFF),
+
+   MESON_PIN(GPIOH_0, EE_OFF),
+   MESON_PIN(GPIOH_1, EE_OFF),
+   MESON_PIN(GPIOH_2, EE_OFF),
+   MESON_PIN(GPIOH_3, EE_OFF),
+   MESON_PIN(GPIOH_4, EE_OFF),
+   MESON_PIN(GPIOH_5, EE_OFF),
+   MESON_PIN(GPIOH_6, EE_OFF),
+   MESON_PIN(GPIOH_7, EE_OFF),
+   MESON_PIN(GPIOH_8, EE_OFF),
+   MESON_PIN(GPIOH_9, EE_OFF),
+
+   MESON_PIN(BOOT_0, EE_OFF),
+   MESON_PIN(BOOT_1, EE_OFF),
+   MESON_PIN(BOOT_2, EE_OFF),
+   MESON_PIN(BOOT_3, EE_OFF),
+   MESON_PIN(BOOT_4, EE_OFF),
+   MESON_PIN(BOOT_5, EE_OFF),
+   MESON_PIN(BOOT_6, EE_OFF),
+   MESON_PIN(BOOT_7, EE_OFF),
+   MESON_PIN(BOOT_8, EE_OFF),
+   MESON_PIN(BOOT_9, EE_OFF),
+   MESON_PIN(BOOT_10, EE_OFF),
+   MESON_PIN(BOOT_11, EE_OFF),
+   MESON_PIN(BOOT_12, EE_OFF),
+   MESON_PIN(BOOT_13, EE_OFF),
+   MESON_PIN(BOOT_14, EE_OFF),
+   MESON_PIN(BOOT_15, EE_OFF),
+
+   MESON_PIN(CARD_0, EE_OFF),
+   MESON_PIN(CARD_1, EE_OFF),
+   MESON_PIN(CARD_2, EE_OFF),
+   MESON_PIN(CARD_3, EE_OFF),
+   MESON_PIN(CARD_4, EE_OFF),
+   MESON_PIN(CARD_5, EE_OFF),
+   MESON_PIN(CARD_6, EE_OFF),
+
+   MESON_PIN(GPIODV_0, EE_OFF),
+   MESON_PIN(GPIODV_1, EE_OFF),
+   MESON_PIN(GPIODV_2, EE_OFF),
+   MESON_PIN(GPIODV_3, EE_OFF),
+   MESON_PIN(GPIODV_4, EE_OFF),
+   MESON_PIN(GPIODV_5, EE_OFF),
+   MESON_PIN(GPIODV_6, EE_OFF),
+   MESON_PIN(GPIODV_7, EE_OFF),
+   MESON_PIN(GPIODV_8, EE_OFF),
+   MESON_PIN(GPIODV_9, EE_OFF),
+   MESON_PIN(GPIODV_10, EE_OFF),
+   MESON_PIN(GPIODV_11, 

Re: [PATCH/RFC 0/5] cpu_relax: introduce yield, remove lowlatency

[David Miller]

From: Christian Borntraeger 
Date: Fri, 21 Oct 2016 13:58:53 +0200

> For spinning loops people did often use barrier() or cpu_relax().
> For most architectures cpu_relax and barrier are the same, but on
> some architectures cpu_relax can add some latency. For example on s390
> cpu_relax gives up the time slice to the hypervisor. On power cpu_relax
> tries to give some of the CPU to the neighbor threads. To reduce the
> latency another variant cpu_relax_lowlatency was introduced. Before this
> is used in more and more places, lets revert the logic of provide a new
> function cpu_relax_yield that can spend some time and for s390 yields
> the guest CPU.

Sparc64, fwiw, behaves similarly to powerpc.

[PATCH] block: zoned: fix harmless maybe-uninitialized warning

[Arnd Bergmann]

The blkdev_report_zones produces a harmless warning when
-Wmaybe-uninitialized is set, after gcc gets a little confused
about the multiple 'goto' here:

block/blk-zoned.c: In function 'blkdev_report_zones':
block/blk-zoned.c:188:13: error: 'nz' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

Moving the assignment to nr_zones makes this a little simpler
while also avoiding the warning reliably. I'm removing the
extraneous initialization of 'int ret' in the same patch, as
that is semi-related and could cause an uninitialized use of
that variable to not produce a warning.

Fixes: 6a0cb1bc106f ("block: Implement support for zoned block devices")
Signed-off-by: Arnd Bergmann 
---
 block/blk-zoned.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/block/blk-zoned.c b/block/blk-zoned.c
index 667f95d86695..472211fa183a 100644
--- a/block/blk-zoned.c
+++ b/block/blk-zoned.c
@@ -80,7 +80,7 @@ int blkdev_report_zones(struct block_device *bdev,
unsigned int i, n, nz;
unsigned int ofst;
void *addr;
-   int ret = 0;
+   int ret;
 
if (!q)
return -ENXIO;
@@ -179,14 +179,12 @@ int blkdev_report_zones(struct block_device *bdev,
 
}
 
+   *nr_zones = nz;
 out:
bio_for_each_segment_all(bv, bio, i)
__free_page(bv->bv_page);
bio_put(bio);
 
-   if (ret == 0)
-   *nr_zones = nz;
-
return ret;
 }
 EXPORT_SYMBOL_GPL(blkdev_report_zones);
-- 
2.9.0

Re: [PATCH] softirq: Display IRQ_POLL for irq-poll statistics

[Jens Axboe]

On 10/10/2016 06:10 AM, Sagi Grimberg wrote:

This library was moved to the generic area and was
renamed to irq-poll. Hence, update proc/softirqs output accordingly.


Added, thanks.

--
Jens Axboe

[PATCH 2/5] ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol

[patrice.chotard]

From: Patrice Chotard 

STiH415/6 SoC support is being removed from the kernel and
was the only platform using this Kconfig symbol

Signed-off-by: Patrice Chotard 
Cc: 
Cc: 
---
 arch/arm/configs/multi_v7_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 437d074..15b2f99 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -450,7 +450,6 @@ CONFIG_RCAR_THERMAL=y
 CONFIG_ARMADA_THERMAL=y
 CONFIG_DAVINCI_WATCHDOG=m
 CONFIG_EXYNOS_THERMAL=m
-CONFIG_ST_THERMAL_SYSCFG=y
 CONFIG_ST_THERMAL_MEMMAP=y
 CONFIG_WATCHDOG=y
 CONFIG_DA9063_WATCHDOG=m
-- 
1.9.1

[RFC PATCH] NFSv4: replace seqcount_t with a seqlock_t

[Sebastian Andrzej Siewior]

The raw_write_seqcount_begin() in nfs4_reclaim_open_state() bugs me
because it maps to preempt_disable() in -RT which I can't have at this
point. So I took a look at the code.
It the lockdep part was removed in commit abbec2da13f0 ("NFS: Use
raw_write_seqcount_begin/end int nfs4_reclaim_open_state") because
lockdep complained. The whole seqcount thing was introduced in commit
c137afabe330 ("NFSv4: Allow the state manager to mark an open_owner as
being recovered").
I don't understand how it is possible that we don't end up with two
writers for the same resource because the `sp->so_lock' lock is dropped
is soon in the list_for_each_entry() loop. It might be the
test_and_clear_bit() check in nfs4_do_reclaim() but it might clear one
bit on each iteration so I *think* we could have two invocations of the
same struct nfs4_state_owner in nfs4_reclaim_open_state().
So there is that.

But back to the list_for_each_entry() macro.
It seems that this `so_lock' lock protects the ->so_states list among
other atomic_t & flags members. So at the begin of the loop we inc ->count
ensuring that this field is not removed while we use it. So we drop the
->so_lock lock during the loop. And after nfs4_reclaim_locks() invocation we
nfs4_put_open_state() and then grab the ->so_lock again. So if we were the last
user of this struct and we remove it, then the following list_next_entry()
invocation is a use-after-free. Even if we use list_for_each_entry_safe() there
is no guarantee that the following member is still valid because it might have
been removed by something that invoked nfs4_put_open_state(), right?
So there is this.

However to address my initial problem I have here a patch :) So it uses
a seqlock_t which ensures that there is only one writer at a time. So it
should be basically what is happening now plus a tiny tiny tiny lock
plus lockdep coverage. I tried to test this myself but I don't manage to get
into this code path at all so I might be doing something wrong.

Could you please check if this patch is working for you and whether my
list_for_each_entry() observation is correct or not?

Signed-off-by: Sebastian Andrzej Siewior 
---
 fs/nfs/delegation.c |  4 ++--
 fs/nfs/nfs4_fs.h|  2 +-
 fs/nfs/nfs4proc.c   |  4 ++--
 fs/nfs/nfs4state.c  | 10 --
 4 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index dff600ae0d74..d726d2e09353 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -150,11 +150,11 @@ static int nfs_delegation_claim_opens(struct inode *inode,
sp = state->owner;
/* Block nfs4_proc_unlck */
mutex_lock(>so_delegreturn_mutex);
-   seq = raw_seqcount_begin(>so_reclaim_seqcount);
+   seq = read_seqbegin(>so_reclaim_seqlock);
err = nfs4_open_delegation_recall(ctx, state, stateid, type);
if (!err)
err = nfs_delegation_claim_locks(ctx, state, stateid);
-   if (!err && read_seqcount_retry(>so_reclaim_seqcount, seq))
+   if (!err && read_seqretry(>so_reclaim_seqlock, seq))
err = -EAGAIN;
mutex_unlock(>so_delegreturn_mutex);
put_nfs_open_context(ctx);
diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
index 9b3a82abab07..9b5089bf0f2e 100644
--- a/fs/nfs/nfs4_fs.h
+++ b/fs/nfs/nfs4_fs.h
@@ -111,7 +111,7 @@ struct nfs4_state_owner {
unsigned longso_flags;
struct list_head so_states;
struct nfs_seqid_counter so_seqid;
-   seqcount_t   so_reclaim_seqcount;
+   seqlock_tso_reclaim_seqlock;
struct mutex so_delegreturn_mutex;
 };
 
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index ad917bd72b38..3d6be8405c08 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2685,7 +2685,7 @@ static int _nfs4_open_and_get_state(struct nfs4_opendata 
*opendata,
unsigned int seq;
int ret;
 
-   seq = raw_seqcount_begin(>so_reclaim_seqcount);
+   seq = raw_seqcount_begin(>so_reclaim_seqlock.seqcount);
 
ret = _nfs4_proc_open(opendata);
if (ret != 0)
@@ -2723,7 +2723,7 @@ static int _nfs4_open_and_get_state(struct nfs4_opendata 
*opendata,
ctx->state = state;
if (d_inode(dentry) == state->inode) {
nfs_inode_attach_open_context(ctx);
-   if (read_seqcount_retry(>so_reclaim_seqcount, seq))
+   if (read_seqretry(>so_reclaim_seqlock, seq))
nfs4_schedule_stateid_recovery(server, state);
}
 out:
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 5f4281ec5f72..74be6378ca08 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -488,7 +488,7 @@ nfs4_alloc_state_owner(struct nfs_server *server,
nfs4_init_seqid_counter(>so_seqid);
atomic_set(>so_count, 1);
INIT_LIST_HEAD(>so_lru);
-   

Re: [PATCH V2 0/8] PM / OPP: Multiple regulator support

[Viresh Kumar]

On 21 October 2016 at 19:09, Rafael J. Wysocki  wrote:
> On Thu, Oct 20, 2016 at 10:44 AM, Viresh Kumar  
> wrote:
>> Hi,
>>
>> Some platforms (like TI) have complex DVFS configuration for CPU
>> devices, where multiple regulators are required to be configured to
>> change DVFS state of the device. This was explained well by Nishanth
>> earlier [1].
>>
>> Some thoughts went into it few months back but then it all got lost. I
>> am trying to get that back on track with this thread.
>>
>> One of the major complaints around multiple regulators case was that the
>> DT isn't responsible in any way to represent the ordering in which
>> multiple supplies need to be programmed, before or after frequency
>> change. It was considered in this patch and such information is left to
>> the platform specific OPP driver now, which can register its own
>> opp_set_rate() callback with the OPP core and the OPP core will then
>> call it during DVFS.
>>
>> The patches are tested on Exynos5250 (Dual A15). I have hacked around DT
>> and code to pass values for multiple regulators and verified that they
>> are all properly read by the kernel (using debugfs interface).
>>
>> Though more testing on real (TI) platforms would be useful.
>>
>> This is rebased over: linux-next branch in the PM tree.
>>
>> V1->V2:
>> - Ack from Rob for 1st patch
>> - Moved the supplies structure to pm_opp.h (Dave)
>> - Fixed an compilation warning.
>
> I need somebody from the OPP camp to review patches [2-8/8] for me.

Sure, I have already asked Stephen yesterday to do that.

--
viresh

Re: 4.9-rc1 boot regression, ambiguous bisect result

[Matt Fleming]

On Thu, 20 Oct, at 12:37:16PM, Dan Williams wrote:
> 
> I am able to build a kernel and boot the platform with the following
> set of reverts:
> 
>   Revert "x86/efi: Round EFI memmap reservations to EFI_PAGE_SIZE"
>   Revert "x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data"
>   Revert "efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()"
>   Revert "efi: Allow drivers to reserve boot services forever"

FYI, I've been able to reproduce some crash when using your EFI memory
map layout under Qemu and forcing the ESRT driver to reserve the space.

It looks like the new EFI memmap we allocate as part of the
reservation is smaller than the old one - which is backwards.

Still debugging...

[PATCH] flow_dissector: avoid uninitialized variable access

[Arnd Bergmann]

gcc warns about an uninitialized pointer dereference in the vlan
priority handling:

net/core/flow_dissector.c: In function '__skb_flow_dissect':
net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]

>From all I can tell, this warning is about a real bug, and we
should not attempt look up the vlan header if there was
no vlan tag.

Fixes: f6a66927692e ("flow_dissector: Get vlan priority in addition to vlan id")
Signed-off-by: Arnd Bergmann 
---
I'm not sure about this one, please have a closer look at what
the original code does before applying.
---
 net/core/flow_dissector.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 44e6ba9d3a6b..dd6003bf27e1 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -245,7 +245,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
}
case htons(ETH_P_8021AD):
case htons(ETH_P_8021Q): {
-   const struct vlan_hdr *vlan;
+   const struct vlan_hdr *vlan = NULL;
 
if (skb && skb_vlan_tag_present(skb))
proto = skb->protocol;
@@ -264,7 +264,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
}
 
skip_vlan = true;
-   if (dissector_uses_key(flow_dissector,
+   if (vlan && dissector_uses_key(flow_dissector,
   FLOW_DISSECTOR_KEY_VLAN)) {
key_vlan = skb_flow_dissector_target(flow_dissector,
 
FLOW_DISSECTOR_KEY_VLAN,
-- 
2.9.0

[GIT PULL] Block fixes for 4.9-rc

[Jens Axboe]

Hi Linus,

A set of fixes that missed the merge window, mostly due to me being away
around that time. Nothing major here, a mix of nvme cleanups and fixes,
and one fix for the badblocks handling.

Please pull!


  git://git.kernel.dk/linux-block.git for-linus



Christoph Hellwig (5):
  nvme.h: resync with nvme-cli
  nvme.h: don't use uuid_be
  nvme.h: add an enum for cns values
  nvme: use symbolic constants for CNS values
  nvmet: use symbolic constants for CNS values

Gabriel Krisman Bertazi (1):
  nvme: Add tertiary number to NVME_VS

Keith Busch (3):
  nvme: Stop probing a removed device
  nvme: Delete created IO queues on reset
  nvme: don't schedule multiple resets

Stephen Bates (1):
  nvme : Add sysfs entry for NVMe CMBs when appropriate

Tomasz Majchrzak (1):
  badblocks: fix overlapping check for clearing

 block/badblocks.c   |  6 ++--
 drivers/nvme/host/core.c| 14 
 drivers/nvme/host/pci.c | 77 
+

 drivers/nvme/host/scsi.c|  4 +--
 drivers/nvme/target/admin-cmd.c |  8 ++---
 drivers/nvme/target/core.c  |  2 +-
 drivers/nvme/target/discovery.c |  4 +--
 include/linux/nvme.h| 49 +-
 8 files changed, 115 insertions(+), 49 deletions(-)

--
Jens Axboe

Re: [PATCH] flow_dissector: avoid uninitialized variable access

[Jiri Pirko]

Fri, Oct 21, 2016 at 05:55:53PM CEST, a...@arndb.de wrote:
>gcc warns about an uninitialized pointer dereference in the vlan
>priority handling:
>
>net/core/flow_dissector.c: In function '__skb_flow_dissect':
>net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in 
>this function [-Werror=maybe-uninitialized]
>
>From all I can tell, this warning is about a real bug, and we
>should not attempt look up the vlan header if there was
>no vlan tag.

I don't see how vlan could be used uninitialized. But I understand that
this is impossible for gcc to track it. Please just use uninitialized_var()



>
>Fixes: f6a66927692e ("flow_dissector: Get vlan priority in addition to vlan 
>id")
>Signed-off-by: Arnd Bergmann 
>---
>I'm not sure about this one, please have a closer look at what
>the original code does before applying.
>---
> net/core/flow_dissector.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>index 44e6ba9d3a6b..dd6003bf27e1 100644
>--- a/net/core/flow_dissector.c
>+++ b/net/core/flow_dissector.c
>@@ -245,7 +245,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>   }
>   case htons(ETH_P_8021AD):
>   case htons(ETH_P_8021Q): {
>-  const struct vlan_hdr *vlan;
>+  const struct vlan_hdr *vlan = NULL;
> 
>   if (skb && skb_vlan_tag_present(skb))
>   proto = skb->protocol;
>@@ -264,7 +264,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
>   }
> 
>   skip_vlan = true;
>-  if (dissector_uses_key(flow_dissector,
>+  if (vlan && dissector_uses_key(flow_dissector,
>  FLOW_DISSECTOR_KEY_VLAN)) {
>   key_vlan = skb_flow_dissector_target(flow_dissector,
>
> FLOW_DISSECTOR_KEY_VLAN,
>-- 
>2.9.0
>

Re: [PATCH 1/5] ftrace: Support full glob matching

[Masami Hiramatsu]

On Thu, 20 Oct 2016 09:43:20 -0400
Steven Rostedt  wrote:

> On Thu, 20 Oct 2016 11:07:52 +0900
> Masami Hiramatsu  wrote:
> 
> 
> > And OK, what kind of tests are failed on 4.9-rc1? I though a possible
> > kernel freeze in 4.8 when I ran ftracetest, but it seemed disappeared
> > in 4.9-rc1.
> 
> The kernel crashed on enabling the mmiotracer, which disables CPUs.
> That tracer is notorious for finding CPU hotplug bugs. There's a fix in
> tip/urgent that I pulled in, which lets it pass. I rather wait till rc2
> to base changes on where I don't need to add commits to make my tests
> pass.

Ah, I think this should same as what I hit :)
I've tested this series on tip/master, so it was fixed at that point.

Thanks,

-- 
Masami Hiramatsu 

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use __sg_alloc_table_from_pages for allocating object backing store

[Tvrtko Ursulin]

On 21/10/2016 15:27, Chris Wilson wrote:

On Fri, Oct 21, 2016 at 03:11:22PM +0100, Tvrtko Ursulin wrote:

@@ -2236,18 +2233,16 @@ i915_gem_object_get_pages_gtt(struct 
drm_i915_gem_object *obj)
BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);

-   max_segment = swiotlb_max_size();
-   if (!max_segment)
-   max_segment = rounddown(UINT_MAX, PAGE_SIZE);
-
-   st = kmalloc(sizeof(*st), GFP_KERNEL);
-   if (st == NULL)
-   return -ENOMEM;
-
page_count = obj->base.size / PAGE_SIZE;
-   if (sg_alloc_table(st, page_count, GFP_KERNEL)) {
-   kfree(st);
+   pages = drm_malloc_gfp(page_count, sizeof(struct page *),
+  GFP_TEMPORARY | __GFP_ZERO);
+   if (!pages)
return -ENOMEM;


Full circle! The whole reason this exists was to avoid that vmalloc. I
don't really want it back...


Yes, it is not ideal.

However all objects under 4 MiB should fall under the kmalloc fast path 
(8 KiB of struct page pointers, which should always be available), and 
possibly bigger ones as well if there is room.


It only fallbacks to vmalloc for objects larger than 4 MiB, when it also 
fails to get the page pointer array from the SLAB (GFP_TEMPORARY).


So perhaps SLAB would most of the time have some nice chunks for us to 
pretty much limit vmalloc apart for the huge objects? And then, is 
creation time for those so performance critical?


I came up with this because I started to dislike my previous 
sg_trim_table approach as too ugly. It had an advantage of simplicity 
after fixing the theoretical chunk overflow in sg_alloc_table_from_pages.


If we choose none of the two, only third option I can think of is to 
allocate the sg table as we add entries to it. I don't think it would be 
hard to do that.


Regards,

Tvrtko

Re: [PATCH 02/26] fscrypto: Constify struct inode pointer

[Theodore Ts'o]

On Fri, Oct 21, 2016 at 02:48:17PM +0200, Richard Weinberger wrote:
> Some filesystems, such as UBIFS, maintain a const pointer
> for struct inode.
> 
>  /* fname.c */
> -extern int fscrypt_setup_filename(struct inode *, const struct qstr *,
> - int lookup, struct fscrypt_name *);
> +extern int fscrypt_setup_filename(struct inode *dir, const struct qstr 
> *iname,
> +int lookup, struct fscrypt_name *fname);

Was it deliberate that you didn't add a const pointer here?

I take it that ubifs is basically using const in certain places to
essentially promise that those functions don't actually modify the
inode structure?

- Ted

Re: [PATCH] net: sched: make default fifo qdiscs appear in the dump

[David Miller]

From: Jiri Kosina 
Date: Fri, 21 Oct 2016 14:56:33 +0200 (CEST)

> I'd really like to unhide the default qdiscs, it makes little sense to be 
> inconsistent in this way.

Something that's been invisible for such a long time... there is no
way applications need or require this.

If some new ones do, they can ask for it via the netlink request
inside of a new netlink attribute or similar.

That makes everyone happy.

[PATCH 07/12] ko_KR/HOWTO: Update information about generating documentation

[SeongJae Park]

This commit applies commit 43fb67a5258c ("Documentation/HOWTO: update
information about generating documentation") to Korean translation.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 30 ++
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index a8991333790f..f1e2c4718aad 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -176,21 +176,35 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 패치가 무엇이며 그것을 커널의 다른 개발 브랜치들에 어떻게
 적용하는지에 관하여 자세히 설명하고 있는 좋은 입문서이다.
 
-커널은 소스 코드 그 자체에서 자동적으로 만들어질 수 있는 많은 문서들을
-가지고 있다. 이것은 커널 내의 API에 대한 모든 설명, 그리고 락킹을
-올바르게 처리하는 법에 관한 규칙을 포함하고 있다. 이 문서는
-Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, HTML,
-그리고 man 페이지들로 다음과 같이 실행하여 만들어 진다.
+커널은 소스 코드 그 자체에서 또는 이것과 같은 ReStructuredText 마크업 (ReST) 을
+통해 자동적으로 만들어질 수 있는 많은 문서들을 가지고 있다. 이것은 커널 내의
+API에 대한 모든 설명, 그리고 락킹을 올바르게 처리하는 법에 관한 규칙을 포함하고
+있다.
+
+모든 그런 문서들은 커널 소스 디렉토리에서 다음 커맨드를 실행하는 것을 통해 PDF
+나 HTML 의 형태로 만들어질 수 있다.
 
 ::
 
  make pdfdocs
- make psdocs
  make htmldocs
- make mandocs
 
-각각의 명령을 메인 커널 소스 디렉토리로부터 실행한다.
+ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된다.  해당
+문서들은 다음의 커맨드를 사용하면 LaTeX 이나 ePub 로도 만들어질 수 있다:
+
+::
+
+ make latexdocs
+ make epubdocs
+
+현재, ReST 로의 변환이 진행중인, DocBook 으로 쓰인 문서들이 존재한다. 그런
+문서들은 Documentation/DocBook/ 디렉토리 안에 생성될 것이고 다음 커맨드를 통해
+Postscript 나 man page 로도 만들어질 수 있다:
+
+::
 
+ make psdocs
+ make mandocs
 
 커널 개발자가 되는 것
 -
-- 
2.10.0

[PATCH 08/12] ko_KR/HOWTO: Improve some markups to make it visually better

[SeongJae Park]

This commit applies commit 34fed7e7e0e5 ("Documentation/HOWTO: improve
some markups to make it visually better") to Korean translation.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index f1e2c4718aad..19a19c5baa72 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -295,11 +295,9 @@ Postscript 나 man page 로도 만들어질 수 있다:
 커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의
 Andrew Morton의 글이 있다.
 
-::
-
-"커널이 언제 배포될지는 아무도 모른다. 왜냐하면 배포는 알려진
+*"커널이 언제 배포될지는 아무도 모른다. 왜냐하면 배포는 알려진
  버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라
- 배포되는 것은 아니기 때문이다."
+ 배포되는 것은 아니기 때문이다."*
 
 4.x.y - 안정 커널 트리
 --
@@ -569,16 +567,14 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
 
 여기에 커널 개발자 Al Viro의 이야기가 있다.
 
-::
-
-"학생의 수학 숙제를 채점하는 선생님을 생각해보라. 선생님은 학생들이
+*"학생의 수학 숙제를 채점하는 선생님을 생각해보라. 선생님은 학생들이
 답을 얻을때까지 겪은 시행착오를 보길 원하지 않는다. 선생님들은
 간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고
-마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다.
+마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다.*
 
-커널 개발도 마찬가지이다. 메인테이너들과 검토하는 사람들은 문제를
+*커널 개발도 마찬가지이다. 메인테이너들과 검토하는 사람들은 문제를
 풀어나가는 과정속에 숨겨진 과정을 보길 원하진 않는다. 그들은
-간결하고 멋진 답을 보길 원한다."
+간결하고 멋진 답을 보길 원한다."*
 
 커뮤니티와 협력하며 뛰어난 답을 찾는 것과 여러분들의 끝마치지 못한 작업들
 사이에 균형을 유지해야 하는 것은 어려울지도 모른다. 그러므로 프로세스의
-- 
2.10.0

[PATCH] clk: fix link error for rcar-gen2

[Arnd Bergmann]

The addition of one more rcar-gen2 based SoC caused a build error (again)
in my randconfig builds:

arch/arm/mach-shmobile/setup-rcar-gen2.o: In function `rcar_gen2_timer_init':
setup-rcar-gen2.c:(.init.text+0x200): undefined reference to 
`rcar_gen2_clocks_init'

I think this has happened twice in the past. Instead of adding each SoC
one at a time, this changes the existing list to always build the
rcar-gen2 related clk files whenever the generic symbol is selected.

Fixes: 1254f607fc3d ("ARM: shmobile: r8a7743: basic SoC support")
Signed-off-by: Arnd Bergmann 
---
 drivers/clk/renesas/Makefile | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index 90dd0db7d9c6..762d122eddec 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -4,11 +4,7 @@ obj-$(CONFIG_ARCH_R8A73A4) += clk-r8a73a4.o 
clk-div6.o
 obj-$(CONFIG_ARCH_R8A7740) += clk-r8a7740.o clk-div6.o
 obj-$(CONFIG_ARCH_R8A7778) += clk-r8a7778.o
 obj-$(CONFIG_ARCH_R8A7779) += clk-r8a7779.o
-obj-$(CONFIG_ARCH_R8A7790) += clk-rcar-gen2.o clk-div6.o
-obj-$(CONFIG_ARCH_R8A7791) += clk-rcar-gen2.o clk-div6.o
-obj-$(CONFIG_ARCH_R8A7792) += clk-rcar-gen2.o clk-div6.o
-obj-$(CONFIG_ARCH_R8A7793) += clk-rcar-gen2.o clk-div6.o
-obj-$(CONFIG_ARCH_R8A7794) += clk-rcar-gen2.o clk-div6.o
+obj-$(CONFIG_ARCH_RCAR_GEN2)   += clk-rcar-gen2.o clk-div6.o
 obj-$(CONFIG_ARCH_R8A7795) += r8a7795-cpg-mssr.o rcar-gen3-cpg.o
 obj-$(CONFIG_ARCH_R8A7796) += r8a7796-cpg-mssr.o rcar-gen3-cpg.o
 obj-$(CONFIG_ARCH_SH73A0)  += clk-sh73a0.o clk-div6.o
-- 
2.9.0

Re: [PATCH 2/2] sched: do not call workqueue sleep hook if task is already dead

[Oleg Nesterov]

On 10/20, Andy Lutomirski wrote:
>
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -3380,8 +3380,22 @@ static void __sched notrace __schedule(bool preempt)
> >  * If a worker went to sleep, notify and ask 
> > workqueue
> >  * whether it wants to wake up a task to maintain
> >  * concurrency.
> > +*
> > +* Also the following stack is possible:
> > +*oops_end()
> > +*do_exit()
> > +*schedule()
> > +*
> > +* If panic_on_oops is not set and oops happens on
> > +* a workqueue execution path, thread will be 
> > killed.
> > +* That is definitly sad, but not to make the 
> > situation
> > +* even worse we have to ignore dead tasks in order 
> > not
> > +* to step on zeroed out members (e.g. 
> > t->vfork_done is
> > +* already NULL on that path, since we were called 
> > by
> > +* do_exit()))

And we have more problems like this. Say, if blk_flush_plug_list()
crashes it will likely crash again and again recursively.

> >  */
> > -   if (prev->flags & PF_WQ_WORKER) {
> > +   if (prev->flags & PF_WQ_WORKER &&
> > +   prev->state != TASK_DEAD) {

I don't think we should change __schedule()... Can't we simply clear
PF_WQ_WORKER in complete_vfork_done() ? Or add the PF_EXITING checks
into wq_worker_sleeping() and wq_worker_waking_up().

Or perhaps something like the change below.

Oleg.

--- x/kernel/workqueue.c
+++ x/kernel/workqueue.c
@@ -2157,6 +2157,14 @@ static void process_scheduled_works(stru
}
 }
 
+static void oops_handler(struct callback_head *oops_work)
+{
+   if (!(current->flags & PF_WQ_WORKER))
+   return;
+
+   clear PF_WQ_WORKER, probably do more cleanups
+}
+
 /**
  * worker_thread - the worker thread function
  * @__worker: self
@@ -2171,11 +2179,14 @@ static void process_scheduled_works(stru
  */
 static int worker_thread(void *__worker)
 {
+   struct callback_head oops_work;
struct worker *worker = __worker;
struct worker_pool *pool = worker->pool;
 
/* tell the scheduler that this is a workqueue worker */
worker->task->flags |= PF_WQ_WORKER;
+   init_task_work(_work, oops_handler);
+   task_work_add(current, _work, false);
 woke_up:
spin_lock_irq(>lock);
 

Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

[Philipp Zabel]

Am Freitag, den 21.10.2016, 17:45 +0200 schrieb Philipp Zabel:
>  A. Hi Geert,
> 
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> > Hi Philipp, Mike, Stephen, Simon, Magnus,
> > (see questions *** below!)
> > 
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> > 
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> > 
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module.  Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
> 
> I think you should add a binding doc even though the DT bindings are
> still trivial.

Disregard that, I literally sent this mail and a second later noticed
patch 1 for the first time.

regards
Philipp

Re: [PATCH net] net: remove MTU limits on a few ether_setup callers

[Jarod Wilson]

On Fri, Oct 21, 2016 at 10:44:41AM +0200, Andrew Lunn wrote:
> On Thu, Oct 20, 2016 at 08:42:46PM -0700, Florian Fainelli wrote:
> > Le 20/10/2016 à 20:25, Jarod Wilson a écrit :
> > > These few drivers call ether_setup(), but have no ndo_change_mtu, and thus
> > > were overlooked for changes to MTU range checking behavior. They
> > > previously had no range checks, so for feature-parity, set their min_mtu
> > > to 0 and max_mtu to ETH_MAX_MTU (65535), instead of the 68 and 1500
> > > inherited from the ether_setup() changes. Fine-tuning can come after we 
> > > get
> > > back to full feature-parity here.
> > > 
> > > CC: net...@vger.kernel.org
> > > Reported-by: Asbjoern Sloth Toennesen 
> > > CC: Asbjoern Sloth Toennesen 
> > > CC: R Parameswaran 
> > > Signed-off-by: Jarod Wilson 
> > > ---
> > 
> > > diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> > > index 68714a5..d0c7bce 100644
> > > --- a/net/dsa/slave.c
> > > +++ b/net/dsa/slave.c
> > > @@ -1247,6 +1247,8 @@ int dsa_slave_create(struct dsa_switch *ds, struct 
> > > device *parent,
> > >   slave_dev->priv_flags |= IFF_NO_QUEUE;
> > >   slave_dev->netdev_ops = _slave_netdev_ops;
> > >   slave_dev->switchdev_ops = _slave_switchdev_ops;
> > > + slave_dev->min_mtu = 0;
> > > + slave_dev->max_mtu = ETH_MAX_MTU;
> > >   SET_NETDEV_DEVTYPE(slave_dev, _type);
> > 
> > Actually for DSA, a reasonable minimum is probably 68 for the following
> > reasons: ETH_ZLEN of 60 bytes + FCS (4 bytes) + 2/4/8 bytes of
> > Ethernet switch tag (which is dependent on the tagging protocol
> > used).
> 
> Humm, isn't the switch tag added by the layer below this? So this
> should be - 2/4/8 bytes, so that the assembled frame that actually
> hits the conduit interface has an MTU of 64.

I'm all for fine-tuning things to be more correct, but my initial approach
here was to restore the ranges that were previously there, and DSA had no
upper or lower bounds checks. I'm not at all familiar with DSA either way.

> > Such an Ethernet interface would submit packets through the conduit
> > interface which is connected to an Ethernet switches, and those
> > typically discard packets smaller than 64 bytes +/- their custom tag
> > length.
> 
> I have a purely theoretical observation, i.e. i have not checked the
> datasheets. You can also control some of the Marvell switches by
> sending it ethernet frames containing commands. Most commands are 4
> bytes long. So an Ethernet header + 4 bytes is < 64. I expect the
> switch will accept command frames which are padded to stop them being
> runts. Also, such frames will be submitted to the conduit interface,
> not the slave interface.

So presumably, slave_dev->min_mtu wouldn't come into play in that
scenario, and we wouldn't break that functionality if min_mtu did get get
to 64 or 68 or whatever > 0.

-- 
Jarod Wilson
ja...@redhat.com