Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On 18.02.2017 00:25, Cong Wang wrote: On Fri, Feb 17, 2017 at 3:16 PM, Gabriel C wrote: On 17.02.2017 23:38, Cong Wang wrote: On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: Hi all, while poking at a different issue I found the following

Re: [PATCH 4.4 00/20] 4.4.50-stable review

On Fri, Feb 17, 2017 at 11:28:43AM -0800, kernelci.org bot wrote: > stable-rc boot: 31 boots: 0 failed, 31 passed (v4.4.49-21-g967e7e889dce) Better than the 4.9 number of boots, but still odd...

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On 18.02.2017 00:25, Cong Wang wrote: On Fri, Feb 17, 2017 at 3:16 PM, Gabriel C wrote: On 17.02.2017 23:38, Cong Wang wrote: On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: Hi all, while poking at a different issue I found the following on my logs : [85362.132770] BUG: sleeping

Re: [PATCH 4.4 00/20] 4.4.50-stable review

On Fri, Feb 17, 2017 at 11:28:43AM -0800, kernelci.org bot wrote: > stable-rc boot: 31 boots: 0 failed, 31 passed (v4.4.49-21-g967e7e889dce) Better than the 4.9 number of boots, but still odd...

Re: [PATCH 4.9 00/32] 4.9.11-stable review

On Fri, Feb 17, 2017 at 11:28:44AM -0800, kernelci.org bot wrote: > stable-rc boot: 4 boots: 0 failed, 4 passed (v4.9.10-33-gf6f9e9361112) That's a small number of boots, really small, what went wrong here? Do you all need more time? thanks, greg k-h

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 3:38 PM, Gabriel C wrote: > > My card seems to use the e1000e driver which is buit-in.. > > Anyway here an objdump -x : > > http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/objdump-x_e1000.ko.txt > Found disable_hardirq() but not

Re: [PATCH 4.9 00/32] 4.9.11-stable review

On Fri, Feb 17, 2017 at 11:28:44AM -0800, kernelci.org bot wrote: > stable-rc boot: 4 boots: 0 failed, 4 passed (v4.9.10-33-gf6f9e9361112) That's a small number of boots, really small, what went wrong here? Do you all need more time? thanks, greg k-h

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 3:38 PM, Gabriel C wrote: > > My card seems to use the e1000e driver which is buit-in.. > > Anyway here an objdump -x : > > http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/objdump-x_e1000.ko.txt > Found disable_hardirq() but not disable_irq(). Are you sure the

Re: [PATCH net-next v2 2/6] net: dsa: mv88e6xxx: move ATU code in its own file

From: Andrew Lunn Date: Fri, 17 Feb 2017 23:36:51 +0100 > Please take your time to do this right. Lots of small patches, which > are obviously correct. Agreed.

Re: [PATCH net-next v2 2/6] net: dsa: mv88e6xxx: move ATU code in its own file

From: Andrew Lunn Date: Fri, 17 Feb 2017 23:36:51 +0100 > Please take your time to do this right. Lots of small patches, which > are obviously correct. Agreed.

[PATCH] Make mtdblock can handle partition bigger than 4G.

Signed-off-by: Lepton Wu --- drivers/mtd/mtdblock.c| 33 + drivers/mtd/mtdblock_ro.c | 4 ++-- 2 files changed, 19 insertions(+), 18 deletions(-) diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c index

[PATCH] Make mtdblock can handle partition bigger than 4G.

Signed-off-by: Lepton Wu --- drivers/mtd/mtdblock.c| 33 + drivers/mtd/mtdblock_ro.c | 4 ++-- 2 files changed, 19 insertions(+), 18 deletions(-) diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c index bb4c14f83c75..3d2da76287a7 100644 ---

Re: [PATCH] PCI,pciehp: Don't handle PDC for cards with attention button

On Fri, Feb 17, 2017 at 2:39 PM, Bjorn Helgaas wrote: > On Thu, Feb 16, 2017 at 10:12:47PM -0800, Yinghai Lu wrote: > > I don't think it really makes sense to tie PDC handling with the > attention button. It might happen to avoid the problem on your > system, but I don't see

