[PATCH 2/2] gpiolib: Fix unaligned used of reference counters

gpiolib relies on the reference counters to clean up the gpio_device structure. Although the number of get/put is properly aligned on gpiolib.c itself, it does not take into consideration how the referece counters are affected by other external functions such as cdev_add and device_add. Because

[PATCH 2/2] gpiolib: Fix unaligned used of reference counters

gpiolib relies on the reference counters to clean up the gpio_device structure. Although the number of get/put is properly aligned on gpiolib.c itself, it does not take into consideration how the referece counters are affected by other external functions such as cdev_add and device_add. Because

Re: [PATCH RFC v7 3/5] skb_array: array based FIFO for skbs

Could not compile this new version of skb_array.h, it complains about implicit declaration of function 'skb_vlan_tag_present' and 'VLAN_HLEN' being undeclared. Fix this by including linux/if_vlan.h, but is that correct? On Thu, 2 Jun 2016 19:08:26 +0300 "Michael S. Tsirkin"

Re: [PATCH RFC v7 3/5] skb_array: array based FIFO for skbs

Could not compile this new version of skb_array.h, it complains about implicit declaration of function 'skb_vlan_tag_present' and 'VLAN_HLEN' being undeclared. Fix this by including linux/if_vlan.h, but is that correct? On Thu, 2 Jun 2016 19:08:26 +0300 "Michael S. Tsirkin" wrote: > A simple

Re: [RFC PATCH 1/3] pci, acpi: Match PCI config space accessors against platfrom specific ECAM quirks.

On 6/3/2016 9:32 AM, Gabriele Paoloni wrote: Hi Cov -Original Message- From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci- ow...@vger.kernel.org] On Behalf Of Christopher Covington Sent: 03 June 2016 16:15 To: Tomasz Nowicki; helg...@kernel.org; a...@arndb.de; will.dea...@arm.com;

Re: [RFC PATCH 1/3] pci, acpi: Match PCI config space accessors against platfrom specific ECAM quirks.

On 6/3/2016 9:32 AM, Gabriele Paoloni wrote: Hi Cov -Original Message- From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci- ow...@vger.kernel.org] On Behalf Of Christopher Covington Sent: 03 June 2016 16:15 To: Tomasz Nowicki; helg...@kernel.org; a...@arndb.de; will.dea...@arm.com;

Re: [RFC PATCH 1/3] pci, acpi: Match PCI config space accessors against platfrom specific ECAM quirks.

On 06/03/2016 08:32 AM, Gabriele Paoloni wrote: [...] +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root) +{ + int bus_num = root->secondary.start; + int domain = root->segment; + struct pci_cfg_fixup *f; + + if (!mcfg_table) + return

Re: [RFC PATCH 1/3] pci, acpi: Match PCI config space accessors against platfrom specific ECAM quirks.

On 06/03/2016 08:32 AM, Gabriele Paoloni wrote: [...] +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root) +{ + int bus_num = root->secondary.start; + int domain = root->segment; + struct pci_cfg_fixup *f; + + if (!mcfg_table) + return

[PATCH] drm: sun4i: fix LPAE warnings

When the sun4i DRM driver is compiled with LPAE enabled, dma_addr_t turns into a 64-bit type, which causes warnings with some debug printks: = In file included from drivers/gpu/drm/sun4i/sun4i_backend.c:13:: drivers/gpu/drm/sun4i/sun4i_backend.c: In function

[PATCH] drm: sun4i: fix LPAE warnings

When the sun4i DRM driver is compiled with LPAE enabled, dma_addr_t turns into a 64-bit type, which causes warnings with some debug printks: = In file included from drivers/gpu/drm/sun4i/sun4i_backend.c:13:: drivers/gpu/drm/sun4i/sun4i_backend.c: In function

Re: [RFC PATCH v1 4/6] PM / devfreq: event: support rockchip dfi controller

On Fri, Jun 03, 2016 at 05:55:17PM +0800, Lin Huang wrote: [...] > + ret = clk_prepare_enable(data->clk); > + if (ret) { > + dev_err(>dev, "failed to enable clk: %d\n", ret); > + clk_disable_unprepare(data->clk); > + return ret; > + } This is going

Re: [RFC PATCH v1 4/6] PM / devfreq: event: support rockchip dfi controller

On Fri, Jun 03, 2016 at 05:55:17PM +0800, Lin Huang wrote: [...] > + ret = clk_prepare_enable(data->clk); > + if (ret) { > + dev_err(>dev, "failed to enable clk: %d\n", ret); > + clk_disable_unprepare(data->clk); > + return ret; > + } This is going

Re: [Nbd] Fwd: [PATCH v4 02/18] nbd: fix checkpatch trailing space warning.

On Wed 2016-05-11 07:46:25, Eric Blake wrote: > On 05/11/2016 03:38 AM, Pranay Srivastava wrote: > > > > > The series contained some checkpatch changes so I had included you as well. > > > >> know why you are sending them to me), but I know I do not accept patches > >> without any changelog

