Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation

Hi Sascha, > The current assumption as discussed by Philipp and me is that the ipg > clk is only needed when the pwm output is driven by the ipg clk > (MX3_PWMCR[16:17] = MX3_PWMCR_CLKSRC_IPG) At least on my setup (i.MX6q) the ipg clock (ipg_clk) don't need to be explicitly enabled in the

Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation

Hi Sascha, > The current assumption as discussed by Philipp and me is that the ipg > clk is only needed when the pwm output is driven by the ipg clk > (MX3_PWMCR[16:17] = MX3_PWMCR_CLKSRC_IPG) At least on my setup (i.MX6q) the ipg clock (ipg_clk) don't need to be explicitly enabled in the

[PATCH v2] usb: dwc3: gadget: wait for End Transfer to complete

Instead of just delaying for 100us, we should actually wait for End Transfer Command Complete interrupt before moving on. Note that this should only be done if we're dealing with one of the core revisions that actually require the interrupt before moving on. [ felipe.ba...@linux.intel.com: minor

[PATCH v2] usb: dwc3: gadget: wait for End Transfer to complete

Instead of just delaying for 100us, we should actually wait for End Transfer Command Complete interrupt before moving on. Note that this should only be done if we're dealing with one of the core revisions that actually require the interrupt before moving on. [ felipe.ba...@linux.intel.com: minor

RE: Device or HBA level QD throttling creates randomness in sequetial workload

Jens- Replied inline. Omar - I tested your WIP repo and figure out System hangs only if I pass " scsi_mod.use_blk_mq=Y". Without this, your WIP branch works fine, but I am looking for scsi_mod.use_blk_mq=Y. Also below is snippet of blktrace. In case of higher per device QD, I see Requeue

RE: Device or HBA level QD throttling creates randomness in sequetial workload

Jens- Replied inline. Omar - I tested your WIP repo and figure out System hangs only if I pass " scsi_mod.use_blk_mq=Y". Without this, your WIP branch works fine, but I am looking for scsi_mod.use_blk_mq=Y. Also below is snippet of blktrace. In case of higher per device QD, I see Requeue

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 11/01/16 at 01:10pm, Dave Young wrote: > On 10/06/16 at 04:46pm, Baoquan He wrote: > > KASLR memory randomization can randomize the base of the physical memory > > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap > > (VMEMMAP_START). These need be exported to VMCOREINFO so that user

S5PV210 boot problem

Dear friends, I have problem booting my custom HW (around s5pv210 SoC) using the latest stable kernel release (v4.8.5). Of course this is the first DT based kernel I'm trying to boot with in this HW. I chose s5pv210_defconfig and by checking CONFIG_ARM_APPENDED_DTB, appended the DTB

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 11/01/16 at 01:10pm, Dave Young wrote: > On 10/06/16 at 04:46pm, Baoquan He wrote: > > KASLR memory randomization can randomize the base of the physical memory > > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap > > (VMEMMAP_START). These need be exported to VMCOREINFO so that user

S5PV210 boot problem

Dear friends, I have problem booting my custom HW (around s5pv210 SoC) using the latest stable kernel release (v4.8.5). Of course this is the first DT based kernel I'm trying to boot with in this HW. I chose s5pv210_defconfig and by checking CONFIG_ARM_APPENDED_DTB, appended the DTB

Re: [PATCH v10 01/19] vfio: Mediated device Core driver

