Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support

[Jan Kara]

On Mon 03-10-16 15:05:57, Ross Zwisler wrote:
> > > @@ -623,22 +672,30 @@ static void *dax_insert_mapping_entry(struct 
> > > address_space *mapping,
> > >   error = radix_tree_preload(vmf->gfp_mask & ~__GFP_HIGHMEM);
> > >   if (error)
> > >   return ERR_PTR(error);
> > > + } else if ((unsigned long)entry & RADIX_DAX_HZP && !hzp) {
> > > + /* replacing huge zero page with PMD block mapping */
> > > + unmap_mapping_range(mapping,
> > > + (vmf->pgoff << PAGE_SHIFT) & PMD_MASK, PMD_SIZE, 0);
> > >   }
> > >  
> > >   spin_lock_irq(>tree_lock);
> > > - new_entry = (void *)((unsigned long)RADIX_DAX_ENTRY(sector, false) |
> > > -RADIX_DAX_ENTRY_LOCK);
> > > + if (hzp)
> > > + new_entry = RADIX_DAX_HZP_ENTRY();
> > > + else
> > > + new_entry = RADIX_DAX_ENTRY(sector, new_type);
> > > +
> > >   if (hole_fill) {
> > >   __delete_from_page_cache(entry, NULL);
> > >   /* Drop pagecache reference */
> > >   put_page(entry);
> > > - error = radix_tree_insert(page_tree, index, new_entry);
> > > + error = __radix_tree_insert(page_tree, index,
> > > + RADIX_DAX_ORDER(new_type), new_entry);
> > >   if (error) {
> > >   new_entry = ERR_PTR(error);
> > >   goto unlock;
> > >   }
> > >   mapping->nrexceptional++;
> > > - } else {
> > > + } else if ((unsigned long)entry & (RADIX_DAX_HZP|RADIX_DAX_EMPTY)) {
> > >   void **slot;
> > >   void *ret;
> > 
> > Hum, I somewhat dislike how PTE and PMD paths differ here. But it's OK for
> > now I guess. Long term we might be better off to do away with zero pages
> > for PTEs as well and use exceptional entry and a single zero page like you
> > do for PMD. Because the special cases these zero pages cause are a
> > headache.
> 
> I've been thinking about this as well, and I do think we'd be better off with
> a single zero page for PTEs, as we have with PMDs.  It'd reduce the special
> casing in the DAX code, and it'd also ensure that we don't waste a bunch of
> time and memory creating read-only zero pages to service reads from holes.
> 
> I'll look into adding this for v5.

Well, this would clash with the dirty bit cleaning series I have. So I'd
prefer to put this on a todo list and address it once existing series are
integrated...

> > > + if (error)
> > > + goto fallback;
> > > + if (iomap.offset + iomap.length < pos + PMD_SIZE)
> > > + goto fallback;
> > > +
> > > + vmf.pgoff = pgoff;
> > > + vmf.flags = flags;
> > > + vmf.gfp_mask = mapping_gfp_mask(mapping) | __GFP_FS | __GFP_IO;
> > 
> > I don't think you want __GFP_FS here - we have already gone through the
> > filesystem's pmd_fault() handler which called dax_iomap_pmd_fault() and
> > thus we hold various fs locks, freeze protection, ...
> 
> I copied this from __get_fault_gfp_mask() in mm/memory.c.  That function is
> used by do_page_mkwrite() and __do_fault(), and we eventually get this
> vmf->gfp_mask in the PTE fault code.  With the code as it is we get the same
> vmf->gfp_mask in both dax_iomap_fault() and dax_iomap_pmd_fault().  It seems
> like they should remain consistent - is it wrong to have __GFP_FS in
> dax_iomap_fault()?

The gfp_mask that propagates from __do_fault() or do_page_mkwrite() is fine
because at that point it is correct. But once we grab filesystem locks
which are not reclaim safe, we should update vmf->gfp_mask we pass further
down into DAX code to not contain __GFP_FS (that's a bug we apparently have
there). And inside DAX code, we definitely are not generally safe to add
__GFP_FS to mapping_gfp_mask(). Maybe we'd be better off propagating struct
vm_fault into this function, using passed gfp_mask there and make sure
callers update gfp_mask as appropriate.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support

[Jan Kara]

On Mon 03-10-16 15:05:57, Ross Zwisler wrote:
> > > @@ -623,22 +672,30 @@ static void *dax_insert_mapping_entry(struct 
> > > address_space *mapping,
> > >   error = radix_tree_preload(vmf->gfp_mask & ~__GFP_HIGHMEM);
> > >   if (error)
> > >   return ERR_PTR(error);
> > > + } else if ((unsigned long)entry & RADIX_DAX_HZP && !hzp) {
> > > + /* replacing huge zero page with PMD block mapping */
> > > + unmap_mapping_range(mapping,
> > > + (vmf->pgoff << PAGE_SHIFT) & PMD_MASK, PMD_SIZE, 0);
> > >   }
> > >  
> > >   spin_lock_irq(>tree_lock);
> > > - new_entry = (void *)((unsigned long)RADIX_DAX_ENTRY(sector, false) |
> > > -RADIX_DAX_ENTRY_LOCK);
> > > + if (hzp)
> > > + new_entry = RADIX_DAX_HZP_ENTRY();
> > > + else
> > > + new_entry = RADIX_DAX_ENTRY(sector, new_type);
> > > +
> > >   if (hole_fill) {
> > >   __delete_from_page_cache(entry, NULL);
> > >   /* Drop pagecache reference */
> > >   put_page(entry);
> > > - error = radix_tree_insert(page_tree, index, new_entry);
> > > + error = __radix_tree_insert(page_tree, index,
> > > + RADIX_DAX_ORDER(new_type), new_entry);
> > >   if (error) {
> > >   new_entry = ERR_PTR(error);
> > >   goto unlock;
> > >   }
> > >   mapping->nrexceptional++;
> > > - } else {
> > > + } else if ((unsigned long)entry & (RADIX_DAX_HZP|RADIX_DAX_EMPTY)) {
> > >   void **slot;
> > >   void *ret;
> > 
> > Hum, I somewhat dislike how PTE and PMD paths differ here. But it's OK for
> > now I guess. Long term we might be better off to do away with zero pages
> > for PTEs as well and use exceptional entry and a single zero page like you
> > do for PMD. Because the special cases these zero pages cause are a
> > headache.
> 
> I've been thinking about this as well, and I do think we'd be better off with
> a single zero page for PTEs, as we have with PMDs.  It'd reduce the special
> casing in the DAX code, and it'd also ensure that we don't waste a bunch of
> time and memory creating read-only zero pages to service reads from holes.
> 
> I'll look into adding this for v5.

Well, this would clash with the dirty bit cleaning series I have. So I'd
prefer to put this on a todo list and address it once existing series are
integrated...

> > > + if (error)
> > > + goto fallback;
> > > + if (iomap.offset + iomap.length < pos + PMD_SIZE)
> > > + goto fallback;
> > > +
> > > + vmf.pgoff = pgoff;
> > > + vmf.flags = flags;
> > > + vmf.gfp_mask = mapping_gfp_mask(mapping) | __GFP_FS | __GFP_IO;
> > 
> > I don't think you want __GFP_FS here - we have already gone through the
> > filesystem's pmd_fault() handler which called dax_iomap_pmd_fault() and
> > thus we hold various fs locks, freeze protection, ...
> 
> I copied this from __get_fault_gfp_mask() in mm/memory.c.  That function is
> used by do_page_mkwrite() and __do_fault(), and we eventually get this
> vmf->gfp_mask in the PTE fault code.  With the code as it is we get the same
> vmf->gfp_mask in both dax_iomap_fault() and dax_iomap_pmd_fault().  It seems
> like they should remain consistent - is it wrong to have __GFP_FS in
> dax_iomap_fault()?

The gfp_mask that propagates from __do_fault() or do_page_mkwrite() is fine
because at that point it is correct. But once we grab filesystem locks
which are not reclaim safe, we should update vmf->gfp_mask we pass further
down into DAX code to not contain __GFP_FS (that's a bug we apparently have
there). And inside DAX code, we definitely are not generally safe to add
__GFP_FS to mapping_gfp_mask(). Maybe we'd be better off propagating struct
vm_fault into this function, using passed gfp_mask there and make sure
callers update gfp_mask as appropriate.

Honza
-- 
Jan Kara 
SUSE Labs, CR

[PATCH v2] phy: micrel.c: Enable ksz9031 energy-detect power-down mode

[Mike Looijmans]

Set bit 0 in register 1C.23 to enable the EDPD feature of the
KSZ9031 PHY. This reduces power consumption when the link is
down.

Signed-off-by: Mike Looijmans 
---
v2: Unconditionally enable EDPD mode

 drivers/net/phy/micrel.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 885ac9c..081df68 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -439,6 +439,10 @@ static int ksz9021_config_init(struct phy_device *phydev)
 #define MII_KSZ9031RN_TX_DATA_PAD_SKEW 6
 #define MII_KSZ9031RN_CLK_PAD_SKEW 8
 
+/* MMD Address 0x1C */
+#define MII_KSZ9031RN_EDPD 0x23
+#define MII_KSZ9031RN_EDPD_ENABLE  BIT(0)
+
 static int ksz9031_extended_write(struct phy_device *phydev,
  u8 mode, u32 dev_addr, u32 regnum, u16 val)
 {
@@ -510,6 +514,18 @@ static int ksz9031_center_flp_timing(struct phy_device 
*phydev)
return genphy_restart_aneg(phydev);
 }
 
+/* Enable energy-detect power-down mode */
+static int ksz9031_enable_edpd(struct phy_device *phydev)
+{
+   int reg;
+
+   reg = ksz9031_extended_read(phydev, OP_DATA, 0x1C, MII_KSZ9031RN_EDPD);
+   if (reg < 0)
+   return reg;
+   return ksz9031_extended_write(phydev, OP_DATA, 0x1C, MII_KSZ9031RN_EDPD,
+ reg | MII_KSZ9031RN_EDPD_ENABLE);
+}
+
 static int ksz9031_config_init(struct phy_device *phydev)
 {
const struct device *dev = >mdio.dev;
@@ -525,6 +541,11 @@ static int ksz9031_config_init(struct phy_device *phydev)
};
static const char *control_skews[2] = {"txen-skew-ps", "rxdv-skew-ps"};
const struct device *dev_walker;
+   int result;
+
+   result = ksz9031_enable_edpd(phydev);
+   if (result < 0)
+   return result;
 
/* The Micrel driver has a deprecated option to place phy OF
 * properties in the MAC node. Walk up the tree of devices to
-- 
1.9.1

[PATCH v2] phy: micrel.c: Enable ksz9031 energy-detect power-down mode

[Mike Looijmans]

Set bit 0 in register 1C.23 to enable the EDPD feature of the
KSZ9031 PHY. This reduces power consumption when the link is
down.

Signed-off-by: Mike Looijmans 
---
v2: Unconditionally enable EDPD mode

 drivers/net/phy/micrel.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 885ac9c..081df68 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -439,6 +439,10 @@ static int ksz9021_config_init(struct phy_device *phydev)
 #define MII_KSZ9031RN_TX_DATA_PAD_SKEW 6
 #define MII_KSZ9031RN_CLK_PAD_SKEW 8
 
+/* MMD Address 0x1C */
+#define MII_KSZ9031RN_EDPD 0x23
+#define MII_KSZ9031RN_EDPD_ENABLE  BIT(0)
+
 static int ksz9031_extended_write(struct phy_device *phydev,
  u8 mode, u32 dev_addr, u32 regnum, u16 val)
 {
@@ -510,6 +514,18 @@ static int ksz9031_center_flp_timing(struct phy_device 
*phydev)
return genphy_restart_aneg(phydev);
 }
 
+/* Enable energy-detect power-down mode */
+static int ksz9031_enable_edpd(struct phy_device *phydev)
+{
+   int reg;
+
+   reg = ksz9031_extended_read(phydev, OP_DATA, 0x1C, MII_KSZ9031RN_EDPD);
+   if (reg < 0)
+   return reg;
+   return ksz9031_extended_write(phydev, OP_DATA, 0x1C, MII_KSZ9031RN_EDPD,
+ reg | MII_KSZ9031RN_EDPD_ENABLE);
+}
+
 static int ksz9031_config_init(struct phy_device *phydev)
 {
const struct device *dev = >mdio.dev;
@@ -525,6 +541,11 @@ static int ksz9031_config_init(struct phy_device *phydev)
};
static const char *control_skews[2] = {"txen-skew-ps", "rxdv-skew-ps"};
const struct device *dev_walker;
+   int result;
+
+   result = ksz9031_enable_edpd(phydev);
+   if (result < 0)
+   return result;
 
/* The Micrel driver has a deprecated option to place phy OF
 * properties in the MAC node. Walk up the tree of devices to
-- 
1.9.1

[GIT PULL] EDAC queue for 4.9

[Borislav Petkov]

Hi Linus,

a lot of movement in the EDAC tree this time around, coarse changelog
below.

Please pull,
thanks.

---
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_for_4.9

for you to fetch changes up to a29d64a45eed1ee0d4ac90335da79ad1a9a0990d:

  EDAC, altera: Add IRQ Flags to disable IRQ while handling (2016-09-23 
12:03:34 +0200)


* Altera Arria10 enablement of NAND, DMA, USB, QSPI and SD-MMC FIFO
buffers (Thor Thayer)

* Split the memory controller part out of mpc85xx and share it with a
* new Freescale ARM Layerscape driver (York Sun)

* amd64_edac fixes (Yazen Ghannam)

* Misc cleanups, refactoring and fixes all over the place


Bhaktipriya Shridhar (1):
  EDAC, wq: Remove deprecated create_singlethread_workqueue()

Borislav Petkov (3):
  EDAC, I3000: Orphan driver
  EDAC: Move Doug Thompson to CREDITS
  EDAC, fsl_ddr: Add entry to MAINTAINERS

Colin Ian King (1):
  EDAC, sb_edac: Remove NULL pointer check on array pci_tad

Michael Ellerman (1):
  EDAC: Remove NO_IRQ from powerpc-only drivers

Thor Thayer (17):
  Documentation: dt: socfpga: Add Arria10 NAND EDAC binding
  Documentation: dt: socfpga: Add Arria10 DMA EDAC binding
  Documentation: dt: socfpga: Add Arria10 USB EDAC binding
  Documentation: dt: socfpga: Add Arria10 QSPI EDAC binding
  EDAC, altera: Add Arria10 NAND support
  EDAC, altera: Add Arria10 DMA support
  EDAC, altera: Add Arria10 USB support
  EDAC, altera: Add Arria10 QSPI support
  ARM: dts: Add Arria10 DMA EDAC devicetree entry
  ARM: dts: Add Arria10 USB EDAC devicetree entry
  Documentation: dt: socfpga: Add Arria10 SD-MMC EDAC binding
  EDAC, altera: Add Arria10 SD-MMC EDAC support
  ARM: dts: Add Arria10 SD/MMC EDAC devicetree entry
  EDAC, altera: Rename device trigger to common name
  EDAC, altera: Rename MC trigger to common name
  EDAC, altera: Correct EDAC IRQ error message
  EDAC, altera: Add IRQ Flags to disable IRQ while handling

Tillmann Heidsieck (1):
  EDAC, mpc85xx: Fix PCIe error capture

Wei Yongjun (2):
  EDAC, altera: Make a10_eccmgr_ic_ops static
  EDAC, fsl_ddr: Fix error return code in fsl_mc_err_probe()

Yazen Ghannam (2):
  EDAC, amd64: Fix channel decode on Fam15hMod60h systems
  EDAC, amd64: Autoload module using x86_cpu_id

York Sun (9):
  EDAC, mpc85xx: Drop setting/clearing RFXE bit in HID1
  EDAC, mpc85xx: Replace printk() with pr_* format
  EDAC, fsl-ddr: Separate FSL DDR driver from MPC85xx
  EDAC, fsl_ddr: Rename macros and names
  EDAC, fsl_ddr: Add missing DDR DRAM types
  EDAC, fsl_ddr: Add support for little endian
  EDAC, fsl_ddr: Fix IRQ dispose warning when module is removed
  EDAC, layerscape: Add Layerscape EDAC support
  EDAC, fsl_ddr: Replace simple_strtoul() with kstrtoul()

 CREDITS|   8 +
 .../bindings/arm/altera/socfpga-eccmgr.txt |  98 +++
 .../fsl/ddr.txt}   |   2 +
 MAINTAINERS|  15 +-
 arch/arm/boot/dts/socfpga_arria10.dtsi |  16 +
 arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts  |  12 +
 arch/arm64/Kconfig.platforms   |   1 +
 drivers/edac/Kconfig   |  42 ++
 drivers/edac/Makefile  |   8 +-
 drivers/edac/altera_edac.c | 346 ++-
 drivers/edac/altera_edac.h |   6 +-
 drivers/edac/amd64_edac.c  |  24 +-
 drivers/edac/fsl_ddr_edac.c| 633 +++
 drivers/edac/fsl_ddr_edac.h|  79 +++
 drivers/edac/layerscape_edac.c |  73 +++
 drivers/edac/mpc85xx_edac.c| 685 ++---
 drivers/edac/mpc85xx_edac.h|  66 --
 drivers/edac/mv64x60_edac.c|   4 -
 drivers/edac/ppc4xx_edac.c |   4 +-
 drivers/edac/sb_edac.c |   5 +-
 drivers/edac/wq.c  |   2 +-
 21 files changed, 1373 insertions(+), 756 deletions(-)
 rename Documentation/devicetree/bindings/{powerpc/fsl/mem-ctrlr.txt => 
memory-controllers/fsl/ddr.txt} (86%)
 create mode 100644 drivers/edac/fsl_ddr_edac.c
 create mode 100644 drivers/edac/fsl_ddr_edac.h
 create mode 100644 drivers/edac/layerscape_edac.c

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[GIT PULL] EDAC queue for 4.9

[Borislav Petkov]

Hi Linus,

a lot of movement in the EDAC tree this time around, coarse changelog
below.

Please pull,
thanks.

---
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_for_4.9

for you to fetch changes up to a29d64a45eed1ee0d4ac90335da79ad1a9a0990d:

  EDAC, altera: Add IRQ Flags to disable IRQ while handling (2016-09-23 
12:03:34 +0200)


* Altera Arria10 enablement of NAND, DMA, USB, QSPI and SD-MMC FIFO
buffers (Thor Thayer)

* Split the memory controller part out of mpc85xx and share it with a
* new Freescale ARM Layerscape driver (York Sun)

* amd64_edac fixes (Yazen Ghannam)

* Misc cleanups, refactoring and fixes all over the place


Bhaktipriya Shridhar (1):
  EDAC, wq: Remove deprecated create_singlethread_workqueue()

Borislav Petkov (3):
  EDAC, I3000: Orphan driver
  EDAC: Move Doug Thompson to CREDITS
  EDAC, fsl_ddr: Add entry to MAINTAINERS

Colin Ian King (1):
  EDAC, sb_edac: Remove NULL pointer check on array pci_tad

Michael Ellerman (1):
  EDAC: Remove NO_IRQ from powerpc-only drivers

Thor Thayer (17):
  Documentation: dt: socfpga: Add Arria10 NAND EDAC binding
  Documentation: dt: socfpga: Add Arria10 DMA EDAC binding
  Documentation: dt: socfpga: Add Arria10 USB EDAC binding
  Documentation: dt: socfpga: Add Arria10 QSPI EDAC binding
  EDAC, altera: Add Arria10 NAND support
  EDAC, altera: Add Arria10 DMA support
  EDAC, altera: Add Arria10 USB support
  EDAC, altera: Add Arria10 QSPI support
  ARM: dts: Add Arria10 DMA EDAC devicetree entry
  ARM: dts: Add Arria10 USB EDAC devicetree entry
  Documentation: dt: socfpga: Add Arria10 SD-MMC EDAC binding
  EDAC, altera: Add Arria10 SD-MMC EDAC support
  ARM: dts: Add Arria10 SD/MMC EDAC devicetree entry
  EDAC, altera: Rename device trigger to common name
  EDAC, altera: Rename MC trigger to common name
  EDAC, altera: Correct EDAC IRQ error message
  EDAC, altera: Add IRQ Flags to disable IRQ while handling

Tillmann Heidsieck (1):
  EDAC, mpc85xx: Fix PCIe error capture

Wei Yongjun (2):
  EDAC, altera: Make a10_eccmgr_ic_ops static
  EDAC, fsl_ddr: Fix error return code in fsl_mc_err_probe()

Yazen Ghannam (2):
  EDAC, amd64: Fix channel decode on Fam15hMod60h systems
  EDAC, amd64: Autoload module using x86_cpu_id

York Sun (9):
  EDAC, mpc85xx: Drop setting/clearing RFXE bit in HID1
  EDAC, mpc85xx: Replace printk() with pr_* format
  EDAC, fsl-ddr: Separate FSL DDR driver from MPC85xx
  EDAC, fsl_ddr: Rename macros and names
  EDAC, fsl_ddr: Add missing DDR DRAM types
  EDAC, fsl_ddr: Add support for little endian
  EDAC, fsl_ddr: Fix IRQ dispose warning when module is removed
  EDAC, layerscape: Add Layerscape EDAC support
  EDAC, fsl_ddr: Replace simple_strtoul() with kstrtoul()

 CREDITS|   8 +
 .../bindings/arm/altera/socfpga-eccmgr.txt |  98 +++
 .../fsl/ddr.txt}   |   2 +
 MAINTAINERS|  15 +-
 arch/arm/boot/dts/socfpga_arria10.dtsi |  16 +
 arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts  |  12 +
 arch/arm64/Kconfig.platforms   |   1 +
 drivers/edac/Kconfig   |  42 ++
 drivers/edac/Makefile  |   8 +-
 drivers/edac/altera_edac.c | 346 ++-
 drivers/edac/altera_edac.h |   6 +-
 drivers/edac/amd64_edac.c  |  24 +-
 drivers/edac/fsl_ddr_edac.c| 633 +++
 drivers/edac/fsl_ddr_edac.h|  79 +++
 drivers/edac/layerscape_edac.c |  73 +++
 drivers/edac/mpc85xx_edac.c| 685 ++---
 drivers/edac/mpc85xx_edac.h|  66 --
 drivers/edac/mv64x60_edac.c|   4 -
 drivers/edac/ppc4xx_edac.c |   4 +-
 drivers/edac/sb_edac.c |   5 +-
 drivers/edac/wq.c  |   2 +-
 21 files changed, 1373 insertions(+), 756 deletions(-)
 rename Documentation/devicetree/bindings/{powerpc/fsl/mem-ctrlr.txt => 
memory-controllers/fsl/ddr.txt} (86%)
 create mode 100644 drivers/edac/fsl_ddr_edac.c
 create mode 100644 drivers/edac/fsl_ddr_edac.h
 create mode 100644 drivers/edac/layerscape_edac.c

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH 09/12] scsi/ncr5380: Pass hostdata pointer to register polling routines

[Finn Thain]

Pass a NCR5380_hostdata struct pointer to the board-specific routines
instead of a Scsi_Host struct pointer. This reduces pointer chasing in
the PIO and PDMA fast paths. The old way was a mistake because it is
slow and the board-specific code is not concerned with the mid-layer.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.c  | 33 -
 drivers/scsi/NCR5380.h  |  6 +++---
 drivers/scsi/mac_scsi.c | 10 +-
 3 files changed, 24 insertions(+), 25 deletions(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 8e11ab7..3f71556 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -178,7 +178,7 @@ static inline void initialize_SCp(struct scsi_cmnd *cmd)
 
 /**
  * NCR5380_poll_politely2 - wait for two chip register values
- * @instance: controller to poll
+ * @hostdata: host private data
  * @reg1: 5380 register to poll
  * @bit1: Bitmask to check
  * @val1: Expected value
@@ -195,12 +195,11 @@ static inline void initialize_SCp(struct scsi_cmnd *cmd)
  * Returns 0 if either or both event(s) occurred otherwise -ETIMEDOUT.
  */
 
-static int NCR5380_poll_politely2(struct Scsi_Host *instance,
+static int NCR5380_poll_politely2(struct NCR5380_hostdata *hostdata,
   unsigned int reg1, u8 bit1, u8 val1,
   unsigned int reg2, u8 bit2, u8 val2,
   unsigned long wait)
 {
-   struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned long n = hostdata->poll_loops;
unsigned long deadline = jiffies + wait;
 
@@ -561,7 +560,7 @@ static int NCR5380_maybe_reset_bus(struct Scsi_Host 
*instance)
case 3:
case 5:
shost_printk(KERN_ERR, instance, "SCSI bus busy, 
waiting up to five seconds\n");
-   NCR5380_poll_politely(instance,
+   NCR5380_poll_politely(hostdata,
  STATUS_REG, SR_BSY, 0, 5 * HZ);
break;
case 2:
@@ -1076,7 +1075,7 @@ static struct scsi_cmnd *NCR5380_select(struct Scsi_Host 
*instance,
 */
 
spin_unlock_irq(>lock);
-   err = NCR5380_poll_politely2(instance, MODE_REG, MR_ARBITRATE, 0,
+   err = NCR5380_poll_politely2(hostdata, MODE_REG, MR_ARBITRATE, 0,
INITIATOR_COMMAND_REG, ICR_ARBITRATION_PROGRESS,
   ICR_ARBITRATION_PROGRESS, HZ);
spin_lock_irq(>lock);
@@ -1202,7 +1201,7 @@ static struct scsi_cmnd *NCR5380_select(struct Scsi_Host 
*instance,
 * selection.
 */
 
-   err = NCR5380_poll_politely(instance, STATUS_REG, SR_BSY, SR_BSY,
+   err = NCR5380_poll_politely(hostdata, STATUS_REG, SR_BSY, SR_BSY,
msecs_to_jiffies(250));
 
if ((NCR5380_read(STATUS_REG) & (SR_SEL | SR_IO)) == (SR_SEL | SR_IO)) {
@@ -1248,7 +1247,7 @@ static struct scsi_cmnd *NCR5380_select(struct Scsi_Host 
*instance,
 
/* Wait for start of REQ/ACK handshake */
 
-   err = NCR5380_poll_politely(instance, STATUS_REG, SR_REQ, SR_REQ, HZ);
+   err = NCR5380_poll_politely(hostdata, STATUS_REG, SR_REQ, SR_REQ, HZ);
spin_lock_irq(>lock);
if (err < 0) {
shost_printk(KERN_ERR, instance, "select: REQ timeout\n");
@@ -1338,7 +1337,7 @@ static int NCR5380_transfer_pio(struct Scsi_Host 
*instance,
 * valid
 */
 
-   if (NCR5380_poll_politely(instance, STATUS_REG, SR_REQ, SR_REQ, 
HZ) < 0)
+   if (NCR5380_poll_politely(hostdata, STATUS_REG, SR_REQ, SR_REQ, 
HZ) < 0)
break;
 
dsprintk(NDEBUG_HANDSHAKE, instance, "REQ asserted\n");
@@ -1383,7 +1382,7 @@ static int NCR5380_transfer_pio(struct Scsi_Host 
*instance,
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE | 
ICR_ASSERT_ACK);
}
 
-   if (NCR5380_poll_politely(instance,
+   if (NCR5380_poll_politely(hostdata,
  STATUS_REG, SR_REQ, 0, 5 * HZ) < 0)
break;
 
@@ -1483,7 +1482,7 @@ static int do_abort(struct Scsi_Host *instance)
 * the target sees, so we just handshake.
 */
 
-   rc = NCR5380_poll_politely(instance, STATUS_REG, SR_REQ, SR_REQ, 10 * 
HZ);
+   rc = NCR5380_poll_politely(hostdata, STATUS_REG, SR_REQ, SR_REQ, 10 * 
HZ);
if (rc < 0)
goto timeout;
 
@@ -1494,7 +1493,7 @@ static int do_abort(struct Scsi_Host *instance)
if (tmp != PHASE_MSGOUT) {
NCR5380_write(INITIATOR_COMMAND_REG,
  ICR_BASE | ICR_ASSERT_ATN | ICR_ASSERT_ACK);
-   rc = NCR5380_poll_politely(instance, STATUS_REG, SR_REQ, 0, 3 * 
HZ);
+   rc = NCR5380_poll_politely(hostdata, 

[PATCH 07/12] scsi/ncr5380: Store IO ports and addresses in host private data

[Finn Thain]

The various 5380 drivers inconsistently store register pointers
either in the Scsi_Host struct "legacy crap" area or in special,
board-specific members of the NCR5380_hostdata struct. Uniform
use of the latter struct makes for simpler and faster code (see
the following patches) and helps to reduce use of the
NCR5380_implementation_fields macro.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.c  |  8 +++---
 drivers/scsi/NCR5380.h  |  5 
 drivers/scsi/arm/cumana_1.c | 60 
 drivers/scsi/arm/oak.c  | 23 
 drivers/scsi/dmx3191d.c | 14 +++---
 drivers/scsi/g_NCR5380.c| 67 +++--
 drivers/scsi/g_NCR5380.h|  6 ++--
 drivers/scsi/mac_scsi.c | 27 ++
 drivers/scsi/sun3_scsi.c|  5 +++-
 9 files changed, 118 insertions(+), 97 deletions(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 330668b..68092f7 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -437,14 +437,14 @@ static void prepare_info(struct Scsi_Host *instance)
struct NCR5380_hostdata *hostdata = shost_priv(instance);
 
snprintf(hostdata->info, sizeof(hostdata->info),
-"%s, io_port 0x%lx, n_io_port %d, "
-"base 0x%lx, irq %d, "
+"%s, irq %d, "
+"io_port 0x%lx, base 0x%lx, "
 "can_queue %d, cmd_per_lun %d, "
 "sg_tablesize %d, this_id %d, "
 "flags { %s%s%s}, "
 "options { %s} ",
-instance->hostt->name, instance->io_port, instance->n_io_port,
-instance->base, instance->irq,
+instance->hostt->name, instance->irq,
+hostdata->io_port, hostdata->base,
 instance->can_queue, instance->cmd_per_lun,
 instance->sg_tablesize, instance->this_id,
 hostdata->flags & FLAG_DMA_FIXUP ? "DMA_FIXUP " : "",
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 8212efb6..5441970 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -220,6 +220,9 @@
 
 struct NCR5380_hostdata {
NCR5380_implementation_fields;  /* Board-specific data */
+   u8 __iomem *io; /* Remapped 5380 address */
+   u8 __iomem *pdma_io;/* Remapped PDMA address */
+   unsigned long io_port;  /* Device IO port */
unsigned long poll_loops;   /* Register polling limit */
spinlock_t lock;/* Protects this struct */
struct scsi_cmnd *connected;/* Currently connected cmnd */
@@ -239,6 +242,8 @@ struct NCR5380_hostdata {
unsigned char id_mask;  /* 1 << Host ID */
unsigned char id_higher_mask;   /* All bits above id_mask */
unsigned char last_message; /* Last Message Out */
+   unsigned long base; /* Device base address */
+   unsigned long region_size;  /* Size of address/port range */
char info[256];
 };
 
diff --git a/drivers/scsi/arm/cumana_1.c b/drivers/scsi/arm/cumana_1.c
index f616756..88db281 100644
--- a/drivers/scsi/arm/cumana_1.c
+++ b/drivers/scsi/arm/cumana_1.c
@@ -27,9 +27,7 @@
 #define NCR5380_info   cumanascsi_info
 
 #define NCR5380_implementation_fields  \
-   unsigned ctrl;  \
-   void __iomem *base; \
-   void __iomem *dma
+   unsigned ctrl
 
 #include "../NCR5380.h"
 
@@ -42,17 +40,18 @@ static inline int cumanascsi_pwrite(struct Scsi_Host *host,
 unsigned char *addr, int len)
 {
   unsigned long *laddr;
-  void __iomem *dma = priv(host)->dma + 0x2000;
+  u8 __iomem *base = priv(host)->io;
+  u8 __iomem *dma = priv(host)->pdma_io + 0x2000;
 
   if(!len) return 0;
 
-  writeb(0x02, priv(host)->base + CTRL);
+  writeb(0x02, base + CTRL);
   laddr = (unsigned long *)addr;
   while(len >= 32)
   {
 unsigned int status;
 unsigned long v;
-status = readb(priv(host)->base + STAT);
+status = readb(base + STAT);
 if(status & 0x80)
   goto end;
 if(!(status & 0x40))
@@ -71,12 +70,12 @@ static inline int cumanascsi_pwrite(struct Scsi_Host *host,
   }
 
   addr = (unsigned char *)laddr;
-  writeb(0x12, priv(host)->base + CTRL);
+  writeb(0x12, base + CTRL);
 
   while(len > 0)
   {
 unsigned int status;
-status = readb(priv(host)->base + STAT);
+status = readb(base + STAT);
 if(status & 0x80)
   goto end;
 if(status & 0x40)
@@ -86,7 +85,7 @@ static inline int cumanascsi_pwrite(struct Scsi_Host *host,
 break;
 }
 
-status = readb(priv(host)->base + STAT);
+status = readb(base + STAT);
 if(status & 0x80)
   goto end;
 if(status & 0x40)
@@ -97,7 +96,7 @@ static inline 

[PATCH 05/12] scsi/ncr5380: Increase register polling limit

[Finn Thain]

If NCR5380_poll_politely() is called under irq lock, the polling time
limit is clamped to avoid a spike in interrupt latency. When not under
irq lock, the same polling time limit acts as the worst case delay
between schedule() calls.

During PDMA (under irq lock) I've found that the 10 ms time limit is
sometimes too short, and leads to the error message,
sd 0:0:0:0: [sda] tag#1 macscsi_pread: !REQ and !ACK

This particular target identifies itself as a QUANTUM DAYTONA514S. It
seems to be slower to assert ACK than the other targets I've tested.
This patch solves the problem by increasing the polling timeout.

Signed-off-by: Finn Thain 
---
When irqs are disabled, this change will make no difference unless the
driver or target happens to suffer from timeout errors. In the irqs
enabled case, this patch may delay the next call to schedule() by an
additional 5 ms (in all 5380 drivers). Normally that would only happen
for a target selection timeout during a SCSI bus scan, which should not
bother anyone too much.
---
 drivers/scsi/NCR5380.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index ac0daa4..13d7aff 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -253,7 +253,7 @@ struct NCR5380_cmd {
 #define NCR5380_PIO_CHUNK_SIZE 256
 
 /* Time limit (ms) to poll registers when IRQs are disabled, e.g. during PDMA 
*/
-#define NCR5380_REG_POLL_TIME  10
+#define NCR5380_REG_POLL_TIME  15
 
 static inline struct scsi_cmnd *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr)
 {
-- 
2.7.3

[PATCH 06/12] scsi/ncr5380: Improve hostdata struct member alignment and cache-ability

[Finn Thain]

Re-order struct members so that hot data lies at the beginning of the
struct and cold data at the end. Improve the comments while we're here.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.h | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 13d7aff..8212efb6 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -219,27 +219,27 @@
 #define FLAG_TOSHIBA_DELAY 128 /* Allow for borken CD-ROMs */
 
 struct NCR5380_hostdata {
-   NCR5380_implementation_fields;  /* implementation specific */
-   struct Scsi_Host *host; /* Host backpointer */
-   unsigned char id_mask, id_higher_mask;  /* 1 << id, all bits greater */
-   unsigned char busy[8];  /* index = target, bit = lun */
-   int dma_len;/* requested length of DMA */
-   unsigned char last_message; /* last message OUT */
-   struct scsi_cmnd *connected;/* currently connected cmnd */
-   struct scsi_cmnd *selecting;/* cmnd to be connected */
-   struct list_head unissued;  /* waiting to be issued */
-   struct list_head autosense; /* priority issue queue */
-   struct list_head disconnected;  /* waiting for reconnect */
-   spinlock_t lock;/* protects this struct */
-   int flags;
-   struct scsi_eh_save ses;
-   struct scsi_cmnd *sensing;
+   NCR5380_implementation_fields;  /* Board-specific data */
+   unsigned long poll_loops;   /* Register polling limit */
+   spinlock_t lock;/* Protects this struct */
+   struct scsi_cmnd *connected;/* Currently connected cmnd */
+   struct list_head disconnected;  /* Waiting for reconnect */
+   struct Scsi_Host *host; /* SCSI host backpointer */
+   struct workqueue_struct *work_q;/* SCSI host work queue */
+   struct work_struct main_task;   /* Work item for main loop */
+   int flags;  /* Board-specific quirks */
+   int dma_len;/* Requested length of DMA */
+   int read_overruns;  /* Transfer size reduction for DMA erratum */
+   struct list_head unissued;  /* Waiting to be issued */
+   struct scsi_cmnd *selecting;/* Cmnd to be connected */
+   struct list_head autosense; /* Priority cmnd queue */
+   struct scsi_cmnd *sensing;  /* Cmnd needing autosense */
+   struct scsi_eh_save ses;/* Cmnd state saved for EH */
+   unsigned char busy[8];  /* Index = target, bit = lun */
+   unsigned char id_mask;  /* 1 << Host ID */
+   unsigned char id_higher_mask;   /* All bits above id_mask */
+   unsigned char last_message; /* Last Message Out */
char info[256];
-   int read_overruns;/* number of bytes to cut from a
-  * transfer to handle chip overruns */
-   struct work_struct main_task;
-   struct workqueue_struct *work_q;
-   unsigned long poll_loops;   /* register polling limit */
 };
 
 #ifdef __KERNEL__
-- 
2.7.3

[PATCH 05/12] scsi/ncr5380: Increase register polling limit

[Finn Thain]

If NCR5380_poll_politely() is called under irq lock, the polling time
limit is clamped to avoid a spike in interrupt latency. When not under
irq lock, the same polling time limit acts as the worst case delay
between schedule() calls.

During PDMA (under irq lock) I've found that the 10 ms time limit is
sometimes too short, and leads to the error message,
sd 0:0:0:0: [sda] tag#1 macscsi_pread: !REQ and !ACK

This particular target identifies itself as a QUANTUM DAYTONA514S. It
seems to be slower to assert ACK than the other targets I've tested.
This patch solves the problem by increasing the polling timeout.

Signed-off-by: Finn Thain 
---
When irqs are disabled, this change will make no difference unless the
driver or target happens to suffer from timeout errors. In the irqs
enabled case, this patch may delay the next call to schedule() by an
additional 5 ms (in all 5380 drivers). Normally that would only happen
for a target selection timeout during a SCSI bus scan, which should not
bother anyone too much.
---
 drivers/scsi/NCR5380.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index ac0daa4..13d7aff 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -253,7 +253,7 @@ struct NCR5380_cmd {
 #define NCR5380_PIO_CHUNK_SIZE 256
 
 /* Time limit (ms) to poll registers when IRQs are disabled, e.g. during PDMA 
*/
-#define NCR5380_REG_POLL_TIME  10
+#define NCR5380_REG_POLL_TIME  15
 
 static inline struct scsi_cmnd *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr)
 {
-- 
2.7.3

[PATCH 06/12] scsi/ncr5380: Improve hostdata struct member alignment and cache-ability

[Finn Thain]

Re-order struct members so that hot data lies at the beginning of the
struct and cold data at the end. Improve the comments while we're here.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.h | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 13d7aff..8212efb6 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -219,27 +219,27 @@
 #define FLAG_TOSHIBA_DELAY 128 /* Allow for borken CD-ROMs */
 
 struct NCR5380_hostdata {
-   NCR5380_implementation_fields;  /* implementation specific */
-   struct Scsi_Host *host; /* Host backpointer */
-   unsigned char id_mask, id_higher_mask;  /* 1 << id, all bits greater */
-   unsigned char busy[8];  /* index = target, bit = lun */
-   int dma_len;/* requested length of DMA */
-   unsigned char last_message; /* last message OUT */
-   struct scsi_cmnd *connected;/* currently connected cmnd */
-   struct scsi_cmnd *selecting;/* cmnd to be connected */
-   struct list_head unissued;  /* waiting to be issued */
-   struct list_head autosense; /* priority issue queue */
-   struct list_head disconnected;  /* waiting for reconnect */
-   spinlock_t lock;/* protects this struct */
-   int flags;
-   struct scsi_eh_save ses;
-   struct scsi_cmnd *sensing;
+   NCR5380_implementation_fields;  /* Board-specific data */
+   unsigned long poll_loops;   /* Register polling limit */
+   spinlock_t lock;/* Protects this struct */
+   struct scsi_cmnd *connected;/* Currently connected cmnd */
+   struct list_head disconnected;  /* Waiting for reconnect */
+   struct Scsi_Host *host; /* SCSI host backpointer */
+   struct workqueue_struct *work_q;/* SCSI host work queue */
+   struct work_struct main_task;   /* Work item for main loop */
+   int flags;  /* Board-specific quirks */
+   int dma_len;/* Requested length of DMA */
+   int read_overruns;  /* Transfer size reduction for DMA erratum */
+   struct list_head unissued;  /* Waiting to be issued */
+   struct scsi_cmnd *selecting;/* Cmnd to be connected */
+   struct list_head autosense; /* Priority cmnd queue */
+   struct scsi_cmnd *sensing;  /* Cmnd needing autosense */
+   struct scsi_eh_save ses;/* Cmnd state saved for EH */
+   unsigned char busy[8];  /* Index = target, bit = lun */
+   unsigned char id_mask;  /* 1 << Host ID */
+   unsigned char id_higher_mask;   /* All bits above id_mask */
+   unsigned char last_message; /* Last Message Out */
char info[256];
-   int read_overruns;/* number of bytes to cut from a
-  * transfer to handle chip overruns */
-   struct work_struct main_task;
-   struct workqueue_struct *work_q;
-   unsigned long poll_loops;   /* register polling limit */
 };
 
 #ifdef __KERNEL__
-- 
2.7.3

[PATCH 09/12] scsi/ncr5380: Pass hostdata pointer to register polling routines

[Finn Thain]

Pass a NCR5380_hostdata struct pointer to the board-specific routines
instead of a Scsi_Host struct pointer. This reduces pointer chasing in
the PIO and PDMA fast paths. The old way was a mistake because it is
slow and the board-specific code is not concerned with the mid-layer.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.c  | 33 -
 drivers/scsi/NCR5380.h  |  6 +++---
 drivers/scsi/mac_scsi.c | 10 +-
 3 files changed, 24 insertions(+), 25 deletions(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 8e11ab7..3f71556 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -178,7 +178,7 @@ static inline void initialize_SCp(struct scsi_cmnd *cmd)
 
 /**
  * NCR5380_poll_politely2 - wait for two chip register values
- * @instance: controller to poll
+ * @hostdata: host private data
  * @reg1: 5380 register to poll
  * @bit1: Bitmask to check
  * @val1: Expected value
@@ -195,12 +195,11 @@ static inline void initialize_SCp(struct scsi_cmnd *cmd)
  * Returns 0 if either or both event(s) occurred otherwise -ETIMEDOUT.
  */
 
-static int NCR5380_poll_politely2(struct Scsi_Host *instance,
+static int NCR5380_poll_politely2(struct NCR5380_hostdata *hostdata,
   unsigned int reg1, u8 bit1, u8 val1,
   unsigned int reg2, u8 bit2, u8 val2,
   unsigned long wait)
 {
-   struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned long n = hostdata->poll_loops;
unsigned long deadline = jiffies + wait;
 
@@ -561,7 +560,7 @@ static int NCR5380_maybe_reset_bus(struct Scsi_Host 
*instance)
case 3:
case 5:
shost_printk(KERN_ERR, instance, "SCSI bus busy, 
waiting up to five seconds\n");
-   NCR5380_poll_politely(instance,
+   NCR5380_poll_politely(hostdata,
  STATUS_REG, SR_BSY, 0, 5 * HZ);
break;
case 2:
@@ -1076,7 +1075,7 @@ static struct scsi_cmnd *NCR5380_select(struct Scsi_Host 
*instance,
 */
 
spin_unlock_irq(>lock);
-   err = NCR5380_poll_politely2(instance, MODE_REG, MR_ARBITRATE, 0,
+   err = NCR5380_poll_politely2(hostdata, MODE_REG, MR_ARBITRATE, 0,
INITIATOR_COMMAND_REG, ICR_ARBITRATION_PROGRESS,
   ICR_ARBITRATION_PROGRESS, HZ);
spin_lock_irq(>lock);
@@ -1202,7 +1201,7 @@ static struct scsi_cmnd *NCR5380_select(struct Scsi_Host 
*instance,
 * selection.
 */
 
-   err = NCR5380_poll_politely(instance, STATUS_REG, SR_BSY, SR_BSY,
+   err = NCR5380_poll_politely(hostdata, STATUS_REG, SR_BSY, SR_BSY,
msecs_to_jiffies(250));
 
if ((NCR5380_read(STATUS_REG) & (SR_SEL | SR_IO)) == (SR_SEL | SR_IO)) {
@@ -1248,7 +1247,7 @@ static struct scsi_cmnd *NCR5380_select(struct Scsi_Host 
*instance,
 
/* Wait for start of REQ/ACK handshake */
 
-   err = NCR5380_poll_politely(instance, STATUS_REG, SR_REQ, SR_REQ, HZ);
+   err = NCR5380_poll_politely(hostdata, STATUS_REG, SR_REQ, SR_REQ, HZ);
spin_lock_irq(>lock);
if (err < 0) {
shost_printk(KERN_ERR, instance, "select: REQ timeout\n");
@@ -1338,7 +1337,7 @@ static int NCR5380_transfer_pio(struct Scsi_Host 
*instance,
 * valid
 */
 
-   if (NCR5380_poll_politely(instance, STATUS_REG, SR_REQ, SR_REQ, 
HZ) < 0)
+   if (NCR5380_poll_politely(hostdata, STATUS_REG, SR_REQ, SR_REQ, 
HZ) < 0)
break;
 
dsprintk(NDEBUG_HANDSHAKE, instance, "REQ asserted\n");
@@ -1383,7 +1382,7 @@ static int NCR5380_transfer_pio(struct Scsi_Host 
*instance,
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE | 
ICR_ASSERT_ACK);
}
 
-   if (NCR5380_poll_politely(instance,
+   if (NCR5380_poll_politely(hostdata,
  STATUS_REG, SR_REQ, 0, 5 * HZ) < 0)
break;
 
@@ -1483,7 +1482,7 @@ static int do_abort(struct Scsi_Host *instance)
 * the target sees, so we just handshake.
 */
 
-   rc = NCR5380_poll_politely(instance, STATUS_REG, SR_REQ, SR_REQ, 10 * 
HZ);
+   rc = NCR5380_poll_politely(hostdata, STATUS_REG, SR_REQ, SR_REQ, 10 * 
HZ);
if (rc < 0)
goto timeout;
 
@@ -1494,7 +1493,7 @@ static int do_abort(struct Scsi_Host *instance)
if (tmp != PHASE_MSGOUT) {
NCR5380_write(INITIATOR_COMMAND_REG,
  ICR_BASE | ICR_ASSERT_ATN | ICR_ASSERT_ACK);
-   rc = NCR5380_poll_politely(instance, STATUS_REG, SR_REQ, 0, 3 * 
HZ);
+   rc = NCR5380_poll_politely(hostdata, STATUS_REG, SR_REQ, 0, 3 * 
HZ);

[PATCH 07/12] scsi/ncr5380: Store IO ports and addresses in host private data

[Finn Thain]

The various 5380 drivers inconsistently store register pointers
either in the Scsi_Host struct "legacy crap" area or in special,
board-specific members of the NCR5380_hostdata struct. Uniform
use of the latter struct makes for simpler and faster code (see
the following patches) and helps to reduce use of the
NCR5380_implementation_fields macro.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.c  |  8 +++---
 drivers/scsi/NCR5380.h  |  5 
 drivers/scsi/arm/cumana_1.c | 60 
 drivers/scsi/arm/oak.c  | 23 
 drivers/scsi/dmx3191d.c | 14 +++---
 drivers/scsi/g_NCR5380.c| 67 +++--
 drivers/scsi/g_NCR5380.h|  6 ++--
 drivers/scsi/mac_scsi.c | 27 ++
 drivers/scsi/sun3_scsi.c|  5 +++-
 9 files changed, 118 insertions(+), 97 deletions(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 330668b..68092f7 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -437,14 +437,14 @@ static void prepare_info(struct Scsi_Host *instance)
struct NCR5380_hostdata *hostdata = shost_priv(instance);
 
snprintf(hostdata->info, sizeof(hostdata->info),
-"%s, io_port 0x%lx, n_io_port %d, "
-"base 0x%lx, irq %d, "
+"%s, irq %d, "
+"io_port 0x%lx, base 0x%lx, "
 "can_queue %d, cmd_per_lun %d, "
 "sg_tablesize %d, this_id %d, "
 "flags { %s%s%s}, "
 "options { %s} ",
-instance->hostt->name, instance->io_port, instance->n_io_port,
-instance->base, instance->irq,
+instance->hostt->name, instance->irq,
+hostdata->io_port, hostdata->base,
 instance->can_queue, instance->cmd_per_lun,
 instance->sg_tablesize, instance->this_id,
 hostdata->flags & FLAG_DMA_FIXUP ? "DMA_FIXUP " : "",
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 8212efb6..5441970 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -220,6 +220,9 @@
 
 struct NCR5380_hostdata {
NCR5380_implementation_fields;  /* Board-specific data */
+   u8 __iomem *io; /* Remapped 5380 address */
+   u8 __iomem *pdma_io;/* Remapped PDMA address */
+   unsigned long io_port;  /* Device IO port */
unsigned long poll_loops;   /* Register polling limit */
spinlock_t lock;/* Protects this struct */
struct scsi_cmnd *connected;/* Currently connected cmnd */
@@ -239,6 +242,8 @@ struct NCR5380_hostdata {
unsigned char id_mask;  /* 1 << Host ID */
unsigned char id_higher_mask;   /* All bits above id_mask */
unsigned char last_message; /* Last Message Out */
+   unsigned long base; /* Device base address */
+   unsigned long region_size;  /* Size of address/port range */
char info[256];
 };
 
diff --git a/drivers/scsi/arm/cumana_1.c b/drivers/scsi/arm/cumana_1.c
index f616756..88db281 100644
--- a/drivers/scsi/arm/cumana_1.c
+++ b/drivers/scsi/arm/cumana_1.c
@@ -27,9 +27,7 @@
 #define NCR5380_info   cumanascsi_info
 
 #define NCR5380_implementation_fields  \
-   unsigned ctrl;  \
-   void __iomem *base; \
-   void __iomem *dma
+   unsigned ctrl
 
 #include "../NCR5380.h"
 
@@ -42,17 +40,18 @@ static inline int cumanascsi_pwrite(struct Scsi_Host *host,
 unsigned char *addr, int len)
 {
   unsigned long *laddr;
-  void __iomem *dma = priv(host)->dma + 0x2000;
+  u8 __iomem *base = priv(host)->io;
+  u8 __iomem *dma = priv(host)->pdma_io + 0x2000;
 
   if(!len) return 0;
 
-  writeb(0x02, priv(host)->base + CTRL);
+  writeb(0x02, base + CTRL);
   laddr = (unsigned long *)addr;
   while(len >= 32)
   {
 unsigned int status;
 unsigned long v;
-status = readb(priv(host)->base + STAT);
+status = readb(base + STAT);
 if(status & 0x80)
   goto end;
 if(!(status & 0x40))
@@ -71,12 +70,12 @@ static inline int cumanascsi_pwrite(struct Scsi_Host *host,
   }
 
   addr = (unsigned char *)laddr;
-  writeb(0x12, priv(host)->base + CTRL);
+  writeb(0x12, base + CTRL);
 
   while(len > 0)
   {
 unsigned int status;
-status = readb(priv(host)->base + STAT);
+status = readb(base + STAT);
 if(status & 0x80)
   goto end;
 if(status & 0x40)
@@ -86,7 +85,7 @@ static inline int cumanascsi_pwrite(struct Scsi_Host *host,
 break;
 }
 
-status = readb(priv(host)->base + STAT);
+status = readb(base + STAT);
 if(status & 0x80)
   goto end;
 if(status & 0x40)
@@ -97,7 +96,7 @@ static inline int cumanascsi_pwrite(struct 

[PATCH 02/12] scsi/cumana_1: Remove unused cumanascsi_setup() function

[Finn Thain]

Signed-off-by: Finn Thain 
---
 drivers/scsi/arm/cumana_1.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/scsi/arm/cumana_1.c b/drivers/scsi/arm/cumana_1.c
index 8e9cfe8..f616756 100644
--- a/drivers/scsi/arm/cumana_1.c
+++ b/drivers/scsi/arm/cumana_1.c
@@ -33,10 +33,6 @@
 
 #include "../NCR5380.h"
 
-void cumanascsi_setup(char *str, int *ints)
-{
-}
-
 #define CTRL   0x16fc
 #define STAT   0x2004
 #define L(v)   (((v)<<16)|((v) & 0x))
-- 
2.7.3

[PATCH 00/12] Fixes, cleanup and g_NCR5380_mmio/g_NCR5380 merger

[Finn Thain]

This patch series has fixes for compatibility, reliability and
performance issues and some cleanup. It also includes a new version
of Ondrej Zary's patch that merges g_NCR5380_mmio into g_NCR5380.

I've tested this patch series on a Powerbook 180. If someone would
test some of the other platforms that would be very helpful. All
drivers were compile-tested.

(Apologies for any duplicate messages.)


Finn Thain (12):
  scsi/g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio drivers
  scsi/cumana_1: Remove unused cumanascsi_setup() function
  scsi/atari_scsi: Make device register accessors re-enterant
  scsi/ncr5380: Simplify register polling limit
  scsi/ncr5380: Increase register polling limit
  scsi/ncr5380: Improve hostdata struct member alignment and
cache-ability
  scsi/ncr5380: Store IO ports and addresses in host private data
  scsi/ncr5380: Use correct types for device register accessors
  scsi/ncr5380: Pass hostdata pointer to register polling routines
  scsi/ncr5380: Expedite register polling
  scsi/ncr5380: Use correct types for DMA routines
  scsi/ncr5380: Suppress unhelpful "interrupt without IRQ bit" message

 MAINTAINERS   |   1 -
 drivers/scsi/Kconfig  |  32 +
 drivers/scsi/Makefile |   1 -
 drivers/scsi/NCR5380.c| 137 +++-
 drivers/scsi/NCR5380.h|  87 +
 drivers/scsi/arm/cumana_1.c   |  98 +++---
 drivers/scsi/arm/oak.c|  34 +++--
 drivers/scsi/atari_scsi.c |  77 ++-
 drivers/scsi/dmx3191d.c   |  20 +--
 drivers/scsi/g_NCR5380.c  | 290 --
 drivers/scsi/g_NCR5380.h  |  32 +
 drivers/scsi/g_NCR5380_mmio.c |  10 --
 drivers/scsi/mac_scsi.c   |  83 +---
 drivers/scsi/sun3_scsi.c  |  80 ++--
 14 files changed, 495 insertions(+), 487 deletions(-)
 delete mode 100644 drivers/scsi/g_NCR5380_mmio.c

-- 
2.7.3

[PATCH 08/12] scsi/ncr5380: Use correct types for device register accessors

[Finn Thain]

For timeout values adopt unsigned long, which is the type of jiffies etc.

For chip register values and bit masks pass u8, which is the return type
of readb, inb etc.

For device register offsets adopt unsigned int, as it is suitable for
adding to base addresses.

Pass the NCR5380_hostdata pointer to the board-specific routines instead
of the Scsi_Host pointer. The board-specific code is concerned with
hardware and not with SCSI protocol or the mid-layer.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.c  | 10 --
 drivers/scsi/NCR5380.h  |  7 +--
 drivers/scsi/arm/cumana_1.c | 20 +++-
 drivers/scsi/arm/oak.c  |  6 ++
 drivers/scsi/atari_scsi.c   | 16 
 drivers/scsi/dmx3191d.c |  6 ++
 drivers/scsi/g_NCR5380.h|  8 ++--
 drivers/scsi/mac_scsi.c | 22 ++
 drivers/scsi/sun3_scsi.c| 32 +---
 9 files changed, 49 insertions(+), 78 deletions(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 68092f7..8e11ab7 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -196,8 +196,9 @@ static inline void initialize_SCp(struct scsi_cmnd *cmd)
  */
 
 static int NCR5380_poll_politely2(struct Scsi_Host *instance,
-  int reg1, int bit1, int val1,
-  int reg2, int bit2, int val2, int wait)
+  unsigned int reg1, u8 bit1, u8 val1,
+  unsigned int reg2, u8 bit2, u8 val2,
+  unsigned long wait)
 {
struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned long n = hostdata->poll_loops;
@@ -284,6 +285,7 @@ mrs[] = {
 
 static void NCR5380_print(struct Scsi_Host *instance)
 {
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned char status, data, basr, mr, icr, i;
 
data = NCR5380_read(CURRENT_SCSI_DATA_REG);
@@ -333,6 +335,7 @@ static struct {
 
 static void NCR5380_print_phase(struct Scsi_Host *instance)
 {
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned char status;
int i;
 
@@ -1316,6 +1319,7 @@ static int NCR5380_transfer_pio(struct Scsi_Host 
*instance,
unsigned char *phase, int *count,
unsigned char **data)
 {
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned char p = *phase, tmp;
int c = *count;
unsigned char *d = *data;
@@ -1438,6 +1442,7 @@ static int NCR5380_transfer_pio(struct Scsi_Host 
*instance,
 
 static void do_reset(struct Scsi_Host *instance)
 {
+   struct NCR5380_hostdata __maybe_unused *hostdata = shost_priv(instance);
unsigned long flags;
 
local_irq_save(flags);
@@ -1460,6 +1465,7 @@ static void do_reset(struct Scsi_Host *instance)
 
 static int do_abort(struct Scsi_Host *instance)
 {
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned char *msgptr, phase, tmp;
int len;
int rc;
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 5441970..79f8add 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -302,10 +302,13 @@ static void NCR5380_reselect(struct Scsi_Host *instance);
 static struct scsi_cmnd *NCR5380_select(struct Scsi_Host *, struct scsi_cmnd 
*);
 static int NCR5380_transfer_dma(struct Scsi_Host *instance, unsigned char 
*phase, int *count, unsigned char **data);
 static int NCR5380_transfer_pio(struct Scsi_Host *instance, unsigned char 
*phase, int *count, unsigned char **data);
-static int NCR5380_poll_politely2(struct Scsi_Host *, int, int, int, int, int, 
int, int);
+static int NCR5380_poll_politely2(struct Scsi_Host *,
+  unsigned int, u8, u8,
+  unsigned int, u8, u8, unsigned long);
 
 static inline int NCR5380_poll_politely(struct Scsi_Host *instance,
-int reg, int bit, int val, int wait)
+unsigned int reg, u8 bit, u8 val,
+unsigned long wait)
 {
return NCR5380_poll_politely2(instance, reg, bit, val,
reg, bit, val, wait);
diff --git a/drivers/scsi/arm/cumana_1.c b/drivers/scsi/arm/cumana_1.c
index 88db281..ae1d4c6 100644
--- a/drivers/scsi/arm/cumana_1.c
+++ b/drivers/scsi/arm/cumana_1.c
@@ -14,8 +14,8 @@
 #include 
 
 #define priv(host) ((struct NCR5380_hostdata 
*)(host)->hostdata)
-#define NCR5380_read(reg)  cumanascsi_read(instance, reg)
-#define NCR5380_write(reg, value)  cumanascsi_write(instance, reg, value)
+#define NCR5380_read(reg)  cumanascsi_read(hostdata, reg)
+#define NCR5380_write(reg, value)  cumanascsi_write(hostdata, reg, value)
 

[PATCH 11/12] scsi/ncr5380: Use correct types for DMA routines

[Finn Thain]

Apply prototypes to get consistent function signatures for the DMA
functions implemented in the board-specific drivers. To avoid using
macros to alter actual parameters, some of those functions are reworked
slightly.

This is a step toward the goal of passing the board-specific routines
to the core driver using an ops struct (as in a platform driver or
library module).

This also helps fix some inconsistent types: where the core driver uses
ints (cmd->SCp.this_residual and hostdata->dma_len) for keeping track of
transfers, certain board-specific routines used unsigned long.

While we are fixing these function signatures, pass the hostdata pointer
to DMA routines instead of a Scsi_Host pointer, for shorter and faster
code.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.c  | 74 +
 drivers/scsi/NCR5380.h  | 25 +++
 drivers/scsi/arm/cumana_1.c | 26 ++--
 drivers/scsi/arm/oak.c  | 13 
 drivers/scsi/atari_scsi.c   | 45 +++
 drivers/scsi/dmx3191d.c |  8 ++---
 drivers/scsi/g_NCR5380.c| 13 +++-
 drivers/scsi/g_NCR5380.h|  5 ++-
 drivers/scsi/mac_scsi.c | 36 +++---
 drivers/scsi/sun3_scsi.c| 45 +++
 10 files changed, 176 insertions(+), 114 deletions(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 3f71556..d479e11 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -121,9 +121,10 @@
  *
  * Either real DMA *or* pseudo DMA may be implemented
  *
- * NCR5380_dma_write_setup(instance, src, count) - initialize
- * NCR5380_dma_read_setup(instance, dst, count) - initialize
- * NCR5380_dma_residual(instance); - residual count
+ * NCR5380_dma_xfer_len   - determine size of DMA/PDMA transfer
+ * NCR5380_dma_send_setup - execute DMA/PDMA from memory to 5380
+ * NCR5380_dma_recv_setup - execute DMA/PDMA from 5380 to memory
+ * NCR5380_dma_residual   - residual byte count
  *
  * The generic driver is initialized by calling NCR5380_init(instance),
  * after setting the appropriate host specific fields and ID.  If the
@@ -871,7 +872,7 @@ static void NCR5380_dma_complete(struct Scsi_Host *instance)
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
NCR5380_read(RESET_PARITY_INTERRUPT_REG);
 
-   transferred = hostdata->dma_len - NCR5380_dma_residual(instance);
+   transferred = hostdata->dma_len - NCR5380_dma_residual(hostdata);
hostdata->dma_len = 0;
 
data = (unsigned char **)>connected->SCp.ptr;
@@ -1578,9 +1579,9 @@ static int NCR5380_transfer_dma(struct Scsi_Host 
*instance,
 * starting the NCR. This is also the cleaner way for the TT.
 */
if (p & SR_IO)
-   result = NCR5380_dma_recv_setup(instance, d, c);
+   result = NCR5380_dma_recv_setup(hostdata, d, c);
else
-   result = NCR5380_dma_send_setup(instance, d, c);
+   result = NCR5380_dma_send_setup(hostdata, d, c);
}
 
/*
@@ -1612,9 +1613,9 @@ static int NCR5380_transfer_dma(struct Scsi_Host 
*instance,
 * NCR access, else the DMA setup gets trashed!
 */
if (p & SR_IO)
-   result = NCR5380_dma_recv_setup(instance, d, c);
+   result = NCR5380_dma_recv_setup(hostdata, d, c);
else
-   result = NCR5380_dma_send_setup(instance, d, c);
+   result = NCR5380_dma_send_setup(hostdata, d, c);
}
 
/* On failure, NCR5380_dma__setup() returns a negative int. */
@@ -1754,22 +1755,26 @@ static void NCR5380_information_transfer(struct 
Scsi_Host *instance)
NCR5380_dprint_phase(NDEBUG_INFORMATION, 
instance);
}
 #ifdef CONFIG_SUN3
-   if (phase == PHASE_CMDOUT) {
-   void *d;
-   unsigned long count;
+   if (phase == PHASE_CMDOUT &&
+   sun3_dma_setup_done != cmd) {
+   int count;
 
if (!cmd->SCp.this_residual && 
cmd->SCp.buffers_residual) {
-   count = cmd->SCp.buffer->length;
-   d = sg_virt(cmd->SCp.buffer);
-   } else {
-   count = cmd->SCp.this_residual;
-   d = cmd->SCp.ptr;
+   ++cmd->SCp.buffer;
+   --cmd->SCp.buffers_residual;
+   cmd->SCp.this_residual = 
cmd->SCp.buffer->length;
+   cmd->SCp.ptr = sg_virt(cmd->SCp.buffer);
   

[PATCH 08/12] scsi/ncr5380: Use correct types for device register accessors

[Finn Thain]

For timeout values adopt unsigned long, which is the type of jiffies etc.

For chip register values and bit masks pass u8, which is the return type
of readb, inb etc.

For device register offsets adopt unsigned int, as it is suitable for
adding to base addresses.

Pass the NCR5380_hostdata pointer to the board-specific routines instead
of the Scsi_Host pointer. The board-specific code is concerned with
hardware and not with SCSI protocol or the mid-layer.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.c  | 10 --
 drivers/scsi/NCR5380.h  |  7 +--
 drivers/scsi/arm/cumana_1.c | 20 +++-
 drivers/scsi/arm/oak.c  |  6 ++
 drivers/scsi/atari_scsi.c   | 16 
 drivers/scsi/dmx3191d.c |  6 ++
 drivers/scsi/g_NCR5380.h|  8 ++--
 drivers/scsi/mac_scsi.c | 22 ++
 drivers/scsi/sun3_scsi.c| 32 +---
 9 files changed, 49 insertions(+), 78 deletions(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 68092f7..8e11ab7 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -196,8 +196,9 @@ static inline void initialize_SCp(struct scsi_cmnd *cmd)
  */
 
 static int NCR5380_poll_politely2(struct Scsi_Host *instance,
-  int reg1, int bit1, int val1,
-  int reg2, int bit2, int val2, int wait)
+  unsigned int reg1, u8 bit1, u8 val1,
+  unsigned int reg2, u8 bit2, u8 val2,
+  unsigned long wait)
 {
struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned long n = hostdata->poll_loops;
@@ -284,6 +285,7 @@ mrs[] = {
 
 static void NCR5380_print(struct Scsi_Host *instance)
 {
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned char status, data, basr, mr, icr, i;
 
data = NCR5380_read(CURRENT_SCSI_DATA_REG);
@@ -333,6 +335,7 @@ static struct {
 
 static void NCR5380_print_phase(struct Scsi_Host *instance)
 {
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned char status;
int i;
 
@@ -1316,6 +1319,7 @@ static int NCR5380_transfer_pio(struct Scsi_Host 
*instance,
unsigned char *phase, int *count,
unsigned char **data)
 {
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned char p = *phase, tmp;
int c = *count;
unsigned char *d = *data;
@@ -1438,6 +1442,7 @@ static int NCR5380_transfer_pio(struct Scsi_Host 
*instance,
 
 static void do_reset(struct Scsi_Host *instance)
 {
+   struct NCR5380_hostdata __maybe_unused *hostdata = shost_priv(instance);
unsigned long flags;
 
local_irq_save(flags);
@@ -1460,6 +1465,7 @@ static void do_reset(struct Scsi_Host *instance)
 
 static int do_abort(struct Scsi_Host *instance)
 {
+   struct NCR5380_hostdata *hostdata = shost_priv(instance);
unsigned char *msgptr, phase, tmp;
int len;
int rc;
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 5441970..79f8add 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -302,10 +302,13 @@ static void NCR5380_reselect(struct Scsi_Host *instance);
 static struct scsi_cmnd *NCR5380_select(struct Scsi_Host *, struct scsi_cmnd 
*);
 static int NCR5380_transfer_dma(struct Scsi_Host *instance, unsigned char 
*phase, int *count, unsigned char **data);
 static int NCR5380_transfer_pio(struct Scsi_Host *instance, unsigned char 
*phase, int *count, unsigned char **data);
-static int NCR5380_poll_politely2(struct Scsi_Host *, int, int, int, int, int, 
int, int);
+static int NCR5380_poll_politely2(struct Scsi_Host *,
+  unsigned int, u8, u8,
+  unsigned int, u8, u8, unsigned long);
 
 static inline int NCR5380_poll_politely(struct Scsi_Host *instance,
-int reg, int bit, int val, int wait)
+unsigned int reg, u8 bit, u8 val,
+unsigned long wait)
 {
return NCR5380_poll_politely2(instance, reg, bit, val,
reg, bit, val, wait);
diff --git a/drivers/scsi/arm/cumana_1.c b/drivers/scsi/arm/cumana_1.c
index 88db281..ae1d4c6 100644
--- a/drivers/scsi/arm/cumana_1.c
+++ b/drivers/scsi/arm/cumana_1.c
@@ -14,8 +14,8 @@
 #include 
 
 #define priv(host) ((struct NCR5380_hostdata 
*)(host)->hostdata)
-#define NCR5380_read(reg)  cumanascsi_read(instance, reg)
-#define NCR5380_write(reg, value)  cumanascsi_write(instance, reg, value)
+#define NCR5380_read(reg)  cumanascsi_read(hostdata, reg)
+#define NCR5380_write(reg, value)  cumanascsi_write(hostdata, reg, value)
 
 #define 

[PATCH 11/12] scsi/ncr5380: Use correct types for DMA routines

[Finn Thain]

Apply prototypes to get consistent function signatures for the DMA
functions implemented in the board-specific drivers. To avoid using
macros to alter actual parameters, some of those functions are reworked
slightly.

This is a step toward the goal of passing the board-specific routines
to the core driver using an ops struct (as in a platform driver or
library module).

This also helps fix some inconsistent types: where the core driver uses
ints (cmd->SCp.this_residual and hostdata->dma_len) for keeping track of
transfers, certain board-specific routines used unsigned long.

While we are fixing these function signatures, pass the hostdata pointer
to DMA routines instead of a Scsi_Host pointer, for shorter and faster
code.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.c  | 74 +
 drivers/scsi/NCR5380.h  | 25 +++
 drivers/scsi/arm/cumana_1.c | 26 ++--
 drivers/scsi/arm/oak.c  | 13 
 drivers/scsi/atari_scsi.c   | 45 +++
 drivers/scsi/dmx3191d.c |  8 ++---
 drivers/scsi/g_NCR5380.c| 13 +++-
 drivers/scsi/g_NCR5380.h|  5 ++-
 drivers/scsi/mac_scsi.c | 36 +++---
 drivers/scsi/sun3_scsi.c| 45 +++
 10 files changed, 176 insertions(+), 114 deletions(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 3f71556..d479e11 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -121,9 +121,10 @@
  *
  * Either real DMA *or* pseudo DMA may be implemented
  *
- * NCR5380_dma_write_setup(instance, src, count) - initialize
- * NCR5380_dma_read_setup(instance, dst, count) - initialize
- * NCR5380_dma_residual(instance); - residual count
+ * NCR5380_dma_xfer_len   - determine size of DMA/PDMA transfer
+ * NCR5380_dma_send_setup - execute DMA/PDMA from memory to 5380
+ * NCR5380_dma_recv_setup - execute DMA/PDMA from 5380 to memory
+ * NCR5380_dma_residual   - residual byte count
  *
  * The generic driver is initialized by calling NCR5380_init(instance),
  * after setting the appropriate host specific fields and ID.  If the
@@ -871,7 +872,7 @@ static void NCR5380_dma_complete(struct Scsi_Host *instance)
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
NCR5380_read(RESET_PARITY_INTERRUPT_REG);
 
-   transferred = hostdata->dma_len - NCR5380_dma_residual(instance);
+   transferred = hostdata->dma_len - NCR5380_dma_residual(hostdata);
hostdata->dma_len = 0;
 
data = (unsigned char **)>connected->SCp.ptr;
@@ -1578,9 +1579,9 @@ static int NCR5380_transfer_dma(struct Scsi_Host 
*instance,
 * starting the NCR. This is also the cleaner way for the TT.
 */
if (p & SR_IO)
-   result = NCR5380_dma_recv_setup(instance, d, c);
+   result = NCR5380_dma_recv_setup(hostdata, d, c);
else
-   result = NCR5380_dma_send_setup(instance, d, c);
+   result = NCR5380_dma_send_setup(hostdata, d, c);
}
 
/*
@@ -1612,9 +1613,9 @@ static int NCR5380_transfer_dma(struct Scsi_Host 
*instance,
 * NCR access, else the DMA setup gets trashed!
 */
if (p & SR_IO)
-   result = NCR5380_dma_recv_setup(instance, d, c);
+   result = NCR5380_dma_recv_setup(hostdata, d, c);
else
-   result = NCR5380_dma_send_setup(instance, d, c);
+   result = NCR5380_dma_send_setup(hostdata, d, c);
}
 
/* On failure, NCR5380_dma__setup() returns a negative int. */
@@ -1754,22 +1755,26 @@ static void NCR5380_information_transfer(struct 
Scsi_Host *instance)
NCR5380_dprint_phase(NDEBUG_INFORMATION, 
instance);
}
 #ifdef CONFIG_SUN3
-   if (phase == PHASE_CMDOUT) {
-   void *d;
-   unsigned long count;
+   if (phase == PHASE_CMDOUT &&
+   sun3_dma_setup_done != cmd) {
+   int count;
 
if (!cmd->SCp.this_residual && 
cmd->SCp.buffers_residual) {
-   count = cmd->SCp.buffer->length;
-   d = sg_virt(cmd->SCp.buffer);
-   } else {
-   count = cmd->SCp.this_residual;
-   d = cmd->SCp.ptr;
+   ++cmd->SCp.buffer;
+   --cmd->SCp.buffers_residual;
+   cmd->SCp.this_residual = 
cmd->SCp.buffer->length;
+   cmd->SCp.ptr = sg_virt(cmd->SCp.buffer);
}
 
-  

[PATCH 02/12] scsi/cumana_1: Remove unused cumanascsi_setup() function

[Finn Thain]

Signed-off-by: Finn Thain 
---
 drivers/scsi/arm/cumana_1.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/scsi/arm/cumana_1.c b/drivers/scsi/arm/cumana_1.c
index 8e9cfe8..f616756 100644
--- a/drivers/scsi/arm/cumana_1.c
+++ b/drivers/scsi/arm/cumana_1.c
@@ -33,10 +33,6 @@
 
 #include "../NCR5380.h"
 
-void cumanascsi_setup(char *str, int *ints)
-{
-}
-
 #define CTRL   0x16fc
 #define STAT   0x2004
 #define L(v)   (((v)<<16)|((v) & 0x))
-- 
2.7.3

[PATCH 00/12] Fixes, cleanup and g_NCR5380_mmio/g_NCR5380 merger

[Finn Thain]

This patch series has fixes for compatibility, reliability and
performance issues and some cleanup. It also includes a new version
of Ondrej Zary's patch that merges g_NCR5380_mmio into g_NCR5380.

I've tested this patch series on a Powerbook 180. If someone would
test some of the other platforms that would be very helpful. All
drivers were compile-tested.

(Apologies for any duplicate messages.)


Finn Thain (12):
  scsi/g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio drivers
  scsi/cumana_1: Remove unused cumanascsi_setup() function
  scsi/atari_scsi: Make device register accessors re-enterant
  scsi/ncr5380: Simplify register polling limit
  scsi/ncr5380: Increase register polling limit
  scsi/ncr5380: Improve hostdata struct member alignment and
cache-ability
  scsi/ncr5380: Store IO ports and addresses in host private data
  scsi/ncr5380: Use correct types for device register accessors
  scsi/ncr5380: Pass hostdata pointer to register polling routines
  scsi/ncr5380: Expedite register polling
  scsi/ncr5380: Use correct types for DMA routines
  scsi/ncr5380: Suppress unhelpful "interrupt without IRQ bit" message

 MAINTAINERS   |   1 -
 drivers/scsi/Kconfig  |  32 +
 drivers/scsi/Makefile |   1 -
 drivers/scsi/NCR5380.c| 137 +++-
 drivers/scsi/NCR5380.h|  87 +
 drivers/scsi/arm/cumana_1.c   |  98 +++---
 drivers/scsi/arm/oak.c|  34 +++--
 drivers/scsi/atari_scsi.c |  77 ++-
 drivers/scsi/dmx3191d.c   |  20 +--
 drivers/scsi/g_NCR5380.c  | 290 --
 drivers/scsi/g_NCR5380.h  |  32 +
 drivers/scsi/g_NCR5380_mmio.c |  10 --
 drivers/scsi/mac_scsi.c   |  83 +---
 drivers/scsi/sun3_scsi.c  |  80 ++--
 14 files changed, 495 insertions(+), 487 deletions(-)
 delete mode 100644 drivers/scsi/g_NCR5380_mmio.c

-- 
2.7.3

[PATCH 10/12] scsi/ncr5380: Expedite register polling

[Finn Thain]

Avoid the call to NCR5380_poll_politely2() when possible. The call is
easily short-circuited on the PIO fast path, using the inline wrapper.
This requires that the NCR5380_read macro be made available before
any #include "NCR5380.h" so a few declarations have to be moved too.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.h  | 3 +++
 drivers/scsi/arm/cumana_1.c | 4 
 drivers/scsi/atari_scsi.c   | 6 +++---
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 2950bc0..2024566 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -310,6 +310,9 @@ static inline int NCR5380_poll_politely(struct 
NCR5380_hostdata *hostdata,
 unsigned int reg, u8 bit, u8 val,
 unsigned long wait)
 {
+   if ((NCR5380_read(reg) & bit) == val)
+   return 0;
+
return NCR5380_poll_politely2(hostdata, reg, bit, val,
reg, bit, val, wait);
 }
diff --git a/drivers/scsi/arm/cumana_1.c b/drivers/scsi/arm/cumana_1.c
index ae1d4c6..fb7600d 100644
--- a/drivers/scsi/arm/cumana_1.c
+++ b/drivers/scsi/arm/cumana_1.c
@@ -29,6 +29,10 @@
 #define NCR5380_implementation_fields  \
unsigned ctrl
 
+struct NCR5380_hostdata;
+static u8 cumanascsi_read(struct NCR5380_hostdata *, unsigned int);
+static void cumanascsi_write(struct NCR5380_hostdata *, unsigned int, u8);
+
 #include "../NCR5380.h"
 
 #define CTRL   0x16fc
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index aed69ac..f77c311 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -57,6 +57,9 @@
 
 #define NCR5380_implementation_fields   /* none */
 
+static u8 (*atari_scsi_reg_read)(unsigned int);
+static void (*atari_scsi_reg_write)(unsigned int, u8);
+
 #define NCR5380_read(reg)   atari_scsi_reg_read(reg)
 #define NCR5380_write(reg, value)   atari_scsi_reg_write(reg, value)
 
@@ -126,9 +129,6 @@ static inline unsigned long SCSI_DMA_GETADR(void)
 
 static void atari_scsi_fetch_restbytes(void);
 
-static u8 (*atari_scsi_reg_read)(unsigned int);
-static void (*atari_scsi_reg_write)(unsigned int, u8);
-
 static unsigned long   atari_dma_residual, atari_dma_startaddr;
 static short   atari_dma_active;
 /* pointer to the dribble buffer */
-- 
2.7.3

[PATCH 12/12] scsi/ncr5380: Suppress unhelpful "interrupt without IRQ bit" message

[Finn Thain]

If a NCR5380 host instance ends up on a shared interrupt line then
this printk will be a problem. It is already a problem on some Mac
models: when testing mac_scsi on a PowerBook 180 I found that PDMA
transfers (but not PIO transfers) cause the message to be logged.

These spurious interrupts don't appear to come from the DRQ signal from
the 5380. And they don't happen at all on the Mac LC III. A comment in
the NetBSD source code mentions this mystery. Testing seems to show
that we can safely ignore these interrupts.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index d479e11..03d3d1b 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -995,7 +995,7 @@ static irqreturn_t __maybe_unused NCR5380_intr(int irq, 
void *dev_id)
}
handled = 1;
} else {
-   shost_printk(KERN_NOTICE, instance, "interrupt without IRQ 
bit\n");
+   dsprintk(NDEBUG_INTR, instance, "interrupt without IRQ bit\n");
 #ifdef SUN3_SCSI_VME
dregs->csr |= CSR_DMA_ENABLE;
 #endif
-- 
2.7.3

[PATCH 12/12] scsi/ncr5380: Suppress unhelpful "interrupt without IRQ bit" message

[Finn Thain]

If a NCR5380 host instance ends up on a shared interrupt line then
this printk will be a problem. It is already a problem on some Mac
models: when testing mac_scsi on a PowerBook 180 I found that PDMA
transfers (but not PIO transfers) cause the message to be logged.

These spurious interrupts don't appear to come from the DRQ signal from
the 5380. And they don't happen at all on the Mac LC III. A comment in
the NetBSD source code mentions this mystery. Testing seems to show
that we can safely ignore these interrupts.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index d479e11..03d3d1b 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -995,7 +995,7 @@ static irqreturn_t __maybe_unused NCR5380_intr(int irq, 
void *dev_id)
}
handled = 1;
} else {
-   shost_printk(KERN_NOTICE, instance, "interrupt without IRQ 
bit\n");
+   dsprintk(NDEBUG_INTR, instance, "interrupt without IRQ bit\n");
 #ifdef SUN3_SCSI_VME
dregs->csr |= CSR_DMA_ENABLE;
 #endif
-- 
2.7.3

[PATCH 10/12] scsi/ncr5380: Expedite register polling

[Finn Thain]

Avoid the call to NCR5380_poll_politely2() when possible. The call is
easily short-circuited on the PIO fast path, using the inline wrapper.
This requires that the NCR5380_read macro be made available before
any #include "NCR5380.h" so a few declarations have to be moved too.

Signed-off-by: Finn Thain 
---
 drivers/scsi/NCR5380.h  | 3 +++
 drivers/scsi/arm/cumana_1.c | 4 
 drivers/scsi/atari_scsi.c   | 6 +++---
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 2950bc0..2024566 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -310,6 +310,9 @@ static inline int NCR5380_poll_politely(struct 
NCR5380_hostdata *hostdata,
 unsigned int reg, u8 bit, u8 val,
 unsigned long wait)
 {
+   if ((NCR5380_read(reg) & bit) == val)
+   return 0;
+
return NCR5380_poll_politely2(hostdata, reg, bit, val,
reg, bit, val, wait);
 }
diff --git a/drivers/scsi/arm/cumana_1.c b/drivers/scsi/arm/cumana_1.c
index ae1d4c6..fb7600d 100644
--- a/drivers/scsi/arm/cumana_1.c
+++ b/drivers/scsi/arm/cumana_1.c
@@ -29,6 +29,10 @@
 #define NCR5380_implementation_fields  \
unsigned ctrl
 
+struct NCR5380_hostdata;
+static u8 cumanascsi_read(struct NCR5380_hostdata *, unsigned int);
+static void cumanascsi_write(struct NCR5380_hostdata *, unsigned int, u8);
+
 #include "../NCR5380.h"
 
 #define CTRL   0x16fc
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index aed69ac..f77c311 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -57,6 +57,9 @@
 
 #define NCR5380_implementation_fields   /* none */
 
+static u8 (*atari_scsi_reg_read)(unsigned int);
+static void (*atari_scsi_reg_write)(unsigned int, u8);
+
 #define NCR5380_read(reg)   atari_scsi_reg_read(reg)
 #define NCR5380_write(reg, value)   atari_scsi_reg_write(reg, value)
 
@@ -126,9 +129,6 @@ static inline unsigned long SCSI_DMA_GETADR(void)
 
 static void atari_scsi_fetch_restbytes(void);
 
-static u8 (*atari_scsi_reg_read)(unsigned int);
-static void (*atari_scsi_reg_write)(unsigned int, u8);
-
 static unsigned long   atari_dma_residual, atari_dma_startaddr;
 static short   atari_dma_active;
 /* pointer to the dribble buffer */
-- 
2.7.3

[PATCH 03/12] scsi/atari_scsi: Make device register accessors re-enterant

[Finn Thain]

This patch fixes an old bug: accesses to device registers from the
interrupt handler (after reselection, DMA completion etc.) could mess
up a device register access elsewhere, if the latter takes place outside
of an irq lock (during selection etc.).

Signed-off-by: Finn Thain 
---
 drivers/scsi/atari_scsi.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index a59ad94..862f30c 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -670,14 +670,26 @@ static void atari_scsi_tt_reg_write(unsigned char reg, 
unsigned char value)
 
 static unsigned char atari_scsi_falcon_reg_read(unsigned char reg)
 {
-   dma_wd.dma_mode_status= (u_short)(0x88 + reg);
-   return (u_char)dma_wd.fdc_acces_seccount;
+   unsigned long flags;
+   unsigned char result;
+
+   reg += 0x88;
+   local_irq_save(flags);
+   dma_wd.dma_mode_status = (u_short)reg;
+   result = (u_char)dma_wd.fdc_acces_seccount;
+   local_irq_restore(flags);
+   return result;
 }
 
 static void atari_scsi_falcon_reg_write(unsigned char reg, unsigned char value)
 {
-   dma_wd.dma_mode_status = (u_short)(0x88 + reg);
+   unsigned long flags;
+
+   reg += 0x88;
+   local_irq_save(flags);
+   dma_wd.dma_mode_status = (u_short)reg;
dma_wd.fdc_acces_seccount = (u_short)value;
+   local_irq_restore(flags);
 }
 
 
-- 
2.7.3

[PATCH 03/12] scsi/atari_scsi: Make device register accessors re-enterant

[Finn Thain]

This patch fixes an old bug: accesses to device registers from the
interrupt handler (after reselection, DMA completion etc.) could mess
up a device register access elsewhere, if the latter takes place outside
of an irq lock (during selection etc.).

Signed-off-by: Finn Thain 
---
 drivers/scsi/atari_scsi.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index a59ad94..862f30c 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -670,14 +670,26 @@ static void atari_scsi_tt_reg_write(unsigned char reg, 
unsigned char value)
 
 static unsigned char atari_scsi_falcon_reg_read(unsigned char reg)
 {
-   dma_wd.dma_mode_status= (u_short)(0x88 + reg);
-   return (u_char)dma_wd.fdc_acces_seccount;
+   unsigned long flags;
+   unsigned char result;
+
+   reg += 0x88;
+   local_irq_save(flags);
+   dma_wd.dma_mode_status = (u_short)reg;
+   result = (u_char)dma_wd.fdc_acces_seccount;
+   local_irq_restore(flags);
+   return result;
 }
 
 static void atari_scsi_falcon_reg_write(unsigned char reg, unsigned char value)
 {
-   dma_wd.dma_mode_status = (u_short)(0x88 + reg);
+   unsigned long flags;
+
+   reg += 0x88;
+   local_irq_save(flags);
+   dma_wd.dma_mode_status = (u_short)reg;
dma_wd.fdc_acces_seccount = (u_short)value;
+   local_irq_restore(flags);
 }
 
 
-- 
2.7.3

[PATCH 04/12] scsi/ncr5380: Simplify register polling limit

[Finn Thain]

When polling a device register under irq lock the polling loop terminates
after a given number of jiffies. Make this timeout independent of the HZ
setting.

All 5380 drivers benefit from this patch, which optimizes the PIO fast
path, because they all use PIO transfers (for phases other than DATA IN
and DATA OUT). Some cards support only PIO transfers (even for DATA
phases). CPU cycles are scarce on some of these systems, so a small
improvement here makes a big difference.

Signed-off-by: Finn Thain 
---
This patch eliminates a call to jiffies_to_usecs from the fast path.
For g_NCR5380 it also eliminates a mul instruction and an imul instruction.
For ARM drivers like oak, this change eliminates an __aeabi_uidiv call.
---
 drivers/scsi/NCR5380.c | 10 --
 drivers/scsi/NCR5380.h |  5 -
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index d90fefd..330668b 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -200,13 +200,9 @@ static int NCR5380_poll_politely2(struct Scsi_Host 
*instance,
   int reg2, int bit2, int val2, int wait)
 {
struct NCR5380_hostdata *hostdata = shost_priv(instance);
+   unsigned long n = hostdata->poll_loops;
unsigned long deadline = jiffies + wait;
-   unsigned long n;
 
-   /* Busy-wait for up to 10 ms */
-   n = min(1U, jiffies_to_usecs(wait));
-   n *= hostdata->accesses_per_ms;
-   n /= 2000;
do {
if ((NCR5380_read(reg1) & bit1) == val1)
return 0;
@@ -482,6 +478,7 @@ static int NCR5380_init(struct Scsi_Host *instance, int 
flags)
struct NCR5380_hostdata *hostdata = shost_priv(instance);
int i;
unsigned long deadline;
+   unsigned long accesses_per_ms;
 
instance->max_lun = 7;
 
@@ -530,7 +527,8 @@ static int NCR5380_init(struct Scsi_Host *instance, int 
flags)
++i;
cpu_relax();
} while (time_is_after_jiffies(deadline));
-   hostdata->accesses_per_ms = i / 256;
+   accesses_per_ms = i / 256;
+   hostdata->poll_loops = NCR5380_REG_POLL_TIME * accesses_per_ms / 2;
 
return 0;
 }
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 3d0895b..ac0daa4 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -239,7 +239,7 @@ struct NCR5380_hostdata {
   * transfer to handle chip overruns */
struct work_struct main_task;
struct workqueue_struct *work_q;
-   unsigned long accesses_per_ms;  /* chip register accesses per ms */
+   unsigned long poll_loops;   /* register polling limit */
 };
 
 #ifdef __KERNEL__
@@ -252,6 +252,9 @@ struct NCR5380_cmd {
 
 #define NCR5380_PIO_CHUNK_SIZE 256
 
+/* Time limit (ms) to poll registers when IRQs are disabled, e.g. during PDMA 
*/
+#define NCR5380_REG_POLL_TIME  10
+
 static inline struct scsi_cmnd *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr)
 {
return ((struct scsi_cmnd *)ncmd_ptr) - 1;
-- 
2.7.3

[PATCH 01/12] scsi/g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio drivers

[Finn Thain]

From: Ondrej Zary 

Merge the port-mapped IO and memory-mapped IO support (with the help of
ioport_map) into the g_NCR5380 module and delete g_NCR5380_mmio.

Signed-off-by: Ondrej Zary 
Signed-off-by: Finn Thain 
---
 MAINTAINERS   |   1 -
 drivers/scsi/Kconfig  |  32 +-
 drivers/scsi/Makefile |   1 -
 drivers/scsi/g_NCR5380.c  | 252 --
 drivers/scsi/g_NCR5380.h  |  33 ++
 drivers/scsi/g_NCR5380_mmio.c |  10 --
 6 files changed, 134 insertions(+), 195 deletions(-)
 delete mode 100644 drivers/scsi/g_NCR5380_mmio.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e09df13..ffee572a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7827,7 +7827,6 @@ F:drivers/scsi/arm/oak.c
 F: drivers/scsi/atari_scsi.*
 F: drivers/scsi/dmx3191d.c
 F: drivers/scsi/g_NCR5380.*
-F: drivers/scsi/g_NCR5380_mmio.c
 F: drivers/scsi/mac_scsi.*
 F: drivers/scsi/sun3_scsi.*
 F: drivers/scsi/sun3_scsi_vme.c
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 5d54af3..b67854d 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -766,40 +766,18 @@ config SCSI_ISCI
  control unit found in the Intel(R) C600 series chipset.
 
 config SCSI_GENERIC_NCR5380
-   tristate "Generic NCR5380/53c400 SCSI PIO support"
+   tristate "Generic NCR5380/53c400 SCSI ISA card support"
depends on ISA && SCSI
select SCSI_SPI_ATTRS
---help---
- This is a driver for the old NCR 53c80 series of SCSI controllers
- on boards using PIO. Most boards such as the Trantor T130 fit this
- category, along with a large number of ISA 8bit controllers shipped
- for free with SCSI scanners. If you have a PAS16, T128 or DMX3191
- you should select the specific driver for that card rather than
- generic 5380 support.
-
- It is explained in section 3.8 of the SCSI-HOWTO, available from
- .  If it doesn't work out
- of the box, you may have to change some settings in
- .
+ This is a driver for old ISA card SCSI controllers based on a
+ NCR 5380, 53C80, 53C400, 53C400A, or DTC 436 device.
+ Most boards such as the Trantor T130 fit this category, as do
+ various 8-bit and 16-bit ISA cards bundled with SCSI scanners.
 
  To compile this driver as a module, choose M here: the
  module will be called g_NCR5380.
 
-config SCSI_GENERIC_NCR5380_MMIO
-   tristate "Generic NCR5380/53c400 SCSI MMIO support"
-   depends on ISA && SCSI
-   select SCSI_SPI_ATTRS
-   ---help---
- This is a driver for the old NCR 53c80 series of SCSI controllers
- on boards using memory mapped I/O. 
- It is explained in section 3.8 of the SCSI-HOWTO, available from
- .  If it doesn't work out
- of the box, you may have to change some settings in
- .
-
- To compile this driver as a module, choose M here: the
- module will be called g_NCR5380_mmio.
-
 config SCSI_IPS
tristate "IBM ServeRAID support"
depends on PCI && SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index a2f1c2f..9960a5a 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -77,7 +77,6 @@ obj-$(CONFIG_SCSI_IPS)+= ips.o
 obj-$(CONFIG_SCSI_FUTURE_DOMAIN)+= fdomain.o
 obj-$(CONFIG_SCSI_IN2000)  += in2000.o
 obj-$(CONFIG_SCSI_GENERIC_NCR5380) += g_NCR5380.o
-obj-$(CONFIG_SCSI_GENERIC_NCR5380_MMIO) += g_NCR5380_mmio.o
 obj-$(CONFIG_SCSI_NCR53C406A)  += NCR53c406a.o
 obj-$(CONFIG_SCSI_NCR_D700)+= 53c700.o NCR_D700.o
 obj-$(CONFIG_SCSI_NCR_Q720)+= NCR_Q720_mod.o
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index cbf0103..4d7a9de 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -64,9 +64,9 @@ static int card[] = { -1, -1, -1, -1, -1, -1, -1, -1 };
 module_param_array(card, int, NULL, 0);
 MODULE_PARM_DESC(card, "card type (0=NCR5380, 1=NCR53C400, 2=NCR53C400A, 
3=DTC3181E, 4=HP C2502)");
 
+MODULE_ALIAS("g_NCR5380_mmio");
 MODULE_LICENSE("GPL");
 
-#ifndef SCSI_G_NCR5380_MEM
 /*
  * Configure I/O address of 53C400A or DTC436 by writing magic numbers
  * to ports 0x779 and 0x379.
@@ -88,40 +88,35 @@ static void magic_configure(int idx, u8 irq, u8 magic[])
cfg = 0x80 | idx | (irq << 4);
outb(cfg, 0x379);
 }
-#endif
+
+static unsigned int ncr_53c400a_ports[] = {
+   0x280, 0x290, 0x300, 0x310, 0x330, 0x340, 0x348, 0x350, 0
+};
+static unsigned int dtc_3181e_ports[] = {
+   0x220, 0x240, 0x280, 0x2a0, 0x2c0, 0x300, 0x320, 0x340, 0
+};
+static u8 ncr_53c400a_magic[] = {  /* 53C400A & DTC436 */
+   0x59, 0xb9, 0xc5, 0xae, 0xa6
+};
+static u8 hp_c2502_magic[] = { /* HP C2502 

[PATCH 01/12] scsi/g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio drivers

[Finn Thain]

From: Ondrej Zary 

Merge the port-mapped IO and memory-mapped IO support (with the help of
ioport_map) into the g_NCR5380 module and delete g_NCR5380_mmio.

Signed-off-by: Ondrej Zary 
Signed-off-by: Finn Thain 
---
 MAINTAINERS   |   1 -
 drivers/scsi/Kconfig  |  32 +-
 drivers/scsi/Makefile |   1 -
 drivers/scsi/g_NCR5380.c  | 252 --
 drivers/scsi/g_NCR5380.h  |  33 ++
 drivers/scsi/g_NCR5380_mmio.c |  10 --
 6 files changed, 134 insertions(+), 195 deletions(-)
 delete mode 100644 drivers/scsi/g_NCR5380_mmio.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e09df13..ffee572a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7827,7 +7827,6 @@ F:drivers/scsi/arm/oak.c
 F: drivers/scsi/atari_scsi.*
 F: drivers/scsi/dmx3191d.c
 F: drivers/scsi/g_NCR5380.*
-F: drivers/scsi/g_NCR5380_mmio.c
 F: drivers/scsi/mac_scsi.*
 F: drivers/scsi/sun3_scsi.*
 F: drivers/scsi/sun3_scsi_vme.c
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 5d54af3..b67854d 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -766,40 +766,18 @@ config SCSI_ISCI
  control unit found in the Intel(R) C600 series chipset.
 
 config SCSI_GENERIC_NCR5380
-   tristate "Generic NCR5380/53c400 SCSI PIO support"
+   tristate "Generic NCR5380/53c400 SCSI ISA card support"
depends on ISA && SCSI
select SCSI_SPI_ATTRS
---help---
- This is a driver for the old NCR 53c80 series of SCSI controllers
- on boards using PIO. Most boards such as the Trantor T130 fit this
- category, along with a large number of ISA 8bit controllers shipped
- for free with SCSI scanners. If you have a PAS16, T128 or DMX3191
- you should select the specific driver for that card rather than
- generic 5380 support.
-
- It is explained in section 3.8 of the SCSI-HOWTO, available from
- .  If it doesn't work out
- of the box, you may have to change some settings in
- .
+ This is a driver for old ISA card SCSI controllers based on a
+ NCR 5380, 53C80, 53C400, 53C400A, or DTC 436 device.
+ Most boards such as the Trantor T130 fit this category, as do
+ various 8-bit and 16-bit ISA cards bundled with SCSI scanners.
 
  To compile this driver as a module, choose M here: the
  module will be called g_NCR5380.
 
-config SCSI_GENERIC_NCR5380_MMIO
-   tristate "Generic NCR5380/53c400 SCSI MMIO support"
-   depends on ISA && SCSI
-   select SCSI_SPI_ATTRS
-   ---help---
- This is a driver for the old NCR 53c80 series of SCSI controllers
- on boards using memory mapped I/O. 
- It is explained in section 3.8 of the SCSI-HOWTO, available from
- .  If it doesn't work out
- of the box, you may have to change some settings in
- .
-
- To compile this driver as a module, choose M here: the
- module will be called g_NCR5380_mmio.
-
 config SCSI_IPS
tristate "IBM ServeRAID support"
depends on PCI && SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index a2f1c2f..9960a5a 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -77,7 +77,6 @@ obj-$(CONFIG_SCSI_IPS)+= ips.o
 obj-$(CONFIG_SCSI_FUTURE_DOMAIN)+= fdomain.o
 obj-$(CONFIG_SCSI_IN2000)  += in2000.o
 obj-$(CONFIG_SCSI_GENERIC_NCR5380) += g_NCR5380.o
-obj-$(CONFIG_SCSI_GENERIC_NCR5380_MMIO) += g_NCR5380_mmio.o
 obj-$(CONFIG_SCSI_NCR53C406A)  += NCR53c406a.o
 obj-$(CONFIG_SCSI_NCR_D700)+= 53c700.o NCR_D700.o
 obj-$(CONFIG_SCSI_NCR_Q720)+= NCR_Q720_mod.o
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index cbf0103..4d7a9de 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -64,9 +64,9 @@ static int card[] = { -1, -1, -1, -1, -1, -1, -1, -1 };
 module_param_array(card, int, NULL, 0);
 MODULE_PARM_DESC(card, "card type (0=NCR5380, 1=NCR53C400, 2=NCR53C400A, 
3=DTC3181E, 4=HP C2502)");
 
+MODULE_ALIAS("g_NCR5380_mmio");
 MODULE_LICENSE("GPL");
 
-#ifndef SCSI_G_NCR5380_MEM
 /*
  * Configure I/O address of 53C400A or DTC436 by writing magic numbers
  * to ports 0x779 and 0x379.
@@ -88,40 +88,35 @@ static void magic_configure(int idx, u8 irq, u8 magic[])
cfg = 0x80 | idx | (irq << 4);
outb(cfg, 0x379);
 }
-#endif
+
+static unsigned int ncr_53c400a_ports[] = {
+   0x280, 0x290, 0x300, 0x310, 0x330, 0x340, 0x348, 0x350, 0
+};
+static unsigned int dtc_3181e_ports[] = {
+   0x220, 0x240, 0x280, 0x2a0, 0x2c0, 0x300, 0x320, 0x340, 0
+};
+static u8 ncr_53c400a_magic[] = {  /* 53C400A & DTC436 */
+   0x59, 0xb9, 0xc5, 0xae, 0xa6
+};
+static u8 hp_c2502_magic[] = { /* HP C2502 */
+   0x0f, 0x22, 0xf0, 0x20, 0x80
+};
 
 static int 

[PATCH 04/12] scsi/ncr5380: Simplify register polling limit

[Finn Thain]

When polling a device register under irq lock the polling loop terminates
after a given number of jiffies. Make this timeout independent of the HZ
setting.

All 5380 drivers benefit from this patch, which optimizes the PIO fast
path, because they all use PIO transfers (for phases other than DATA IN
and DATA OUT). Some cards support only PIO transfers (even for DATA
phases). CPU cycles are scarce on some of these systems, so a small
improvement here makes a big difference.

Signed-off-by: Finn Thain 
---
This patch eliminates a call to jiffies_to_usecs from the fast path.
For g_NCR5380 it also eliminates a mul instruction and an imul instruction.
For ARM drivers like oak, this change eliminates an __aeabi_uidiv call.
---
 drivers/scsi/NCR5380.c | 10 --
 drivers/scsi/NCR5380.h |  5 -
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index d90fefd..330668b 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -200,13 +200,9 @@ static int NCR5380_poll_politely2(struct Scsi_Host 
*instance,
   int reg2, int bit2, int val2, int wait)
 {
struct NCR5380_hostdata *hostdata = shost_priv(instance);
+   unsigned long n = hostdata->poll_loops;
unsigned long deadline = jiffies + wait;
-   unsigned long n;
 
-   /* Busy-wait for up to 10 ms */
-   n = min(1U, jiffies_to_usecs(wait));
-   n *= hostdata->accesses_per_ms;
-   n /= 2000;
do {
if ((NCR5380_read(reg1) & bit1) == val1)
return 0;
@@ -482,6 +478,7 @@ static int NCR5380_init(struct Scsi_Host *instance, int 
flags)
struct NCR5380_hostdata *hostdata = shost_priv(instance);
int i;
unsigned long deadline;
+   unsigned long accesses_per_ms;
 
instance->max_lun = 7;
 
@@ -530,7 +527,8 @@ static int NCR5380_init(struct Scsi_Host *instance, int 
flags)
++i;
cpu_relax();
} while (time_is_after_jiffies(deadline));
-   hostdata->accesses_per_ms = i / 256;
+   accesses_per_ms = i / 256;
+   hostdata->poll_loops = NCR5380_REG_POLL_TIME * accesses_per_ms / 2;
 
return 0;
 }
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index 3d0895b..ac0daa4 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -239,7 +239,7 @@ struct NCR5380_hostdata {
   * transfer to handle chip overruns */
struct work_struct main_task;
struct workqueue_struct *work_q;
-   unsigned long accesses_per_ms;  /* chip register accesses per ms */
+   unsigned long poll_loops;   /* register polling limit */
 };
 
 #ifdef __KERNEL__
@@ -252,6 +252,9 @@ struct NCR5380_cmd {
 
 #define NCR5380_PIO_CHUNK_SIZE 256
 
+/* Time limit (ms) to poll registers when IRQs are disabled, e.g. during PDMA 
*/
+#define NCR5380_REG_POLL_TIME  10
+
 static inline struct scsi_cmnd *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr)
 {
return ((struct scsi_cmnd *)ncmd_ptr) - 1;
-- 
2.7.3

Re: [PATCH] tpm: don't destroy chip device prematurely

[Jarkko Sakkinen]

On Mon, Oct 03, 2016 at 03:48:36PM +0300, Jarkko Sakkinen wrote:
> On Mon, Oct 03, 2016 at 07:05:48AM +, Winkler, Tomas wrote:
> > 
> > > On Sun, Oct 02, 2016 at 01:24:55PM +0300, Jarkko Sakkinen wrote:
> > > > On Sun, Oct 02, 2016 at 01:17:55PM +0300, Jarkko Sakkinen wrote:
> > > > > On Sun, Oct 02, 2016 at 10:39:31AM +0300, Tomas Winkler wrote:
> > > > > > In tpm_del_char_device device_del is called prior to tpm2_shutdown
> > > > > > where it is still used.
> > > > > >
> > > > > > Fortunately, so far chip->dev was used only for printouts int
> > > > > > tpm2_shutdown flow, hence system didn't crash. But with the
> > > > > > introduction of runtime power management it will result in
> > > > > > shutting down the parent device while it still in use.
> > > > > >
> > > > > > Fixes: 20e0152393b41 ("tpm: fix crash in tpm_tis
> > > > > > deinitialization")
> > > > > > Signed-off-by: Tomas Winkler 
> > > > >
> > > > > Tested-by: Jarkko Sakkinen 
> > > > > Reviewed-by: Jarkko Sakkinen 
> > > >
> > > > Applied.
> > > 
> > > This patch is wrong, I though the comments were clear. All entry points 
> > > to find
> > > the device must be deleted before we commit to shutting down the device.
> > > 
> > > You need to figure out some other way to solve your problem.
> > 
> > Please  be more specific regarding flows you think will be wrong  with
> > this patch, you must agree that the current code is broken even w/o
> > runtime pm.
> 
> Make the driver uncallable first. The worst race that can happen is that
> open("/dev/tpm0", ...) returns -EPIPE. I do not consider this fatal at
> all.

No responses for this reasonable proposal so I'll show what I mean:

/* Make the driver uncallable. */
down_write(>ops_sem);
if (chip->flags & TPM_CHIP_FLAG_TPM2)
tpm2_shutdown(chip, TPM2_SU_CLEAR);
chip->ops = NULL;
up_write(>ops_sem);

cdev_del(>cdev);
device_del(>dev);

/* Make the chip unavailable. */
mutex_lock(_lock);
idr_replace(_nums_idr, NULL, chip->dev_num);
mutex_unlock(_lock);

The worst thing that can happen is -EPIPE.

/Jarkko

Dearest Chosen One

[Mrs. Amina]

Dearest Chosen One

With Due Respect And Humanity,I was compelled to write to you under a 
humanitarian ground. My name is Mrs Amina Mohammed, My Husband was a director 
in a trading company here in Cote D Ivoire.We were married for 36 years without 
a child.  He died after Cardiac Arteries operation.

And Recently,My Doctor told me that I would not last for the next Eight months 
due to my cancer problem and stroke) .Before my husband died he lodged the sum 
of four million five hundred thousand dollars,(US$15,500.000.) in a bank here 
In Ivory Coast.

Presently,this money is still in a bank here. Having known my condition I 
decided to donate this fund to any good God fearing man or woman that will 
utilize this fund the way I am going to instruct herein.

I want somebody that will use this fund according to the desire of my late 
husband to help Less privilaged people,orphanages,widows and propagating the 
word of God.

I took this decision because I don't have any child that will inherit this 
fund,And I don't want in away where this money will be used in an unGodly way. 
This is why I am taking this decision to hand you over this Fund.

I am not afraid of death hence I know where I am going. I want you to always 
remember me in your daily prayers because of my up coming Cancer Surgery.

Write back as soon as possible any delay in your reply will give me room in 
sourcing another person for this same purpose.

God bless you as I hope to hear from you as soon.

Yours Sincerely Sister

Amina Mohammed

Re: [PATCH] tpm: don't destroy chip device prematurely

[Jarkko Sakkinen]

On Mon, Oct 03, 2016 at 03:48:36PM +0300, Jarkko Sakkinen wrote:
> On Mon, Oct 03, 2016 at 07:05:48AM +, Winkler, Tomas wrote:
> > 
> > > On Sun, Oct 02, 2016 at 01:24:55PM +0300, Jarkko Sakkinen wrote:
> > > > On Sun, Oct 02, 2016 at 01:17:55PM +0300, Jarkko Sakkinen wrote:
> > > > > On Sun, Oct 02, 2016 at 10:39:31AM +0300, Tomas Winkler wrote:
> > > > > > In tpm_del_char_device device_del is called prior to tpm2_shutdown
> > > > > > where it is still used.
> > > > > >
> > > > > > Fortunately, so far chip->dev was used only for printouts int
> > > > > > tpm2_shutdown flow, hence system didn't crash. But with the
> > > > > > introduction of runtime power management it will result in
> > > > > > shutting down the parent device while it still in use.
> > > > > >
> > > > > > Fixes: 20e0152393b41 ("tpm: fix crash in tpm_tis
> > > > > > deinitialization")
> > > > > > Signed-off-by: Tomas Winkler 
> > > > >
> > > > > Tested-by: Jarkko Sakkinen 
> > > > > Reviewed-by: Jarkko Sakkinen 
> > > >
> > > > Applied.
> > > 
> > > This patch is wrong, I though the comments were clear. All entry points 
> > > to find
> > > the device must be deleted before we commit to shutting down the device.
> > > 
> > > You need to figure out some other way to solve your problem.
> > 
> > Please  be more specific regarding flows you think will be wrong  with
> > this patch, you must agree that the current code is broken even w/o
> > runtime pm.
> 
> Make the driver uncallable first. The worst race that can happen is that
> open("/dev/tpm0", ...) returns -EPIPE. I do not consider this fatal at
> all.

No responses for this reasonable proposal so I'll show what I mean:

/* Make the driver uncallable. */
down_write(>ops_sem);
if (chip->flags & TPM_CHIP_FLAG_TPM2)
tpm2_shutdown(chip, TPM2_SU_CLEAR);
chip->ops = NULL;
up_write(>ops_sem);

cdev_del(>cdev);
device_del(>dev);

/* Make the chip unavailable. */
mutex_lock(_lock);
idr_replace(_nums_idr, NULL, chip->dev_num);
mutex_unlock(_lock);

The worst thing that can happen is -EPIPE.

/Jarkko

Dearest Chosen One

[Mrs. Amina]

Dearest Chosen One

With Due Respect And Humanity,I was compelled to write to you under a 
humanitarian ground. My name is Mrs Amina Mohammed, My Husband was a director 
in a trading company here in Cote D Ivoire.We were married for 36 years without 
a child.  He died after Cardiac Arteries operation.

And Recently,My Doctor told me that I would not last for the next Eight months 
due to my cancer problem and stroke) .Before my husband died he lodged the sum 
of four million five hundred thousand dollars,(US$15,500.000.) in a bank here 
In Ivory Coast.

Presently,this money is still in a bank here. Having known my condition I 
decided to donate this fund to any good God fearing man or woman that will 
utilize this fund the way I am going to instruct herein.

I want somebody that will use this fund according to the desire of my late 
husband to help Less privilaged people,orphanages,widows and propagating the 
word of God.

I took this decision because I don't have any child that will inherit this 
fund,And I don't want in away where this money will be used in an unGodly way. 
This is why I am taking this decision to hand you over this Fund.

I am not afraid of death hence I know where I am going. I want you to always 
remember me in your daily prayers because of my up coming Cancer Surgery.

Write back as soon as possible any delay in your reply will give me room in 
sourcing another person for this same purpose.

God bless you as I hope to hear from you as soon.

Yours Sincerely Sister

Amina Mohammed

Re: [PATCH -resend 6/6] frv, mn10300, s390, sh: remove empty vga.h

[Martin Schwidefsky]

On Mon,  3 Oct 2016 11:07:36 +0200
Jiri Slaby  wrote:

> Provided the architectures do not need any special handling (they seem
> not to support vga at all, actually), there is no need to have an
> empty vga.h. Let them refer to the generic one instead.
> 
> Signed-off-by: Jiri Slaby 
> Cc: David Howells 
> Cc: Martin Schwidefsky 
> Cc: Heiko Carstens 
> Cc: Yoshinori Sato 
> Cc: Rich Felker 
> Cc: linux-am33-l...@redhat.com
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@vger.kernel.org

Acked-by: Martin Schwidefsky 

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH -resend 6/6] frv, mn10300, s390, sh: remove empty vga.h

[Martin Schwidefsky]

On Mon,  3 Oct 2016 11:07:36 +0200
Jiri Slaby  wrote:

> Provided the architectures do not need any special handling (they seem
> not to support vga at all, actually), there is no need to have an
> empty vga.h. Let them refer to the generic one instead.
> 
> Signed-off-by: Jiri Slaby 
> Cc: David Howells 
> Cc: Martin Schwidefsky 
> Cc: Heiko Carstens 
> Cc: Yoshinori Sato 
> Cc: Rich Felker 
> Cc: linux-am33-l...@redhat.com
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@vger.kernel.org

Acked-by: Martin Schwidefsky 

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

[PATCH 1/2 v3] pci-hyperv: properly handle pci bus remove

[Long Li]

From: Long Li 

hv_pci_devices_present is called in hv_pci_remove when we remove a PCI device 
from host (e.g. by disabling SRIOV on a device). In hv_pci_remove, the bus is 
already removed before the call, so we don't need to rescan the bus in the 
workqueue scheduled from hv_pci_devices_present. By introducing status 
hv_pcibus_removed, we can avoid this situation.

Signed-off-by: Long Li 
Tested-by: Cathy Avery 
Reported-by: Xiaofeng Wang 
---
 drivers/pci/host/pci-hyperv.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index a8deeca..4a37598 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -348,6 +348,7 @@ enum hv_pcibus_state {
hv_pcibus_init = 0,
hv_pcibus_probed,
hv_pcibus_installed,
+   hv_pcibus_removed,
hv_pcibus_maximum
 };
 
@@ -1481,13 +1482,24 @@ static void pci_devices_present_work(struct work_struct 
*work)
put_pcichild(hpdev, hv_pcidev_ref_initial);
}
 
-   /* Tell the core to rescan bus because there may have been changes. */
-   if (hbus->state == hv_pcibus_installed) {
+   switch (hbus->state) {
+   case hv_pcibus_installed:
+   /*
+* Tell the core to rescan bus
+* because there may have been changes.
+*/
pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
pci_unlock_rescan_remove();
-   } else {
+   break;
+
+   case hv_pcibus_init:
+   case hv_pcibus_probed:
survey_child_resources(hbus);
+   break;
+
+   default:
+   break;
}
 
up(>enum_sem);
@@ -2163,6 +2175,7 @@ static int hv_pci_probe(struct hv_device *hdev,
hbus = kzalloc(sizeof(*hbus), GFP_KERNEL);
if (!hbus)
return -ENOMEM;
+   hbus->state = hv_pcibus_init;
 
/*
 * The PCI bus "domain" is what is called "segment" in ACPI and
@@ -2305,6 +2318,7 @@ static int hv_pci_remove(struct hv_device *hdev)
pci_stop_root_bus(hbus->pci_bus);
pci_remove_root_bus(hbus->pci_bus);
pci_unlock_rescan_remove();
+   hbus->state = hv_pcibus_removed;
}
 
ret = hv_send_resources_released(hdev);
-- 
1.8.5.6

[PATCH 1/2 v3] pci-hyperv: properly handle pci bus remove

[Long Li]

From: Long Li 

hv_pci_devices_present is called in hv_pci_remove when we remove a PCI device 
from host (e.g. by disabling SRIOV on a device). In hv_pci_remove, the bus is 
already removed before the call, so we don't need to rescan the bus in the 
workqueue scheduled from hv_pci_devices_present. By introducing status 
hv_pcibus_removed, we can avoid this situation.

Signed-off-by: Long Li 
Tested-by: Cathy Avery 
Reported-by: Xiaofeng Wang 
---
 drivers/pci/host/pci-hyperv.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index a8deeca..4a37598 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -348,6 +348,7 @@ enum hv_pcibus_state {
hv_pcibus_init = 0,
hv_pcibus_probed,
hv_pcibus_installed,
+   hv_pcibus_removed,
hv_pcibus_maximum
 };
 
@@ -1481,13 +1482,24 @@ static void pci_devices_present_work(struct work_struct 
*work)
put_pcichild(hpdev, hv_pcidev_ref_initial);
}
 
-   /* Tell the core to rescan bus because there may have been changes. */
-   if (hbus->state == hv_pcibus_installed) {
+   switch (hbus->state) {
+   case hv_pcibus_installed:
+   /*
+* Tell the core to rescan bus
+* because there may have been changes.
+*/
pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
pci_unlock_rescan_remove();
-   } else {
+   break;
+
+   case hv_pcibus_init:
+   case hv_pcibus_probed:
survey_child_resources(hbus);
+   break;
+
+   default:
+   break;
}
 
up(>enum_sem);
@@ -2163,6 +2175,7 @@ static int hv_pci_probe(struct hv_device *hdev,
hbus = kzalloc(sizeof(*hbus), GFP_KERNEL);
if (!hbus)
return -ENOMEM;
+   hbus->state = hv_pcibus_init;
 
/*
 * The PCI bus "domain" is what is called "segment" in ACPI and
@@ -2305,6 +2318,7 @@ static int hv_pci_remove(struct hv_device *hdev)
pci_stop_root_bus(hbus->pci_bus);
pci_remove_root_bus(hbus->pci_bus);
pci_unlock_rescan_remove();
+   hbus->state = hv_pcibus_removed;
}
 
ret = hv_send_resources_released(hdev);
-- 
1.8.5.6

[PATCH 2/2 v3] pci-hyperv: lock pci bus on device eject

[Long Li]

From: Long Li 

A PCI_EJECT message can arrive at the same time we are calling 
pci_scan_child_bus in the workqueue for the previous PCI_BUS_RELATIONS message 
or in create_root_hv_pci_bus(), in this case we could potentailly modify the 
bus from multiple places. Properly lock the bus access.

Thanks Dexuan Cui  for pointing out the race condition in 
create_root_hv_pci_bus().

Signed-off-by: Long Li 
Tested-by: Cathy Avery 
Reported-by: Xiaofeng Wang 
---
 drivers/pci/host/pci-hyperv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 4a37598..33c75c9 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1198,9 +1198,11 @@ static int create_root_hv_pci_bus(struct 
hv_pcibus_device *hbus)
hbus->pci_bus->msi = >msi_chip;
hbus->pci_bus->msi->dev = >hdev->device;
 
+   pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
pci_bus_assign_resources(hbus->pci_bus);
pci_bus_add_devices(hbus->pci_bus);
+   pci_unlock_rescan_remove();
hbus->state = hv_pcibus_installed;
return 0;
 }
@@ -1590,8 +1592,10 @@ static void hv_eject_device_work(struct work_struct 
*work)
pdev = pci_get_domain_bus_and_slot(hpdev->hbus->sysdata.domain, 0,
   wslot);
if (pdev) {
+   pci_lock_rescan_remove();
pci_stop_and_remove_bus_device(pdev);
pci_dev_put(pdev);
+   pci_unlock_rescan_remove();
}
 
memset(, 0, sizeof(ctxt));
-- 
1.8.5.6

[PATCH 2/2 v3] pci-hyperv: lock pci bus on device eject

[Long Li]

From: Long Li 

A PCI_EJECT message can arrive at the same time we are calling 
pci_scan_child_bus in the workqueue for the previous PCI_BUS_RELATIONS message 
or in create_root_hv_pci_bus(), in this case we could potentailly modify the 
bus from multiple places. Properly lock the bus access.

Thanks Dexuan Cui  for pointing out the race condition in 
create_root_hv_pci_bus().

Signed-off-by: Long Li 
Tested-by: Cathy Avery 
Reported-by: Xiaofeng Wang 
---
 drivers/pci/host/pci-hyperv.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 4a37598..33c75c9 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1198,9 +1198,11 @@ static int create_root_hv_pci_bus(struct 
hv_pcibus_device *hbus)
hbus->pci_bus->msi = >msi_chip;
hbus->pci_bus->msi->dev = >hdev->device;
 
+   pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
pci_bus_assign_resources(hbus->pci_bus);
pci_bus_add_devices(hbus->pci_bus);
+   pci_unlock_rescan_remove();
hbus->state = hv_pcibus_installed;
return 0;
 }
@@ -1590,8 +1592,10 @@ static void hv_eject_device_work(struct work_struct 
*work)
pdev = pci_get_domain_bus_and_slot(hpdev->hbus->sysdata.domain, 0,
   wslot);
if (pdev) {
+   pci_lock_rescan_remove();
pci_stop_and_remove_bus_device(pdev);
pci_dev_put(pdev);
+   pci_unlock_rescan_remove();
}
 
memset(, 0, sizeof(ctxt));
-- 
1.8.5.6

Re: [PATCH 14/15] staging: wlang-ng: fix line style warnings in prism2sta.c

[Sergio Paracuellos]

El 2016年10月03日 a las 20:18, Joe Perches escribió:

On Mon, 2016-10-03 at 20:12 +0200, Sergio Paracuellos wrote:

El 2016年10月03日 a las 18:16, Joe Perches escribió:

Perhaps better as   hw->scanresults = kmemdup(inf, sizeof(*inf), 
GFP_ATOMIC);

I agree. But because all the code is full of sizeof(struct xxx) I though
it would be bettter to follow the actual style and not change only one...
I don't have any problem in fix this patch and resend it. What should I do?


I suggest not fixing this patch.

Maybe just send another patch changing all the applicable
sizeof(struct ) uses to sizeof(*var) with the appropriate
line wrapping.



Ok, I think that it would be better too. Let's do that.

Thanks,
Sergio Paracuellos

Re: [PATCH 14/15] staging: wlang-ng: fix line style warnings in prism2sta.c

[Sergio Paracuellos]

El 2016年10月03日 a las 20:18, Joe Perches escribió:

On Mon, 2016-10-03 at 20:12 +0200, Sergio Paracuellos wrote:

El 2016年10月03日 a las 18:16, Joe Perches escribió:

Perhaps better as   hw->scanresults = kmemdup(inf, sizeof(*inf), 
GFP_ATOMIC);

I agree. But because all the code is full of sizeof(struct xxx) I though
it would be bettter to follow the actual style and not change only one...
I don't have any problem in fix this patch and resend it. What should I do?


I suggest not fixing this patch.

Maybe just send another patch changing all the applicable
sizeof(struct ) uses to sizeof(*var) with the appropriate
line wrapping.



Ok, I think that it would be better too. Let's do that.

Thanks,
Sergio Paracuellos

Re: [PATCH 2/3] zram: support page-based parallel write

[Sergey Senozhatsky]

Hello,

Cc Jens and block-dev,

I'll outline the commit message for Jens and blockdev people, may be
someone will have some thoughts/ideas/opinions:

> On (09/22/16 15:42), Minchan Kim wrote:
: zram supports stream-based parallel compression. IOW, it can support
: parallel compression on SMP system only if each cpus has streams.
: For example, assuming 4 CPU system, there are 4 sources for compressing
: in system and each source must be located in each CPUs for full
: parallel compression.
:
: So, if there is *one* stream in the system, it cannot be compressed
: in parallel although the system supports multiple CPUs. This patch
: aims to overcome such weakness.
:
: The idea is to use multiple background threads to compress pages
: in idle CPU and foreground just queues BIOs without interrupting
: while other CPUs consumes pages in BIO to compress.
: It means zram begins to support asynchronous writeback to increase
: write bandwidth.


is there any way of addressing this issues? [a silly idea] can we, for
instance, ask the bock layer to split request and put pages into different
queues (assuming that we run in blk-mq mode)? because this looks like a
common issue, and it may be a bit too late to fix it in zram driver.
any thoughts?


[..]
> Could you retest the benchmark without direct IO? Instead of dio,
> I used fsync_on_close to flush buffered IO.
> 
> DIO isn't normal workload compared to buffered IO. The reason I used DIO
> for zram benchmark was that it's handy to transfer IO to block layer 
> effectively
> and no-noise of page cache.
> If we use buffered IO, the result would be fake as dirty page was just
> queued in page cache without any flushing.
> I think you know already it very well so no need to explan any more. :)
> 
> More important thing is current zram is poor for parallel IO.
> Let's thing two usecases, zram-swap, zram-fs.

well, that's why we use direct=1 in benchmarks - to test the peformance
of zram; not anything else. but I can run fsync_on_close=1 tests as well
(see later).


> 1) zram-swap
> 
> parallel IO can be done only where every CPU have reclaim context.
> IOW,
> 
> 1. kswapd on CPU 0
> 2. A process direct reclaim on CPU 1
> 3. process direct reclaim on CPU 2
> 4. process direct reclaim on CPU 3
>
> I don't think it's usual workload. Most of time, a kswapd and a process
> direct reclaim in embedded platform workload. The point is we can not
> use full bandwidth.

hm. but we are on an SMP system and at least one process had to start
direct reclaim, which basically increases chances of direct reclaims
from other CPUs, should running processes there request big enough
memory allocations. I really see no reasons to rule this possibility
out.


> 2) zram-fs
> 
> Currently, there is a work per bdi. So, without fsync(and friends),
> every IO submit would be done via that work on worker thread.
> It means the IO couldn't be parallelized. However, if we use fsync,
> it could be parallelized but it depends on the sync granuarity.
> For exmaple, if your test application uses fsync directly, the IO
> would be done in the CPU context your application running on. So,
> if you has 4 test applications, every CPU could be utilized.
> However, if you test application doesn't use fsync directly and
> parant process calls sync if every test child applications, the
> IO could be done 2 CPU context(1 is parent process context and
> other is bdi work context).
> So, In summary, we were poor for parallel IO workload without
> sync or DIO.

but this again looks [to me] like a more general problem which can be
addressed somewhere up the stack. zram is not absolutely silly here - it
just does what it's being asked to do. any block drivers/block device can
suffer from that.




TEST


new tests results; same tests, same conditions, same .config.
4-way test:
- BASE zram, fio direct=1
- BASE zram, fio fsync_on_close=1
- NEW zram, fio direct=1
- NEW zram, fio fsync_on_close=1



and what I see is that:
 - new zram is x3 times slower when we do a lot of direct=1 IO
and
 - 10% faster when we use buffered IO (fsync_on_close); but not always;
   for instance, test execution time is longer (a reproducible behavior)
   when the number of jobs equals the number of CPUs - 4.



if flushing is a problem for new zram during direct=1 test, then I would
assume that writing a huge number of small files (creat/write 4k/close)
would probably have same fsync_on_close=1 performance as direct=1.


ENV
===

   x86_64 SMP (4 CPUs), "bare zram" 3g, lzo, static compression buffer.


TEST COMMAND


  ZRAM_SIZE=3G ZRAM_COMP_ALG=lzo LOG_SUFFIX={NEW, OLD} FIO_LOOPS=2 
./zram-fio-test.sh


EXECUTED TESTS
==

  - [seq-read]
  - [rand-read]
  - [seq-write]
  - [rand-write]
  - [mixed-seq]
  - [mixed-rand]


fio-perf-o-meter.sh test-fio-zram-OLD test-fio-zram-OLD-flush test-fio-zram-NEW 
test-fio-zram-NEW-flush
Processing test-fio-zram-OLD
Processing test-fio-zram-OLD-flush
Processing test-fio-zram-NEW

Re: [PATCH 2/3] zram: support page-based parallel write

[Sergey Senozhatsky]

Hello,

Cc Jens and block-dev,

I'll outline the commit message for Jens and blockdev people, may be
someone will have some thoughts/ideas/opinions:

> On (09/22/16 15:42), Minchan Kim wrote:
: zram supports stream-based parallel compression. IOW, it can support
: parallel compression on SMP system only if each cpus has streams.
: For example, assuming 4 CPU system, there are 4 sources for compressing
: in system and each source must be located in each CPUs for full
: parallel compression.
:
: So, if there is *one* stream in the system, it cannot be compressed
: in parallel although the system supports multiple CPUs. This patch
: aims to overcome such weakness.
:
: The idea is to use multiple background threads to compress pages
: in idle CPU and foreground just queues BIOs without interrupting
: while other CPUs consumes pages in BIO to compress.
: It means zram begins to support asynchronous writeback to increase
: write bandwidth.


is there any way of addressing this issues? [a silly idea] can we, for
instance, ask the bock layer to split request and put pages into different
queues (assuming that we run in blk-mq mode)? because this looks like a
common issue, and it may be a bit too late to fix it in zram driver.
any thoughts?


[..]
> Could you retest the benchmark without direct IO? Instead of dio,
> I used fsync_on_close to flush buffered IO.
> 
> DIO isn't normal workload compared to buffered IO. The reason I used DIO
> for zram benchmark was that it's handy to transfer IO to block layer 
> effectively
> and no-noise of page cache.
> If we use buffered IO, the result would be fake as dirty page was just
> queued in page cache without any flushing.
> I think you know already it very well so no need to explan any more. :)
> 
> More important thing is current zram is poor for parallel IO.
> Let's thing two usecases, zram-swap, zram-fs.

well, that's why we use direct=1 in benchmarks - to test the peformance
of zram; not anything else. but I can run fsync_on_close=1 tests as well
(see later).


> 1) zram-swap
> 
> parallel IO can be done only where every CPU have reclaim context.
> IOW,
> 
> 1. kswapd on CPU 0
> 2. A process direct reclaim on CPU 1
> 3. process direct reclaim on CPU 2
> 4. process direct reclaim on CPU 3
>
> I don't think it's usual workload. Most of time, a kswapd and a process
> direct reclaim in embedded platform workload. The point is we can not
> use full bandwidth.

hm. but we are on an SMP system and at least one process had to start
direct reclaim, which basically increases chances of direct reclaims
from other CPUs, should running processes there request big enough
memory allocations. I really see no reasons to rule this possibility
out.


> 2) zram-fs
> 
> Currently, there is a work per bdi. So, without fsync(and friends),
> every IO submit would be done via that work on worker thread.
> It means the IO couldn't be parallelized. However, if we use fsync,
> it could be parallelized but it depends on the sync granuarity.
> For exmaple, if your test application uses fsync directly, the IO
> would be done in the CPU context your application running on. So,
> if you has 4 test applications, every CPU could be utilized.
> However, if you test application doesn't use fsync directly and
> parant process calls sync if every test child applications, the
> IO could be done 2 CPU context(1 is parent process context and
> other is bdi work context).
> So, In summary, we were poor for parallel IO workload without
> sync or DIO.

but this again looks [to me] like a more general problem which can be
addressed somewhere up the stack. zram is not absolutely silly here - it
just does what it's being asked to do. any block drivers/block device can
suffer from that.




TEST


new tests results; same tests, same conditions, same .config.
4-way test:
- BASE zram, fio direct=1
- BASE zram, fio fsync_on_close=1
- NEW zram, fio direct=1
- NEW zram, fio fsync_on_close=1



and what I see is that:
 - new zram is x3 times slower when we do a lot of direct=1 IO
and
 - 10% faster when we use buffered IO (fsync_on_close); but not always;
   for instance, test execution time is longer (a reproducible behavior)
   when the number of jobs equals the number of CPUs - 4.



if flushing is a problem for new zram during direct=1 test, then I would
assume that writing a huge number of small files (creat/write 4k/close)
would probably have same fsync_on_close=1 performance as direct=1.


ENV
===

   x86_64 SMP (4 CPUs), "bare zram" 3g, lzo, static compression buffer.


TEST COMMAND


  ZRAM_SIZE=3G ZRAM_COMP_ALG=lzo LOG_SUFFIX={NEW, OLD} FIO_LOOPS=2 
./zram-fio-test.sh


EXECUTED TESTS
==

  - [seq-read]
  - [rand-read]
  - [seq-write]
  - [rand-write]
  - [mixed-seq]
  - [mixed-rand]


fio-perf-o-meter.sh test-fio-zram-OLD test-fio-zram-OLD-flush test-fio-zram-NEW 
test-fio-zram-NEW-flush
Processing test-fio-zram-OLD
Processing test-fio-zram-OLD-flush
Processing test-fio-zram-NEW

[PATCH 1/2] cgroup: Add generic cgroup subsystem permission checks

[John Stultz]

From: Colin Cross 

Rather than using explicit euid == 0 checks when trying to move
tasks into a cgroup, move permission checks into each specific
cgroup subsystem. If a subsystem does not specify a 'allow_attach'
handler, then we fall back to doing the checks the old way.

This patch adds a 'allow_attach' handler instead of reusing the
'can_attach' handler, since if the 'can_attach' handler was
reused, a new cgroup that implements 'can_attach' but not the
permission checks could end up with no permission checks at all.

This also includes folded down fixes from:
  Christian Poetzsch 
  Amit Pundir 

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 
Cc: Dmitry Shmidt 
Cc: Todd Kjos 
Cc: Christian Poetzsch 
Cc: Amit Pundir 
Original-Author: San Mehat 
Signed-off-by: Colin Cross 
[jstultz: Rewording of commit message, folded down fixes]
Signed-off-by: John Stultz 
---
 Documentation/cgroup-v1/cgroups.txt |  9 +
 include/linux/cgroup-defs.h |  1 +
 kernel/cgroup.c | 40 +++--
 3 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/Documentation/cgroup-v1/cgroups.txt 
b/Documentation/cgroup-v1/cgroups.txt
index 308e5ff..295f026 100644
--- a/Documentation/cgroup-v1/cgroups.txt
+++ b/Documentation/cgroup-v1/cgroups.txt
@@ -578,6 +578,15 @@ is completely unused; @cgrp->parent is still valid. (Note 
- can also
 be called for a newly-created cgroup if an error occurs after this
 subsystem's create() method has been called for the new cgroup).
 
+int allow_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
+(cgroup_mutex held by caller)
+
+Called prior to moving a task into a cgroup; if the subsystem
+returns an error, this will abort the attach operation.  Used
+to extend the permission checks - if all subsystems in a cgroup
+return 0, the attach will be allowed to proceed, even if the
+default permission check (root or same user) fails.
+
 int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
 (cgroup_mutex held by caller)
 
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 5b17de6..0f4548c 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -441,6 +441,7 @@ struct cgroup_subsys {
void (*css_free)(struct cgroup_subsys_state *css);
void (*css_reset)(struct cgroup_subsys_state *css);
 
+   int (*allow_attach)(struct cgroup_taskset *tset);
int (*can_attach)(struct cgroup_taskset *tset);
void (*cancel_attach)(struct cgroup_taskset *tset);
void (*attach)(struct cgroup_taskset *tset);
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index d6b729b..e6afe2d 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2833,6 +2833,25 @@ static int cgroup_attach_task(struct cgroup *dst_cgrp,
return ret;
 }
 
+static int cgroup_allow_attach(struct cgroup *cgrp, struct cgroup_taskset 
*tset)
+{
+   struct cgroup_subsys_state *css;
+   int i;
+   int ret;
+
+   for_each_css(css, i, cgrp) {
+   if (css->ss->allow_attach) {
+   ret = css->ss->allow_attach(tset);
+   if (ret)
+   return ret;
+   } else {
+   return -EACCES;
+   }
+   }
+
+   return 0;
+}
+
 static int cgroup_procs_write_permission(struct task_struct *task,
 struct cgroup *dst_cgrp,
 struct kernfs_open_file *of)
@@ -2847,8 +2866,25 @@ static int cgroup_procs_write_permission(struct 
task_struct *task,
 */
if (!uid_eq(cred->euid, GLOBAL_ROOT_UID) &&
!uid_eq(cred->euid, tcred->uid) &&
-   !uid_eq(cred->euid, tcred->suid))
-   ret = -EACCES;
+   !uid_eq(cred->euid, tcred->suid)) {
+   /*
+* if the default permission check fails, give each
+* cgroup a chance to extend the permission check
+*/
+   struct cgroup_taskset tset = {
+   .src_csets = LIST_HEAD_INIT(tset.src_csets),
+   .dst_csets = LIST_HEAD_INIT(tset.dst_csets),
+   .csets = _csets,
+   };
+   struct css_set *cset;
+
+   cset = task_css_set(task);
+   list_add(>mg_node, _csets);
+   ret = cgroup_allow_attach(dst_cgrp, );
+   list_del(_csets);
+   if (ret)
+   ret = -EACCES;
+   

[PATCH 1/2] cgroup: Add generic cgroup subsystem permission checks

[John Stultz]

From: Colin Cross 

Rather than using explicit euid == 0 checks when trying to move
tasks into a cgroup, move permission checks into each specific
cgroup subsystem. If a subsystem does not specify a 'allow_attach'
handler, then we fall back to doing the checks the old way.

This patch adds a 'allow_attach' handler instead of reusing the
'can_attach' handler, since if the 'can_attach' handler was
reused, a new cgroup that implements 'can_attach' but not the
permission checks could end up with no permission checks at all.

This also includes folded down fixes from:
  Christian Poetzsch 
  Amit Pundir 

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 
Cc: Dmitry Shmidt 
Cc: Todd Kjos 
Cc: Christian Poetzsch 
Cc: Amit Pundir 
Original-Author: San Mehat 
Signed-off-by: Colin Cross 
[jstultz: Rewording of commit message, folded down fixes]
Signed-off-by: John Stultz 
---
 Documentation/cgroup-v1/cgroups.txt |  9 +
 include/linux/cgroup-defs.h |  1 +
 kernel/cgroup.c | 40 +++--
 3 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/Documentation/cgroup-v1/cgroups.txt 
b/Documentation/cgroup-v1/cgroups.txt
index 308e5ff..295f026 100644
--- a/Documentation/cgroup-v1/cgroups.txt
+++ b/Documentation/cgroup-v1/cgroups.txt
@@ -578,6 +578,15 @@ is completely unused; @cgrp->parent is still valid. (Note 
- can also
 be called for a newly-created cgroup if an error occurs after this
 subsystem's create() method has been called for the new cgroup).
 
+int allow_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
+(cgroup_mutex held by caller)
+
+Called prior to moving a task into a cgroup; if the subsystem
+returns an error, this will abort the attach operation.  Used
+to extend the permission checks - if all subsystems in a cgroup
+return 0, the attach will be allowed to proceed, even if the
+default permission check (root or same user) fails.
+
 int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
 (cgroup_mutex held by caller)
 
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 5b17de6..0f4548c 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -441,6 +441,7 @@ struct cgroup_subsys {
void (*css_free)(struct cgroup_subsys_state *css);
void (*css_reset)(struct cgroup_subsys_state *css);
 
+   int (*allow_attach)(struct cgroup_taskset *tset);
int (*can_attach)(struct cgroup_taskset *tset);
void (*cancel_attach)(struct cgroup_taskset *tset);
void (*attach)(struct cgroup_taskset *tset);
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index d6b729b..e6afe2d 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2833,6 +2833,25 @@ static int cgroup_attach_task(struct cgroup *dst_cgrp,
return ret;
 }
 
+static int cgroup_allow_attach(struct cgroup *cgrp, struct cgroup_taskset 
*tset)
+{
+   struct cgroup_subsys_state *css;
+   int i;
+   int ret;
+
+   for_each_css(css, i, cgrp) {
+   if (css->ss->allow_attach) {
+   ret = css->ss->allow_attach(tset);
+   if (ret)
+   return ret;
+   } else {
+   return -EACCES;
+   }
+   }
+
+   return 0;
+}
+
 static int cgroup_procs_write_permission(struct task_struct *task,
 struct cgroup *dst_cgrp,
 struct kernfs_open_file *of)
@@ -2847,8 +2866,25 @@ static int cgroup_procs_write_permission(struct 
task_struct *task,
 */
if (!uid_eq(cred->euid, GLOBAL_ROOT_UID) &&
!uid_eq(cred->euid, tcred->uid) &&
-   !uid_eq(cred->euid, tcred->suid))
-   ret = -EACCES;
+   !uid_eq(cred->euid, tcred->suid)) {
+   /*
+* if the default permission check fails, give each
+* cgroup a chance to extend the permission check
+*/
+   struct cgroup_taskset tset = {
+   .src_csets = LIST_HEAD_INIT(tset.src_csets),
+   .dst_csets = LIST_HEAD_INIT(tset.dst_csets),
+   .csets = _csets,
+   };
+   struct css_set *cset;
+
+   cset = task_css_set(task);
+   list_add(>mg_node, _csets);
+   ret = cgroup_allow_attach(dst_cgrp, );
+   list_del(_csets);
+   if (ret)
+   ret = -EACCES;
+   }
 
if (!ret && cgroup_on_dfl(dst_cgrp)) {
struct super_block *sb = of->file->f_path.dentry->d_sb;
-- 
1.9.1

[PATCH 2/2] cgroup: Add a allow_attach policy for Android

[John Stultz]

From: Rom Lemarchand 

If CONFIG_CGROUP_NICE_ATTACH is enabled, this implements an
allow_attach policy for Android, which allows any process with
CAP_SYS_NICE to move tasks across cpuset and cpuctrl cgroups.

This includes folded down fixes from:
  Dmitry Shmidt 
  Riley Andrews 
  Amit Pundir 

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 
Cc: Dmitry Shmidt 
Cc: Todd Kjos 
Cc: Christian Poetzsch 
Cc: Amit Pundir 
Signed-off-by: Rom Lemarchand 
[jstultz: Majorly reworked to make this policy function
 configurable, and folded in fixes]
Signed-off-by: John Stultz 
---
 include/linux/cgroup.h | 16 
 init/Kconfig   |  8 
 kernel/cgroup.c| 22 ++
 kernel/cpuset.c|  3 +++
 kernel/sched/core.c|  3 +++
 5 files changed, 52 insertions(+)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 984f73b..eab4311 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -554,6 +554,17 @@ static inline void pr_cont_cgroup_path(struct cgroup *cgrp)
pr_cont_kernfs_path(cgrp->kn);
 }
 
+#ifdef CONFIG_CGROUP_NICE_ATTACH
+/*
+ * Default Android check for whether the current process is allowed to move a
+ * task across cgroups, either because CAP_SYS_NICE is set or because the uid
+ * of the calling process is the same as the moved task or because we are
+ * running as root.
+ * Returns 0 if this is allowed, or -EACCES otherwise.
+ */
+int cgroup_nice_allow_attach(struct cgroup_taskset *tset);
+#endif
+
 #else /* !CONFIG_CGROUPS */
 
 struct cgroup_subsys_state;
@@ -647,6 +658,11 @@ copy_cgroup_ns(unsigned long flags, struct user_namespace 
*user_ns,
return old_ns;
 }
 
+static inline int subsys_cgroup_allow_attach(void *tset)
+{
+   return -EINVAL;
+}
+
 #endif /* !CONFIG_CGROUPS */
 
 static inline void get_cgroup_ns(struct cgroup_namespace *ns)
diff --git a/init/Kconfig b/init/Kconfig
index cac3f09..c000734 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1021,6 +1021,14 @@ config DEBUG_BLK_CGROUP
Enable some debugging help. Currently it exports additional stat
files in a cgroup which can be useful for debugging.
 
+config CGROUP_NICE_ATTACH
+   bool "Enabled Android-style loosening of perm checks for attachment"
+   default n
+   ---help---
+   Allows non-root processes to add arbitrary processes to cpuset and
+   cpuctrl cgroups if they have CAP_SYS_NICE set. This is useful for
+   Android.
+
 config CGROUP_WRITEBACK
bool
depends on MEMCG && BLK_CGROUP
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index e6afe2d..a53f0be 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2833,6 +2833,28 @@ static int cgroup_attach_task(struct cgroup *dst_cgrp,
return ret;
 }
 
+#ifdef CONFIG_CGROUP_NICE_ATTACH
+int cgroup_nice_allow_attach(struct cgroup_taskset *tset)
+{
+   const struct cred *cred = current_cred(), *tcred;
+   struct task_struct *task;
+   struct cgroup_subsys_state *css;
+
+   if (capable(CAP_SYS_NICE))
+   return 0;
+
+   cgroup_taskset_for_each(task, css, tset) {
+   tcred = __task_cred(task);
+
+   if (current != task && !uid_eq(cred->euid, tcred->uid) &&
+   !uid_eq(cred->euid, tcred->suid))
+   return -EACCES;
+   }
+
+   return 0;
+}
+#endif
+
 static int cgroup_allow_attach(struct cgroup *cgrp, struct cgroup_taskset 
*tset)
 {
struct cgroup_subsys_state *css;
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 2b4c20a..87aede4 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2100,6 +2100,9 @@ struct cgroup_subsys cpuset_cgrp_subsys = {
.css_offline= cpuset_css_offline,
.css_free   = cpuset_css_free,
.can_attach = cpuset_can_attach,
+#ifdef CONFIG_CGROUP_NICE_ATTACH
+   .allow_attach   = cgroup_nice_allow_attach,
+#endif
.cancel_attach  = cpuset_cancel_attach,
.attach = cpuset_attach,
.post_attach= cpuset_post_attach,
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 44817c6..5573505 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -8657,6 +8657,9 @@ struct cgroup_subsys cpu_cgrp_subsys = {
.fork   = cpu_cgroup_fork,
.can_attach = cpu_cgroup_can_attach,
.attach = cpu_cgroup_attach,
+#ifdef CONFIG_CGROUP_NICE_ATTACH
+   .allow_attach   = cgroup_nice_allow_attach,
+#endif
.legacy_cftypes = cpu_files,
.early_init = true,
 };
-- 

[RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

[John Stultz]

As a heads up, this is just a first RFC and not a submission.

I wanted to send this out again, as the last time I submitted this
(https://marc.info/?l=linux-kernel=143217972215192=2) the
discussion got out into the separate issue of how Android at one
time abused memcg (but I believe now memcg is no longer used).

So for this revision, I've removed any memcg usage so we can try
to focus on just the actively used cpuset and cpuctrl cgroups.

Android currently loosens the cgroup attchment permissions, allowing
tasks with CAP_SYS_NICE to be able to allow tasks to move arbitrary
tasks across cgroups.

Android currently uses cgroups to bound tasks in various states (ie:
foreground applications, background applications, audio application,
system audio, and system tasks), to specific cpus as well as to limit
cpu time. This allows for things like audio applications to be
SCHED_FIFO but not run-away hogging infinite cpu, and background task
cpu usage to be similarly cputime limited, and kept to only low-power
cpus.

The migration of a task from the foreground to background, or to
elevate a task to audio priority, may be done by system service that
does not run as root. So this patch allows processes with CAP_SYS_NICE
to be able to migrate tasks between cgroups.  I suspect if there was a
specific cap (CAP_SYS_CHANGE_CGROUP) for this, it would be usable here,
but in its absence, they've overloaded CAP_SYS_NICE for this use.

At first glance, overloading CAP_SYS_NICE seems a bit hackish, but this
shows that there is a active and widely deployed use for different cgroup
attachment rules then what is currently available.

I've tried to rework the patches so this attachment policy is build
time configurable, and wanted to send them out for review so folks
might give their thoughts on this implementation and what they might
see as a better way to go about achieving the same goal.

Thoughts and feedback would be appriciated!

thanks
-john

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 
Cc: Dmitry Shmidt 
Cc: Todd Kjos 
Cc: Christian Poetzsch 
Cc: Amit Pundir 

Colin Cross (1):
  cgroup: Add generic cgroup subsystem permission checks

Rom Lemarchand (1):
  cgroup: Add a allow_attach policy for Android

 Documentation/cgroup-v1/cgroups.txt |  9 ++
 include/linux/cgroup-defs.h |  1 +
 include/linux/cgroup.h  | 16 ++
 init/Kconfig|  7 +
 kernel/cgroup.c | 61 +++--
 kernel/cpuset.c |  3 ++
 kernel/sched/core.c |  3 ++
 7 files changed, 98 insertions(+), 2 deletions(-)

-- 
1.9.1

[PATCH 2/2] cgroup: Add a allow_attach policy for Android

[John Stultz]

From: Rom Lemarchand 

If CONFIG_CGROUP_NICE_ATTACH is enabled, this implements an
allow_attach policy for Android, which allows any process with
CAP_SYS_NICE to move tasks across cpuset and cpuctrl cgroups.

This includes folded down fixes from:
  Dmitry Shmidt 
  Riley Andrews 
  Amit Pundir 

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 
Cc: Dmitry Shmidt 
Cc: Todd Kjos 
Cc: Christian Poetzsch 
Cc: Amit Pundir 
Signed-off-by: Rom Lemarchand 
[jstultz: Majorly reworked to make this policy function
 configurable, and folded in fixes]
Signed-off-by: John Stultz 
---
 include/linux/cgroup.h | 16 
 init/Kconfig   |  8 
 kernel/cgroup.c| 22 ++
 kernel/cpuset.c|  3 +++
 kernel/sched/core.c|  3 +++
 5 files changed, 52 insertions(+)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 984f73b..eab4311 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -554,6 +554,17 @@ static inline void pr_cont_cgroup_path(struct cgroup *cgrp)
pr_cont_kernfs_path(cgrp->kn);
 }
 
+#ifdef CONFIG_CGROUP_NICE_ATTACH
+/*
+ * Default Android check for whether the current process is allowed to move a
+ * task across cgroups, either because CAP_SYS_NICE is set or because the uid
+ * of the calling process is the same as the moved task or because we are
+ * running as root.
+ * Returns 0 if this is allowed, or -EACCES otherwise.
+ */
+int cgroup_nice_allow_attach(struct cgroup_taskset *tset);
+#endif
+
 #else /* !CONFIG_CGROUPS */
 
 struct cgroup_subsys_state;
@@ -647,6 +658,11 @@ copy_cgroup_ns(unsigned long flags, struct user_namespace 
*user_ns,
return old_ns;
 }
 
+static inline int subsys_cgroup_allow_attach(void *tset)
+{
+   return -EINVAL;
+}
+
 #endif /* !CONFIG_CGROUPS */
 
 static inline void get_cgroup_ns(struct cgroup_namespace *ns)
diff --git a/init/Kconfig b/init/Kconfig
index cac3f09..c000734 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1021,6 +1021,14 @@ config DEBUG_BLK_CGROUP
Enable some debugging help. Currently it exports additional stat
files in a cgroup which can be useful for debugging.
 
+config CGROUP_NICE_ATTACH
+   bool "Enabled Android-style loosening of perm checks for attachment"
+   default n
+   ---help---
+   Allows non-root processes to add arbitrary processes to cpuset and
+   cpuctrl cgroups if they have CAP_SYS_NICE set. This is useful for
+   Android.
+
 config CGROUP_WRITEBACK
bool
depends on MEMCG && BLK_CGROUP
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index e6afe2d..a53f0be 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2833,6 +2833,28 @@ static int cgroup_attach_task(struct cgroup *dst_cgrp,
return ret;
 }
 
+#ifdef CONFIG_CGROUP_NICE_ATTACH
+int cgroup_nice_allow_attach(struct cgroup_taskset *tset)
+{
+   const struct cred *cred = current_cred(), *tcred;
+   struct task_struct *task;
+   struct cgroup_subsys_state *css;
+
+   if (capable(CAP_SYS_NICE))
+   return 0;
+
+   cgroup_taskset_for_each(task, css, tset) {
+   tcred = __task_cred(task);
+
+   if (current != task && !uid_eq(cred->euid, tcred->uid) &&
+   !uid_eq(cred->euid, tcred->suid))
+   return -EACCES;
+   }
+
+   return 0;
+}
+#endif
+
 static int cgroup_allow_attach(struct cgroup *cgrp, struct cgroup_taskset 
*tset)
 {
struct cgroup_subsys_state *css;
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 2b4c20a..87aede4 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2100,6 +2100,9 @@ struct cgroup_subsys cpuset_cgrp_subsys = {
.css_offline= cpuset_css_offline,
.css_free   = cpuset_css_free,
.can_attach = cpuset_can_attach,
+#ifdef CONFIG_CGROUP_NICE_ATTACH
+   .allow_attach   = cgroup_nice_allow_attach,
+#endif
.cancel_attach  = cpuset_cancel_attach,
.attach = cpuset_attach,
.post_attach= cpuset_post_attach,
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 44817c6..5573505 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -8657,6 +8657,9 @@ struct cgroup_subsys cpu_cgrp_subsys = {
.fork   = cpu_cgroup_fork,
.can_attach = cpu_cgroup_can_attach,
.attach = cpu_cgroup_attach,
+#ifdef CONFIG_CGROUP_NICE_ATTACH
+   .allow_attach   = cgroup_nice_allow_attach,
+#endif
.legacy_cftypes = cpu_files,
.early_init = true,
 };
-- 
1.9.1

[RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions

[John Stultz]

As a heads up, this is just a first RFC and not a submission.

I wanted to send this out again, as the last time I submitted this
(https://marc.info/?l=linux-kernel=143217972215192=2) the
discussion got out into the separate issue of how Android at one
time abused memcg (but I believe now memcg is no longer used).

So for this revision, I've removed any memcg usage so we can try
to focus on just the actively used cpuset and cpuctrl cgroups.

Android currently loosens the cgroup attchment permissions, allowing
tasks with CAP_SYS_NICE to be able to allow tasks to move arbitrary
tasks across cgroups.

Android currently uses cgroups to bound tasks in various states (ie:
foreground applications, background applications, audio application,
system audio, and system tasks), to specific cpus as well as to limit
cpu time. This allows for things like audio applications to be
SCHED_FIFO but not run-away hogging infinite cpu, and background task
cpu usage to be similarly cputime limited, and kept to only low-power
cpus.

The migration of a task from the foreground to background, or to
elevate a task to audio priority, may be done by system service that
does not run as root. So this patch allows processes with CAP_SYS_NICE
to be able to migrate tasks between cgroups.  I suspect if there was a
specific cap (CAP_SYS_CHANGE_CGROUP) for this, it would be usable here,
but in its absence, they've overloaded CAP_SYS_NICE for this use.

At first glance, overloading CAP_SYS_NICE seems a bit hackish, but this
shows that there is a active and widely deployed use for different cgroup
attachment rules then what is currently available.

I've tried to rework the patches so this attachment policy is build
time configurable, and wanted to send them out for review so folks
might give their thoughts on this implementation and what they might
see as a better way to go about achieving the same goal.

Thoughts and feedback would be appriciated!

thanks
-john

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 
Cc: Dmitry Shmidt 
Cc: Todd Kjos 
Cc: Christian Poetzsch 
Cc: Amit Pundir 

Colin Cross (1):
  cgroup: Add generic cgroup subsystem permission checks

Rom Lemarchand (1):
  cgroup: Add a allow_attach policy for Android

 Documentation/cgroup-v1/cgroups.txt |  9 ++
 include/linux/cgroup-defs.h |  1 +
 include/linux/cgroup.h  | 16 ++
 init/Kconfig|  7 +
 kernel/cgroup.c | 61 +++--
 kernel/cpuset.c |  3 ++
 kernel/sched/core.c |  3 ++
 7 files changed, 98 insertions(+), 2 deletions(-)

-- 
1.9.1

Re: [PATCH v1 1/2] ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid

[maitysanchayan]

Hello Stefan,

On 16-10-03 11:05:59, Stefan Agner wrote:
> On 2016-10-03 05:50, Sanchayan Maity wrote:
> > Enable DMA for DSPI on Vybrid.
> 
> Hm, we have that in 4.4 already, is that meant for 4.1?

Sorry?! I send this out for mainline and the patch series is based
on top of shawn's for-next branch. Did not intend it for our downstream
4.1.

Thanks.

Regards,
Stefan.

> 
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vf-colibri.dtsi | 4 
> >  arch/arm/boot/dts/vfxxx.dtsi  | 6 ++
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
> > b/arch/arm/boot/dts/vf-colibri.dtsi
> > index b741709..21bfef9 100644
> > --- a/arch/arm/boot/dts/vf-colibri.dtsi
> > +++ b/arch/arm/boot/dts/vf-colibri.dtsi
> > @@ -108,6 +108,10 @@
> > status = "okay";
> >  };
> >  
> > + {
> > +   status = "okay";
> > +};
> > +
> >   {
> > pinctrl-names = "default";
> > pinctrl-0 = <_esdhc1>;
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 2c13ec6..eac4213 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -194,6 +194,9 @@
> > clocks = < VF610_CLK_DSPI0>;
> > clock-names = "dspi";
> > spi-num-chipselects = <6>;
> > +   dmas = < 1 12>,
> > +   < 1 13>;
> > +   dma-names = "rx", "tx";
> > status = "disabled";
> > };
> >  
> > @@ -206,6 +209,9 @@
> > clocks = < VF610_CLK_DSPI1>;
> > clock-names = "dspi";
> > spi-num-chipselects = <4>;
> > +   dmas = < 1 14>,
> > +   < 1 15>;
> > +   dma-names = "rx", "tx";
> > status = "disabled";
> > };

Re: [PATCH v1 1/2] ARM: dts: vfxxx: Enable DMA for DSPI on Vybrid

[maitysanchayan]

Hello Stefan,

On 16-10-03 11:05:59, Stefan Agner wrote:
> On 2016-10-03 05:50, Sanchayan Maity wrote:
> > Enable DMA for DSPI on Vybrid.
> 
> Hm, we have that in 4.4 already, is that meant for 4.1?

Sorry?! I send this out for mainline and the patch series is based
on top of shawn's for-next branch. Did not intend it for our downstream
4.1.

Thanks.

Regards,
Stefan.

> 
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vf-colibri.dtsi | 4 
> >  arch/arm/boot/dts/vfxxx.dtsi  | 6 ++
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
> > b/arch/arm/boot/dts/vf-colibri.dtsi
> > index b741709..21bfef9 100644
> > --- a/arch/arm/boot/dts/vf-colibri.dtsi
> > +++ b/arch/arm/boot/dts/vf-colibri.dtsi
> > @@ -108,6 +108,10 @@
> > status = "okay";
> >  };
> >  
> > + {
> > +   status = "okay";
> > +};
> > +
> >   {
> > pinctrl-names = "default";
> > pinctrl-0 = <_esdhc1>;
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 2c13ec6..eac4213 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -194,6 +194,9 @@
> > clocks = < VF610_CLK_DSPI0>;
> > clock-names = "dspi";
> > spi-num-chipselects = <6>;
> > +   dmas = < 1 12>,
> > +   < 1 13>;
> > +   dma-names = "rx", "tx";
> > status = "disabled";
> > };
> >  
> > @@ -206,6 +209,9 @@
> > clocks = < VF610_CLK_DSPI1>;
> > clock-names = "dspi";
> > spi-num-chipselects = <4>;
> > +   dmas = < 1 14>,
> > +   < 1 15>;
> > +   dma-names = "rx", "tx";
> > status = "disabled";
> > };

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

[Fengguang Wu]

CC Michal. It looks like a microblaze specific error. I'll blacklist
this old error on microblaze if there are no good solutions.

Sorry for the noise!

On Fri, Sep 23, 2016 at 05:11:32PM -0400, Nicolas Pitre wrote:

On Thu, 22 Sep 2016, kbuild test robot wrote:


Hi Nicolas,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   7d1e042314619115153a0f6f06e4552c09a50e13
commit: 461a5e51060c93f5844113f4be9dba513cc92830 do_div(): generic optimization 
for constant divisor on 32-bit machines
date:   10 months ago
config: microblaze-mmu_defconfig (attached as .config)
compiler: microblaze-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 461a5e51060c93f5844113f4be9dba513cc92830
# save the attached .config to linux build tree
make.cross ARCH=microblaze

All errors (new ones prefixed by >>):

   net/built-in.o: In function `rpc_print_iostats':
>> net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'
   scripts/link-vmlinux.sh: line 52:  5714 Segmentation fault  ${LD} 
${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds} ${KBUILD_VMLINUX_INIT} 
--start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}


The problem must be at your end, especially if the toolchain exhibits
segmentation faults.

Following exactly the instructions above, I get:

[...]
 LD  vmlinux
 SORTEX  vmlinux
 SYSMAP  System.map
 OBJCOPY arch/microblaze/boot/linux.bin
 Building modules, stage 2.
 MODPOST 3 modules
 CC  crypto/drbg.mod.o
 CC  crypto/echainiv.mod.o
 CC  crypto/jitterentropy_rng.mod.o
 LD [M]  crypto/jitterentropy_rng.ko
 LD [M]  crypto/drbg.ko
 LD [M]  crypto/echainiv.ko
Kernel: arch/microblaze/boot/linux.bin is ready  (#1)


Nicolas

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

[Fengguang Wu]

CC Michal. It looks like a microblaze specific error. I'll blacklist
this old error on microblaze if there are no good solutions.

Sorry for the noise!

On Fri, Sep 23, 2016 at 05:11:32PM -0400, Nicolas Pitre wrote:

On Thu, 22 Sep 2016, kbuild test robot wrote:


Hi Nicolas,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   7d1e042314619115153a0f6f06e4552c09a50e13
commit: 461a5e51060c93f5844113f4be9dba513cc92830 do_div(): generic optimization 
for constant divisor on 32-bit machines
date:   10 months ago
config: microblaze-mmu_defconfig (attached as .config)
compiler: microblaze-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 461a5e51060c93f5844113f4be9dba513cc92830
# save the attached .config to linux build tree
make.cross ARCH=microblaze

All errors (new ones prefixed by >>):

   net/built-in.o: In function `rpc_print_iostats':
>> net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'
   scripts/link-vmlinux.sh: line 52:  5714 Segmentation fault  ${LD} 
${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds} ${KBUILD_VMLINUX_INIT} 
--start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}


The problem must be at your end, especially if the toolchain exhibits
segmentation faults.

Following exactly the instructions above, I get:

[...]
 LD  vmlinux
 SORTEX  vmlinux
 SYSMAP  System.map
 OBJCOPY arch/microblaze/boot/linux.bin
 Building modules, stage 2.
 MODPOST 3 modules
 CC  crypto/drbg.mod.o
 CC  crypto/echainiv.mod.o
 CC  crypto/jitterentropy_rng.mod.o
 LD [M]  crypto/jitterentropy_rng.ko
 LD [M]  crypto/drbg.ko
 LD [M]  crypto/echainiv.ko
Kernel: arch/microblaze/boot/linux.bin is ready  (#1)


Nicolas

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

[Michael Ellerman]

Peter Zijlstra  writes:

> On Mon, Oct 03, 2016 at 03:29:32PM +0200, Jiri Olsa wrote:
>> On Fri, Sep 23, 2016 at 06:37:47PM +0200, Peter Zijlstra wrote:
>> > On Wed, Sep 21, 2016 at 03:55:34PM +0200, Jiri Olsa wrote:
>> > >   stack backtrace:
>> > >   CPU: 9 PID: 2998 Comm: ls Tainted: GW   4.8.0-rc5+ #7
>> > >   Call Trace:
>> > >   [c002f7933150] [c094b1f8] .dump_stack+0xe0/0x14c 
>> > > (unreliable)
>> > >   [c002f79331e0] [c013c468] 
>> > > .lockdep_rcu_suspicious+0x138/0x180
>> > >   [c002f7933270] [c01005d8] .___might_sleep+0x278/0x2e0
>> > >   [c002f7933300] [c0935584] .mutex_lock_nested+0x64/0x5a0
>> > >   [c002f7933410] [c023084c] 
>> > > .perf_event_ctx_lock_nested+0x16c/0x380
>> > >   [c002f7933500] [c0230a80] .perf_event_disable+0x20/0x60
>> > >   [c002f7933580] [c093aeec] 
>> > > .hw_breakpoint_handler+0x29c/0x2b0
>> > >   [c002f7933630] [c00f671c] .notifier_call_chain+0x7c/0xf0
>> > >   [c002f79336d0] [c00f6abc] 
>> > > .__atomic_notifier_call_chain+0xbc/0x1c0
>> > >   [c002f7933780] [c00f6c40] .notify_die+0x70/0xd0
>> > >   [c002f7933820] [c001a74c] .do_break+0x4c/0x100
>> > >   [c002f7933920] [c00089fc] handle_dabr_fault+0x14/0x48
>> > 
>> > Well, that lockdep warning only says you should not be taking sleeping
>> > locks while holding rcu_read_lock(), which is true. It does not say the
>> > context you're doing this is cannot sleep.
>> > 
>> > I'm not familiar enough with the PPC stuff to tell if the DIE_DABR_MATCH
>> > trap context is atomic or not and this Changelog doesn't tell me.
>> 
>> ping
>
> So I think all the DIE notifiers are atomic, which means this would
> indeed be the thing to do. That said, I didn't see anything similar on
> other BP implementations.

Seems everyone is being called from the same notifier, which is atomic,
but powerpc is the only arch that does perf_event_disable().

> So it would be good to also explain why PPC needs this in the first
> place.

Unfortunately I don't really know the code, and the original author is AWOL.

But AFAICS perf_event_disable() is only called here:

if (!stepped) {
WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
"0x%lx will be disabled.", info->address);
perf_event_disable(bp);
goto out;
}

Which is where we cope with the possibility that we couldn't emulate the
instruction that hit the breakpoint. Seems that is not an issue on x86,
or it's handled elsewhere?

We should fix emulate_step() if it failed to emulate something it
should have, but there will always be the possibility that it fails.

Instead of calling perf_event_disable() we could just add a flag to
arch_hw_breakpoint that says we hit an error on the event, and block
reinstalling it in arch_install_hw_breakpoint().

cheers

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

[Michael Ellerman]

Peter Zijlstra  writes:

> On Mon, Oct 03, 2016 at 03:29:32PM +0200, Jiri Olsa wrote:
>> On Fri, Sep 23, 2016 at 06:37:47PM +0200, Peter Zijlstra wrote:
>> > On Wed, Sep 21, 2016 at 03:55:34PM +0200, Jiri Olsa wrote:
>> > >   stack backtrace:
>> > >   CPU: 9 PID: 2998 Comm: ls Tainted: GW   4.8.0-rc5+ #7
>> > >   Call Trace:
>> > >   [c002f7933150] [c094b1f8] .dump_stack+0xe0/0x14c 
>> > > (unreliable)
>> > >   [c002f79331e0] [c013c468] 
>> > > .lockdep_rcu_suspicious+0x138/0x180
>> > >   [c002f7933270] [c01005d8] .___might_sleep+0x278/0x2e0
>> > >   [c002f7933300] [c0935584] .mutex_lock_nested+0x64/0x5a0
>> > >   [c002f7933410] [c023084c] 
>> > > .perf_event_ctx_lock_nested+0x16c/0x380
>> > >   [c002f7933500] [c0230a80] .perf_event_disable+0x20/0x60
>> > >   [c002f7933580] [c093aeec] 
>> > > .hw_breakpoint_handler+0x29c/0x2b0
>> > >   [c002f7933630] [c00f671c] .notifier_call_chain+0x7c/0xf0
>> > >   [c002f79336d0] [c00f6abc] 
>> > > .__atomic_notifier_call_chain+0xbc/0x1c0
>> > >   [c002f7933780] [c00f6c40] .notify_die+0x70/0xd0
>> > >   [c002f7933820] [c001a74c] .do_break+0x4c/0x100
>> > >   [c002f7933920] [c00089fc] handle_dabr_fault+0x14/0x48
>> > 
>> > Well, that lockdep warning only says you should not be taking sleeping
>> > locks while holding rcu_read_lock(), which is true. It does not say the
>> > context you're doing this is cannot sleep.
>> > 
>> > I'm not familiar enough with the PPC stuff to tell if the DIE_DABR_MATCH
>> > trap context is atomic or not and this Changelog doesn't tell me.
>> 
>> ping
>
> So I think all the DIE notifiers are atomic, which means this would
> indeed be the thing to do. That said, I didn't see anything similar on
> other BP implementations.

Seems everyone is being called from the same notifier, which is atomic,
but powerpc is the only arch that does perf_event_disable().

> So it would be good to also explain why PPC needs this in the first
> place.

Unfortunately I don't really know the code, and the original author is AWOL.

But AFAICS perf_event_disable() is only called here:

if (!stepped) {
WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
"0x%lx will be disabled.", info->address);
perf_event_disable(bp);
goto out;
}

Which is where we cope with the possibility that we couldn't emulate the
instruction that hit the breakpoint. Seems that is not an issue on x86,
or it's handled elsewhere?

We should fix emulate_step() if it failed to emulate something it
should have, but there will always be the possibility that it fails.

Instead of calling perf_event_disable() we could just add a flag to
arch_hw_breakpoint that says we hit an error on the event, and block
reinstalling it in arch_install_hw_breakpoint().

cheers

Re: [PATCH 05/12] ASoC: sun4i-codec: Add support for A31 playback through headphone output

[Chen-Yu Tsai]

On Mon, Oct 3, 2016 at 7:47 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Mon, Oct 03, 2016 at 07:07:57PM +0800, Chen-Yu Tsai wrote:
>> The A31 has a similar codec to the A10/A20. The PCM parts are very
>> similar, with just different register offsets. The analog paths are
>> very different. There are more inputs and outputs.
>>
>> The quirks structure is expanded to include different register offsets
>> and separate callbacks for creating the ASoC card. Also the DMA burst
>> length is increased to 8. While the A10 DMA engine supports bursts of
>> 1, 4 and 8, the A31 engine only supports 1 and 8.
>>
>> This patch adds support for the basic playback path of the A31 codec,
>> from the DAC to the headphones. Headphone detection, microphone,
>> signaling, other inputs/outputs and capture will be added later.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  .../devicetree/bindings/sound/sun4i-codec.txt  |   6 +-
>>  sound/soc/sunxi/sun4i-codec.c  | 396 
>> +
>>  2 files changed, 334 insertions(+), 68 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt 
>> b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
>> index 0dce690f78f5..1d2411cea98d 100644
>> --- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
>> +++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
>> @@ -1,8 +1,10 @@
>>  * Allwinner A10 Codec
>>
>>  Required properties:
>> -- compatible: must be either "allwinner,sun4i-a10-codec" or
>> -  "allwinner,sun7i-a20-codec"
>> +- compatible: must be one of the following compatibles:
>> + - "allwinner,sun4i-a10-codec"
>> + - "allwinner,sun6i-a31-codec"
>> + - "allwinner,sun7i-a20-codec"
>
> I'm guessing it needs a reset line?

There isn't one. I know, weird.

>>  - reg: must contain the registers location and length
>>  - interrupts: must contain the codec interrupt
>>  - dmas: DMA channels for tx and rx dma. See the DMA client binding,
>> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
>> index e047ec06d538..9916714ecb71 100644
>> --- a/sound/soc/sunxi/sun4i-codec.c
>> +++ b/sound/soc/sunxi/sun4i-codec.c
>> @@ -3,6 +3,7 @@
>>   * Copyright 2014 Jon Smirl 
>>   * Copyright 2015 Maxime Ripard 
>>   * Copyright 2015 Adam Sampson 
>> + * Copyright 2016 Chen-Yu Tsai 
>>   *
>>   * Based on the Allwinner SDK driver, released under the GPL.
>>   *
>> @@ -24,8 +25,9 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -55,6 +57,8 @@
>>  #define SUN4I_CODEC_DAC_FIFOC_FIFO_FLUSH (0)
>>  #define SUN4I_CODEC_DAC_FIFOS(0x08)
>>  #define SUN4I_CODEC_DAC_TXDATA   (0x0c)
>> +
>> +/* Codec DAC side analog signal controls */
>>  #define SUN4I_CODEC_DAC_ACTL (0x10)
>>  #define SUN4I_CODEC_DAC_ACTL_DACAENR (31)
>>  #define SUN4I_CODEC_DAC_ACTL_DACAENL (30)
>> @@ -81,6 +85,8 @@
>>  #define SUN4I_CODEC_ADC_FIFOC_FIFO_FLUSH (0)
>>  #define SUN4I_CODEC_ADC_FIFOS(0x20)
>>  #define SUN4I_CODEC_ADC_RXDATA   (0x24)
>> +
>> +/* Codec ADC side analog signal controls */
>>  #define SUN4I_CODEC_ADC_ACTL (0x28)
>>  #define SUN4I_CODEC_ADC_ACTL_ADC_R_EN(31)
>>  #define SUN4I_CODEC_ADC_ACTL_ADC_L_EN(30)
>> @@ -93,18 +99,106 @@
>>  #define SUN4I_CODEC_ADC_ACTL_DDE (3)
>>  #define SUN4I_CODEC_ADC_DEBUG(0x2c)
>>
>> -/* Other various ADC registers */
>> +/* FIFO counters */
>>  #define SUN4I_CODEC_DAC_TXCNT(0x30)
>>  #define SUN4I_CODEC_ADC_RXCNT(0x34)
>> +
>> +/* Other various ADC registers */
>>  #define SUN7I_CODEC_AC_DAC_CAL   (0x38)
>>  #define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
>>
>> +/*** sun6i specific register offsets ***/
>> +#define SUN6I_CODEC_ADC_FIFOC(0x10)
>> +#define SUN6I_CODEC_ADC_FIFOC_EN_AD  (28)
>> +#define SUN6I_CODEC_ADC_FIFOS(0x14)
>> +#define SUN6I_CODEC_ADC_RXDATA   (0x18)
>> +#define SUN6I_CODEC_OM_DACA_CTRL (0x20)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_DACAREN (31)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_DACALEN (30)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIXEN  (29)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_LMIXEN  (28)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC1   (23)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC2   (22)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIX_PHONE  (21)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIX_PHONEP

Re: [PATCH 05/12] ASoC: sun4i-codec: Add support for A31 playback through headphone output

[Chen-Yu Tsai]

On Mon, Oct 3, 2016 at 7:47 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Mon, Oct 03, 2016 at 07:07:57PM +0800, Chen-Yu Tsai wrote:
>> The A31 has a similar codec to the A10/A20. The PCM parts are very
>> similar, with just different register offsets. The analog paths are
>> very different. There are more inputs and outputs.
>>
>> The quirks structure is expanded to include different register offsets
>> and separate callbacks for creating the ASoC card. Also the DMA burst
>> length is increased to 8. While the A10 DMA engine supports bursts of
>> 1, 4 and 8, the A31 engine only supports 1 and 8.
>>
>> This patch adds support for the basic playback path of the A31 codec,
>> from the DAC to the headphones. Headphone detection, microphone,
>> signaling, other inputs/outputs and capture will be added later.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  .../devicetree/bindings/sound/sun4i-codec.txt  |   6 +-
>>  sound/soc/sunxi/sun4i-codec.c  | 396 
>> +
>>  2 files changed, 334 insertions(+), 68 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt 
>> b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
>> index 0dce690f78f5..1d2411cea98d 100644
>> --- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
>> +++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
>> @@ -1,8 +1,10 @@
>>  * Allwinner A10 Codec
>>
>>  Required properties:
>> -- compatible: must be either "allwinner,sun4i-a10-codec" or
>> -  "allwinner,sun7i-a20-codec"
>> +- compatible: must be one of the following compatibles:
>> + - "allwinner,sun4i-a10-codec"
>> + - "allwinner,sun6i-a31-codec"
>> + - "allwinner,sun7i-a20-codec"
>
> I'm guessing it needs a reset line?

There isn't one. I know, weird.

>>  - reg: must contain the registers location and length
>>  - interrupts: must contain the codec interrupt
>>  - dmas: DMA channels for tx and rx dma. See the DMA client binding,
>> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
>> index e047ec06d538..9916714ecb71 100644
>> --- a/sound/soc/sunxi/sun4i-codec.c
>> +++ b/sound/soc/sunxi/sun4i-codec.c
>> @@ -3,6 +3,7 @@
>>   * Copyright 2014 Jon Smirl 
>>   * Copyright 2015 Maxime Ripard 
>>   * Copyright 2015 Adam Sampson 
>> + * Copyright 2016 Chen-Yu Tsai 
>>   *
>>   * Based on the Allwinner SDK driver, released under the GPL.
>>   *
>> @@ -24,8 +25,9 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -55,6 +57,8 @@
>>  #define SUN4I_CODEC_DAC_FIFOC_FIFO_FLUSH (0)
>>  #define SUN4I_CODEC_DAC_FIFOS(0x08)
>>  #define SUN4I_CODEC_DAC_TXDATA   (0x0c)
>> +
>> +/* Codec DAC side analog signal controls */
>>  #define SUN4I_CODEC_DAC_ACTL (0x10)
>>  #define SUN4I_CODEC_DAC_ACTL_DACAENR (31)
>>  #define SUN4I_CODEC_DAC_ACTL_DACAENL (30)
>> @@ -81,6 +85,8 @@
>>  #define SUN4I_CODEC_ADC_FIFOC_FIFO_FLUSH (0)
>>  #define SUN4I_CODEC_ADC_FIFOS(0x20)
>>  #define SUN4I_CODEC_ADC_RXDATA   (0x24)
>> +
>> +/* Codec ADC side analog signal controls */
>>  #define SUN4I_CODEC_ADC_ACTL (0x28)
>>  #define SUN4I_CODEC_ADC_ACTL_ADC_R_EN(31)
>>  #define SUN4I_CODEC_ADC_ACTL_ADC_L_EN(30)
>> @@ -93,18 +99,106 @@
>>  #define SUN4I_CODEC_ADC_ACTL_DDE (3)
>>  #define SUN4I_CODEC_ADC_DEBUG(0x2c)
>>
>> -/* Other various ADC registers */
>> +/* FIFO counters */
>>  #define SUN4I_CODEC_DAC_TXCNT(0x30)
>>  #define SUN4I_CODEC_ADC_RXCNT(0x34)
>> +
>> +/* Other various ADC registers */
>>  #define SUN7I_CODEC_AC_DAC_CAL   (0x38)
>>  #define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
>>
>> +/*** sun6i specific register offsets ***/
>> +#define SUN6I_CODEC_ADC_FIFOC(0x10)
>> +#define SUN6I_CODEC_ADC_FIFOC_EN_AD  (28)
>> +#define SUN6I_CODEC_ADC_FIFOS(0x14)
>> +#define SUN6I_CODEC_ADC_RXDATA   (0x18)
>> +#define SUN6I_CODEC_OM_DACA_CTRL (0x20)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_DACAREN (31)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_DACALEN (30)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIXEN  (29)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_LMIXEN  (28)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC1   (23)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC2   (22)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIX_PHONE  (21)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIX_PHONEP (20)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIX_LINEINR(19)
>> +#define SUN6I_CODEC_OM_DACA_CTRL_RMIX_DACR

Re: linux-next: Tree for Oct 4

[Stephen Rothwell]

Hi all,

On Tue, 4 Oct 2016 14:56:49 +1100 Stephen Rothwell <s...@canb.auug.org.au> 
wrote:
>
> There will be no linux-next release on Friday.
> 
> Changes since 20161003:

I forgot to say: Please do *not* add any v4.10 material to your
linux-next included trees until v4.9-rc1 has been released i.e. the
merge window closes.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: Tree for Oct 4

[Stephen Rothwell]

Hi all,

On Tue, 4 Oct 2016 14:56:49 +1100 Stephen Rothwell  
wrote:
>
> There will be no linux-next release on Friday.
> 
> Changes since 20161003:

I forgot to say: Please do *not* add any v4.10 material to your
linux-next included trees until v4.9-rc1 has been released i.e. the
merge window closes.

-- 
Cheers,
Stephen Rothwell

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Linus Torvalds]

On Mon, Oct 3, 2016 at 9:07 PM, Andrew Morton  wrote:
>
> Well, it's a VM_BUG_ON and few people run with CONFIG_DEBUG_VM.

Ehh. If by "few people" you mean "pretty much everybody", you'd be
right, but your choice of wording would be somewhat misleading,
wouldn't you say?

Hint: here's a line from the standard Fedora kernel config:

CONFIG_DEBUG_VM=y

so *no*. VM_BUG_ON() is no less deadly than a regular BUG_ON(). It
just allows some people to build smaller kernels, but apparently
distro people would rather have debugging than save a few kB of RAM.

The VM debvugging code has VM_WARN_ON() and VM_WARN_ON_ONCE() for
people who want to get a "oops, my assumptions were wrong"

Killing machines because somebody made an assumption that was wrong is not ok.

Killing the machine is ok if we have a situation where there literally
is no other choice.

  Linus

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Linus Torvalds]

On Mon, Oct 3, 2016 at 9:07 PM, Andrew Morton  wrote:
>
> Well, it's a VM_BUG_ON and few people run with CONFIG_DEBUG_VM.

Ehh. If by "few people" you mean "pretty much everybody", you'd be
right, but your choice of wording would be somewhat misleading,
wouldn't you say?

Hint: here's a line from the standard Fedora kernel config:

CONFIG_DEBUG_VM=y

so *no*. VM_BUG_ON() is no less deadly than a regular BUG_ON(). It
just allows some people to build smaller kernels, but apparently
distro people would rather have debugging than save a few kB of RAM.

The VM debvugging code has VM_WARN_ON() and VM_WARN_ON_ONCE() for
people who want to get a "oops, my assumptions were wrong"

Killing machines because somebody made an assumption that was wrong is not ok.

Killing the machine is ok if we have a situation where there literally
is no other choice.

  Linus

[PATCHv1] hwmon: adm9240: handle temperature readings below 0

[Chris Packham]

Unlike the temperature thresholds the temperature data is a 9-bit signed
value. This allows and additional 0.5 degrees of precision on the
reading but means we can't rely on sign-extension to handle negative
values.

Signed-off-by: Chris Packham 
---
 drivers/hwmon/adm9240.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/adm9240.c b/drivers/hwmon/adm9240.c
index 98114ce..6929b25 100644
--- a/drivers/hwmon/adm9240.c
+++ b/drivers/hwmon/adm9240.c
@@ -107,6 +107,21 @@ static inline s8 TEMP_TO_REG(long val)
return clamp_val(SCALE(val, 1, 1000), -40, 127);
 }
 
+/* 8-bit signed temperature (from Thigh, Tlow etc) */
+static inline int TEMP_FROM_REG(s8 val)
+{
+   return val * 1000;
+}
+
+/* 9-bit signed temperature (from temperature data) */
+static inline int TEMP_FROM_DATA_REG(s16 val)
+{
+   if (val > 255)
+   val -= 512;
+
+   return val * 500;
+}
+
 /* two fans, each with low fan speed limit */
 static inline unsigned int FAN_FROM_REG(u8 reg, u8 div)
 {
@@ -263,7 +278,7 @@ static ssize_t show_temp(struct device *dev, struct 
device_attribute *dummy,
char *buf)
 {
struct adm9240_data *data = adm9240_update_device(dev);
-   return sprintf(buf, "%d\n", data->temp * 500); /* 9-bit value */
+   return sprintf(buf, "%d\n", TEMP_FROM_DATA_REG(data->temp));
 }
 
 static ssize_t show_max(struct device *dev, struct device_attribute *devattr,
@@ -271,7 +286,7 @@ static ssize_t show_max(struct device *dev, struct 
device_attribute *devattr,
 {
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
struct adm9240_data *data = adm9240_update_device(dev);
-   return sprintf(buf, "%d\n", data->temp_max[attr->index] * 1000);
+   return sprintf(buf, "%d\n", TEMP_FROM_REG(data->temp_max[attr->index]));
 }
 
 static ssize_t set_max(struct device *dev, struct device_attribute *devattr,
-- 
2.10.0

[PATCHv1] hwmon: adm9240: handle temperature readings below 0

[Chris Packham]

Unlike the temperature thresholds the temperature data is a 9-bit signed
value. This allows and additional 0.5 degrees of precision on the
reading but means we can't rely on sign-extension to handle negative
values.

Signed-off-by: Chris Packham 
---
 drivers/hwmon/adm9240.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/adm9240.c b/drivers/hwmon/adm9240.c
index 98114ce..6929b25 100644
--- a/drivers/hwmon/adm9240.c
+++ b/drivers/hwmon/adm9240.c
@@ -107,6 +107,21 @@ static inline s8 TEMP_TO_REG(long val)
return clamp_val(SCALE(val, 1, 1000), -40, 127);
 }
 
+/* 8-bit signed temperature (from Thigh, Tlow etc) */
+static inline int TEMP_FROM_REG(s8 val)
+{
+   return val * 1000;
+}
+
+/* 9-bit signed temperature (from temperature data) */
+static inline int TEMP_FROM_DATA_REG(s16 val)
+{
+   if (val > 255)
+   val -= 512;
+
+   return val * 500;
+}
+
 /* two fans, each with low fan speed limit */
 static inline unsigned int FAN_FROM_REG(u8 reg, u8 div)
 {
@@ -263,7 +278,7 @@ static ssize_t show_temp(struct device *dev, struct 
device_attribute *dummy,
char *buf)
 {
struct adm9240_data *data = adm9240_update_device(dev);
-   return sprintf(buf, "%d\n", data->temp * 500); /* 9-bit value */
+   return sprintf(buf, "%d\n", TEMP_FROM_DATA_REG(data->temp));
 }
 
 static ssize_t show_max(struct device *dev, struct device_attribute *devattr,
@@ -271,7 +286,7 @@ static ssize_t show_max(struct device *dev, struct 
device_attribute *devattr,
 {
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
struct adm9240_data *data = adm9240_update_device(dev);
-   return sprintf(buf, "%d\n", data->temp_max[attr->index] * 1000);
+   return sprintf(buf, "%d\n", TEMP_FROM_REG(data->temp_max[attr->index]));
 }
 
 static ssize_t set_max(struct device *dev, struct device_attribute *devattr,
-- 
2.10.0

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

[Michael Ellerman]

Jiri Olsa  writes:

> The trinity syscall fuzzer triggered following WARN on powerpc:
>   WARNING: CPU: 9 PID: 2998 at arch/powerpc/kernel/hw_breakpoint.c:278
>   ...
>   NIP [c093aedc] .hw_breakpoint_handler+0x28c/0x2b0
>   LR [c093aed8] .hw_breakpoint_handler+0x288/0x2b0
>   Call Trace:
>   [c002f7933580] [c093aed8] .hw_breakpoint_handler+0x288/0x2b0 
> (unreliable)
>   [c002f7933630] [c00f671c] .notifier_call_chain+0x7c/0xf0
>   [c002f79336d0] [c00f6abc] 
> .__atomic_notifier_call_chain+0xbc/0x1c0
>   [c002f7933780] [c00f6c40] .notify_die+0x70/0xd0
>   [c002f7933820] [c001a74c] .do_break+0x4c/0x100
>   [c002f7933920] [c00089fc] handle_dabr_fault+0x14/0x48

Is that the full stack trace? It doesn't look like it.

And were you running trinity as root or regular user?

cheers

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

[Michael Ellerman]

Jiri Olsa  writes:

> The trinity syscall fuzzer triggered following WARN on powerpc:
>   WARNING: CPU: 9 PID: 2998 at arch/powerpc/kernel/hw_breakpoint.c:278
>   ...
>   NIP [c093aedc] .hw_breakpoint_handler+0x28c/0x2b0
>   LR [c093aed8] .hw_breakpoint_handler+0x288/0x2b0
>   Call Trace:
>   [c002f7933580] [c093aed8] .hw_breakpoint_handler+0x288/0x2b0 
> (unreliable)
>   [c002f7933630] [c00f671c] .notifier_call_chain+0x7c/0xf0
>   [c002f79336d0] [c00f6abc] 
> .__atomic_notifier_call_chain+0xbc/0x1c0
>   [c002f7933780] [c00f6c40] .notify_die+0x70/0xd0
>   [c002f7933820] [c001a74c] .do_break+0x4c/0x100
>   [c002f7933920] [c00089fc] handle_dabr_fault+0x14/0x48

Is that the full stack trace? It doesn't look like it.

And were you running trinity as root or regular user?

cheers

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Andrew Morton]

On Mon, 3 Oct 2016 21:00:55 -0700 Linus Torvalds 
 wrote:

> In particular, I just got this
> 
> kernel BUG at ./include/linux/swap.h:276

Well, it's a VM_BUG_ON and few people run with CONFIG_DEBUG_VM.

But a) something's clearly wrong and b) points taken.

Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Andrew Morton]

On Mon, 3 Oct 2016 21:00:55 -0700 Linus Torvalds 
 wrote:

> In particular, I just got this
> 
> kernel BUG at ./include/linux/swap.h:276

Well, it's a VM_BUG_ON and few people run with CONFIG_DEBUG_VM.

But a) something's clearly wrong and b) points taken.

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

[Nicolas Pitre]

As I stated before, I can't reproduce this.
Please check your toolchain. It apparently throws segmentation faults.

On Sun, 2 Oct 2016, kbuild test robot wrote:

> Hi Nicolas,
> 
> FYI, the error/warning still remains.
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   f51fdffad5b7709d0ade40736b58a2da2707fa15
> commit: 461a5e51060c93f5844113f4be9dba513cc92830 do_div(): generic 
> optimization for constant divisor on 32-bit machines
> date:   11 months ago
> config: microblaze-mmu_defconfig (attached as .config)
> compiler: microblaze-linux-gcc (GCC) 6.2.0
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 461a5e51060c93f5844113f4be9dba513cc92830
> # save the attached .config to linux build tree
> make.cross ARCH=microblaze 
> 
> All errors (new ones prefixed by >>):
> 
>net/built-in.o: In function `rpc_print_iostats':
> >> net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'
>scripts/link-vmlinux.sh: line 52: 107322 Segmentation fault  ${LD} 
> ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds} ${KBUILD_VMLINUX_INIT} 
> --start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}
> 
> vim +204 net/sunrpc/stats.c
> 
> 840210fc Weston Andros Adamson 2014-06-24  188
>   [task->tk_msg.rpc_proc->p_statidx]);
> 840210fc Weston Andros Adamson 2014-06-24  189  }
> 0a702195 Weston Andros Adamson 2012-02-17  190  
> EXPORT_SYMBOL_GPL(rpc_count_iostats);
> 11c556b3 Chuck Lever   2006-03-20  191  
> ec535ce1 Adrian Bunk   2006-04-18  192  static void 
> _print_name(struct seq_file *seq, unsigned int op,
> ec535ce1 Adrian Bunk   2006-04-18  193struct 
> rpc_procinfo *procs)
> cc0175c1 Chuck Lever   2006-03-20  194  {
> cc0175c1 Chuck Lever   2006-03-20  195if (procs[op].p_name)
> cc0175c1 Chuck Lever   2006-03-20  196seq_printf(seq, 
> "\t%12s: ", procs[op].p_name);
> cc0175c1 Chuck Lever   2006-03-20  197else if (op == 0)
> cc0175c1 Chuck Lever   2006-03-20  198seq_printf(seq, 
> "\tNULL: ");
> cc0175c1 Chuck Lever   2006-03-20  199else
> cc0175c1 Chuck Lever   2006-03-20  200seq_printf(seq, 
> "\t%12u: ", op);
> cc0175c1 Chuck Lever   2006-03-20  201  }
> cc0175c1 Chuck Lever   2006-03-20  202  
> 11c556b3 Chuck Lever   2006-03-20  203  void rpc_print_iostats(struct 
> seq_file *seq, struct rpc_clnt *clnt)
> 11c556b3 Chuck Lever   2006-03-20 @204  {
> 11c556b3 Chuck Lever   2006-03-20  205struct rpc_iostats 
> *stats = clnt->cl_metrics;
> 2446ab60 Trond Myklebust   2012-03-01  206struct rpc_xprt *xprt;
> 11c556b3 Chuck Lever   2006-03-20  207unsigned int op, 
> maxproc = clnt->cl_maxproc;
> 11c556b3 Chuck Lever   2006-03-20  208  
> 11c556b3 Chuck Lever   2006-03-20  209if (!stats)
> 11c556b3 Chuck Lever   2006-03-20  210return;
> 11c556b3 Chuck Lever   2006-03-20  211  
> 11c556b3 Chuck Lever   2006-03-20  212seq_printf(seq, "\tRPC 
> iostats version: %s  ", RPC_IOSTATS_VERS);
> 
> :: The code at line 204 was first introduced by commit
> :: 11c556b3d8d481829ab5f9933a25d29b00913b5a SUNRPC: provide a mechanism 
> for collecting stats in the RPC client
> 
> :: TO: Chuck Lever 
> :: CC: Trond Myklebust 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 

Re: net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'

[Nicolas Pitre]

As I stated before, I can't reproduce this.
Please check your toolchain. It apparently throws segmentation faults.

On Sun, 2 Oct 2016, kbuild test robot wrote:

> Hi Nicolas,
> 
> FYI, the error/warning still remains.
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   f51fdffad5b7709d0ade40736b58a2da2707fa15
> commit: 461a5e51060c93f5844113f4be9dba513cc92830 do_div(): generic 
> optimization for constant divisor on 32-bit machines
> date:   11 months ago
> config: microblaze-mmu_defconfig (attached as .config)
> compiler: microblaze-linux-gcc (GCC) 6.2.0
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 461a5e51060c93f5844113f4be9dba513cc92830
> # save the attached .config to linux build tree
> make.cross ARCH=microblaze 
> 
> All errors (new ones prefixed by >>):
> 
>net/built-in.o: In function `rpc_print_iostats':
> >> net/sunrpc/stats.c:204: undefined reference to `_GLOBAL_OFFSET_TABLE_'
>scripts/link-vmlinux.sh: line 52: 107322 Segmentation fault  ${LD} 
> ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds} ${KBUILD_VMLINUX_INIT} 
> --start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}
> 
> vim +204 net/sunrpc/stats.c
> 
> 840210fc Weston Andros Adamson 2014-06-24  188
>   [task->tk_msg.rpc_proc->p_statidx]);
> 840210fc Weston Andros Adamson 2014-06-24  189  }
> 0a702195 Weston Andros Adamson 2012-02-17  190  
> EXPORT_SYMBOL_GPL(rpc_count_iostats);
> 11c556b3 Chuck Lever   2006-03-20  191  
> ec535ce1 Adrian Bunk   2006-04-18  192  static void 
> _print_name(struct seq_file *seq, unsigned int op,
> ec535ce1 Adrian Bunk   2006-04-18  193struct 
> rpc_procinfo *procs)
> cc0175c1 Chuck Lever   2006-03-20  194  {
> cc0175c1 Chuck Lever   2006-03-20  195if (procs[op].p_name)
> cc0175c1 Chuck Lever   2006-03-20  196seq_printf(seq, 
> "\t%12s: ", procs[op].p_name);
> cc0175c1 Chuck Lever   2006-03-20  197else if (op == 0)
> cc0175c1 Chuck Lever   2006-03-20  198seq_printf(seq, 
> "\tNULL: ");
> cc0175c1 Chuck Lever   2006-03-20  199else
> cc0175c1 Chuck Lever   2006-03-20  200seq_printf(seq, 
> "\t%12u: ", op);
> cc0175c1 Chuck Lever   2006-03-20  201  }
> cc0175c1 Chuck Lever   2006-03-20  202  
> 11c556b3 Chuck Lever   2006-03-20  203  void rpc_print_iostats(struct 
> seq_file *seq, struct rpc_clnt *clnt)
> 11c556b3 Chuck Lever   2006-03-20 @204  {
> 11c556b3 Chuck Lever   2006-03-20  205struct rpc_iostats 
> *stats = clnt->cl_metrics;
> 2446ab60 Trond Myklebust   2012-03-01  206struct rpc_xprt *xprt;
> 11c556b3 Chuck Lever   2006-03-20  207unsigned int op, 
> maxproc = clnt->cl_maxproc;
> 11c556b3 Chuck Lever   2006-03-20  208  
> 11c556b3 Chuck Lever   2006-03-20  209if (!stats)
> 11c556b3 Chuck Lever   2006-03-20  210return;
> 11c556b3 Chuck Lever   2006-03-20  211  
> 11c556b3 Chuck Lever   2006-03-20  212seq_printf(seq, "\tRPC 
> iostats version: %s  ", RPC_IOSTATS_VERS);
> 
> :: The code at line 204 was first introduced by commit
> :: 11c556b3d8d481829ab5f9933a25d29b00913b5a SUNRPC: provide a mechanism 
> for collecting stats in the RPC client
> 
> :: TO: Chuck Lever 
> :: CC: Trond Myklebust 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 

BUG_ON() in workingset_node_shadows_dec() triggers

[Linus Torvalds]

I'm really sorry I applied that last series from Andrew just before
doing the 4.8 release, because they cause problems, and now it is in
4.8 (and that buggy crap is marked for stable too).

In particular, I just got this

kernel BUG at ./include/linux/swap.h:276

and the end result was a dead kernel.

The bug that commit 22f2ac51b6d64 ("mm: workingset: fix crash in
shadow node shrinker caused by replace_page_cache_page()") purports to
have fixed has apparently been there since 3.15, but the fix is
clearly worse than the bug it tried to fix, since that original bug
has never killed my machine!

I should have reacted to the damn added BUG_ON() lines. I suspect I
will have to finally just remove the idiotic BUG_ON() concept once and
for all, because there is NO F*CKING EXCUSE to knowingly kill the
kernel.

Why the hell was that not a *warning*?

Yes, I'm grumpy. This went in very late in the release candidates, and
I had higher expectations of things coming in through Andrew. Adding
random BUG_ON()'s to code that clearly hasn't had sufficient testing
is *not* acceptable, and it's definitely not acceptable to send that
to me after rc8 unless it has gotten a *lot* of testing, which it
clearly must not have had. Adding stable to the cc too to warn about
this.

The full report is

  kernel BUG at ./include/linux/swap.h:276!
  invalid opcode:  [#1] SMP
  Modules linked in: isofs usb_storage fuse xt_CHECKSUM ipt_MASQUERADE
nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns
nf_conntrack_broadcast ip6t_REJECT nf_reject_ipv6
   soundcore wmi acpi_als pinctrl_sunrisepoint kfifo_buf tpm_tis
industrialio acpi_pad pinctrl_intel tpm_tis_core tpm nfsd auth_rpcgss
nfs_acl lockd grace sunrpc dm_crypt
  CPU: 0 PID: 20929 Comm: blkid Not tainted 4.8.0-rc8-00087-gbe67d60ba944 #1
  Hardware name: System manufacturer System Product Name/Z170-K, BIOS
1803 05/06/2016
  task: 8faa93ecd940 task.stack: 8faa7f478000
  RIP: page_cache_tree_insert+0xf1/0x100
  RSP: 0018:8faa7f47bab0  EFLAGS: 00010046
  RAX: 0001 RBX: 8faadfaf8c18 RCX: 8fa8737b5488
  RDX:  RSI:  RDI: 8fa8737b4b48
  RBP: 8faa7f47bae8 R08: 0012 R09: 8fa8737b54b0
  R10: 0040 R11: 8fa8737b54b0 R12: ea000b1ad580
  R13:  R14: 8faa7f47bb48 R15: ea000b1ad580
  FS:  7ffba3a61780() GS:8faaf6c0() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 7ffba31a5430 CR3: 0002c6d4 CR4: 003406f0
  DR0:  DR1:  DR2: 
  DR3:  DR6: fffe0ff0 DR7: 0400
  Call Trace:
__add_to_page_cache_locked+0x12e/0x270
add_to_page_cache_lru+0x4e/0xe0
mpage_readpages+0x112/0x1d0
blkdev_readpages+0x1d/0x20
__do_page_cache_readahead+0x1ad/0x290
force_page_cache_readahead+0xaa/0x100
page_cache_sync_readahead+0x3f/0x50
generic_file_read_iter+0x5af/0x740
blkdev_read_iter+0x35/0x40
__vfs_read+0xe1/0x130
vfs_read+0x96/0x130
SyS_read+0x55/0xc0
entry_SYSCALL_64_fastpath+0x13/0x8f
  Code: 03 00 48 8b 5d d8 65 48 33 1c 25 28 00 00 00 44 89 e8 75 19 48
83 c4 18 5b 41 5c 41 5d 41 5e 5d c3 0f 0b 41 bd ef ff ff ff eb d7 <0f>
0b e8 88 68 ef ff 0f 1f 84 00
  RIP  page_cache_tree_insert+0xf1/0x100

and I hope somebody can see what is going wrong in there. The reason
the machine *dies* from that thing is that we end up then immediately
having a

  BUG: unable to handle kernel paging request at b70bdaa8
  IP: blk_flush_plug_list+0x8b/0x250
  Call Trace:
schedule+0x61/0x80
do_exit+0x8c8/0xae0
rewind_stack_do_exit+0x17/0x20

and then a

  Fixing recursive fault but reboot is needed!

and the machine will never recover.

People who add random assert statements that kill machines should damn
well not be let near the VM layer.

Johannes? Please make this your first priority. And in the meantime I
will make that VM_BUG_ON() be a VM_WARN_ON_ONCE().

And dammit, if anybody else feels that they had done "debugging
messages with BUG_ON()", I would suggest you

 (a) rethink your approach to programming

 (b) send me patches to remove the crap entirely, or make them real
*DEBUGGING* messages, not "kill the whole machine" messages.

I've ranted against people using BUG_ON() for debugging in the past.
Why the f*ck does this still happen? And Andrew - please stop taking
those kinds of patches! Lookie here:

https://lwn.net/Articles/13183/

so excuse me for being upset that people still do this shit almost 15
years later.

 Linus

BUG_ON() in workingset_node_shadows_dec() triggers

[Linus Torvalds]

I'm really sorry I applied that last series from Andrew just before
doing the 4.8 release, because they cause problems, and now it is in
4.8 (and that buggy crap is marked for stable too).

In particular, I just got this

kernel BUG at ./include/linux/swap.h:276

and the end result was a dead kernel.

The bug that commit 22f2ac51b6d64 ("mm: workingset: fix crash in
shadow node shrinker caused by replace_page_cache_page()") purports to
have fixed has apparently been there since 3.15, but the fix is
clearly worse than the bug it tried to fix, since that original bug
has never killed my machine!

I should have reacted to the damn added BUG_ON() lines. I suspect I
will have to finally just remove the idiotic BUG_ON() concept once and
for all, because there is NO F*CKING EXCUSE to knowingly kill the
kernel.

Why the hell was that not a *warning*?

Yes, I'm grumpy. This went in very late in the release candidates, and
I had higher expectations of things coming in through Andrew. Adding
random BUG_ON()'s to code that clearly hasn't had sufficient testing
is *not* acceptable, and it's definitely not acceptable to send that
to me after rc8 unless it has gotten a *lot* of testing, which it
clearly must not have had. Adding stable to the cc too to warn about
this.

The full report is

  kernel BUG at ./include/linux/swap.h:276!
  invalid opcode:  [#1] SMP
  Modules linked in: isofs usb_storage fuse xt_CHECKSUM ipt_MASQUERADE
nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns
nf_conntrack_broadcast ip6t_REJECT nf_reject_ipv6
   soundcore wmi acpi_als pinctrl_sunrisepoint kfifo_buf tpm_tis
industrialio acpi_pad pinctrl_intel tpm_tis_core tpm nfsd auth_rpcgss
nfs_acl lockd grace sunrpc dm_crypt
  CPU: 0 PID: 20929 Comm: blkid Not tainted 4.8.0-rc8-00087-gbe67d60ba944 #1
  Hardware name: System manufacturer System Product Name/Z170-K, BIOS
1803 05/06/2016
  task: 8faa93ecd940 task.stack: 8faa7f478000
  RIP: page_cache_tree_insert+0xf1/0x100
  RSP: 0018:8faa7f47bab0  EFLAGS: 00010046
  RAX: 0001 RBX: 8faadfaf8c18 RCX: 8fa8737b5488
  RDX:  RSI:  RDI: 8fa8737b4b48
  RBP: 8faa7f47bae8 R08: 0012 R09: 8fa8737b54b0
  R10: 0040 R11: 8fa8737b54b0 R12: ea000b1ad580
  R13:  R14: 8faa7f47bb48 R15: ea000b1ad580
  FS:  7ffba3a61780() GS:8faaf6c0() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 7ffba31a5430 CR3: 0002c6d4 CR4: 003406f0
  DR0:  DR1:  DR2: 
  DR3:  DR6: fffe0ff0 DR7: 0400
  Call Trace:
__add_to_page_cache_locked+0x12e/0x270
add_to_page_cache_lru+0x4e/0xe0
mpage_readpages+0x112/0x1d0
blkdev_readpages+0x1d/0x20
__do_page_cache_readahead+0x1ad/0x290
force_page_cache_readahead+0xaa/0x100
page_cache_sync_readahead+0x3f/0x50
generic_file_read_iter+0x5af/0x740
blkdev_read_iter+0x35/0x40
__vfs_read+0xe1/0x130
vfs_read+0x96/0x130
SyS_read+0x55/0xc0
entry_SYSCALL_64_fastpath+0x13/0x8f
  Code: 03 00 48 8b 5d d8 65 48 33 1c 25 28 00 00 00 44 89 e8 75 19 48
83 c4 18 5b 41 5c 41 5d 41 5e 5d c3 0f 0b 41 bd ef ff ff ff eb d7 <0f>
0b e8 88 68 ef ff 0f 1f 84 00
  RIP  page_cache_tree_insert+0xf1/0x100

and I hope somebody can see what is going wrong in there. The reason
the machine *dies* from that thing is that we end up then immediately
having a

  BUG: unable to handle kernel paging request at b70bdaa8
  IP: blk_flush_plug_list+0x8b/0x250
  Call Trace:
schedule+0x61/0x80
do_exit+0x8c8/0xae0
rewind_stack_do_exit+0x17/0x20

and then a

  Fixing recursive fault but reboot is needed!

and the machine will never recover.

People who add random assert statements that kill machines should damn
well not be let near the VM layer.

Johannes? Please make this your first priority. And in the meantime I
will make that VM_BUG_ON() be a VM_WARN_ON_ONCE().

And dammit, if anybody else feels that they had done "debugging
messages with BUG_ON()", I would suggest you

 (a) rethink your approach to programming

 (b) send me patches to remove the crap entirely, or make them real
*DEBUGGING* messages, not "kill the whole machine" messages.

I've ranted against people using BUG_ON() for debugging in the past.
Why the f*ck does this still happen? And Andrew - please stop taking
those kinds of patches! Lookie here:

https://lwn.net/Articles/13183/

so excuse me for being upset that people still do this shit almost 15
years later.

 Linus

linux-next: Tree for Oct 4

[Stephen Rothwell]

Hi all,

There will be no linux-next release on Friday.

Changes since 20161003:

Non-merge commits (relative to Linus' tree): 12964
 9515 files changed, 516789 insertions(+), 294462 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (af79ad2b1f33 Merge branch 'sched-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (117e5e9c4cfc ARM: 8618/1: decompressor: reset ttbcr 
fields to use TTBR0 on ARMv7)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (c8d2bc9bc39e Linux 4.8)
Merging net/master (c8d2bc9bc39e Linux 4.8)
Merging ipsec/master (b1f2beb87bb0 Merge tag 'media/v4.8-7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging netfilter/master (440f895aa97f drivers: net: phy: xgene: Fix 'remove' 
function)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (db64c5fa590b Merge tag 
'iwlwifi-for-kalle-2016-09-15' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (7ac327318e09 Merge tag 'mac80211-for-davem-2016-09-16' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (eeea8b40cd28 Merge tag 'asoc-v4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next)
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (3be7988674ab Linux 4.8-rc7)
Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix 
endpoint name)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (9395452b4aab Linux 4.8-rc6)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (9fb6de1b0bf4 Input: joydev - recognize devices 
with Z axis as joysticks)
Merging crypto-current/master (80da44c29d99 crypto: vmx - Fix memory corruption 
caused by p8_ghash)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: Fix NULL pointer oops in 
error interrupt setup handling)
Merging kselftest-fixes/fixes (29b4817d4018 Linux 4.8-rc1)
Merging backlight-fixes

linux-next: Tree for Oct 4

[Stephen Rothwell]

Hi all,

There will be no linux-next release on Friday.

Changes since 20161003:

Non-merge commits (relative to Linus' tree): 12964
 9515 files changed, 516789 insertions(+), 294462 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (af79ad2b1f33 Merge branch 'sched-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (117e5e9c4cfc ARM: 8618/1: decompressor: reset ttbcr 
fields to use TTBR0 on ARMv7)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (c8d2bc9bc39e Linux 4.8)
Merging net/master (c8d2bc9bc39e Linux 4.8)
Merging ipsec/master (b1f2beb87bb0 Merge tag 'media/v4.8-7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging netfilter/master (440f895aa97f drivers: net: phy: xgene: Fix 'remove' 
function)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (db64c5fa590b Merge tag 
'iwlwifi-for-kalle-2016-09-15' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (7ac327318e09 Merge tag 'mac80211-for-davem-2016-09-16' 
of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging sound-current/for-linus (eeea8b40cd28 Merge tag 'asoc-v4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next)
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (3be7988674ab Linux 4.8-rc7)
Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix 
endpoint name)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (9395452b4aab Linux 4.8-rc6)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (9fb6de1b0bf4 Input: joydev - recognize devices 
with Z axis as joysticks)
Merging crypto-current/master (80da44c29d99 crypto: vmx - Fix memory corruption 
caused by p8_ghash)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: Fix NULL pointer oops in 
error interrupt setup handling)
Merging kselftest-fixes/fixes (29b4817d4018 Linux 4.8-rc1)
Merging backlight-fixes

[GIT PULL] regmap updates for v4.9

[Mark Brown]

The following changes since commit c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:

  Linux 4.8 (2016-10-02 16:24:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 
tags/regmap-v4.9

for you to fetch changes up to f785fb2ec0cbe73165333ea1f23cce36c7fc2521:

  Merge remote-tracking branches 'regmap/topic/core' and 'regmap/topic/debugfs' 
into regmap-next (2016-10-04 05:17:12 +0200)


regmap: Updates for v4.9

Another quiet release, a few small extensions to the set of register
maps we support and an improvement in the debugfs code:

 - Allow viewing of cached contents for write only registers via
   debugfs.
 - Support a wider range of read/write flag masks in register formats.
 - Support more little endian formats.


Cristian Birsan (2):
  regmap: Add a function to check if a regmap register is cached
  regmap: debugfs: Add support for dumping write only device registers

Mark Brown (1):
  Merge remote-tracking branches 'regmap/topic/core' and 
'regmap/topic/debugfs' into regmap-next

Tony Lindgren (2):
  regmap: Allow longer flag masks for read and write
  regmap: Add missing little endian functions

 drivers/base/regmap/internal.h   |  5 +--
 drivers/base/regmap/regmap-debugfs.c | 16 +++--
 drivers/base/regmap/regmap.c | 64 
 include/linux/regmap.h   |  8 ++---
 4 files changed, 71 insertions(+), 22 deletions(-)


signature.asc
Description: PGP signature

[GIT PULL] regmap updates for v4.9

[Mark Brown]

The following changes since commit c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:

  Linux 4.8 (2016-10-02 16:24:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 
tags/regmap-v4.9

for you to fetch changes up to f785fb2ec0cbe73165333ea1f23cce36c7fc2521:

  Merge remote-tracking branches 'regmap/topic/core' and 'regmap/topic/debugfs' 
into regmap-next (2016-10-04 05:17:12 +0200)


regmap: Updates for v4.9

Another quiet release, a few small extensions to the set of register
maps we support and an improvement in the debugfs code:

 - Allow viewing of cached contents for write only registers via
   debugfs.
 - Support a wider range of read/write flag masks in register formats.
 - Support more little endian formats.


Cristian Birsan (2):
  regmap: Add a function to check if a regmap register is cached
  regmap: debugfs: Add support for dumping write only device registers

Mark Brown (1):
  Merge remote-tracking branches 'regmap/topic/core' and 
'regmap/topic/debugfs' into regmap-next

Tony Lindgren (2):
  regmap: Allow longer flag masks for read and write
  regmap: Add missing little endian functions

 drivers/base/regmap/internal.h   |  5 +--
 drivers/base/regmap/regmap-debugfs.c | 16 +++--
 drivers/base/regmap/regmap.c | 64 
 include/linux/regmap.h   |  8 ++---
 4 files changed, 71 insertions(+), 22 deletions(-)


signature.asc
Description: PGP signature

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

[Jeffrey Merkey]

On 10/3/16, Jeffrey Merkey  wrote:
> On 10/3/16, Joe Perches  wrote:
>>
>> On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote:
>>> Hi Joe,
>>
>> Hi Stephen.
>>
>>> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches  wrote:
>>> >
>>> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
>>> > > The following changes since commit
>>> > > c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
>>> > >
>>> > >   Linux 4.8 (2016-10-02 16:24:33 -0700)
>>> > >
>>> > > are available in the git repository at:
>>> > >
>>> > >   https://github.com/jeffmerkey/linux.git mdb-v4.8
>>> > >
>>> > > for you to fetch changes up to
>>> > > 8e3486647ebcef24e67fc2eebe49f3641a4ffc95:
>>> > >
>>> > >   Add MDB Debugger to Linux Kernel v4.8 (2016-10-02 20:33:55 -0600)
>>> >
>>> >
>>> > Stephen, can this tree be added to -next to get some
>>> > exposure for the next cycle?
>>>
>>>
>>> I don't add trees during the merge window (unless they contain stuff
>>> for the current merge window and, even then, only rarely).  Also, I
>>> only take requests from the maintainer/owner of the tree.
>>
>> No worries, it's really a request for Jeff who doesn't seem
>> to know the process very well.
>>
>> Jeff, you really should get this into -next before sending a
>> pull request to Linus for this large bit of code.
>>
>>> Has there been much recent discussion/review/testing of this tree?
>>
>> Not to my knowledge for about 6 months now.
>>
>>> Is it likely that Linus will merge it?  (Just asking, I haven't been
>>> following it.)
>>
>> Dunno.  I'd guess it will _not_ be merged without some time
>> in -next and a compelling reason to use it.
>>
>>
>
> Hi Joe,
> Hi Stephen,
>
> I put it out as a pull request so the kbuild test robot can build it
> against all sort of configs to make certain it runs across all
> i386/x86_64 configs.  If I recall correctly, Ingo Molnar stated he
> would be interested in mdb being chopped up into pieces and possibly
> integrated into kdb, since MDB has a very good disassembler and
> conditional breakpoints which kdb lacks, if I understood what he said
> last linux release when this came up.
>
> Since I produce mdb for mostly my own internal use, I have not done
> this integration work as of yet as I have been more a user of MDB than
> the developer of late.  That's not to say someone else could do what
> Ingo suggested, and I have looked over KDB but to be honest, it would
> require a whole lot of non-intrusive changes to kdb to pull it off --
> not impossible but where I left it with Ingo is he would need to ask
> and be specific about what changes or sections he would want in KDB.
> Without specific guidance from him, I hesitate to work on it -- in
> other words he needs to ask me exactly what he expects to be done
> here.   kdb is a very unstable tool from what limited testing I have
> done and it's processor roundup for SMP systems is a very different
> approach from mdb and is prone to crashes and lockups (particularly
> when you are servicing multiple NMI interrupts and more then one of
> the processors ends up in the INT1 exception handler).
>
> MDB's plus to Linux is a working deferenced disassembler which kdb
> lacks.  Ingo did not like the fact the MDB is monolithic if I read
> what he said correctly, and I can see his point, however, debuggers
> are always tightly coupled with the underlying arch.  kgdb is
> interesting but is not a standalone debugger, requires two boxes, and
> uses a cumbersome command syntax.
>
> That being said, Ingo will need to ask me to do the work then be a
> little more forthright about his interest -- if any -- and provide
> some guidance.  If Linus wants to pull it be my guest.  It's always
> out there for him or anyone else who needs it.
>
> :-)
>
> Jeff
>

The mdb disassembler also supports multiple disassembly options 16
bit, 32 bit, 64 bit, intel and GNU formats all interchangable with
simple commands which is something even kgdb does not support.


Jeff

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

[Jeffrey Merkey]

On 10/3/16, Jeffrey Merkey  wrote:
> On 10/3/16, Joe Perches  wrote:
>>
>> On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote:
>>> Hi Joe,
>>
>> Hi Stephen.
>>
>>> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches  wrote:
>>> >
>>> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
>>> > > The following changes since commit
>>> > > c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
>>> > >
>>> > >   Linux 4.8 (2016-10-02 16:24:33 -0700)
>>> > >
>>> > > are available in the git repository at:
>>> > >
>>> > >   https://github.com/jeffmerkey/linux.git mdb-v4.8
>>> > >
>>> > > for you to fetch changes up to
>>> > > 8e3486647ebcef24e67fc2eebe49f3641a4ffc95:
>>> > >
>>> > >   Add MDB Debugger to Linux Kernel v4.8 (2016-10-02 20:33:55 -0600)
>>> >
>>> >
>>> > Stephen, can this tree be added to -next to get some
>>> > exposure for the next cycle?
>>>
>>>
>>> I don't add trees during the merge window (unless they contain stuff
>>> for the current merge window and, even then, only rarely).  Also, I
>>> only take requests from the maintainer/owner of the tree.
>>
>> No worries, it's really a request for Jeff who doesn't seem
>> to know the process very well.
>>
>> Jeff, you really should get this into -next before sending a
>> pull request to Linus for this large bit of code.
>>
>>> Has there been much recent discussion/review/testing of this tree?
>>
>> Not to my knowledge for about 6 months now.
>>
>>> Is it likely that Linus will merge it?  (Just asking, I haven't been
>>> following it.)
>>
>> Dunno.  I'd guess it will _not_ be merged without some time
>> in -next and a compelling reason to use it.
>>
>>
>
> Hi Joe,
> Hi Stephen,
>
> I put it out as a pull request so the kbuild test robot can build it
> against all sort of configs to make certain it runs across all
> i386/x86_64 configs.  If I recall correctly, Ingo Molnar stated he
> would be interested in mdb being chopped up into pieces and possibly
> integrated into kdb, since MDB has a very good disassembler and
> conditional breakpoints which kdb lacks, if I understood what he said
> last linux release when this came up.
>
> Since I produce mdb for mostly my own internal use, I have not done
> this integration work as of yet as I have been more a user of MDB than
> the developer of late.  That's not to say someone else could do what
> Ingo suggested, and I have looked over KDB but to be honest, it would
> require a whole lot of non-intrusive changes to kdb to pull it off --
> not impossible but where I left it with Ingo is he would need to ask
> and be specific about what changes or sections he would want in KDB.
> Without specific guidance from him, I hesitate to work on it -- in
> other words he needs to ask me exactly what he expects to be done
> here.   kdb is a very unstable tool from what limited testing I have
> done and it's processor roundup for SMP systems is a very different
> approach from mdb and is prone to crashes and lockups (particularly
> when you are servicing multiple NMI interrupts and more then one of
> the processors ends up in the INT1 exception handler).
>
> MDB's plus to Linux is a working deferenced disassembler which kdb
> lacks.  Ingo did not like the fact the MDB is monolithic if I read
> what he said correctly, and I can see his point, however, debuggers
> are always tightly coupled with the underlying arch.  kgdb is
> interesting but is not a standalone debugger, requires two boxes, and
> uses a cumbersome command syntax.
>
> That being said, Ingo will need to ask me to do the work then be a
> little more forthright about his interest -- if any -- and provide
> some guidance.  If Linus wants to pull it be my guest.  It's always
> out there for him or anyone else who needs it.
>
> :-)
>
> Jeff
>

The mdb disassembler also supports multiple disassembly options 16
bit, 32 bit, 64 bit, intel and GNU formats all interchangable with
simple commands which is something even kgdb does not support.


Jeff

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

[R. Parameswaran]

Hi James, 

Please see inline, thanks for the reply:

On Sat, 1 Oct 2016, James Chapman wrote:

> On 30/09/16 03:39, R. Parameswaran wrote:
> >
> >>> + /* Adjust MTU, factor overhead - underlay L3 hdr, overlay L2 hdr*/
> >>> + if (tunnel->sock->sk_family == AF_INET)
> >>> + overhead += (ETH_HLEN + sizeof(struct iphdr));
> >>> + else if (tunnel->sock->sk_family == AF_INET6)
> >>> + overhead += (ETH_HLEN + sizeof(struct ipv6hdr));
> >> What about options in the IP header? If certain options are set on the
> >> socket, the IP header may be larger.
> >>
> > Thanks for the reply - It looks like IP options can only be 
> > enabled through setsockopt on an application's socket (if there's any 
> > other way to turn on IP options, please let me know - didn't see any 
> > sysctl setting for transmit). This scenario would come 
> > into picture when an application opens a raw IP or UDP socket such that it 
> > routes into the L2TP logical interface.
> 
> No. An L2TP daemon (userspace) will open a socket for each tunnel that
> it creates. Control and data packets use the same socket, which is the
> socket used by this code. It may set any options on its sockets. L2TP
> tunnel sockets can be created either by an L2TP daemon (managed tunnels)
> or by ip l2tp commands (unmanaged tunnels).
> 

One Q I have is whether it would be sufficient to solve this for the
common case (i.e no IP options) and have an expectation that the 
administrator will explicitly provision the mtu using the 'ip link ... 
mtu'  command when dealing with infrequent occurences like IP options? 

But looking at the code, it looks to be possible to pick up whether 
options are enabled and how long the options are, from the ip_options struct 
embedded in the tunnel socket. If you want me to, I can repost the patch
with this change (will need a few days) - please let me know if this is 
what you had in mind.

thanks,

Ramkumar



> > If you take the case of a plain IP (ethernet) interface, even if an
> > application opened a socket turning on IP options, it would not change
> > the MTU of the underlying interface, and it would not affect other 
> > applications transacting packets on the same interface. I know its not an 
> > exact parallel to this case, but since the IP option control is per 
> > application, we probably should not factor it into the L2TP logical 
> > interface?
> > We cannot affect other applications/processes running on the same L2TP 
> > tunnel. Also, since the application  using IP options knows that it has 
> > turned 
> > on IP options, maybe we can count on it to factor the size of the options 
> > into the size of the payload it sends into the socket, or set the mtu on 
> > the 
> > L2TP interface through config? 
> 
> No. See above.
> 
> >
> > Other than this, I don't see keepalives or anything else in which the 
> > kernel will source its own packet into the L2TP interface, outside of 
> > an application injected packet - if there is something like that, please
> > let me know. The user space L2TP daemon would probably fall in the 
> > category of applications.
> >
> > thanks,
> >
> > Ramkumar 
> >
> >
> 
> 
> 

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

[R. Parameswaran]

Hi James, 

Please see inline, thanks for the reply:

On Sat, 1 Oct 2016, James Chapman wrote:

> On 30/09/16 03:39, R. Parameswaran wrote:
> >
> >>> + /* Adjust MTU, factor overhead - underlay L3 hdr, overlay L2 hdr*/
> >>> + if (tunnel->sock->sk_family == AF_INET)
> >>> + overhead += (ETH_HLEN + sizeof(struct iphdr));
> >>> + else if (tunnel->sock->sk_family == AF_INET6)
> >>> + overhead += (ETH_HLEN + sizeof(struct ipv6hdr));
> >> What about options in the IP header? If certain options are set on the
> >> socket, the IP header may be larger.
> >>
> > Thanks for the reply - It looks like IP options can only be 
> > enabled through setsockopt on an application's socket (if there's any 
> > other way to turn on IP options, please let me know - didn't see any 
> > sysctl setting for transmit). This scenario would come 
> > into picture when an application opens a raw IP or UDP socket such that it 
> > routes into the L2TP logical interface.
> 
> No. An L2TP daemon (userspace) will open a socket for each tunnel that
> it creates. Control and data packets use the same socket, which is the
> socket used by this code. It may set any options on its sockets. L2TP
> tunnel sockets can be created either by an L2TP daemon (managed tunnels)
> or by ip l2tp commands (unmanaged tunnels).
> 

One Q I have is whether it would be sufficient to solve this for the
common case (i.e no IP options) and have an expectation that the 
administrator will explicitly provision the mtu using the 'ip link ... 
mtu'  command when dealing with infrequent occurences like IP options? 

But looking at the code, it looks to be possible to pick up whether 
options are enabled and how long the options are, from the ip_options struct 
embedded in the tunnel socket. If you want me to, I can repost the patch
with this change (will need a few days) - please let me know if this is 
what you had in mind.

thanks,

Ramkumar



> > If you take the case of a plain IP (ethernet) interface, even if an
> > application opened a socket turning on IP options, it would not change
> > the MTU of the underlying interface, and it would not affect other 
> > applications transacting packets on the same interface. I know its not an 
> > exact parallel to this case, but since the IP option control is per 
> > application, we probably should not factor it into the L2TP logical 
> > interface?
> > We cannot affect other applications/processes running on the same L2TP 
> > tunnel. Also, since the application  using IP options knows that it has 
> > turned 
> > on IP options, maybe we can count on it to factor the size of the options 
> > into the size of the payload it sends into the socket, or set the mtu on 
> > the 
> > L2TP interface through config? 
> 
> No. See above.
> 
> >
> > Other than this, I don't see keepalives or anything else in which the 
> > kernel will source its own packet into the L2TP interface, outside of 
> > an application injected packet - if there is something like that, please
> > let me know. The user space L2TP daemon would probably fall in the 
> > category of applications.
> >
> > thanks,
> >
> > Ramkumar 
> >
> >
> 
> 
> 

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

[Andy Lutomirski]

On Mon, Oct 3, 2016 at 7:47 PM, Rik van Riel  wrote:
> On Mon, 2016-10-03 at 19:09 -0700, Andy Lutomirski wrote:
>
>> > Having two separate status booleans for "registers valid"
>> > and "memory valid" may make more sense.
>>
>> I have no problem with the concept of "owner_ctx", and I think it's a
>> perfectly reasonable data structure.  My problem with it is that it's
>> subtle and knowledge of it is spread all over the place.  Just going
>> with "registers valid" in a variable won't work, I think, because
>> there's nowhere to put it.  We need to be able to delete a struct fpu
>> while that struct fpu might have a valid copy in a different cpu's
>> registers.
>>
>> Anyway, feel free to tell me that I'm making this too difficult :)
>
> How about we rename fpu_want_lazy_restore to
> fpu_registers_valid()?  Problem solved :)
>
> Then we can rename __cpu_disable_lazy_restore
> to fpu_invalidate_registers(), and call that
> before we modify any in-memory FPU state.

Sounds good to me.

>
>> > We can get rid of fpu.counter, since nobody uses it
>> > any more.
>>
>> We should definitely do this.
>>
>> Maybe getting in some cleanups first (my lazy fpu deletion,
>> fpu.counter removal, etc) first is the way to go.
>
> Sounds good.  I will keep my patch 1/4 as part of the
> cleanup series, and will not move on to the harder
> stuff until after the cleanups.
>
> Any other stuff I should clean up while we're there?

Almost certainly, but nothing I'm thinking of right now :)

>
>> > > > >
>> > You are right, read_pkru() and write_pkru() can only deal with
>> > the pkru state being present in registers. Is this because of an
>> > assumption in the code, or because of a hardware requirement?
>
> read_pkru and write_pkru would be candidates for using
> fpu_registers_valid, and potentially a fpu_make_registers_valid,
> which restores the contents of the fpu registers from memory,
> if fpu_registers_valid is not true.
>
> Likewise, we can have an fpu_make_memory_valid to ensure the
> in kernel memory copy of the FPU registers is valid, potentially
> a _read and _write version that do exactly what the pstate code
> wants today.
>
> Would that make sense as an API?
>
> --
> All Rights Reversed.



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

[Andy Lutomirski]

On Mon, Oct 3, 2016 at 7:47 PM, Rik van Riel  wrote:
> On Mon, 2016-10-03 at 19:09 -0700, Andy Lutomirski wrote:
>
>> > Having two separate status booleans for "registers valid"
>> > and "memory valid" may make more sense.
>>
>> I have no problem with the concept of "owner_ctx", and I think it's a
>> perfectly reasonable data structure.  My problem with it is that it's
>> subtle and knowledge of it is spread all over the place.  Just going
>> with "registers valid" in a variable won't work, I think, because
>> there's nowhere to put it.  We need to be able to delete a struct fpu
>> while that struct fpu might have a valid copy in a different cpu's
>> registers.
>>
>> Anyway, feel free to tell me that I'm making this too difficult :)
>
> How about we rename fpu_want_lazy_restore to
> fpu_registers_valid()?  Problem solved :)
>
> Then we can rename __cpu_disable_lazy_restore
> to fpu_invalidate_registers(), and call that
> before we modify any in-memory FPU state.

Sounds good to me.

>
>> > We can get rid of fpu.counter, since nobody uses it
>> > any more.
>>
>> We should definitely do this.
>>
>> Maybe getting in some cleanups first (my lazy fpu deletion,
>> fpu.counter removal, etc) first is the way to go.
>
> Sounds good.  I will keep my patch 1/4 as part of the
> cleanup series, and will not move on to the harder
> stuff until after the cleanups.
>
> Any other stuff I should clean up while we're there?

Almost certainly, but nothing I'm thinking of right now :)

>
>> > > > >
>> > You are right, read_pkru() and write_pkru() can only deal with
>> > the pkru state being present in registers. Is this because of an
>> > assumption in the code, or because of a hardware requirement?
>
> read_pkru and write_pkru would be candidates for using
> fpu_registers_valid, and potentially a fpu_make_registers_valid,
> which restores the contents of the fpu registers from memory,
> if fpu_registers_valid is not true.
>
> Likewise, we can have an fpu_make_memory_valid to ensure the
> in kernel memory copy of the FPU registers is valid, potentially
> a _read and _write version that do exactly what the pstate code
> wants today.
>
> Would that make sense as an API?
>
> --
> All Rights Reversed.



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

[Andy Lutomirski]

On Oct 3, 2016 7:11 PM, "Rik van Riel"  wrote:
>
> On Mon, 2016-10-03 at 14:36 -0700, Andy Lutomirski wrote:
> >
> > Anything else that tries to read task xstate from memory, i.e. MPX
> > and
> > PKRU.  (Although if we switch to eager-switched PKRU, then PKRU stops
> > mattering for this purpose.)
> >
> > Actually, I don't see any way your patches can be compatible with
> > PKRU
> > without switching to eager-switched PKRU.
>
> There is one case where the in-register PKRU state matters:
> - user space accesses to memory
>
> There are several cases where the in-memory PKRU state would
> suffice:
> - get_user_pages(_fast) to the local task (could also use registers)
> - setting VMA/PTE permission bits (could also use registers)
>
> There is one case where only in-memory PKRU state works, where
> PKRU is currently simply ignored:
> - get_user_pages to another task's memory

Also __get_user, etc.  I don't think you want to start playing with
TIF_LOAD_FPU there.  I think tracking PKRU separately and eagerly
loading it with WRPKRU may be the only decent choice here.

>
> Dave, are there major obstacles to making read_pkru and write_pkru
> work with in-memory state?
>
> Would it be better for read/write_pkru to force the FPU state
> to get loaded into registers, under the assumption that if things
> like get_user_pages_fast happens, we will likely switch back to
> userspace soon, anyway?
>
> Would that assumption be wrong with KVM? :)

>
> --
> All Rights Reversed.

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

[Andy Lutomirski]

On Oct 3, 2016 7:11 PM, "Rik van Riel"  wrote:
>
> On Mon, 2016-10-03 at 14:36 -0700, Andy Lutomirski wrote:
> >
> > Anything else that tries to read task xstate from memory, i.e. MPX
> > and
> > PKRU.  (Although if we switch to eager-switched PKRU, then PKRU stops
> > mattering for this purpose.)
> >
> > Actually, I don't see any way your patches can be compatible with
> > PKRU
> > without switching to eager-switched PKRU.
>
> There is one case where the in-register PKRU state matters:
> - user space accesses to memory
>
> There are several cases where the in-memory PKRU state would
> suffice:
> - get_user_pages(_fast) to the local task (could also use registers)
> - setting VMA/PTE permission bits (could also use registers)
>
> There is one case where only in-memory PKRU state works, where
> PKRU is currently simply ignored:
> - get_user_pages to another task's memory

Also __get_user, etc.  I don't think you want to start playing with
TIF_LOAD_FPU there.  I think tracking PKRU separately and eagerly
loading it with WRPKRU may be the only decent choice here.

>
> Dave, are there major obstacles to making read_pkru and write_pkru
> work with in-memory state?
>
> Would it be better for read/write_pkru to force the FPU state
> to get loaded into registers, under the assumption that if things
> like get_user_pages_fast happens, we will likely switch back to
> userspace soon, anyway?
>
> Would that assumption be wrong with KVM? :)

>
> --
> All Rights Reversed.

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

[Jeffrey Merkey]

On 10/3/16, Joe Perches  wrote:
>
> On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote:
>> Hi Joe,
>
> Hi Stephen.
>
>> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches  wrote:
>> >
>> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
>> > > The following changes since commit
>> > > c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
>> > >
>> > >   Linux 4.8 (2016-10-02 16:24:33 -0700)
>> > >
>> > > are available in the git repository at:
>> > >
>> > >   https://github.com/jeffmerkey/linux.git mdb-v4.8
>> > >
>> > > for you to fetch changes up to
>> > > 8e3486647ebcef24e67fc2eebe49f3641a4ffc95:
>> > >
>> > >   Add MDB Debugger to Linux Kernel v4.8 (2016-10-02 20:33:55 -0600)
>> >
>> >
>> > Stephen, can this tree be added to -next to get some
>> > exposure for the next cycle?
>>
>>
>> I don't add trees during the merge window (unless they contain stuff
>> for the current merge window and, even then, only rarely).  Also, I
>> only take requests from the maintainer/owner of the tree.
>
> No worries, it's really a request for Jeff who doesn't seem
> to know the process very well.
>
> Jeff, you really should get this into -next before sending a
> pull request to Linus for this large bit of code.
>
>> Has there been much recent discussion/review/testing of this tree?
>
> Not to my knowledge for about 6 months now.
>
>> Is it likely that Linus will merge it?  (Just asking, I haven't been
>> following it.)
>
> Dunno.  I'd guess it will _not_ be merged without some time
> in -next and a compelling reason to use it.
>
>

Hi Joe,
Hi Stephen,

I put it out as a pull request so the kbuild test robot can build it
against all sort of configs to make certain it runs across all
i386/x86_64 configs.  If I recall correctly, Ingo Molnar stated he
would be interested in mdb being chopped up into pieces and possibly
integrated into kdb, since MDB has a very good disassembler and
conditional breakpoints which kdb lacks, if I understood what he said
last linux release when this came up.

Since I produce mdb for mostly my own internal use, I have not done
this integration work as of yet as I have been more a user of MDB than
the developer of late.  That's not to say someone else could do what
Ingo suggested, and I have looked over KDB but to be honest, it would
require a whole lot of non-intrusive changes to kdb to pull it off --
not impossible but where I left it with Ingo is he would need to ask
and be specific about what changes or sections he would want in KDB.
Without specific guidance from him, I hesitate to work on it -- in
other words he needs to ask me exactly what he expects to be done
here.   kdb is a very unstable tool from what limited testing I have
done and it's processor roundup for SMP systems is a very different
approach from mdb and is prone to crashes and lockups (particularly
when you are servicing multiple NMI interrupts and more then one of
the processors ends up in the INT1 exception handler).

MDB's plus to Linux is a working deferenced disassembler which kdb
lacks.  Ingo did not like the fact the MDB is monolithic if I read
what he said correctly, and I can see his point, however, debuggers
are always tightly coupled with the underlying arch.  kgdb is
interesting but is not a standalone debugger, requires two boxes, and
uses a cumbersome command syntax.

That being said, Ingo will need to ask me to do the work then be a
little more forthright about his interest -- if any -- and provide
some guidance.  If Linus wants to pull it be my guest.  It's always
out there for him or anyone else who needs it.

:-)

Jeff

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

[Jeffrey Merkey]

On 10/3/16, Joe Perches  wrote:
>
> On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote:
>> Hi Joe,
>
> Hi Stephen.
>
>> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches  wrote:
>> >
>> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
>> > > The following changes since commit
>> > > c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
>> > >
>> > >   Linux 4.8 (2016-10-02 16:24:33 -0700)
>> > >
>> > > are available in the git repository at:
>> > >
>> > >   https://github.com/jeffmerkey/linux.git mdb-v4.8
>> > >
>> > > for you to fetch changes up to
>> > > 8e3486647ebcef24e67fc2eebe49f3641a4ffc95:
>> > >
>> > >   Add MDB Debugger to Linux Kernel v4.8 (2016-10-02 20:33:55 -0600)
>> >
>> >
>> > Stephen, can this tree be added to -next to get some
>> > exposure for the next cycle?
>>
>>
>> I don't add trees during the merge window (unless they contain stuff
>> for the current merge window and, even then, only rarely).  Also, I
>> only take requests from the maintainer/owner of the tree.
>
> No worries, it's really a request for Jeff who doesn't seem
> to know the process very well.
>
> Jeff, you really should get this into -next before sending a
> pull request to Linus for this large bit of code.
>
>> Has there been much recent discussion/review/testing of this tree?
>
> Not to my knowledge for about 6 months now.
>
>> Is it likely that Linus will merge it?  (Just asking, I haven't been
>> following it.)
>
> Dunno.  I'd guess it will _not_ be merged without some time
> in -next and a compelling reason to use it.
>
>

Hi Joe,
Hi Stephen,

I put it out as a pull request so the kbuild test robot can build it
against all sort of configs to make certain it runs across all
i386/x86_64 configs.  If I recall correctly, Ingo Molnar stated he
would be interested in mdb being chopped up into pieces and possibly
integrated into kdb, since MDB has a very good disassembler and
conditional breakpoints which kdb lacks, if I understood what he said
last linux release when this came up.

Since I produce mdb for mostly my own internal use, I have not done
this integration work as of yet as I have been more a user of MDB than
the developer of late.  That's not to say someone else could do what
Ingo suggested, and I have looked over KDB but to be honest, it would
require a whole lot of non-intrusive changes to kdb to pull it off --
not impossible but where I left it with Ingo is he would need to ask
and be specific about what changes or sections he would want in KDB.
Without specific guidance from him, I hesitate to work on it -- in
other words he needs to ask me exactly what he expects to be done
here.   kdb is a very unstable tool from what limited testing I have
done and it's processor roundup for SMP systems is a very different
approach from mdb and is prone to crashes and lockups (particularly
when you are servicing multiple NMI interrupts and more then one of
the processors ends up in the INT1 exception handler).

MDB's plus to Linux is a working deferenced disassembler which kdb
lacks.  Ingo did not like the fact the MDB is monolithic if I read
what he said correctly, and I can see his point, however, debuggers
are always tightly coupled with the underlying arch.  kgdb is
interesting but is not a standalone debugger, requires two boxes, and
uses a cumbersome command syntax.

That being said, Ingo will need to ask me to do the work then be a
little more forthright about his interest -- if any -- and provide
some guidance.  If Linus wants to pull it be my guest.  It's always
out there for him or anyone else who needs it.

:-)

Jeff

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

[Rik van Riel]

On Mon, 2016-10-03 at 19:09 -0700, Andy Lutomirski wrote:

> > Having two separate status booleans for "registers valid"
> > and "memory valid" may make more sense.
> 
> I have no problem with the concept of "owner_ctx", and I think it's a
> perfectly reasonable data structure.  My problem with it is that it's
> subtle and knowledge of it is spread all over the place.  Just going
> with "registers valid" in a variable won't work, I think, because
> there's nowhere to put it.  We need to be able to delete a struct fpu
> while that struct fpu might have a valid copy in a different cpu's
> registers.
> 
> Anyway, feel free to tell me that I'm making this too difficult :)

How about we rename fpu_want_lazy_restore to
fpu_registers_valid()?  Problem solved :)

Then we can rename __cpu_disable_lazy_restore
to fpu_invalidate_registers(), and call that
before we modify any in-memory FPU state.

> > We can get rid of fpu.counter, since nobody uses it
> > any more.
> 
> We should definitely do this.
> 
> Maybe getting in some cleanups first (my lazy fpu deletion,
> fpu.counter removal, etc) first is the way to go.

Sounds good.  I will keep my patch 1/4 as part of the
cleanup series, and will not move on to the harder
stuff until after the cleanups.

Any other stuff I should clean up while we're there?

> > > > > 
> > You are right, read_pkru() and write_pkru() can only deal with
> > the pkru state being present in registers. Is this because of an
> > assumption in the code, or because of a hardware requirement?

read_pkru and write_pkru would be candidates for using
fpu_registers_valid, and potentially a fpu_make_registers_valid,
which restores the contents of the fpu registers from memory,
if fpu_registers_valid is not true.

Likewise, we can have an fpu_make_memory_valid to ensure the
in kernel memory copy of the FPU registers is valid, potentially
a _read and _write version that do exactly what the pstate code
wants today.

Would that make sense as an API?

-- 
All Rights Reversed.

signature.asc
Description: This is a digitally signed message part

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

[Rik van Riel]

On Mon, 2016-10-03 at 19:09 -0700, Andy Lutomirski wrote:

> > Having two separate status booleans for "registers valid"
> > and "memory valid" may make more sense.
> 
> I have no problem with the concept of "owner_ctx", and I think it's a
> perfectly reasonable data structure.  My problem with it is that it's
> subtle and knowledge of it is spread all over the place.  Just going
> with "registers valid" in a variable won't work, I think, because
> there's nowhere to put it.  We need to be able to delete a struct fpu
> while that struct fpu might have a valid copy in a different cpu's
> registers.
> 
> Anyway, feel free to tell me that I'm making this too difficult :)

How about we rename fpu_want_lazy_restore to
fpu_registers_valid()?  Problem solved :)

Then we can rename __cpu_disable_lazy_restore
to fpu_invalidate_registers(), and call that
before we modify any in-memory FPU state.

> > We can get rid of fpu.counter, since nobody uses it
> > any more.
> 
> We should definitely do this.
> 
> Maybe getting in some cleanups first (my lazy fpu deletion,
> fpu.counter removal, etc) first is the way to go.

Sounds good.  I will keep my patch 1/4 as part of the
cleanup series, and will not move on to the harder
stuff until after the cleanups.

Any other stuff I should clean up while we're there?

> > > > > 
> > You are right, read_pkru() and write_pkru() can only deal with
> > the pkru state being present in registers. Is this because of an
> > assumption in the code, or because of a hardware requirement?

read_pkru and write_pkru would be candidates for using
fpu_registers_valid, and potentially a fpu_make_registers_valid,
which restores the contents of the fpu registers from memory,
if fpu_registers_valid is not true.

Likewise, we can have an fpu_make_memory_valid to ensure the
in kernel memory copy of the FPU registers is valid, potentially
a _read and _write version that do exactly what the pstate code
wants today.

Would that make sense as an API?

-- 
All Rights Reversed.

signature.asc
Description: This is a digitally signed message part

[PATCH 09/22] perf tools: Support CPU id matching for x86 v2

[Arnaldo Carvalho de Melo]

From: Andi Kleen 

Implement the code to match CPU types to mapfile types for x86 based on
CPUID. This extends an existing similar function, but changes it to use
the x86 mapfile cpu description.  This allows to resolve event lists
generated by jevents.

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Ingo Molnar 
Acked-by: Jiri Olsa 
Cc: Madhavan Srinivasan 
Cc: Peter Zijlstra 
Cc: linuxppc-...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/1473978296-20712-6-git-send-email-suka...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/util/header.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index 146d12a1cec0..a74a48db26f5 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -19,8 +19,8 @@ cpuid(unsigned int op, unsigned int *a, unsigned int *b, 
unsigned int *c,
: "a" (op));
 }
 
-int
-get_cpuid(char *buffer, size_t sz)
+static int
+__get_cpuid(char *buffer, size_t sz, const char *fmt)
 {
unsigned int a, b, c, d, lvl;
int family = -1, model = -1, step = -1;
@@ -48,7 +48,7 @@ get_cpuid(char *buffer, size_t sz)
if (family >= 0x6)
model += ((a >> 16) & 0xf) << 4;
}
-   nb = scnprintf(buffer, sz, "%s,%u,%u,%u$", vendor, family, model, step);
+   nb = scnprintf(buffer, sz, fmt, vendor, family, model, step);
 
/* look for end marker to ensure the entire data fit */
if (strchr(buffer, '$')) {
@@ -57,3 +57,21 @@ get_cpuid(char *buffer, size_t sz)
}
return -1;
 }
+
+int
+get_cpuid(char *buffer, size_t sz)
+{
+   return __get_cpuid(buffer, sz, "%s,%u,%u,%u$");
+}
+
+char *
+get_cpuid_str(void)
+{
+   char *buf = malloc(128);
+
+   if (__get_cpuid(buf, 128, "%s-%u-%X$") < 0) {
+   free(buf);
+   return NULL;
+   }
+   return buf;
+}
-- 
2.7.4

Re: [PATCH 2/4] regulator: Enable compile testing for Maxim and Samsung PMIC drivers

[Mark Brown]

On Sun, Oct 02, 2016 at 10:58:15PM +0200, Krzysztof Kozlowski wrote:
> Most of Maxim and Samsung PMIC/MUIC regulator drivers can be compile
> tested to increase build coverage.

All these drivers already just depend on the MFDs which don't have any
weird architecture dependencies - the main goal with COMPILE_TEST is
usually to eliminate dependencies which just can't be selected so they
can be built at all.  Given that there's no easy way to select
everything in a subsystem otherwise does this buy us a lot?


signature.asc
Description: PGP signature

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

[Joe Perches]

On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote:
> Hi Joe,

Hi Stephen.

> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches  wrote:
> > 
> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
> > > The following changes since commit 
> > > c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
> > > 
> > >   Linux 4.8 (2016-10-02 16:24:33 -0700)
> > > 
> > > are available in the git repository at:
> > > 
> > >   https://github.com/jeffmerkey/linux.git mdb-v4.8
> > > 
> > > for you to fetch changes up to 8e3486647ebcef24e67fc2eebe49f3641a4ffc95:
> > > 
> > >   Add MDB Debugger to Linux Kernel v4.8 (2016-10-02 20:33:55 -0600)  
> > 
> > 
> > Stephen, can this tree be added to -next to get some
> > exposure for the next cycle?
> 
> 
> I don't add trees during the merge window (unless they contain stuff
> for the current merge window and, even then, only rarely).  Also, I
> only take requests from the maintainer/owner of the tree.

No worries, it's really a request for Jeff who doesn't seem
to know the process very well.

Jeff, you really should get this into -next before sending a
pull request to Linus for this large bit of code.

> Has there been much recent discussion/review/testing of this tree?

Not to my knowledge for about 6 months now.

> Is it likely that Linus will merge it?  (Just asking, I haven't been
> following it.)

Dunno.  I'd guess it will _not_ be merged without some time
in -next and a compelling reason to use it.

[PATCH 09/22] perf tools: Support CPU id matching for x86 v2

[Arnaldo Carvalho de Melo]

From: Andi Kleen 

Implement the code to match CPU types to mapfile types for x86 based on
CPUID. This extends an existing similar function, but changes it to use
the x86 mapfile cpu description.  This allows to resolve event lists
generated by jevents.

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Ingo Molnar 
Acked-by: Jiri Olsa 
Cc: Madhavan Srinivasan 
Cc: Peter Zijlstra 
Cc: linuxppc-...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/1473978296-20712-6-git-send-email-suka...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/util/header.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index 146d12a1cec0..a74a48db26f5 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -19,8 +19,8 @@ cpuid(unsigned int op, unsigned int *a, unsigned int *b, 
unsigned int *c,
: "a" (op));
 }
 
-int
-get_cpuid(char *buffer, size_t sz)
+static int
+__get_cpuid(char *buffer, size_t sz, const char *fmt)
 {
unsigned int a, b, c, d, lvl;
int family = -1, model = -1, step = -1;
@@ -48,7 +48,7 @@ get_cpuid(char *buffer, size_t sz)
if (family >= 0x6)
model += ((a >> 16) & 0xf) << 4;
}
-   nb = scnprintf(buffer, sz, "%s,%u,%u,%u$", vendor, family, model, step);
+   nb = scnprintf(buffer, sz, fmt, vendor, family, model, step);
 
/* look for end marker to ensure the entire data fit */
if (strchr(buffer, '$')) {
@@ -57,3 +57,21 @@ get_cpuid(char *buffer, size_t sz)
}
return -1;
 }
+
+int
+get_cpuid(char *buffer, size_t sz)
+{
+   return __get_cpuid(buffer, sz, "%s,%u,%u,%u$");
+}
+
+char *
+get_cpuid_str(void)
+{
+   char *buf = malloc(128);
+
+   if (__get_cpuid(buf, 128, "%s-%u-%X$") < 0) {
+   free(buf);
+   return NULL;
+   }
+   return buf;
+}
-- 
2.7.4

Re: [PATCH 2/4] regulator: Enable compile testing for Maxim and Samsung PMIC drivers

[Mark Brown]

On Sun, Oct 02, 2016 at 10:58:15PM +0200, Krzysztof Kozlowski wrote:
> Most of Maxim and Samsung PMIC/MUIC regulator drivers can be compile
> tested to increase build coverage.

All these drivers already just depend on the MFDs which don't have any
weird architecture dependencies - the main goal with COMPILE_TEST is
usually to eliminate dependencies which just can't be selected so they
can be built at all.  Given that there's no easy way to select
everything in a subsystem otherwise does this buy us a lot?


signature.asc
Description: PGP signature

Re: [GIT PULL] MDB Linux Kernel Debugger v4.8 (for kbuild robot testing)

[Joe Perches]

On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote:
> Hi Joe,

Hi Stephen.

> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches  wrote:
> > 
> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
> > > The following changes since commit 
> > > c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
> > > 
> > >   Linux 4.8 (2016-10-02 16:24:33 -0700)
> > > 
> > > are available in the git repository at:
> > > 
> > >   https://github.com/jeffmerkey/linux.git mdb-v4.8
> > > 
> > > for you to fetch changes up to 8e3486647ebcef24e67fc2eebe49f3641a4ffc95:
> > > 
> > >   Add MDB Debugger to Linux Kernel v4.8 (2016-10-02 20:33:55 -0600)  
> > 
> > 
> > Stephen, can this tree be added to -next to get some
> > exposure for the next cycle?
> 
> 
> I don't add trees during the merge window (unless they contain stuff
> for the current merge window and, even then, only rarely).  Also, I
> only take requests from the maintainer/owner of the tree.

No worries, it's really a request for Jeff who doesn't seem
to know the process very well.

Jeff, you really should get this into -next before sending a
pull request to Linus for this large bit of code.

> Has there been much recent discussion/review/testing of this tree?

Not to my knowledge for about 6 months now.

> Is it likely that Linus will merge it?  (Just asking, I haven't been
> following it.)

Dunno.  I'd guess it will _not_ be merged without some time
in -next and a compelling reason to use it.

[PATCH 17/22] perf list jevents: Add support for event list topics

[Arnaldo Carvalho de Melo]

From: Andi Kleen 

Add support to group the output of perf list by the Topic field in the
JSON file.

Example output:

% perf list
...
Cache:
  l1d.replacement
   [L1D data line replacements]
  l1d_pend_miss.pending
   [L1D miss oustandings duration in cycles]
  l1d_pend_miss.pending_cycles
   [Cycles with L1D load Misses outstanding]
  l2_l1d_wb_rqsts.all
   [Not rejected writebacks from L1D to L2 cache lines in any state]
  l2_l1d_wb_rqsts.hit_e
   [Not rejected writebacks from L1D to L2 cache lines in E state]
  l2_l1d_wb_rqsts.hit_m
   [Not rejected writebacks from L1D to L2 cache lines in M state]

...
Pipeline:
  arith.fpu_div
   [Divide operations executed]
  arith.fpu_div_active
   [Cycles when divider is busy executing divide operations]
  baclears.any
   [Counts the total number when the front end is resteered, mainly
   when the BPU cannot provide a correct prediction and this is
   corrected by other branch handling mechanisms at the front end]
  br_inst_exec.all_branches
   [Speculative and retired branches]
  br_inst_exec.all_conditional
   [Speculative and retired macro-conditional branches]
  br_inst_exec.all_direct_jmp
   [Speculative and retired macro-unconditional branches excluding
   calls and indirects]
  br_inst_exec.all_direct_near_call
   [Speculative and retired direct near calls]
  br_inst_exec.all_indirect_jump_non_call_ret

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Ingo Molnar 
Acked-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Madhavan Srinivasan 
Cc: Peter Zijlstra 
Cc: linuxppc-...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/1473978296-20712-14-git-send-email-suka...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/pmu.c | 37 +++--
 tools/perf/util/pmu.h |  1 +
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 8ff382cb161d..b1474dcadfa2 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -223,7 +223,8 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias 
*alias,
 }
 
 static int __perf_pmu__new_alias(struct list_head *list, char *dir, char *name,
-char *desc, char *val, char *long_desc)
+char *desc, char *val, char *long_desc,
+char *topic)
 {
struct perf_pmu_alias *alias;
int ret;
@@ -259,6 +260,7 @@ static int __perf_pmu__new_alias(struct list_head *list, 
char *dir, char *name,
alias->desc = desc ? strdup(desc) : NULL;
alias->long_desc = long_desc ? strdup(long_desc) :
desc ? strdup(desc) : NULL;
+   alias->topic = topic ? strdup(topic) : NULL;
 
list_add_tail(>list, list);
 
@@ -276,7 +278,7 @@ static int perf_pmu__new_alias(struct list_head *list, char 
*dir, char *name, FI
 
buf[ret] = 0;
 
-   return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL);
+   return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL, NULL);
 }
 
 static inline bool pmu_alias_info_file(char *name)
@@ -535,7 +537,7 @@ static void pmu_add_cpu_aliases(struct list_head *head)
/* need type casts to override 'const' */
__perf_pmu__new_alias(head, NULL, (char *)pe->name,
(char *)pe->desc, (char *)pe->event,
-   (char *)pe->long_desc);
+   (char *)pe->long_desc, (char *)pe->topic);
}
 
 out:
@@ -1055,19 +1057,26 @@ static char *format_alias_or(char *buf, int len, struct 
perf_pmu *pmu,
return buf;
 }
 
-struct pair {
+struct sevent {
char *name;
char *desc;
+   char *topic;
 };
 
-static int cmp_pair(const void *a, const void *b)
+static int cmp_sevent(const void *a, const void *b)
 {
-   const struct pair *as = a;
-   const struct pair *bs = b;
+   const struct sevent *as = a;
+   const struct sevent *bs = b;
 
/* Put extra events last */
if (!!as->desc != !!bs->desc)
return !!as->desc - !!bs->desc;
+   if (as->topic && bs->topic) {
+   int n = strcmp(as->topic, bs->topic);
+
+   if (n)
+   return n;
+   }
return strcmp(as->name, bs->name);
 }
 
@@ -1101,9 +1110,10 @@ void print_pmu_events(const char *event_glob, bool 
name_only, bool quiet_flag,
char buf[1024];
int printed = 0;
int len, j;
-   struct pair *aliases;
+   struct sevent *aliases;
int numdesc = 0;
int columns = pager_get_columns();
+   char *topic = NULL;
 
pmu = NULL;
   

[PATCH 07/22] perf pmu: Use pmu_events table to create aliases

[Arnaldo Carvalho de Melo]

From: Sukadev Bhattiprolu 

At run time (when 'perf' is starting up), locate the specific table of
PMU events that corresponds to the current CPU. Using that table, create
aliases for the each of the PMU events in the CPU. The use these aliases
to parse the user specified perf event.

In short this would allow the user to specify events using their aliases
rather than raw event codes.

Based on input and some earlier patches from Andi Kleen, Jiri Olsa.

Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Ingo Molnar 
Acked-by: Jiri Olsa 
Cc: Madhavan Srinivasan 
Cc: Peter Zijlstra 
Cc: linuxppc-...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/1473978296-20712-4-git-send-email-suka...@linux.vnet.ibm.com
[ Make pmu_add_cpu_aliases() return void, since it was returning just '0' and
  furthermore, even that was being discarded via an explicit (void) cast ]
Signed-off-by: Arnaldo Carvalho de Melo 

Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/header.h |  1 +
 tools/perf/util/pmu.c| 60 
 2 files changed, 61 insertions(+)

diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index d306ca118449..d30109b421ee 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -151,4 +151,5 @@ int write_padded(int fd, const void *bf, size_t count, 
size_t count_aligned);
  */
 int get_cpuid(char *buffer, size_t sz);
 
+char *get_cpuid_str(void);
 #endif /* __PERF_HEADER_H */
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 2babcdf62839..10668b7f5272 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -12,6 +12,8 @@
 #include "pmu.h"
 #include "parse-events.h"
 #include "cpumap.h"
+#include "header.h"
+#include "pmu-events/pmu-events.h"
 
 struct perf_pmu_format {
char *name;
@@ -473,6 +475,61 @@ static struct cpu_map *pmu_cpumask(const char *name)
return cpus;
 }
 
+/*
+ * Return the CPU id as a raw string.
+ *
+ * Each architecture should provide a more precise id string that
+ * can be use to match the architecture's "mapfile".
+ */
+char * __weak get_cpuid_str(void)
+{
+   return NULL;
+}
+
+/*
+ * From the pmu_events_map, find the table of PMU events that corresponds
+ * to the current running CPU. Then, add all PMU events from that table
+ * as aliases.
+ */
+static void pmu_add_cpu_aliases(struct list_head *head)
+{
+   int i;
+   struct pmu_events_map *map;
+   struct pmu_event *pe;
+   char *cpuid;
+
+   cpuid = get_cpuid_str();
+   if (!cpuid)
+   return;
+
+   i = 0;
+   while (1) {
+   map = _events_map[i++];
+   if (!map->table)
+   goto out;
+
+   if (!strcmp(map->cpuid, cpuid))
+   break;
+   }
+
+   /*
+* Found a matching PMU events table. Create aliases
+*/
+   i = 0;
+   while (1) {
+   pe = >table[i++];
+   if (!pe->name)
+   break;
+
+   /* need type casts to override 'const' */
+   __perf_pmu__new_alias(head, NULL, (char *)pe->name,
+   (char *)pe->desc, (char *)pe->event);
+   }
+
+out:
+   free(cpuid);
+}
+
 struct perf_event_attr * __weak
 perf_pmu__get_default_config(struct perf_pmu *pmu __maybe_unused)
 {
@@ -497,6 +554,9 @@ static struct perf_pmu *pmu_lookup(const char *name)
if (pmu_aliases(name, ))
return NULL;
 
+   if (!strcmp(name, "cpu"))
+   pmu_add_cpu_aliases();
+
if (pmu_type(name, ))
return NULL;
 
-- 
2.7.4

[PATCH 10/22] perf jevents: Handle header line in mapfile

[Arnaldo Carvalho de Melo]

From: Andi Kleen 

To work with existing mapfiles, assume that the first line in
'mapfile.csv' is a header line and skip over it.

Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Ingo Molnar 
Acked-by: Jiri Olsa 
Cc: Madhavan Srinivasan 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1473978296-20712-15-git-send-email-suka...@linux.vnet.ibm.com
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Andi Kleen 
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/pmu-events/jevents.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index c4c074a49b6e..c9bf9a7dc7b2 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -477,7 +477,12 @@ static int process_mapfile(FILE *outfp, char *fpath)
 
print_mapping_table_prefix(outfp);
 
-   line_num = 0;
+   /* Skip first line (header) */
+   p = fgets(line, n, mapfp);
+   if (!p)
+   goto out;
+
+   line_num = 1;
while (1) {
char *cpuid, *version, *type, *fname;
 
@@ -521,8 +526,8 @@ static int process_mapfile(FILE *outfp, char *fpath)
fprintf(outfp, "},\n");
}
 
+out:
print_mapping_table_suffix(outfp);
-
return 0;
 }
 
-- 
2.7.4

[PATCH 17/22] perf list jevents: Add support for event list topics

[Arnaldo Carvalho de Melo]

From: Andi Kleen 

Add support to group the output of perf list by the Topic field in the
JSON file.

Example output:

% perf list
...
Cache:
  l1d.replacement
   [L1D data line replacements]
  l1d_pend_miss.pending
   [L1D miss oustandings duration in cycles]
  l1d_pend_miss.pending_cycles
   [Cycles with L1D load Misses outstanding]
  l2_l1d_wb_rqsts.all
   [Not rejected writebacks from L1D to L2 cache lines in any state]
  l2_l1d_wb_rqsts.hit_e
   [Not rejected writebacks from L1D to L2 cache lines in E state]
  l2_l1d_wb_rqsts.hit_m
   [Not rejected writebacks from L1D to L2 cache lines in M state]

...
Pipeline:
  arith.fpu_div
   [Divide operations executed]
  arith.fpu_div_active
   [Cycles when divider is busy executing divide operations]
  baclears.any
   [Counts the total number when the front end is resteered, mainly
   when the BPU cannot provide a correct prediction and this is
   corrected by other branch handling mechanisms at the front end]
  br_inst_exec.all_branches
   [Speculative and retired branches]
  br_inst_exec.all_conditional
   [Speculative and retired macro-conditional branches]
  br_inst_exec.all_direct_jmp
   [Speculative and retired macro-unconditional branches excluding
   calls and indirects]
  br_inst_exec.all_direct_near_call
   [Speculative and retired direct near calls]
  br_inst_exec.all_indirect_jump_non_call_ret

Signed-off-by: Andi Kleen 
Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Ingo Molnar 
Acked-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Madhavan Srinivasan 
Cc: Peter Zijlstra 
Cc: linuxppc-...@lists.ozlabs.org
Link: 
http://lkml.kernel.org/r/1473978296-20712-14-git-send-email-suka...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/pmu.c | 37 +++--
 tools/perf/util/pmu.h |  1 +
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 8ff382cb161d..b1474dcadfa2 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -223,7 +223,8 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias 
*alias,
 }
 
 static int __perf_pmu__new_alias(struct list_head *list, char *dir, char *name,
-char *desc, char *val, char *long_desc)
+char *desc, char *val, char *long_desc,
+char *topic)
 {
struct perf_pmu_alias *alias;
int ret;
@@ -259,6 +260,7 @@ static int __perf_pmu__new_alias(struct list_head *list, 
char *dir, char *name,
alias->desc = desc ? strdup(desc) : NULL;
alias->long_desc = long_desc ? strdup(long_desc) :
desc ? strdup(desc) : NULL;
+   alias->topic = topic ? strdup(topic) : NULL;
 
list_add_tail(>list, list);
 
@@ -276,7 +278,7 @@ static int perf_pmu__new_alias(struct list_head *list, char 
*dir, char *name, FI
 
buf[ret] = 0;
 
-   return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL);
+   return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL, NULL);
 }
 
 static inline bool pmu_alias_info_file(char *name)
@@ -535,7 +537,7 @@ static void pmu_add_cpu_aliases(struct list_head *head)
/* need type casts to override 'const' */
__perf_pmu__new_alias(head, NULL, (char *)pe->name,
(char *)pe->desc, (char *)pe->event,
-   (char *)pe->long_desc);
+   (char *)pe->long_desc, (char *)pe->topic);
}
 
 out:
@@ -1055,19 +1057,26 @@ static char *format_alias_or(char *buf, int len, struct 
perf_pmu *pmu,
return buf;
 }
 
-struct pair {
+struct sevent {
char *name;
char *desc;
+   char *topic;
 };
 
-static int cmp_pair(const void *a, const void *b)
+static int cmp_sevent(const void *a, const void *b)
 {
-   const struct pair *as = a;
-   const struct pair *bs = b;
+   const struct sevent *as = a;
+   const struct sevent *bs = b;
 
/* Put extra events last */
if (!!as->desc != !!bs->desc)
return !!as->desc - !!bs->desc;
+   if (as->topic && bs->topic) {
+   int n = strcmp(as->topic, bs->topic);
+
+   if (n)
+   return n;
+   }
return strcmp(as->name, bs->name);
 }
 
@@ -1101,9 +1110,10 @@ void print_pmu_events(const char *event_glob, bool 
name_only, bool quiet_flag,
char buf[1024];
int printed = 0;
int len, j;
-   struct pair *aliases;
+   struct sevent *aliases;
int numdesc = 0;
int columns = pager_get_columns();
+   char *topic = NULL;
 
pmu = NULL;
len = 0;
@@ -1113,7 +1123,7 @@ void print_pmu_events(const char *event_glob, bool 
name_only, bool quiet_flag,
if (pmu->selectable)
len++;
}