Re: [Nbd] Fwd: [PATCH v4 02/18] nbd: fix checkpatch trailing space warning.

On Wed 2016-05-11 07:46:25, Eric Blake wrote: > On 05/11/2016 03:38 AM, Pranay Srivastava wrote: > > > > > The series contained some checkpatch changes so I had included you as well. > > > >> know why you are sending them to me), but I know I do not accept patches > >> without any changelog

Re: [PATCH] net: ethernet: ti: cpsw: remove rx_descs property

On 06/03/2016 01:43 AM, Ivan Khoronzhuk wrote: There is no reason to hold s/w dependent parameter in device tree. Even more, there is no reason in this parameter because davinici_cpdma driver splits pool of descriptors equally between tx and rx channels. That is, if number of descriptors 256,

Re: [PATCH] net: ethernet: ti: cpsw: remove rx_descs property

On 06/03/2016 01:43 AM, Ivan Khoronzhuk wrote: There is no reason to hold s/w dependent parameter in device tree. Even more, there is no reason in this parameter because davinici_cpdma driver splits pool of descriptors equally between tx and rx channels. That is, if number of descriptors 256,

Re: BUG: scheduling while atomic: cron/668/0x10c9a0c0

On Fri, 3 Jun 2016 17:46:25 +0100 Mel Gorman wrote: > On Fri, Jun 03, 2016 at 09:35:18AM -0700, Andrew Morton wrote: > > On Fri, 3 Jun 2016 11:00:30 +0200 Geert Uytterhoeven > > wrote: > > > > > In the mean time my tests completed

Re: BUG: scheduling while atomic: cron/668/0x10c9a0c0

On Fri, 3 Jun 2016 17:46:25 +0100 Mel Gorman wrote: > On Fri, Jun 03, 2016 at 09:35:18AM -0700, Andrew Morton wrote: > > On Fri, 3 Jun 2016 11:00:30 +0200 Geert Uytterhoeven > > wrote: > > > > > In the mean time my tests completed successfully with both patches > > > applied. > > > > Can

Re: Re: linux-next memleak after IO on dax mountpoint

On 06/02/2016 08:22 AM, David Drysdale wrote: FWIW, I'm also seeing kmemleak report a leak with v4.7-rc1, in a different scenario (just normal desktop use). Not done much digging so far, but this commit (9082e87bf) looks like it might be relevant -- lots of the following: unreferenced object

Re: Re: linux-next memleak after IO on dax mountpoint

On 06/02/2016 08:22 AM, David Drysdale wrote: FWIW, I'm also seeing kmemleak report a leak with v4.7-rc1, in a different scenario (just normal desktop use). Not done much digging so far, but this commit (9082e87bf) looks like it might be relevant -- lots of the following: unreferenced object

Re: [PATCH 1/2] ARM: dts: am437x-idk-evm: Mark MAC as having only one PHY

On 05/27/2016 09:17 PM, Andrew F. Davis wrote: Currently am4372.dtsi declares the MAC controller to have two slave ports, on this board we only use one, so set the slave count to one. This eliminates a console error message when the non-existent PHY is not detected. Signed-off-by: Andrew F.

Re: [PATCH] net: ethernet: ti: cpsw: fix rx-usecs interrupt pacing consistency

On 06/02/2016 04:30 PM, Ivan Khoronzhuk wrote: On 02.06.16 16:14, Ivan Khoronzhuk wrote: The rx-usecs shouldn't be changed while interface down/up. Currently, for instance, if it's set to 100us, after interface down/up it's 500us. It's a hidden bug that can lead to lavish interrupt pacing time

Re: [PATCH 2/2] ARM: dts: am335x-bone-common: Mark MAC as having only one PHY

On 05/27/2016 09:17 PM, Andrew F. Davis wrote: Currently am33xx.dtsi declares the MAC controller to have two slave ports, on these boards we only use one, so set the slave count to one. This eliminates a console error message when the non-existent PHY is not detected. Signed-off-by: Andrew F.

Re: [PATCH 1/2] ARM: dts: am437x-idk-evm: Mark MAC as having only one PHY

