Re: [PATCH] mips: Add #ifdef in file bridge.h
No I didn't I finally learned how to cross compile the kernel it's not hard just have to find the docs for it :). Cheers Nick On Sat, Jul 5, 2014 at 10:43 AM, Randy Dunlap wrote: > On 07/04/2014 07:50 PM, Nicholas Krause wrote: >> This patch addes a #ifdef __ASSEMBLY__ in order to check if this part >> of the file is configured to fix this #ifdef block in bridge.h for mips. >> >> Signed-off-by: Nicholas Krause >> --- >> arch/mips/include/asm/netlogic/xlp-hal/bridge.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/mips/include/asm/netlogic/xlp-hal/bridge.h >> b/arch/mips/include/asm/netlogic/xlp-hal/bridge.h >> index 3067f98..4f315c3 100644 >> --- a/arch/mips/include/asm/netlogic/xlp-hal/bridge.h >> +++ b/arch/mips/include/asm/netlogic/xlp-hal/bridge.h >> @@ -143,7 +143,7 @@ >> #define BRIDGE_GIO_WEIGHT0x2cb >> #define BRIDGE_FLASH_WEIGHT 0x2cc >> >> -/* FIXME verify */ >> +#ifdef __ASSEMBLY__ >> #define BRIDGE_9XX_FLASH_BAR(i) (0x11 + (i)) >> #define BRIDGE_9XX_FLASH_BAR_LIMIT(i)(0x15 + (i)) >> >> > > Hi, > > Where is the corresponding #endif ? > The #endif at line 185 goes with the #ifndef __ASSEMBLY__ at line 176. > > I think that this patch will cause a build error (or at least a warning). > Did you test it? > > > -- > ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jul 4
Both tests for powerpc I can't test as I don't known where the configs
for all yes and random are for powerpc.
Cheers Nick
On Sun, Jul 6, 2014 at 1:34 AM, Nick Krause wrote:
> Here are my test logs for arm. Most of the failures from these builds
> not having default configures or make one by one errors. Below are
> my typed results. In the next message I will be sending logs for powerpc.
> Results
> iop13xx_defconfig - Successes in my tests
> mackerel_defconfig - Fails in my tests
> nuc910_defconfig - Fails in my tests
> nuc950_defconfig -Fails in my tests
> nuc960_defconfig - Fails in my tests
> s5p64x0_defconfig - Fails in my tests
> s5p64x0_defconfig - Fails in my tests
> arm-randconfig -Fails in my tests
> Cheers Nick
>
> On Sun, Jul 6, 2014 at 1:21 AM, Nick Krause wrote:
>> Sorry my mistake some of this are wrong I will resend.
>> Cheers Nick
>>
>> On Sun, Jul 6, 2014 at 1:17 AM, Nick Krause wrote:
>>> Here are my test logs for arm. Most of the failures from these builds
>>> not having default configures or make one by one errors. Below are
>>> my typed results.
>>> Results
>>> iop13xx_defconfig - Successes in my tests
>>> mackerel_defconfig - Fails in my tests
>>> nuc910_defconfig - Fails in my tests
>>> nuc950_defconfig -Fails in my tests
>>> nuc960_defconfig - Fails in my tests
>>> s5p64x0_defconfig - Fails in my tests
>>> s5p64x0_defconfig - Fails in my tests
>>> arm-randconfig -Fails in my tests
>>> BF561-ACVILON_defconfig -Fails in my tests
>>> BlackStamp_defconfig - Fails in my tests
>>> TCM-BF518_defconfig - Fails in my tests
>>>
>>> Cheers Nick
>>>
>>> On Sun, Jul 6, 2014 at 12:54 AM, Nick Krause wrote:
Hey guys ,
I checking Sachin Karmat's tests and fixing compile issues with
patches if need be. In my next email I am going to give a up to date
log of still failing builds for arm.
Cheers Nick
On Sat, Jul 5, 2014 at 10:57 AM, Sachin Kamat wrote:
> On Sat, Jul 5, 2014 at 6:18 AM, J. Bruce Fields
> wrote:
>> On Sat, Jul 05, 2014 at 01:10:58AM +1000, Stephen Rothwell wrote:
>>> Hi Sachin,
>>>
>>> On Fri, 4 Jul 2014 14:12:11 +0530 Sachin Kamat
>>> wrote:
>>> >
>>> > Was bisecting a kernel crash on Arndale octa board (Exynos5420). It
>>> > points to a merge
>>> > commit:
>>> > 40556a4c485d12d324f1ea196cc30f590e564237 is the first bad commit
>>> > ("Merge remote-tracking branch 'nfsd/nfsd-next'").
>>> >
>>> > How do I proceed with this?
>>>
>>> I guess we get the owner of the tree (possibly) in question involved
>>> (cc'd).
>>
>> Looking at the total diffstat for that branch, it's almost all contained
>> in fs/nfsd with a little in include/linux/sunrpc/ and net/sunrpc. So
>> it's extremely unlikely that it would be causing a problem unless you're
>> actually testing nfsd.
>
> I found it surprising too as I do not use nfsd. I will try out the things
> suggested by Stephen and update.
>
> --
> Regards,
> Sachin.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jul 4
Here are my test logs for arm. Most of the failures from these builds
not having default configures or make one by one errors. Below are
my typed results. In the next message I will be sending logs for powerpc.
Results
iop13xx_defconfig - Successes in my tests
mackerel_defconfig - Fails in my tests
nuc910_defconfig - Fails in my tests
nuc950_defconfig -Fails in my tests
nuc960_defconfig - Fails in my tests
s5p64x0_defconfig - Fails in my tests
s5p64x0_defconfig - Fails in my tests
arm-randconfig -Fails in my tests
Cheers Nick
On Sun, Jul 6, 2014 at 1:21 AM, Nick Krause wrote:
> Sorry my mistake some of this are wrong I will resend.
> Cheers Nick
>
> On Sun, Jul 6, 2014 at 1:17 AM, Nick Krause wrote:
>> Here are my test logs for arm. Most of the failures from these builds
>> not having default configures or make one by one errors. Below are
>> my typed results.
>> Results
>> iop13xx_defconfig - Successes in my tests
>> mackerel_defconfig - Fails in my tests
>> nuc910_defconfig - Fails in my tests
>> nuc950_defconfig -Fails in my tests
>> nuc960_defconfig - Fails in my tests
>> s5p64x0_defconfig - Fails in my tests
>> s5p64x0_defconfig - Fails in my tests
>> arm-randconfig -Fails in my tests
>> BF561-ACVILON_defconfig -Fails in my tests
>> BlackStamp_defconfig - Fails in my tests
>> TCM-BF518_defconfig - Fails in my tests
>>
>> Cheers Nick
>>
>> On Sun, Jul 6, 2014 at 12:54 AM, Nick Krause wrote:
>>> Hey guys ,
>>> I checking Sachin Karmat's tests and fixing compile issues with
>>> patches if need be. In my next email I am going to give a up to date
>>> log of still failing builds for arm.
>>> Cheers Nick
>>>
>>> On Sat, Jul 5, 2014 at 10:57 AM, Sachin Kamat wrote:
On Sat, Jul 5, 2014 at 6:18 AM, J. Bruce Fields
wrote:
> On Sat, Jul 05, 2014 at 01:10:58AM +1000, Stephen Rothwell wrote:
>> Hi Sachin,
>>
>> On Fri, 4 Jul 2014 14:12:11 +0530 Sachin Kamat
>> wrote:
>> >
>> > Was bisecting a kernel crash on Arndale octa board (Exynos5420). It
>> > points to a merge
>> > commit:
>> > 40556a4c485d12d324f1ea196cc30f590e564237 is the first bad commit
>> > ("Merge remote-tracking branch 'nfsd/nfsd-next'").
>> >
>> > How do I proceed with this?
>>
>> I guess we get the owner of the tree (possibly) in question involved
>> (cc'd).
>
> Looking at the total diffstat for that branch, it's almost all contained
> in fs/nfsd with a little in include/linux/sunrpc/ and net/sunrpc. So
> it's extremely unlikely that it would be causing a problem unless you're
> actually testing nfsd.
I found it surprising too as I do not use nfsd. I will try out the things
suggested by Stephen and update.
--
Regards,
Sachin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jul 4
Sorry my mistake some of this are wrong I will resend.
Cheers Nick
On Sun, Jul 6, 2014 at 1:17 AM, Nick Krause wrote:
> Here are my test logs for arm. Most of the failures from these builds
> not having default configures or make one by one errors. Below are
> my typed results.
> Results
> iop13xx_defconfig - Successes in my tests
> mackerel_defconfig - Fails in my tests
> nuc910_defconfig - Fails in my tests
> nuc950_defconfig -Fails in my tests
> nuc960_defconfig - Fails in my tests
> s5p64x0_defconfig - Fails in my tests
> s5p64x0_defconfig - Fails in my tests
> arm-randconfig -Fails in my tests
> BF561-ACVILON_defconfig -Fails in my tests
> BlackStamp_defconfig - Fails in my tests
> TCM-BF518_defconfig - Fails in my tests
>
> Cheers Nick
>
> On Sun, Jul 6, 2014 at 12:54 AM, Nick Krause wrote:
>> Hey guys ,
>> I checking Sachin Karmat's tests and fixing compile issues with
>> patches if need be. In my next email I am going to give a up to date
>> log of still failing builds for arm.
>> Cheers Nick
>>
>> On Sat, Jul 5, 2014 at 10:57 AM, Sachin Kamat wrote:
>>> On Sat, Jul 5, 2014 at 6:18 AM, J. Bruce Fields
>>> wrote:
On Sat, Jul 05, 2014 at 01:10:58AM +1000, Stephen Rothwell wrote:
> Hi Sachin,
>
> On Fri, 4 Jul 2014 14:12:11 +0530 Sachin Kamat
> wrote:
> >
> > Was bisecting a kernel crash on Arndale octa board (Exynos5420). It
> > points to a merge
> > commit:
> > 40556a4c485d12d324f1ea196cc30f590e564237 is the first bad commit
> > ("Merge remote-tracking branch 'nfsd/nfsd-next'").
> >
> > How do I proceed with this?
>
> I guess we get the owner of the tree (possibly) in question involved
> (cc'd).
Looking at the total diffstat for that branch, it's almost all contained
in fs/nfsd with a little in include/linux/sunrpc/ and net/sunrpc. So
it's extremely unlikely that it would be causing a problem unless you're
actually testing nfsd.
>>>
>>> I found it surprising too as I do not use nfsd. I will try out the things
>>> suggested by Stephen and update.
>>>
>>> --
>>> Regards,
>>> Sachin.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jul 4
Here are my test logs for arm. Most of the failures from these builds
not having default configures or make one by one errors. Below are
my typed results.
Results
iop13xx_defconfig - Successes in my tests
mackerel_defconfig - Fails in my tests
nuc910_defconfig - Fails in my tests
nuc950_defconfig -Fails in my tests
nuc960_defconfig - Fails in my tests
s5p64x0_defconfig - Fails in my tests
s5p64x0_defconfig - Fails in my tests
arm-randconfig -Fails in my tests
BF561-ACVILON_defconfig -Fails in my tests
BlackStamp_defconfig - Fails in my tests
TCM-BF518_defconfig - Fails in my tests
Cheers Nick
On Sun, Jul 6, 2014 at 12:54 AM, Nick Krause wrote:
> Hey guys ,
> I checking Sachin Karmat's tests and fixing compile issues with
> patches if need be. In my next email I am going to give a up to date
> log of still failing builds for arm.
> Cheers Nick
>
> On Sat, Jul 5, 2014 at 10:57 AM, Sachin Kamat wrote:
>> On Sat, Jul 5, 2014 at 6:18 AM, J. Bruce Fields wrote:
>>> On Sat, Jul 05, 2014 at 01:10:58AM +1000, Stephen Rothwell wrote:
Hi Sachin,
On Fri, 4 Jul 2014 14:12:11 +0530 Sachin Kamat wrote:
>
> Was bisecting a kernel crash on Arndale octa board (Exynos5420). It
> points to a merge
> commit:
> 40556a4c485d12d324f1ea196cc30f590e564237 is the first bad commit
> ("Merge remote-tracking branch 'nfsd/nfsd-next'").
>
> How do I proceed with this?
I guess we get the owner of the tree (possibly) in question involved
(cc'd).
>>>
>>> Looking at the total diffstat for that branch, it's almost all contained
>>> in fs/nfsd with a little in include/linux/sunrpc/ and net/sunrpc. So
>>> it's extremely unlikely that it would be causing a problem unless you're
>>> actually testing nfsd.
>>
>> I found it surprising too as I do not use nfsd. I will try out the things
>> suggested by Stephen and update.
>>
>> --
>> Regards,
>> Sachin.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Filesystem lockup with CONFIG_PREEMPT_RT
On Sat, Jul 5, 2014 at 1:26 PM, Thomas Gleixner wrote: > On Mon, 30 Jun 2014, Austin Schuh wrote: >> I think I might have an answer for my own question, but I would >> appreciate someone else to double check. If list_empty erroneously >> returns that there is work to do when there isn't work to do, we wake >> up an extra worker which then goes back to sleep. Not a big loss. If >> list_empty erroneously returns that there isn't work to do when there >> is, this should only be because someone is modifying the work list. >> When they finish, as far as I can tell, all callers then check to see >> if a worker needs to be started up, and start one. > > Precisely. A comment there when you put together a polished patch for inclusion would be awesome. I'm assuming that you will put the patch together? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jul 4
Hey guys ,
I checking Sachin Karmat's tests and fixing compile issues with
patches if need be. In my next email I am going to give a up to date
log of still failing builds for arm.
Cheers Nick
On Sat, Jul 5, 2014 at 10:57 AM, Sachin Kamat wrote:
> On Sat, Jul 5, 2014 at 6:18 AM, J. Bruce Fields wrote:
>> On Sat, Jul 05, 2014 at 01:10:58AM +1000, Stephen Rothwell wrote:
>>> Hi Sachin,
>>>
>>> On Fri, 4 Jul 2014 14:12:11 +0530 Sachin Kamat wrote:
>>> >
>>> > Was bisecting a kernel crash on Arndale octa board (Exynos5420). It
>>> > points to a merge
>>> > commit:
>>> > 40556a4c485d12d324f1ea196cc30f590e564237 is the first bad commit
>>> > ("Merge remote-tracking branch 'nfsd/nfsd-next'").
>>> >
>>> > How do I proceed with this?
>>>
>>> I guess we get the owner of the tree (possibly) in question involved
>>> (cc'd).
>>
>> Looking at the total diffstat for that branch, it's almost all contained
>> in fs/nfsd with a little in include/linux/sunrpc/ and net/sunrpc. So
>> it's extremely unlikely that it would be causing a problem unless you're
>> actually testing nfsd.
>
> I found it surprising too as I do not use nfsd. I will try out the things
> suggested by Stephen and update.
>
> --
> Regards,
> Sachin.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] SCSI fixes for 3.16-rc3
This is a set of 13 fixes, a MAINTAINERS update and a sparse update.
The fixes are mostly correct value initialisations, avoiding NULL derefs
and some uninitialised pointer avoidance.
All the patches have been incubated in -next for a few days. The final
patch (use the scsi data buffer length to extract transfer size) has
been rebased to add a cc to stable, but only the commit message has
changed.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-for-linus
The short changelog is:
Brian King (2):
ibmvscsi: Add memory barriers for send / receive
ibmvscsi: Abort init sequence during error recovery
Hannes Reinecke (1):
scsi_error: set DID_TIME_OUT correctly
Martin K. Petersen (1):
use the scsi data buffer length to extract transfer size
Maurizio Lombardi (2):
bnx2fc: do not scan uninitialized lists in case of error.
pm8001: Fix potential null pointer dereference and memory leak.
Neil Horman (2):
bnx2fc: Improve stats update mechanism
fc: ensure scan_work isn't active when freeing fc_rport
Paolo Bonzini (2):
virtio-scsi: fix various bad behavior on aborted requests
virtio-scsi: avoid cancelling uninitialized work items
Quinn Tran (1):
qla2xxx: Fix sparse warning in qla_target.c.
Reddy, Sreekanth (1):
MAINTAINERS: Update LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) maintainers
Email IDs
Tomas Henzl (2):
be2iscsi: remove potential junk pointer free
be2iscsi: add an missing goto in error path
Ulrich Obergfell (1):
scsi_error: fix invalid setting of host byte
And the diffstat:
MAINTAINERS | 9 +
drivers/scsi/be2iscsi/be_main.c | 2 ++
drivers/scsi/be2iscsi/be_mgmt.c | 4 +---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 16
drivers/scsi/bnx2fc/bnx2fc_io.c | 2 ++
drivers/scsi/ibmvscsi/ibmvscsi.c | 13 -
drivers/scsi/pm8001/pm8001_init.c | 13 ++---
drivers/scsi/qla2xxx/qla_target.c | 17 +++--
drivers/scsi/qla2xxx/qla_target.h | 4 ++--
drivers/scsi/scsi_error.c | 20 ++--
drivers/scsi/scsi_transport_fc.c | 1 +
drivers/scsi/virtio_scsi.c| 26 +-
include/scsi/scsi_cmnd.h | 2 +-
13 files changed, 86 insertions(+), 43 deletions(-)
With the full diff below.
James
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 3cc94ff..636a51a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5517,10 +5517,11 @@ S: Maintained
F: arch/arm/mach-lpc32xx/
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
-M: Nagalakshmi Nandigama
-M: Sreekanth Reddy
-M: supp...@lsi.com
-L: dl-mptfusionli...@lsi.com
+M: Nagalakshmi Nandigama
+M: Praveen Krishnamoorthy
+M: Sreekanth Reddy
+M: Abhijit Mahajan
+L: mpt-fusionlinux@avagotech.com
L: linux-s...@vger.kernel.org
W: http://www.lsilogic.com/support
S: Supported
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 5543490..56467df 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -4198,6 +4198,8 @@ static int hba_setup_cid_tbls(struct beiscsi_hba *phba)
kfree(phba->ep_array);
phba->ep_array = NULL;
ret = -ENOMEM;
+
+ goto free_memory;
}
for (i = 0; i < phba->params.cxns_per_ctrl; i++) {
diff --git a/drivers/scsi/be2iscsi/be_mgmt.c b/drivers/scsi/be2iscsi/be_mgmt.c
index 6045aa7..07934b0 100644
--- a/drivers/scsi/be2iscsi/be_mgmt.c
+++ b/drivers/scsi/be2iscsi/be_mgmt.c
@@ -1008,10 +1008,8 @@ int mgmt_set_ip(struct beiscsi_hba *phba,
BE2_IPV6 : BE2_IPV4 ;
rc = mgmt_get_if_info(phba, ip_type, _info);
- if (rc) {
- kfree(if_info);
+ if (rc)
return rc;
- }
if (boot_proto == ISCSI_BOOTPROTO_DHCP) {
if (if_info->dhcp_state) {
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index f548430..785d0d7 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -516,23 +516,17 @@ static void bnx2fc_recv_frame(struct sk_buff *skb)
skb_pull(skb, sizeof(struct fcoe_hdr));
fr_len = skb->len - sizeof(struct fcoe_crc_eof);
- stats = per_cpu_ptr(lport->stats, get_cpu());
- stats->RxFrames++;
- stats->RxWords += fr_len / FCOE_WORD_TO_BYTE;
-
fp = (struct fc_frame *)skb;
fc_frame_init(fp);
fr_dev(fp) = lport;
fr_sof(fp) = hp->fcoe_sof;
if (skb_copy_bits(skb, fr_len, _eof, sizeof(crc_eof))) {
- put_cpu();
kfree_skb(skb);
return;
}
fr_eof(fp) = crc_eof.fcoe_eof;
fr_crc(fp) = crc_eof.fcoe_crc32;
if (pskb_trim(skb, fr_len)) {
- put_cpu();
kfree_skb(skb);
return;
ATTN:
Hello, I'm Norman Chan, Tak-Lam, S.B.S., J.P, Chief Executive, Hong Kong Monetary Authority (HKMA). I have a monetary proposal worth $47.1M for you to handle with me. Contact me for more details. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH v10 2/2] dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller
Hi Maxime,
El 30/06/14 10:20, Maxime Ripard escribió:
The Allwinner A31 has a 16 channels DMA controller that it shares with the
newer A23. Although sharing some similarities with the DMA controller of the
older Allwinner SoCs, it's significantly different, I don't expect it to be
possible to share the driver for these two.
The A31 Controller is able to memory-to-memory or memory-to-device transfers on
the 16 channels in parallel.
Signed-off-by: Maxime Ripard
Acked-by: Arnd Bergmann
---
(...)
+
+static struct of_device_id sun6i_dma_match[] = {
+ { .compatible = "allwinner,sun6i-a31-dma" }
+};
The empty sentinel is missing here
Cheers,
Emilio
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm fixes
Hi Dave, This is NOT fixing problems with a stalled boot due to VGA problems as reported in thread: [PATCH 5/5] drm/i915: Kick out vga console It can be fixed by reverting: a4de05268e674e8ed31df6348269e22d6c6a1803 or applying the patch from Chris Wilson which can be found as a reply to my report. Thanks Ed Tomlinson On Saturday 05 July 2014 23:13:27 Dave Airlie wrote: > > Hi Linus, > > i915, tda998x and vmwgfx fixes, the main one is i915 fix for missing VGA > connectors, along with some fixes for the tda998x from Russell fixing some > modesetting problems > > (still on holidays, but got a spare moment to find these). > > Dave. > > The following changes since commit e1a08b855f56d6528e7f85aae9ca8123f4c3ae04: > > Merge tag 'arm64-fixes' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux (2014-07-05 > 10:12:52 -0700) > > are available in the git repository at: > > > git://people.freedesktop.org/~airlied/linux drm-fixes > > for you to fetch changes up to dfd7aecfd6d227831d77719379d4c7137f444fee: > > Merge tag 'drm-intel-fixes-2014-07-03' of > git://anongit.freedesktop.org/drm-intel (2014-07-06 07:49:59 +1000) > > > > Dave Airlie (3): > Merge branch 'tda998x-fixes' of > git://ftp.arm.linux.org.uk/~rmk/linux-cubox > Merge branch 'vmwgfx-fixes-3.16' of > git://people.freedesktop.org/~thomash/linux > Merge tag 'drm-intel-fixes-2014-07-03' of > git://anongit.freedesktop.org/drm-intel > > Deepak S (1): > drm/i915: Drop early VLV WA to fix Voltage not getting dropped to Vmin > > Guido Martínez (1): > drm/i2c: tda998x: move drm_i2c_encoder_destroy call > > Jesse Barnes (1): > drm/i915: only apply crt_present check on VLV > > Russell King (2): > drm/i2c: tda998x: faster polling for edid > drm/i2c: tda998x: add some basic mode validation > > Thomas Hellstrom (1): > drm/vmwgfx: Fix incorrect write to read-only register v2: > > Ville Syrjälä (1): > drm/i915: Wait for vblank after enabling the primary plane on BDW > > drivers/gpu/drm/i2c/tda998x_drv.c| 12 +--- > drivers/gpu/drm/i915/intel_display.c | 27 ++- > drivers/gpu/drm/i915/intel_pm.c | 8 > drivers/gpu/drm/i915/intel_sprite.c | 8 > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 1 - > 5 files changed, 51 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [USB spamming log] with 3.16-rc (git) my pl2303 is spaming my logs
Hi, The kernel in question is running on a i7 with a pi connected via to the i6 via the pl2303 to view the pi's console. The kernel on the i7 is at level: commit 77c4cf17ae867ba93233b3832bda3de7adaae326 Merge: 88b5a85 133d452 Author: Linus Torvalds Date: Fri Jul 4 09:37:43 2014 -0700 There is one extra patch applied to fix a problem with the boot stalling see the patch from Chris Wilson in the thread: [PATCH 5/5] drm/i915: Kick out vga console Here is a lsusb -v Bus 001 Device 011: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x067b Prolific Technology, Inc. idProduct 0x2303 PL2303 Serial Port bcdDevice3.00 iManufacturer 1 Prolific Technology Inc. iProduct2 USB-Serial Controller iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x (Bus Powered) Thanks Ed On Saturday 05 July 2014 11:02:06 Greg KH wrote: > On Sat, Jul 05, 2014 at 10:55:57AM -0400, Ed Tomlinson wrote: > > Hi > > > > I have a raspberry PI sending its console to my box via a pl2303 > > What exact pl2303 is this? Can you provide the output from 'lsusb'? > > > [5.184385] usbserial: USB Serial support registered for pl2303 > > [5.184398] pl2303 1-2.6:1.0: pl2303 converter detected > > [5.185353] usb 1-2.6: pl2303 converter now attached to ttyUSB0 > > > > and with the latest fixes from git on 3.16 its now started spamming my logs > > with: > > > > [55507.155354] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55510.736558] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55517.238586] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55521.099938] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55521.778520] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55523.229808] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55523.229846] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55525.074519] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > [55527.270207] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > > nonzero urb status: -71 > > That's saying there was one of the following errors in this device: > a) bitstuff error > b) no response packet received within the prescribed bus turn-around > time > c) unknown USB error > > All of which point to either a problem in the USB host controller, or > the usb device itself. > > Is this an "unpatched" 3.16-rc kernel running on the rpi? If so, odds > are it's a host controller issue... > > thanks, > > greg k-h > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More
[PATCH 0/6] DRBG: Rebasing unapplied patches
Hi, This patchset superseeds the patch sets submitted with [1] and [2]. It rebases all non-applied patches to the current Herbert Xu's cryptodev-2.6 tree. [1] https://lkml.org/lkml/2014/6/28/497 [2] https://lkml.org/lkml/2014/7/1/332 Stephan Mueller (6): DRBG: cleanup of preprocessor macros DRBG: Fix format string for debugging statements DRBG: Call CTR DRBG DF function only once DRBG: Select correct DRBG core for stdrng DRBG: Mix a time stamp into DRBG state DRBG: HMAC-SHA1 DRBG has crypto strength of 128 bits crypto/drbg.c | 134 +- include/crypto/drbg.h | 2 +- 2 files changed, 78 insertions(+), 58 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] DRBG: cleanup of preprocessor macros
The structure used to construct the module description line was marked
problematic by the sparse code analysis tool. The module line
description now does not contain any ifdefs to prevent error reports
from sparse.
Reported-by: kbuild test robot
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index acc7523..cce915b 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -356,6 +356,7 @@ static inline void drbg_add_buf(unsigned char *dst, size_t
dstlen,
**/
#ifdef CONFIG_CRYPTO_DRBG_CTR
+#define CRYPTO_DRBG_CTR_STRING "CTR "
static int drbg_kcapi_sym(struct drbg_state *drbg, const unsigned char *key,
unsigned char *outval, const struct drbg_string *in);
static int drbg_init_sym_kernel(struct drbg_state *drbg);
@@ -717,6 +718,7 @@ static int drbg_fini_hash_kernel(struct drbg_state *drbg);
#endif /* (CONFIG_CRYPTO_DRBG_HASH || CONFIG_CRYPTO_DRBG_HMAC) */
#ifdef CONFIG_CRYPTO_DRBG_HMAC
+#define CRYPTO_DRBG_HMAC_STRING "HMAC "
/* update function of HMAC DRBG as defined in 10.1.2.2 */
static int drbg_hmac_update(struct drbg_state *drbg, struct list_head *seed,
int reseed)
@@ -836,6 +838,7 @@ static struct drbg_state_ops drbg_hmac_ops = {
**/
#ifdef CONFIG_CRYPTO_DRBG_HASH
+#define CRYPTO_DRBG_HASH_STRING "HASH "
/*
* scratchpad usage: as drbg_hash_update and drbg_hash_df are used
* interlinked, the scratchpad is used as follows:
@@ -1867,7 +1870,7 @@ static inline int __init drbg_healthcheck_sanity(void)
#ifdef CONFIG_CRYPTO_DRBG_CTR
drbg_convert_tfm_core("drbg_nopr_ctr_aes128", , );
-#elif CONFIG_CRYPTO_DRBG_HASH
+#elif defined CONFIG_CRYPTO_DRBG_HASH
drbg_convert_tfm_core("drbg_nopr_sha256", , );
#else
drbg_convert_tfm_core("drbg_nopr_hmac_sha256", , );
@@ -2009,16 +2012,19 @@ void __exit drbg_exit(void)
module_init(drbg_init);
module_exit(drbg_exit);
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Stephan Mueller ");
-MODULE_DESCRIPTION("NIST SP800-90A Deterministic Random Bit Generator (DRBG)
using following cores:"
-#ifdef CONFIG_CRYPTO_DRBG_HMAC
-"HMAC "
+#ifndef CRYPTO_DRBG_HASH_STRING
+#define CRYPTO_DRBG_HASH_STRING ""
#endif
-#ifdef CONFIG_CRYPTO_DRBG_HASH
-"Hash "
+#ifndef CRYPTO_DRBG_HMAC_STRING
+#define CRYPTO_DRBG_HMAC_STRING ""
#endif
-#ifdef CONFIG_CRYPTO_DRBG_CTR
-"CTR"
+#ifndef CRYPTO_DRBG_CTR_STRING
+#define CRYPTO_DRBG_CTR_STRING ""
#endif
-);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Stephan Mueller ");
+MODULE_DESCRIPTION("NIST SP800-90A Deterministic Random Bit Generator (DRBG) "
+ "using following cores: "
+ CRYPTO_DRBG_HASH_STRING
+ CRYPTO_DRBG_HMAC_STRING
+ CRYPTO_DRBG_CTR_STRING);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] DRBG: Fix format string for debugging statements
The initial format strings caused warnings on several architectures. The
updated format strings now match the variable types.
Reported-by: kbuild test robot
Reported-by: Randy Dunlap
CC: Joe Perches
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index cce915b..c9b4c49 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1106,7 +1106,7 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
/* 9.1 / 9.2 / 9.3.1 step 3 */
if (pers && pers->len > (drbg_max_addtl(drbg))) {
- pr_devel("DRBG: personalization string too long %lu\n",
+ pr_devel("DRBG: personalization string too long %zu\n",
pers->len);
return -EINVAL;
}
@@ -1984,7 +1984,7 @@ static int __init drbg_init(void)
if (ARRAY_SIZE(drbg_cores) * 2 > ARRAY_SIZE(drbg_algs)) {
pr_info("DRBG: Cannot register all DRBG types"
- "(slots needed: %lu, slots available: %lu)\n",
+ "(slots needed: %zu, slots available: %zu)\n",
ARRAY_SIZE(drbg_cores) * 2, ARRAY_SIZE(drbg_algs));
return ret;
}
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] DRBG: Call CTR DRBG DF function only once
The CTR DRBG requires the update function to be called twice when
generating a random number. In both cases, update function must process
the additional information string by using the DF function. As the DF
produces the same result in both cases, we can save one invocation of
the DF function when the first DF function result is reused.
The result of the DF function is stored in the scratchpad storage. The
patch ensures that the scratchpad is not cleared when we want to reuse
the DF result. For achieving this, the CTR DRBG update function must
know by whom and in which scenario it is called. This information is
provided with the reseed parameter to the update function.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index c9b4c49..dba5ed2 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -562,7 +562,21 @@ out:
return ret;
}
-/* update function of CTR DRBG as defined in 10.2.1.2 */
+/*
+ * update function of CTR DRBG as defined in 10.2.1.2
+ *
+ * The reseed variable has an enhanced meaning compared to the update
+ * functions of the other DRBGs as follows:
+ * 0 => initial seed from initialization
+ * 1 => reseed via drbg_seed
+ * 2 => first invocation from drbg_ctr_update when addtl is present. In
+ * this case, the df_data scratchpad is not deleted so that it is
+ * available for another calls to prevent calling the DF function
+ * again.
+ * 3 => second invocation from drbg_ctr_update. When the update function
+ * was called with addtl, the df_data memory already contains the
+ * DFed addtl information and we do not need to call DF again.
+ */
static int drbg_ctr_update(struct drbg_state *drbg, struct list_head *seed,
int reseed)
{
@@ -577,7 +591,8 @@ static int drbg_ctr_update(struct drbg_state *drbg, struct
list_head *seed,
unsigned char prefix = DRBG_PREFIX1;
memset(temp, 0, drbg_statelen(drbg) + drbg_blocklen(drbg));
- memset(df_data, 0, drbg_statelen(drbg));
+ if (3 > reseed)
+ memset(df_data, 0, drbg_statelen(drbg));
/* 10.2.1.3.2 step 2 and 10.2.1.4.2 step 2 */
if (seed) {
@@ -619,7 +634,8 @@ static int drbg_ctr_update(struct drbg_state *drbg, struct
list_head *seed,
out:
memset(temp, 0, drbg_statelen(drbg) + drbg_blocklen(drbg));
- memset(df_data, 0, drbg_statelen(drbg));
+ if (2 != reseed)
+ memset(df_data, 0, drbg_statelen(drbg));
return ret;
}
@@ -644,7 +660,7 @@ static int drbg_ctr_generate(struct drbg_state *drbg,
LIST_HEAD(addtllist);
list_add_tail(>list, );
- ret = drbg_ctr_update(drbg, , 1);
+ ret = drbg_ctr_update(drbg, , 2);
if (ret)
return 0;
}
@@ -675,21 +691,8 @@ static int drbg_ctr_generate(struct drbg_state *drbg,
drbg_add_buf(drbg->V, drbg_blocklen(drbg), , 1);
}
- /*
-* 10.2.1.5.2 step 6
-* The following call invokes the DF function again which could be
-* optimized. In step 2, the "additional_input" after step 2 is the
-* output of the DF function. If this result would be saved, the DF
-* function would not need to be invoked again at this point.
-*/
- if (addtl && 0 < addtl->len) {
- LIST_HEAD(addtllist);
-
- list_add_tail(>list, );
- ret = drbg_ctr_update(drbg, , 1);
- } else {
- ret = drbg_ctr_update(drbg, NULL, 1);
- }
+ /* 10.2.1.5.2 step 6 */
+ ret = drbg_ctr_update(drbg, NULL, 3);
if (ret)
len = ret;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] DRBG: Select correct DRBG core for stdrng
When the DRBG is initialized, the core is looked up using the DRBG name. The name that can be used for the lookup is registered in cra_driver_name. The cra_name value contains stdrng. Thus, the lookup code must use crypto_tfm_alg_driver_name to obtain the precise DRBG name and select the correct DRBG. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index dba5ed2..2a7860f 100644 --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1761,7 +1761,7 @@ static int drbg_kcapi_init(struct crypto_tfm *tfm) bool pr = false; int coreref = 0; - drbg_convert_tfm_core(crypto_tfm_alg_name(tfm), , ); + drbg_convert_tfm_core(crypto_tfm_alg_driver_name(tfm), , ); /* * when personalization string is needed, the caller must call reset * and provide the personalization string as seed information -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] DRBG: Mix a time stamp into DRBG state
The current locking approach of the DRBG tries to keep the protected
code paths very minimal. It is therefore possible that two threads query
one DRBG instance at the same time. When thread A requests random
numbers, a shadow copy of the DRBG state is created upon which the
request for A is processed. After finishing the state for A's request is
merged back into the DRBG state. If now thread B requests random numbers
from the same DRBG after the request for thread A is received, but
before A's shadow state is merged back, the random numbers for B will be
identical to the ones for A. Please note that the time window is very
small for this scenario.
To prevent that there is even a theoretical chance for thread A and B
having the same DRBG state, the current time stamp is provided as
additional information string for each new request.
The addition of the time stamp as additional information string implies
that now all generate functions must be capable to process a linked
list with additional information strings instead of a scalar.
CC: Rafael Aquini
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 59 ++-
include/crypto/drbg.h | 2 +-
2 files changed, 36 insertions(+), 25 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 2a7860f..a76b3cb 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -646,7 +646,7 @@ out:
/* Generate function of CTR DRBG as defined in 10.2.1.5.2 */
static int drbg_ctr_generate(struct drbg_state *drbg,
unsigned char *buf, unsigned int buflen,
-struct drbg_string *addtl)
+struct list_head *addtl)
{
int len = 0;
int ret = 0;
@@ -656,11 +656,8 @@ static int drbg_ctr_generate(struct drbg_state *drbg,
memset(drbg->scratchpad, 0, drbg_blocklen(drbg));
/* 10.2.1.5.2 step 2 */
- if (addtl && 0 < addtl->len) {
- LIST_HEAD(addtllist);
-
- list_add_tail(>list, );
- ret = drbg_ctr_update(drbg, , 2);
+ if (addtl && !list_empty(addtl)) {
+ ret = drbg_ctr_update(drbg, addtl, 2);
if (ret)
return 0;
}
@@ -777,7 +774,7 @@ static int drbg_hmac_update(struct drbg_state *drbg, struct
list_head *seed,
static int drbg_hmac_generate(struct drbg_state *drbg,
unsigned char *buf,
unsigned int buflen,
- struct drbg_string *addtl)
+ struct list_head *addtl)
{
int len = 0;
int ret = 0;
@@ -785,11 +782,8 @@ static int drbg_hmac_generate(struct drbg_state *drbg,
LIST_HEAD(datalist);
/* 10.1.2.5 step 2 */
- if (addtl && 0 < addtl->len) {
- LIST_HEAD(addtllist);
-
- list_add_tail(>list, );
- ret = drbg_hmac_update(drbg, , 1);
+ if (addtl && !list_empty(addtl)) {
+ ret = drbg_hmac_update(drbg, addtl, 1);
if (ret)
return ret;
}
@@ -813,14 +807,10 @@ static int drbg_hmac_generate(struct drbg_state *drbg,
}
/* 10.1.2.5 step 6 */
- if (addtl && 0 < addtl->len) {
- LIST_HEAD(addtllist);
-
- list_add_tail(>list, );
- ret = drbg_hmac_update(drbg, , 1);
- } else {
+ if (addtl && !list_empty(addtl))
+ ret = drbg_hmac_update(drbg, addtl, 1);
+ else
ret = drbg_hmac_update(drbg, NULL, 1);
- }
if (ret)
return ret;
@@ -944,7 +934,7 @@ out:
/* processing of additional information string for Hash DRBG */
static int drbg_hash_process_addtl(struct drbg_state *drbg,
- struct drbg_string *addtl)
+ struct list_head *addtl)
{
int ret = 0;
struct drbg_string data1, data2;
@@ -955,7 +945,7 @@ static int drbg_hash_process_addtl(struct drbg_state *drbg,
memset(drbg->scratchpad, 0, drbg_blocklen(drbg));
/* 10.1.1.4 step 2 */
- if (!addtl || 0 == addtl->len)
+ if (!addtl || list_empty(addtl))
return 0;
/* 10.1.1.4 step 2a */
@@ -963,7 +953,7 @@ static int drbg_hash_process_addtl(struct drbg_state *drbg,
drbg_string_fill(, drbg->V, drbg_statelen(drbg));
list_add_tail(, );
list_add_tail(, );
- list_add_tail(>list, );
+ list_splice_tail(addtl, );
ret = drbg_kcapi_hash(drbg, NULL, drbg->scratchpad, );
if (ret)
goto out;
@@ -1029,7 +1019,7 @@ out:
/* generate function for Hash DRBG as defined in 10.1.1.4 */
static int drbg_hash_generate(struct drbg_state *drbg,
unsigned char *buf, unsigned int buflen,
- struct drbg_string *addtl)
+ struct
[PATCH 6/6] DRBG: HMAC-SHA1 DRBG has crypto strength of 128 bits
The patch corrects the security strength of the HMAC-SHA1 DRBG to 128
bits. This strength defines the size of the seed required for the DRBG.
Thus, the patch lowers the seeding requirement from 256 bits to 128 bits
for HMAC-SHA1.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index a76b3cb..84478cb 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -184,7 +184,7 @@ static const struct drbg_core drbg_cores[] = {
#endif /* CONFIG_CRYPTO_DRBG_HASH */
#ifdef CONFIG_CRYPTO_DRBG_HMAC
{
- .flags = DRBG_HMAC | DRBG_STRENGTH256,
+ .flags = DRBG_HMAC | DRBG_STRENGTH128,
.statelen = 20, /* block length of cipher */
.max_addtllen = 35,
.max_bits = 19,
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy
On Wed, 25 Jun 2014, Kishon Vijay Abraham I wrote: > Added hwmod data for pcie1 and pcie2 phy present in DRA7xx SOC. > Also added the missing CLKCTRL OFFSET macro and CONTEXT OFFSET macro > for pcie1 phy and pcie2 phy. > > Cc: Tony Lindgren > Cc: Russell King > Cc: Paul Walmsley > Signed-off-by: Kishon Vijay Abraham I > Tested-by: Kishon Vijay Abraham I Thanks, queued for v3.17 with Rajendra's ack. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] ARM: DRA7: hwmod: Add OCP2SCP3 module
Hi On Fri, 4 Jul 2014, Roger Quadros wrote: > On 07/03/2014 10:48 PM, Paul Walmsley wrote: > > On Thu, 3 Jul 2014, Roger Quadros wrote: > > > >> This module is needed for the SATA and PCIe PHYs. > >> > >> Signed-off-by: Roger Quadros > >> Reviewed-by: Rajendra Nayak > >> Tested-by: Sekhar Nori > > > > > This looks like adding support for a new device, so, after > > discussing with Tony, queuing for v3.17. > > We should treat it as missing device (bug) rather than new device > (feature) as the corresponding device tree node is already present. > Without this patch we get the following message in kernel boot log > > [0.261680] platform 4a09.ocp2scp: Cannot lookup hwmod 'ocp2scp3' > > I would consider this patch as a fix rather than a new feature. Just to make sure I'm correctly applying the rules for sequencing -rc patches vs. merge window patches, could you please confirm my understanding of the situation: 1. The OCP2SCP3 device (and the devices that rely on it) never worked on DRA7xx in earlier kernels 2. Even with this support added, neither SATA nor PCIe will work in 3.16 on DRA7xx (SATA for unknown reasons, PCIe because the patches are targeted for 3.17). 3. The warning doesn't prevent the machine from booting and does not impair any previously working functionality 4. There are other DRA7xx warning messages on boot in 3.16-rc: for example, http://paste.ubuntu.com/7701601/ lists: [0.009931] omap_hwmod: l3_main_2 using broken dt data from ocp ... [0.291802] platform 4e00.dmm: Cannot lookup hwmod 'dmm' Are these four statements correct? If so, is there some other reason why we should rush this in for 3.16-rc? Put differently: how can we justify adding this device in 3.16-rc rather than 3.17 to Linus Torvalds? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MIPS: Remove incorrect NULL check in local_flush_tlb_page()
We check that the struct vm_area_struct pointer vma is NULL and then
dereference it a few lines below. The intent was to make sure vma is
not NULL but this is not necessary since the bug pre-dates GIT history
and seem to never have caused a problem. The tlb-4k and tlb-8k versions
of local_flush_tlb_page() don't bother checking if vma is NULL, also
vma is dereferenced before being passed to local_flush_tlb_page(),
thus it is safe to remove this NULL check.
Signed-off-by: Emil Goode
---
arch/mips/mm/tlb-r3k.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/mm/tlb-r3k.c b/arch/mips/mm/tlb-r3k.c
index d657493..4094bbd 100644
--- a/arch/mips/mm/tlb-r3k.c
+++ b/arch/mips/mm/tlb-r3k.c
@@ -158,7 +158,7 @@ void local_flush_tlb_page(struct vm_area_struct *vma,
unsigned long page)
{
int cpu = smp_processor_id();
- if (!vma || cpu_context(cpu, vma->vm_mm) != 0) {
+ if (cpu_context(cpu, vma->vm_mm) != 0) {
unsigned long flags;
int oldpid, newpid, idx;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] MIPS: Fix incorrect NULL check in local_flush_tlb_page()
Hello,
On Sat, Jul 05, 2014 at 09:10:44PM +0200, Jonas Gorski wrote:
> On Sat, Jul 5, 2014 at 8:26 PM, Emil Goode wrote:
> > We check that the struct vm_area_struct pointer vma is NULL and then
> > dereference it a few lines below. The intent must have been to make sure
> > that vma is not NULL and then to check the value from cpu_context() for
> > the condition to be true.
> >
> > Signed-off-by: Emil Goode
> > ---
> >
> > v2: Updated the commit message with a better explanation.
> >
> > arch/mips/mm/tlb-r3k.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/mips/mm/tlb-r3k.c b/arch/mips/mm/tlb-r3k.c
> > index d657493..6546758 100644
> > --- a/arch/mips/mm/tlb-r3k.c
> > +++ b/arch/mips/mm/tlb-r3k.c
> > @@ -158,7 +158,7 @@ void local_flush_tlb_page(struct vm_area_struct *vma,
> > unsigned long page)
> > {
> > int cpu = smp_processor_id();
> >
> > - if (!vma || cpu_context(cpu, vma->vm_mm) != 0) {
> > + if (vma && cpu_context(cpu, vma->vm_mm) != 0) {
>
> Sorry for replying "too late", but grepping through the kernel code I
> fail to find any caller that does not dereference vma before calling
> (local)flush_tlb_page(). Also both tlb-4k and tlb-8k assume vma cannot
> be NULL, so I would say it is safe to assume vma is never NULL, and
> the NULL check can be removed completely.
>
> Also it looks like this "bug" was there since at least 2.6.12, and
> never seem to have bitten anyone.
Yes, the bug pre-dates GIT history and I agree that it is most unlikely
that it ever caused a problem. I will send a new patch that removes the
NULL check of vma.
Best regards,
Emil Goode
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH block/for-linus] blkcg: don't call into policy draining if root_blkg is already gone
While a queue is being destroyed, all the blkgs are destroyed and its
->root_blkg pointer is set to NULL. If someone else starts to drain
while the queue is in this state, the following oops happens.
NULL pointer dereference at 0028
IP: [] blk_throtl_drain+0x84/0x230
PGD e4a1067 PUD b773067 PMD 0
Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: cfq_iosched(-) [last unloaded: cfq_iosched]
CPU: 1 PID: 537 Comm: bash Not tainted 3.16.0-rc3-work+ #2
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: 88000e50 ti: 88000efd4000 task.ti: 88000efd4000
RIP: 0010:[] []
blk_throtl_drain+0x84/0x230
RSP: 0018:88000efd7bf0 EFLAGS: 00010046
RAX: RBX: 880015091450 RCX: 0001
RDX: RSI: RDI:
RBP: 88000efd7c10 R08: R09: 0001
R10: 88000e50 R11: R12: 880015091450
R13: 880015092e00 R14: 880015091d70 R15: 88001508fc28
FS: 7f1332650740() GS:88001fa8() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0028 CR3: 09446000 CR4: 06e0
Stack:
8144e8f6 880015091450 880015091d80
88000efd7c28 8144ae2f 880015091450 88000efd7c58
81427641 880015091450 82401f00 880015091450
Call Trace:
[] blkcg_drain_queue+0x1f/0x60
[] __blk_drain_queue+0x71/0x180
[] blk_queue_bypass_start+0x6e/0xb0
[] blkcg_deactivate_policy+0x38/0x120
[] blk_throtl_exit+0x34/0x50
[] blkcg_exit_queue+0x35/0x40
[] blk_release_queue+0x26/0xd0
[] kobject_cleanup+0x38/0x70
[] kobject_put+0x28/0x60
[] blk_put_queue+0x15/0x20
[] scsi_device_dev_release_usercontext+0x16b/0x1c0
[] execute_in_process_context+0x89/0xa0
[] scsi_device_dev_release+0x1c/0x20
[] device_release+0x32/0xa0
[] kobject_cleanup+0x38/0x70
[] kobject_put+0x28/0x60
[] put_device+0x17/0x20
[] __scsi_remove_device+0xa9/0xe0
[] scsi_remove_device+0x2b/0x40
[] sdev_store_delete+0x27/0x30
[] dev_attr_store+0x18/0x30
[] sysfs_kf_write+0x3e/0x50
[] kernfs_fop_write+0xe7/0x170
[] vfs_write+0xaf/0x1d0
[] SyS_write+0x4d/0xc0
[] system_call_fastpath+0x16/0x1b
776687bce42b ("block, blk-mq: draining can't be skipped even if
bypass_depth was non-zero") made it easier to trigger this bug by
making blk_queue_bypass_start() drain even when it loses the first
bypass test to blk_cleanup_queue(); however, the bug has always been
there even before the commit as blk_queue_bypass_start() could race
against queue destruction, win the initial bypass test but perform the
actual draining after blk_cleanup_queue() already destroyed all blkgs.
Fix it by skippping calling into policy draining if all the blkgs are
already gone.
Signed-off-by: Tejun Heo
Reported-by: Shirish Pargaonkar
Reported-by: Sasha Levin
Reported-by: Jet Chen
Cc: sta...@vger.kernel.org
---
block/blk-cgroup.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index b9f4cc4..28d227c 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -872,6 +872,13 @@ void blkcg_drain_queue(struct request_queue *q)
{
lockdep_assert_held(q->queue_lock);
+ /*
+* @q could be exiting and already have destroyed all blkgs as
+* indicated by NULL root_blkg. If so, don't confuse policies.
+*/
+ if (!q->root_blkg)
+ return;
+
blk_throtl_drain(q);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm fixes
Hi Linus, i915, tda998x and vmwgfx fixes, the main one is i915 fix for missing VGA connectors, along with some fixes for the tda998x from Russell fixing some modesetting problems. (still on holidays, but got a spare moment to find these). Dave. The following changes since commit e1a08b855f56d6528e7f85aae9ca8123f4c3ae04: Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux (2014-07-05 10:12:52 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to dfd7aecfd6d227831d77719379d4c7137f444fee: Merge tag 'drm-intel-fixes-2014-07-03' of git://anongit.freedesktop.org/drm-intel (2014-07-06 07:49:59 +1000) Dave Airlie (3): Merge branch 'tda998x-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox Merge branch 'vmwgfx-fixes-3.16' of git://people.freedesktop.org/~thomash/linux Merge tag 'drm-intel-fixes-2014-07-03' of git://anongit.freedesktop.org/drm-intel Deepak S (1): drm/i915: Drop early VLV WA to fix Voltage not getting dropped to Vmin Guido Martínez (1): drm/i2c: tda998x: move drm_i2c_encoder_destroy call Jesse Barnes (1): drm/i915: only apply crt_present check on VLV Russell King (2): drm/i2c: tda998x: faster polling for edid drm/i2c: tda998x: add some basic mode validation Thomas Hellstrom (1): drm/vmwgfx: Fix incorrect write to read-only register v2: Ville Syrjälä (1): drm/i915: Wait for vblank after enabling the primary plane on BDW drivers/gpu/drm/i2c/tda998x_drv.c| 12 +--- drivers/gpu/drm/i915/intel_display.c | 27 ++- drivers/gpu/drm/i915/intel_pm.c | 8 drivers/gpu/drm/i915/intel_sprite.c | 8 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 1 - 5 files changed, 51 insertions(+), 5 deletions(-)
Re: [PATCH RFC net-next 03/14] bpf: introduce syscall(BPF, ...) and BPF maps
On Fri, Jul 4, 2014 at 8:17 AM, Andy Lutomirski wrote: > On Wed, Jul 2, 2014 at 7:29 PM, Alexei Starovoitov wrote: >> >> non-root API: >> >> ufd = bpf_create_map(local_map_id,… ) >> bpf_map_update/delete/lookup_elem(ufd,…) >> ufd = bpf_prog_load(insns) >> close(ufd) >> >> root only API: >> >> global_id = bpf_get_id(ufd) // returns either map or prog global id >> bpf_map_delete(global_map_id) >> bpf_prog_unload(global_prog_id) >> >> Details: >> >> ufd = bpf_create_map(local_map_id, ...); >> >> local_map_id - process local map_id >> (this id is used to access maps from eBPF program loaded by this process) >> >> ufd - process local file descriptor >> (used to update/lookup maps from this process) >> >> global_map_id = bpf_get_id(ufd) >> this is root only call to get global_ids and pass them to global events >> like tracing. >> >> global ids will only be seen by root. There is no way for root or non-root >> to influence id ranges. >> >> I think it will be cleaner once I finish fd conversion as a patch. > > OK > > FWIW, per-process local id maps sound almost equivalent to relocations > -- the latter could be as simple as an extra nlattr giving a list of > pairs of (per-eBPF-program id, fd). I thought about array of such pairs as well, but it felt cleaner to remember the (per-eBPF-program id, fd) pair in a kernel, instead of asking user space to keep track of them. Either way I think it's minor. I'll implement both and see which way is cleaner. So far I did 3-way enum split in verifier and addressed Namhyung's and Chema's comments. Updated in the same place: git://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf master I'll be traveling next week. Once I'm done with fd-style interface, I'll post a v2. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI: Add bridge DMA alias quirk for Intel 82801
On Sat, Jul 05, 2014 at 03:26:29PM -0600, Bjorn Helgaas wrote: > I saw that Joerg applied those iommu changes to his core branch, which I > assume will be merged for v3.17. So I'll move this to a pci/iommu branch, > to be merged during the v3.17 merge window. Yes, these changes are queued for v3.17. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/59] 3.14.11-stable review
At Sat, 5 Jul 2014 12:10:58 -0700, Greg Kroah-Hartman wrote: > > On Sat, Jul 05, 2014 at 02:56:55PM +0200, Takashi Iwai wrote: > > At Sat, 05 Jul 2014 18:21:04 +0900, > > Satoru Takeuchi wrote: > > > > > > Hi Greg, > > > > > > Add Takashi Iwai to this thread. > > > > > > At Sat, 05 Jul 2014 16:00:41 +0900, > > > Satoru Takeuchi wrote: > > > > > > > > At Fri, 04 Jul 2014 22:45:42 -0700, > > > > Guenter Roeck wrote: > > > > > > > > > > On 07/04/2014 03:18 PM, Greg Kroah-Hartman wrote: > > > > > > This is the start of the stable review cycle for the 3.14.11 > > > > > > release. > > > > > > There are 59 patches in this series, all will be posted as a > > > > > > response > > > > > > to this one. If anyone has any issues with these being applied, > > > > > > please > > > > > > let me know. > > > > > > > > > > > > Responses should be made by Sun Jul 6 22:15:27 UTC 2014. > > > > > > Anything received after that time might be too late. > > > > > > > > > > > > > > > > Build results: > > > > > total: 144 pass: 130 skipped: 4 fail: 10 > > > > > Failed builds: > > > > > alpha:allmodconfig > > > > > i386:allyesconfig > > > > > i386:allmodconfig > > > > > powerpc:allmodconfig (binutils 2.23) > > > > > powerpc:allmodconfig (binutils 2.24) > > > > > sparc64:allmodconfig > > > > > unicore32:defconfig > > > > > x86_64:allyesconfig > > > > > x86_64:allmodconfig > > > > > xtensa:allmodconfig > > > > > > > > > > Qemu test for x86 failed. > > > > > > > > > > Build error is the same as seen with 3.14. > > > > > > > > > > sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': > > > > > sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of > > > > > function 'codec_dbg' [-Werror=implicit-function-declaration] > > > > > > > > This kernel failed to build with the following error. Probably the root > > > > cause is the same as Guenter. I'm now bisecting to find the problematic > > > > patch... > > > > > > The following patch caused the boot failure of both this kernel and > > > 3.10.47-rc1. > > > > > > alsa-hda-adjust-speaker-hpf-and-add-led-support-for-hp-spectre-13.patch: > > > === > > > From 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab Mon Sep 17 00:00:00 2001 > > > From: Takashi Iwai > > > Date: Tue, 24 Jun 2014 13:55:25 +0200 > > > Subject: ALSA: hda - Adjust speaker HPF and add LED support for HP > > > Spectre 13 > > > > > > From: Takashi Iwai > > > > > > commit 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab upstream. > > > > > > HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the > > > default high-pass filter in some "safer" range, which results in the > > > very soft tone from the built-in speakers in contrast to Windows. > > > Also, the mute LED control is missing, since 92HD95 codec still has no > > > HP-specific fixups for GPIO setups. > > > > > > This patch adds these missing features: the HPF is adjusted by the > > > vendor-specific verb, and the LED is set up from a DMI string (but > > > with the default polarity = 0 assumption due to the incomplete BIOS on > > > the given machine). > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841 > > > Signed-off-by: Takashi Iwai > > > Signed-off-by: Greg Kroah-Hartman > > > ... > > > === > > > > > > This patch uses codec_dbg(), however, this macro is intrdocuded by the > > > following patch and it's not applied to these stable-tree yet. > > > > > > === > > > ommit 4e76a8833fac8dc1735aa5be7d1b3c92c65e209e > > > Author: Takashi Iwai > > > Date: Tue Feb 25 12:21:03 2014 +0100 > > > > > > ALSA: hda - Replace with standard printk > > > > > > Use dev_err() and co for messages from HD-audio controller and codec > > > drivers. The codec drivers are mostly bound with codec objects, so > > > some helper macros, codec_err(), codec_info(), etc, are provided. > > > They merely wrap the corresponding dev_xxx(). > > > > > > There are a few places still calling snd_printk() and its variants > > > as they are called without the codec or device context. > > > > > > Signed-off-by: Takashi Iwai > > > ... > > > === > > > > > > Unfortunately I failed to apply this patch to 3.14.11-rc1 with the > > > following > > > error log. > > > > > > === > > > $ git apply ~/src/test-linux-stable/extra_patch.txt > > > error: patch failed: sound/pci/hda/hda_intel.c:897 > > > error: sound/pci/hda/hda_intel.c: patch does not apply > > > error: sound/pci/hda/hda_sysfs.c: No such file or directory > > >
Re: [PATCH] PCI: Add bridge DMA alias quirk for Intel 82801
[+cc Joerg] On Sat, Jul 05, 2014 at 10:31:43AM -0600, Bjorn Helgaas wrote: > On Mon, Jun 23, 2014 at 04:36:25PM -0600, Alex Williamson wrote: > > This bridge sometimes shows up as a root complex device and sometimes > > as a discrete PCIe-to-PCI bridge. Testing indicates that in the > > latter case, we need to enable the PCIe bridge DMA alias quirk. > > > > Signed-off-by: Alex Williamson > > Reported-by: Milos Kaurin > > Tested-by: Milos Kaurin > > Applied to for-linus for v3.16, thanks! Actually, this quirk doesn't make any difference until the iommu changes are in, so there's no reason to have this in v3.16, is there? I saw that Joerg applied those iommu changes to his core branch, which I assume will be merged for v3.17. So I'll move this to a pci/iommu branch, to be merged during the v3.17 merge window. > > --- > > > > drivers/pci/quirks.c |2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > > index 78a7df6..460c354 100644 > > --- a/drivers/pci/quirks.c > > +++ b/drivers/pci/quirks.c > > @@ -3405,6 +3405,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ASMEDIA, > > 0x1080, > > DECLARE_PCI_FIXUP_HEADER(0x10e3, 0x8113, quirk_use_pcie_bridge_dma_alias); > > /* ITE 8892, https://bugzilla.kernel.org/show_bug.cgi?id=73551 */ > > DECLARE_PCI_FIXUP_HEADER(0x1283, 0x8892, quirk_use_pcie_bridge_dma_alias); > > +/* Intel 82801, https://bugzilla.kernel.org/show_bug.cgi?id=44881#c49 */ > > +DECLARE_PCI_FIXUP_HEADER(0x8086, 0x244e, quirk_use_pcie_bridge_dma_alias); > > > > /* > > * AMD has indicated that the devices below do not support peer-to-peer > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: Emit a warning on file add/move/delete
On Fri, 2014-07-04 at 16:11 +0100, Andy Whitcroft wrote: > On Thu, Jul 03, 2014 at 05:46:56PM -0700, Joe Perches wrote: > > Whenever files are added, moved, or deleted, the > > MAINTAINERS file patterns can be out of sync or > > outdated. > > > > To try to keep MAINTAINERS more up-to-date, add a > > one-time warning whenever a patch does any of those. [] > That seems like a sensible plan. Sometime we might try and work out if > any entries are affected or needed. Hey again Andy. Just fyi: I think this is not possible. A patch series will often add or delete a file independently from an earlier or later patch that modifies MAINTAINERS. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kGraft to -next [was: 00/21 kGraft]
On Sat, Jul 05, 2014 at 11:06:28PM +0200, Jiri Kosina wrote: > On Sat, 5 Jul 2014, Tejun Heo wrote: > > > It'd be awesome if people who are working on the features can talk to > > each other and see whether things can be combined. > > Oh, I absolutely agree; trust me, we are trying to get as much discussion > going on as possible :) I proposed it as a Kernel Summit topic, and > hopefully work will be done at the mini-summit proposed by Steven at > Plumbers as well. Ah, that's awesome to hear. :) -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kGraft to -next [was: 00/21 kGraft]
On Sat, 5 Jul 2014, Tejun Heo wrote: > It'd be awesome if people who are working on the features can talk to > each other and see whether things can be combined. Oh, I absolutely agree; trust me, we are trying to get as much discussion going on as possible :) I proposed it as a Kernel Summit topic, and hopefully work will be done at the mini-summit proposed by Steven at Plumbers as well. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kGraft to -next [was: 00/21 kGraft]
Hello, On Sat, Jul 05, 2014 at 10:49:18PM +0200, Jiri Kosina wrote: > Quite frankly, I have to say that I don't personally see *that* big > difference. In both cases we are making assumptions about semantics, and > are trying to get "as close as possible" to the point in time where the > set of assumptions can be made as minimal as possible. > > With userspace thread, this is kernel/userspace boundary. With kthread, > this is starting of new iteration of the main loop / try_to_freeze(). This is really different. With kernel/userspace boundary, if the patch is correct, the mechanism, sans bugs, should be able to guarantee that the patched result is correct. With kthreads, it can't. The boundary between the old and new worlds might or might not be correct. How can they be the same? The fact that they may coincide often can be useful as a guideline or whatever but I'm completely against just mushing it together when it isn't correct. This kind of things quickly lead to ambiguous situations where people are not sure about the specific semantics or guarantees of the construct and implement weird voodoo code followed by voodoo fixes. We already had a full round of that with the kernel freezer itself, where people thought that the freezer magically makes PM work properly for a subsystem. Let's please not do that again. > > This is the mechanism itself being flaky and buggy. This can make > > things fail not because the patch itself is semantically wrong but > > because the mechanism stopped the kernel at the wrong place. > > Well, to be precise, we are not "stopping" the kernel at all. Sure, whatever the term is, this is the boundary that the mechanism considers it safe to swap the code, right? User/kernel boundary should be able to serve that purpose. Freezing points can't. > > If kthread can't be safely supported now, that's fine but then make it > > clear that functions which may be executed by kthreads aren't supported. > > So one of the aproaches implied by this would be first merging a light > version of kGraft which doesn't support kthreads, and working towards a > solution for kthreads as well (which might be tangential to kGraft; if > most of the kthreads get converted to workqueues, it's a win-win > situation anyway); would such kGraft-light get your Ack then? :) Yes, I think that converting things over to workqueue or kthread_worker is generally a good idea but I'm not sure I'm in the position to ack or nack kgraft as a whole. I am not too sure about the capability itself (neither positive or negative) and it'd take quite a bit of energy to scrutinize and compare all the alternatives. It'd be awesome if people who are working on the features can talk to each other and see whether things can be combined. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.16rc3 multiplatform, Armada 370 and IOMMU: unbootable kernel
On Sat, Jul 05, 2014 at 12:03:08PM -0300, Ezequiel Garcia wrote: > After following Gregory's stacktrace (also reproduced here): > > [] (iommu_bus_notifier) from [] > (notifier_call_chain+0x64/0x9c) > [] (notifier_call_chain) from [] > (__blocking_notifier_call_chain+0x40/0x58) > [] (__blocking_notifier_call_chain) from [] > (blocking_notifier_call_chain+0x14/0x1c) > [] (blocking_notifier_call_chain) from [] > (device_add+0x424/0x524) > [] (device_add) from [] (pci_device_add+0xec/0x110) > [] (pci_device_add) from [] > (pci_scan_single_device+0xa0/0xac) > > I added a few printks and found that the problem is that the > iommu_bus_notifier is > called for the 'pci' bus type, which has a null iommu_ops. > > On 04 Jul 10:47 AM, Laurent Pinchart wrote: > [..] > > > > We need a quick fix for v3.16, ... > > Therefore, a quick fix would be to simply check for that: > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index efc..b712cb2 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -536,6 +536,9 @@ static int iommu_bus_notifier(struct notifier_block *nb, > struct iommu_group *group; > unsigned long group_action = 0; > > + if (!ops) > + return 0; > + > /* > * ADD/DEL call into iommu driver ops if provided, which may > * result in ADD/DEL notifiers to group->notifier > > This (nasty workaround?) patch makes the problem go away. > > [..] > > > So it also boot well in 3.15 and then failed in 3.16-rc3. I hope it will > > > help the developers of the OMAP IOMMU driver to fix it. > > > > Thank you. I've had a look at the OMAP IOMMU driver changes between v3.15 > > and > > v3.16-rc3, and didn't find at first sight any change that could explain the > > crash. > > > > 286f600 iommu/omap: Fix map protection value handling > > 67b779d iommu/omap: Remove comment about supporting single page mappings > > only > > f7129a0 iommu/omap: Fix 'no page for' debug message in flush_iotlb_page() > > 5acc97d iommu/omap: Move to_iommu definition from omap-iopgtable.h > > 2ac6133 iommu/omap: Remove omap_iommu_domain_has_cap() function > > d760e3e iommu/omap: Correct init value of iotlb_entry valid field > > > > Could you try reverting those changes and retest ? If the problem doesn't > > disappear, we'll need to look somewhere else. > > > > I reverted the above commits but nothing changed. I'm far from being an > expert, > but it sounds odd to have this bus notifier (that got registered for the > platform bus type) called by a pci bus type. Why wouldn't the PCI bus set this up for its devices? Are you "assuming" you know the bus type and that's the issue? I see the a number of different places this is being initialized for the pci bus. Ah, look at drivers/iommu/fsl_pamu_domain.c, odds are, it shouldn't be doing that logic in the pamu_domain_init() code, using the same bus ops for different bus types, that's ripe for major problems... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 REBASED 06/10] serial/arc: remove last remanants of platform data
On Tue, Jun 24, 2014 at 11:38 PM, Vineet Gupta wrote: > On Wednesday 25 June 2014 02:31 AM, Rob Herring wrote: >> On Tue, Jun 24, 2014 at 3:25 AM, Vineet Gupta >> wrote: >>> Signed-off-by: Vineet Gupta >>> --- >>> drivers/tty/serial/arc_uart.c | 22 ++ >>> 1 file changed, 6 insertions(+), 16 deletions(-) >>> >>> diff --git a/drivers/tty/serial/arc_uart.c b/drivers/tty/serial/arc_uart.c >>> index 2ffaf099691a..dc3d5db37dc4 100644 >>> --- a/drivers/tty/serial/arc_uart.c >>> +++ b/drivers/tty/serial/arc_uart.c >> >>> @@ -518,21 +516,13 @@ arc_uart_init_one(struct platform_device *pdev, int >>> dev_id) >>> } >>> uart->baud = val; >>> >>> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> - if (!res) >>> - return -ENODEV; >>> - >>> - res2 = platform_get_resource(pdev, IORESOURCE_IRQ, 0); >>> - if (!res2) >>> - return -ENODEV; >>> - >>> - port->mapbase = res->start; >>> - port->membase = ioremap_nocache(res->start, resource_size(res)); >>> + port->membase = of_iomap(np, 0); >> ioremap is preferred over of_iomap as it is not OF specific. > > I could, but much of the driver assumes OF to be selected already > (of_property...) > >> Perhaps >> use devm_request_and_ioremap instead. > > devm_request_and_ioremap has been flag day removed in favour of > devm_ioremap_resource(). > However even then it would require me to retain the prior > platform_get_resource() > call. > IMHO, of_iomap is must more concise. Perhaps, but it is preferred to limit the OF specific parts of drivers. It is maybe not important for this driver, but in cases where there is a need to support multiple bindings such as DT and ACPI it is important. >>> if (!port->membase) >>> /* No point of dev_err since UART itself is hosed here */ >>> return -ENXIO; >>> >>> - port->irq = res2->start; >>> + port->irq = irq_of_parse_and_map(np, 0); >>> + >> platform_get_irq should be used here. > > And this again is for reducing OF dependency or is it something else. We may eventually stop populating the irqs in resources for DT. The irqs are now translated at probe time to deal with probe ordering issues. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] include/uapi: Define AT_FDNODIR constant as future guarantee
From: Steven Stewart-Gallus --- This is my first kernel patch but this is really trivial so I hope I'm doing this right. diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h index 074b886..92223f0 100644 --- a/include/uapi/linux/fcntl.h +++ b/include/uapi/linux/fcntl.h @@ -38,9 +38,15 @@ #define DN_ATTRIB 0x0020 /* File changed attibutes */ #define DN_MULTISHOT 0x8000 /* Don't remove notifier */ +#define AT_FDNODDIR-1 /* Special value used to indicate + openat should not use any directory. + Currently, other values work for this + but in the future that might + change. */ #define AT_FDCWD -100/* Special value used to indicate - openat should use the current - working directory. */ + openat should use the current + working directory. */ + #define AT_SYMLINK_NOFOLLOW0x100 /* Do not follow symbolic links. */ #define AT_REMOVEDIR 0x200 /* Remove directory instead of unlinking file. */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kGraft to -next [was: 00/21 kGraft]
On Sat, 5 Jul 2014, Tejun Heo wrote: > > What we need is to have a defined point in execution where we can draw a > > line between "old" and "new" universes. For processess that are crossing > > the userspace/kernelspace boundary, the obvious choice, that covers most > > of the use-cases, has been made. There are still scenarios where this > > aproach can't be just-blindly-applied(TM) for various reasons (changing > > lock order might cause deadlocks, there are cases where state is lingering > > Sure, if something breaks work due to semantic differences, there > isn't anything we can do. [ ... ] > > The same holds for the kernel threads -- until all (or most of) the > > kthreads are converted to workqueues, the obivous choice, that should > > cover most of the use-cases, has been made. > > But, this is different. Quite frankly, I have to say that I don't personally see *that* big difference. In both cases we are making assumptions about semantics, and are trying to get "as close as possible" to the point in time where the set of assumptions can be made as minimal as possible. With userspace thread, this is kernel/userspace boundary. With kthread, this is starting of new iteration of the main loop / try_to_freeze(). We were not able to come up with anything better. Alan, you were stating "I don't see why it can't use the kernel freeze functionality?". What exactly was your suggestion, if not this, please? > This is the mechanism itself being flaky and buggy. This can make > things fail not because the patch itself is semantically wrong but > because the mechanism stopped the kernel at the wrong place. Well, to be precise, we are not "stopping" the kernel at all. > If kthread can't be safely supported now, that's fine but then make it > clear that functions which may be executed by kthreads aren't supported. So one of the aproaches implied by this would be first merging a light version of kGraft which doesn't support kthreads, and working towards a solution for kthreads as well (which might be tangential to kGraft; if most of the kthreads get converted to workqueues, it's a win-win situation anyway); would such kGraft-light get your Ack then? :) Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 4/9] pci: OF: Fix the conversion of IO ranges into IO resources.
On Saturday 05 July 2014 14:25:52 Rob Herring wrote: > On Tue, Jul 1, 2014 at 1:43 PM, Liviu Dudau wrote: > > The ranges property for a host bridge controller in DT describes > > the mapping between the PCI bus address and the CPU physical address. > > The resources framework however expects that the IO resources start > > at a pseudo "port" address 0 (zero) and have a maximum size of > > IO_SPACE_LIMIT. > > The conversion from pci ranges to resources failed to take that into > > account. > > I don't think this change is right. There are 2 resources: the PCI bus > addresses and cpu addresses. This function deals with the cpu > addresses. Returning pci addresses for i/o and cpu addresses for > memory is going to be error prone. We probably need both cpu and pci > resources exposed to host controllers. > > Making the new function only deal with i/o bus resources and naming it > of_pci_range_to_io_resource would be better. I think you are correct that this change by itself is will break existing drivers that rely on the current behavior of of_pci_range_to_resource, but there is also something wrong with the existing implementation: of_pci_range_to_resource() at the moment returns a the address in cpu address space (i.e. IORESOURCE_MEM) but sets the res->flags value to IORESOURCE_IO, which means it doesn't fit into the resource tree. Liviu's version gets that part right, and it would be nice to fix that eventually, however we do it here. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vsprintf: Remove SPECIAL from pointer types
Because gcc issues a complaint about any pointer format with %#p,
remove the use of SPECIAL to prefix 0x to various pointer types.
There are no uses in the kernel tree of %#p.
This removes the capability added by commit 725fe002d315
("vsprintf: correctly handle width when '#' flag used in %#p format").
There are some incidental message logging output changes of %pa
uses with this change. None are in seq output so there are no
api changes.
Signed-off-by: Joe Perches
---
Fine by me, here...
On Sat, 2014-07-05 at 21:25 +0100, Maciej W. Rozycki wrote:
> On Sat, 5 Jul 2014, Joe Perches wrote:
>
> > > > I don't think %#p is valid so it
> > > > shouldn't have been set by #.
> > >
> > > Huh? As recently as last Wednesday you pointed me at the specific
> > > commit
> > > from Grant that made it valid (GCC format complaints aside).
> >
> > Those gcc complaints are precisely the thing
> > that makes it invalid.
>
> So enforce that in code then, clear the SPECIAL flag where appropriate
> and do not try to handle it in one place while leaving other ones to
> behave randomly (i.e. a supposedly fixed field width varies depending on
> the two uppermost digits). Please note that it's only your proposed
> change that introduces that randomness, right now code does what's
> supposed and documented to, except a bit inconsistently.
>
> > I believe you're tilting at windmills.
> >
> > Hey, it works sometimes. Knock yourself out.
>
> I pointed out an inconsistency with the intent to propose a fix once a
> consensus have been reached, one way or another. And I think shifting the
> inconsistency to a different place, which is what your proposal does,
> isn't really a complete solution, although I do recognise the improvement.
lib/vsprintf.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 6fe2c84..1cad65b 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -632,7 +632,7 @@ char *symbol_string(char *buf, char *end, void *ptr,
return string(buf, end, sym, spec);
#else
spec.field_width = 2 * sizeof(void *);
- spec.flags |= SPECIAL | SMALL | ZEROPAD;
+ spec.flags |= SMALL | ZEROPAD;
spec.base = 16;
return number(buf, end, value, spec);
@@ -1165,18 +1165,18 @@ char *address_val(char *buf, char *end, const void
*addr,
{
unsigned long long num;
- spec.flags |= SPECIAL | SMALL | ZEROPAD;
+ spec.flags |= SMALL | ZEROPAD;
spec.base = 16;
switch (fmt[1]) {
case 'd':
num = *(const dma_addr_t *)addr;
- spec.field_width = sizeof(dma_addr_t) * 2 + 2;
+ spec.field_width = sizeof(dma_addr_t) * 2;
break;
case 'p':
default:
num = *(const phys_addr_t *)addr;
- spec.field_width = sizeof(phys_addr_t) * 2 + 2;
+ spec.field_width = sizeof(phys_addr_t) * 2;
break;
}
@@ -1259,7 +1259,7 @@ static noinline_for_stack
char *pointer(const char *fmt, char *buf, char *end, void *ptr,
struct printf_spec spec)
{
- int default_width = 2 * sizeof(void *) + (spec.flags & SPECIAL ? 2 : 0);
+ int default_width = 2 * sizeof(void *);
if (!ptr && *fmt != 'K') {
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Filesystem lockup with CONFIG_PREEMPT_RT
On Wed, 21 May 2014, John Blackwood wrote: > I'm not 100% sure that the patch below will fix your problem, but we > saw something that sounds pretty familiar to your issue involving the > nvidia driver and the preempt-rt patch. The nvidia driver uses the > completion support to create their own driver's notion of an internally > used semaphore. And why should we care about that? If they abuse the completion code then it's their problem. And it has nothing to do at all with the problem Austin is observing. > Some tasks were failing to ever wakeup from wait_for_completion() calls > due to a race in the underlying do_wait_for_common() routine. Why are you not fixing the nvidia crap instead of hacking utter shite into the core kernel? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kGraft to -next [was: 00/21 kGraft]
Hello, On Sat, Jul 05, 2014 at 10:04:52PM +0200, Jiri Kosina wrote: > What we need is to have a defined point in execution where we can draw a > line between "old" and "new" universes. For processess that are crossing > the userspace/kernelspace boundary, the obvious choice, that covers most > of the use-cases, has been made. There are still scenarios where this > aproach can't be just-blindly-applied(TM) for various reasons (changing > lock order might cause deadlocks, there are cases where state is lingering Sure, if something breaks work due to semantic differences, there isn't anything we can do. > between two user <-> kernel transitions, etc). So we'll need to provide > guidelines for kGraft patch writers anyway. > > The same holds for the kernel threads -- until all (or most of) the > kthreads are converted to workqueues, the obivous choice, that should > cover most of the use-cases, has been made. But, this is different. This is the mechanism itself being flaky and buggy. This can make things fail not because the patch itself is semantically wrong but because the mechanism stopped the kernel at the wrong place. The mechanism is simply broken and it might as well declare that patching whatever kthreads are running isn't supported. > But manual/human inspection is absolutely unavoidably necessary in any > case. This is extremely tricky to inspect and likely to just work in most, but not all, cases when it goes wrong just out of sheer luck. > Please keep in mind that this is designed for fixes that need immediate > response (getting bounds checking right, adding an extra check, adding a > missing lock, etc -- please see my previous mail on this topic in the old > thread). It's absolutely by design not intended for implementing whole new > features or exchanging the whole kernel on the fly; there are other > solutions for that (such as the criu-based thing). As such, we tend to > interfere with the rest of the kernel as little as possible, but it > inadverently brings drawbacks in the form of putting burden of more work > to the actual kGraft patch writers. I don't see that as a bad thing. I'm not saying this must be able to do everything but it shouldn't be voodoo either. Freezer points *can* coincide with what kgraft requires but it may not too. Why claim that freezing points are safe as stopping points when they aren't? That doesn't make any sense to me. If kthread can't be safely supported now, that's fine but then make it clear that functions which may be executed by kthreads aren't supported. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] staging: nvec: fix some coding style problems
The following patches fix some warnings reported by checkpatch.pl Pawel Lebioda (2): staging: nvec: remove unnecessary 'else' after 'return' statement staging: nvec: remove unneccessary 'out of memory' message drivers/staging/nvec/nvec.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging: nvec: remove unnecessary 'else' after 'return' statement
Fix the following warning reported by checkpatch.pl: WARNING: else is not generally useful after a break or return 235: FILE: drivers/staging/nvec/nvec.c:235 Signed-off-by: Pawel Lebioda --- drivers/staging/nvec/nvec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c index 90f1c4d..8a3dd47 100644 --- a/drivers/staging/nvec/nvec.c +++ b/drivers/staging/nvec/nvec.c @@ -232,8 +232,7 @@ static size_t nvec_msg_size(struct nvec_msg *msg) return 2; else if (event_length == NVEC_3BYTES) return 3; - else - return 0; + return 0; } /** -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] staging: nvec: remove unneccessary 'out of memory' message
Fix the following warning reported by checkpatch.pl:
WARNING: Possible unnecessary 'out of memory' message
811: FILE: drivers/staging/nvec/nvec.c:811
Signed-off-by: Pawel Lebioda
---
drivers/staging/nvec/nvec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 8a3dd47..d325048 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -806,10 +806,9 @@ static int tegra_nvec_probe(struct platform_device *pdev)
}
nvec = devm_kzalloc(>dev, sizeof(struct nvec_chip), GFP_KERNEL);
- if (nvec == NULL) {
- dev_err(>dev, "failed to reserve memory\n");
+ if (nvec == NULL)
return -ENOMEM;
- }
+
platform_set_drvdata(pdev, nvec);
nvec->dev = >dev;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] appletalk: Set skb with destructor
On Sat, Jul 05, 2014 at 07:28:14AM +0300, Andrey Utkin wrote:
> See https://bugzilla.kernel.org/show_bug.cgi?id=79441
> ---8<---
> Made changes similar to 0ae89beb283a0db5980d1d4781c7d7be2f2810d6
>
Thanks for fixing this bug but the patch description is just a URL and a
git hash. Say something like:
The sock ref counting is off so there is a kernel panic when you run
`atalkd`. See https://bugzilla.kernel.org/show_bug.cgi?id=79441
This fix is similar to 0ae89beb283a ('can: add destructor for self
generated skbs')
--
Putting a little information directly in the changelog that it is about
refcounting and panics is a useful thing.
Also you need to send this to net...@vger.kernel.org and CC
"David S. Miller" . Otherwise the patch looks good
to my non-expert eye. Please resend to with the updated changelog and
CC list.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Filesystem lockup with CONFIG_PREEMPT_RT
On Mon, 30 Jun 2014, Austin Schuh wrote: > I think I might have an answer for my own question, but I would > appreciate someone else to double check. If list_empty erroneously > returns that there is work to do when there isn't work to do, we wake > up an extra worker which then goes back to sleep. Not a big loss. If > list_empty erroneously returns that there isn't work to do when there > is, this should only be because someone is modifying the work list. > When they finish, as far as I can tell, all callers then check to see > if a worker needs to be started up, and start one. Precisely. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] declance: Fix 64-bit compilation warnings
On Sat, 5 Jul 2014, Joe Perches wrote: > > > I don't think %#p is valid so it > > > shouldn't have been set by #. > > > > Huh? As recently as last Wednesday you pointed me at the specific commit > > from Grant that made it valid (GCC format complaints aside). > > Those gcc complaints are precisely the thing > that makes it invalid. So enforce that in code then, clear the SPECIAL flag where appropriate and do not try to handle it in one place while leaving other ones to behave randomly (i.e. a supposedly fixed field width varies depending on the two uppermost digits). Please note that it's only your proposed change that introduces that randomness, right now code does what's supposed and documented to, except a bit inconsistently. > I believe you're tilting at windmills. > > Hey, it works sometimes. Knock yourself out. I pointed out an inconsistency with the intent to propose a fix once a consensus have been reached, one way or another. And I think shifting the inconsistency to a different place, which is what your proposal does, isn't really a complete solution, although I do recognise the improvement. Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: fbdev: sis: init.c: Cleaning up variable that is never used
Verifying the email address is not 100% fool proof so it's not a massive deal either way. The only reason I mentioned it here was because this patch wasn't correct anyway and had to be redone regardless. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: fbdev: sis: init.c: Cleaning up variable that is never used
On Sat, Jul 05, 2014 at 09:44:56PM +0200, Geert Uytterhoeven wrote: > On Sat, Jul 5, 2014 at 9:23 PM, Dan Carpenter > wrote: > > On Sat, Jul 05, 2014 at 02:48:27PM +0200, Rickard Strandqvist wrote: > >> From: Rickard Strandqvist > > > > These for lines are for when you are sending on someone else's behalf. > > Or for when you are sending the patches from a different email address > than the one that should be recorded in git. > Yeah. But it's better to fix your email client so we can at least verify that the signed off matches the author tag. I know a lot of people have trouble configuring email but in the end everyone pretty much manages when we ask them to. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kGraft to -next [was: 00/21 kGraft]
On Wed, 2 Jul 2014, Tejun Heo wrote:
> > static inline bool try_to_freeze(void)
> > {
> > + kgr_task_safe(current);
> > +
> > if (!(current->flags & PF_NOFREEZE))
> > debug_check_no_locks_held();
> > return try_to_freeze_unsafe();
>
> Heh, I'm totally confused now. Why is this correct? What guarantees
> that context is not carried across try_to_freeze()?
I think we need to take a step back now, and ask ourselves a question
"What is the actual goal here?".
What we need is to have a defined point in execution where we can draw a
line between "old" and "new" universes. For processess that are crossing
the userspace/kernelspace boundary, the obvious choice, that covers most
of the use-cases, has been made. There are still scenarios where this
aproach can't be just-blindly-applied(TM) for various reasons (changing
lock order might cause deadlocks, there are cases where state is lingering
between two user <-> kernel transitions, etc). So we'll need to provide
guidelines for kGraft patch writers anyway.
The same holds for the kernel threads -- until all (or most of) the
kthreads are converted to workqueues, the obivous choice, that should
cover most of the use-cases, has been made.
But manual/human inspection is absolutely unavoidably necessary in any
case.
Please keep in mind that this is designed for fixes that need immediate
response (getting bounds checking right, adding an extra check, adding a
missing lock, etc -- please see my previous mail on this topic in the old
thread). It's absolutely by design not intended for implementing whole new
features or exchanging the whole kernel on the fly; there are other
solutions for that (such as the criu-based thing). As such, we tend to
interfere with the rest of the kernel as little as possible, but it
inadverently brings drawbacks in the form of putting burden of more work
to the actual kGraft patch writers. I don't see that as a bad thing.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ALSA: hda - Fix and neaten print_nid_path/debug_badness
print_nid_path has a possible buffer overflow if
struct nid_path.path values are > 256.
Avoid this and neaten the output to remove the leading ':'
Neaten debug_badness to always verify arguments.
Signed-off-by: Joe Perches
---
sound/pci/hda/hda_generic.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c
index 589e47c..b293583 100644
--- a/sound/pci/hda/hda_generic.c
+++ b/sound/pci/hda/hda_generic.c
@@ -350,16 +350,16 @@ static void print_nid_path(struct hda_codec *codec,
const char *pfx, struct nid_path *path)
{
char buf[40];
+ char *pos = buf;
int i;
+ *pos = 0;
+ for (i = 0; i < path->depth; i++)
+ pos += scnprintf(pos, sizeof(buf) - (pos - buf), "%s%02x",
+pos != buf ? ":" : "",
+path->path[i]);
- buf[0] = 0;
- for (i = 0; i < path->depth; i++) {
- char tmp[4];
- sprintf(tmp, ":%02x", path->path[i]);
- strlcat(buf, tmp, sizeof(buf));
- }
- codec_dbg(codec, "%s path: depth=%d %s\n", pfx, path->depth, buf);
+ codec_dbg(codec, "%s path: depth=%d '%s'\n", pfx, path->depth, buf);
}
/* called recursively */
@@ -1700,9 +1700,11 @@ static int fill_and_eval_dacs(struct hda_codec *codec,
#define DEBUG_BADNESS
#ifdef DEBUG_BADNESS
-#define debug_badness(fmt, args...)codec_dbg(codec, fmt, ##args)
+#define debug_badness(fmt, ...)
\
+ codec_dbg(codec, fmt, ##__VA_ARGS__)
#else
-#define debug_badness(...)
+#define debug_badness(fmt, ...)
\
+ do { if (0) codec_dbg(codec, fmt, ##__VA_ARGS__); } while (0)
#endif
#ifdef DEBUG_BADNESS
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] kernfs: kernel-doc warning fix
On Fri, Jul 04, 2014 at 09:47:53PM +0200, Fabian Frederick wrote: > s/static_name/name_is_static > > Cc: Greg Kroah-Hartman > Cc: Andrew Morton > Cc: Tejun Heo > Signed-off-by: Fabian Frederick Acked-by: Tejun Heo Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Use DMA for data transfers in JZ4740 MMC driver
Hello, MMC driver for JZ4740 SoC is currently relying on PIO mode only for data transfers. The patch that comes as a follow-up of this message allows the use of DMA for data transfers. Changes since v1: - remove blank line added by mistake in jz_mmc_prepare_data_transfer(). According to the following DMA vs PIO benchmarks there seems to be a slight improvement in transfer speed with the Ben NanoNote booting from SD card, while load average seems to be roughly on par: * With DMA: Test cases | root@BenNanoNote:/# uptime | root@BenNanoNote:/# time zcat root/fedora-16.iso.gz > /dev/null && uptime ---|-- Test run 1 | 00:20:55 up 1 min, load average: 1.26, 0.42, 0.14 | 00:26:10 up 6 min, load average: 2.89, 1.94, 0.89 Test run 2 | 00:30:22 up 1 min, load average: 1.16, 0.38, 0.13 | 00:35:34 up 6 min, load average: 2.68, 1.86, 0.85 Test run 3 | 00:39:56 up 1 min, load average: 1.16, 0.38, 0.13 | 00:45:06 up 6 min, load average: 2.57, 1.76, 0.81 ---|-- Average | 1 min, load average: 1.19, 0.39, 0.13 | 6 min, load average: 2.71, 1.85, 0.85 * With PIO: Test cases | root@BenNanoNote:/# uptime | root@BenNanoNote:/# time zcat root/fedora-16.iso.gz > /dev/null && uptime -- Test run 1 | 00:50:47 up 1 min, load average: 1.42, 0.49, 0.17 | 00:56:52 up 7 min, load average: 2.47, 2.00, 0.98 Test run 2 | 01:00:19 up 1 min, load average: 1.21, 0.39, 0.14 | 01:06:29 up 7 min, load average: 2.45, 1.96, 0.96 Test run 3 | 01:11:27 up 1 min, load average: 1.15, 0.36, 0.12 | 01:17:33 up 7 min, load average: 2.63, 2.01, 0.97 ---|-- Average | 1 min, load average: 1.26, 0.41, 0.14 | 7 min, load average: 2.52, 1.99, 0.97 DMA tranfers performance might be further improved with a latter patch by taking advantage of the asynchronous request capability of the MMC framework. Changes were rebased on top of linux master branch, built and tested successfully. The following changes since commit 4c83445: Linux 3.16-rc3 are available in the git repository at: git://git.seketeli.net/~apelete/linux.git mmc-dma-jz4740 Apelete Seketeli (1): mmc: jz4740: add dma infrastructure for data transfers drivers/mmc/host/jz4740_mmc.c | 172 +++-- 1 file changed, 164 insertions(+), 8 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] mmc: jz4740: add dma infrastructure for data transfers
Until now the MMC driver for JZ4740 SoC was relying on PIO mode only
for data transfers.
This patch allows the use of DMA for data trasnfers in addition to PIO
mode by relying on DMA Engine.
DMA tranfers performance might be further improved by taking advantage
of the asynchronous request capability of the MMC framework.
Signed-off-by: Apelete Seketeli
---
drivers/mmc/host/jz4740_mmc.c | 172 +++--
1 file changed, 164 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index 537d6c7..035849e 100644
--- a/drivers/mmc/host/jz4740_mmc.c
+++ b/drivers/mmc/host/jz4740_mmc.c
@@ -30,7 +30,9 @@
#include
#include
#include
+#include
+#include
#include
#define JZ_REG_MMC_STRPCL 0x00
@@ -122,6 +124,7 @@ struct jz4740_mmc_host {
int card_detect_irq;
void __iomem *base;
+ struct resource *mem_res;
struct mmc_request *req;
struct mmc_command *cmd;
@@ -136,8 +139,132 @@ struct jz4740_mmc_host {
struct timer_list timeout_timer;
struct sg_mapping_iter miter;
enum jz4740_mmc_state state;
+
+ /* DMA support */
+ struct dma_chan *dma_rx;
+ struct dma_chan *dma_tx;
+ unsigned int sg_len;
+ bool use_dma;
+
+/* The DMA trigger level is 8 words, that is to say, the DMA read
+ * trigger is when data words in MSC_RXFIFO is >= 8 and the DMA write
+ * trigger is when data words in MSC_TXFIFO is < 8.
+ */
+#define JZ4740_MMC_FIFO_HALF_SIZE 8
};
+/**/
+/* DMA infrastructure */
+
+static void jz4740_release_dma_channels(struct jz4740_mmc_host *host)
+{
+ if (!host->use_dma)
+ return;
+
+ dma_release_channel(host->dma_tx);
+ dma_release_channel(host->dma_rx);
+}
+
+static int jz4740_acquire_dma_channels(struct jz4740_mmc_host *host)
+{
+ dma_cap_mask_t mask;
+
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+
+ host->dma_tx = dma_request_channel(mask, NULL, host);
+ if (!host->dma_tx) {
+ dev_err(mmc_dev(host->mmc), "Failed to get dma_tx channel\n");
+ return -ENODEV;
+ }
+
+ host->dma_rx = dma_request_channel(mask, NULL, host);
+ if (!host->dma_rx) {
+ dev_err(mmc_dev(host->mmc), "Failed to get dma_rx channel\n");
+ goto free_master_write;
+ }
+
+ return 0;
+
+free_master_write:
+ dma_release_channel(host->dma_tx);
+ return -ENODEV;
+}
+
+static inline int jz4740_get_dma_dir(struct mmc_data *data)
+{
+ return (data->flags & MMC_DATA_READ) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+}
+
+static void jz4740_dma_unmap(struct jz4740_mmc_host *host,
+struct mmc_data *data)
+{
+ enum dma_data_direction dir = jz4740_get_dma_dir(data);
+
+ dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len, dir);
+}
+
+static int jz4740_start_dma_transfer(struct jz4740_mmc_host *host,
+struct mmc_data *data)
+{
+ struct dma_chan *chan;
+ struct dma_async_tx_descriptor *desc;
+ struct dma_slave_config conf = {
+ .src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .src_maxburst = JZ4740_MMC_FIFO_HALF_SIZE,
+ .dst_maxburst = JZ4740_MMC_FIFO_HALF_SIZE,
+ };
+ enum dma_data_direction dir = jz4740_get_dma_dir(data);
+
+ host->sg_len = dma_map_sg(mmc_dev(host->mmc),
+ data->sg,
+ data->sg_len,
+ dir);
+
+ if (host->sg_len < 0) {
+ dev_err(mmc_dev(host->mmc),
+"Failed to map scatterlist for DMA operation\n");
+ return -EINVAL;
+ }
+
+ if (dir == DMA_TO_DEVICE) {
+ conf.direction = DMA_MEM_TO_DEV;
+ conf.dst_addr = host->mem_res->start + JZ_REG_MMC_TXFIFO;
+ conf.slave_id = JZ4740_DMA_TYPE_MMC_TRANSMIT;
+ chan = host->dma_tx;
+ } else {
+ conf.direction = DMA_DEV_TO_MEM;
+ conf.src_addr = host->mem_res->start + JZ_REG_MMC_RXFIFO;
+ conf.slave_id = JZ4740_DMA_TYPE_MMC_RECEIVE;
+ chan = host->dma_rx;
+ }
+
+ dmaengine_slave_config(chan, );
+ desc = dmaengine_prep_slave_sg(chan,
+ data->sg,
+ host->sg_len,
+ conf.direction,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (!desc) {
+ dev_err(mmc_dev(host->mmc),
+"Failed to allocate DMA %s descriptor",
+conf.direction == DMA_MEM_TO_DEV ? "TX" : "RX");
+
[GIT PULL] ARM: SoC fixes for 3.16-rc
Hi Linus, The following changes since commit 6c9d16178870315846faa1f59697b801e3fe0531: Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into fixes (2014-06-25 20:27:15 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus for you to fetch changes up to bc6aa56680b07984dc1443ef1a5a1a0fac0e20be: MAINTAINERS: Add few more Keystone drivers (2014-07-04 21:53:13 -0700) ARM: SoC fixes for 3.16-rc This week's arm-soc fixes: - A set of of OMAP patches that we had missed Tony's pull request of: - Reset fix for am43xx - Proper OPP table for omap5 - Fix for SoC detection of one of the DRA7 SoCs - hwmod updates to get SATA and OCP to work on omap5 (drivers merged in 3.16) - ... plus a handful of smaller fixes - sunxi needed to re-add machine specific restart code that was removed in anticipation of a watchdog driver being merged for 3.16, and it didn't make it in. - Marvell fixes for PCIe on SMP and a big-endian fix. - A trivial defconfig update to make my capri test board boot with bcm_defconfig again. ... and a couple of MAINTAINERS updates, one to claim new Keystone drivers that have been merged, and one to merge MXS and i.MX (both Freescale platforms). The largest diffs come from the hwmod code for omap5 and the re-add of the restart code on sunxi. The hwmod stuff is quite late at this point but it slipped through cracks repeatedly while coming up the maintainer chain and only affects the one SoC so risk is low. Brian Norris (1): ARM: OMAP2+: drop unused function Dave Gerlach (1): ARM: OMAP2+: hwmod: Change hardreset soc_ops for AM43XX David R. Piegdon (1): ARM: OMAP2+: Fix parser-bug in platform muxing code George Cherian (1): ARM: dts: am43x-epos-evm: Add Missing cpsw-phy-sel for am43x-epos-evm Keshava Munegowda (1): ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods Maxime Ripard (1): ARM: sunxi: Reintroduce the restart code for A10/A20 SoCs Nishanth Menon (2): ARM: DRA722: add detection of SoC information ARM: dts: omap5: Update CPU OPP table as per final production Manual Olof Johansson (3): ARM: bcm: Fix bcm and multi_v7 defconfigs Merge tag 'omap-for-v3.16/fixes-against-rc1' of git://git.kernel.org/.../tmlind/linux-omap into fixes Merge tag 'mvebu-fixes-3.16-2' of git://git.infradead.org/linux-mvebu into fixes Peter Ujfalusi (1): ARM: DTS: dra7/dra7xx-clocks: ATL related changes Santosh Shilimkar (1): MAINTAINERS: Add few more Keystone drivers Shawn Guo (1): MAINTAINERS: merge MXS entry into IMX one Sourav Poddar (1): ARM: dts: dra7-evm: remove interrupt binding Thomas Petazzoni (3): ARM: mvebu: move Armada 375 external abort logic as a quirk ARM: mvebu: update L2/PCIe deadlock workaround after L2CC cleanup ARM: mvebu: fix cpuidle implementation to work on big-endian systems Tony Lindgren (2): ARM: dts: Enable twl4030 off-idle configuration for selected omaps Merge tag 'for-v3.16-rc/omap-fixes-a' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.16/fixes MAINTAINERS| 34 + arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++ arch/arm/boot/dts/dra7.dtsi| 12 - arch/arm/boot/dts/dra7xx-clocks.dtsi | 16 +++ arch/arm/boot/dts/omap3-beagle-xm.dts | 6 +++ arch/arm/boot/dts/omap3-evm-common.dtsi| 7 +++ arch/arm/boot/dts/omap3-n900.dts | 5 ++ arch/arm/boot/dts/omap5.dtsi | 1 - arch/arm/configs/bcm_defconfig | 2 +- arch/arm/configs/multi_v7_defconfig| 3 +- arch/arm/mach-mvebu/Makefile | 2 +- arch/arm/mach-mvebu/board-v7.c | 29 +++ arch/arm/mach-mvebu/pmsu.c | 9 +--- arch/arm/mach-mvebu/pmsu_ll.S | 25 ++ arch/arm/mach-omap2/Makefile | 6 ++- arch/arm/mach-omap2/cm33xx.h | 2 +- arch/arm/mach-omap2/common.h | 1 - arch/arm/mach-omap2/id.c | 12 + arch/arm/mach-omap2/mux.c | 6 ++- arch/arm/mach-omap2/omap4-common.c | 20 arch/arm/mach-omap2/omap_hwmod.c | 6 +-- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73 arch/arm/mach-omap2/soc.h | 1 + arch/arm/mach-sunxi/sunxi.c| 77 ++ 24 files changed, 292 insertions(+), 67 deletions(-) create mode 100644 arch/arm/mach-mvebu/pmsu_ll.S -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
[Git pull] irq updates for 3.16
Linus,
please pull the latest irq-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-for-linus
A few minor fixlets in ARM SoC irq drivers and a fix for a memory leak
which I introduced in the last round of cleanups :(
Thanks,
tglx
-->
Florian Fainelli (1):
irqchip: brcmstb-l2: Level-2 interrupts are edge sensitive
Keith Busch (1):
genirq: Fix memory leak when calling irq_free_hwirqs()
Thomas Gleixner (1):
irqchip: spear_shirq: Fix interrupt offset
Thomas Petazzoni (1):
irqchip: armada-370-xp: Mask all interrupts during initialization.
drivers/irqchip/irq-armada-370-xp.c | 17 +++--
drivers/irqchip/irq-brcmstb-l2.c| 2 +-
drivers/irqchip/spear-shirq.c | 2 +-
kernel/irq/irqdesc.c| 4 ++--
4 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-armada-370-xp.c
b/drivers/irqchip/irq-armada-370-xp.c
index c887e6e..574aba0 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -334,6 +334,15 @@ static void armada_mpic_send_doorbell(const struct cpumask
*mask,
static void armada_xp_mpic_smp_cpu_init(void)
{
+ u32 control;
+ int nr_irqs, i;
+
+ control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
+ nr_irqs = (control >> 2) & 0x3ff;
+
+ for (i = 0; i < nr_irqs; i++)
+ writel(i, per_cpu_int_base + ARMADA_370_XP_INT_SET_MASK_OFFS);
+
/* Clear pending IPIs */
writel(0, per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS);
@@ -474,7 +483,7 @@ static int __init armada_370_xp_mpic_of_init(struct
device_node *node,
struct device_node *parent)
{
struct resource main_int_res, per_cpu_int_res;
- int parent_irq;
+ int parent_irq, nr_irqs, i;
u32 control;
BUG_ON(of_address_to_resource(node, 0, _int_res));
@@ -496,9 +505,13 @@ static int __init armada_370_xp_mpic_of_init(struct
device_node *node,
BUG_ON(!per_cpu_int_base);
control = readl(main_int_base + ARMADA_370_XP_INT_CONTROL);
+ nr_irqs = (control >> 2) & 0x3ff;
+
+ for (i = 0; i < nr_irqs; i++)
+ writel(i, main_int_base + ARMADA_370_XP_INT_CLEAR_ENABLE_OFFS);
armada_370_xp_mpic_domain =
- irq_domain_add_linear(node, (control >> 2) & 0x3ff,
+ irq_domain_add_linear(node, nr_irqs,
_370_xp_mpic_irq_ops, NULL);
BUG_ON(!armada_370_xp_mpic_domain);
diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
index 8ee2a36..c15c840 100644
--- a/drivers/irqchip/irq-brcmstb-l2.c
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -150,7 +150,7 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
/* Allocate a single Generic IRQ chip for this node */
ret = irq_alloc_domain_generic_chips(data->domain, 32, 1,
- np->full_name, handle_level_irq, clr, 0, 0);
+ np->full_name, handle_edge_irq, clr, 0, 0);
if (ret) {
pr_err("failed to allocate generic irq chip\n");
goto out_free_domain;
diff --git a/drivers/irqchip/spear-shirq.c b/drivers/irqchip/spear-shirq.c
index 3fdda3a..6ce6bd3 100644
--- a/drivers/irqchip/spear-shirq.c
+++ b/drivers/irqchip/spear-shirq.c
@@ -125,7 +125,7 @@ static struct spear_shirq spear320_shirq_ras2 = {
};
static struct spear_shirq spear320_shirq_ras3 = {
- .irq_nr = 3,
+ .irq_nr = 7,
.irq_bit_off = 0,
.invalid_irq = 1,
.regs = {
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 7339e42..1487a12 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -455,9 +455,9 @@ EXPORT_SYMBOL_GPL(irq_alloc_hwirqs);
*/
void irq_free_hwirqs(unsigned int from, int cnt)
{
- int i;
+ int i, j;
- for (i = from; cnt > 0; i++, cnt--) {
+ for (i = from, j = cnt; j > 0; i++, j--) {
irq_set_status_flags(i, _IRQ_NOREQUEST | _IRQ_NOPROBE);
arch_teardown_hwirq(i);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -repost 05/21] kgr: update Kconfig documentation
On Fri, 4 Jul 2014, Pavel Machek wrote: > > Hi, why do you believe so? But it is not so important, see below. > > Because it is quite hard to prepare the patch, and there's not really > enough documentation..? And given choice between "spend half an hour > preparing patch" and "just reboot", people compiling their own kernels > know what to do... I fail to see how "having the skills to compile my own kernel" and "being responsible for a datacenter that can't afford immediate reboot of all nodes" are connected in any way. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:irq/urgent] genirq: Fix memory leak when calling irq_free_hwirqs()
Commit-ID: 8844aad89ed61545b4db6a3467e1b21ca1c49460
Gitweb: http://git.kernel.org/tip/8844aad89ed61545b4db6a3467e1b21ca1c49460
Author: Keith Busch
AuthorDate: Mon, 30 Jun 2014 16:24:44 -0600
Committer: Thomas Gleixner
CommitDate: Sat, 5 Jul 2014 21:42:08 +0200
genirq: Fix memory leak when calling irq_free_hwirqs()
irq_free_hwirqs() always calls irq_free_descs() with a cnt == 0
which makes it a no-op since the interrupt count to free is
decremented in itself.
Fixes: 7b6ef1262549f6afc5c881aaef80beb8fd15f908
Signed-off-by: Keith Busch
Acked-by: David Rientjes
Link:
http://lkml.kernel.org/r/1404167084-8070-1-git-send-email-keith.bu...@intel.com
Signed-off-by: Thomas Gleixner
---
kernel/irq/irqdesc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 7339e42..1487a12 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -455,9 +455,9 @@ EXPORT_SYMBOL_GPL(irq_alloc_hwirqs);
*/
void irq_free_hwirqs(unsigned int from, int cnt)
{
- int i;
+ int i, j;
- for (i = from; cnt > 0; i++, cnt--) {
+ for (i = from, j = cnt; j > 0; i++, j--) {
irq_set_status_flags(i, _IRQ_NOREQUEST | _IRQ_NOPROBE);
arch_teardown_hwirq(i);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: fbdev: sis: init.c: Cleaning up variable that is never used
On Sat, Jul 5, 2014 at 9:23 PM, Dan Carpenter wrote:
> On Sat, Jul 05, 2014 at 02:48:27PM +0200, Rickard Strandqvist wrote:
>> From: Rickard Strandqvist
>
> These for lines are for when you are sending on someone else's behalf.
Or for when you are sending the patches from a different email address
than the one that should be recorded in git.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] usb: musb: register nop transceiver driver for jz4740
Following the name change of the NOP transceiver driver in commit
4525bee (usb: phy: rename usb_nop_xceiv to usb_phy_generic), make sure
to register the transceiver driver before calling usb_get_phy() to
avoid issues related to accessing its data structure while it was not
registered.
Signed-off-by: Apelete Seketeli
---
drivers/usb/musb/jz4740.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/musb/jz4740.c b/drivers/usb/musb/jz4740.c
index 5f30537..d118729 100644
--- a/drivers/usb/musb/jz4740.c
+++ b/drivers/usb/musb/jz4740.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "musb_core.h"
@@ -80,6 +81,7 @@ static struct musb_hdrc_platform_data
jz4740_musb_platform_data = {
static int jz4740_musb_init(struct musb *musb)
{
+ usb_phy_generic_register();
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (!musb->xceiv) {
pr_err("HS UDC: no transceiver configured\n");
@@ -182,6 +184,7 @@ static int jz4740_remove(struct platform_device *pdev)
struct jz4740_glue *glue = platform_get_drvdata(pdev);
platform_device_unregister(glue->musb);
+ usb_phy_generic_unregister(pdev);
clk_disable_unprepare(glue->clk);
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Register NOP tranciever driver in JZ4740 musb glue layer
Hello, The name of the NOP transceiver driver was changed during v3.16 release cycle from usb_phy_gen_xceiv to usb_phy_generic. The patch that comes as a follow up of this message registers the NOP transceiver driver before calling usb_get_phy() to avoid issues related to accessing its data structure while it was not registered. Changes since v1: - specify commit 4525bee summary line in parens in commit message. For notice, I updated corresponding platform data to rename NOP transceiver used for JZ4740 in a patch sent to linux-mips. Changes were rebased on top of the linux-usb master branch, built and tested successfully. The following changes since commit 80235c4: Merge tag 'v3.16-rc2' are available in the git repository at: git://git.seketeli.net/~apelete/linux-usb.git register-jz4740-phy Apelete Seketeli (1): usb: musb: register nop transceiver driver for jz4740 drivers/usb/musb/jz4740.c |3 +++ 1 file changed, 3 insertions(+) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] mips: jz4740: rename usb_nop_xceiv to usb_phy_generic
Rename usb_nop_xceiv to usb_phy_generic in platform data to match the
name change of the nop transceiver driver in commit 4525bee (usb: phy:
rename usb_nop_xceiv to usb_phy_generic).
The name change induced a kernel panic due to an unhandled kernel
unaligned access while trying to dereference musb->xceiv->io_ops in
musb_init_controller().
Signed-off-by: Apelete Seketeli
---
arch/mips/jz4740/platform.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/jz4740/platform.c b/arch/mips/jz4740/platform.c
index a447101..0b12f27 100644
--- a/arch/mips/jz4740/platform.c
+++ b/arch/mips/jz4740/platform.c
@@ -59,7 +59,7 @@ struct platform_device jz4740_usb_ohci_device = {
/* USB Device Controller */
struct platform_device jz4740_udc_xceiv_device = {
- .name = "usb_phy_gen_xceiv",
+ .name = "usb_phy_generic",
.id = 0,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Rename NOP transceiver in JZ4740 platform data
Hello, The name of the NOP transceiver driver was changed during v3.16 release cycle from usb_phy_gen_xceiv to usb_phy_generic. The patch that comes as a follow up of this message renames accordingly the NOP transceiver driver in JZ4740 platform data to fix a subsequent kernel panic. Changes since v1: - specify commit 4525bee summary line in parens and give more details about the bug that was fixed in the commit message. Please consider for merge in 3.16 if possible since it fixes an issue that makes the Ben Nanonote unable to boot. Changes were rebased on top of the linux-mips master branch, built and tested successfully. The following changes since commit bc0b9d9: Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux are available in the git repository at: git://git.seketeli.net/~apelete/linux-mips.git rename-jz4740-xceiv Apelete Seketeli (1): mips: jz4740: rename usb_nop_xceiv to usb_phy_generic arch/mips/jz4740/platform.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] machine_power_off: not only local_irq_disable but also do disable preemption
On Sun, Jul 06, 2014 at 12:34:14AM +0530, pawandeep oza wrote: > no this is not a generic code bug, because only in this scenerio, problem > might happen. > because other core is plugged out and now there is no chance that it can > release the spin_lock it would have held previously. > > so this core must run with preemption and interrupt disabled. > > this is only applicable for shutdown, not for any other scenerio. No. See my reply I just sent. Preempting when local interrupts disabled is a bug. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: fbdev: sis: init.c: Cleaning up variable that is never used
On Sat, Jul 05, 2014 at 02:48:27PM +0200, Rickard Strandqvist wrote:
> From: Rickard Strandqvist
These for lines are for when you are sending on someone else's behalf.
>
> Variable ar assigned a value that is never used.
> I have also removed all the code that thereby serves no purpose.
>
> This was found using a static code analysis program called cppcheck
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/video/fbdev/sis/init.c | 21 +
> 1 file changed, 5 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
> index bd40f5e..3ba446c 100644
> --- a/drivers/video/fbdev/sis/init.c
> +++ b/drivers/video/fbdev/sis/init.c
> @@ -2649,7 +2649,7 @@ static void
> SiS_SetCRT1ModeRegs(struct SiS_Private *SiS_Pr, unsigned short ModeNo,
> unsigned short ModeIdIndex, unsigned short RRTI)
> {
> - unsigned short data, infoflag = 0, modeflag, resindex;
> + unsigned short data, infoflag = 0, modeflag;
> #ifdef CONFIG_FB_SIS_315
> unsigned char *ROMAddr = SiS_Pr->VirtualRomBase;
> unsigned short data2, data3;
> @@ -2660,7 +2660,7 @@ SiS_SetCRT1ModeRegs(struct SiS_Private *SiS_Pr,
> unsigned short ModeNo,
> if(SiS_Pr->UseCustomMode) {
>infoflag = SiS_Pr->CInfoFlag;
> } else {
> - resindex = SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex);
> + SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex);
Remove this whole line.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 4/9] pci: OF: Fix the conversion of IO ranges into IO resources.
On Tue, Jul 1, 2014 at 1:43 PM, Liviu Dudau wrote:
> The ranges property for a host bridge controller in DT describes
> the mapping between the PCI bus address and the CPU physical address.
> The resources framework however expects that the IO resources start
> at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
> The conversion from pci ranges to resources failed to take that into account.
I don't think this change is right. There are 2 resources: the PCI bus
addresses and cpu addresses. This function deals with the cpu
addresses. Returning pci addresses for i/o and cpu addresses for
memory is going to be error prone. We probably need both cpu and pci
resources exposed to host controllers.
Making the new function only deal with i/o bus resources and naming it
of_pci_range_to_io_resource would be better.
Rob
> In the process move the function into drivers/of/address.c as it now
> depends on pci_address_to_pio() code and make it return an error message.
>
> Signed-off-by: Liviu Dudau
> Tested-by: Tanmay Inamdar
> ---
> drivers/of/address.c | 47
> ++
> include/linux/of_address.h | 13 ++---
> 2 files changed, 49 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 1345733..cbbaed2 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -872,3 +872,50 @@ bool of_dma_is_coherent(struct device_node *np)
> return false;
> }
> EXPORT_SYMBOL_GPL(of_dma_is_coherent);
> +
> +/*
> + * of_pci_range_to_resource - Create a resource from an of_pci_range
> + * @range: the PCI range that describes the resource
> + * @np:device node where the range belongs to
> + * @res: pointer to a valid resource that will be updated to
> + * reflect the values contained in the range.
> + *
> + * Returns EINVAL if the range cannot be converted to resource.
> + *
> + * Note that if the range is an IO range, the resource will be converted
> + * using pci_address_to_pio() which can fail if it is called too early or
> + * if the range cannot be matched to any host bridge IO space (our case
> here).
> + * To guard against that we try to register the IO range first.
> + * If that fails we know that pci_address_to_pio() will do too.
> + */
> +int of_pci_range_to_resource(struct of_pci_range *range,
> + struct device_node *np, struct resource *res)
> +{
> + int err;
> + res->flags = range->flags;
> + res->parent = res->child = res->sibling = NULL;
> + res->name = np->full_name;
> +
> + if (res->flags & IORESOURCE_IO) {
> + unsigned long port = -1;
> + err = pci_register_io_range(range->cpu_addr, range->size);
> + if (err)
> + goto invalid_range;
> + port = pci_address_to_pio(range->cpu_addr);
> + if (port == (unsigned long)-1) {
> + err = -EINVAL;
> + goto invalid_range;
> + }
> + res->start = port;
> + } else {
> + res->start = range->cpu_addr;
> + }
> + res->end = res->start + range->size - 1;
> + return 0;
> +
> +invalid_range:
> + res->start = (resource_size_t)OF_BAD_ADDR;
> + res->end = (resource_size_t)OF_BAD_ADDR;
> + return err;
> +}
> +
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index ac4aac4..33c0420 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -23,17 +23,8 @@ struct of_pci_range {
> #define for_each_of_pci_range(parser, range) \
> for (; of_pci_range_parser_one(parser, range);)
>
> -static inline void of_pci_range_to_resource(struct of_pci_range *range,
> - struct device_node *np,
> - struct resource *res)
> -{
> - res->flags = range->flags;
> - res->start = range->cpu_addr;
> - res->end = range->cpu_addr + range->size - 1;
> - res->parent = res->child = res->sibling = NULL;
> - res->name = np->full_name;
> -}
> -
> +extern int of_pci_range_to_resource(struct of_pci_range *range,
> + struct device_node *np, struct resource *res);
> /* Translate a DMA address from device space to CPU space */
> extern u64 of_translate_dma_address(struct device_node *dev,
> const __be32 *in_addr);
> --
> 2.0.0
>
>
> ___
> linaro-kernel mailing list
> linaro-ker...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] machine_power_off: not only local_irq_disable but also do disable preemption
On Sun, Jul 06, 2014 at 12:20:03AM +0530, pawandeep oza wrote:
> preempt_check_resched would check TIF_NEED_RESCHED
> #define preempt_check_resched() \
> do { \
> if (unlikely(test_thread_flag(TIF_NEED_RESCHED))) \
> preempt_schedule(); \
> } while (0)
>
> there is a chance that just beofre we disabled irqs, somebody would have
> marked the flag to current, and
> later on, it might happen that, current gets replaced by the process which
> tries to hold a spin_lock which has already been previosuly held by CPU1
> when
> was being plugged out by smp_send_stop.
And preempt_schedule() contains:
/*
* If there is a non-zero preempt_count or interrupts are disabled,
* we do not want to preempt the current task. Just return..
*/
if (likely(!preemptible()))
return;
where preemptible() is defined as:
(preempt_count() == 0 && !irqs_disabled())
which means... if interrupts are disabled (as they are) we don't
return from preempt_schedule() without doing anything.
Scheduling with interrupts disabled is a bug. If you need to add
preempt_disable() before local_irq_disable() to prevent it, then
there's a bug somewhere else, and we don't "fix" that by adding
preempt_disable(). The real bug needs to be found and fixed.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] MIPS: Fix incorrect NULL check in local_flush_tlb_page()
On Sat, Jul 5, 2014 at 8:26 PM, Emil Goode wrote:
> We check that the struct vm_area_struct pointer vma is NULL and then
> dereference it a few lines below. The intent must have been to make sure
> that vma is not NULL and then to check the value from cpu_context() for
> the condition to be true.
>
> Signed-off-by: Emil Goode
> ---
>
> v2: Updated the commit message with a better explanation.
>
> arch/mips/mm/tlb-r3k.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/mips/mm/tlb-r3k.c b/arch/mips/mm/tlb-r3k.c
> index d657493..6546758 100644
> --- a/arch/mips/mm/tlb-r3k.c
> +++ b/arch/mips/mm/tlb-r3k.c
> @@ -158,7 +158,7 @@ void local_flush_tlb_page(struct vm_area_struct *vma,
> unsigned long page)
> {
> int cpu = smp_processor_id();
>
> - if (!vma || cpu_context(cpu, vma->vm_mm) != 0) {
> + if (vma && cpu_context(cpu, vma->vm_mm) != 0) {
Sorry for replying "too late", but grepping through the kernel code I
fail to find any caller that does not dereference vma before calling
(local)flush_tlb_page(). Also both tlb-4k and tlb-8k assume vma cannot
be NULL, so I would say it is safe to assume vma is never NULL, and
the NULL check can be removed completely.
Also it looks like this "bug" was there since at least 2.6.12, and
never seem to have bitten anyone.
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/46] 3.10.47-stable review
On Fri, Jul 04, 2014 at 10:43:40PM -0700, Guenter Roeck wrote: > On 07/04/2014 03:19 PM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.10.47 release. > >There are 46 patches in this series, all will be posted as a response > >to this one. If anyone has any issues with these being applied, please > >let me know. > > > >Responses should be made by Sun Jul 6 22:15:52 UTC 2014. > >Anything received after that time might be too late. > > > > Build results: > total: 144 pass: 125 skipped: 6 fail: 13 > Failed builds: > alpha:allmodconfig > i386:defconfig > i386:allyesconfig > i386:allmodconfig > powerpc:allmodconfig (binutils 2.23) > powerpc:allmodconfig (binutils 2.24) > score:defconfig > sparc64:allmodconfig > unicore32:defconfig > x86_64:defconfig > x86_64:allyesconfig > x86_64:allmodconfig > xtensa:allmodconfig > > Qemu test for x86 failed with a build error. > > This is not as expected. New build error is always the same as far as I can > see: > > sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': > sound/pci/hda/patch_sigmatel.c:3578:3: error: implicit declaration of > function 'codec_dbg' [-Werror=implicit-function-declaration] Should now be fixed, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/59] 3.14.11-stable review
On Sat, Jul 05, 2014 at 02:56:55PM +0200, Takashi Iwai wrote: > At Sat, 05 Jul 2014 18:21:04 +0900, > Satoru Takeuchi wrote: > > > > Hi Greg, > > > > Add Takashi Iwai to this thread. > > > > At Sat, 05 Jul 2014 16:00:41 +0900, > > Satoru Takeuchi wrote: > > > > > > At Fri, 04 Jul 2014 22:45:42 -0700, > > > Guenter Roeck wrote: > > > > > > > > On 07/04/2014 03:18 PM, Greg Kroah-Hartman wrote: > > > > > This is the start of the stable review cycle for the 3.14.11 release. > > > > > There are 59 patches in this series, all will be posted as a response > > > > > to this one. If anyone has any issues with these being applied, > > > > > please > > > > > let me know. > > > > > > > > > > Responses should be made by Sun Jul 6 22:15:27 UTC 2014. > > > > > Anything received after that time might be too late. > > > > > > > > > > > > > Build results: > > > > total: 144 pass: 130 skipped: 4 fail: 10 > > > > Failed builds: > > > > alpha:allmodconfig > > > > i386:allyesconfig > > > > i386:allmodconfig > > > > powerpc:allmodconfig (binutils 2.23) > > > > powerpc:allmodconfig (binutils 2.24) > > > > sparc64:allmodconfig > > > > unicore32:defconfig > > > > x86_64:allyesconfig > > > > x86_64:allmodconfig > > > > xtensa:allmodconfig > > > > > > > > Qemu test for x86 failed. > > > > > > > > Build error is the same as seen with 3.14. > > > > > > > > sound/pci/hda/patch_sigmatel.c: In function 'stac92hd95_fixup_hp_led': > > > > sound/pci/hda/patch_sigmatel.c:4143:3: error: implicit declaration of > > > > function 'codec_dbg' [-Werror=implicit-function-declaration] > > > > > > This kernel failed to build with the following error. Probably the root > > > cause is the same as Guenter. I'm now bisecting to find the problematic > > > patch... > > > > The following patch caused the boot failure of both this kernel and > > 3.10.47-rc1. > > > > alsa-hda-adjust-speaker-hpf-and-add-led-support-for-hp-spectre-13.patch: > > === > > From 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab Mon Sep 17 00:00:00 2001 > > From: Takashi Iwai > > Date: Tue, 24 Jun 2014 13:55:25 +0200 > > Subject: ALSA: hda - Adjust speaker HPF and add LED support for HP Spectre > > 13 > > > > From: Takashi Iwai > > > > commit 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab upstream. > > > > HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the > > default high-pass filter in some "safer" range, which results in the > > very soft tone from the built-in speakers in contrast to Windows. > > Also, the mute LED control is missing, since 92HD95 codec still has no > > HP-specific fixups for GPIO setups. > > > > This patch adds these missing features: the HPF is adjusted by the > > vendor-specific verb, and the LED is set up from a DMI string (but > > with the default polarity = 0 assumption due to the incomplete BIOS on > > the given machine). > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841 > > Signed-off-by: Takashi Iwai > > Signed-off-by: Greg Kroah-Hartman > > ... > > === > > > > This patch uses codec_dbg(), however, this macro is intrdocuded by the > > following patch and it's not applied to these stable-tree yet. > > > > === > > ommit 4e76a8833fac8dc1735aa5be7d1b3c92c65e209e > > Author: Takashi Iwai > > Date: Tue Feb 25 12:21:03 2014 +0100 > > > > ALSA: hda - Replace with standard printk > > > > Use dev_err() and co for messages from HD-audio controller and codec > > drivers. The codec drivers are mostly bound with codec objects, so > > some helper macros, codec_err(), codec_info(), etc, are provided. > > They merely wrap the corresponding dev_xxx(). > > > > There are a few places still calling snd_printk() and its variants > > as they are called without the codec or device context. > > > > Signed-off-by: Takashi Iwai > > ... > > === > > > > Unfortunately I failed to apply this patch to 3.14.11-rc1 with the following > > error log. > > > > === > > $ git apply ~/src/test-linux-stable/extra_patch.txt > > error: patch failed: sound/pci/hda/hda_intel.c:897 > > error: sound/pci/hda/hda_intel.c: patch does not apply > > error: sound/pci/hda/hda_sysfs.c: No such file or directory > > === > > > > I'm not sure whether we should drop this patch or should apply extra patches > > to remove this build failure. Any idea? > > Just drop the patch from 3.14 and earlier stable kernels. If anyone > wants to use the laptop, they should use 3.15.x or later kernel.
Re: [PATCH 3.14 59/59] ALSA: hda - Adjust speaker HPF and add LED support for HP Spectre 13
On Sat, Jul 05, 2014 at 02:58:28PM +0200, Takashi Iwai wrote: > At Fri, 4 Jul 2014 15:19:48 -0700, > Greg Kroah-Hartman wrote: > > > > 3.14-stable review patch. If anyone has any objections, please let me know. > > This turned to be not applicable to 3.14 and earlier, as mentioned in > another thread. Please drop. Now dropped from 3.10 and 3.14, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 7/9] pci: of: Parse and map the IRQ when adding the PCI device.
On Wed, Jul 2, 2014 at 6:17 AM, Will Deacon wrote:
> On Tue, Jul 01, 2014 at 07:43:32PM +0100, Liviu Dudau wrote:
>> Enhance the default implementation of pcibios_add_device() to
>> parse and map the IRQ of the device if a DT binding is available.
>>
>> Signed-off-by: Liviu Dudau
>> ---
>> drivers/pci/pci.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 63a54a3..8e65dc3 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -17,6 +17,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -1453,6 +1454,9 @@ EXPORT_SYMBOL(pcim_pin_device);
>> */
>> int __weak pcibios_add_device(struct pci_dev *dev)
>> {
>> +#ifdef CONFIG_OF
>> + dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
>> +#endif
>
> You could avoid the #ifdef by only assigning dev->irq if
> of_irq_parse_and_map_pci returned something > 0.
Perhaps it could just be unconditional always. Presumably, dev->irq is
not already set to something valid and setting it to <= 0 should not
have any consequences.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] PCI: enable ASPM configuration in PCIE POWERSAVE mode
[+cc Rafael]
On Sat, Jul 05, 2014 at 12:57:36PM -0600, Bjorn Helgaas wrote:
> [+cc Matthew]
>
> On Tue, Jul 01, 2014 at 12:46:18PM +0530, Vidya Sagar wrote:
> > commit 1a680b7c moved pcie_aspm_powersave_config_link() out of
> > pci_raw_set_power_state() to pci_set_power_state() which would enable
> > ASPM. But, with commit db288c9c, which re-introduced the following check
> > ./drivers/pci/pci.c: pci_set_power_state()
> > + /* Check if we're already there */
> > + if (dev->current_state == state)
> > + return 0;
> > in pci_set_power_state(), call to pcie_aspm_powersave_config_link() is never
> > made leaving ASPM broken.
> > Fix it by not returning from when the above condition is true, rather, jump
> > to
> > ASPM configuration code and exit from there eventually.
>
> Rafael, Matthew, any comments? We have vacillated on this before and
> the web is already pretty tangled.
>
> Vidya, can you give more details about the bug fixed by this change?
> What's the scenario? Are we resuming and the device is powered up but
> ASPM isn't enabled? Maybe you could collect more details in a
> http://bugzilla.kernel.org report?
>
> > Signed-off-by: Vidya Sagar
> > ---
> > drivers/pci/pci.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 1c8592b..ded24c4 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -804,7 +804,7 @@ EXPORT_SYMBOL_GPL(__pci_complete_power_transition);
> > */
> > int pci_set_power_state(struct pci_dev *dev, pci_power_t state)
> > {
> > - int error;
> > + int error = 0;
> >
> > /* bound the state we're entering */
> > if (state > PCI_D3cold)
> > @@ -821,7 +821,7 @@ int pci_set_power_state(struct pci_dev *dev,
> > pci_power_t state)
> >
> > /* Check if we're already there */
> > if (dev->current_state == state)
> > - return 0;
> > + goto config_aspm;
> >
> > __pci_start_power_transition(dev, state);
> >
> > @@ -839,6 +839,8 @@ int pci_set_power_state(struct pci_dev *dev,
> > pci_power_t state)
> >
> > if (!__pci_complete_power_transition(dev, state))
> > error = 0;
> > +
> > +config_aspm:
> > /*
> > * When aspm_policy is "powersave" this call ensures
> > * that ASPM is configured.
> > --
> > 1.8.1.5
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] machine_power_off: not only local_irq_disable but also do disable preemption
On Sun, Jul 06, 2014 at 12:20:03AM +0530, pawandeep oza wrote:
> Hi,
>
> I am referring to this version of spin lock apis.
>
> static inline void __raw_spin_lock(raw_spinlock_t *lock)
> {
> preempt_disable();
> spin_acquire(>dep_map, 0, 0, _RET_IP_);
> LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
> }
>
>
> static inline void __raw_spin_unlock(raw_spinlock_t *lock)
> {
> spin_release(>dep_map, 1, _RET_IP_);
> do_raw_spin_unlock(lock);
> preempt_enable();
> }
>
> poweroff path runs with irqs disabled, but what is some one (valid
> scenerio) try to have spin_lock and spin_unlock for its own reasons.
>
> spin_unlock doesn preempt_enable at the end...
> which in turn does following.
>
> #define preempt_enable() \
> do { \
> preempt_enable_no_resched(); \
> barrier(); \
> preempt_check_resched(); \
> } while (0)
>
>
> preempt_check_resched would check TIF_NEED_RESCHED
> #define preempt_check_resched() \
> do { \
> if (unlikely(test_thread_flag(TIF_NEED_RESCHED))) \
> preempt_schedule(); \
> } while (0)
>
> there is a chance that just beofre we disabled irqs, somebody would have
> marked the flag to current, and
> later on, it might happen that, current gets replaced by the process which
> tries to hold a spin_lock which has already been previosuly held by CPU1
> when
> was being plugged out by smp_send_stop.
This seems to be a generic code bug - if interrupts are disabled (they
are) then we should not schedule at all.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] PCI: enable ASPM configuration in PCIE POWERSAVE mode
[+cc Matthew]
On Tue, Jul 01, 2014 at 12:46:18PM +0530, Vidya Sagar wrote:
> commit 1a680b7c moved pcie_aspm_powersave_config_link() out of
> pci_raw_set_power_state() to pci_set_power_state() which would enable
> ASPM. But, with commit db288c9c, which re-introduced the following check
> ./drivers/pci/pci.c: pci_set_power_state()
> + /* Check if we're already there */
> + if (dev->current_state == state)
> + return 0;
> in pci_set_power_state(), call to pcie_aspm_powersave_config_link() is never
> made leaving ASPM broken.
> Fix it by not returning from when the above condition is true, rather, jump to
> ASPM configuration code and exit from there eventually.
Rafael, Matthew, any comments? We have vacillated on this before and
the web is already pretty tangled.
Vidya, can you give more details about the bug fixed by this change?
What's the scenario? Are we resuming and the device is powered up but
ASPM isn't enabled? Maybe you could collect more details in a
http://bugzilla.kernel.org report?
> Signed-off-by: Vidya Sagar
> ---
> drivers/pci/pci.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 1c8592b..ded24c4 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -804,7 +804,7 @@ EXPORT_SYMBOL_GPL(__pci_complete_power_transition);
> */
> int pci_set_power_state(struct pci_dev *dev, pci_power_t state)
> {
> - int error;
> + int error = 0;
>
> /* bound the state we're entering */
> if (state > PCI_D3cold)
> @@ -821,7 +821,7 @@ int pci_set_power_state(struct pci_dev *dev, pci_power_t
> state)
>
> /* Check if we're already there */
> if (dev->current_state == state)
> - return 0;
> + goto config_aspm;
>
> __pci_start_power_transition(dev, state);
>
> @@ -839,6 +839,8 @@ int pci_set_power_state(struct pci_dev *dev, pci_power_t
> state)
>
> if (!__pci_complete_power_transition(dev, state))
> error = 0;
> +
> +config_aspm:
> /*
>* When aspm_policy is "powersave" this call ensures
>* that ASPM is configured.
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] spi: add driver for Rockchip RK3xxx SoCs integrated SPI
On Fri, Jul 4, 2014 at 8:32 PM, Mark Brown wrote:
> On Tue, Jul 01, 2014 at 09:03:59AM +0800, addy ke wrote:
>> In order to facilitate understanding, rockchip SPI controller IP design
>> looks similar in its registers to designware. But IC implementation
>> is different from designware, So we need a dedicated driver for Rockchip
>> RK3XXX SoCs integrated SPI. The main differences:
>
> This looks good overall, a nice clean driver. I've applied it but there
> are a few small issues that need fixing up which I've noted below, can
> you please send followup patches dealing with these?
>
>> + * static void spi_set_cs(struct spi_device *spi, bool enable)
>> + * {
>> + * if (spi->mode & SPI_CS_HIGH)
>> + * enable = !enable;
>> + *
>> + * if (spi->cs_gpio >= 0)
>> + * gpio_set_value(spi->cs_gpio, !enable);
>> + * else if (spi->master->set_cs)
>> + * spi->master->set_cs(spi, !enable);
>> + * }
>> + *
>> + * Note: enable(rockchip_spi_set_cs) = !enable(spi_set_cs)
>> + */
>
> So, the point here is that chip select is an active low signal by
> default which means that if chip select is asserted we have a low logic
> level and the parameter means "asserted" not "logic level for the
> output". It doesn't really matter but it might be clearer to say so
> directly.
>
>> + if (spi->mode & SPI_CS_HIGH) {
>> + dev_err(rs->dev, "spi_cs_hign: not support\n");
>> + return -EINVAL;
>
> Typo here (high).
This whole check looks bogus and should probably be removed. Either
the driver/hardware does not support SPI_CS_HIGH, then the
master->mode_bits set in rockchip_spi_probe are wrong and SPI_CS_HIGH
should be removed. The common code already ensures that spi_device's
mode match the master's mode_bits, so the condition then could never
be true.
Or the driver/hardware does actually support it as it claims with it
mode_bits, then the check is wrong and it will wrongfully rejects
spi_devices using/requiring SPI_CS_HIGH.
Going that the rockchip_spi_set_cs has this extra explanation about
enable being inverted with CS_HIGH, I would guess the latter.
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/5] PCI: add PCI controller for Keystone PCIe h/w
On Mon, Jun 30, 2014 at 05:45:20PM -0400, Murali Karicheri wrote:
> Keystone PCIe controller is based on v3.65 version of the
> designware h/w. Main differences are
> 1. No ATU support
> 2. Legacy and MSI irq functions are implemented in
> application register space
> 3. MSI interrupts are multiplexed over 8 IRQ lines to the Host
> side.
> All of the Application register space handing code are organized into
> pci-keystone-dw.c and the functions are called from pci-keystone.c
> to implement PCI controller driver. Also add necessary DT documentation
> for the driver.
I didn't review this code, but have a few minor comments below.
> Signed-off-by: Murali Karicheri
>
> CC: Santosh Shilimkar
> CC: Russell King
> CC: Grant Likely
> CC: Rob Herring
> CC: Mohit Kumar
> CC: Jingoo Han
> CC: Bjorn Helgaas
> CC: Pratyush Anand
> CC: Richard Zhu
> CC: Kishon Vijay Abraham I
> CC: Marek Vasut
> CC: Arnd Bergmann
> CC: Pawel Moll
> CC: Mark Rutland
> CC: Ian Campbell
> CC: Kumar Gala
> CC: Randy Dunlap
> CC: Grant Likely
> ---
> .../devicetree/bindings/pci/pci-keystone.txt | 69 +++
> drivers/pci/host/Kconfig |5 +
> drivers/pci/host/Makefile |1 +
> drivers/pci/host/pci-keystone-dw.c | 523
>
> drivers/pci/host/pci-keystone.c| 381 ++
> drivers/pci/host/pci-keystone.h| 56 +++
> 6 files changed, 1035 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/pci-keystone.txt
> create mode 100644 drivers/pci/host/pci-keystone-dw.c
> create mode 100644 drivers/pci/host/pci-keystone.c
> create mode 100644 drivers/pci/host/pci-keystone.h
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-keystone.txt
> b/Documentation/devicetree/bindings/pci/pci-keystone.txt
> new file mode 100644
> index 000..bb39601
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/pci-keystone.txt
> @@ -0,0 +1,69 @@
> +TI Keystone PCIe interface
> +
> +Keystone PCI host Controller is based on Designware PCI h/w version 3.65.
> +It shares common functions with PCIE Designware core driver and inherit
> +common properties defined in
> +Documentation/devicetree/bindings/pci/designware-pci.txt
> +Compatibility string "dw,snps-pcie-v3.65" is used to identify the verison
> +of the DW h/w used on Keystone.
> +
> +Please refer to Documentation/devicetree/bindings/pci/designware-pci.txt
> +for the details of designware DT bindings. Additional properties are
> +described here as well propeties that are not applicable.
> +
> +Required Properties:-
> +
> +compatibility: "ti,keystone-pcie"
> +reg: index 1 is the base address and length of DW application registers.
> + index 2 is the base address and length of PCI mode configuration
> + register.
> + index 3 is the base address and length of PCI device ID register.
> +
> +pcie_msi_intc : Interrupt controller device node for MSI irq chip
> + interrupt-cells: should be set to 1
> + interrupt-parent: Parent interrupt controller phandle
> + interrupts: GIC interrupt lines connected to PCI MSI interrupt lines
> +
> + Example:
> + pcie_msi_intc: msi-interrupt-controller {
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + interrupt-parent = <>;
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + };
> +
> +pcie_intc: Interrupt controller device node for Legacy irq chip
> + interrupt-cells: should be set to 1
> + interrupt-parent: Parent interrupt controller phandle
> + interrupts: GIC interrupt lines connected to PCI Legacy interrupt lines
> +
> + Example:
> + pcie_intc: legacy-interrupt-controller {
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + interrupt-parent = <>;
> + interrupts = ,
> + ,
> + ,
> + ;
> + };
> +
> +Optional properties:-
> + phys: phandle to Generic Keystone SerDes phy for PCI
> + phy-names: name of the Generic Keystine SerDes phy for PCI
> + - If boot loader already does PCI link establishment, then phys and
> + phy-names shouldn't be present.
> + ti,enable-linktrain - Enable Link training.
> + - If boot loader already does PCI link establishment, then this
> + shouldn't be present.
> +
> +Designware DT Properties not applicable for Keystone PCI
> +
> +1. pcie_bus clock-names not used. Instead, a phandle to phys is used.
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>
Re: [PATCH v2] declance: Fix 64-bit compilation warnings
On Sat, 2014-07-05 at 19:20 +0100, Maciej W. Rozycki wrote: > On Sat, 5 Jul 2014, Joe Perches wrote: > > I don't think %#p is valid so it > > shouldn't have been set by #. > > Huh? As recently as last Wednesday you pointed me at the specific commit > from Grant that made it valid (GCC format complaints aside). Those gcc complaints are precisely the thing that makes it invalid. I believe you're tilting at windmills. Hey, it works sometimes. Knock yourself out. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] arm: pxa: add non device-tree timer link to clocksource
On Saturday 05 July 2014 13:13:01 Robert Jarzmik wrote:
> EXPORT_SYMBOL(get_clock_tick_rate);
>
> /*
> + * For non device-tree builds, keep legacy timer init
> + */
> +extern void pxa_timer_nodt_init(int irq, void __iomem *base,
> + unsigned long clock_tick_rate);
> +void pxa_timer_init(void)
> +{
> + pxa_timer_nodt_init(IRQ_OST0, io_p2v(0x40a0),
> + get_clock_tick_rate());
> +}
> +
I think it would be better to move the extern declaration into
a new header file, e.g. include/clocksource/pxa.h.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] MIPS: Fix incorrect NULL check in local_flush_tlb_page()
We check that the struct vm_area_struct pointer vma is NULL and then
dereference it a few lines below. The intent must have been to make sure
that vma is not NULL and then to check the value from cpu_context() for
the condition to be true.
Signed-off-by: Emil Goode
---
v2: Updated the commit message with a better explanation.
arch/mips/mm/tlb-r3k.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/mm/tlb-r3k.c b/arch/mips/mm/tlb-r3k.c
index d657493..6546758 100644
--- a/arch/mips/mm/tlb-r3k.c
+++ b/arch/mips/mm/tlb-r3k.c
@@ -158,7 +158,7 @@ void local_flush_tlb_page(struct vm_area_struct *vma,
unsigned long page)
{
int cpu = smp_processor_id();
- if (!vma || cpu_context(cpu, vma->vm_mm) != 0) {
+ if (vma && cpu_context(cpu, vma->vm_mm) != 0) {
unsigned long flags;
int oldpid, newpid, idx;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/19] 3.4.97-stable review
On 07/05/2014 10:48 AM, Greg Kroah-Hartman wrote: On Sat, Jul 05, 2014 at 10:46:46AM -0700, Greg Kroah-Hartman wrote: On Fri, Jul 04, 2014 at 10:39:01PM -0700, Guenter Roeck wrote: On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.97 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Jul 6 22:14:29 UTC 2014. Anything received after that time might be too late. Build results: total: 137 pass: 111 skipped: 20 fail: 6 111 skipped? Did you add a bunch more targets? Why skip them? Doh, that is 20 skipped, nevermind... But, in looking at your site, it seems that there are always at least 7 that are "skipped", for all kernel versions. Why? lowest 'skipped' value is actually 4, for 3.14. 'skipped' means that a configuration does not apply for this kernel version. As I am adding more recent configurations, the number of 'skipped' builds gets larger for older kernels. Similar, as configurations are dropped from newer kernels, the number gets larger for newer kernels as well. I'll see if I can change the output and not display the 'skipped' value in the final summary; it doesn't really provide value and just creates confusion. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] Add Keystone PCIe controller driver
On Mon, Jun 30, 2014 at 05:45:15PM -0400, Murali Karicheri wrote: > This patch add PCIe controller driver for Keystone SoCs. This > is based on v2 of the series posted to the mailing list. > Keystone PCI controller is based on version 3.65 of the DW > hardware. This driver re-uses some of the DW core driver > functions and required modification in some to support > the old DW h/w based Keystone driver. > > Please review and let me know if you have any comments. I'm waiting for acks from Mohit or Jingoo for the designware changes. I'd also like an ack from the devicetree folks for the Keystone binding. And I think we need a MAINTAINERS update for drivers/pci/host/\*keystone\* > CC: Santosh Shilimkar > CC: Russell King > CC: Grant Likely > CC: Rob Herring > CC: Mohit Kumar > CC: Jingoo Han > CC: Bjorn Helgaas > CC: Pratyush Anand > CC: Richard Zhu > CC: Kishon Vijay Abraham I > CC: Marek Vasut > CC: Arnd Bergmann > CC: Pawel Moll > CC: Mark Rutland > CC: Ian Campbell > CC: Kumar Gala > CC: Randy Dunlap > CC: Grant Likely > > Changelog: > > v3 > - DW application register handling code is now part of >Keystone PCI driver. RFC had this code part of Keystone >PCI driver, then V1 moved this to a separate file to >re-use on other platforms that uses this version of the >DW h/w. Then based on comments against v2, this is moved >back to Keystone driver. > - Keystone SerDes phy driver is removed from this series so that >this can be merged independent of that patch > - added msi_set_irq()/clear_irq() API's to support Keystone > > V2 > - Split the designware pcie enhancement patch to multiple >patches based on functionality added > - Remove the quirk code and add a patch to fix mps/mrss >tuning for ARM. Use kernel command line parameter >pci=pcie_bus_perf to work with Keystone PCI Controller. >Following patch addressed this. > [PATCH v1] ARM: pci: add call to pcie_bus_configure_settings() > - Add documentation for device tree bindings > - Add separate interrupt controller nodes for MSI and Legacy >IRQs and use irq map for legacy IRQ > - Use compatibility to identify v3.65 version of the DW hardware >and use it to customize the designware common code. > - Use reg property for configuration space instead of range > - Other minor updates based on code inspection. > > V1 > - Add an interrupt controller node for Legacy irq chip and use >interrupt map/map-mask property to map legacy IRQs A/B/C/D > - Add a Phy driver to replace the original serdes driver > - Move common application register handling code to a separate >file to allow re-use across other platforms that use older >DW PCIe h/w > - PCI quirk for maximum read request size. Check and override only >if the maximum is higher than what controller can handle. > - Converted to a module platform driver. > > Murali Karicheri (5): > PCI: designware: add rd[wr]_other_conf API > PCI: designware: refactor MSI code to work with v3.65 dw hardware > PCI: designware: refactor host init code to re-use on keystone PCI > PCI: designware: enhance dw core driver to support Keystone PCI host > controller > PCI: add PCI controller for Keystone PCIe h/w > > .../devicetree/bindings/pci/designware-pcie.txt|2 + > .../devicetree/bindings/pci/pci-keystone.txt | 69 +++ > drivers/pci/host/Kconfig |5 + > drivers/pci/host/Makefile |1 + > drivers/pci/host/pci-keystone-dw.c | 523 > > drivers/pci/host/pci-keystone.c| 381 ++ > drivers/pci/host/pci-keystone.h| 56 +++ > drivers/pci/host/pcie-designware.c | 206 ++-- > drivers/pci/host/pcie-designware.h | 17 +- > 9 files changed, 1207 insertions(+), 53 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pci/pci-keystone.txt > create mode 100644 drivers/pci/host/pci-keystone-dw.c > create mode 100644 drivers/pci/host/pci-keystone.c > create mode 100644 drivers/pci/host/pci-keystone.h > > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: musb: register nop transceiver driver for jz4740
On 07/05/2014 09:47 AM, Apelete Seketeli wrote: Following the name change of the nop transceiver driver in commit 4525bee, make sure to register the transceiver driver before calling Please also specify that commit's summary line in parens. usb_get_phy() to avoid issues related to accessing its data structure while it was not registered. Signed-off-by: Apelete Seketeli WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] declance: Fix 64-bit compilation warnings
On Sat, 5 Jul 2014, Joe Perches wrote: > > > I think it's a mistake and I agree. > > > > > > I submitted a patch to remove the prefix from %pad. > > > > > > https://lkml.org/lkml/2014/3/21/333 > > > > Great! Your proposal looks good to me in principle, however you need to > > factor in SPECIAL having been set by `#' somehow as `number' will respect > > it. I suggest using the same field width calculation that `pointer' uses > > for `default_width' (sans the type used with `sizeof' of course, that is). > > I don't think %#p is valid so it > shouldn't have been set by #. Huh? As recently as last Wednesday you pointed me at the specific commit from Grant that made it valid (GCC format complaints aside). Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] machine_power_off: not only local_irq_disable but also do disable preemption
On Sat, Jul 05, 2014 at 10:44:41PM +0530, pawandeep oza wrote: > process calls sys_reboot and that process then stops other CPUs while those > CPUs are within a spin_lock() region we can potentially encounter a > deadlock > scenario like below. > > CPU 0 CPU 1 > - - > spin_lock(my_lock) > smp_send_stop() > handle_IPI() > disable_preemption/irqs > while(1); > > spin_lock(my_lock) <--- Waits forever Please explain how that occurs with IRQs already disabled. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] declance: Fix 64-bit compilation warnings
On Sat, 2014-07-05 at 18:39 +0100, Maciej W. Rozycki wrote: > On Sat, 5 Jul 2014, Joe Perches wrote: > > > > One question though, does either of you or anybody else know why we're > > > inconsistent about this 0x prefixing of virtual addresses vs physical > > > addresses? Specifically %p vs e.g. %pad. > > > > I think it's a mistake and I agree. > > > > I submitted a patch to remove the prefix from %pad. > > > > https://lkml.org/lkml/2014/3/21/333 > > Great! Your proposal looks good to me in principle, however you need to > factor in SPECIAL having been set by `#' somehow as `number' will respect > it. I suggest using the same field width calculation that `pointer' uses > for `default_width' (sans the type used with `sizeof' of course, that is). I don't think %#p is valid so it shouldn't have been set by #. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [USB spamming log] with 3.16-rc (git) my pl2303 is spaming my logs
On Sat, Jul 05, 2014 at 10:55:57AM -0400, Ed Tomlinson wrote: > Hi > > I have a raspberry PI sending its console to my box via a pl2303 What exact pl2303 is this? Can you provide the output from 'lsusb'? > [5.184385] usbserial: USB Serial support registered for pl2303 > [5.184398] pl2303 1-2.6:1.0: pl2303 converter detected > [5.185353] usb 1-2.6: pl2303 converter now attached to ttyUSB0 > > and with the latest fixes from git on 3.16 its now started spamming my logs > with: > > [55507.155354] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > nonzero urb status: -71 > [55510.736558] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > nonzero urb status: -71 > [55517.238586] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > nonzero urb status: -71 > [55521.099938] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > nonzero urb status: -71 > [55521.778520] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > nonzero urb status: -71 > [55523.229808] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > nonzero urb status: -71 > [55523.229846] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > nonzero urb status: -71 > [55525.074519] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > nonzero urb status: -71 > [55527.270207] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - > nonzero urb status: -71 That's saying there was one of the following errors in this device: a) bitstuff error b) no response packet received within the prescribed bus turn-around time c) unknown USB error All of which point to either a problem in the USB host controller, or the usb device itself. Is this an "unpatched" 3.16-rc kernel running on the rpi? If so, odds are it's a host controller issue... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] drivers/pci/hotplug/cpqphp_sysfs.c: remove unnecessary null test before debugfs_remove
On Sat, Jun 28, 2014 at 11:44:43AM +0200, Fabian Frederick wrote:
> Fix checkpatch warning:
> "WARNING: debugfs_remove(NULL) is safe this check is probably not required"
>
> Cc: Bjorn Helgaas
> Cc: Ryan Desfosses
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Fabian Frederick
Applied to pci/hotplug for v3.17, thanks!
> ---
> drivers/pci/hotplug/cpqphp_sysfs.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/pci/hotplug/cpqphp_sysfs.c
> b/drivers/pci/hotplug/cpqphp_sysfs.c
> index 4a392c4..d81648f 100644
> --- a/drivers/pci/hotplug/cpqphp_sysfs.c
> +++ b/drivers/pci/hotplug/cpqphp_sysfs.c
> @@ -216,8 +216,7 @@ void cpqhp_create_debugfs_files(struct controller *ctrl)
>
> void cpqhp_remove_debugfs_files(struct controller *ctrl)
> {
> - if (ctrl->dentry)
> - debugfs_remove(ctrl->dentry);
> + debugfs_remove(ctrl->dentry);
> ctrl->dentry = NULL;
> }
>
> --
> 1.8.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] regulator: act8865: prepare support for other act88xx devices
On Sat, Jul 05, 2014 at 11:41:26PM +0800, Axel Lin wrote: > 2014-07-05 21:20 GMT+08:00 Beniamino Galvani : > > This patch prepares support for other devices in the act88xx family of > > PMUs manufactured by Active-Semi. > > > > http://www.active-semi.com/products/power-management-units/act88xx/ > > > > Signed-off-by: Beniamino Galvani > > Tested-by: Wenyou Yang > > For this serial, Reviewed-by: Axel Lin Thanks! Beniamino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/19] 3.4.97-stable review
On Sat, Jul 05, 2014 at 10:46:46AM -0700, Greg Kroah-Hartman wrote: > On Fri, Jul 04, 2014 at 10:39:01PM -0700, Guenter Roeck wrote: > > On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote: > > >This is the start of the stable review cycle for the 3.4.97 release. > > >There are 19 patches in this series, all will be posted as a response > > >to this one. If anyone has any issues with these being applied, please > > >let me know. > > > > > >Responses should be made by Sun Jul 6 22:14:29 UTC 2014. > > >Anything received after that time might be too late. > > > > > > > Build results: > > total: 137 pass: 111 skipped: 20 fail: 6 > > 111 skipped? Did you add a bunch more targets? Why skip them? Doh, that is 20 skipped, nevermind... But, in looking at your site, it seems that there are always at least 7 that are "skipped", for all kernel versions. Why? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pciehp: Remove the field controller->no_cmd_completed
On Thu, Jun 26, 2014 at 11:58:55AM -0700, Rajat Jain wrote:
> After following recent cleanups by Bjorn:
>
> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/hotplug
>
> 2cc56f3 PCI: pciehp: Remove assumptions about which commands cause
> 40b9608 PCI: pciehp: Compute timeout from hotplug command start time
> 3461a06 PCI: pciehp: Wait for hotplug command completion lazily
> 4283c70 PCI: pciehp: Make pcie_wait_cmd() self-contained
>
> the bitfield no_cmd_complete is not really needed anymore, as there is
> only a single occurance of its use. Hence remove the unnecessary bit
> field, and use existing macro NO_CMD_CMPL() instead.
>
> Signed-off-by: Rajat Jain
> Signed-off-by: Rajat Jain
> Signed-off-by: Guenter Roeck
Great, thanks for fixing this! Applied to pci/hotplug for v3.17.
> ---
> (This is rebased on top of Bjorn's pci/hotplug branch mentioned above)
>
> drivers/pci/hotplug/pciehp.h |1 -
> drivers/pci/hotplug/pciehp_hpc.c | 11 +--
> 2 files changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
> index c496258..9e5a9fb 100644
> --- a/drivers/pci/hotplug/pciehp.h
> +++ b/drivers/pci/hotplug/pciehp.h
> @@ -96,7 +96,6 @@ struct controller {
> struct timer_list poll_timer;
> unsigned long cmd_started; /* jiffies */
> unsigned int cmd_busy:1;
> - unsigned int no_cmd_complete:1;
> unsigned int link_active_reporting:1;
> unsigned int notification_enabled:1;
> unsigned int power_fault_detected;
> diff --git a/drivers/pci/hotplug/pciehp_hpc.c
> b/drivers/pci/hotplug/pciehp_hpc.c
> index a3a5c65..f7c3709 100644
> --- a/drivers/pci/hotplug/pciehp_hpc.c
> +++ b/drivers/pci/hotplug/pciehp_hpc.c
> @@ -140,7 +140,7 @@ static void pcie_wait_cmd(struct controller *ctrl)
>* If the controller does not generate notifications for command
>* completions, we never need to wait between writes.
>*/
> - if (ctrl->no_cmd_complete)
> + if (NO_CMD_CMPL(ctrl))
> return;
>
> if (!ctrl->cmd_busy)
> @@ -772,15 +772,6 @@ struct controller *pcie_init(struct pcie_device *dev)
> init_waitqueue_head(>queue);
> dbg_ctrl(ctrl);
>
> - /*
> - * Controller doesn't notify of command completion if the "No
> - * Command Completed Support" bit is set in Slot Capabilities.
> - * If set, it means the controller can accept hotplug commands
> - * with no delay between them.
> - */
> - if (NO_CMD_CMPL(ctrl))
> - ctrl->no_cmd_complete = 1;
> -
> /* Check if Data Link Layer Link Active Reporting is implemented */
> pcie_capability_read_dword(pdev, PCI_EXP_LNKCAP, _cap);
> if (link_cap & PCI_EXP_LNKCAP_DLLLARC) {
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/19] 3.4.97-stable review
On Fri, Jul 04, 2014 at 10:39:01PM -0700, Guenter Roeck wrote: > On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.4.97 release. > >There are 19 patches in this series, all will be posted as a response > >to this one. If anyone has any issues with these being applied, please > >let me know. > > > >Responses should be made by Sun Jul 6 22:14:29 UTC 2014. > >Anything received after that time might be too late. > > > > Build results: > total: 137 pass: 111 skipped: 20 fail: 6 111 skipped? Did you add a bunch more targets? Why skip them? thanks for testing, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/19] 3.4.97-stable review
On Sat, Jul 05, 2014 at 03:53:09PM +0900, Satoru Takeuchi wrote: > At Fri, 04 Jul 2014 22:39:01 -0700, > Guenter Roeck wrote: > > > > On 07/04/2014 03:15 PM, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 3.4.97 release. > > > There are 19 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Sun Jul 6 22:14:29 UTC 2014. > > > Anything received after that time might be too late. > > > > > > > Build results: > > total: 137 pass: 111 skipped: 20 fail: 6 > > Failed builds: > > alpha:allmodconfig > > arm:spear6xx_defconfig > > score:defconfig > > sparc64:allmodconfig > > unicore32:defconfig > > xtensa:allmodconfi > > > > Qemu tests all passed. > > > > Results are as expected. > > > > Details are available at http://server.roeck-us.net:8010/builders. > > This kernel passed my test. > > - Test Cases: >- Build this kernel. >- Boot this kernel. >- Build the latest mainline kernel with this kernel. > > - Test Tool: >https://github.com/satoru-takeuchi/test-linux-stable > > - Test Result (kernel .config, ktest config and test log): >http://satoru-takeuchi.org/test-linux-stable/results/- datetime>.tar.xz > > - Build Environment: >- OS: Debian Jessy x86_64 >- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 >- memory: 8GB > > - Test Target Environment: >- Debian Jessy x86_64 (KVM guest on the Build Environment) >- # of vCPU: 2 >- memory: 2GB Great, thanks for testing and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] declance: Fix 64-bit compilation warnings
On Sat, 5 Jul 2014, Joe Perches wrote: > > One question though, does either of you or anybody else know why we're > > inconsistent about this 0x prefixing of virtual addresses vs physical > > addresses? Specifically %p vs e.g. %pad. > > I think it's a mistake and I agree. > > I submitted a patch to remove the prefix from %pad. > > https://lkml.org/lkml/2014/3/21/333 Great! Your proposal looks good to me in principle, however you need to factor in SPECIAL having been set by `#' somehow as `number' will respect it. I suggest using the same field width calculation that `pointer' uses for `default_width' (sans the type used with `sizeof' of course, that is). Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] dra7: Add PCIe support
On Wed, Jun 25, 2014 at 11:26:44PM +0530, Kishon Vijay Abraham I wrote: > [1] is split into separate series in order for individual subsystem > Maintainers to pick up the patches. This series handles the PCIe > support for DRA7. > > Rebased to 3.16-rc2. > > [1] -> https://lkml.org/lkml/2014/5/29/258 > > Kishon Vijay Abraham I (3): > PCI: designware: Configuration space should be specified in 'reg' > PCI: designware: use untranslated address while programming ATU > PCI: host: pcie-dra7xx: add support for pcie-dra7xx controller Mohit, I see your ack for [1/3], but not for [2/3]; are you OK with that, too? Pratyush, you had some questions about [2/3]; are you happy with that one? [3/3] adds the devicetree binding; I'd like somebody to check that out. Also, there's no MAINTAINERS update for pci-dra7xx.c. Kishon, can you include an update for that? Kishon, can you collect the acks and post a v2 series with those and the MAINTAINERS update? Bjorn > > .../devicetree/bindings/pci/designware-pcie.txt|4 + > Documentation/devicetree/bindings/pci/ti-pci.txt | 59 +++ > drivers/pci/host/Kconfig | 10 + > drivers/pci/host/Makefile |1 + > drivers/pci/host/pci-dra7xx.c | 458 > > drivers/pci/host/pcie-designware.c | 66 ++- > drivers/pci/host/pcie-designware.h |4 + > 7 files changed, 589 insertions(+), 13 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt > create mode 100644 drivers/pci/host/pci-dra7xx.c > > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: fbdev: g364fb.c: Cleaning up variable that is never used
On Sat, Jul 5, 2014 at 2:21 PM, Rickard Strandqvist
wrote:
> From: Rickard Strandqvist
>
> Variable ar assigned a value that is never used.
> I have also removed all the code that thereby serves no purpose.
>
> This was found using a static code analysis program called cppcheck
>
> Signed-off-by: Rickard Strandqvist
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PCI: Add bridge DMA alias quirk for Intel 82801
On Mon, Jun 23, 2014 at 04:36:25PM -0600, Alex Williamson wrote: > This bridge sometimes shows up as a root complex device and sometimes > as a discrete PCIe-to-PCI bridge. Testing indicates that in the > latter case, we need to enable the PCIe bridge DMA alias quirk. > > Signed-off-by: Alex Williamson > Reported-by: Milos Kaurin > Tested-by: Milos Kaurin Applied to for-linus for v3.16, thanks! > --- > > drivers/pci/quirks.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 78a7df6..460c354 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -3405,6 +3405,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ASMEDIA, 0x1080, > DECLARE_PCI_FIXUP_HEADER(0x10e3, 0x8113, quirk_use_pcie_bridge_dma_alias); > /* ITE 8892, https://bugzilla.kernel.org/show_bug.cgi?id=73551 */ > DECLARE_PCI_FIXUP_HEADER(0x1283, 0x8892, quirk_use_pcie_bridge_dma_alias); > +/* Intel 82801, https://bugzilla.kernel.org/show_bug.cgi?id=44881#c49 */ > +DECLARE_PCI_FIXUP_HEADER(0x8086, 0x244e, quirk_use_pcie_bridge_dma_alias); > > /* > * AMD has indicated that the devices below do not support peer-to-peer > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
This avoids handling gpiochip remove error in device
remove handler.
Signed-off-by: abdoulaye berthe
---
drivers/gpio/gpiolib.c | 24 +++-
include/linux/gpio/driver.h | 2 +-
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index f48817d..fd4d3cb 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1263,10 +1263,9 @@ static void gpiochip_irqchip_remove(struct gpio_chip
*gpiochip);
*
* A gpio_chip with any GPIOs still requested may not be removed.
*/
-int gpiochip_remove(struct gpio_chip *chip)
+void gpiochip_remove(struct gpio_chip *chip)
{
unsigned long flags;
- int status = 0;
unsignedid;
acpi_gpiochip_remove(chip);
@@ -1278,24 +1277,15 @@ int gpiochip_remove(struct gpio_chip *chip)
of_gpiochip_remove(chip);
for (id = 0; id < chip->ngpio; id++) {
- if (test_bit(FLAG_REQUESTED, >desc[id].flags)) {
- status = -EBUSY;
- break;
- }
- }
- if (status == 0) {
- for (id = 0; id < chip->ngpio; id++)
- chip->desc[id].chip = NULL;
-
- list_del(>list);
+ if (test_bit(FLAG_REQUESTED, >desc[id].flags))
+ dev_crit(chip->dev, "REMOVING GPIOCHIP WITH GPIOS STILL
REQUESTED\n");
}
+ for (id = 0; id < chip->ngpio; id++)
+ chip->desc[id].chip = NULL;
+ list_del(>list);
spin_unlock_irqrestore(_lock, flags);
-
- if (status == 0)
- gpiochip_unexport(chip);
-
- return status;
+ gpiochip_unexport(chip);
}
EXPORT_SYMBOL_GPL(gpiochip_remove);
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 1827b43..ad5c4ef 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -138,7 +138,7 @@ extern const char *gpiochip_is_requested(struct gpio_chip
*chip,
/* add/remove chips */
extern int gpiochip_add(struct gpio_chip *chip);
-extern int __must_check gpiochip_remove(struct gpio_chip *chip);
+extern void gpiochip_remove(struct gpio_chip *chip);
extern struct gpio_chip *gpiochip_find(void *data,
int (*match)(struct gpio_chip *chip, void *data));
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] video: fbdev: omap: omapfb_main.c: Cleaning up removal variable thet is never used
From: Rickard Strandqvist Removal of union member variable thet is never used This was found using a static code analysis program called cppcheck Signed-off-by: Rickard Strandqvist --- drivers/video/fbdev/omap/omapfb_main.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/omap/omapfb_main.c b/drivers/video/fbdev/omap/omapfb_main.c index d8d028d..557aaa3 100644 --- a/drivers/video/fbdev/omap/omapfb_main.c +++ b/drivers/video/fbdev/omap/omapfb_main.c @@ -1096,7 +1096,6 @@ static int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd, enum omapfb_update_mode update_mode; struct omapfb_caps caps; unsigned intmirror; - int plane_out; int enable_plane; } p; int r = 0; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] video: fbdev: omap2: dss: sdi.c: Cleaning up removal variable thet is never used
From: Rickard Strandqvist
Removal of struct member variable thet is never used
This was found using a static code analysis program called cppcheck
Signed-off-by: Rickard Strandqvist
---
drivers/video/fbdev/omap2/dss/sdi.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/sdi.c
b/drivers/video/fbdev/omap2/dss/sdi.c
index 911dcc9..c6491ac 100644
--- a/drivers/video/fbdev/omap2/dss/sdi.c
+++ b/drivers/video/fbdev/omap2/dss/sdi.c
@@ -34,7 +34,6 @@
static struct {
struct platform_device *pdev;
- bool update_enabled;
struct regulator *vdds_sdi_reg;
struct dss_lcd_mgr_config mgr_config;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
