Re: [PATCH v2] OMAPDSS: HDMI5: Change DDC timings

On 21/04/16 20:27, J.D. Schroeder wrote: > From: Jim Lodes > > The DDC scl high and low times were set to the minimum values > from the i2c specification, but the i2c specification takes into > account the rise time and fall time to calculate the frequency. > To pass HDMI

Re: [PATCH v2] OMAPDSS: HDMI5: Change DDC timings

On 21/04/16 20:27, J.D. Schroeder wrote: > From: Jim Lodes > > The DDC scl high and low times were set to the minimum values > from the i2c specification, but the i2c specification takes into > account the rise time and fall time to calculate the frequency. > To pass HDMI certification DDC can

Re: [PATCH v2] OMAPDSS: HDMI5: Fix AVI infoframe

On 21/04/16 20:49, J.D. Schroeder wrote: > From: Jim Lodes > > The AVI infoframe R0-R3 in the 2nd data byte represents the > Active Format Aspect Ratio. It is four bits long not two bits. > This fixes that mask used to extract the bits before writing the > bits to the

Re: [PATCH v2] OMAPDSS: HDMI5: Fix AVI infoframe

On 21/04/16 20:49, J.D. Schroeder wrote: > From: Jim Lodes > > The AVI infoframe R0-R3 in the 2nd data byte represents the > Active Format Aspect Ratio. It is four bits long not two bits. > This fixes that mask used to extract the bits before writing the > bits to the hardware registers. > >

Re: [RESEND PATCH v2 1/7] usb: xhci: plat: Fix suspend/resume when the optional clk exists