On 05/27/2016 09:17 PM, Andrew F. Davis wrote: Currently am4372.dtsi declares the MAC controller to have two slave ports, on this board we only use one, so set the slave count to one. This eliminates a console error message when the non-existent PHY is not detected. Signed-off-by: Andrew F.

Re: [PATCH] net: ethernet: ti: cpsw: fix rx-usecs interrupt pacing consistency

On 06/02/2016 04:30 PM, Ivan Khoronzhuk wrote: On 02.06.16 16:14, Ivan Khoronzhuk wrote: The rx-usecs shouldn't be changed while interface down/up. Currently, for instance, if it's set to 100us, after interface down/up it's 500us. It's a hidden bug that can lead to lavish interrupt pacing time

Re: [PATCH 2/2] ARM: dts: am335x-bone-common: Mark MAC as having only one PHY

On 05/27/2016 09:17 PM, Andrew F. Davis wrote: Currently am33xx.dtsi declares the MAC controller to have two slave ports, on these boards we only use one, so set the slave count to one. This eliminates a console error message when the non-existent PHY is not detected. Signed-off-by: Andrew F.

Re: [PATCH] net: ethernet: ti: cpsw: remove unused priv lock

On 06/03/2016 01:37 AM, Ivan Khoronzhuk wrote: There is no reason in this lock. At least for now. Signed-off-by: Ivan Khoronzhuk --- Based on master drivers/net/ethernet/ti/cpsw.c | 3 --- 1 file changed, 3 deletions(-) diff --git

Re: [PATCH] net: ethernet: ti: cpsw: remove unused priv lock

On 06/03/2016 01:37 AM, Ivan Khoronzhuk wrote: There is no reason in this lock. At least for now. Signed-off-by: Ivan Khoronzhuk --- Based on master drivers/net/ethernet/ti/cpsw.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/ethernet/ti/cpsw.c

Re: BUG: scheduling while atomic: cron/668/0x10c9a0c0

On Fri, Jun 03, 2016 at 09:35:18AM -0700, Andrew Morton wrote: > On Fri, 3 Jun 2016 11:00:30 +0200 Geert Uytterhoeven > wrote: > > > In the mean time my tests completed successfully with both patches applied. > > Can we please identify "both patches" with specificity? I

Re: BUG: scheduling while atomic: cron/668/0x10c9a0c0

On Fri, Jun 03, 2016 at 09:35:18AM -0700, Andrew Morton wrote: > On Fri, 3 Jun 2016 11:00:30 +0200 Geert Uytterhoeven > wrote: > > > In the mean time my tests completed successfully with both patches applied. > > Can we please identify "both patches" with specificity? I have the > below one.

Re: [PATCH] tracing: expose current->comm to kprobe events

On Fri, Jun 03, 2016 at 05:59:43PM +0900, Masami Hiramatsu wrote: > On Fri, 3 Jun 2016 00:40:02 +0900 > Namhyung Kim wrote: > > > Hello, > > > > On Wed, Jun 1, 2016 at 3:17 PM, Omar Sandoval wrote: > > > From: Omar Sandoval > > > > > >

Re: [PATCH] tracing: expose current->comm to kprobe events

On Fri, Jun 03, 2016 at 05:59:43PM +0900, Masami Hiramatsu wrote: > On Fri, 3 Jun 2016 00:40:02 +0900 > Namhyung Kim wrote: > > > Hello, > > > > On Wed, Jun 1, 2016 at 3:17 PM, Omar Sandoval wrote: > > > From: Omar Sandoval > > > > > > ftrace is very quick to give up on saving the task

Dcache oops

I am dropping NFS people since it seems to be converting into a generic VFS/dcache bug even though you need NFS or the like to trigger it - the lookup_open path. On Jun 3, 2016, at 12:26 AM, Al Viro wrote: > Looks like the right thing to do would be to do d_drop() at no_open:, > just before we

Dcache oops

I am dropping NFS people since it seems to be converting into a generic VFS/dcache bug even though you need NFS or the like to trigger it - the lookup_open path. On Jun 3, 2016, at 12:26 AM, Al Viro wrote: > Looks like the right thing to do would be to do d_drop() at no_open:, > just before we

Re: BUG: scheduling while atomic: cron/668/0x10c9a0c0

On Fri, 3 Jun 2016 11:00:30 +0200 Geert Uytterhoeven wrote: > In the mean time my tests completed successfully with both patches applied. Can we please identify "both patches" with specificity? I have the below one. From: Mel Gorman

Re: BUG: scheduling while atomic: cron/668/0x10c9a0c0

