Barto | 28 Aug 20:50 2015
Picon

Re: [PATCH] PCI: Disable async suspend/resume for Jmicron chip

> 
> And are you sure you are already at kernel 4.6.1? ;)
> 
> Jay
> 

sorry, I meant "kernel 4.1.6", not 4.6.1 ;)

so I will wait the final version of this patch
Gabriel Fernandez | 27 Aug 14:34 2015

[PATCH v4 0/4] PCI: st: provide support for dw pcie


This patchset is based on v4.2-rc1 and is based on 
[PATCH v8 0/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
patchset from Zhou Wang.

Changes in v4:
 - Remove pci: designware: remove my pci_common_init_dev() patch and
	use [PATCH v8 3/6] PCI: designware: Add ARM64 support instead.
	This patch is a good solution for me to disable IO support.
 - add __init to st_pcie_probe() and use module_init() instead
	device_initcall() to prevent the probe function from being
	deferred and to prevent module unloading.

Changes in v3:
 - Remove power management functions (was not fully tested)
 - Remove configuration space range from dt binding
 - Remove pci_common_init_dev() call in pcie-designware.c to avoid 
   default IO space declaration. 

Changes in v2:
 - comestic corrections in device tree binding
 - add pci-st.c into MAINTAINERS
 - remove st_pcie_ops structure to avoid another level of indirection
 - remove nasty busy-loop
 - remove useless test using virt_to_phys()
 - move disable io support into dw-pcie driver

I don't change the st_pcie_abort_handler() function because abort handling
is masked during boot.

(Continue reading)

Kuninori Morimoto | 27 Aug 02:37 2015

[PATCH][resent] PCI: rcar: Add PCIE_CONF_REGNO macro for PCIECAR register

From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj <at> renesas.com>

The reg variable used when setting PCIECAR register need to be masked by 0xFC
by restriction of the corresponding register.
This adds PCIE_CONF_REGNO are macros for masking changes that PCIE_CONF_REGNO
is used when setting PCIECAR register.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj <at> renesas.com>
---
This patch was posted to ML, but still no response.
I re-sent it because original author has gone now.

 drivers/pci/host/pcie-rcar.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index c086210..9fd39cd8b 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
 <at>  <at>  -104,6 +104,7  <at>  <at> 
 #define  PCIE_CONF_BUS(b)	(((b) & 0xff) << 24)
 #define  PCIE_CONF_DEV(d)	(((d) & 0x1f) << 19)
 #define  PCIE_CONF_FUNC(f)	(((f) & 0x7) << 16)
+#define  PCIE_CONF_REGNO(r)	(r & 0xfc)

 #define RCAR_PCI_MAX_RESOURCES 4
 #define MAX_NR_INBOUND_MAPS 6
 <at>  <at>  -227,7 +228,8  <at>  <at>  static int rcar_pcie_config_access(struct rcar_pcie *pcie,

 	/* Set the PIO address */
(Continue reading)

Zhou Wang | 26 Aug 05:17 2015

[PATCH v2] PCI: designware: Fix PORT_LOGIC_LINK_WIDTH_MASK

The value under PORT_LOGIC_LINK_WIDTH_MASK is 0x1, 0x2, 0x4, 0x8. Here change
this mask to proper value.

In IP v4.2, bits [16:8] are defined for NUM_OF_LANES. But in IP v4.4, bits[12:8]
are defined for NUM_OF_LANES, bits [16:13] are for other usages(bit 16 is
AUTO_LANE_FLIP_CTRL_EN, bits [15:13] are PRE_DET_LANE).

As there is no conflict about NUM_OF_LANES between v4.2 and v4.4, this patch
change above mask value to avoid future problem.

Signed-off-by: Zhou Wang <wangzhou1 <at> hisilicon.com>
---
 drivers/pci/host/pcie-designware.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index 69486be..eb549b9 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
 <at>  <at>  -35,7 +35,7  <at>  <at> 

 #define PCIE_LINK_WIDTH_SPEED_CONTROL	0x80C
 #define PORT_LOGIC_SPEED_CHANGE		(0x1 << 17)
-#define PORT_LOGIC_LINK_WIDTH_MASK	(0x1ff << 8)
+#define PORT_LOGIC_LINK_WIDTH_MASK	(0x1f << 8)
 #define PORT_LOGIC_LINK_WIDTH_1_LANES	(0x1 << 8)
 #define PORT_LOGIC_LINK_WIDTH_2_LANES	(0x2 << 8)
 #define PORT_LOGIC_LINK_WIDTH_4_LANES	(0x4 << 8)
--

-- 
1.9.1
(Continue reading)

Paul Gortmaker | 26 Aug 02:25 2015

[PATCH] PCI: create builtin_pci_driver to avoid registration boilerplate

In commit f309d4443130bf814e991f836e919dca22df37ae ("platform_device:
better support builtin boilerplate avoidance") we introduced the
builtin_driver macro.

Here we use that support and extend it to PCI driver registration,
so where a driver is clearly non-modular and builtin-only, we can
register it in a similar fashion.  And existing code that is clearly
non-modular can be updated with the simple mapping of

     module_pci_driver(...)  ---> builtin_pci_driver(...)

We've essentially cloned the former to make the latter, and taken
out the remove/module_exit parts since those never get used in a
non-modular build of the code.

Cc: Bjorn Helgaas <bhelgaas <at> google.com>
Cc: linux-pci <at> vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker <at> windriver.com>
---
 include/linux/pci.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 88bee285b93d..8da2758e7d0e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
 <at>  <at>  -1187,6 +1187,17  <at>  <at>  void pci_unregister_driver(struct pci_driver *dev);
 	module_driver(__pci_driver, pci_register_driver, \
 		       pci_unregister_driver)

(Continue reading)

Yinghai Lu | 25 Aug 21:01 2015

Re: [PATCH v4 4/4] Use 2GB memory block size on large-memory x86-64 systems

On Tue, Aug 25, 2015 at 10:03 AM, Tony Luck <tony.luck <at> gmail.com> wrote:
> On Mon, Aug 24, 2015 at 4:59 PM, Yinghai Lu <yinghai <at> kernel.org> wrote:
>> attached should fix the problem:
>
> It does ... but this (attached) is simpler.  Your patch and mine both
> allow the system to boot ...

The version that fix with section_nr present checking may save couple thousands
calling to get_nid_for_pfn(). section size / page_size = 128M/4k = 32k

> but it is not happy. See all the chatter from systemd in the attached dmesg.

because of you have "debug ignore_loglevel" ?

>
> x86 doesn't allow me to set CONFIG_HOLES_IN_ZONE ... but now I'm
> worried about all the other places use pfn_valid_within()
>
> Still trying to get an answer from the BIOS folks on whether these
> holes are normal when setting up mirrored areas of memory.

The problem only happens when memory block size is 512M and section
size is 128M.
when you have them both at 128M, the system works. so current kernel
should only has
problem with hole size  > 128M to leave some section not present.

Thanks

Yinghai
(Continue reading)

Zhou Wang | 25 Aug 12:35 2015

[PATCH] PCI: designware: Fix PORT_LOGIC_LINK_WIDTH_MASK

The value under PORT_LOGIC_LINK_WIDTH_MASK is 0x1, 0x2, 0x4, 0x8. Here change
this mask to proper value.

In fact, for DesignWare PCIe IP version 4.4, it only uses bit8~12 to indicate
number of lanes. Original mask will bring a mistake.

Signed-off-by: Zhou Wang <wangzhou1 <at> hisilicon.com>
---
 drivers/pci/host/pcie-designware.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index 69486be..eb549b9 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
 <at>  <at>  -35,7 +35,7  <at>  <at> 

 #define PCIE_LINK_WIDTH_SPEED_CONTROL	0x80C
 #define PORT_LOGIC_SPEED_CHANGE		(0x1 << 17)
-#define PORT_LOGIC_LINK_WIDTH_MASK	(0x1ff << 8)
+#define PORT_LOGIC_LINK_WIDTH_MASK	(0x1f << 8)
 #define PORT_LOGIC_LINK_WIDTH_1_LANES	(0x1 << 8)
 #define PORT_LOGIC_LINK_WIDTH_2_LANES	(0x2 << 8)
 #define PORT_LOGIC_LINK_WIDTH_4_LANES	(0x4 << 8)
--

-- 
1.9.1

Zhou Wang | 25 Aug 11:58 2015

[PATCH v8 0/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

This patchset adds PCIe host support for HiSilicon SoC Hip05. The PCIe hosts
use PCIe IP core from Synopsys, So this driver is base on designware PCIe driver.

Hip05 is an ARMv8 architecture SoC. It should be able to use ARM64 PCIe API in
designeware PCIe driver. So this patch also adds ARM64 support for designware
pcie.

This patchset is based on v4.2-rc1.

Change from v7:
- Remove pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape,
  spear13xx. Pass pp->busn->start to pci_create_root_bus as root bus number.
- Remove bus-range parsing in pcie-hisi.c.

Change from v6:
- Add Pratyush's Acked-by for 1/6 and 2/6.
- Add James' Tested-by for 3/6.

Change from v5:
- Merge 1/6 in this series, discussion about this can be found in [1]

Change from v4:
- Change the author of 1/5 to Gabriele.
- Modify problems in 3/5 pointed by Bjorn.
- Modify spelling problems in 4/5.

Change from v3:
- Change 1/5 to what Gabriele suggested.
- Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3 series.

(Continue reading)

David Binderman | 24 Aug 22:41 2015
Picon

linux-4.2-rc8/drivers/pci/setup-bus.c: 2 * redundant conditions ?

Hello there,

1.

[linux-4.2-rc8/drivers/pci/setup-bus.c:946]: (style) Redundant condition: reallo
c_head. '!realloc_head || (realloc_head && !add_size)' is equivalent to '!reallo
c_head || !add_size'

Source code is

    size1 = (!realloc_head || (realloc_head && !add_size)) ? size0 :
        calculate_iosize(size, min_size, add_size + size1,
            resource_size(b_res), min_align);

2.

[linux-4.2-rc8/drivers/pci/setup-bus.c:1094]: (style) Redundant condition: reall
oc_head. '!realloc_head || (realloc_head && !add_size)' is equivalent to '!reall
oc_head || !add_size'

    size1 = (!realloc_head || (realloc_head && !add_size)) ? size0 :
        calculate_memsize(size, min_size, add_size,
                resource_size(b_res), add_align);

Duplicate.

Regards

David Binderman
 		 	   		  --
(Continue reading)

Ameya Palande | 24 Aug 21:32 2015
Picon

[PATCH] pciutils: Fix sysfs_get_string to handle invalid read

 - Fix minor indentation alignment

Signed-off-by: Ameya Palande <2ameya <at> gmail.com>
---
 lib/sysfs.c | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/lib/sysfs.c b/lib/sysfs.c
index 9f348bb..90ed013 100644
--- a/lib/sysfs.c
+++ b/lib/sysfs.c
 <at>  <at>  -99,15 +99,21  <at>  <at>  sysfs_get_string(struct pci_dev *d, char *object, char *buf, int mandatory)
   if (fd < 0)
     {
       if (mandatory)
-	a->error("Cannot open %s: %s", namebuf, strerror(errno));
+        a->error("Cannot open %s: %s", namebuf, strerror(errno));
       return 0;
     }
   n = read(fd, buf, OBJBUFSIZE);
   close(fd);
-  if (n < 0)
-    a->error("Error reading %s: %s", namebuf, strerror(errno));
-  if (n >= OBJBUFSIZE)
-    a->error("Value in %s too long", namebuf);
+  if (n < 0) {
+    if (mandatory)
+      a->error("Error reading %s: %s", namebuf, strerror(errno));
+    return 0;
+  }
(Continue reading)

Luis R. Rodriguez | 24 Aug 21:13 2015

[PATCH v4 00/11] x86/dma: RIP MTRR and dma write-combine API rename

From: "Luis R. Rodriguez" <mcgrof <at> suse.com>

Ingo,

This is my pending series of patches for both write-combining and moving
Linux' use of MTRR into the grave. It combines three set of straggler patch
series which have been pending integration for a while now. The rename patches
do not depend in any way with the MTRR patches but I've combined them here as
they are all pending and relating to write-combining. I explain why integration
of such patches has been delayed but also provide reasoning for why I believe
its time to merge them.

1) The DMA API rename for write-combining goes with the old naming convention
   defines added as suggested by you for any possible stragglers which may come
   up as this goes through and gets merged. We can remove the old define
   mappings after a release once this gets sucked in and things settle. These
   patches have been in Boris tree for a while but I keep having to refresh
   them as the kernel moves on, the addition of the old mapping should allow
   us to merge this without any collateral.

2) The PCI driver changes go with Tomi Valkeinen's Acks as well as
   Arnd Bergmann's own Acks for the PCI and asm-generic changes. This series
   was technically acknowledged by Bjorn to be correct and acceptable but his
   preference was for this to not use EXPORT_SYMBOL_GPL() as not *all*
   write-combine APIs are using EXPORT_SYMBOL_GPL(). Our goal on x86 though
   is to not deal with bug reports for new PAT APIs [0] and since its now clear
   through documentation that its up to the maintainers / developers if they
   decide to use EXPORT_SYMBOL_GPL() for new *features* [1] I keep that
   practice in alignment with our own x86 goals to avoid bug reports and
   issues with proprietary drivers on new PAT interfaces. Bjorn was happy for
(Continue reading)


Gmane