On 11/01/2016 11:44 AM, Alex Williamson wrote: > On Tue, 01 Nov 2016 11:08:15 +0800 > Jike Song wrote: >> On 10/27/2016 05:29 AM, Kirti Wankhede wrote: >>> +static int mdev_attach_iommu(struct mdev_device *mdev) >>> +{ >>> + int ret; >>> + struct iommu_group *group; >>> +

Re: [PATCH v10 01/19] vfio: Mediated device Core driver

On 11/01/2016 11:44 AM, Alex Williamson wrote: > On Tue, 01 Nov 2016 11:08:15 +0800 > Jike Song wrote: >> On 10/27/2016 05:29 AM, Kirti Wankhede wrote: >>> +static int mdev_attach_iommu(struct mdev_device *mdev) >>> +{ >>> + int ret; >>> + struct iommu_group *group; >>> + >>> + group =

Re: pull-request: wireless-drivers-next 2016-10-30

David Miller writes: > From: Kalle Valo > Date: Sun, 30 Oct 2016 11:20:46 +0200 > >> few fixes for 4.9. I tagged this on the plane over a slow mosh >> connection while travelling to Plumbers so I might have done something >> wrong, please check more

Re: pull-request: wireless-drivers-next 2016-10-30

David Miller writes: > From: Kalle Valo > Date: Sun, 30 Oct 2016 11:20:46 +0200 > >> few fixes for 4.9. I tagged this on the plane over a slow mosh >> connection while travelling to Plumbers so I might have done something >> wrong, please check more carefully than usually. For example I had to

Re: [PATCH v2 2/2] PM / sleep: don't suspend parent when async child suspend_{noirq,late} fails

Hi Rafael, On Tue, Nov 01, 2016 at 05:25:39AM +0100, Rafael J. Wysocki wrote: > On Thursday, October 27, 2016 09:05:34 AM Brian Norris wrote: > > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c > > index c58563581345..eaf6b53463a5 100644 > > --- a/drivers/base/power/main.c > >

Re: [PATCH v2 2/2] PM / sleep: don't suspend parent when async child suspend_{noirq,late} fails

Hi Rafael, On Tue, Nov 01, 2016 at 05:25:39AM +0100, Rafael J. Wysocki wrote: > On Thursday, October 27, 2016 09:05:34 AM Brian Norris wrote: > > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c > > index c58563581345..eaf6b53463a5 100644 > > --- a/drivers/base/power/main.c > >

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/06/16 at 04:46pm, Baoquan He wrote: > KASLR memory randomization can randomize the base of the physical memory > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space > utility, mainly makedumpfile can use them

Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

On 10/06/16 at 04:46pm, Baoquan He wrote: > KASLR memory randomization can randomize the base of the physical memory > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space > utility, mainly makedumpfile can use them

[PATCH 1/1] vmbus: make sysfs names consistent with PCI

From: Stephen Hemminger In commit 9a56e5d6a0ba ("Drivers: hv: make VMBus bus ids persistent") the name of vmbus devices in sysfs changed to be (in 4.9-rc1): /sys/bus/vmbus/vmbus-6aebe374-9ba0-11e6-933c-00259086b36b The prefix ("vmbus-") is redundant and differs from

[PATCH 1/1] vmbus: make sysfs names consistent with PCI

From: Stephen Hemminger In commit 9a56e5d6a0ba ("Drivers: hv: make VMBus bus ids persistent") the name of vmbus devices in sysfs changed to be (in 4.9-rc1): /sys/bus/vmbus/vmbus-6aebe374-9ba0-11e6-933c-00259086b36b The prefix ("vmbus-") is redundant and differs from how PCI is represented in

[PATCH v4 3/4] usb: serial: usb_debug: add support for dbc debug device

This patch add dbc debug device support in usb_debug driver. Signed-off-by: Lu Baolu Acked-by: Johan Hovold --- drivers/usb/serial/usb_debug.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git

[PATCH v4 3/4] usb: serial: usb_debug: add support for dbc debug device

This patch add dbc debug device support in usb_debug driver. Signed-off-by: Lu Baolu Acked-by: Johan Hovold --- drivers/usb/serial/usb_debug.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/drivers/usb/serial/usb_debug.c

[PATCH v4 1/4] usb: dbc: early driver for xhci debug capability

xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. xHCI specification describes DbC in section 7.6. This patch introduces the code to probe and

[PATCH v4 4/4] usb: doc: add document for USB3 debug port usage

Add Documentation/usb/usb3-debug-port.rst. This document includes the user guide for USB3 debug port. Cc: linux-...@vger.kernel.org Signed-off-by: Lu Baolu --- Documentation/usb/usb3-debug-port.rst | 95 +++ 1 file changed, 95

[PATCH v4 4/4] usb: doc: add document for USB3 debug port usage

Add Documentation/usb/usb3-debug-port.rst. This document includes the user guide for USB3 debug port. Cc: linux-...@vger.kernel.org Signed-off-by: Lu Baolu --- Documentation/usb/usb3-debug-port.rst | 95 +++ 1 file changed, 95 insertions(+) create mode 100644

[PATCH v4 1/4] usb: dbc: early driver for xhci debug capability

xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. Software learns this capability by walking through the extended capability list of the host. xHCI specification describes DbC in section 7.6. This patch introduces the code to probe and

[PATCH v4 0/4] usb: early: add support for early printk through USB3 debug port

xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. With DbC hardware initialized, the system will present a debug device through the USB3 debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework

[PATCH v4 0/4] usb: early: add support for early printk through USB3 debug port

xHCI debug capability (DbC) is an optional but standalone functionality provided by an xHCI host controller. With DbC hardware initialized, the system will present a debug device through the USB3 debug port (normally the first USB3 port). The debug device is fully compliant with the USB framework

[PATCH v4 2/4] x86: add support for earlyprintk via USB3 debug port

Add support for early printk by writing debug messages to the USB3 debug port. Users can use this type of early printk by specifying kernel parameter of "earlyprintk=xdbc". This gives users a chance of providing debug output. The hardware for USB3 debug port requires DMA memory blocks. This

[PATCH v4 2/4] x86: add support for earlyprintk via USB3 debug port

Add support for early printk by writing debug messages to the USB3 debug port. Users can use this type of early printk by specifying kernel parameter of "earlyprintk=xdbc". This gives users a chance of providing debug output. The hardware for USB3 debug port requires DMA memory blocks. This

Re: make pdfdocs fails with v4.9-rc3

Em Mon, 31 Oct 2016 16:41:48 -0600 Mauro Carvalho Chehab escreveu: > Em Mon, 31 Oct 2016 16:40:02 -0600 > Mauro Carvalho Chehab escreveu: > > > Em Mon, 31 Oct 2016 15:04:42 -0700 > > Jim Davis escreveu: > > > > > On Mon, Oct

Re: make pdfdocs fails with v4.9-rc3

Em Mon, 31 Oct 2016 16:41:48 -0600 Mauro Carvalho Chehab escreveu: > Em Mon, 31 Oct 2016 16:40:02 -0600 > Mauro Carvalho Chehab escreveu: > > > Em Mon, 31 Oct 2016 15:04:42 -0700 > > Jim Davis escreveu: > > > > > On Mon, Oct 31, 2016 at 1:58 PM, Mauro Carvalho Chehab > > > wrote: > > > > Em

[PATCH v6 3/3] fpga: Add support for Lattice iCE40 FPGAs

The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. This patch adds support to the FPGA manager for configuring the SRAM of iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite

[PATCH v6 3/3] fpga: Add support for Lattice iCE40 FPGAs

The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. This patch adds support to the FPGA manager for configuring the SRAM of iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite

[PATCH v6 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager

--- .../bindings/fpga/lattice-ice40-fpga-mgr.txt| 21 + 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt

[PATCH v6 1/3] of: Add vendor prefix for Lattice Semiconductor

Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1992aa9..d64a835 100644 ---

[PATCH v6 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager

--- .../bindings/fpga/lattice-ice40-fpga-mgr.txt| 21 + 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt

[PATCH v6 1/3] of: Add vendor prefix for Lattice Semiconductor

Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1992aa9..d64a835 100644 ---

[PATCH v5 3/3] fpga: Add support for Lattice iCE40 FPGAs

The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. This patch adds support to the FPGA manager for configuring the SRAM of iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite

[PATCH v5 3/3] fpga: Add support for Lattice iCE40 FPGAs

The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. This patch adds support to the FPGA manager for configuring the SRAM of iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite

[PATCH v5 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager

--- .../bindings/fpga/lattice-ice40-fpga-mgr.txt| 21 + 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt

Re: [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

Hi David and Jan, I did more testing on the code. Casting to either (long) or (unsigned long) would be fine. However, there is still an issue that ref is of type uint32_t and IS_ERR_VALUE((unsigned long)ref) would not return true when ref=-ENOSPC (or other error code). IS_ERR_VALUE((long)ref)

[PATCH v5 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager

--- .../bindings/fpga/lattice-ice40-fpga-mgr.txt| 21 + 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt

Re: [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short

Hi David and Jan, I did more testing on the code. Casting to either (long) or (unsigned long) would be fine. However, there is still an issue that ref is of type uint32_t and IS_ERR_VALUE((unsigned long)ref) would not return true when ref=-ENOSPC (or other error code). IS_ERR_VALUE((long)ref)

[PATCH v5 1/3] of: Add vendor prefix for Lattice Semiconductor

From: Joel Holdsworth Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt

[PATCH v5 1/3] of: Add vendor prefix for Lattice Semiconductor

From: Joel Holdsworth Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1992aa9..d64a835 100644

Re: [PATCH] PM / Domains: check for negative return from of_count_phandle_with_args

On Wednesday, October 26, 2016 01:00:08 PM Pavel Machek wrote: > > --zhXaljGHf11kAtnf > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue 2016-10-25 11:14:40, Kevin Hilman wrote: > > Colin King

Re: [PATCH] PM / Domains: check for negative return from of_count_phandle_with_args

On Wednesday, October 26, 2016 01:00:08 PM Pavel Machek wrote: > > --zhXaljGHf11kAtnf > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue 2016-10-25 11:14:40, Kevin Hilman wrote: > > Colin King writes: > >=20 > > >

Re: [PATCH v2] console: use first console if stdout-path device doesn't appear

Sergey Senozhatsky writes: > On (10/31/16 15:50), Paul Burton wrote: > [..] >> Actually whilst this fixes the output in QEMU it has other problems. I'm >> still >> digging... > > I propose a revert of '05fd007e46296', so you guys can find the > problem and fix it,

Re: [PATCH v2] console: use first console if stdout-path device doesn't appear

Sergey Senozhatsky writes: > On (10/31/16 15:50), Paul Burton wrote: > [..] >> Actually whilst this fixes the output in QEMU it has other problems. I'm >> still >> digging... > > I propose a revert of '05fd007e46296', so you guys can find the > problem and fix it, not being under 'rc3'

[PATCH] acer-wmi: setup accelerometer when machine has appropriate notify event

The accelerometer event relies on on the ACERWMID_EVENT_GUID notify. So, this patch changes the codes to setup accelerometer input device when detected ACERWMID_EVENT_GUID. It avoids that the accel input device created on every acer machines. In addition, patch adds a clearly parsing logic of

[PATCH] acer-wmi: setup accelerometer when machine has appropriate notify event

The accelerometer event relies on on the ACERWMID_EVENT_GUID notify. So, this patch changes the codes to setup accelerometer input device when detected ACERWMID_EVENT_GUID. It avoids that the accel input device created on every acer machines. In addition, patch adds a clearly parsing logic of

[PATCH] acer-wmi: only supports AMW0_GUID1 on acer family

The AMW0_GUID1 wmi is not only found on Acer family but also other machines like Lenovo, Fujitsu and Medion. In the past days, acer-wmi driver handled those non-Acer machines by quirks list. But actually acer-wmi driver was loaded on any machines that have AMW0_GUID1. This behavior is strange

[PATCH] acer-wmi: only supports AMW0_GUID1 on acer family

The AMW0_GUID1 wmi is not only found on Acer family but also other machines like Lenovo, Fujitsu and Medion. In the past days, acer-wmi driver handled those non-Acer machines by quirks list. But actually acer-wmi driver was loaded on any machines that have AMW0_GUID1. This behavior is strange

Re: [PATCH 00/12] xen: add common function for reading optional value

On 31/10/16 18:08, David Miller wrote: > From: Juergen Gross > Date: Mon, 31 Oct 2016 17:48:18 +0100 > >> There are multiple instances of code reading an optional unsigned >> parameter from Xenstore via xenbus_scanf(). Instead of repeating the >> same code over and over add a

Re: [PATCH 00/12] xen: add common function for reading optional value

On 31/10/16 18:08, David Miller wrote: > From: Juergen Gross > Date: Mon, 31 Oct 2016 17:48:18 +0100 > >> There are multiple instances of code reading an optional unsigned >> parameter from Xenstore via xenbus_scanf(). Instead of repeating the >> same code over and over add a service function

Re: [RESEND PATCH 1/2] PM / sleep: print function name of callbacks

On Wednesday, October 19, 2016 05:26:09 PM Brian Norris wrote: > From: Douglas Anderson > > The printouts writen to the logs by suspend can be a bit opaque: it can > be hard to track them down to the actual function called. You might > see: > > calling rfkill1+ @

Re: [RESEND PATCH 1/2] PM / sleep: print function name of callbacks

On Wednesday, October 19, 2016 05:26:09 PM Brian Norris wrote: > From: Douglas Anderson > > The printouts writen to the logs by suspend can be a bit opaque: it can > be hard to track them down to the actual function called. You might > see: > > calling rfkill1+ @ 19473, parent: phy0 >

Re: [PATCH v2 2/2] PM / sleep: don't suspend parent when async child suspend_{noirq,late} fails

On Thursday, October 27, 2016 09:05:34 AM Brian Norris wrote: > Consider two devices, A and B, where B is a child of A, and B utilizes > asynchronous suspend (it does not matter whether A is sync or async). If > B fails to suspend_noirq() or suspend_late(), or is interrupted by a > wakeup

Re: [PATCH v2 2/2] PM / sleep: don't suspend parent when async child suspend_{noirq,late} fails

On Thursday, October 27, 2016 09:05:34 AM Brian Norris wrote: > Consider two devices, A and B, where B is a child of A, and B utilizes > asynchronous suspend (it does not matter whether A is sync or async). If > B fails to suspend_noirq() or suspend_late(), or is interrupted by a > wakeup

Re: [PATCH v2 0/3] powernv:stop: Use psscr_val,mask provided by firmware

On Thursday, October 27, 2016 02:05:04 PM Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > Hi, > > This is the second iteration of the patchset to use the psscr_val and > psscr_mask provided by the firmware for each of the stop states. > > The previous version

Re: [PATCH v2 0/3] powernv:stop: Use psscr_val,mask provided by firmware

On Thursday, October 27, 2016 02:05:04 PM Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > Hi, > > This is the second iteration of the patchset to use the psscr_val and > psscr_mask provided by the firmware for each of the stop states. > > The previous version can be found here: >

Re: [PATCH 1/6] staging: iio: set proper supply name to devm_regulator_get()

On Mon, Oct 31, 2016 at 10:04 AM, Eva Rachel Retuya wrote: > The name passed to devm_regulator_get() should match the name of the > supply as specified in the device datasheet. This makes it clear what > power supply is being referred to in case of presence of other >

Re: [PATCH 1/6] staging: iio: set proper supply name to devm_regulator_get()

On Mon, Oct 31, 2016 at 10:04 AM, Eva Rachel Retuya wrote: > The name passed to devm_regulator_get() should match the name of the > supply as specified in the device datasheet. This makes it clear what > power supply is being referred to in case of presence of other > regulators. > > Currently,

Re: [PATCH v10 01/19] vfio: Mediated device Core driver

On Tue, 01 Nov 2016 11:08:15 +0800 Jike Song wrote: > On 10/27/2016 05:29 AM, Kirti Wankhede wrote: > > +static int mdev_attach_iommu(struct mdev_device *mdev) > > +{ > > + int ret; > > + struct iommu_group *group; > > + > > + group = iommu_group_alloc(); > > + if

Re: [PATCH v10 01/19] vfio: Mediated device Core driver

On Tue, 01 Nov 2016 11:08:15 +0800 Jike Song wrote: > On 10/27/2016 05:29 AM, Kirti Wankhede wrote: > > +static int mdev_attach_iommu(struct mdev_device *mdev) > > +{ > > + int ret; > > + struct iommu_group *group; > > + > > + group = iommu_group_alloc(); > > + if (IS_ERR(group)) > > +

Re: [PATCH v6 0/5] Functional dependencies between devices

On Monday, October 31, 2016 11:47:03 AM Greg Kroah-Hartman wrote: > On Sun, Oct 30, 2016 at 05:22:13PM +0100, Rafael J. Wysocki wrote: > > Hi, > > > > Let me quote from the previous intro messages for this series first: > > > > > > Time for another update. :-) > > > > > > > > Fewer changes this

Re: [PATCH v6 0/5] Functional dependencies between devices

On Monday, October 31, 2016 11:47:03 AM Greg Kroah-Hartman wrote: > On Sun, Oct 30, 2016 at 05:22:13PM +0100, Rafael J. Wysocki wrote: > > Hi, > > > > Let me quote from the previous intro messages for this series first: > > > > > > Time for another update. :-) > > > > > > > > Fewer changes this

Re: [RFC PATCH 0/6] UART slave devices using serio

On Mon, Oct 31, 2016 at 3:00 PM, Peter Hurley wrote: > On Tue, Oct 25, 2016 at 4:02 PM, Rob Herring wrote: >> >> > Maybe you can try to find some minutes at the Kernel Summit to talk >> > about this? >> >> Still waiting for my invite... >> >> But I will

Re: [RFC PATCH 0/6] UART slave devices using serio

On Mon, Oct 31, 2016 at 3:00 PM, Peter Hurley wrote: > On Tue, Oct 25, 2016 at 4:02 PM, Rob Herring wrote: >> >> > Maybe you can try to find some minutes at the Kernel Summit to talk >> > about this? >> >> Still waiting for my invite... >> >> But I will be at Plumbers if folks want to discuss

cygnus-pcm.c:undefined reference to `bad_dma_ops'

Hi Mark, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0c183d92b20b5c84ca655b45ef57b3318b83eb9e commit: 3ceeda1cbee9f93bb5537c9b840d1f7e767d7c01 Merge remote-tracking branches 'asoc/topic/cs53l30',

cygnus-pcm.c:undefined reference to `bad_dma_ops'

Hi Mark, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 0c183d92b20b5c84ca655b45ef57b3318b83eb9e commit: 3ceeda1cbee9f93bb5537c9b840d1f7e767d7c01 Merge remote-tracking branches 'asoc/topic/cs53l30',

[PATCH net-next 04/11] net: dsa: mv88e6xxx: add port FID accessors

Add functions to port files to access the ports default FID. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 77 +++- drivers/net/dsa/mv88e6xxx/port.c | 67 ++

[PATCH] clk: rockchip: optimize the configuration for 800MHz and 1GHz on RK3399

Usually, the 800MHz and 1GHz are supplied for CPLL and NPLL in the RK3399. But dues to the carelessly copying from RK3036 when the RK3399 bringing up, the refdiv == 6, it will increase the lock time, and it is not an optimal configuration. Please let's fix them for the lock time and jitter are

[PATCH net-next 02/11] net: dsa: mv88e6xxx: add port state setter

Add the port STP state setter to the port files. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 49 drivers/net/dsa/mv88e6xxx/port.c | 31 +

[PATCH net-next 11/11] net: dsa: mv88e6xxx: setup port's MAC

Now that we have setters to configure the port's MAC, use them to refactor the port setup and adjust_link code. Note that port's MAC speed, duplex or RGMII delay must not be changed unless the port's link is forced down. So wrap all that in a mv88e6xxx_port_ctrl_mac function. Signed-off-by:

[PATCH net-next 11/11] net: dsa: mv88e6xxx: setup port's MAC

Now that we have setters to configure the port's MAC, use them to refactor the port setup and adjust_link code. Note that port's MAC speed, duplex or RGMII delay must not be changed unless the port's link is forced down. So wrap all that in a mv88e6xxx_port_ctrl_mac function. Signed-off-by:

[PATCH net-next 04/11] net: dsa: mv88e6xxx: add port FID accessors

Add functions to port files to access the ports default FID. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 77 +++- drivers/net/dsa/mv88e6xxx/port.c | 67 ++ drivers/net/dsa/mv88e6xxx/port.h | 3 ++ 3

[PATCH] clk: rockchip: optimize the configuration for 800MHz and 1GHz on RK3399

Usually, the 800MHz and 1GHz are supplied for CPLL and NPLL in the RK3399. But dues to the carelessly copying from RK3036 when the RK3399 bringing up, the refdiv == 6, it will increase the lock time, and it is not an optimal configuration. Please let's fix them for the lock time and jitter are

[PATCH net-next 02/11] net: dsa: mv88e6xxx: add port state setter

Add the port STP state setter to the port files. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 49 drivers/net/dsa/mv88e6xxx/port.c | 31 + drivers/net/dsa/mv88e6xxx/port.h | 2 ++ 3 files changed, 37

[PATCH net-next 01/11] net: dsa: mv88e6xxx: add port files

The Marvell switches contains one internal SMI device per port, called "Port Registers". Depending on the model, the addresses of these devices start from 0x0, 0x8 or 0x10. Start moving Port Registers specific code to their own files. Signed-off-by: Vivien Didelot

[PATCH net-next 03/11] net: dsa: mv88e6xxx: add port vlan map setter

Add a port function to access the Port Based VLAN Map register. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 14 ++ drivers/net/dsa/mv88e6xxx/port.c | 25 + drivers/net/dsa/mv88e6xxx/port.h | 2 ++

[PATCH net-next 03/11] net: dsa: mv88e6xxx: add port vlan map setter

Add a port function to access the Port Based VLAN Map register. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 14 ++ drivers/net/dsa/mv88e6xxx/port.c | 25 + drivers/net/dsa/mv88e6xxx/port.h | 2 ++ 3 files changed, 29 insertions(+),

[PATCH net-next 01/11] net: dsa: mv88e6xxx: add port files

The Marvell switches contains one internal SMI device per port, called "Port Registers". Depending on the model, the addresses of these devices start from 0x0, 0x8 or 0x10. Start moving Port Registers specific code to their own files. Signed-off-by: Vivien Didelot ---

[PATCH net-next 07/11] net: dsa: mv88e6xxx: add port link setter

Most of the chips will have a port register control bits to force the port's link up, down, or let normal link detection occurs. Implement such operation to use it later when setting duplex, etc. Signed-off-by: Vivien Didelot ---

[PATCH net-next 05/11] net: dsa: mv88e6xxx: add port PVID accessors

Add port functions to access the ports default VID. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 51 drivers/net/dsa/mv88e6xxx/port.c | 38 ++

[PATCH net-next 07/11] net: dsa: mv88e6xxx: add port link setter

Most of the chips will have a port register control bits to force the port's link up, down, or let normal link detection occurs. Implement such operation to use it later when setting duplex, etc. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 17 +

[PATCH net-next 05/11] net: dsa: mv88e6xxx: add port PVID accessors

Add port functions to access the ports default VID. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 51 drivers/net/dsa/mv88e6xxx/port.c | 38 ++ drivers/net/dsa/mv88e6xxx/port.h | 3 +++ 3 files changed,

[PATCH net-next 08/11] net: dsa: mv88e6xxx: add port duplex setter

Similarly to port's link, add setter to force port's half duplex, full duplex or let normal duplex detection occurs. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 17 + drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 7

[PATCH net-next 09/11] net: dsa: mv88e6xxx: add port's RGMII delay setter

Some chips such as 88E6352 and 88E6390 can be programmed to add delays to RXCLK for IND inputs or to GTXCLK for OUTD outputs when port is in RGMII mode. Add a port function to program such delays according to the provided PHY interface mode. Signed-off-by: Vivien Didelot

[PATCH net-next 08/11] net: dsa: mv88e6xxx: add port duplex setter

Similarly to port's link, add setter to force port's half duplex, full duplex or let normal duplex detection occurs. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 17 + drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 7 +++

[PATCH net-next 09/11] net: dsa: mv88e6xxx: add port's RGMII delay setter

Some chips such as 88E6352 and 88E6390 can be programmed to add delays to RXCLK for IND inputs or to GTXCLK for OUTD outputs when port is in RGMII mode. Add a port function to program such delays according to the provided PHY interface mode. Signed-off-by: Vivien Didelot ---

[PATCH net-next 06/11] net: dsa: mv88e6xxx: add port 802.1Q mode setter

Add port functions to set the port 802.1Q mode. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 33 ++--- drivers/net/dsa/mv88e6xxx/port.c | 32

[PATCH net-next 10/11] net: dsa: mv88e6xxx: add port's MAC speed setter

While the two bits for link, duplex or RGMII delays are used the same way on chips supporting the said feature, the two bits for speed have different meaning for most of the chips out there. Speed value is stored in bits 1:0, 0x3 means unforce (normal detection). Some chips reuse values for

[PATCH net-next 06/11] net: dsa: mv88e6xxx: add port 802.1Q mode setter

Add port functions to set the port 802.1Q mode. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx/chip.c | 33 ++--- drivers/net/dsa/mv88e6xxx/port.c | 32 drivers/net/dsa/mv88e6xxx/port.h | 3 +++ 3 files changed, 37

[PATCH net-next 10/11] net: dsa: mv88e6xxx: add port's MAC speed setter

While the two bits for link, duplex or RGMII delays are used the same way on chips supporting the said feature, the two bits for speed have different meaning for most of the chips out there. Speed value is stored in bits 1:0, 0x3 means unforce (normal detection). Some chips reuse values for

[PATCH net-next 00/11] net: dsa: mv88e6xxx: refine port operations

The Marvell chips have one internal SMI device per port, containing a set of registers used to configure a port's link, STP state, default VLAN or addresses database, etc. This patchset creates port files to implement the port operations as described in datasheets, and extend the chip ops

[PATCH net-next 00/11] net: dsa: mv88e6xxx: refine port operations

The Marvell chips have one internal SMI device per port, containing a set of registers used to configure a port's link, STP state, default VLAN or addresses database, etc. This patchset creates port files to implement the port operations as described in datasheets, and extend the chip ops

Re: [PATCH v1] usb: dwc3: gadget: wait for End Transfer to complete

Hi, On 31 October 2016 at 20:53, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> Instead of just delaying for 100us, we should >> actually wait for End Transfer Command Complete >> interrupt before moving on. Note that this should >> only be done

Re: [PATCH v1] usb: dwc3: gadget: wait for End Transfer to complete

Hi, On 31 October 2016 at 20:53, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> Instead of just delaying for 100us, we should >> actually wait for End Transfer Command Complete >> interrupt before moving on. Note that this should >> only be done if we're dealing with one of the core >>

  1   2   3   4   5   6   7   8   9   10   >