On Fri, 3 Jun 2016 11:00:30 +0200 Geert Uytterhoeven wrote: > In the mean time my tests completed successfully with both patches applied. Can we please identify "both patches" with specificity? I have the below one. From: Mel Gorman Subject: mm, page_alloc: recalculate the preferred

Re: [PATCH v3 RESEND 0/7] Add MDIO bus multiplexer support for iProc SoCs

> Reason for resend: > -Rebased on v4.7-rc1 How do you see this getting merged? Via netdev? If so, you should be based on net-next/master, not v4.7-rc1. Andrew

Re: [PATCH v3 RESEND 0/7] Add MDIO bus multiplexer support for iProc SoCs

> Reason for resend: > -Rebased on v4.7-rc1 How do you see this getting merged? Via netdev? If so, you should be based on net-next/master, not v4.7-rc1. Andrew

Re: [PATCH v3 7/7] phy: Add Northstar2 PCI Phy support

On Fri, Jun 03, 2016 at 08:56:08PM +0530, Pramod Kumar wrote: > Add PCI Phy support for Broadcom Northstar2 SoCs. This driver uses the > interface from the iproc mdio mux driver to enable the devices > respective phys. > > Signed-off-by: Jon Mason > Signed-off-by: Pramod

Re: [PATCH v3 7/7] phy: Add Northstar2 PCI Phy support

On Fri, Jun 03, 2016 at 08:56:08PM +0530, Pramod Kumar wrote: > Add PCI Phy support for Broadcom Northstar2 SoCs. This driver uses the > interface from the iproc mdio mux driver to enable the devices > respective phys. > > Signed-off-by: Jon Mason > Signed-off-by: Pramod Kumar Reviewed-by:

Re: [PATCH v3 5/7] net:mdio-mux: Add MDIO mux driver for iProc SoCs

On Fri, Jun 03, 2016 at 08:56:06PM +0530, Pramod Kumar wrote: > iProc based SoCs supports the integrated mdio multiplexer which > has the bus selection as well as mdio transaction generation logic > inside. > > This mutiplexer has child buses for PCIe, SATA, USB and ETH. These multiplexer >

Re: [PATCH v3 5/7] net:mdio-mux: Add MDIO mux driver for iProc SoCs

On Fri, Jun 03, 2016 at 08:56:06PM +0530, Pramod Kumar wrote: > iProc based SoCs supports the integrated mdio multiplexer which > has the bus selection as well as mdio transaction generation logic > inside. > > This mutiplexer has child buses for PCIe, SATA, USB and ETH. These multiplexer >

Re: [PATCH] ASoC: sgtl5000: only check VDDD-supply, not revision

Hi Fabio, On 06/02/2016 05:48 PM, Fabio Estevam wrote: > Hi Clemens, > > On Thu, Jun 2, 2016 at 9:47 AM, Clemens Gruber > wrote: >> Instead of checking the SGTL5000 chip revision, we should only check if >> the VDDD regulator exists and only call

Re: [PATCH] ASoC: sgtl5000: only check VDDD-supply, not revision

Hi Fabio, On 06/02/2016 05:48 PM, Fabio Estevam wrote: > Hi Clemens, > > On Thu, Jun 2, 2016 at 9:47 AM, Clemens Gruber > wrote: >> Instead of checking the SGTL5000 chip revision, we should only check if >> the VDDD regulator exists and only call sgtl5000_replace_vddd_with_ldo >> if the

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

On Fri, Jun 3, 2016 at 5:39 AM, Gerd Hoffmann wrote: > Hi, > >> I tried >> >> subdir-y += ../../../arm64/boot/dts/broadcom > > Hmm, works for me too now, probably had a typo somewhere. What directory does the dtb end up in? Because as it was, it ended up in

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

On Fri, Jun 3, 2016 at 5:39 AM, Gerd Hoffmann wrote: > Hi, > >> I tried >> >> subdir-y += ../../../arm64/boot/dts/broadcom > > Hmm, works for me too now, probably had a typo somewhere. What directory does the dtb end up in? Because as it was, it ended up in arch/arm64/boot/dts/broadcom. I'm

Re: [PATCH] checkpatch: Flag code that returns a negative number

On Fri, 2016-06-03 at 11:07 -0500, Nishanth Menon wrote: > On 06/03/2016 11:01 AM, Joe Perches wrote: > > [...] > > > > I did more or less the same grep, and that's somewhat true. > > -1 though is very common and doesn't need to be replaced. > OK, > > > > > > > $ git grep -E

Re: [PATCH] checkpatch: Flag code that returns a negative number