Re: [PATCH] PCI,pciehp: Don't handle PDC for cards with attention button

On Fri, Feb 17, 2017 at 2:39 PM, Bjorn Helgaas wrote: > On Thu, Feb 16, 2017 at 10:12:47PM -0800, Yinghai Lu wrote: > > I don't think it really makes sense to tie PDC handling with the > attention button. It might happen to avoid the problem on your > system, but I don't see the logical

[RFC/RFT PATCH 3/3] Input: ad7879 - allow exporting AUX/VBAT/GPIO pin via device property

Up until now only platforms using legacy platform data were able to switch AUX/VBAT/GPIO pin in GPIO mode and use it as regular GPIO line. Let's allow platforms using generic device properties to do the same. Signed-off-by: Dmitry Torokhov ---

[RFC/RFT PATCH 3/3] Input: ad7879 - allow exporting AUX/VBAT/GPIO pin via device property

Up until now only platforms using legacy platform data were able to switch AUX/VBAT/GPIO pin in GPIO mode and use it as regular GPIO line. Let's allow platforms using generic device properties to do the same. Signed-off-by: Dmitry Torokhov ---

[RFC/RFT PATCH 1/3] Input: ad7879 - convert to use regmap

Instead of rolling our own infrastructure to provide uniform access to I2C and SPI buses, let's switch to using regmap. Signed-off-by: Dmitry Torokhov --- Michael, I am a bit (actually a lot) confused how this driver was working with SPI and Blackfin, which is, as

mmotm 2017-02-17-15-31 uploaded

The mm-of-the-moment snapshot 2017-02-17-15-31 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

[RFC/RFT PATCH 1/3] Input: ad7879 - convert to use regmap

Instead of rolling our own infrastructure to provide uniform access to I2C and SPI buses, let's switch to using regmap. Signed-off-by: Dmitry Torokhov --- Michael, I am a bit (actually a lot) confused how this driver was working with SPI and Blackfin, which is, as far as I understand,

mmotm 2017-02-17-15-31 uploaded

The mm-of-the-moment snapshot 2017-02-17-15-31 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

[RFC/RFT PATCH 2/3] Input: ad7879 - use more devm interfaces

gpiochip_add now has a managed version, and we can remove sysfs attribute group via devm_add_action_or_reset (at least until we have devm version of sysfs_crreate_group). This allows us to get rid of ad7879_remove(). Signed-off-by: Dmitry Torokhov ---

[RFC/RFT PATCH 2/3] Input: ad7879 - use more devm interfaces

gpiochip_add now has a managed version, and we can remove sysfs attribute group via devm_add_action_or_reset (at least until we have devm version of sysfs_crreate_group). This allows us to get rid of ad7879_remove(). Signed-off-by: Dmitry Torokhov --- drivers/input/touchscreen/ad7879-i2c.c | 12

Re: [PATCH net-next] virito-net: set queues after reset during xdp_set

On 17-02-16 09:10 PM, Jason Wang wrote: > > > On 2017年02月17日 12:53, John Fastabend wrote: >> On 17-02-15 01:08 AM, Jason Wang wrote: >>> We set queues before reset which will cause a crash[1]. This is >>> because is_xdp_raw_buffer_queue() depends on the old xdp queue pairs >>> number to do the

Re: [PATCH net-next] virito-net: set queues after reset during xdp_set

On 17-02-16 09:10 PM, Jason Wang wrote: > > > On 2017年02月17日 12:53, John Fastabend wrote: >> On 17-02-15 01:08 AM, Jason Wang wrote: >>> We set queues before reset which will cause a crash[1]. This is >>> because is_xdp_raw_buffer_queue() depends on the old xdp queue pairs >>> number to do the

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 3:16 PM, Gabriel C wrote: > > > On 17.02.2017 23:38, Cong Wang wrote: >> >> On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: >>> >>> Hi all, >>> >>> while poking at a different issue I found the following on my logs : >>> >>>

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 3:16 PM, Gabriel C wrote: > > > On 17.02.2017 23:38, Cong Wang wrote: >> >> On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: >>> >>> Hi all, >>> >>> while poking at a different issue I found the following on my logs : >>> >>> [85362.132770] BUG: sleeping function called

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On 18.02.2017 00:16, Gabriel C wrote: On 17.02.2017 23:38, Cong Wang wrote: On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: Hi all, while poking at a different issue I found the following on my logs : [85362.132770] BUG: sleeping function called from invalid

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On 18.02.2017 00:16, Gabriel C wrote: On 17.02.2017 23:38, Cong Wang wrote: On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: Hi all, while poking at a different issue I found the following on my logs : [85362.132770] BUG: sleeping function called from invalid context at