Dear Felipe, On Wed, 27 Apr 2016 08:25:38 +0300 Felipe Balbi wrote: > Hi, > > (since you're fixing somebody else's commit, it's nice to Cc authors) > > Jisheng Zhang writes: > > Commit 4718c1774051 ("usb: host: xhci-plat: add clock support") adds > > optional clk support,

Re: [RESEND PATCH v2 1/7] usb: xhci: plat: Fix suspend/resume when the optional clk exists

Dear Felipe, On Wed, 27 Apr 2016 08:25:38 +0300 Felipe Balbi wrote: > Hi, > > (since you're fixing somebody else's commit, it's nice to Cc authors) > > Jisheng Zhang writes: > > Commit 4718c1774051 ("usb: host: xhci-plat: add clock support") adds > > optional clk support, but it forgets to

Re: [PATCH 1/1] [RFC] workqueue: fix ghost PENDING flag while doing MQ IO

On 04/26/2016 07:45 PM, Tejun Heo wrote: > Hello, Peter. > > On Tue, Apr 26, 2016 at 10:27:59AM -0700, Peter Hurley wrote: >>> It's unlikely to make any measureable difference. Is xchg() actually >>> cheaper than store + rmb? >> >> store + mfence (full barrier), yes. Roughly 2x faster. >> >>

Re: [PATCH 1/1] [RFC] workqueue: fix ghost PENDING flag while doing MQ IO

On 04/26/2016 07:45 PM, Tejun Heo wrote: > Hello, Peter. > > On Tue, Apr 26, 2016 at 10:27:59AM -0700, Peter Hurley wrote: >>> It's unlikely to make any measureable difference. Is xchg() actually >>> cheaper than store + rmb? >> >> store + mfence (full barrier), yes. Roughly 2x faster. >> >>

[PATCH v2] net: Add Qualcomm IPC router

From: Courtney Cavin Add an implementation of Qualcomm's IPC router protocol, used to communicate with service providing remote processors. Signed-off-by: Courtney Cavin Signed-off-by: Bjorn Andersson

[PATCH v2] net: Add Qualcomm IPC router

From: Courtney Cavin Add an implementation of Qualcomm's IPC router protocol, used to communicate with service providing remote processors. Signed-off-by: Courtney Cavin Signed-off-by: Bjorn Andersson [bjorn: Cope with 0 being a valid node id and implement RTM_NEWADDR] Signed-off-by: Bjorn

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

Hi, Grygorii Strashko writes: > On 04/26/2016 09:17 AM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> Now not all DMA paremters configured properly for "xhci-hcd" platform >>> device which is created manually. For

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

Hi, Grygorii Strashko writes: > On 04/26/2016 09:17 AM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> Now not all DMA paremters configured properly for "xhci-hcd" platform >>> device which is created manually. For example: dma_pfn_offset, dam_ops >>> and iommu

Re: [PATCH 02/19] radix-tree: Miscellaneous fixes

On Fri, Apr 15 2016, Matthew Wilcox wrote: > Typos, whitespace, grammar, line length, using the correct types, etc. > > Signed-off-by: Matthew Wilcox > Reviewed-by: Ross Zwisler > > -static inline void root_tag_clear(struct radix_tree_root

Re: [PATCH 02/19] radix-tree: Miscellaneous fixes

On Fri, Apr 15 2016, Matthew Wilcox wrote: > Typos, whitespace, grammar, line length, using the correct types, etc. > > Signed-off-by: Matthew Wilcox > Reviewed-by: Ross Zwisler > > -static inline void root_tag_clear(struct radix_tree_root *root, unsigned int > tag) > +static inline void

Re: [PATCH 05/12] nvmem: vif610-ocotp: remove nvmem regmap dependency

Hello Srinivas, On 16-04-24 20:28:09, Srinivas Kandagatla wrote: > This patch moves to nvmem support in the driver to use callback > instead of regmap. Minor nit, it says "vif610-octop" it should have been vf610-ocotp. For what it's worth, I tested this on Colibri Vybrid VF61 for a while and

Re: Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c

On Tue, 26 Apr 2016, Kees Cook wrote: > On Mon, Apr 25, 2016 at 7:50 AM, Pengfei Wang wrote: > > Hello, > > > > I found this Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c > > when I was examining the source code. > > Thanks for these reports! I wrote a

Re: [PATCH 05/12] nvmem: vif610-ocotp: remove nvmem regmap dependency

Hello Srinivas, On 16-04-24 20:28:09, Srinivas Kandagatla wrote: > This patch moves to nvmem support in the driver to use callback > instead of regmap. Minor nit, it says "vif610-octop" it should have been vf610-ocotp. For what it's worth, I tested this on Colibri Vybrid VF61 for a while and

Re: Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c

On Tue, 26 Apr 2016, Kees Cook wrote: > On Mon, Apr 25, 2016 at 7:50 AM, Pengfei Wang wrote: > > Hello, > > > > I found this Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c > > when I was examining the source code. > > Thanks for these reports! I wrote a coccinelle script to

Re: [RESEND PATCH v2 7/7] usb: xhci: plat: add vbus regulator control

Hi, Jisheng Zhang writes: > The Marvell BG4CT STB board has board level vbus control through gpio. > This patch adds the vbus regulator control to support this board. > > Signed-off-by: Jisheng Zhang > --- > drivers/usb/host/xhci-plat.c | 40

Re: + mm-zswap-use-workqueue-to-destroy-pool.patch added to -mm tree

Hello, On (04/26/16 16:52), a...@linux-foundation.org wrote: [..] > -static void __zswap_pool_release(struct rcu_head *head) > +static void __zswap_pool_release(struct work_struct *work) > { > - struct zswap_pool *pool = container_of(head, typeof(*pool), rcu_head); > + struct zswap_pool

Re: + mm-zswap-use-workqueue-to-destroy-pool.patch added to -mm tree

Hello, On (04/26/16 16:52), a...@linux-foundation.org wrote: [..] > -static void __zswap_pool_release(struct rcu_head *head) > +static void __zswap_pool_release(struct work_struct *work) > { > - struct zswap_pool *pool = container_of(head, typeof(*pool), rcu_head); > + struct zswap_pool

Re: [RESEND PATCH v2 7/7] usb: xhci: plat: add vbus regulator control

Hi, Jisheng Zhang writes: > The Marvell BG4CT STB board has board level vbus control through gpio. > This patch adds the vbus regulator control to support this board. > > Signed-off-by: Jisheng Zhang > --- > drivers/usb/host/xhci-plat.c | 40 +++- >

Re: [RESEND PATCH v2 6/7] usb: xhci: plat: add generic PHY support

Hi, Jisheng Zhang writes: > Marvell BG4CT SoC needs two phy: one for usb2 and another for usb3. Add > the calls to retrieve generic PHY to xhci plat in order to support this. > > Signed-off-by: Jisheng Zhang > --- > drivers/usb/host/xhci-plat.c | 87

Re: [RESEND PATCH v2 6/7] usb: xhci: plat: add generic PHY support

Hi, Jisheng Zhang writes: > Marvell BG4CT SoC needs two phy: one for usb2 and another for usb3. Add > the calls to retrieve generic PHY to xhci plat in order to support this. > > Signed-off-by: Jisheng Zhang > --- > drivers/usb/host/xhci-plat.c | 87 >

Re: [PATCH V6 05/13] acpi, pci: Support IO resources when parsing PCI host bridge resources.

On 04/26/2016 10:39 PM, Bjorn Helgaas wrote: > On Fri, Apr 15, 2016 at 07:06:40PM +0200, Tomasz Nowicki wrote: >> Platforms that have memory mapped IO port (such as ARM64) need special >> handling for PCI I/O resources. For host bridge's resource probing case >> these resources need to be fixed up

Re: [PATCH V6 05/13] acpi, pci: Support IO resources when parsing PCI host bridge resources.

On 04/26/2016 10:39 PM, Bjorn Helgaas wrote: > On Fri, Apr 15, 2016 at 07:06:40PM +0200, Tomasz Nowicki wrote: >> Platforms that have memory mapped IO port (such as ARM64) need special >> handling for PCI I/O resources. For host bridge's resource probing case >> these resources need to be fixed up

Re: [RESEND PATCH v2 5/7] usb: xhci: plat: Remove checks for optional clock in error/remove path

Jisheng Zhang writes: > Commit 63589e92c2d9 ("clk: Ignore error and NULL pointers passed to > clk_{unprepare, disable}()") allows NULL or error pointer to be passed > unconditionally. > > This patch is to simplify probe error and remove code paths. this seems wrong to me.

Re: [RESEND PATCH v2 5/7] usb: xhci: plat: Remove checks for optional clock in error/remove path

Jisheng Zhang writes: > Commit 63589e92c2d9 ("clk: Ignore error and NULL pointers passed to > clk_{unprepare, disable}()") allows NULL or error pointer to be passed > unconditionally. > > This patch is to simplify probe error and remove code paths. this seems wrong to me. xhci->clk isn't

Re: [RFC] a corner case of open(2)

Fun bugs caught while trying to massage atomic_open()... Patch below is in vfs.git#for-linus (along with two more fixes); I would like to get an ACK from Miklos on that one - it's his code and this thing had been present in there since the original merge. I might be misreading what it tries to

Re: [RFC] a corner case of open(2)

Fun bugs caught while trying to massage atomic_open()... Patch below is in vfs.git#for-linus (along with two more fixes); I would like to get an ACK from Miklos on that one - it's his code and this thing had been present in there since the original merge. I might be misreading what it tries to

Re: [RESEND PATCH v2 3/7] usb: xhci: plat: Fix suspend/resume when the optional usb_phy exists

Hi, Jisheng Zhang writes: > Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the > usb_phy for usb3, but it forgets to shutdown/init the usb_phy in the > suspend/resume path. This patch fixes this issue by adding missing > usb_phy related calls. Fixes:

Re: [RESEND PATCH v2 3/7] usb: xhci: plat: Fix suspend/resume when the optional usb_phy exists

Hi, Jisheng Zhang writes: > Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the > usb_phy for usb3, but it forgets to shutdown/init the usb_phy in the > suspend/resume path. This patch fixes this issue by adding missing > usb_phy related calls. Fixes: 7b8ef22ea547 ("usb:

Re: [RESEND PATCH v2 2/7] usb: xhci: plat: attach the usb_phy to the correct hcd

Hi, (Cc authors and maintainer, otherwise you're patch might be forgotten ;-) Jisheng Zhang writes: > Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the > usb_phy for usb3, but it attached the usb_phy to incorrect hcd. The where did you see that's the

Re: [RESEND PATCH v2 2/7] usb: xhci: plat: attach the usb_phy to the correct hcd

Hi, (Cc authors and maintainer, otherwise you're patch might be forgotten ;-) Jisheng Zhang writes: > Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the > usb_phy for usb3, but it attached the usb_phy to incorrect hcd. The where did you see that's the USB3 phy ? I can't see

Re: [RESEND PATCH v2 1/7] usb: xhci: plat: Fix suspend/resume when the optional clk exists

Hi, (since you're fixing somebody else's commit, it's nice to Cc authors) Jisheng Zhang writes: > Commit 4718c1774051 ("usb: host: xhci-plat: add clock support") adds > optional clk support, but it forgets to prepare/disable and

Re: [RESEND PATCH v2 1/7] usb: xhci: plat: Fix suspend/resume when the optional clk exists

Hi, (since you're fixing somebody else's commit, it's nice to Cc authors) Jisheng Zhang writes: > Commit 4718c1774051 ("usb: host: xhci-plat: add clock support") adds > optional clk support, but it forgets to prepare/disable and ^^^

Re: [PATCH V2 1/2] devicetree/bindings: Add binding for operator panel on FSP machines

Suraj Jitindar Singh writes: > Add a binding to Documentation/devicetree/bindings/powerpc/opal > (oppanel-opal.txt) for the operator panel which is present on IBM > pseries machines with FSPs. It's not pseries (as that implies PowerVM / PAPR) - while here we're all

Re: [PATCH V2 1/2] devicetree/bindings: Add binding for operator panel on FSP machines

Suraj Jitindar Singh writes: > Add a binding to Documentation/devicetree/bindings/powerpc/opal > (oppanel-opal.txt) for the operator panel which is present on IBM > pseries machines with FSPs. It's not pseries (as that implies PowerVM / PAPR) - while here we're all about OPAL. With a slight

Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests

On 21/04/16 11:30, Stefano Stabellini wrote: > On Thu, 21 Apr 2016, Juergen Gross wrote: >> On 20/04/16 15:15, Stefano Stabellini wrote: >>> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number >>> of legacy interrupts when actually nr_legacy_irqs() returns 0 after >>>

Re: [GIT PULL] platform-drivers-x86 for 4.6-3

On Tue, Apr 26, 2016 at 09:58:01PM -0700, Darren Hart wrote: > Hi Linus, > > The following changes since commit 5d07163334ba016c053b033cd0bb3c92d7dc0229: > > platform:x86 decouple telemetry driver from the optional IPC resources > (2016-04-19 13:51:41 -0700) > > are available in the git

Re: [PATCH] xen/x86: actually allocate legacy interrupts on PV guests

On 21/04/16 11:30, Stefano Stabellini wrote: > On Thu, 21 Apr 2016, Juergen Gross wrote: >> On 20/04/16 15:15, Stefano Stabellini wrote: >>> b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number >>> of legacy interrupts when actually nr_legacy_irqs() returns 0 after >>>

Re: [GIT PULL] platform-drivers-x86 for 4.6-3

On Tue, Apr 26, 2016 at 09:58:01PM -0700, Darren Hart wrote: > Hi Linus, > > The following changes since commit 5d07163334ba016c053b033cd0bb3c92d7dc0229: > > platform:x86 decouple telemetry driver from the optional IPC resources > (2016-04-19 13:51:41 -0700) > > are available in the git

[GIT PULL] platform-drivers-x86 for 4.6-3

Hi Linus, The following changes since commit 5d07163334ba016c053b033cd0bb3c92d7dc0229: platform:x86 decouple telemetry driver from the optional IPC resources (2016-04-19 13:51:41 -0700) are available in the git repository at:

[GIT PULL] platform-drivers-x86 for 4.6-3

Hi Linus, The following changes since commit 5d07163334ba016c053b033cd0bb3c92d7dc0229: platform:x86 decouple telemetry driver from the optional IPC resources (2016-04-19 13:51:41 -0700) are available in the git repository at:

linux-next: manual merge of the staging tree with the staging.current tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/iio/magnetometer/ak8975.c between commit: 05be8d4101d9 ("iio: ak8975: fix maybe-uninitialized warning") from the staging.current tree and commit: 97eacb9166f4 ("iio:ak8975: add mounting matrix support")

linux-next: manual merge of the staging tree with the staging.current tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/iio/magnetometer/ak8975.c between commit: 05be8d4101d9 ("iio: ak8975: fix maybe-uninitialized warning") from the staging.current tree and commit: 97eacb9166f4 ("iio:ak8975: add mounting matrix support")

Re: [PATCH 1/6] bus: Add shared MDIO bus framework

On Wed, Apr 27, 2016 at 1:11 AM, Andrew Lunn wrote: > On Tue, Apr 26, 2016 at 09:24:34PM +0200, Arnd Bergmann wrote: >> On Tuesday 26 April 2016 20:23:35 Andrew Lunn wrote: >> > > A more complex problem would be having a PHY driver for a device >> > > that can be either an

Re: [PATCH 1/6] bus: Add shared MDIO bus framework

On Wed, Apr 27, 2016 at 1:11 AM, Andrew Lunn wrote: > On Tue, Apr 26, 2016 at 09:24:34PM +0200, Arnd Bergmann wrote: >> On Tuesday 26 April 2016 20:23:35 Andrew Lunn wrote: >> > > A more complex problem would be having a PHY driver for a device >> > > that can be either an ethernet phy or some

Re: [PATCH 1/1] simplified security.nscapability xattr

Quoting Kees Cook (keesc...@chromium.org): > On Tue, Apr 26, 2016 at 3:26 PM, Serge E. Hallyn wrote: > > Quoting Kees Cook (keesc...@chromium.org): > >> On Fri, Apr 22, 2016 at 10:26 AM, wrote: > >> > From: Serge Hallyn > >> >

Re: [PATCH 1/1] simplified security.nscapability xattr

Quoting Kees Cook (keesc...@chromium.org): > On Tue, Apr 26, 2016 at 3:26 PM, Serge E. Hallyn wrote: > > Quoting Kees Cook (keesc...@chromium.org): > >> On Fri, Apr 22, 2016 at 10:26 AM, wrote: > >> > From: Serge Hallyn > >> > > >> > This can only be set by root in his own namespace, and will

[PATCH] IPMI: reserve memio regions separately

From: Corey Minyard Commit d61a3ead2680 ("[PATCH] IPMI: reserve I/O ports separately") changed the way I/O ports were reserved and includes this comment in log: Some BIOSes reserve disjoint I/O regions in their ACPI tables for the IPMI controller. This causes problems

[PATCH] IPMI: reserve memio regions separately

From: Corey Minyard Commit d61a3ead2680 ("[PATCH] IPMI: reserve I/O ports separately") changed the way I/O ports were reserved and includes this comment in log: Some BIOSes reserve disjoint I/O regions in their ACPI tables for the IPMI controller. This causes problems when trying to register

Re: random(4) changes

On Tue, Apr 26, 2016 at 01:47:09PM -0700, Andi Kleen wrote: > > I posted patches to fix this. At some point it definitely has to be. Can you point me to the patch submission? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

Re: random(4) changes

On Tue, Apr 26, 2016 at 01:47:09PM -0700, Andi Kleen wrote: > > I posted patches to fix this. At some point it definitely has to be. Can you point me to the patch submission? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

[PATCH] mmc: sdhci-of-arasan: refactor set_clock callback

commit 61b914eb81f8 ("mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan") introduce phy support for arasan. According to the vendor's databook, we should make sure the phy is in poweroff status before we configure the clk stuff. Otherwise it may cause some IO sample timing issues from the

[PATCH] mmc: sdhci-of-arasan: refactor set_clock callback

commit 61b914eb81f8 ("mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan") introduce phy support for arasan. According to the vendor's databook, we should make sure the phy is in poweroff status before we configure the clk stuff. Otherwise it may cause some IO sample timing issues from the

RE: [PATCH] scripts/spelling.txt: add "fimware" misspelling

Hi, Kees Cook * From: Kees Cook [mailto:keesc...@chromium.org] > Sent: Wednesday, April 27, 2016 7:48 AM > To: Andrew Morton > Cc: Randy Dunlap ; Andy Whitcroft > ; Joe Perches ; Zhao Lei >

RE: [PATCH] scripts/spelling.txt: add "fimware" misspelling

Hi, Kees Cook * From: Kees Cook [mailto:keesc...@chromium.org] > Sent: Wednesday, April 27, 2016 7:48 AM > To: Andrew Morton > Cc: Randy Dunlap ; Andy Whitcroft > ; Joe Perches ; Zhao Lei > ; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: [PATCH] scripts/spelling.txt: add

Re: [PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

On Wed, Apr 27, 2016 at 12:02 PM, NeilBrown wrote: > On Wed, Apr 27 2016, Ming Lei wrote: > >> There were reports about heavy stack use by recursive calling >> .bi_end_io()([1][2][3]). For example, more than 16K stack is >> consumed in a single bio complete path[3], and in [2]

Re: [PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

On Wed, Apr 27, 2016 at 12:02 PM, NeilBrown wrote: > On Wed, Apr 27 2016, Ming Lei wrote: > >> There were reports about heavy stack use by recursive calling >> .bi_end_io()([1][2][3]). For example, more than 16K stack is >> consumed in a single bio complete path[3], and in [2] stack >> overflow

Re: [PATCH v5 12/14] arm64, acpi, numa: NUMA support based on SRAT and SLIT

Hi Dennis, David, Sorry for the late reply, please see my comments below. On 2016/4/27 9:14, David Daney wrote: On 04/21/2016 03:06 AM, Dennis Chen wrote: On 20 April 2016 at 09:40, David Daney wrote: [...] +/* Callback for Proximity Domain -> ACPI processor UID

Re: [PATCH v5 12/14] arm64, acpi, numa: NUMA support based on SRAT and SLIT

Hi Dennis, David, Sorry for the late reply, please see my comments below. On 2016/4/27 9:14, David Daney wrote: On 04/21/2016 03:06 AM, Dennis Chen wrote: On 20 April 2016 at 09:40, David Daney wrote: [...] +/* Callback for Proximity Domain -> ACPI processor UID mapping */ +void __init

Re: [PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

On Wed, Apr 27 2016, Ming Lei wrote: > There were reports about heavy stack use by recursive calling > .bi_end_io()([1][2][3]). For example, more than 16K stack is > consumed in a single bio complete path[3], and in [2] stack > overflow can be triggered if 20 nested dm-crypt is used. > > Also

Re: [PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

On Wed, Apr 27 2016, Ming Lei wrote: > There were reports about heavy stack use by recursive calling > .bi_end_io()([1][2][3]). For example, more than 16K stack is > consumed in a single bio complete path[3], and in [2] stack > overflow can be triggered if 20 nested dm-crypt is used. > > Also

[PATCH v2 1/3] fs: direct-io: handle error in dio_end_io()

If error is passed to dio_end_io(), it should have been dealt with. Unfortunately current code just ignores that silently. Only btrfs uses dio_end_io(). Signed-off-by: Ming Lei --- fs/direct-io.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/direct-io.c

[PATCH v2 1/3] fs: direct-io: handle error in dio_end_io()

If error is passed to dio_end_io(), it should have been dealt with. Unfortunately current code just ignores that silently. Only btrfs uses dio_end_io(). Signed-off-by: Ming Lei --- fs/direct-io.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/direct-io.c b/fs/direct-io.c index

[PATCH v2 2/3] fs: direct-io: call .bi_end_io via bio_endio()

bio_endio() is the graceful way to complete one bio. Signed-off-by: Ming Lei --- fs/direct-io.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/fs/direct-io.c b/fs/direct-io.c index a8dd60a..0a35e51 100644 --- a/fs/direct-io.c +++

[PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

There were reports about heavy stack use by recursive calling .bi_end_io()([1][2][3]). For example, more than 16K stack is consumed in a single bio complete path[3], and in [2] stack overflow can be triggered if 20 nested dm-crypt is used. Also patches[1] [2] [3] were posted for addressing the

[PATCH v2 2/3] fs: direct-io: call .bi_end_io via bio_endio()

bio_endio() is the graceful way to complete one bio. Signed-off-by: Ming Lei --- fs/direct-io.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/fs/direct-io.c b/fs/direct-io.c index a8dd60a..0a35e51 100644 --- a/fs/direct-io.c +++ b/fs/direct-io.c @@ -350,15 +350,10 @@

[PATCH v2 3/3] block: avoid to call .bi_end_io() recursively

There were reports about heavy stack use by recursive calling .bi_end_io()([1][2][3]). For example, more than 16K stack is consumed in a single bio complete path[3], and in [2] stack overflow can be triggered if 20 nested dm-crypt is used. Also patches[1] [2] [3] were posted for addressing the

[PATCH v2 0/3] block: avoid to call .bi_end_io() recursively

Hi, The 1st patch handles bio error in dio_end_io() which is only used by btrfs. The 2nd patch uses bio_endio() to call .bi_end_io() in dio_end_io(). The 3rd patch avoids to call .bi_end_io recursively in complete path. xfstests(-g auto) is run over ext4, xfs and btrfs with this patchset and

[PATCH v2 0/3] block: avoid to call .bi_end_io() recursively

Hi, The 1st patch handles bio error in dio_end_io() which is only used by btrfs. The 2nd patch uses bio_endio() to call .bi_end_io() in dio_end_io(). The 3rd patch avoids to call .bi_end_io recursively in complete path. xfstests(-g auto) is run over ext4, xfs and btrfs with this patchset and

linux-next: manual merge of the dt-rh tree with the tegra tree

Hi Rob, Today's linux-next merge of the dt-rh tree got a conflict in: Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt between commit: 53cafb93da6f ("dt-bindings: Add documentation for GM20B GPU") from the tegra tree and commit: f43521e95211 ("dt-bindings: tegra: Remove 0, prefix

linux-next: manual merge of the dt-rh tree with the tegra tree

Hi Rob, Today's linux-next merge of the dt-rh tree got a conflict in: Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt between commit: 53cafb93da6f ("dt-bindings: Add documentation for GM20B GPU") from the tegra tree and commit: f43521e95211 ("dt-bindings: tegra: Remove 0, prefix

Re: [PATCH] iio: tmp006: Set correct iio name

Thanks for your mails. Is it possible to just merge this patch, then test if there is any application is using it? Considering almost all other I2C devices are using the correct ID name, it should be low risky Yong 2016-04-26 23:21 GMT+08:00 Daniel Baluta : > On Tue,

Re: [PATCH] iio: tmp006: Set correct iio name

Thanks for your mails. Is it possible to just merge this patch, then test if there is any application is using it? Considering almost all other I2C devices are using the correct ID name, it should be low risky Yong 2016-04-26 23:21 GMT+08:00 Daniel Baluta : > On Tue, Apr 26, 2016 at 4:14 PM,

Re: [PATCH 3.2 000/115] 3.2.80-rc1 review

On 04/26/2016 04:02 PM, Ben Hutchings wrote: This is the start of the stable review cycle for the 3.2.80 release. There are 115 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made

Re: [PATCH 3.2 000/115] 3.2.80-rc1 review

On 04/26/2016 04:02 PM, Ben Hutchings wrote: This is the start of the stable review cycle for the 3.2.80 release. There are 115 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made

Re: [PATCH v5 09/21] IB/hns: Add hca support

On 2016/4/26 22:18, Leon Romanovsky wrote: > On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote: >> On 2016/4/24 15:54, Leon Romanovsky wrote: >>> On Sat, Apr 23, 2016 at 06:26:47PM +0800, Lijun Ou wrote: This patch mainly setup hca for RoCE. it will do a series of initial works as

Re: [PATCH v5 09/21] IB/hns: Add hca support

On 2016/4/26 22:18, Leon Romanovsky wrote: > On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote: >> On 2016/4/24 15:54, Leon Romanovsky wrote: >>> On Sat, Apr 23, 2016 at 06:26:47PM +0800, Lijun Ou wrote: This patch mainly setup hca for RoCE. it will do a series of initial works as

Re: [PATCH v5 09/21] IB/hns: Add hca support

On 2016/4/26 22:25, Jiri Pirko wrote: > Tue, Apr 26, 2016 at 04:18:21PM CEST, l...@kernel.org wrote: >> On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote: >>> On 2016/4/24 15:54, Leon Romanovsky wrote: > > > > +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj) >

Re: [PATCH v5 09/21] IB/hns: Add hca support

On 2016/4/26 22:25, Jiri Pirko wrote: > Tue, Apr 26, 2016 at 04:18:21PM CEST, l...@kernel.org wrote: >> On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote: >>> On 2016/4/24 15:54, Leon Romanovsky wrote: > > > > +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj) >

Re: [PATCH] parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls

On Tue, Apr 26, 2016 at 10:45:11PM -0400, Mike Frysinger wrote: > On 27 Apr 2016 04:56, Dmitry V. Levin wrote: > > Do not load one entry beyond the end of the syscall table when the > > syscall number of a traced process equals to __NR_Linux_syscalls. > > Similar bug with regular processes was

Re: [PATCH] parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls

On Tue, Apr 26, 2016 at 10:45:11PM -0400, Mike Frysinger wrote: > On 27 Apr 2016 04:56, Dmitry V. Levin wrote: > > Do not load one entry beyond the end of the syscall table when the > > syscall number of a traced process equals to __NR_Linux_syscalls. > > Similar bug with regular processes was

[PATCH v2 2/9] arm64: tegra: use tegra132-soctherm for Tegra132

The Tegra132 has the specific settings for soctherm, so change to use campatible "nvidia,tegra132-soctherm" for it. And adds cpu, gpu, mem and pllx thermal zones. Signed-off-by: Wei Ni --- arch/arm64/boot/dts/nvidia/tegra132.dtsi | 36 ++-- 1 file

[PATCH v2 6/9] thermal: tegra: add hw-throttle for Tegra132

Tegra132 use CCROC throttle registers to configure pulse skiper, set these registers to enable throttle function for Tegra132. Signed-off-by: Wei Ni --- drivers/thermal/tegra/soctherm.c| 215 +--- drivers/thermal/tegra/tegra132-soctherm.c

[PATCH v2 2/9] arm64: tegra: use tegra132-soctherm for Tegra132

The Tegra132 has the specific settings for soctherm, so change to use campatible "nvidia,tegra132-soctherm" for it. And adds cpu, gpu, mem and pllx thermal zones. Signed-off-by: Wei Ni --- arch/arm64/boot/dts/nvidia/tegra132.dtsi | 36 ++-- 1 file changed, 34

[PATCH v2 6/9] thermal: tegra: add hw-throttle for Tegra132

Tegra132 use CCROC throttle registers to configure pulse skiper, set these registers to enable throttle function for Tegra132. Signed-off-by: Wei Ni --- drivers/thermal/tegra/soctherm.c| 215 +--- drivers/thermal/tegra/tegra132-soctherm.c | 17 ++

Re: [PATCH] dmaengine: pl330: Fix race in pl330_get_desc()

On Tue, Apr 26, 2016 at 10:00 PM, Robin Murphy wrote: > The current logic in pl330_get_desc() contains a clear race condition, > whereby if the descriptor pool is empty, we will create a new > descriptor, add it to the pool with the lock held, *release the lock*, > then try

[PATCH v2 0/9] Add HW throttle for Tegra soctherm

This series add following functions for Tegra soctherm: 1. add Tegra132 support. 2. add HW throttle function. 3. set hot trip temperatures which can trigger the HW throttle. Main changes from V1: 1. use readl/writel instead of __raw_readl/__raw_writel. 2. rebase on the linux-next. The v1 series

[PATCH v2 7/9] arm64: tegra: set hot trips for Tegra210

Enable throttle function for SOC_THERM. Set "hot" trips for cpu and gpu thermal zones, which can trigger the SOC_THERM hardware throttle. Signed-off-by: Wei Ni --- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 41 +--- 1 file changed, 32 insertions(+),

[PATCH v2 5/9] thermal: tegra: add hw-throttle function

Tegra soctherm support HW throttle, when the soctherm snesors' temperature is above the throttle trip point, it will trigger pulse skiper to tune clocks accroding to the throttle depth. Add this function for Tegra124 and Tegra210. Since Tegra132 use different registers to configure pulse skiper,

Re: [PATCH] dmaengine: pl330: Fix race in pl330_get_desc()

On Tue, Apr 26, 2016 at 10:00 PM, Robin Murphy wrote: > The current logic in pl330_get_desc() contains a clear race condition, > whereby if the descriptor pool is empty, we will create a new > descriptor, add it to the pool with the lock held, *release the lock*, > then try to remove it from the

[PATCH v2 0/9] Add HW throttle for Tegra soctherm

This series add following functions for Tegra soctherm: 1. add Tegra132 support. 2. add HW throttle function. 3. set hot trip temperatures which can trigger the HW throttle. Main changes from V1: 1. use readl/writel instead of __raw_readl/__raw_writel. 2. rebase on the linux-next. The v1 series

[PATCH v2 7/9] arm64: tegra: set hot trips for Tegra210

Enable throttle function for SOC_THERM. Set "hot" trips for cpu and gpu thermal zones, which can trigger the SOC_THERM hardware throttle. Signed-off-by: Wei Ni --- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 41 +--- 1 file changed, 32 insertions(+), 9 deletions(-)

[PATCH v2 5/9] thermal: tegra: add hw-throttle function

Tegra soctherm support HW throttle, when the soctherm snesors' temperature is above the throttle trip point, it will trigger pulse skiper to tune clocks accroding to the throttle depth. Add this function for Tegra124 and Tegra210. Since Tegra132 use different registers to configure pulse skiper,

[PATCH v2 1/9] thermal: tegra: add Tegra132 specific SOC_THERM driver

add Tegra132 specific SOC_THERM driver. Signed-off-by: Wei Ni --- drivers/thermal/tegra/Makefile| 1 + drivers/thermal/tegra/soctherm.c | 6 + drivers/thermal/tegra/soctherm.h | 4 + drivers/thermal/tegra/tegra132-soctherm.c | 196

[PATCH v2 9/9] arm: tegra: set hot trips for Tegra124

Enable throttle function for SOC_THERM. Set "hot" trips for cpu and gpu thermal zones, which can trigger the SOC_THERM hardware throttle. Signed-off-by: Wei Ni --- arch/arm/boot/dts/tegra124.dtsi | 39 ++- 1 file changed, 30 insertions(+), 9

[PATCH v2 3/9] arm64: tegra: set critical trips for Tegra132

Set general "critical" trip temperatures for cpu, gpu, mem and pllx thermal zones on Tegra132, these trips can trigger shut down or reset. Signed-off-by: Wei Ni --- arch/arm64/boot/dts/nvidia/tegra132.dtsi | 60 1 file changed, 60 insertions(+)

[PATCH v2 1/9] thermal: tegra: add Tegra132 specific SOC_THERM driver

add Tegra132 specific SOC_THERM driver. Signed-off-by: Wei Ni --- drivers/thermal/tegra/Makefile| 1 + drivers/thermal/tegra/soctherm.c | 6 + drivers/thermal/tegra/soctherm.h | 4 + drivers/thermal/tegra/tegra132-soctherm.c | 196

  1   2   3   4   5   6   7   8   9   10   >