On Fri, 2016-06-03 at 11:07 -0500, Nishanth Menon wrote: > On 06/03/2016 11:01 AM, Joe Perches wrote: > > [...] > > > > I did more or less the same grep, and that's somewhat true. > > -1 though is very common and doesn't need to be replaced. > OK, > > > > > > > $ git grep -E

Re: [PATCH v3 3/7] binding: mdio-mux: Add DT binding doc for Broadcom MDIO bus mutiplexer

> +Properties for an MDIO bus mutiplexer found in Broadcom iProc based SoCs. > + > +This MDIO bus multiplexer defines buses that could be internal as well as > +external to SoCs and could accept MDIO transaction compatible to C-22 or > +C-45 Clause. When child bus is selected, one needs to select

Re: [PATCH v3 3/7] binding: mdio-mux: Add DT binding doc for Broadcom MDIO bus mutiplexer

> +Properties for an MDIO bus mutiplexer found in Broadcom iProc based SoCs. > + > +This MDIO bus multiplexer defines buses that could be internal as well as > +external to SoCs and could accept MDIO transaction compatible to C-22 or > +C-45 Clause. When child bus is selected, one needs to select

Re: [PATCH 5/5] ARM: dts: Move Arria10 SDRAM as child of ECC Manager

On Wed, 25 May 2016, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > Changes to support ECC Manager as SDRAM IRQ parent by > 1) updating IRQ property values to correct child IRQs > 2) moving node under ECC Manager. > > Signed-off-by: Thor Thayer

Re: [PATCH 5/5] ARM: dts: Move Arria10 SDRAM as child of ECC Manager

On Wed, 25 May 2016, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > Changes to support ECC Manager as SDRAM IRQ parent by > 1) updating IRQ property values to correct child IRQs > 2) moving node under ECC Manager. > > Signed-off-by: Thor Thayer > --- >

Re: [RFC 10/12] x86, rwsem: simplify __down_write

On Wed, Feb 03, 2016 at 09:10:16AM +0100, Ingo Molnar wrote: > > * Michal Hocko wrote: > > > From: Michal Hocko > > > > x86 implementation of __down_write is using inline asm to optimize the > > code flow. This however requires that it has go over an

Re: [RFC 10/12] x86, rwsem: simplify __down_write

On Wed, Feb 03, 2016 at 09:10:16AM +0100, Ingo Molnar wrote: > > * Michal Hocko wrote: > > > From: Michal Hocko > > > > x86 implementation of __down_write is using inline asm to optimize the > > code flow. This however requires that it has go over an additional hop > > for the slow path

[PATCH v3] CHROMIUM: mmc: Set pref erase size based on size.

If available, eMMC stack uses HC_ERASE_GRP_SIZE as erase size. The perfererred erase size may need to be bigger to ensure discard operations are not too slow. Some high capacity eMMC (64MB) reports erase size to 512kB, resulting in long discard time. Calculate prefeerred erase size based on eMMC

[PATCH v3] CHROMIUM: mmc: Set pref erase size based on size.

If available, eMMC stack uses HC_ERASE_GRP_SIZE as erase size. The perfererred erase size may need to be bigger to ensure discard operations are not too slow. Some high capacity eMMC (64MB) reports erase size to 512kB, resulting in long discard time. Calculate prefeerred erase size based on eMMC

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

Hi Peter, On 06/03/2016 03:41 PM, Peter Chen wrote: > On Thu, Jun 02, 2016 at 09:37:24AM +0800, Lu Baolu wrote: >> > Several Intel platforms implement USB dual role by having completely >> > separate xHCI and dwc3 IPs in PCH or SOC silicons. These two IPs share >> > a single USB port. There is

Re: [PATCH] checkpatch: Flag code that returns a negative number

On 06/03/2016 11:01 AM, Joe Perches wrote: [...] > I did more or less the same grep, and that's somewhat true. > -1 though is very common and doesn't need to be replaced. OK, > > $ git grep -E "\breturn\s+\-\s*[0-9]+\s*;" * | grep -v "^tools" | grep -vP > "return\s*\-1;" | wc -l > 211 > >

Re: [PATCH] checkpatch: Flag code that returns a negative number

On 06/03/2016 11:01 AM, Joe Perches wrote: [...] > I did more or less the same grep, and that's somewhat true. > -1 though is very common and doesn't need to be replaced. OK, > > $ git grep -E "\breturn\s+\-\s*[0-9]+\s*;" * | grep -v "^tools" | grep -vP > "return\s*\-1;" | wc -l > 211 > >

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