Re: [PATCH V2 0/6] PM / Domains: Implement domain performance states

Viresh Kumar writes: > An earlier series[1] tried to implement bindings for PM domain > performance states. Rob Herring suggested that we can actually merge the > supporting code first instead of bindings, as that will make things > easier to understand for all. The

Re: [PATCH V2 0/6] PM / Domains: Implement domain performance states

Viresh Kumar writes: > An earlier series[1] tried to implement bindings for PM domain > performance states. Rob Herring suggested that we can actually merge the > supporting code first instead of bindings, as that will make things > easier to understand for all. The bindings can be decided and

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On 17.02.2017 23:38, Cong Wang wrote: On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: Hi all, while poking at a different issue I found the following on my logs : [85362.132770] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On 17.02.2017 23:38, Cong Wang wrote: On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: Hi all, while poking at a different issue I found the following on my logs : [85362.132770] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110 [85362.132771] in_atomic(): 1,

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

On February 17, 2017 3:02:33 PM PST, Andy Lutomirski wrote: >On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds > wrote: >> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski > wrote: >>> >>> At the very least, I'd want to see

[ANNOUNCE] Git v2.12.0-rc2

A release candidate Git v2.12.0-rc2 is now available for testing at the usual places. It is comprised of 487 non-merge commits since v2.11.0, contributed by 67 people, 21 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

On February 17, 2017 3:02:33 PM PST, Andy Lutomirski wrote: >On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds > wrote: >> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski > wrote: >>> >>> At the very least, I'd want to see >>> MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING. I *hate* the current >>>

[ANNOUNCE] Git v2.12.0-rc2

A release candidate Git v2.12.0-rc2 is now available for testing at the usual places. It is comprised of 487 non-merge commits since v2.11.0, contributed by 67 people, 21 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

Re: [PATCH 4/5] staging: bcm2835-audio: bcm2835.h: fix volatile coding style issue

On Fri, 2017-02-17 at 15:16 -0500, Nathan Howard wrote: > Fix checkpatch.pl warning of the form "WARNING: Use of volatile is > usually wrong: see Documentation/process/volatile-considered-harmful.rst." Why are you sure the volatile use is not necessary? > Signed-off-by: Nathan Howard

Re: [PATCH 4/5] staging: bcm2835-audio: bcm2835.h: fix volatile coding style issue

On Fri, 2017-02-17 at 15:16 -0500, Nathan Howard wrote: > Fix checkpatch.pl warning of the form "WARNING: Use of volatile is > usually wrong: see Documentation/process/volatile-considered-harmful.rst." Why are you sure the volatile use is not necessary? > Signed-off-by: Nathan Howard > --- >

Re: [PATCH 2/2] mmc: meson-gx: remove mmc host on device removal

Michał Zegan writes: > W dniu 17.02.2017 o 20:47, Kevin Hilman pisze: >> Michał Zegan writes: >> >>> The mmc host was added in meson_mmc_probe, but never removed in >>> meson_mmc_remove. >>> Fix that by removing the host before deallocating other

Re: [PATCH 2/2] mmc: meson-gx: remove mmc host on device removal

Michał Zegan writes: > W dniu 17.02.2017 o 20:47, Kevin Hilman pisze: >> Michał Zegan writes: >> >>> The mmc host was added in meson_mmc_probe, but never removed in >>> meson_mmc_remove. >>> Fix that by removing the host before deallocating other resources. >>> >>> Signed-off-by: Michał Zegan

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds wrote: > On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski wrote: >> >> At the very least, I'd want to see >> MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING. I *hate* the current >> interface. > >

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds wrote: > On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski wrote: >> >> At the very least, I'd want to see >> MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING. I *hate* the current >> interface. > > That's unrelated, but I guess w could add a MAP_NOUNMAP

[PATCH] Input: tsc2007 - switch to using input_set_capability()

Do not manipulate evbit/keybit directly, use helper for that. Signed-off-by: Dmitry Torokhov --- drivers/input/touchscreen/tsc2007_core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/input/touchscreen/tsc2007_core.c

[PATCH] Input: tsc2007 - switch to using input_set_capability()

Do not manipulate evbit/keybit directly, use helper for that. Signed-off-by: Dmitry Torokhov --- drivers/input/touchscreen/tsc2007_core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/input/touchscreen/tsc2007_core.c b/drivers/input/touchscreen/tsc2007_core.c

Re: [PATCH v9] soc: qcom: Add SoC info driver

On 02/16, Imran Khan wrote: > diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c > index 18ec52f..4f0ccf8 100644 > --- a/drivers/soc/qcom/smem.c > +++ b/drivers/soc/qcom/smem.c > @@ -85,6 +85,9 @@ > /* Max number of processors/hosts in a system */ > #define SMEM_HOST_COUNT

Re: [PATCH v9] soc: qcom: Add SoC info driver

On 02/16, Imran Khan wrote: > diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c > index 18ec52f..4f0ccf8 100644 > --- a/drivers/soc/qcom/smem.c > +++ b/drivers/soc/qcom/smem.c > @@ -85,6 +85,9 @@ > /* Max number of processors/hosts in a system */ > #define SMEM_HOST_COUNT

Re: [PATCH] Staging: ks7010: ks_*: Braces should be used on all arms of these statements

On Fri, 2017-02-17 at 22:41 +0100, Shiva Kerdel wrote: > Braces should be used on all arms of these statements (CHECK).. [] > diff --git a/drivers/staging/ks7010/ks_hostif.c > b/drivers/staging/ks7010/ks_hostif.c [] > @@ -2148,8 +2148,9 @@ void hostif_sme_mode_setup(struct ks_wlan_private *priv)

Re: [PATCH] Staging: ks7010: ks_*: Braces should be used on all arms of these statements

On Fri, 2017-02-17 at 22:41 +0100, Shiva Kerdel wrote: > Braces should be used on all arms of these statements (CHECK).. [] > diff --git a/drivers/staging/ks7010/ks_hostif.c > b/drivers/staging/ks7010/ks_hostif.c [] > @@ -2148,8 +2148,9 @@ void hostif_sme_mode_setup(struct ks_wlan_private *priv)

Re: [PATCH v2] gpio: dwapb: Add support for next generation of X-Gene SoC

Hi Andy, On Fri, Feb 17, 2017 at 2:23 AM, Andy Shevchenko wrote: > On Fri, Feb 17, 2017 at 3:01 AM, Hoan Tran wrote: >> Next generation of X-Gene SoC's GPIO hardware register map is very >> similar to DW GPIO. It only differs by a few register

Re: [PATCH v2] gpio: dwapb: Add support for next generation of X-Gene SoC

Hi Andy, On Fri, Feb 17, 2017 at 2:23 AM, Andy Shevchenko wrote: > On Fri, Feb 17, 2017 at 3:01 AM, Hoan Tran wrote: >> Next generation of X-Gene SoC's GPIO hardware register map is very >> similar to DW GPIO. It only differs by a few register addresses. >> This patch modifies DW GPIO driver to

Re: [PATCH net-next v2 6/6] net: dsa: mv88e6xxx: add support for 6390 VTU

On Fri, Feb 17, 2017 at 10:05:31AM -0500, Vivien Didelot wrote: > The 6390 family of chips use only 2 of the 3 VTU Data registers to pack > the MemberTag and PortState VLAN data. This means that they must be > written or read before or after each VTU/STU operations. > > Implement this variant to

Re: [PATCH net-next v2 6/6] net: dsa: mv88e6xxx: add support for 6390 VTU