Hi Peter, On 06/03/2016 03:41 PM, Peter Chen wrote: > On Thu, Jun 02, 2016 at 09:37:24AM +0800, Lu Baolu wrote: >> > Several Intel platforms implement USB dual role by having completely >> > separate xHCI and dwc3 IPs in PCH or SOC silicons. These two IPs share >> > a single USB port. There is

[PATCH v3 RESEND 3/7] binding: mdio-mux: Add DT binding doc for Broadcom MDIO bus mutiplexer

Add DT binding doc for Broadcom MDIO bus mutiplexer driver. Signed-off-by: Pramod Kumar --- .../bindings/net/brcm,mdio-mux-iproc.txt | 59 ++ 1 file changed, 59 insertions(+) create mode 100644

[PATCH v3 RESEND 3/7] binding: mdio-mux: Add DT binding doc for Broadcom MDIO bus mutiplexer

Add DT binding doc for Broadcom MDIO bus mutiplexer driver. Signed-off-by: Pramod Kumar --- .../bindings/net/brcm,mdio-mux-iproc.txt | 59 ++ 1 file changed, 59 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt diff

[PATCH v3 RESEND 6/7] Binding:PHY: Binding doc for NS2 PCIe PHYs.

Binding doc for NS2 PCIe PHYs. Acked-by: Rob Herring Signed-off-by: Jon Mason Signed-off-by: Pramod Kumar --- .../bindings/phy/brcm,mdio-mux-bus-pci.txt | 27 ++ 1 file changed, 27 insertions(+)

[PATCH v3 RESEND 6/7] Binding:PHY: Binding doc for NS2 PCIe PHYs.

Binding doc for NS2 PCIe PHYs. Acked-by: Rob Herring Signed-off-by: Jon Mason Signed-off-by: Pramod Kumar --- .../bindings/phy/brcm,mdio-mux-bus-pci.txt | 27 ++ 1 file changed, 27 insertions(+) create mode 100644

[PATCH v3 RESEND 5/7] net:mdio-mux: Add MDIO mux driver for iProc SoCs

iProc based SoCs supports the integrated mdio multiplexer which has the bus selection as well as mdio transaction generation logic inside. This mutiplexer has child buses for PCIe, SATA, USB and ETH. These buses could be internal or external to SOC where PHYs are attached. These buses could use

[PATCH v3 RESEND 7/7] phy: Add Northstar2 PCI Phy support

Add PCI Phy support for Broadcom Northstar2 SoCs. This driver uses the interface from the iproc mdio mux driver to enable the devices respective phys. Signed-off-by: Jon Mason Signed-off-by: Pramod Kumar --- drivers/phy/Kconfig|

Re: [PATCH v2 -next] virtio-net: Add initial MTU advice feature

On Thu, Jun 02, 2016 at 05:10:59PM -0400, Aaron Conole wrote: > This commit adds the feature bit and associated mtu device entry for the > virtio network device. When a virtio device comes up, it checks the > feature bit for the VIRTIO_NET_F_MTU feature. If such feature bit is > enabled, the

[PATCH v3 RESEND 7/7] phy: Add Northstar2 PCI Phy support

Add PCI Phy support for Broadcom Northstar2 SoCs. This driver uses the interface from the iproc mdio mux driver to enable the devices respective phys. Signed-off-by: Jon Mason Signed-off-by: Pramod Kumar --- drivers/phy/Kconfig| 8 +++ drivers/phy/Makefile | 2 +-

Re: [PATCH v2 -next] virtio-net: Add initial MTU advice feature

On Thu, Jun 02, 2016 at 05:10:59PM -0400, Aaron Conole wrote: > This commit adds the feature bit and associated mtu device entry for the > virtio network device. When a virtio device comes up, it checks the > feature bit for the VIRTIO_NET_F_MTU feature. If such feature bit is > enabled, the

[PATCH v3 RESEND 5/7] net:mdio-mux: Add MDIO mux driver for iProc SoCs

iProc based SoCs supports the integrated mdio multiplexer which has the bus selection as well as mdio transaction generation logic inside. This mutiplexer has child buses for PCIe, SATA, USB and ETH. These buses could be internal or external to SOC where PHYs are attached. These buses could use

Re: [PATCH v2 2/3] mm: Change the interface for __tlb_remove_page

Hi, [auto build test ERROR on arm/for-next] [also build test ERROR on v4.7-rc1 next-20160603] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Aneesh-Kumar-K-V/mm-hugetlb-Simplify-hugetlb-unmap

Re: [PATCH v2 2/3] mm: Change the interface for __tlb_remove_page

Hi, [auto build test ERROR on arm/for-next] [also build test ERROR on v4.7-rc1 next-20160603] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Aneesh-Kumar-K-V/mm-hugetlb-Simplify-hugetlb-unmap

[PATCH v3 RESEND 0/7] Add MDIO bus multiplexer support for iProc SoCs

Broadcom iProc based SoCs use a MDIO bus multiplexer where child buses could be internal as well external to SoCs. These buses could supports MDIO transaction compatible to C-22/C-45. Broadcom MDIO bus mulitplexer is an integrated multiplexer where child bus selection and mdio transaction logic

[PATCH v3 RESEND 2/7] binding: Make "mdio-parent-bus" property from mandatory to optional

Change "mdio-parent-bus" from mandatory section to optional as it won't be required by integrated MDIO multiplexer which has bus selection and mdio transaction generation logic, integrated inside. Signed-off-by: Pramod Kumar ---

[PATCH v3 RESEND 2/7] binding: Make "mdio-parent-bus" property from mandatory to optional

Change "mdio-parent-bus" from mandatory section to optional as it won't be required by integrated MDIO multiplexer which has bus selection and mdio transaction generation logic, integrated inside. Signed-off-by: Pramod Kumar --- Documentation/devicetree/bindings/net/mdio-mux.txt | 3 ++- 1 file

[PATCH v3 RESEND 0/7] Add MDIO bus multiplexer support for iProc SoCs

Broadcom iProc based SoCs use a MDIO bus multiplexer where child buses could be internal as well external to SoCs. These buses could supports MDIO transaction compatible to C-22/C-45. Broadcom MDIO bus mulitplexer is an integrated multiplexer where child bus selection and mdio transaction logic

[PATCH v3 RESEND 4/7] dt:mdio-mux: Add mdio multiplexer driver node

Add integrated MDIO multiplexer driver node which contains two mux PCIe bus and one ethernet bus along with phys lying on these bus. Signed-off-by: Pramod Kumar --- arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 arch/arm64/boot/dts/broadcom/ns2.dtsi|

[PATCH v3 RESEND 1/7] mdio:mux: Enhanced MDIO mux framework for integrated multiplexers

An integrated multiplexer uses same address space for "muxed bus selection" and "generation of mdio transaction" hence its good to register parent bus from mux driver. Hence added a mechanism where mux driver could register a parent bus and pass it down to framework via mdio_mux_init api.

[PATCH v3 RESEND 4/7] dt:mdio-mux: Add mdio multiplexer driver node

Add integrated MDIO multiplexer driver node which contains two mux PCIe bus and one ethernet bus along with phys lying on these bus. Signed-off-by: Pramod Kumar --- arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 arch/arm64/boot/dts/broadcom/ns2.dtsi| 31

[PATCH v3 RESEND 1/7] mdio:mux: Enhanced MDIO mux framework for integrated multiplexers

An integrated multiplexer uses same address space for "muxed bus selection" and "generation of mdio transaction" hence its good to register parent bus from mux driver. Hence added a mechanism where mux driver could register a parent bus and pass it down to framework via mdio_mux_init api.

Re: [PATCH] checkpatch: Flag code that returns a negative number

On Fri, 2016-06-03 at 10:49 -0500, Andrew F. Davis wrote: > On 06/03/2016 10:41 AM, Joe Perches wrote: > > On Fri, 2016-06-03 at 10:25 -0500, Nishanth Menon wrote: > > > In some functions, returning a -ve decimal value is actually a valid > > > return condition when the function is returning a

Re: [PATCH] checkpatch: Flag code that returns a negative number

On Fri, 2016-06-03 at 10:49 -0500, Andrew F. Davis wrote: > On 06/03/2016 10:41 AM, Joe Perches wrote: > > On Fri, 2016-06-03 at 10:25 -0500, Nishanth Menon wrote: > > > In some functions, returning a -ve decimal value is actually a valid > > > return condition when the function is returning a

[PATCH ipvs-next] ipvs: count pre-established TCP states as active

Some users observed that "least connection" distribution algorithm doesn't handle well bursts of TCP connections from reconnecting clients after a node or network failure. This is because the algorithm counts active connection as worth 256 inactive ones where for TCP, "active" only means TCP

[PATCH ipvs-next] ipvs: count pre-established TCP states as active

Some users observed that "least connection" distribution algorithm doesn't handle well bursts of TCP connections from reconnecting clients after a node or network failure. This is because the algorithm counts active connection as worth 256 inactive ones where for TCP, "active" only means TCP

[PATCH net-next v2 2/5] hv_netvsc: introduce {net,hv}_device_to_netvsc_device() helpers