On Fri, Feb 17, 2017 at 10:05:31AM -0500, Vivien Didelot wrote: > The 6390 family of chips use only 2 of the 3 VTU Data registers to pack > the MemberTag and PortState VLAN data. This means that they must be > written or read before or after each VTU/STU operations. > > Implement this variant to

Re: [PATCH] PCI,pciehp: Don't handle PDC for cards with attention button

On Thu, Feb 16, 2017 at 10:12:47PM -0800, Yinghai Lu wrote: > On one system during power off slot, find card get power on right away. > # echo 0 > /sys/bus/pci/slots/1/power > pci_hotplug: power_write_file: power = 0 > pciehp :16:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read

Re: [PATCH] PCI,pciehp: Don't handle PDC for cards with attention button

On Thu, Feb 16, 2017 at 10:12:47PM -0800, Yinghai Lu wrote: > On one system during power off slot, find card get power on right away. > # echo 0 > /sys/bus/pci/slots/1/power > pci_hotplug: power_write_file: power = 0 > pciehp :16:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: > Hi all, > > while poking at a different issue I found the following on my logs : > > [85362.132770] BUG: sleeping function called from invalid context at > kernel/irq/manage.c:110 > [85362.132771] in_atomic(): 1,

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C wrote: > Hi all, > > while poking at a different issue I found the following on my logs : > > [85362.132770] BUG: sleeping function called from invalid context at > kernel/irq/manage.c:110 > [85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153,

Re: [PATCH net-next v2 2/6] net: dsa: mv88e6xxx: move ATU code in its own file

> Note that we are very close from 4.10, so unless there is a major issue > in the patchset, I'd prefer not to respin new versions. I'd gladly send > cosmetics fixup later though. I'm waiting for this patchset to land in > net-next to send the second one ready for cross-chip bridging in DSA. I

Re: [PATCH net-next v2 2/6] net: dsa: mv88e6xxx: move ATU code in its own file

> Note that we are very close from 4.10, so unless there is a major issue > in the patchset, I'd prefer not to respin new versions. I'd gladly send > cosmetics fixup later though. I'm waiting for this patchset to land in > net-next to send the second one ready for cross-chip bridging in DSA. I

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

On Fri, Feb 17, 2017 at 02:37:12PM +0200, Jarkko Sakkinen wrote: Hi, I hope the week is ending well for everyone. > On Fri, Feb 17, 2017 at 03:56:26AM -0600, Dr. Greg Wettstein wrote: > > On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote: > > > > Good morning to everyone. > > > >

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

On Fri, Feb 17, 2017 at 02:37:12PM +0200, Jarkko Sakkinen wrote: Hi, I hope the week is ending well for everyone. > On Fri, Feb 17, 2017 at 03:56:26AM -0600, Dr. Greg Wettstein wrote: > > On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote: > > > > Good morning to everyone. > > > >

Re: [PATCH v8 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver

On 01/10, Imran Khan wrote: > The socinfo ABI document describes the information provided > by socinfo driver and the corresponding attributes to access > that information. > > Signed-off-by: Imran Khan > --- > Documentation/ABI/stable/sysfs-driver-qcom_socinfo | 147 >

Re: g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

On Thu, 16 Feb 2017, Ondrej Zary wrote: > On Tuesday 31 January 2017 02:31:45 Finn Thain wrote: > [...] > > Are you trying to figure out which commands are going to disconnect > > during a transfer? This is really a function of the firmware in the > > target; there are no good heuristics

Re: [PATCH v8 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver

On 01/10, Imran Khan wrote: > The socinfo ABI document describes the information provided > by socinfo driver and the corresponding attributes to access > that information. > > Signed-off-by: Imran Khan > --- > Documentation/ABI/stable/sysfs-driver-qcom_socinfo | 147 > +

Re: g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

On Thu, 16 Feb 2017, Ondrej Zary wrote: > On Tuesday 31 January 2017 02:31:45 Finn Thain wrote: > [...] > > Are you trying to figure out which commands are going to disconnect > > during a transfer? This is really a function of the firmware in the > > target; there are no good heuristics

Re: net: use-after-free in tw_timer_handler

On Fri, Feb 17, 2017 at 12:36 PM, Dmitry Vyukov wrote: > On Fri, Feb 17, 2017 at 7:51 PM, Cong Wang wrote: >> >> This code was changed a long time ago : >> >>

Re: net: use-after-free in tw_timer_handler

On Fri, Feb 17, 2017 at 12:36 PM, Dmitry Vyukov wrote: > On Fri, Feb 17, 2017 at 7:51 PM, Cong Wang wrote: >> >> This code was changed a long time ago : >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ed2e923945892a8372ab70d2f61d364b0b6d9054

Re: [RFC 7/8] fpga-region: add sysfs interface

Moritz, whatever solution we decide to go with has to work with other OS'es. The last thing we want to do is to have wrappers that are Linux specific. Yves On Wed, 15 Feb 2017, Moritz Fischer wrote: >>Hi Jason, >> >>On Wed, Feb 15, 2017 at 12:37 PM, Jason Gunthorpe

Re: [RFC 7/8] fpga-region: add sysfs interface

Moritz, whatever solution we decide to go with has to work with other OS'es. The last thing we want to do is to have wrappers that are Linux specific. Yves On Wed, 15 Feb 2017, Moritz Fischer wrote: >>Hi Jason, >> >>On Wed, Feb 15, 2017 at 12:37 PM, Jason Gunthorpe >> wrote: >>> On Wed, Feb

Userspace mmap to PCI is failing

Hello, I am trying to mmap a PCI device, but it fails with EINVAL. ... fd = open("/dev/mem", O_RDWR | O_SYNC); ... rv = mmap64(0, size, PROT_READ, MAP_SHARED, fd, pci_addr); ... The pci_addr is the address obtained from lspci output which is a 64 bit address. The pci_addr has a value of

Userspace mmap to PCI is failing

Hello, I am trying to mmap a PCI device, but it fails with EINVAL. ... fd = open("/dev/mem", O_RDWR | O_SYNC); ... rv = mmap64(0, size, PROT_READ, MAP_SHARED, fd, pci_addr); ... The pci_addr is the address obtained from lspci output which is a 64 bit address. The pci_addr has a value of

[PATCH] mtd: spi-nor: hisi: do not ignore clk_prepare_enable() failure

hisi_spi_nor_probe() ignores clk_prepare_enable() error code. The patch fixes that. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/mtd/spi-nor/hisi-sfc.c | 5 - 1 file changed, 4 insertions(+), 1

[PATCH] mtd: spi-nor: hisi: do not ignore clk_prepare_enable() failure

hisi_spi_nor_probe() ignores clk_prepare_enable() error code. The patch fixes that. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/mtd/spi-nor/hisi-sfc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

Re: [PATCH v3 0/7] Move dell-led to drivers/platform/x86

Hi Michał, Thanks for collecting relevant credits. I've applied the patchset to the for-4.12 branch of linux-leds.git. Best regards, Jacek Anaszewski On 02/17/2017 08:57 AM, Michał Kępień wrote: > This patch series moves the dell-led driver from the LED subsystem to > the x86 platform driver

Re: [PATCH v3 0/7] Move dell-led to drivers/platform/x86

Hi Michał, Thanks for collecting relevant credits. I've applied the patchset to the for-4.12 branch of linux-leds.git. Best regards, Jacek Anaszewski On 02/17/2017 08:57 AM, Michał Kępień wrote: > This patch series moves the dell-led driver from the LED subsystem to > the x86 platform driver

Re: [PATCH] [media] Staging: media/lirc: don't call put_ir_rx on rx twice

This one is a false positive. The original code is correct. I was looking through my mail boxes to see the history of this and why it hadn't been fixed earlier. Someone tried to fix it in 2011: https://www.spinics.net/lists/linux-driver-devel/msg17403.html Then I complained about it again in

Re: [PATCH] [media] Staging: media/lirc: don't call put_ir_rx on rx twice

This one is a false positive. The original code is correct. I was looking through my mail boxes to see the history of this and why it hadn't been fixed earlier. Someone tried to fix it in 2011: https://www.spinics.net/lists/linux-driver-devel/msg17403.html Then I complained about it again in

[PATCHv2 0/6] x86/platform/uv/BAU: UV4 message completion and initialization updates

The following patch series adds the necessary functionality to make the BAU on UV4 operational. The purpose of these patches is to implement the correct message completion logic on UV4. Also included is a bug fix to add a field to the INTD payload. This is needed to verify the source of each

[PATCHv2 0/6] x86/platform/uv/BAU: UV4 message completion and initialization updates

The following patch series adds the necessary functionality to make the BAU on UV4 operational. The purpose of these patches is to implement the correct message completion logic on UV4. Also included is a bug fix to add a field to the INTD payload. This is needed to verify the source of each

[PATCH v2 2/6] x86/platform/uv/BAU: Add payload descriptor qualifier

On UV4, the destination agent verifies each message by checking the descriptor qualifier field of the message payload. Messages without this field set to 0x534749 will cause a hub error to assert. Split bau_message_payload into uv1_2_3 and uv4 versions to account for the different payload

[PATCH 4/6] x86/platform/uv/BAU: Add status mmr location fields to bau_control

The location of the ERROR and BUSY status bits depends on the descriptor index, i.e. the CPU, of the message. Since this index does not change, there is no need to calculate the MMR and index location during message processing. The less work we do in the hot path the better. Add status_mmr and

[PATCH v2 2/6] x86/platform/uv/BAU: Add payload descriptor qualifier

On UV4, the destination agent verifies each message by checking the descriptor qualifier field of the message payload. Messages without this field set to 0x534749 will cause a hub error to assert. Split bau_message_payload into uv1_2_3 and uv4 versions to account for the different payload

[PATCH 4/6] x86/platform/uv/BAU: Add status mmr location fields to bau_control

The location of the ERROR and BUSY status bits depends on the descriptor index, i.e. the CPU, of the message. Since this index does not change, there is no need to calculate the MMR and index location during message processing. The less work we do in the hot path the better. Add status_mmr and

[PATCH v2 6/6] x86/platform/uv/BAU: Implement uv4_wait_completion with read_status

UV4 does not employ a software-timeout as in previous generations so a new wait_completion routine without this logic is required. Certain completion statuses require the AUX status bit in addition to ERROR and BUSY. Add the read_status routine to construct the full completion status. Use

[PATCH v2 6/6] x86/platform/uv/BAU: Implement uv4_wait_completion with read_status

UV4 does not employ a software-timeout as in previous generations so a new wait_completion routine without this logic is required. Certain completion statuses require the AUX status bit in addition to ERROR and BUSY. Add the read_status routine to construct the full completion status. Use

[PATCH 3/6] x86/platform/uv/BAU: Cleanup bau_operations declaration and instances

Move the bau_operations declaration after bau struct declarations so the bau structs can be referenced when adding new functions to bau_operations. That way we avoid forward declarations of the bau structs. Likewise, move uv*_bau_ops structs down to avoid forward declarations of new functions

[PATCH v2 5/6] x86/platform/uv/BAU: Add wait_completion to bau_operations

Remove the present wait_completion routine and add a function pointer by the same name to the bau_operations struct. Rather than switching on the UV hub version during message processing, set the architecture-specific uv*_wait_completion during initialization. The uv123_bau_ops struct must be

[PATCH 3/6] x86/platform/uv/BAU: Cleanup bau_operations declaration and instances

Move the bau_operations declaration after bau struct declarations so the bau structs can be referenced when adding new functions to bau_operations. That way we avoid forward declarations of the bau structs. Likewise, move uv*_bau_ops structs down to avoid forward declarations of new functions

[PATCH v2 5/6] x86/platform/uv/BAU: Add wait_completion to bau_operations

Remove the present wait_completion routine and add a function pointer by the same name to the bau_operations struct. Rather than switching on the UV hub version during message processing, set the architecture-specific uv*_wait_completion during initialization. The uv123_bau_ops struct must be

[PATCH 1/6] x86/platform/uv/BAU: Add uv_bau_version enumerated constants

Define enumerated constants for each UV hub version and replace magic numbers with the appropriate constant. This makes our checks against uvhub_version more robust, and any use of unsupported archs will be caught during compilation. Signed-off-by: Andrew Banman Acked-by: Mike

[PATCH 1/6] x86/platform/uv/BAU: Add uv_bau_version enumerated constants

Define enumerated constants for each UV hub version and replace magic numbers with the appropriate constant. This makes our checks against uvhub_version more robust, and any use of unsupported archs will be caught during compilation. Signed-off-by: Andrew Banman Acked-by: Mike Travis ---

[PATCH v1 1/1] scsi: ufs-qcom: remove redundant condition check

Dan Carpenter reported this: --- The patch 9c46b8676271: "scsi: ufs-qcom: dump additional testbus registers" from Feb 3, 2017, leads to the following static checker warning: drivers/scsi/ufs/ufs-qcom.c:1531 ufs_qcom_testbus_cfg_is_ok() warn: impossible condition

[PATCH v1 1/1] scsi: ufs-qcom: remove redundant condition check

Dan Carpenter reported this: --- The patch 9c46b8676271: "scsi: ufs-qcom: dump additional testbus registers" from Feb 3, 2017, leads to the following static checker warning: drivers/scsi/ufs/ufs-qcom.c:1531 ufs_qcom_testbus_cfg_is_ok() warn: impossible condition

Re: [RFC 4/8] doc: fpga-mgr: separate getting/locking FPGA manager

On Fri, Feb 17, 2017 at 11:52 AM, Moritz Fischer wrote: > Alan, > > small nits inline Hi Moritz, Thanks for the review! Alan > > On Wed, Feb 15, 2017 at 8:14 AM, Alan Tull wrote: >> Document that getting a reference to a FPGA Manager has been >> separated

Re: [RFC 4/8] doc: fpga-mgr: separate getting/locking FPGA manager

On Fri, Feb 17, 2017 at 11:52 AM, Moritz Fischer wrote: > Alan, > > small nits inline Hi Moritz, Thanks for the review! Alan > > On Wed, Feb 15, 2017 at 8:14 AM, Alan Tull wrote: >> Document that getting a reference to a FPGA Manager has been >> separated from locking the FPGA Mangager for

Re: [PATCH v3 1/4] Documentation: devicetree: Add document bindings for leds-mt6323

Hi Sean, I've noticed some issues here, please refer below. On 02/17/2017 07:05 AM, sean.w...@mediatek.com wrote: > From: Sean Wang > > This patch adds documentation for devicetree bindings > for LED support on MT6323 PMIC > > Signed-off-by: Sean Wang

Re: [PATCH v3 3/4] leds: Add LED support for MT6323 PMIC

Hi Sean, Thanks for the updated patch. I have one more comment below. On 02/17/2017 07:05 AM, sean.w...@mediatek.com wrote: > From: Sean Wang > > MT6323 PMIC is a multi-function device that includes > LED function. It allows attaching up to 4 LEDs which > can either be

Re: [PATCH v3 1/4] Documentation: devicetree: Add document bindings for leds-mt6323

Hi Sean, I've noticed some issues here, please refer below. On 02/17/2017 07:05 AM, sean.w...@mediatek.com wrote: > From: Sean Wang > > This patch adds documentation for devicetree bindings > for LED support on MT6323 PMIC > > Signed-off-by: Sean Wang > --- >

Re: [PATCH v3 3/4] leds: Add LED support for MT6323 PMIC

Hi Sean, Thanks for the updated patch. I have one more comment below. On 02/17/2017 07:05 AM, sean.w...@mediatek.com wrote: > From: Sean Wang > > MT6323 PMIC is a multi-function device that includes > LED function. It allows attaching up to 4 LEDs which > can either be on, off or dimmed and/or

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On Fri, Feb 17, 2017 at 04:44:19PM +0100, Maxime Ripard wrote: [...] > We already have DT bindings for out of tree drivers, there's really > nothing new here. We have DT bindings for *hardware*, not for drivers. As stated in Documentation/devicetree/usage-model.txt: "The "Open Firmware Device

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On Fri, Feb 17, 2017 at 04:44:19PM +0100, Maxime Ripard wrote: [...] > We already have DT bindings for out of tree drivers, there's really > nothing new here. We have DT bindings for *hardware*, not for drivers. As stated in Documentation/devicetree/usage-model.txt: "The "Open Firmware Device

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