Make it easier to get 'struct netvsc_device' from 'struct net_device' and 'struct hv_device' by introducing inline helpers. Signed-off-by: Vitaly Kuznetsov --- drivers/net/hyperv/hyperv_net.h | 12 drivers/net/hyperv/netvsc.c | 11 +++

[v1 PATCH 2/4] phy: Add USB Type-C PHY driver for rk3399

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2 data rates. Signed-off-by:

[PATCH net-next v2 2/5] hv_netvsc: introduce {net,hv}_device_to_netvsc_device() helpers

Make it easier to get 'struct netvsc_device' from 'struct net_device' and 'struct hv_device' by introducing inline helpers. Signed-off-by: Vitaly Kuznetsov --- drivers/net/hyperv/hyperv_net.h | 12 drivers/net/hyperv/netvsc.c | 11 +++

[v1 PATCH 2/4] phy: Add USB Type-C PHY driver for rk3399

Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2 data rates. Signed-off-by:

[v1 PATCH 4/4] drm/rockchip: cdn-dp: add cdn DP support for rk3399

Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file to

[v1 PATCH 4/4] drm/rockchip: cdn-dp: add cdn DP support for rk3399

Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file to

Re: [PATCH] ASoC: sgtl5000: only check VDDD-supply, not revision

On Thu, Jun 02, 2016 at 05:56:51PM +0100, Mark Brown wrote: > On Thu, Jun 02, 2016 at 12:48:15PM -0300, Fabio Estevam wrote: > > > Sometime ago you were looking at this. What do you think about this patch? > > I'm rather concerned that the patches came from people working closely > with

[v1 PATCH 0/4] Rockchip Type-C and DispplayPort driver

Hi all This series patch is for rockchip Type-C phy and DisplayPort controller driver. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and

[PATCH net-next v2 0/5] hv_netvsc: cleanup after untangling the pointer mess

Changes since v1: - resend when net-next is open [David Miller] - rebased to current net-next. After we made traveling through our internal structures explicit it became obvious that some functions take arguments they don't need just to do redundant pointer travel and get to what they really need

Re: [PATCH] ASoC: sgtl5000: only check VDDD-supply, not revision

On Thu, Jun 02, 2016 at 05:56:51PM +0100, Mark Brown wrote: > On Thu, Jun 02, 2016 at 12:48:15PM -0300, Fabio Estevam wrote: > > > Sometime ago you were looking at this. What do you think about this patch? > > I'm rather concerned that the patches came from people working closely > with

[v1 PATCH 0/4] Rockchip Type-C and DispplayPort driver

Hi all This series patch is for rockchip Type-C phy and DisplayPort controller driver. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and

[PATCH net-next v2 0/5] hv_netvsc: cleanup after untangling the pointer mess

Changes since v1: - resend when net-next is open [David Miller] - rebased to current net-next. After we made traveling through our internal structures explicit it became obvious that some functions take arguments they don't need just to do redundant pointer travel and get to what they really need

[PATCH net-next v2 3/5] hv_netvsc: pass struct netvsc_device to rndis_filter_{open,close}()

Both rndis_filter_open()/rndis_filter_close() use struct hv_device to reach to struct netvsc_device only and all callers have it already. While on it, rename net_device to nvdev in rndis_filter_open() as net_device is misleading. Signed-off-by: Vitaly Kuznetsov ---

[PATCH net-next v2 3/5] hv_netvsc: pass struct netvsc_device to rndis_filter_{open,close}()

Both rndis_filter_open()/rndis_filter_close() use struct hv_device to reach to struct netvsc_device only and all callers have it already. While on it, rename net_device to nvdev in rndis_filter_open() as net_device is misleading. Signed-off-by: Vitaly Kuznetsov ---

[PATCH net-next v2 4/5] hv_netvsc: pass struct net_device to rndis_filter_set_device_mac()

We unpack 'struct net_device' in netvsc_set_mac_addr() to get to 'struct hv_device' pointer which we use in rndis_filter_set_device_mac() to get back to 'struct net_device'. Signed-off-by: Vitaly Kuznetsov --- drivers/net/hyperv/hyperv_net.h | 2 +-

[PATCH net-next v2 4/5] hv_netvsc: pass struct net_device to rndis_filter_set_device_mac()

We unpack 'struct net_device' in netvsc_set_mac_addr() to get to 'struct hv_device' pointer which we use in rndis_filter_set_device_mac() to get back to 'struct net_device'. Signed-off-by: Vitaly Kuznetsov --- drivers/net/hyperv/hyperv_net.h | 2 +- drivers/net/hyperv/netvsc_drv.c | 4 +---

<    2   3   4   5   6   7   8   9   10   11   >