Re: [PATCH V2] workqueue: fix possible race condition when rescuer VS pwq-release

[Lai Jiangshan]

On 04/01/2014 04:06 AM, Tejun Heo wrote:
> On Mon, Mar 31, 2014 at 10:40:47PM +0800, Lai Jiangshan wrote:
>> Ping
> 
> Lai, I'll keep the mail tagged but can you pleaes ping me once -rc1
> drops?  While it is an actual bug, given that it'd be pretty difficult
> to trigger, I don't think it's too urgent.
> 
> Thanks!
> 

Hi, Tejun
Ping.

Very old (resent) patch(1 patch):
workqueue: add __WQ_FREEZING and remove POOL_FREEZING

Possible race condition patch(1 patch), (In this email thread)
workqueue: fix possible race condition when rescuer VS pwq-release

Worker management patchset(6 patches)
workqueue: simpler&better workers management synchronization
  workqueue: generic routine to restore percpu/unbound pools' workers'
cpumask
  workqueue: generic framework to manage normal&rescuer workers'
cpumask
  workqueue: make destroy_worker() atomically
  workqueue: commit worker to pool's concurrency setting atomically.
  workqueue: remove manager_mutex
  workqueue: destroy worker directly in idle timeout handler

Sorry for adding some work to you.

Thanks
Lai
--
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: hpsa driver bug crack kernel down!

[Jiang Liu]

Hi Davidlohr,
Thanks for the information!
According to lspci output, device :02:00.2 is HP ILO
controller, device :03:00.0 is RAID controller. Both ILO and
RAID controllers need to access reserved memory range
[0x7f61e000 - 0x7f61] in physical mode.

According to dmesg output, BIOS has reserved memory and
IOMMU has setup 1:1 mapping for ILO and RAID controller to access
this range. Related log messages as below:
BIOS-e820: [mem 0x7f61d000-0x8fff] reserved
IOMMU: Setting RMRR:
IOMMU: Setting identity map for device :03:00.0 [0x7f61e000 -
0x7f61]
IOMMU: Setting identity map for device :02:00.0 [0x7f61e000 -
0x7f61]
IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 -
0x7f61]

From the screenshot, device :02:00.2 fails to access
memory address 0x7f61e000. That indicates IOMMU driver fails to
setup 1:1 mapping for Reserved Memory Range for ILO controller.
So could you please help to check whether you could observe boot
messages like "IOMMU: Setting identity map for device :02:00.2
[0x7f61e000 - 0x7f61]" with the failure kernel image?

It would be great if boot messages could be saved when
failing to boot, so we could get more information from log.

BTW, I have double checked related code, and still can't
find a reliable explanation for the regression:(

Thanks!
Gerry

On 2014/4/11 0:19, Davidlohr Bueso wrote:
> On Thu, 2014-04-10 at 08:46 +, Woodhouse, David wrote:
>> On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote:
>>> [+ David, VT-d maintainer ]
>>>
>>> Jiang, David, can you please have a look into this issue?
>>>
>>
>>> DMAR:[fault reason 02] Present bit in context entry is clear
>>> dmar: DRHD: handling fault status reg 602
>>> dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000
>>
>> That "Present bit in context entry is clear" fault means that we have
>> not set up *any* mappings for this PCI device… on this IOMMU.
>>
 Yes, specifically (finally done bisecting):

 commit 2e45528930388658603ea24d49cf52867b928d3e
 Author: Jiang Liu 
 Date:   Wed Feb 19 14:07:36 2014 +0800

 iommu/vt-d: Unify the way to process DMAR device scope array
>>
>> This commit is about how we decide which IOMMU a given PCI device is
>> attached to.
>>
>> Thus, my first guess would be that we are quite happily setting up the
>> requested DMA maps on the *wrong* IOMMU, and then taking faults when the
>> device actually tries to do DMA.
>>
>> However, I'm not 100% convinced of that. The fault address looks
>> suspiciously like a true physical address, not a virtual bus address of
>> the type that we'd normally allocate for a dma_map_* operation. Those
>> would start at 0xf000 and work downwards, typically.
>>
>> Do you have 'iommu=pt' on the kernel command line? 
> 
> No.
> 
>> Can I see the full
>> dmesg as this system boots, and also a copy of the DMAR table?
> 
> Attaching a dmesg from one of the kernels that boots. It doesn't appear
> to have much of the related information... is there any debug config
> option I can enable that might give you more data?
> 
--
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] tuntap: add flow control to support back pressure

[Michael S. Tsirkin]

On Mon, Apr 14, 2014 at 12:19:14AM -0400, Steven Galgano wrote:
> On 04/13/2014 09:40 PM, David Miller wrote:
> > From: Steven Galgano 
> > Date: Sun, 13 Apr 2014 21:30:27 -0400
> > 
> >> Added optional per queue flow control support using IFF_FLOW_CONTROL. When 
> >> the IFF_FLOW_CONTROL TUNSETIFF flag is specified it will set a per queue 
> >> flag to indicate that the queue should be stopped using 
> >> netif_tx_stop_queue(), rather than discarding frames once full. After 
> >> reading a frame from the respective stopped queue, a netif_tx_wake_queue() 
> >> is issued to signal resource availability.
> >>
> >> The per queue TUN_FLOW_CONTROL flag is stored in struct tun_file. This 
> >> provides the flexibility to enable flow control on all, none or some 
> >> queues when using IFF_MULTI_QUEUE. When not using IFF_MULTI_QUEUE, 
> >> IFF_FLOW_CONTROL will apply to the single queue. No changes were made to 
> >> the default drop frame policy.
> >>
> >> This change adds support for back pressure use cases.
> >>
> >> Reported-by: Brian Adamson 
> >> Tested-by: Joseph Giovatto 
> >> Signed-off-by: Steven Galgano 
> > 
> > Please format your commit messages to ~80 columns of text.
> > 
> > It won't be automatically formatted by GIT and in fact it looks ugly
> > with all the wrapping in text based tools.
> > 
> Added optional per queue flow control support using IFF_FLOW_CONTROL. When 
> the 
> IFF_FLOW_CONTROL TUNSETIFF flag is specified it will set a per queue flag to 
> indicate that the queue should be stopped using netif_tx_stop_queue(), rather 
> than discarding frames once full. After reading a frame from the respective 
> stopped queue, a netif_tx_wake_queue() is issued to signal resource 
> availability.
> 
> The per queue TUN_FLOW_CONTROL flag is stored in struct tun_file. This 
> provides 
> the flexibility to enable flow control on all, none or some queues when using 
> IFF_MULTI_QUEUE. When not using IFF_MULTI_QUEUE, IFF_FLOW_CONTROL will apply 
> to 
> the single queue. No changes were made to the default drop frame policy.
> 
> This change adds support for back pressure use cases.
> 
> Reported-by: Brian Adamson 
> Tested-by: Joseph Giovatto 
> Signed-off-by: Steven Galgano 
> 

Yes, doing this per-queue is an improvement - but still not ideal.

The issue here is still that a daemon would set the flow control
because it deals with a specific protocol - and affect behaviour of all
potentially unrelated applications - they might deadlock
simply because a packet made its way to tun's qdisc.

I do understand this simple patch works for you for simple setups where
there's more or less a single tun device in the system, but I think it's
worth it to try to address a slightly bigger issue:
both to make the feature more generally applicable, and
to prevent potential problems in case where it's not.

I've been thinking about ways to address it issue, and I think I
see a way, though still a bit vaguely.
Basically, I think the problem would be at least partially solved if we
use a queue that limits packet delay (if I understand correctly
e.g. codel doesn't do this exactly in that it won't drop packets
if queues never fill up).
So instead of QUEUE_STATE_DRV_XOFF tun would set some other bit, that means
"we want to stop transmit queue but can't guarantee we'll
restart it within reasonable time". This bit would also have to be
rate-limited, to prevent not just full deadlock but also performance
degradation.

This could then be done unconditionally: instead of setting
the FLOW_CONTROL bit user would configure this "flow control" queue.

Sorry about posting such rough thoughts, no patch yet but I thought this might
be preferable to silence as I'm going offline for a couple of days.

-- 
MST
--
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 2/2] [RFC v2 with seqcount] reservation: add suppport for read-only access using rcu

[Maarten Lankhorst]

op 11-04-14 21:30, Thomas Hellstrom schreef:

Hi!

On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:

op 11-04-14 12:11, Thomas Hellstrom schreef:

On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:

op 11-04-14 10:38, Thomas Hellstrom schreef:

Hi, Maarten.

Here I believe we encounter a lot of locking inconsistencies.

First, it seems you're use a number of pointers as RCU pointers
without
annotating them as such and use the correct rcu
macros when assigning those pointers.

Some pointers (like the pointers in the shared fence list) are both
used
as RCU pointers (in dma_buf_poll()) for example,
or considered protected by the seqlock
(reservation_object_get_fences_rcu()), which I believe is OK, but then
the pointers must
be assigned using the correct rcu macros. In the memcpy in
reservation_object_get_fences_rcu() we might get away with an
ugly typecast, but with a verbose comment that the pointers are
considered protected by the seqlock at that location.

So I've updated (attached) the headers with proper __rcu annotation
and
locking comments according to how they are being used in the various
reading functions.
I believe if we want to get rid of this we need to validate those
pointers using the seqlock as well.
This will generate a lot of sparse warnings in those places needing
rcu_dereference()
rcu_assign_pointer()
rcu_dereference_protected()

With this I think we can get rid of all ACCESS_ONCE macros: It's not
needed when the rcu_x() macros are used, and
it's never needed for the members protected by the seqlock, (provided
that the seq is tested). The only place where I think that's
*not* the case is at the krealloc in
reservation_object_get_fences_rcu().

Also I have some more comments in the
reservation_object_get_fences_rcu() function below:

I felt that the barriers needed for rcu were already provided by
checking the seqcount lock.
But looking at rcu_dereference makes it seem harmless to add it in
more places, it handles
the ACCESS_ONCE and barrier() for us.

And it makes the code more maintainable, and helps sparse doing a lot of
checking for us. I guess
we can tolerate a couple of extra barriers for that.


We could probably get away with using RCU_INIT_POINTER on the writer
side,
because the smp_wmb is already done by arranging seqcount updates
correctly.

Hmm. yes, probably. At least in the replace function. I think if we do
it in other places, we should add comments as to where
the smp_wmb() is located, for future reference.


Also  I saw in a couple of places where you're checking the shared
pointers, you're not checking for NULL pointers, which I guess may
happen if shared_count and pointers are not in full sync?


No, because shared_count is protected with seqcount. I only allow
appending to the array, so when
shared_count is validated by seqcount it means that the
[0...shared_count) indexes are valid and non-null.
What could happen though is that the fence at a specific index is
updated with another one from the same
context, but that's harmless.

Hmm.
Shouldn't we have a way to clean signaled fences from reservation
objects? Perhaps when we attach a new fence, or after a wait with
ww_mutex held? Otherwise we'd have a lot of completely unused fence
objects hanging around for no reason. I don't think we need to be as
picky as TTM, but I think we should do something?


Calling reservation_object_add_excl_fence with a NULL fence works, I do this in 
ttm_bo_wait().
It requires ww_mutex.

~Maarten
--
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] GenWQE: Use pci_enable_msi_exact() instead of pci_enable_msi_block()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Frank Haverkamp 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Acked-by: Frank Haverkamp 
---
 drivers/misc/genwqe/card_utils.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/misc/genwqe/card_utils.c b/drivers/misc/genwqe/card_utils.c
index 6b1a6ef..294f667 100644
--- a/drivers/misc/genwqe/card_utils.c
+++ b/drivers/misc/genwqe/card_utils.c
@@ -628,7 +628,7 @@ int genwqe_set_interrupt_capability(struct genwqe_dev *cd, 
int count)
int rc;
struct pci_dev *pci_dev = cd->pci_dev;
 
-   rc = pci_enable_msi_block(pci_dev, count);
+   rc = pci_enable_msi_exact(pci_dev, count);
if (rc == 0)
cd->flags |= GENWQE_FLAG_MSI_ENABLED;
return rc;
-- 
1.7.7.6

--
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] PCI/MSI: Phase out pci_enable_msi_block()

[Alexander Gordeev]

There are no users of pci_enable_msi_block() function have
left. Obsolete it in favor of pci_enable_msi_range() and
pci_enable_msi_exact() functions.

Up until now, when enabling MSI mode for a device, a single
successful call to arch_msi_check_device() was followed by
a single call to arch_setup_msi_irqs() function.

Yet, if arch_msi_check_device() returned success we should be
able to call arch_setup_msi_irqs() multiple times - while it
returns a number of MSI vectors that could have been allocated
(a third state).

This update makes use of the assumption described above. It
could have broke things had the architectures done any pre-
allocations or switch to some state in a call to function
arch_msi_check_device(). But because arch_msi_check_device()
is expected stateless and MSI resources are allocated in a
follow-up call to arch_setup_msi_irqs() we should be fine.

Signed-off-by: Alexander Gordeev 
Cc: linux-m...@linux-mips.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/msi.c   |   79 +-
 include/linux/pci.h |5 +--
 2 files changed, 34 insertions(+), 50 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 955ab79..fc669ab 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -883,50 +883,6 @@ int pci_msi_vec_count(struct pci_dev *dev)
 }
 EXPORT_SYMBOL(pci_msi_vec_count);
 
-/**
- * pci_enable_msi_block - configure device's MSI capability structure
- * @dev: device to configure
- * @nvec: number of interrupts to configure
- *
- * Allocate IRQs for a device with the MSI capability.
- * This function returns a negative errno if an error occurs.  If it
- * is unable to allocate the number of interrupts requested, it returns
- * the number of interrupts it might be able to allocate.  If it successfully
- * allocates at least the number of interrupts requested, it returns 0 and
- * updates the @dev's irq member to the lowest new interrupt number; the
- * other interrupt numbers allocated to this device are consecutive.
- */
-int pci_enable_msi_block(struct pci_dev *dev, int nvec)
-{
-   int status, maxvec;
-
-   if (dev->current_state != PCI_D0)
-   return -EINVAL;
-
-   maxvec = pci_msi_vec_count(dev);
-   if (maxvec < 0)
-   return maxvec;
-   if (nvec > maxvec)
-   return maxvec;
-
-   status = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSI);
-   if (status)
-   return status;
-
-   WARN_ON(!!dev->msi_enabled);
-
-   /* Check whether driver already requested MSI-X irqs */
-   if (dev->msix_enabled) {
-   dev_info(&dev->dev, "can't enable MSI "
-"(MSI-X already enabled)\n");
-   return -EINVAL;
-   }
-
-   status = msi_capability_init(dev, nvec);
-   return status;
-}
-EXPORT_SYMBOL(pci_enable_msi_block);
-
 void pci_msi_shutdown(struct pci_dev *dev)
 {
struct msi_desc *desc;
@@ -1132,14 +1088,45 @@ void pci_msi_init_pci_dev(struct pci_dev *dev)
  **/
 int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
 {
-   int nvec = maxvec;
+   int nvec;
int rc;
 
+   if (dev->current_state != PCI_D0)
+   return -EINVAL;
+
+   WARN_ON(!!dev->msi_enabled);
+
+   /* Check whether driver already requested MSI-X irqs */
+   if (dev->msix_enabled) {
+   dev_info(&dev->dev,
+"can't enable MSI (MSI-X already enabled)\n");
+   return -EINVAL;
+   }
+
if (maxvec < minvec)
return -ERANGE;
 
+   nvec = pci_msi_vec_count(dev);
+   if (nvec < 0)
+   return nvec;
+   else if (nvec < minvec)
+   return -EINVAL;
+   else if (nvec > maxvec)
+   nvec = maxvec;
+
+   do {
+   rc = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSI);
+   if (rc < 0) {
+   return rc;
+   } else if (rc > 0) {
+   if (rc < minvec)
+   return -ENOSPC;
+   nvec = rc;
+   }
+   } while (rc);
+
do {
-   rc = pci_enable_msi_block(dev, nvec);
+   rc = msi_capability_init(dev, nvec);
if (rc < 0) {
return rc;
} else if (rc > 0) {
diff --git a/include/linux/pci.h b/include/linux/pci.h
index aab57b4..d8104f4 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1158,7 +1158,6 @@ struct msix_entry {
 
 #ifdef CONFIG_PCI_MSI
 int pci_msi_vec_count(struct pci_dev *dev);
-int pci_enable_msi_block(struct pci_dev *dev, int nvec);
 void pci_msi_shutdown(struct pci_dev *dev);
 void pci_disable_msi(struct pci_dev *dev);
 int pci_msix_vec_count(struct pci_dev *dev);
@@ -1188,8 +1187,6 @@ static inline int pci_enable_msix_exact(struct pci_dev 
*

[PATCH 0/2] Phase out pci_enable_msi_block()

[Alexander Gordeev]

Hello,

This series is against 3.15-rc1.

This update obsoletes pci_enable_msi_block() function in
favor of pci_enable_msi_range() and pci_enable_msi_exact().


Cc: Frank Haverkamp 
Cc: Greg Kroah-Hartman 
Cc: linux-m...@linux-mips.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org


Alexander Gordeev (2):
  GenWQE: Use pci_enable_msi_exact() instead of pci_enable_msi_block()
  PCI/MSI: Phase out pci_enable_msi_block()

 drivers/misc/genwqe/card_utils.c |2 +-
 drivers/pci/msi.c|   79 --
 include/linux/pci.h  |5 +--
 3 files changed, 35 insertions(+), 51 deletions(-)

-- 
1.7.7.6

--
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] efi: Clarify Kconfig help for EFI_MIXED

[Ingo Molnar]

* Matt Fleming  wrote:

> On Fri, 11 Apr, at 11:03:13AM, H. Peter Anvin wrote:
> > On 04/11/2014 10:59 AM, Thomas Bächler wrote:
> > > EFI stub support is only missing for a 64 bit kernel on 32-bit firmware,
> > > on 64-bit kernels, EFI stub works as usual.
> > > ---
> > > 
> > > Matt, I don't know if this help was intentionally discouraging,
> > > however, out of curiosity, I tested this with ovmf, and the
> > > kernel boots fine on 64-bit firmware bit with EFI stub, and on
> > > 32-bit firmware using efilinux.
> > > 
> > > Documenting this properly is important for distribution kernels.
> > > We would want to support this on Arch, but not if it means
> > > introducing a regression for EFI stub users.
> > > 
> > >  arch/x86/Kconfig | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > index 5b8ec0f..2b9 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -1529,8 +1529,8 @@ config EFI_MIXED
> > >  mode.
> > >  
> > >  Note that it is not possible to boot a mixed-mode enabled
> > > -kernel via the EFI boot stub - a bootloader that supports
> > > -the EFI handover protocol must be used.
> > > +kernel via the EFI boot stub on 32-bit firmware - a bootloader
> > > +that supports the EFI handover protocol must be used.
> > >  
> > >  If unsure, say N.
> > >  
> > 
> > Right, it is really that it is not possible to boot a mixed-mode kernel
> > on its non-native firmware using the stub, since the stub itself can
> > only be one way or the other.
> 
> Yeah, my help text was a bit... unhelpful.
> 
> CONFIG_EFI_MIXED does not introduce a regression of any sort, you can
> enable it without worrying about that.
> 
> All the boot configurations that used to work will continue to work.
> 
> What I meant to say was that it isn't possible to use the EFI mixed 
> *feature* (booting a 64-bit kernel with 32-bit firmware) with the 
> EFI boot stub - so you can build support into your kernel but 
> there's no way to make the CPU actually execute those code paths.

Same goes for booting a 32-bit kernel on 64-bit firmware, right?

Thanks,

Ingo
--
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 v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC

[Tarek Dakhran]

EXYNOS5410 is SoC in Samsung's Exynos5 SoC series.
Add initial support for this SoC.

Signed-off-by: Tarek Dakhran 
Signed-off-by: Vyacheslav Tyrtov 
Reviewed-by: Tomasz Figa 
---
 arch/arm/mach-exynos/Kconfig |8 
 arch/arm/mach-exynos/exynos.c|   12 
 arch/arm/mach-exynos/hotplug.c   |4 ++--
 arch/arm/mach-exynos/include/mach/map.h  |1 +
 arch/arm/mach-exynos/platsmp.c   |   10 +++---
 arch/arm/mach-exynos/regs-pmu.h  |4 ++--
 arch/arm/plat-samsung/include/plat/cpu.h |   11 ++-
 7 files changed, 42 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..92f2593 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -84,6 +84,14 @@ config SOC_EXYNOS5250
help
  Enable EXYNOS5250 SoC support
 
+config SOC_EXYNOS5410
+   bool "SAMSUNG EXYNOS5410"
+   default y
+   depends on ARCH_EXYNOS5
+   select PM_GENERIC_DOMAINS if PM_RUNTIME
+   help
+ Enable EXYNOS5410 SoC support
+
 config SOC_EXYNOS5420
bool "SAMSUNG EXYNOS5420"
default y
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..fdb3fb5 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -159,6 +159,15 @@ static struct map_desc exynos5250_iodesc[] __initdata = {
},
 };
 
+static struct map_desc exynos5410_iodesc[] __initdata = {
+   {
+   .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
+   .pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
+   .length = SZ_4K,
+   .type   = MT_DEVICE,
+   },
+};
+
 static struct map_desc exynos5_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -294,6 +303,8 @@ static void __init exynos_map_io(void)
iotable_init(exynos4x12_iodesc, ARRAY_SIZE(exynos4x12_iodesc));
if (soc_is_exynos5250())
iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
+   if (soc_is_exynos5410())
+   iotable_init(exynos5410_iodesc, ARRAY_SIZE(exynos5410_iodesc));
 }
 
 void __init exynos_init_io(void)
@@ -376,6 +387,7 @@ static char const *exynos_dt_compat[] __initconst = {
"samsung,exynos4412",
"samsung,exynos5",
"samsung,exynos5250",
+   "samsung,exynos5410",
"samsung,exynos5420",
"samsung,exynos5440",
NULL
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..83ae5fb 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -95,8 +95,8 @@ static inline void platform_do_lowpower(unsigned int cpu, int 
*spurious)
for (;;) {
 
/* make cpu1 to be turned off at next WFI command */
-   if (cpu == 1)
-   __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+   if (cpu > 0)
+   __raw_writel(0, S5P_ARM_CORE_CONFIGURATION(cpu));
 
/*
 * here's the WFI
diff --git a/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index 7b046b5..894f431 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -29,6 +29,7 @@
 #define EXYNOS4210_PA_SYSRAM_NS0x0203F000
 #define EXYNOS4x12_PA_SYSRAM_NS0x0204F000
 #define EXYNOS5250_PA_SYSRAM_NS0x0204F000
+#define EXYNOS5410_PA_SYSRAM_NS0x02073000
 
 #define EXYNOS_PA_CHIPID   0x1000
 
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 03e5e9f..dce2841 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -37,6 +37,8 @@ static inline void __iomem *cpu_boot_reg_base(void)
 {
if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_1_1)
return S5P_INFORM5;
+   if (soc_is_exynos5410())
+   return S5P_VA_SYSRAM_NS;
return S5P_VA_SYSRAM;
 }
 
@@ -47,6 +49,8 @@ static inline void __iomem *cpu_boot_reg(int cpu)
boot_reg = cpu_boot_reg_base();
if (soc_is_exynos4412())
boot_reg += 4*cpu;
+   else if (soc_is_exynos5410())
+   boot_reg += (0x1c);
else if (soc_is_exynos5420())
boot_reg += 4;
return boot_reg;
@@ -107,14 +111,14 @@ static int exynos_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 */
write_pen_release(phys_cpu);
 
-   if (!(__raw_readl(S5P_ARM_CORE1_STATUS) & S5P_CORE_LOCAL_PWR_EN)) {
+   if (!(__raw_readl(S5P_ARM_CORE_STATUS(cpu)) & S5P_CORE_LOCAL_PWR_EN)) {
__raw_writel(S5P_CORE_LOCAL_PWR_EN,
-S5P_ARM_CORE1_CONFIGURATION);
+S5P_ARM_CORE_CONFIGURA

[PATCH v8 0/3] Exynos 5410 support

[Tarek Dakhran]

The series of patches represent support of Exynos 5410 SoC

The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture

Patches add new platform description, support of clock controller and device
tree for Exynos 5410.

Has been build on Linux Kernel v3.15-rc1
Has been tested on: 1) Exynos 5410 reference board (exynos_defconfig)
2) Odroid-XU board (exynos_defconfig)

I hope, this will be commited to Linux v3.15...

Tarek.

Tarek Dakhran (3):
  ARM: EXYNOS: Add support for EXYNOS5410 SoC
  clk: exynos5410: register clocks using common clock framework
  ARM: dts: Add initial device tree support for EXYNOS5410

 .../devicetree/bindings/clock/exynos5410-clock.txt |   51 +
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/exynos5410-smdk5410.dts  |   65 ++
 arch/arm/boot/dts/exynos5410.dtsi  |  140 
 arch/arm/mach-exynos/Kconfig   |8 +
 arch/arm/mach-exynos/exynos.c  |   12 ++
 arch/arm/mach-exynos/hotplug.c |4 +-
 arch/arm/mach-exynos/include/mach/map.h|1 +
 arch/arm/mach-exynos/platsmp.c |   10 +-
 arch/arm/mach-exynos/regs-pmu.h|4 +-
 arch/arm/plat-samsung/include/plat/cpu.h   |   11 +-
 drivers/clk/samsung/Makefile   |1 +
 drivers/clk/samsung/clk-exynos5410.c   |  223 
 include/dt-bindings/clock/exynos5410.h |   33 +++
 14 files changed, 556 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt
 create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts
 create mode 100644 arch/arm/boot/dts/exynos5410.dtsi
 create mode 100644 drivers/clk/samsung/clk-exynos5410.c
 create mode 100644 include/dt-bindings/clock/exynos5410.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/

[PATCH v8 2/3] clk: exynos5410: register clocks using common clock framework

[Tarek Dakhran]

The EXYNOS5410 clocks are statically listed and registered
using the Samsung specific common clock helper functions.

Signed-off-by: Tarek Dakhran 
Signed-off-by: Vyacheslav Tyrtov 
Acked-by: Tomasz Figa 
---
 .../devicetree/bindings/clock/exynos5410-clock.txt |   51 +
 drivers/clk/samsung/Makefile   |1 +
 drivers/clk/samsung/clk-exynos5410.c   |  223 
 include/dt-bindings/clock/exynos5410.h |   33 +++
 4 files changed, 308 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt
 create mode 100644 drivers/clk/samsung/clk-exynos5410.c
 create mode 100644 include/dt-bindings/clock/exynos5410.h

diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
new file mode 100644
index 000..82337c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
@@ -0,0 +1,51 @@
+* Samsung Exynos5410 Clock Controller
+
+The Exynos5410 clock controller generates and supplies clock to various
+controllers within the Exynos5410 SoC.
+
+Required Properties:
+
+- compatible: should be "samsung,exynos5410-clock"
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5410.h header and can be used in device
+tree sources.
+
+External clock:
+There is clock that is generated outside the SoC. It is expected
+that it is defined using standard clock bindings with following
+ - compatible: should be "samsung,exynos5410-oscclk"
+
+Example 1: An example of a clock controller node is listed below.
+
+   clock: clock-controller@0x1001 {
+   compatible = "samsung,exynos5410-clock";
+   reg = <0x1001 0x3>;
+   #clock-cells = <1>;
+   };
+
+Example 2: Required external clock.
+
+   fixed-rate-clocks {
+   oscclk {
+   compatible = "samsung,exynos5410-oscclk";
+   clock-frequency = <2400>;
+   };
+   };
+
+Example 3: UART controller node that consumes the clock generated by the clock
+  controller. Refer to the standard clock bindings for information
+  about 'clocks' and 'clock-names' property.
+
+   serial@12C2 {
+   compatible = "samsung,exynos4210-uart";
+   reg = <0x12C0 0x100>;
+   interrupts = <0 51 0>;
+   clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>;
+   clock-names = "uart", "clk_uart_baud0";
+   };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..b572dd7 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -5,6 +5,7 @@
 obj-$(CONFIG_COMMON_CLK)   += clk.o clk-pll.o
 obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
 obj-$(CONFIG_SOC_EXYNOS5250)   += clk-exynos5250.o
+obj-$(CONFIG_SOC_EXYNOS5410)   += clk-exynos5410.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
 obj-$(CONFIG_SOC_EXYNOS5440)   += clk-exynos5440.o
 obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos-audss.o
diff --git a/drivers/clk/samsung/clk-exynos5410.c 
b/drivers/clk/samsung/clk-exynos5410.c
new file mode 100644
index 000..7fdc17a
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos5410.c
@@ -0,0 +1,223 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for Exynos5410 SoC.
+*/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+#define APLL_LOCK   0x0
+#define APLL_CON0   0x100
+#define CPLL_LOCK   0x10020
+#define CPLL_CON0   0x10120
+#define MPLL_LOCK   0x4000
+#define MPLL_CON0   0x4100
+#define BPLL_LOCK   0x20010
+#define BPLL_CON0   0x20110
+#define KPLL_LOCK   0x28000
+#define KPLL_CON0   0x28100
+
+#define SRC_CPU0x200
+#define DIV_CPU0   0x500
+#define SRC_CPERI1 0x4204
+#define DIV_TOP0   0x10510
+#define DIV_TOP1   0x10514
+#define DIV_FSYS1  0x1054c
+#define DIV_FSYS2  0x10550
+#define DIV_PERIC0 0x10558
+#define SRC_TOP0   0x10210
+#define SRC_TOP1   0x10214
+#define SRC_TOP2   0x10218
+#define SRC_FSYS   0x10244
+#define SRC_PERIC0 0x10250
+#define SRC_MASK_FSYS  0x10340
+#define SRC_MASK_PERIC00x10350
+#define GATE_BUS_FSYS0 0x10740
+#define GATE_IP_FSYS   0x1094

[PATCH v8 3/3] ARM: dts: Add initial device tree support for EXYNOS5410

[Tarek Dakhran]

Add initial device tree nodes for EXYNOS5410 SoC and SMDK5410 board.

Signed-off-by: Tarek Dakhran 
Signed-off-by: Vyacheslav Tyrtov 
Reviewed-by: Tomasz Figa 
---
 arch/arm/boot/dts/Makefile|1 +
 arch/arm/boot/dts/exynos5410-smdk5410.dts |   65 ++
 arch/arm/boot/dts/exynos5410.dtsi |  140 +
 3 files changed, 206 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts
 create mode 100644 arch/arm/boot/dts/exynos5410.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..191dd19 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
exynos5420-arndale-octa.dtb \
+   exynos5410-smdk5410.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts 
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
new file mode 100644
index 000..d69e152
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -0,0 +1,65 @@
+/*
+ * SAMSUNG SMDK5410 board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include "exynos5410.dtsi"
+/ {
+   model = "Samsung SMDK5410 board based on EXYNOS5410";
+   compatible = "samsung,smdk5410", "samsung,exynos5410";
+
+   memory {
+   reg = <0x4000 0x8000>;
+   };
+
+   chosen {
+   bootargs = "console=ttySAC2,115200";
+   };
+
+   fixed-rate-clocks {
+   oscclk {
+   compatible = "samsung,exynos5410-oscclk";
+   clock-frequency = <2400>;
+   };
+   };
+
+   mmc@1220 {
+   status = "okay";
+   num-slots = <1>;
+   supports-highspeed;
+   broken-cd;
+   card-detect-delay = <200>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <2 3>;
+   samsung,dw-mshc-ddr-timing = <1 2>;
+
+   slot@0 {
+   reg = <0>;
+   bus-width = <8>;
+   };
+   };
+
+   mmc@1222 {
+   status = "okay";
+   num-slots = <1>;
+   supports-highspeed;
+   card-detect-delay = <200>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <2 3>;
+   samsung,dw-mshc-ddr-timing = <1 2>;
+
+   slot@0 {
+   reg = <0>;
+   bus-width = <4>;
+   disable-wp;
+   };
+   };
+
+};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
new file mode 100644
index 000..e7cc930
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -0,0 +1,140 @@
+/*
+ * SAMSUNG EXYNOS5410 SoC device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SAMSUNG EXYNOS5410 SoC device nodes are listed in this file.
+ * EXYNOS5410 based board files can include this file and provide
+ * values for board specfic bindings.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include "exynos5.dtsi"
+/ {
+   compatible = "samsung,exynos5410", "samsung,exynos5";
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   CPU0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <0>;
+   clock-frequency = <16>;
+   };
+
+   CPU1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <1>;
+   clock-frequency = <16>;
+   };
+
+   CPU2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <2>;
+   clock-frequency = <16>;
+   };
+
+   CPU3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <3>;
+   clock-frequency = <16>;
+   };
+   };
+
+   clock: clock-controller@1001

Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

[Ingo Molnar]

* Borislav Petkov  wrote:

> On Sat, Apr 12, 2014 at 05:13:40PM -0400, Brian Gerst wrote:
> > Performance is bad in general, running a 32-bit Fedora 20 guest.
> 
> So this means you haven't tried the game in the guest yet, so that 
> we can know for sure that a guest doesn't solve your problem or 
> what?
> 
> Btw, which game is that and can I get it somewhere to try it here 
> locally?

Apparently the game in question is "Exile: Escape from the pit":

  http://osdir.com/ml/wine-bugs/2014-04/msg01159.html

Thanks,

Ingo

--
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:sched/urgent] sched/numa: Fix task_numa_free() lockdep splat

[tip-bot for Mike Galbraith]

Commit-ID:  60e69eed85bb7b5198ef70643b5895c26ad76ef7
Gitweb: http://git.kernel.org/tip/60e69eed85bb7b5198ef70643b5895c26ad76ef7
Author: Mike Galbraith 
AuthorDate: Mon, 7 Apr 2014 10:55:15 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 11 Apr 2014 10:39:15 +0200

sched/numa: Fix task_numa_free() lockdep splat

Sasha reported that lockdep claims that the following commit:
made numa_group.lock interrupt unsafe:

  156654f491dd ("sched/numa: Move task_numa_free() to __put_task_struct()")

While I don't see how that could be, given the commit in question moved
task_numa_free() from one irq enabled region to another, the below does
make both gripes and lockups upon gripe with numa=fake=4 go away.

Reported-by: Sasha Levin 
Fixes: 156654f491dd ("sched/numa: Move task_numa_free() to __put_task_struct()")
Signed-off-by: Mike Galbraith 
Signed-off-by: Peter Zijlstra 
Cc: torva...@linux-foundation.org
Cc: mgor...@suse.com
Cc: a...@linux-foundation.org
Cc: Dave Jones 
Link: http://lkml.kernel.org/r/1396860915.5170.5.ca...@marge.simpson.net
Signed-off-by: Ingo Molnar 
---
 kernel/sched/fair.c  | 13 +++--
 kernel/sched/sched.h |  9 +
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7e9bd0b..4f14a65 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1497,7 +1497,7 @@ static void task_numa_placement(struct task_struct *p)
/* If the task is part of a group prevent parallel updates to group 
stats */
if (p->numa_group) {
group_lock = &p->numa_group->lock;
-   spin_lock(group_lock);
+   spin_lock_irq(group_lock);
}
 
/* Find the node with the highest number of faults */
@@ -1572,7 +1572,7 @@ static void task_numa_placement(struct task_struct *p)
}
}
 
-   spin_unlock(group_lock);
+   spin_unlock_irq(group_lock);
}
 
/* Preferred node as the node with the most faults */
@@ -1677,7 +1677,8 @@ static void task_numa_group(struct task_struct *p, int 
cpupid, int flags,
if (!join)
return;
 
-   double_lock(&my_grp->lock, &grp->lock);
+   BUG_ON(irqs_disabled());
+   double_lock_irq(&my_grp->lock, &grp->lock);
 
for (i = 0; i < NR_NUMA_HINT_FAULT_STATS * nr_node_ids; i++) {
my_grp->faults[i] -= p->numa_faults_memory[i];
@@ -1691,7 +1692,7 @@ static void task_numa_group(struct task_struct *p, int 
cpupid, int flags,
grp->nr_tasks++;
 
spin_unlock(&my_grp->lock);
-   spin_unlock(&grp->lock);
+   spin_unlock_irq(&grp->lock);
 
rcu_assign_pointer(p->numa_group, grp);
 
@@ -1710,14 +1711,14 @@ void task_numa_free(struct task_struct *p)
void *numa_faults = p->numa_faults_memory;
 
if (grp) {
-   spin_lock(&grp->lock);
+   spin_lock_irq(&grp->lock);
for (i = 0; i < NR_NUMA_HINT_FAULT_STATS * nr_node_ids; i++)
grp->faults[i] -= p->numa_faults_memory[i];
grp->total_faults -= p->total_numa_faults;
 
list_del(&p->numa_entry);
grp->nr_tasks--;
-   spin_unlock(&grp->lock);
+   spin_unlock_irq(&grp->lock);
rcu_assign_pointer(p->numa_group, NULL);
put_numa_group(grp);
}
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index c9007f2..456e492 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1385,6 +1385,15 @@ static inline void double_lock(spinlock_t *l1, 
spinlock_t *l2)
spin_lock_nested(l2, SINGLE_DEPTH_NESTING);
 }
 
+static inline void double_lock_irq(spinlock_t *l1, spinlock_t *l2)
+{
+   if (l1 > l2)
+   swap(l1, l2);
+
+   spin_lock_irq(l1);
+   spin_lock_nested(l2, SINGLE_DEPTH_NESTING);
+}
+
 static inline void double_raw_lock(raw_spinlock_t *l1, raw_spinlock_t *l2)
 {
if (l1 > l2)
--
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] ARM: dts: omap5: Add clocks to USB3 PHY node

[Roger Quadros]

Hi Tony,

On 04/01/2014 05:13 PM, Felipe Balbi wrote:
> On Tue, Apr 01, 2014 at 01:37:27PM +0300, Roger Quadros wrote:
>> The USB3 PHY driver (ti-pipe3) was updated so that the relevant
>> clock phandles are expected in the DT node.
>> Provide the necessary clocks.
>>
>> Reported-by: Kishon Vijay Abraham I 
>> Signed-off-by: Roger Quadros 
> 
> Great!!!
> 
> Acked-by: Felipe Balbi 

Could you please pick this up for 3.15-rc? Thanks.

cheers,
-roger

> 
>> ---
>>  arch/arm/boot/dts/omap5.dtsi | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>> index 757f0b9..4df1e7a 100644
>> --- a/arch/arm/boot/dts/omap5.dtsi
>> +++ b/arch/arm/boot/dts/omap5.dtsi
>> @@ -794,6 +794,12 @@
>><0x4a084c00 0x40>;
>>  reg-names = "phy_rx", "phy_tx", "pll_ctrl";
>>  ctrl-module = <&omap_control_usb3phy>;
>> +clocks = <&usb_phy_cm_clk32k>,
>> + <&sys_clkin>,
>> + <&usb_otg_ss_refclk960m>;
>> +clock-names =   "wkupclk",
>> +"sysclk",
>> +"refclk";
>>  #phy-cells = <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] [PATCH V2] tty: memleak in alloc_pid

[Chen Tingjie]

There is memleak in alloc_pid:
--
unreferenced object 0xd3453a80 (size 64):
  comm "adbd", pid 1730, jiffies 66363 (age 6586.950s)
  hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 40 c2 f6 d5 00 d3 25 c1 59 28 00 00  @.%.Y(..
  backtrace:
[] kmemleak_alloc+0x3c/0xa0
[] kmem_cache_alloc+0xc6/0x190
[] alloc_pid+0x1e/0x400
[] copy_process.part.39+0xad4/0x1120
[] do_fork+0x99/0x330
[] sys_fork+0x28/0x30
[] syscall_call+0x7/0xb
[] 0x

the leak is due to unreleased pid->count, which execute in function:
get_pid()(pid->count++) and put_pid()(pid->count--).

The race condition as following:
task[dumpsys]   task[adbd]
in disassociate_ctty()  in tty_signal_session_leader()
--- -
tty = get_current_tty();
// tty is not NULL
...
spin_lock_irq(¤t->sighand->siglock);
put_pid(current->signal->tty_old_pgrp);
current->signal->tty_old_pgrp = NULL;
spin_unlock_irq(¤t->sighand->siglock);

spin_lock_irq(&p->sighand->siglock);
...
p->signal->tty = NULL;
...
spin_unlock_irq(&p->sighand->siglock);

tty = get_current_tty();
// tty NULL, goto else branch by accident.
if (tty) {
...
put_pid(tty_session);
put_pid(tty_pgrp);
...
} else {
print msg
}

in task[dumpsys], in disassociate_ctty(), tty is set NULL by task[adbd],
tty_signal_session_leader(), then it goto else branch and lack of
put_pid(), cause memleak.

move spin_unlock(sighand->siglock) after get_current_tty() can avoid
the race and fix the memleak.

Change-Id: Ic960dda039c8f99aad3e0f4d176489a966c62f6a
Signed-off-by: Zhang Jun 
Signed-off-by: Chen Tingjie 
---
 drivers/tty/tty_io.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 31c4a57..72547a3 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -874,9 +874,8 @@ void disassociate_ctty(int on_exit)
spin_lock_irq(¤t->sighand->siglock);
put_pid(current->signal->tty_old_pgrp);
current->signal->tty_old_pgrp = NULL;
-   spin_unlock_irq(¤t->sighand->siglock);
 
-   tty = get_current_tty();
+   tty = tty_kref_get(current->signal->tty);
if (tty) {
unsigned long flags;
spin_lock_irqsave(&tty->ctrl_lock, flags);
@@ -893,6 +892,7 @@ void disassociate_ctty(int on_exit)
 #endif
}
 
+   spin_unlock_irq(¤t->sighand->siglock);
/* Now clear signal->tty under the lock */
read_lock(&tasklist_lock);
session_clear_tty(task_session(current));
-- 
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 1/1] FS: Add generic data flush to fsync

[Christoph Hellwig]

On Fri, Apr 11, 2014 at 11:05:30PM +0200, Fabian Frederick wrote:
> Ok, that would mean 'older' filesystems -without barrier flag-
> to call generic_file_fsync would result in a flush but ext4 without journal 
> also calls it ; maybe with nobarrier and I'm not sure it's the only case.
> How can I deal with this problem ?

I don't really think not implementing the barrier option is a problem.
For ext4 if you want consistency either opencode generic_file_fsync
there and add the check, or add a __generic_file_fsync that doesn't
do the flush.
--
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:x86/urgent] x86/platform: Fix "make O=dir kvmconfig"

[tip-bot for Antonio Borneo]

Commit-ID:  f96364041ccda63ff4bed96fd06b267d8d841dc0
Gitweb: http://git.kernel.org/tip/f96364041ccda63ff4bed96fd06b267d8d841dc0
Author: Antonio Borneo 
AuthorDate: Sun, 13 Apr 2014 16:26:08 +0800
Committer:  Ingo Molnar 
CommitDate: Mon, 14 Apr 2014 08:50:36 +0200

x86/platform: Fix "make O=dir kvmconfig"

Running:

make O=dir x86_64_defconfig
make O=dir kvmconfig

the second command dirties the source tree with file ".config",
symlink "source" and objects in folder "scripts".

Fixed by using properly prefixed paths in the arch Makefile.

Signed-off-by: Antonio Borneo 
Acked-by: Borislav Petkov 
Cc: Pekka Enberg 
Link: 
http://lkml.kernel.org/r/1397377568-8375-1-git-send-email-borneo.anto...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 3b9348a..0db8910 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -250,8 +250,8 @@ archclean:
 PHONY += kvmconfig
 kvmconfig:
$(if $(wildcard $(objtree)/.config),, $(error You need an existing 
.config for this target))
-   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m -O 
$(objtree) $(objtree)/.config arch/x86/configs/kvm_guest.config
-   $(Q)yes "" | $(MAKE) oldconfig
+   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m -O 
$(objtree) $(objtree)/.config $(srctree)/arch/x86/configs/kvm_guest.config
+   $(Q)yes "" | $(MAKE) -f $(srctree)/Makefile oldconfig
 
 define archhelp
   echo  '* bzImage  - Compressed kernel image (arch/x86/boot/bzImage)'
--
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:core/urgent] locking/mutex: Fix debug_mutexes

[tip-bot for Peter Zijlstra]

Commit-ID:  a227960fe0cafcc229a8d6bb8b454a3a0b33719d
Gitweb: http://git.kernel.org/tip/a227960fe0cafcc229a8d6bb8b454a3a0b33719d
Author: Peter Zijlstra 
AuthorDate: Thu, 10 Apr 2014 16:15:59 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 11 Apr 2014 10:40:35 +0200

locking/mutex: Fix debug_mutexes

debug_mutex_unlock() would bail when !debug_locks and forgets to
actually unlock.

Reported-by: "Michael L. Semon" 
Reported-by: "Kirill A. Shutemov" 
Reported-by: Valdis Kletnieks 
Fixes: 6f008e72cd11 ("locking/mutex: Fix debug checks")
Tested-by: Dave Jones 
Cc: Jason Low 
Signed-off-by: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/20140410141559.ge13...@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
---
 kernel/locking/mutex-debug.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
index e1191c9..5cf6731 100644
--- a/kernel/locking/mutex-debug.c
+++ b/kernel/locking/mutex-debug.c
@@ -71,18 +71,17 @@ void mutex_remove_waiter(struct mutex *lock, struct 
mutex_waiter *waiter,
 
 void debug_mutex_unlock(struct mutex *lock)
 {
-   if (unlikely(!debug_locks))
-   return;
+   if (likely(debug_locks)) {
+   DEBUG_LOCKS_WARN_ON(lock->magic != lock);
 
-   DEBUG_LOCKS_WARN_ON(lock->magic != lock);
+   if (!lock->owner)
+   DEBUG_LOCKS_WARN_ON(!lock->owner);
+   else
+   DEBUG_LOCKS_WARN_ON(lock->owner != current);
 
-   if (!lock->owner)
-   DEBUG_LOCKS_WARN_ON(!lock->owner);
-   else
-   DEBUG_LOCKS_WARN_ON(lock->owner != current);
-
-   DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next);
-   mutex_clear_owner(lock);
+   DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && 
!lock->wait_list.next);
+   mutex_clear_owner(lock);
+   }
 
/*
 * __mutex_slowpath_needs_to_unlock() is explicitly 0 for debug
--
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:x86/urgent] x86/gpu: Fix sign extension issue in Intel graphics stolen memory quirks

[tip-bot for Ville Syrjälä]

Commit-ID:  86e587623a0ca8426267dad8d3eaebd6fc2d00f1
Gitweb: http://git.kernel.org/tip/86e587623a0ca8426267dad8d3eaebd6fc2d00f1
Author: Ville Syrjälä 
AuthorDate: Sun, 13 Apr 2014 12:45:03 +0300
Committer:  Ingo Molnar 
CommitDate: Mon, 14 Apr 2014 08:50:56 +0200

x86/gpu: Fix sign extension issue in Intel graphics stolen memory quirks

Have the KB(),MB(),GB() macros produce unsigned longs to avoid
unintended sign extension issues with the gen2 memory size
detection.

What happens is first the uint8_t returned by
read_pci_config_byte() gets promoted to an int which gets
multiplied by another int from the MB() macro, and finally the
result gets sign extended to size_t.

Although this shouldn't be a problem in practice as all affected
gen2 platforms are 32bit AFAIK, so size_t will be 32 bits.

Reported-by: Bjorn Helgaas 
Suggested-by: H. Peter Anvin 
Signed-off-by: Ville Syrjälä 
Cc: linux-kernel@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1397382303-17525-1-git-send-email-ville.syrj...@linux.intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/early-quirks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index b0cc380..6e2537c 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -240,7 +240,7 @@ static u32 __init intel_stolen_base(int num, int slot, int 
func, size_t stolen_s
return base;
 }
 
-#define KB(x)  ((x) * 1024)
+#define KB(x)  ((x) * 1024UL)
 #define MB(x)  (KB (KB (x)))
 #define GB(x)  (MB (KB (x)))
 
--
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: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

[Ingo Molnar]

* H. Peter Anvin  wrote:

> On 04/11/2014 11:41 AM, Linus Torvalds wrote:
> > 
> > Ok, so you actually do this on x86-64, and it currently works? For
> > some reason I thought that 16-bit windows apps already didn't work.
> > 
> 
> Some will work, because not all 16-bit software care about the upper
> half of ESP getting randomly corrupted.
> 
> That is the "functionality bit" of the problem.  The other bit, of
> course, is that that random corruption is the address of the kernel stack.
> 
> > Because if we have working users of this, then I don't think we can do
> > the "we don't support 16-bit segments", or at least we need to make it
> > runtime configurable.
> 
> I'll let you pick what the policy should be here.  I personally 
> think that we have to be able to draw a line somewhere sometimes 
> (Microsoft themselves haven't supported running 16-bit binaries for 
> several Windows generations now), but it is your policy, not mine.

I think the mmap_min_addr model works pretty well:

 - it defaults to secure

 - allow a security policy to grant an exception to a known package, 
   built by the distro

 - end user can also grant an exception

This essentially punts any 'makes the system less secure' exceptions 
to the distro and the end user.

Thanks,

Ingo
--
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 v4 0/5] rework sched_domain topology description

[Vincent Guittot]

On 12 April 2014 14:56, Dietmar Eggemann  wrote:
> On 11/04/14 10:44, Vincent Guittot wrote:
>>
>> This patchset was previously part of the larger tasks packing patchset
>> [1].
>> I have splitted the latter in 3 different patchsets (at least) to make the
>> thing easier.
>> -configuration of sched_domain topology (this patchset)
>> -update and consolidation of cpu_power
>> -tasks packing algorithm
>>
>> Based on Peter Z's proposal [2][3], this patchset modifies the way to
>> configure
>> the sched_domain level in order to let architectures to add specific level
>> like
>> the current BOOK level or the proposed power gating level for ARM
>> architecture.
>>
>> [1] https://lkml.org/lkml/2013/10/18/121
>> [2] https://lkml.org/lkml/2013/11/5/239
>> [3] https://lkml.org/lkml/2013/11/5/449
>
>
> Hi Vincent,
>
> given the discussion we had for v1-v3 and a short boot test of v4:
>
> For patch 1/5, 4/5, 5/5 on ARM TC2 (heterogeneous dual socket w/o SMT
> machine):
>
> Reviewed-by: Dietmar Eggemann 
> Tested-by: Dietmar Eggemann 
>

Thanks

> Cheers,
>
> -- Dietmar
>
>
>>
>> Change since v3:
>> - remove last patch which was adding SD_SHARE_POWER_DOMAIN for powerpc's
>> SMT
>>level
>>
>> Change since v2:
>> - remove patch 1 as it has been already applied to metag tree for v3.15
>> - updates some commit messages
>> - add new flag description in TOPOLOGY_SD_FLAGS description
>>
>> Change since v1:
>> - move sched_domains_curr_level back under #ifdef CONFIG_NUMA
>> - use function pointer to set flag instead of a plain value.
>> - add list of tunable flags in the commit message of patch 2
>> - add SD_SHARE_POWER_DOMAIN flag for powerpc's SMT level
>>
>> Vincent Guittot (5):
>>sched: rework of sched_domain topology definition
>>sched: s390: create a dedicated topology table
>>sched: powerpc: create a dedicated topology table
>>sched: add a new SD_SHARE_POWERDOMAIN for sched_domain
>>sched: ARM: create a dedicated scheduler topology table
>>
>>   arch/arm/kernel/topology.c   |  26 +
>>   arch/ia64/include/asm/topology.h |  24 
>>   arch/powerpc/kernel/smp.c|  31 +++--
>>   arch/s390/include/asm/topology.h |  13 +--
>>   arch/s390/kernel/topology.c  |  20 
>>   arch/tile/include/asm/topology.h |  33 --
>>   include/linux/sched.h|  49 +++-
>>   include/linux/topology.h | 128 +++-
>>   kernel/sched/core.c  | 244
>> ---
>>   9 files changed, 255 insertions(+), 313 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: [PATCH v3 0/5] hugetlb: add support gigantic page allocation at runtime

[Zhang Yanfei]

Clear explanation and implementation!

Reviewed-by: Zhang Yanfei 

On 04/11/2014 01:58 AM, Luiz Capitulino wrote:
> [Full introduction right after the changelog]
> 
> Changelog
> -
> 
> v3
> 
> - Dropped unnecessary WARN_ON() call [Kirill]
> - Always check if the pfn range lies within a zone [Yasuaki]
> - Renamed some function arguments for consistency
> 
> v2
> 
> - Rewrote allocation loop to avoid scanning unless PFNs [Yasuaki]
> - Dropped incomplete multi-arch support [Naoya]
> - Added patch to drop __init from prep_compound_gigantic_page()
> - Restricted the feature to x86_64 (more details in patch 5/5)
> - Added review-bys plus minor changelog changes
> 
> Introduction
> 
> 
> The HugeTLB subsystem uses the buddy allocator to allocate hugepages during
> runtime. This means that hugepages allocation during runtime is limited to
> MAX_ORDER order. For archs supporting gigantic pages (that is, page sizes
> greater than MAX_ORDER), this in turn means that those pages can't be
> allocated at runtime.
> 
> HugeTLB supports gigantic page allocation during boottime, via the boot
> allocator. To this end the kernel provides the command-line options
> hugepagesz= and hugepages=, which can be used to instruct the kernel to
> allocate N gigantic pages during boot.
> 
> For example, x86_64 supports 2M and 1G hugepages, but only 2M hugepages can
> be allocated and freed at runtime. If one wants to allocate 1G gigantic pages,
> this has to be done at boot via the hugepagesz= and hugepages= command-line
> options.
> 
> Now, gigantic page allocation at boottime has two serious problems:
> 
>  1. Boottime allocation is not NUMA aware. On a NUMA machine the kernel
> evenly distributes boottime allocated hugepages among nodes.
> 
> For example, suppose you have a four-node NUMA machine and want
> to allocate four 1G gigantic pages at boottime. The kernel will
> allocate one gigantic page per node.
> 
> On the other hand, we do have users who want to be able to specify
> which NUMA node gigantic pages should allocated from. So that they
> can place virtual machines on a specific NUMA node.
> 
>  2. Gigantic pages allocated at boottime can't be freed
> 
> At this point it's important to observe that regular hugepages allocated
> at runtime don't have those problems. This is so because HugeTLB interface
> for runtime allocation in sysfs supports NUMA and runtime allocated pages
> can be freed just fine via the buddy allocator.
> 
> This series adds support for allocating gigantic pages at runtime. It does
> so by allocating gigantic pages via CMA instead of the buddy allocator.
> Releasing gigantic pages is also supported via CMA. As this series builds
> on top of the existing HugeTLB interface, it makes gigantic page allocation
> and releasing just like regular sized hugepages. This also means that NUMA
> support just works.
> 
> For example, to allocate two 1G gigantic pages on node 1, one can do:
> 
>  # echo 2 > \
>/sys/devices/system/node/node1/hugepages/hugepages-1048576kB/nr_hugepages
> 
> And, to release all gigantic pages on the same node:
> 
>  # echo 0 > \
>/sys/devices/system/node/node1/hugepages/hugepages-1048576kB/nr_hugepages
> 
> Please, refer to patch 5/5 for full technical details.
> 
> Finally, please note that this series is a follow up for a previous series
> that tried to extend the command-line options set to be NUMA aware:
> 
>  http://marc.info/?l=linux-mm&m=139593335312191&w=2
> 
> During the discussion of that series it was agreed that having runtime
> allocation support for gigantic pages was a better solution.
> 
> Luiz Capitulino (5):
>   hugetlb: prep_compound_gigantic_page(): drop __init marker
>   hugetlb: add hstate_is_gigantic()
>   hugetlb: update_and_free_page(): don't clear PG_reserved bit
>   hugetlb: move helpers up in the file
>   hugetlb: add support for gigantic page allocation at runtime
> 
>  include/linux/hugetlb.h |   5 +
>  mm/hugetlb.c| 336 
> ++--
>  2 files changed, 245 insertions(+), 96 deletions(-)
> 


-- 
Thanks.
Zhang Yanfei
--
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] fs/jfs/jfs_inode.c: atomically set inode->i_flags

[Fabian Frederick]

According to commit 5f16f3225b0624

ext4: atomically set inode->i_flags in ext4_set_inode_flags()

Inspired-by: "Theodore Ts'o" 
Cc: Dave Kleikamp 
Cc: "Theodore Ts'o" 
Signed-off-by: Fabian Frederick 
---
 fs/jfs/jfs_inode.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/fs/jfs/jfs_inode.c b/fs/jfs/jfs_inode.c
index 7f464c5..6b0f816 100644
--- a/fs/jfs/jfs_inode.c
+++ b/fs/jfs/jfs_inode.c
@@ -29,20 +29,20 @@
 void jfs_set_inode_flags(struct inode *inode)
 {
unsigned int flags = JFS_IP(inode)->mode2;
-
-   inode->i_flags &= ~(S_IMMUTABLE | S_APPEND |
-   S_NOATIME | S_DIRSYNC | S_SYNC);
+   unsigned int new_fl = 0;
 
if (flags & JFS_IMMUTABLE_FL)
-   inode->i_flags |= S_IMMUTABLE;
+   new_fl |= S_IMMUTABLE;
if (flags & JFS_APPEND_FL)
-   inode->i_flags |= S_APPEND;
+   new_fl |= S_APPEND;
if (flags & JFS_NOATIME_FL)
-   inode->i_flags |= S_NOATIME;
+   new_fl |= S_NOATIME;
if (flags & JFS_DIRSYNC_FL)
-   inode->i_flags |= S_DIRSYNC;
+   new_fl |= S_DIRSYNC;
if (flags & JFS_SYNC_FL)
-   inode->i_flags |= S_SYNC;
+   new_fl |= S_SYNC;
+   inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND | S_NOATIME |
+   S_DIRSYNC | S_SYNC);
 }
 
 void jfs_get_inode_flags(struct jfs_inode_info *jfs_ip)
-- 
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/

[RFC][PATCH 0/4] No I/O from mntput

[Eric W. Biederman]

There are a lot of ways we could approach this, and I sat down and wrote
the simplest variant I could think of, so hopefully there are not silly
bugs that get overlooked.

The code move all cleanup from mntput that would do filesystem I/O into
work queues.

The code waits in mntput for that I/O to complete if we wait today.

The code has been tested and it works, and it succeeds in running
deactivate_super in a stack from with just short of 7500 bytes free.
7500 bytes should be enough for anybody!

I want to double check that I am using work queues correctly, they used
to be deadlock prone, and sleep on everything before I commit to a final
version but this version is probably good enough.

I may be going overboard in the case where we auto close BSD accounting
files, but at this point I figure better safe than sorry. 

Eric W. Biederman (4):
  vfs: Remove useless loop in mntput_no_expire
  vfs: Move autoclose of BSD accounting into a work queue
  vfs: In mntput run deactivate_super on a shallow stack.
  vfs: Block intuitively in the case of BSD accounting files

 fs/mount.h | 14 +++---
 fs/namespace.c | 43 +++
 kernel/acct.c  | 25 -
 3 files changed, 66 insertions(+), 16 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/

[PATCH] arm64:init: Move of_clk_init to time_init

[Chanho Min]

Clock providers should be initialized before clocksource_of_init.
If not, Clock source initialization can be fail to get the clock.

Signed-off-by: Chanho Min 
---
 arch/arm64/kernel/setup.c |1 -
 arch/arm64/kernel/time.c  |3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 720853f..93e7df89 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -393,7 +393,6 @@ void __init setup_arch(char **cmdline_p)
 
 static int __init arm64_device_init(void)
 {
-   of_clk_init(NULL);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
return 0;
 }
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index 29c39d5..8799242 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -64,7 +65,7 @@ EXPORT_SYMBOL(profile_pc);
 void __init time_init(void)
 {
u32 arch_timer_rate;
-
+   of_clk_init(NULL);
clocksource_of_init();
 
arch_timer_rate = arch_timer_get_rate();
-- 
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/

[PATCH 4/8] arm64: Introduce a kernel configuration option for VA_BITS

[Jungseok Lee]

This patch adds a kernel configuration for VA_BITS.

It helps to prevent unnecessary #ifdef statements insertions
for VA_BITS when implementing different page sizes and level of
translation tables.

Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm64/Kconfig  |8 
 arch/arm64/include/asm/memory.h |6 +-
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1a2faf9..431acbc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -186,6 +186,14 @@ config ARM64_3_LEVELS
 
 endchoice
 
+config ARM64_VA_BITS
+   int "Virtual address space size"
+   range 39 39 if ARM64_4K_PAGES && ARM64_3_LEVELS
+   range 42 42 if ARM64_64K_PAGES && ARM64_2_LEVELS
+   help
+ This feature is determined by a combination of page size and
+ level of translation tables.
+
 config CPU_BIG_ENDIAN
bool "Build big-endian kernel"
help
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index e94f945..f6e7480 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -41,11 +41,7 @@
  * The module space lives between the addresses given by TASK_SIZE
  * and PAGE_OFFSET - it must be within 128MB of the kernel text.
  */
-#ifdef CONFIG_ARM64_64K_PAGES
-#define VA_BITS(42)
-#else
-#define VA_BITS(39)
-#endif
+#define VA_BITS(CONFIG_ARM64_VA_BITS)
 #define PAGE_OFFSET(UL(0x) << (VA_BITS - 1))
 #define MODULES_END(PAGE_OFFSET)
 #define MODULES_VADDR  (MODULES_END - SZ_64M)
-- 
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 1/4] vfs: Remove useless loop in mntput_no_expire

[Eric W. Biederman]

Remove the extra reference added to mnt_count by the mnt_pinned code,
and stop jumping to the top of mntput_no_expire.

When fput synchronously called mntput that extra reference count and
the loop ensured that after acct_auto_close_mnt closed all of the
pinned references mntput_no_expire would then proceed actually
unmount the filesystem.

As fput is asynchronous today there is no point in looping.

Signed-off-by: "Eric W. Biederman" 
---
 fs/namespace.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 9d0eb6b4e7d5..2abd5a2416d0 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -985,7 +985,6 @@ static struct mount *clone_mnt(struct mount *old, struct 
dentry *root,
 
 static void mntput_no_expire(struct mount *mnt)
 {
-put_again:
rcu_read_lock();
mnt_add_count(mnt, -1);
if (likely(mnt->mnt_ns)) { /* shouldn't be the last one */
@@ -999,12 +998,12 @@ put_again:
return;
}
if (unlikely(mnt->mnt_pinned)) {
-   mnt_add_count(mnt, mnt->mnt_pinned + 1);
+   mnt_add_count(mnt, mnt->mnt_pinned);
mnt->mnt_pinned = 0;
rcu_read_unlock();
unlock_mount_hash();
acct_auto_close_mnt(&mnt->mnt);
-   goto put_again;
+   return;
}
if (unlikely(mnt->mnt.mnt_flags & MNT_DOOMED)) {
rcu_read_unlock();
-- 
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 1/8] arm64: Use pr_* instead of printk

[Jungseok Lee]

This patch fixed the following checkpatch complaint as using pr_*
instead of printk.

WARNING: printk() should include KERN_ facility level

Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm64/kernel/traps.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 7ffaddd..0484e81 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -65,7 +65,7 @@ static void dump_mem(const char *lvl, const char *str, 
unsigned long bottom,
fs = get_fs();
set_fs(KERNEL_DS);
 
-   printk("%s%s(0x%016lx to 0x%016lx)\n", lvl, str, bottom, top);
+   pr_emerg("%s%s(0x%016lx to 0x%016lx)\n", lvl, str, bottom, top);
 
for (first = bottom & ~31; first < top; first += 32) {
unsigned long p;
@@ -83,7 +83,7 @@ static void dump_mem(const char *lvl, const char *str, 
unsigned long bottom,
sprintf(str + i * 9, " ");
}
}
-   printk("%s%04lx:%s\n", lvl, first & 0x, str);
+   pr_emerg("%s%04lx:%s\n", lvl, first & 0x, str);
}
 
set_fs(fs);
@@ -124,7 +124,7 @@ static void dump_instr(const char *lvl, struct pt_regs 
*regs)
break;
}
}
-   printk("%sCode: %s\n", lvl, str);
+   pr_emerg("%sCode: %s\n", lvl, str);
 
set_fs(fs);
 }
@@ -156,7 +156,7 @@ static void dump_backtrace(struct pt_regs *regs, struct 
task_struct *tsk)
frame.pc = thread_saved_pc(tsk);
}
 
-   printk("Call trace:\n");
+   pr_emerg("Call trace:\n");
while (1) {
unsigned long where = frame.pc;
int ret;
@@ -328,17 +328,17 @@ asmlinkage void bad_mode(struct pt_regs *regs, int 
reason, unsigned int esr)
 
 void __pte_error(const char *file, int line, unsigned long val)
 {
-   printk("%s:%d: bad pte %016lx.\n", file, line, val);
+   pr_crit("%s:%d: bad pte %016lx.\n", file, line, val);
 }
 
 void __pmd_error(const char *file, int line, unsigned long val)
 {
-   printk("%s:%d: bad pmd %016lx.\n", file, line, val);
+   pr_crit("%s:%d: bad pmd %016lx.\n", file, line, val);
 }
 
 void __pgd_error(const char *file, int line, unsigned long val)
 {
-   printk("%s:%d: bad pgd %016lx.\n", file, line, val);
+   pr_crit("%s:%d: bad pgd %016lx.\n", file, line, val);
 }
 
 void __init trap_init(void)
-- 
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 2/8] arm/arm64: KVM: Fix line length exceeding 80 characters

[Jungseok Lee]

This patch deals with checkpatch complaint as fixing line length
exceeding 80 characters.

WARNING: line over 80 characters

Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm/kvm/mmu.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 80bb1e6..e0d4f24 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -563,8 +563,8 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
kvm->arch.pgd = NULL;
 }
 
-static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache 
*cache,
-phys_addr_t addr)
+static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache
+*cache, phys_addr_t addr)
 {
pgd_t *pgd;
pud_t *pud;
-- 
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 v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support

[Mathias Nyman]

On 04/12/2014 01:54 AM, Timur Tabi wrote:

On Tue, Jun 18, 2013 at 6:33 AM, Mathias Nyman
 wrote:


Pins may be muxed to alternate function instead of gpio by firmware.
This driver does not touch the pin muxing and expect firmare
to set pin muxing and pullup/down properties properly.

Signed-off-by: Mathias Nyman 
---
  drivers/pinctrl/Kconfig|   12 +
  drivers/pinctrl/Makefile   |1 +
  drivers/pinctrl/pinctrl-baytrail.c |  543 



I know it's been ten months since you posted this driver, but I have a
question.  If this driver does not touch the pin muxing, and it
doesn't even call pinctrl_register(), then why is it in
drivers/pinctrl?  It's not a pinctrl driver.  Why isn't this a regular
GPIO drivers in drivers/gpio?



This was the conclusion we reached after some discussion with Linus W.
Initially this was just a GPIO driver, but Linus correctly spotted that 
Baytrail has many pinctrl-like features (like pin muxing, etc) that we 
might need to address in the future.


threads where this was discussed:

http://marc.info/?l=linux-kernel&m=136994203308585&w=2
http://marc.info/?l=linux-kernel&m=137113578604763&w=2

-Mathias

--
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 8/8] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2

[Jungseok Lee]

This patch adds 4 levels of translation tables implementation for both
HYP and stage2. A combination of 4KB + 4 levels host and 4KB + 4 levels
guest can run on ARMv8 architecture as introducing this feature.

Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm/kvm/mmu.c   |   96 +-
 arch/arm64/include/asm/kvm_arm.h |   20 
 arch/arm64/include/asm/kvm_mmu.h |1 +
 3 files changed, 106 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index e0d4f24..6cf89ad 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -388,13 +388,46 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned 
long start,
return 0;
 }
 
+static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
+  unsigned long end, unsigned long pfn,
+  pgprot_t prot)
+{
+   pud_t *pud;
+   pmd_t *pmd;
+   unsigned long addr, next;
+
+   addr = start;
+   do {
+   pud = pud_offset(pgd, addr);
+
+   if (pud_none_or_clear_bad(pud)) {
+   pmd = pmd_alloc_one(NULL, addr);
+   if (!pmd) {
+   kvm_err("Cannot allocate Hyp pmd\n");
+   return -ENOMEM;
+   }
+   pud_populate(NULL, pud, pmd);
+   get_page(virt_to_page(pud));
+   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+   }
+
+   next = pud_addr_end(addr, end);
+
+   create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
+   pfn += (next - addr) >> PAGE_SHIFT;
+   } while (addr = next, addr != end);
+
+   return 0;
+}
+
 static int __create_hyp_mappings(pgd_t *pgdp,
 unsigned long start, unsigned long end,
 unsigned long pfn, pgprot_t prot)
 {
pgd_t *pgd;
+#ifdef CONFIG_ARM64_4_LEVELS
pud_t *pud;
-   pmd_t *pmd;
+#endif
unsigned long addr, next;
int err = 0;
 
@@ -403,22 +436,25 @@ static int __create_hyp_mappings(pgd_t *pgdp,
end = PAGE_ALIGN(end);
do {
pgd = pgdp + pgd_index(addr);
-   pud = pud_offset(pgd, addr);
 
-   if (pud_none_or_clear_bad(pud)) {
-   pmd = pmd_alloc_one(NULL, addr);
-   if (!pmd) {
-   kvm_err("Cannot allocate Hyp pmd\n");
+#ifdef CONFIG_ARM64_4_LEVELS
+   if (pgd_none(*pgd)) {
+   pud = pud_alloc_one(NULL, addr);
+   if (!pud) {
+   kvm_err("Cannot allocate Hyp pud\n");
err = -ENOMEM;
goto out;
}
-   pud_populate(NULL, pud, pmd);
-   get_page(virt_to_page(pud));
-   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+   pgd_populate(NULL, pgd, pud);
+   get_page(virt_to_page(pgd));
+   kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
}
+#endif
 
next = pgd_addr_end(addr, end);
-   err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
+
+   err = create_hyp_pud_mappings(pgd, addr, next, pfn, prot);
+
if (err)
goto out;
pfn += (next - addr) >> PAGE_SHIFT;
@@ -563,6 +599,26 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
kvm->arch.pgd = NULL;
 }
 
+#ifdef CONFIG_ARM64_4_LEVELS
+static pud_t *stage2_get_pud(struct kvm *kvm, struct kvm_mmu_memory_cache
+*cache, phys_addr_t addr)
+{
+   pgd_t *pgd;
+   pud_t *pud;
+
+   pgd = kvm->arch.pgd + pgd_index(addr);
+   if (pgd_none(*pgd)) {
+   if (!cache)
+   return NULL;
+   pud = mmu_memory_cache_alloc(cache);
+   pgd_populate(NULL, pgd, pud);
+   get_page(virt_to_page(pgd));
+   }
+
+   return pud_offset(pgd, addr);
+}
+#endif
+
 static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache
 *cache, phys_addr_t addr)
 {
@@ -617,6 +673,24 @@ static int stage2_set_pte(struct kvm *kvm, struct 
kvm_mmu_memory_cache *cache,
pmd_t *pmd;
pte_t *pte, old_pte;
 
+#ifdef CONFIG_ARM64_4_LEVELS
+   pud_t *pud;
+
+   /* Create stage-2 page table mapping - Level 0 */
+   pud = stage2_get_pud(kvm, cache, addr);
+   if (!pud)
+   return 0;
+
+   if (pud_none(*pud)) {
+   if (!cache)
+   return 0;
+   pmd = mmu_memory_cache_alloc(cache);
+   kvm_clean_pmd(pmd);
+   pud_populate(NULL, pud, pmd);
+  

[PATCH 3/4] vfs: In mntput run deactivate_super on a shallow stack.

[Eric W. Biederman]

mntput as part of path_put is called from all over the vfs sometimes
as in the case of symlink chasing from some rather deep call chains.
During lazy filesystem unmount with the right set of races those
innocuous little mntput calls (that take very little stack space) can
call deactivate_super and wind up taking 3k of stack space or more
(David Chinner reports 5k for xfs).

Avoid deactivate_super being called from a deep stack by moving
the cleanup of the mount into a work queue.

To avoid semantic changes mntput waits for deactivate_super to complete
before returning.

With this change all filesystem unmounting happens with about 7400
bytes free on the stack at the point where deactivate_super is called.
Giving filesystems plenty of room to do I/O and not overflow the
kernel stack during unmounting.

The extra fields mnt_cleanup_work, and mnt_undone are added in
a union to avoid growing struct mount unnecessarily.

Signed-off-by: "Eric W. Biederman" 
---
 fs/mount.h | 14 +++---
 fs/namespace.c | 32 +++-
 2 files changed, 38 insertions(+), 8 deletions(-)

diff --git a/fs/mount.h b/fs/mount.h
index a4111f19fd2e..7272fc416580 100644
--- a/fs/mount.h
+++ b/fs/mount.h
@@ -48,8 +48,17 @@ struct mount {
struct list_head mnt_slave; /* slave list entry */
struct mount *mnt_master;   /* slave is on master->mnt_slave_list */
struct mnt_namespace *mnt_ns;   /* containing namespace */
-   struct mountpoint *mnt_mp;  /* where is it mounted */
-   struct list_head mnt_mp_list;   /* list mounts with the same mountpoint 
*/
+   union {
+   struct {
+   struct path mnt_ex_mountpoint;
+   struct list_head mnt_mp_list;   /* list mounts with the 
same mountpoint */
+   struct mountpoint *mnt_mp;  /* where is it mounted 
*/
+   };
+   struct {
+   struct work_struct mnt_cleanup_work;
+   struct completion *mnt_undone;
+   };
+   };
 #ifdef CONFIG_FSNOTIFY
struct hlist_head mnt_fsnotify_marks;
__u32 mnt_fsnotify_mask;
@@ -58,7 +67,6 @@ struct mount {
int mnt_group_id;   /* peer group identifier */
int mnt_expiry_mark;/* true if marked for expiry */
int mnt_pinned;
-   struct path mnt_ex_mountpoint;
 };
 
 #define MNT_NS_INTERNAL ERR_PTR(-EINVAL) /* distinct from any mnt_namespace */
diff --git a/fs/namespace.c b/fs/namespace.c
index 2abd5a2416d0..ac589ad9f22d 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -983,8 +983,25 @@ static struct mount *clone_mnt(struct mount *old, struct 
dentry *root,
return ERR_PTR(err);
 }
 
+static void cleanup_mnt(struct mount *mnt)
+{
+   fsnotify_vfsmount_delete(&mnt->mnt);
+   dput(mnt->mnt.mnt_root);
+   deactivate_super(mnt->mnt.mnt_sb);
+   mnt_free_id(mnt);
+   complete(mnt->mnt_undone);
+   call_rcu(&mnt->mnt_rcu, delayed_free_vfsmnt);
+}
+
+static void cleanup_mnt_work(struct work_struct *work)
+{
+   cleanup_mnt(container_of(work, struct mount, mnt_cleanup_work));
+}
+
 static void mntput_no_expire(struct mount *mnt)
 {
+   struct completion undone;
+
rcu_read_lock();
mnt_add_count(mnt, -1);
if (likely(mnt->mnt_ns)) { /* shouldn't be the last one */
@@ -1027,11 +1044,16 @@ static void mntput_no_expire(struct mount *mnt)
 * so mnt_get_writers() below is safe.
 */
WARN_ON(mnt_get_writers(mnt));
-   fsnotify_vfsmount_delete(&mnt->mnt);
-   dput(mnt->mnt.mnt_root);
-   deactivate_super(mnt->mnt.mnt_sb);
-   mnt_free_id(mnt);
-   call_rcu(&mnt->mnt_rcu, delayed_free_vfsmnt);
+   /* The stack may be deep here, cleanup the mount on a work
+* queue where the stack is guaranteed to be shallow.
+*/
+   init_completion(&undone);
+   mnt->mnt_undone = &undone;
+
+   INIT_WORK(&mnt->mnt_cleanup_work, cleanup_mnt_work);
+   schedule_work(&mnt->mnt_cleanup_work);
+
+   wait_for_completion(&undone);
 }
 
 void mntput(struct vfsmount *mnt)
-- 
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 2/4] vfs: Move autoclose of BSD accounting into a work queue

[Eric W. Biederman]

The autoclose of BSD accounting writes a record to the BSD accounting
file.  When mntput is called from moderaly deep within the stack the
(3KiB or so) generating I/O can be problemenatic as some I/O paths
require nearly 5KiB of stack on their own.

Avoid the possibility of stack overflow by moving the close of the BSD
accounting file into a work queue.

Signed-off-by: "Eric W. Biederman" 
---
 kernel/acct.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/kernel/acct.c b/kernel/acct.c
index 8d6e145138bb..1853dd4a1d01 100644
--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -93,6 +93,7 @@ struct bsd_acct_struct {
 
 static DEFINE_SPINLOCK(acct_lock);
 static LIST_HEAD(acct_list);
+static LIST_HEAD(acct_close_list);
 
 /*
  * Check the amount of free space and suspend/resume accordingly.
@@ -280,6 +281,20 @@ SYSCALL_DEFINE1(acct, const char __user *, name)
return error;
 }
 
+static void acct_close_mnts(struct work_struct *unused)
+{
+   struct bsd_acct_struct *acct;
+
+   spin_lock(&acct_lock);
+restart:
+   list_for_each_entry(acct, &acct_close_list, list) {
+   acct_file_reopen(acct, NULL, NULL);
+   goto restart;
+   }
+   spin_unlock(&acct_lock);
+}
+static DECLARE_WORK(acct_close_work, acct_close_mnts);
+
 /**
  * acct_auto_close - turn off a filesystem's accounting if it is on
  * @m: vfsmount being shut down
@@ -289,15 +304,15 @@ SYSCALL_DEFINE1(acct, const char __user *, name)
  */
 void acct_auto_close_mnt(struct vfsmount *m)
 {
-   struct bsd_acct_struct *acct;
+   struct bsd_acct_struct *acct, *tmp;
 
spin_lock(&acct_lock);
-restart:
-   list_for_each_entry(acct, &acct_list, list)
+   list_for_each_entry_safe(acct, tmp, &acct_list, list) {
if (acct->file && acct->file->f_path.mnt == m) {
-   acct_file_reopen(acct, NULL, NULL);
-   goto restart;
+   list_move_tail(&acct->list, &acct_close_list);
+   schedule_work(&acct_close_work);
}
+   }
spin_unlock(&acct_lock);
 }
 
-- 
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/

Re: [PATCH 2/2] [RFC v2 with seqcount] reservation: add suppport for read-only access using rcu

[Maarten Lankhorst]

op 11-04-14 21:35, Thomas Hellstrom schreef:

On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:

op 11-04-14 12:11, Thomas Hellstrom schreef:

On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:

op 11-04-14 10:38, Thomas Hellstrom schreef:

Hi, Maarten.

Here I believe we encounter a lot of locking inconsistencies.

First, it seems you're use a number of pointers as RCU pointers
without
annotating them as such and use the correct rcu
macros when assigning those pointers.

Some pointers (like the pointers in the shared fence list) are both
used
as RCU pointers (in dma_buf_poll()) for example,
or considered protected by the seqlock
(reservation_object_get_fences_rcu()), which I believe is OK, but then
the pointers must
be assigned using the correct rcu macros. In the memcpy in
reservation_object_get_fences_rcu() we might get away with an
ugly typecast, but with a verbose comment that the pointers are
considered protected by the seqlock at that location.

So I've updated (attached) the headers with proper __rcu annotation
and
locking comments according to how they are being used in the various
reading functions.
I believe if we want to get rid of this we need to validate those
pointers using the seqlock as well.
This will generate a lot of sparse warnings in those places needing
rcu_dereference()
rcu_assign_pointer()
rcu_dereference_protected()

With this I think we can get rid of all ACCESS_ONCE macros: It's not
needed when the rcu_x() macros are used, and
it's never needed for the members protected by the seqlock, (provided
that the seq is tested). The only place where I think that's
*not* the case is at the krealloc in
reservation_object_get_fences_rcu().

Also I have some more comments in the
reservation_object_get_fences_rcu() function below:

I felt that the barriers needed for rcu were already provided by
checking the seqcount lock.
But looking at rcu_dereference makes it seem harmless to add it in
more places, it handles
the ACCESS_ONCE and barrier() for us.

And it makes the code more maintainable, and helps sparse doing a lot of
checking for us. I guess
we can tolerate a couple of extra barriers for that.


We could probably get away with using RCU_INIT_POINTER on the writer
side,
because the smp_wmb is already done by arranging seqcount updates
correctly.

Hmm. yes, probably. At least in the replace function. I think if we do
it in other places, we should add comments as to where
the smp_wmb() is located, for future reference.


Also  I saw in a couple of places where you're checking the shared
pointers, you're not checking for NULL pointers, which I guess may
happen if shared_count and pointers are not in full sync?


No, because shared_count is protected with seqcount. I only allow
appending to the array, so when
shared_count is validated by seqcount it means that the
[0...shared_count) indexes are valid and non-null.
What could happen though is that the fence at a specific index is
updated with another one from the same
context, but that's harmless.


Hmm, doesn't attaching an exclusive fence clear all shared fence
pointers from under a reader?


No, for that reason. It only resets shared_count to 0. This is harmless because 
the shared fence pointers are
still valid long enough because of RCU delayed deletion. fence_get_rcu will 
fail when the refcount has
dropped to zero. This is enough of a check to prevent errors, so there's no 
need to explicitly clear the fence
pointers.

~Maarten
--
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/4] vfs: Block intuitively in the case of BSD accounting files

[Eric W. Biederman]

Have the mntput that started the BSD accounting files closing block
until the superblock has been succesfully freed.  This is what used to
happen until fput started calling mntput assynchronously, and is arguably
the right thing to do in the case of umount.

Signed-off-by: "Eric W. Biederman" 
---
 fs/namespace.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index ac589ad9f22d..b10db3d69943 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1015,11 +1015,14 @@ static void mntput_no_expire(struct mount *mnt)
return;
}
if (unlikely(mnt->mnt_pinned)) {
+   init_completion(&undone);
+   mnt->mnt_undone = &undone;
mnt_add_count(mnt, mnt->mnt_pinned);
mnt->mnt_pinned = 0;
rcu_read_unlock();
unlock_mount_hash();
acct_auto_close_mnt(&mnt->mnt);
+   wait_for_completion(&undone);
return;
}
if (unlikely(mnt->mnt.mnt_flags & MNT_DOOMED)) {
@@ -1048,7 +1051,10 @@ static void mntput_no_expire(struct mount *mnt)
 * queue where the stack is guaranteed to be shallow.
 */
init_completion(&undone);
-   mnt->mnt_undone = &undone;
+   if (!mnt->mnt_undone)
+   mnt->mnt_undone = &undone;
+   else
+   complete(&undone);
 
INIT_WORK(&mnt->mnt_cleanup_work, cleanup_mnt_work);
schedule_work(&mnt->mnt_cleanup_work);
-- 
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 7/8] arm64: mm: Implement 4 levels of translation tables

[Jungseok Lee]

This patch implements 4 levels of translation tables since 3 levels
of page tables with 4KB pages cannot support 40-bit physical address
space described in [1] due to the following issue.

It is a restriction that kernel logical memory map with 4KB + 3 levels
(0xffc0-0x) cannot cover RAM region from
544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
mapping for this region in map_mem function since __phys_to_virt for
this region reaches to address overflow.

If SoC design follows the document, [1], over 32GB RAM would be placed
from 544GB. Even 64GB system is supposed to use the region from 544GB
to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
of page tables to avoid hacking __virt_to_phys and __phys_to_virt.

However, it is recommended 4 levels of page table should be only enabled
if memory map is too sparse or there is about 512GB RAM.

References
--
[1]: Principle of ARM Memory Maps, White Paper, Issue C

Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm64/Kconfig |7 +
 arch/arm64/include/asm/page.h  |4 ++-
 arch/arm64/include/asm/pgalloc.h   |   20 ++
 arch/arm64/include/asm/pgtable-hwdef.h |8 --
 arch/arm64/include/asm/pgtable.h   |   44 +--
 arch/arm64/include/asm/tlb.h   |8 ++
 arch/arm64/kernel/head.S   |   45 ++--
 arch/arm64/kernel/traps.c  |5 
 arch/arm64/mm/fault.c  |1 +
 arch/arm64/mm/mmu.c|   14 +-
 10 files changed, 148 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 431acbc..7f5270b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -184,12 +184,19 @@ config ARM64_3_LEVELS
help
  This feature enables 3 levels of translation tables.
 
+config ARM64_4_LEVELS
+   bool "4 level"
+   depends on ARM64_4K_PAGES
+   help
+ This feature enables 4 levels of translation tables.
+
 endchoice
 
 config ARM64_VA_BITS
int "Virtual address space size"
range 39 39 if ARM64_4K_PAGES && ARM64_3_LEVELS
range 42 42 if ARM64_64K_PAGES && ARM64_2_LEVELS
+   range 48 48 if ARM64_4K_PAGES && ARM64_4_LEVELS
help
  This feature is determined by a combination of page size and
  level of translation tables.
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 268e53d..83b5289 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -35,8 +35,10 @@
 
 #ifdef CONFIG_ARM64_2_LEVELS
 #include 
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
 #include 
+#else
+#include 
 #endif
 
 extern void __cpu_clear_user_page(void *p, unsigned long user);
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 4829837..8d745fa 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,6 +26,26 @@
 
 #define check_pgt_cache()  do { } while (0)
 
+#ifdef CONFIG_ARM64_4_LEVELS
+
+static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
+{
+   return (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static inline void pud_free(struct mm_struct *mm, pud_t *pud)
+{
+   BUG_ON((unsigned long)pud & (PAGE_SIZE-1));
+   free_page((unsigned long)pud);
+}
+
+static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
+{
+   set_pgd(pgd, __pgd(__pa(pud) | PUD_TYPE_TABLE));
+}
+
+#endif  /* CONFIG_ARM64_4_LEVELS */
+
 #ifndef CONFIG_ARM64_2_LEVELS
 
 static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
b/arch/arm64/include/asm/pgtable-hwdef.h
index 9cd86c6..03ad81b 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -18,8 +18,10 @@
 
 #ifdef CONFIG_ARM64_2_LEVELS
 #include 
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
 #include 
+#else
+#include 
 #endif
 
 /*
@@ -27,7 +29,9 @@
  *
  * Level 1 descriptor (PUD).
  */
-
+#ifdef CONFIG_ARM64_4_LEVELS
+#define PUD_TYPE_TABLE (_AT(pudval_t, 3) << 0)
+#endif
 #define PUD_TABLE_BIT  (_AT(pgdval_t, 1) << 1)
 
 /*
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index a64ce5e..713811d 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -35,7 +35,11 @@
  * VMALLOC and SPARSEMEM_VMEMMAP ranges.
  */
 #define VMALLOC_START  (UL(0x) << VA_BITS)
+#ifndef CONFIG_ARM64_4_LEVELS
 #define VMALLOC_END(PAGE_OFFSET - UL(0x4) - SZ_64K)
+#else
+#define VMALLOC_END(PAGE_OFFSET - UL(0x400) - SZ_64K)
+#endif
 
 #define vmemmap((struct page *)(VMALLOC_END + SZ_64K))
 
@@ -44,12 +48,16 @@
 #ifndef __A

[PATCH 6/8] arm64: Add 4 levels of page tables definition with 4KB pages

[Jungseok Lee]

This patch adds hardware definition and types for 4 levels of
translation tables with 4KB pages.

Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm64/include/asm/pgtable-4level-hwdef.h |   50 +
 arch/arm64/include/asm/pgtable-4level-types.h |   71 +
 2 files changed, 121 insertions(+)
 create mode 100644 arch/arm64/include/asm/pgtable-4level-hwdef.h
 create mode 100644 arch/arm64/include/asm/pgtable-4level-types.h

diff --git a/arch/arm64/include/asm/pgtable-4level-hwdef.h 
b/arch/arm64/include/asm/pgtable-4level-hwdef.h
new file mode 100644
index 000..0ec84e2
--- /dev/null
+++ b/arch/arm64/include/asm/pgtable-4level-hwdef.h
@@ -0,0 +1,50 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_PGTABLE_4LEVEL_HWDEF_H
+#define __ASM_PGTABLE_4LEVEL_HWDEF_H
+
+#define PTRS_PER_PTE   512
+#define PTRS_PER_PMD   512
+#define PTRS_PER_PUD   512
+#define PTRS_PER_PGD   512
+
+/*
+ * PGDIR_SHIFT determines the size a top-level page table entry can map.
+ */
+#define PGDIR_SHIFT39
+#define PGDIR_SIZE (_AC(1, UL) << PGDIR_SHIFT)
+#define PGDIR_MASK (~(PGDIR_SIZE-1))
+
+/*
+ * PUD_SHIFT determines the size the second level page table entry can map.
+ */
+#define PUD_SHIFT  30
+#define PUD_SIZE   (_AC(1, UL) << PUD_SHIFT)
+#define PUD_MASK   (~(PUD_SIZE-1))
+
+/*
+ * PMD_SHIFT determines the size the third level page table entry can map.
+ */
+#define PMD_SHIFT  21
+#define PMD_SIZE   (_AC(1, UL) << PMD_SHIFT)
+#define PMD_MASK   (~(PMD_SIZE-1))
+
+/*
+ * section address mask and size definitions.
+ */
+#define SECTION_SHIFT  21
+#define SECTION_SIZE   (_AC(1, UL) << SECTION_SHIFT)
+#define SECTION_MASK   (~(SECTION_SIZE-1))
+
+#endif
diff --git a/arch/arm64/include/asm/pgtable-4level-types.h 
b/arch/arm64/include/asm/pgtable-4level-types.h
new file mode 100644
index 000..7ad8dd2
--- /dev/null
+++ b/arch/arm64/include/asm/pgtable-4level-types.h
@@ -0,0 +1,71 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_PGTABLE_4LEVEL_TYPES_H
+#define __ASM_PGTABLE_4LEVEL_TYPES_H
+
+#include 
+
+typedef u64 pteval_t;
+typedef u64 pmdval_t;
+typedef u64 pudval_t;
+typedef u64 pgdval_t;
+
+#undef STRICT_MM_TYPECHECKS
+
+#ifdef STRICT_MM_TYPECHECKS
+
+/*
+ * These are used to make use of C type-checking..
+ */
+typedef struct { pteval_t pte; } pte_t;
+typedef struct { pmdval_t pmd; } pmd_t;
+typedef struct { pudval_t pud; } pud_t;
+typedef struct { pgdval_t pgd; } pgd_t;
+typedef struct { pteval_t pgprot; } pgprot_t;
+
+#define pte_val(x) ((x).pte)
+#define pmd_val(x) ((x).pmd)
+#define pud_val(x) ((x).pud)
+#define pgd_val(x) ((x).pgd)
+#define pgprot_val(x)  ((x).pgprot)
+
+#define __pte(x)   ((pte_t) { (x) } )
+#define __pmd(x)   ((pmd_t) { (x) } )
+#define __pud(x)   ((pud_t) { (x) } )
+#define __pgd(x)   ((pgd_t) { (x) } )
+#define __pgprot(x)((pgprot_t) { (x) } )
+
+#else  /* !STRICT_MM_TYPECHECKS */
+
+typedef pteval_t pte_t;
+typedef pmdval_t pmd_t;
+typedef pudval_t pud_t;
+typedef pgdval_t pgd_t;
+typedef pteval_t pgprot_t;
+
+#define pte_val(x) (x)
+#define pmd_val(x) (x)
+#define pud_val(x) (x)
+#define pgd_val(x) (x)
+#define pgprot_val(x)  (x)
+
+#define __pte(x)   (x)
+#define __pmd(x)   (x)
+#define __pud(x)   (x)
+#define __pgd(x)   (x)
+#define __pgprot(x)(x)
+
+#endif /* STRICT_MM_TYPECHECKS */
+
+#endif /* __ASM_PGTABLE_4LEVEL_TYPES_H */
-- 
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 resend] mfd/rtc: s5m: Do not allocate RTC I2C dummy and regmap for unsupported chipsets

[Krzysztof Kozlowski]

The rtc-s5m driver does not support all of S2M and S5M chipsets
supported by main MFD sec-core driver. For such chipsets unsupported by
rtc-s5m, the MFD sec-core driver initialized regmap with default config.
This config in such cases wouldn't work at all.

The main MFD sec-core driver shouldn't initialize regmap for child
drivers which is not used by them and even not valid.

Move the allocation of RTC I2C dummy device and initialization of RTC
regmap from main MFD sec-core driver to the rtc-s5m driver. The rtc-s5m
driver will use proper regmap config for supported devices.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/mfd/sec-core.c   | 53 +---
 drivers/rtc/rtc-s5m.c| 75 +---
 include/linux/mfd/samsung/core.h |  3 --
 3 files changed, 71 insertions(+), 60 deletions(-)

diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 1cf27521fff4..d4682c6cbff5 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -196,20 +195,6 @@ static const struct regmap_config s5m8767_regmap_config = {
.cache_type = REGCACHE_FLAT,
 };
 
-static const struct regmap_config s5m_rtc_regmap_config = {
-   .reg_bits = 8,
-   .val_bits = 8,
-
-   .max_register = SEC_RTC_REG_MAX,
-};
-
-static const struct regmap_config s2mps14_rtc_regmap_config = {
-   .reg_bits = 8,
-   .val_bits = 8,
-
-   .max_register = S2MPS_RTC_REG_MAX,
-};
-
 #ifdef CONFIG_OF
 /*
  * Only the common platform data elements for s5m8767 are parsed here from the
@@ -264,7 +249,7 @@ static int sec_pmic_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
 {
struct sec_platform_data *pdata = dev_get_platdata(&i2c->dev);
-   const struct regmap_config *regmap, *regmap_rtc;
+   const struct regmap_config *regmap;
struct sec_pmic_dev *sec_pmic;
int ret;
 
@@ -298,39 +283,21 @@ static int sec_pmic_probe(struct i2c_client *i2c,
switch (sec_pmic->device_type) {
case S2MPA01:
regmap = &s2mpa01_regmap_config;
-   /*
-* The rtc-s5m driver does not support S2MPA01 and there
-* is no mfd_cell for S2MPA01 RTC device.
-* However we must pass something to devm_regmap_init_i2c()
-* so use S5M-like regmap config even though it wouldn't work.
-*/
-   regmap_rtc = &s5m_rtc_regmap_config;
break;
case S2MPS11X:
regmap = &s2mps11_regmap_config;
-   /*
-* The rtc-s5m driver does not support S2MPS11 and there
-* is no mfd_cell for S2MPS11 RTC device.
-* However we must pass something to devm_regmap_init_i2c()
-* so use S5M-like regmap config even though it wouldn't work.
-*/
-   regmap_rtc = &s5m_rtc_regmap_config;
break;
case S2MPS14X:
regmap = &s2mps14_regmap_config;
-   regmap_rtc = &s2mps14_rtc_regmap_config;
break;
case S5M8763X:
regmap = &s5m8763_regmap_config;
-   regmap_rtc = &s5m_rtc_regmap_config;
break;
case S5M8767X:
regmap = &s5m8767_regmap_config;
-   regmap_rtc = &s5m_rtc_regmap_config;
break;
default:
regmap = &sec_regmap_config;
-   regmap_rtc = &s5m_rtc_regmap_config;
break;
}
 
@@ -342,21 +309,6 @@ static int sec_pmic_probe(struct i2c_client *i2c,
return ret;
}
 
-   sec_pmic->rtc = i2c_new_dummy(i2c->adapter, RTC_I2C_ADDR);
-   if (!sec_pmic->rtc) {
-   dev_err(&i2c->dev, "Failed to allocate I2C for RTC\n");
-   return -ENODEV;
-   }
-   i2c_set_clientdata(sec_pmic->rtc, sec_pmic);
-
-   sec_pmic->regmap_rtc = devm_regmap_init_i2c(sec_pmic->rtc, regmap_rtc);
-   if (IS_ERR(sec_pmic->regmap_rtc)) {
-   ret = PTR_ERR(sec_pmic->regmap_rtc);
-   dev_err(&i2c->dev, "Failed to allocate RTC register map: %d\n",
-   ret);
-   goto err_regmap_rtc;
-   }
-
if (pdata && pdata->cfg_pmic_irq)
pdata->cfg_pmic_irq();
 
@@ -403,8 +355,6 @@ static int sec_pmic_probe(struct i2c_client *i2c,
 
 err_mfd:
sec_irq_exit(sec_pmic);
-err_regmap_rtc:
-   i2c_unregister_device(sec_pmic->rtc);
return ret;
 }
 
@@ -414,7 +364,6 @@ static int sec_pmic_remove(struct i2c_client *i2c)
 
mfd_remove_devices(sec_pmic->dev);
sec_irq_exit(sec_pmic);
-   i2c_unregister_device(sec_pmic->rtc);
return 0;
 }
 
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 476af93543f6..8ec2d6a1dbe1 100644
--

[PATCH 5/8] arm64: Add a description on 48-bit address space with 4KB pages

[Jungseok Lee]

This patch adds memory layout and translation lookup information
about 48-bit address space with 4K pages. The description is based
on 4 levels of translation tables.

Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 Documentation/arm64/memory.txt |   59 ++--
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index d50fa61..8142709 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the 
AArch64
 Linux kernel. The architecture allows up to 4 levels of translation
 tables with a 4KB page size and up to 3 levels with a 64KB page size.
 
-AArch64 Linux uses 3 levels of translation tables with the 4KB page
-configuration, allowing 39-bit (512GB) virtual addresses for both user
-and kernel. With 64KB pages, only 2 levels of translation tables are
-used but the memory layout is the same.
+AArch64 Linux uses 3 levels and 4 levels of translation tables with
+the 4KB page configuration, allowing 39-bit (512GB) and 48-bit (256TB)
+virtual addresses, respectively, for both user and kernel. With 64KB
+pages, only 2 levels of translation tables are used but the memory layout
+is the same.
 
 User addresses have bits 63:39 set to 0 while the kernel addresses have
 the same bits set to 1. TTBRx selection is given by bit 63 of the
@@ -21,7 +22,7 @@ The swapper_pgd_dir address is written to TTBR1 and never 
written to
 TTBR0.
 
 
-AArch64 Linux memory layout with 4KB pages:
+AArch64 Linux memory layout with 4KB pages + 3 levels:
 
 Start  End SizeUse
 ---
@@ -48,7 +49,34 @@ ffbffc00 ffbf  64MB  
modules
 ffc0    256GB  kernel logical 
memory map
 
 
-AArch64 Linux memory layout with 64KB pages:
+AArch64 Linux memory layout with 4KB pages + 4 levels:
+
+Start  End SizeUse
+---
+    256TB  user
+
+   7bfe~124TB  vmalloc
+
+7bff   7bff  64KB  [guard page]
+
+7c00   7dff   2TB  vmemmap
+
+7e00   7bbf  ~2TB  [guard, future 
vmmemap]
+
+7a00   7aff  16MB  PCI I/O space
+
+7b00   7bbf  12MB  [guard]
+
+7bc0   7bdf   2MB  earlyprintk 
device
+
+7be0   7bff   2MB  [guard]
+
+7c00   7fff  64MB  modules
+
+8000    128TB  kernel logical 
memory map
+
+
+AArch64 Linux memory layout with 64KB pages + 2 levels:
 
 Start  End SizeUse
 ---
@@ -75,7 +103,7 @@ fdfffc00 fdff  64MB  
modules
 fe00      2TB  kernel logical 
memory map
 
 
-Translation table lookup with 4KB pages:
+Translation table lookup with 4KB pages + 3 levels:
 
 +++++++++
 |6356|5548|4740|3932|3124|2316|15 8|7  0|
@@ -90,7 +118,22 @@ Translation table lookup with 4KB pages:
  +-> [63] TTBR0/1
 
 
-Translation table lookup with 64KB pages:
+Translation table lookup with 4KB pages + 4 levels:
+
++++++++++
+|6356|5548|4740|3932|3124|2316|15 8|7  0|
++++++++++
+ | | | | | |
+ | | | | | v
+ | | | | |   [11:0]  in-page offset
+ | | | | +-> [20:12] L3 index
+ | | | +---> [29:21] L2 index
+ | | +-> [38:30] L1 index
+ | +---> [47:39] L0 index
+ +-> [63] TTBR0/1
+
+
+Translation table lookup with 64KB pages + 2 levels:
 
 +++++++++
 |6356|5548|4740|3932|3124|2316|15 8|7  0|
-- 
1.7.10.4


--
To unsubscribe from t

Re: [PATCH 2/2] [RFC v2 with seqcount] reservation: add suppport for read-only access using rcu

[Thomas Hellstrom]

On 04/14/2014 09:42 AM, Maarten Lankhorst wrote:
> op 11-04-14 21:35, Thomas Hellstrom schreef:
>> On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
>>> op 11-04-14 12:11, Thomas Hellstrom schreef:
 On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
> op 11-04-14 10:38, Thomas Hellstrom schreef:
>> Hi, Maarten.
>>
>> Here I believe we encounter a lot of locking inconsistencies.
>>
>> First, it seems you're use a number of pointers as RCU pointers
>> without
>> annotating them as such and use the correct rcu
>> macros when assigning those pointers.
>>
>> Some pointers (like the pointers in the shared fence list) are both
>> used
>> as RCU pointers (in dma_buf_poll()) for example,
>> or considered protected by the seqlock
>> (reservation_object_get_fences_rcu()), which I believe is OK, but
>> then
>> the pointers must
>> be assigned using the correct rcu macros. In the memcpy in
>> reservation_object_get_fences_rcu() we might get away with an
>> ugly typecast, but with a verbose comment that the pointers are
>> considered protected by the seqlock at that location.
>>
>> So I've updated (attached) the headers with proper __rcu annotation
>> and
>> locking comments according to how they are being used in the various
>> reading functions.
>> I believe if we want to get rid of this we need to validate those
>> pointers using the seqlock as well.
>> This will generate a lot of sparse warnings in those places needing
>> rcu_dereference()
>> rcu_assign_pointer()
>> rcu_dereference_protected()
>>
>> With this I think we can get rid of all ACCESS_ONCE macros: It's not
>> needed when the rcu_x() macros are used, and
>> it's never needed for the members protected by the seqlock,
>> (provided
>> that the seq is tested). The only place where I think that's
>> *not* the case is at the krealloc in
>> reservation_object_get_fences_rcu().
>>
>> Also I have some more comments in the
>> reservation_object_get_fences_rcu() function below:
> I felt that the barriers needed for rcu were already provided by
> checking the seqcount lock.
> But looking at rcu_dereference makes it seem harmless to add it in
> more places, it handles
> the ACCESS_ONCE and barrier() for us.
 And it makes the code more maintainable, and helps sparse doing a
 lot of
 checking for us. I guess
 we can tolerate a couple of extra barriers for that.

> We could probably get away with using RCU_INIT_POINTER on the writer
> side,
> because the smp_wmb is already done by arranging seqcount updates
> correctly.
 Hmm. yes, probably. At least in the replace function. I think if we do
 it in other places, we should add comments as to where
 the smp_wmb() is located, for future reference.


 Also  I saw in a couple of places where you're checking the shared
 pointers, you're not checking for NULL pointers, which I guess may
 happen if shared_count and pointers are not in full sync?

>>> No, because shared_count is protected with seqcount. I only allow
>>> appending to the array, so when
>>> shared_count is validated by seqcount it means that the
>>> [0...shared_count) indexes are valid and non-null.
>>> What could happen though is that the fence at a specific index is
>>> updated with another one from the same
>>> context, but that's harmless.
>>>
>> Hmm, doesn't attaching an exclusive fence clear all shared fence
>> pointers from under a reader?
>>
> No, for that reason. It only resets shared_count to 0.

Ah. OK. I guess I didn't read the code carefully enough.

Thanks,
Thomas



>
> ~Maarten
--
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/8] arm64: Decouple page size from level of translation

[Jungseok Lee]

This patch separates page size from level of translation tables in
configuration. It facilitates introduction of different options,
such as 4KB + 4 levels, 16KB + 4 levels and 64KB + 3 levels, easily.

Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm64/Kconfig |   36 +++-
 arch/arm64/include/asm/page.h  |2 +-
 arch/arm64/include/asm/pgalloc.h   |4 ++--
 arch/arm64/include/asm/pgtable-hwdef.h |2 +-
 arch/arm64/include/asm/pgtable.h   |8 +++
 arch/arm64/include/asm/tlb.h   |2 +-
 6 files changed, 44 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e6e4d37..1a2faf9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -144,14 +144,48 @@ endmenu
 
 menu "Kernel Features"
 
+choice
+   prompt "Page size"
+   default ARM64_4K_PAGES
+   help
+ Allows page size.
+
+config ARM64_4K_PAGES
+   bool "4KB"
+   help
+ This feature enables 4KB pages support.
+
 config ARM64_64K_PAGES
-   bool "Enable 64KB pages support"
+   bool "64KB"
help
  This feature enables 64KB pages support (4KB by default)
  allowing only two levels of page tables and faster TLB
  look-up. AArch32 emulation is not available when this feature
  is enabled.
 
+endchoice
+
+choice
+   prompt "Level of translation tables"
+   default ARM64_3_LEVELS if ARM64_4K_PAGES
+   default ARM64_2_LEVELS if ARM64_64K_PAGES
+   help
+ Allows level of translation tables.
+
+config ARM64_2_LEVELS
+   bool "2 level"
+   depends on ARM64_64K_PAGES
+   help
+ This feature enables 2 levels of translation tables.
+
+config ARM64_3_LEVELS
+   bool "3 level"
+   depends on ARM64_4K_PAGES
+   help
+ This feature enables 3 levels of translation tables.
+
+endchoice
+
 config CPU_BIG_ENDIAN
bool "Build big-endian kernel"
help
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 46bf666..268e53d 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -33,7 +33,7 @@
 
 #ifndef __ASSEMBLY__
 
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
 #include 
 #else
 #include 
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 9bea6e7..4829837 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,7 +26,7 @@
 
 #define check_pgt_cache()  do { } while (0)
 
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
 
 static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
 {
@@ -44,7 +44,7 @@ static inline void pud_populate(struct mm_struct *mm, pud_t 
*pud, pmd_t *pmd)
set_pud(pud, __pud(__pa(pmd) | PMD_TYPE_TABLE));
 }
 
-#endif /* CONFIG_ARM64_64K_PAGES */
+#endif /* CONFIG_ARM64_2_LEVELS */
 
 extern pgd_t *pgd_alloc(struct mm_struct *mm);
 extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
b/arch/arm64/include/asm/pgtable-hwdef.h
index 5fc8a66..9cd86c6 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -16,7 +16,7 @@
 #ifndef __ASM_PGTABLE_HWDEF_H
 #define __ASM_PGTABLE_HWDEF_H
 
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
 #include 
 #else
 #include 
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 90c811f..a64ce5e 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -47,7 +47,7 @@ extern void __pmd_error(const char *file, int line, unsigned 
long val);
 extern void __pgd_error(const char *file, int line, unsigned long val);
 
 #define pte_ERROR(pte) __pte_error(__FILE__, __LINE__, pte_val(pte))
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
 #define pmd_ERROR(pmd) __pmd_error(__FILE__, __LINE__, pmd_val(pmd))
 #endif
 #define pgd_ERROR(pgd) __pgd_error(__FILE__, __LINE__, pgd_val(pgd))
@@ -320,7 +320,7 @@ static inline pte_t *pmd_page_vaddr(pmd_t pmd)
  */
 #define mk_pte(page,prot)  pfn_pte(page_to_pfn(page),prot)
 
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
 
 #define pud_none(pud)  (!pud_val(pud))
 #define pud_bad(pud)   (!(pud_val(pud) & 2))
@@ -342,7 +342,7 @@ static inline pmd_t *pud_page_vaddr(pud_t pud)
return __va(pud_val(pud) & PHYS_MASK & (s32)PAGE_MASK);
 }
 
-#endif /* CONFIG_ARM64_64K_PAGES */
+#endif /* CONFIG_ARM64_2_LEVELS */
 
 /* to find an entry in a page-table-directory */
 #define pgd_index(addr)(((addr) >> PGDIR_SHIFT) & 
(PTRS_PER_PGD - 1))
@@ -353,7 +353,7 @@ static inline pmd_t *pud_page_vaddr(pud_t pud)
 #define pgd_offset_k(addr) pgd_offset(&init_mm, addr)
 
 /* Find an entry in the second-level page table.. */
-#ifndef CONFIG_ARM64_64K_PAGES
+#i

[PATCH 0/8] Support 4 levels of translation tables for ARM64

[Jungseok Lee]

Hi All,

This patchset supports 4 levels of tranlsation tables for ARM64.

Firstly, the patchset decouples page size from level of translation tables
as taking account into the comment from Catalin Marinas:
http://www.spinics.net/linux/lists/arm-kernel/msg319552.html

Then, it implements 4 levels of translation tables for both native, HYP
and stage2 sides.

This series is validated with Fast Models and kvmtool as platform and guest
launcher, respectively.

Jungseok Lee (8):
  arm64: Use pr_* instead of printk
  arm/arm64: KVM: Fix line length exceeding 80 characters
  arm64: Decouple page size from level of translation tables
  arm64: Introduce a kernel configuration option for VA_BITS
  arm64: Add a description on 48-bit address space with 4KB pages
  arm64: Add 4 levels of page tables definition with 4KB pages
  arm64: mm: Implement 4 levels of translation tables
  arm64: KVM: Implement 4 levels of translation tables for HYP and stage2

Documentation/arm64/memory.txt|   59 ++--
 arch/arm/kvm/mmu.c|  100 ++---
 arch/arm64/Kconfig|   51 ++-
 arch/arm64/include/asm/kvm_arm.h  |   20 +
 arch/arm64/include/asm/kvm_mmu.h  |1 +
 arch/arm64/include/asm/memory.h   |6 +-
 arch/arm64/include/asm/page.h |6 +-
 arch/arm64/include/asm/pgalloc.h  |   24 -
 arch/arm64/include/asm/pgtable-4level-hwdef.h |   50 +++
 arch/arm64/include/asm/pgtable-4level-types.h |   71 +++
 arch/arm64/include/asm/pgtable-hwdef.h|   10 ++-
 arch/arm64/include/asm/pgtable.h  |   52 +--
 arch/arm64/include/asm/tlb.h  |   10 ++-
 arch/arm64/kernel/head.S  |   45 +-
 arch/arm64/kernel/traps.c |   19 ++--
 arch/arm64/mm/fault.c |1 +
 arch/arm64/mm/mmu.c   |   14 ++-
 17 files changed, 488 insertions(+), 51 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/

[RFC PATCH v3] Use kernfs_break_active_protection() for device online store callbacks

[Li Zhong]

I noticed following lockdep warning when trying acpi hot-remove cpus:

[84154.204080] ==
[84154.204080] [ INFO: possible circular locking dependency detected ]
[84154.204080] 3.14.0-next-20140408+ #24 Tainted: GW
[84154.204080] ---
[84154.204080] bash/777 is trying to acquire lock:
[84154.204080]  (cpu_add_remove_lock){+.+.+.}, at: []
cpu_maps_update_begin+0x17/0x20
[84154.213203] 
[84154.213203] but task is already holding lock:
[84154.213203]  (s_active#79){.+}, at: []
kernfs_fop_write+0xe4/0x190
[84154.213203] 
[84154.213203] which lock already depends on the new lock.
[84154.213203] 
[84154.213203] 
[84154.213203] the existing dependency chain (in reverse order) is:
[84154.213203] 
-> #3 (s_active#79){.+}:
[84154.213203][] lock_acquire+0x9b/0x1d0
[84154.213203][] __kernfs_remove+0x250/0x310
[84154.213203][] kernfs_remove_by_name_ns
+0x50/0xc0
[84154.213203][] sysfs_remove_file_ns
+0x15/0x20
[84154.213203][] device_remove_file+0x19/0x20
[84154.213203][] device_remove_attrs+0x33/0x80
[84154.213203][] device_del+0x127/0x1c0
[84154.213203][] device_unregister+0x22/0x60
[84154.213203][] unregister_cpu+0x1e/0x40
[84154.213203][] arch_unregister_cpu+0x23/0x30
[84154.213203][] acpi_processor_remove
+0x8d/0xb2
[84154.213203][] acpi_bus_trim+0x5a/0x8d
[84154.213203][] acpi_device_hotplug
+0x1a8/0x3ec
[84154.213203][] acpi_hotplug_work_fn
+0x1f/0x2b
[84154.213203][] process_one_work+0x1eb/0x6b0
[84154.213203][] worker_thread+0x11b/0x370
[84154.213203][] kthread+0xe4/0x100
[84154.213203][] ret_from_fork+0x7c/0xb0
[84154.213203] 
-> #2 (cpu_hotplug.lock#2){+.+.+.}:
[84154.213203][] lock_acquire+0x9b/0x1d0
[84154.213203][] mutex_lock_nested+0x50/0x3c0
[84154.213203][] cpu_hotplug_begin+0x4f/0x80
[84154.213203][] _cpu_up+0x3f/0x160
[84154.213203][] cpu_up+0x69/0x80
[84154.213203][] smp_init+0x60/0x8c
[84154.213203][] kernel_init_freeable
+0x126/0x23b
[84154.213203][] kernel_init+0xe/0xf0
[84154.213203][] ret_from_fork+0x7c/0xb0
[84154.213203] 
-> #1 (cpu_hotplug.lock){++}:
[84154.213203][] lock_acquire+0x9b/0x1d0
[84154.213203][] cpu_hotplug_begin+0x41/0x80
[84154.213203][] _cpu_up+0x3f/0x160
[84154.213203][] cpu_up+0x69/0x80
[84154.213203][] smp_init+0x60/0x8c
[84154.213203][] kernel_init_freeable
+0x126/0x23b
[84154.213203][] kernel_init+0xe/0xf0
[84154.213203][] ret_from_fork+0x7c/0xb0
[84154.213203] 
-> #0 (cpu_add_remove_lock){+.+.+.}:
[84154.213203][] __lock_acquire+0x1f2a/0x1f60
[84154.213203][] lock_acquire+0x9b/0x1d0
[84154.213203][] mutex_lock_nested+0x50/0x3c0
[84154.213203][] cpu_maps_update_begin
+0x17/0x20
[84154.213203][] cpu_down+0x1d/0x50
[84154.213203][] cpu_subsys_offline+0x14/0x20
[84154.213203][] device_offline+0xad/0xd0
[84154.213203][] online_store+0x42/0x80
[84154.213203][] dev_attr_store+0x18/0x30
[84154.213203][] sysfs_kf_write+0x49/0x60
[84154.213203][] kernfs_fop_write+0x109/0x190
[84154.213203][] vfs_write+0xbe/0x1c0
[84154.213203][] SyS_write+0x52/0xb0
[84154.213203][] tracesys+0xd0/0xd5
[84154.213203] 
[84154.213203] other info that might help us debug this:
[84154.213203] 
[84154.213203] Chain exists of:
  cpu_add_remove_lock --> cpu_hotplug.lock#2 --> s_active#79

[84154.213203]  Possible unsafe locking scenario:
[84154.213203] 
[84154.213203]CPU0CPU1
[84154.213203]
[84154.213203]   lock(s_active#79);
[84154.213203]lock(cpu_hotplug.lock#2);
[84154.213203]lock(s_active#79);
[84154.213203]   lock(cpu_add_remove_lock);
[84154.213203] 
[84154.213203]  *** DEADLOCK ***
.

The deadlock itself seems already fixed in commit 5e33bc41. 

As Tejun suggested, to avoid this lockdep warning,
kernfs_break_active_protection() is used before online/offline callbacks
to take the s_active lock out of the dependency chain during
online/offline operations. 

Signed-off-by: Li Zhong 
---
 drivers/base/core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0dd6528..b313ad7 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -439,6 +439,7 @@ static ssize_t online_store(struct device *dev, struct 
device_attribute *attr,
 {
bool val;
int ret;
+   struct kernfs_node *kn;
 
ret = strtobool(buf, &val);
if (ret < 0)
@@ -448,7 +449,19 @@ static ssize_t online_store(struct device *dev, struct 
device_attribute *attr,
if (ret)
return 

[PATCH V2] tty: fix memleak in alloc_pid

[Chen Tingjie]

There is memleak in alloc_pid:
--
unreferenced object 0xd3453a80 (size 64):
  comm "adbd", pid 1730, jiffies 66363 (age 6586.950s)
  hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 40 c2 f6 d5 00 d3 25 c1 59 28 00 00  @.%.Y(..
  backtrace:
[] kmemleak_alloc+0x3c/0xa0
[] kmem_cache_alloc+0xc6/0x190
[] alloc_pid+0x1e/0x400
[] copy_process.part.39+0xad4/0x1120
[] do_fork+0x99/0x330
[] sys_fork+0x28/0x30
[] syscall_call+0x7/0xb
[] 0x

the leak is due to unreleased pid->count, which execute in function:
get_pid()(pid->count++) and put_pid()(pid->count--).

The race condition as following:
task[dumpsys]   task[adbd]
in disassociate_ctty()  in tty_signal_session_leader()
--- -
tty = get_current_tty();
// tty is not NULL
...
spin_lock_irq(¤t->sighand->siglock);
put_pid(current->signal->tty_old_pgrp);
current->signal->tty_old_pgrp = NULL;
spin_unlock_irq(¤t->sighand->siglock);

spin_lock_irq(&p->sighand->siglock);
...
p->signal->tty = NULL;
...
spin_unlock_irq(&p->sighand->siglock);

tty = get_current_tty();
// tty NULL, goto else branch by accident.
if (tty) {
...
put_pid(tty_session);
put_pid(tty_pgrp);
...
} else {
print msg
}

in task[dumpsys], in disassociate_ctty(), tty is set NULL by task[adbd],
tty_signal_session_leader(), then it goto else branch and lack of
put_pid(), cause memleak.

move spin_unlock(sighand->siglock) after get_current_tty() can avoid
the race and fix the memleak.

Change-Id: Ic960dda039c8f99aad3e0f4d176489a966c62f6a
Signed-off-by: Zhang Jun 
Signed-off-by: Chen Tingjie 
---
 drivers/tty/tty_io.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 31c4a57..72547a3 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -874,9 +874,8 @@ void disassociate_ctty(int on_exit)
spin_lock_irq(¤t->sighand->siglock);
put_pid(current->signal->tty_old_pgrp);
current->signal->tty_old_pgrp = NULL;
-   spin_unlock_irq(¤t->sighand->siglock);
 
-   tty = get_current_tty();
+   tty = tty_kref_get(current->signal->tty);
if (tty) {
unsigned long flags;
spin_lock_irqsave(&tty->ctrl_lock, flags);
@@ -893,6 +892,7 @@ void disassociate_ctty(int on_exit)
 #endif
}
 
+   spin_unlock_irq(¤t->sighand->siglock);
/* Now clear signal->tty under the lock */
read_lock(&tasklist_lock);
session_clear_tty(task_session(current));
-- 
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 v3 2/6] IIO: core: Introduce read_raw_multi

[Jonathan Cameron]

On April 14, 2014 2:51:22 AM GMT+01:00, Srinivas Pandruvada 
 wrote:
>
>On 04/12/2014 09:52 AM, Jonathan Cameron wrote:
>> On 09/04/14 01:56, Srinivas Pandruvada wrote:
>>> This callback is introduced to overcome some limitations of existing
>>> read_raw callback. The functionality of both existing read_raw and
>>> read_raw_multi is similar, both are used to request values from the
>>> device. The current read_raw callback allows only two return values.
>>> The new read_raw_multi allows returning multiple values. Instead of
>>> passing just address of val and val2, it passes length and pointer
>>> to values. Depending on the type and length of passed buffer, iio
>>> client drivers can return multiple values.
>>>
>>> Signed-off-by: Srinivas Pandruvada
>
>> Hi Srinivas.
>>
>> This has come together pretty much how I thought it would. Very nice.
>> Only comment inline is that I'd prefer we took care now with
>possiblity
>> of really long sets of values so that we don't get bitten by it
>sometime
>> in the future.
>>
>I was thinking of using snprintf, but buf had no length passed. If we 
>assume PAGE_SIZE as max length
>then I can do what you suggested below,
IIRC sysfs buffers are always PAGE_SIZE long. Easy enough to check I guess.
>
>Thanks,
>Srinivas
>> If you want to drop the reference to 0 having special meaning in the
>> comment as well, thats fine by me.
>>
>> Jonathan
>>> ---
>>>   drivers/iio/iio_core.h   |  2 +-
>>>   drivers/iio/industrialio-core.c  | 65 
>>> ++--
>>>   drivers/iio/industrialio-event.c |  6 ++--
>>>   drivers/iio/inkern.c | 16 --
>>>   include/linux/iio/iio.h  | 17 +++
>>>   include/linux/iio/types.h|  1 +
>>>   6 files changed, 80 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
>>> index f6db6af..30327ad 100644
>>> --- a/drivers/iio/iio_core.h
>>> +++ b/drivers/iio/iio_core.h
>>> @@ -35,7 +35,7 @@ int __iio_add_chan_devattr(const char *postfix,
>>>  struct list_head *attr_list);
>>>   void iio_free_chan_devattr_list(struct list_head *attr_list);
>>>
>>> -ssize_t iio_format_value(char *buf, unsigned int type, int val, int
>
>>> val2);
>>> +ssize_t iio_format_value(char *buf, unsigned int type, int size,
>int 
>>> *val);
>>>
>>>   /* Event interface flags */
>>>   #define IIO_BUSY_BIT_POS 1
>>> diff --git a/drivers/iio/industrialio-core.c 
>>> b/drivers/iio/industrialio-core.c
>>> index ede16aec..3bd565c 100644
>>> --- a/drivers/iio/industrialio-core.c
>>> +++ b/drivers/iio/industrialio-core.c
>>> @@ -373,41 +373,53 @@ EXPORT_SYMBOL_GPL(iio_enum_write);
>>>* @buf: The buffer to which the formated value gets written
>>>* @type: One of the IIO_VAL_... constants. This decides how the 
>>> val and val2
>>>*parameters are formatted.
>>> - * @val: First part of the value, exact meaning depends on the type
>
>>> parameter.
>>> - * @val2: Second part of the value, exact meaning depends on the 
>>> type parameter.
>>> + * @vals: pointer to the values, exact meaning depends on the type 
>>> parameter.
>>>*/
>>> -ssize_t iio_format_value(char *buf, unsigned int type, int val, int
>
>>> val2)
>>> +ssize_t iio_format_value(char *buf, unsigned int type, int size,
>int 
>>> *vals)
>>>   {
>>>   unsigned long long tmp;
>>>   bool scale_db = false;
>>>
>>>   switch (type) {
>>>   case IIO_VAL_INT:
>>> -return sprintf(buf, "%d\n", val);
>>> +return sprintf(buf, "%d\n", vals[0]);
>>>   case IIO_VAL_INT_PLUS_MICRO_DB:
>>>   scale_db = true;
>>>   case IIO_VAL_INT_PLUS_MICRO:
>>> -if (val2 < 0)
>>> -return sprintf(buf, "-%ld.%06u%s\n", abs(val), -val2,
>>> +if (vals[1] < 0)
>>> +return sprintf(buf, "-%ld.%06u%s\n", abs(vals[0]),
>>> +-vals[1],
>>>   scale_db ? " dB" : "");
>>>   else
>>> -return sprintf(buf, "%d.%06u%s\n", val, val2,
>>> +return sprintf(buf, "%d.%06u%s\n", vals[0], vals[1],
>>>   scale_db ? " dB" : "");
>>>   case IIO_VAL_INT_PLUS_NANO:
>>> -if (val2 < 0)
>>> -return sprintf(buf, "-%ld.%09u\n", abs(val), -val2);
>>> +if (vals[1] < 0)
>>> +return sprintf(buf, "-%ld.%09u\n", abs(vals[0]),
>>> +-vals[1]);
>>>   else
>>> -return sprintf(buf, "%d.%09u\n", val, val2);
>>> +return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
>>>   case IIO_VAL_FRACTIONAL:
>>> -tmp = div_s64((s64)val * 10LL, val2);
>>> -val2 = do_div(tmp, 10LL);
>>> -val = tmp;
>>> -return sprintf(buf, "%d.%09u\n", val, val2);
>>> +tmp = div_s64((s64)vals[0] * 10LL, vals[1]);
>>> +vals[1] = do_div(tmp, 10LL);
>>> +vals[0] = tmp;
>>> +return sprintf(buf, "%d.%09u\n", vals[0], vals[1]);
>>>

[PATCH v3 resend] clk: s2mps11: Add support for S2MPS14 clocks

[Krzysztof Kozlowski]

Hi,

This is a resend of third version of patchset adding support for
the S2MPS14 device to the s2mps11 clock driver.

Previous discusson can be found here:
http://thread.gmane.org/gmane.linux.kernel.samsung-soc/28039

Changes since v2:
=
1. Patch 2/3: Remove MFD cells of_compatible which aren't used by child
   drivers and are not documented.
2. Added Tomasz's Review-by.

Changes since v1:
=
1. Patch 1/3: Update driver description in Kconfig.
2. Patch 2/3: Add of_compatible to all MFD cells.
3. Add Yadwinder's Review-by.

Best regards,
Krzysztof

Krzysztof Kozlowski (1):
  clk: s2mps11: Add support for S2MPS14 clocks

 drivers/clk/Kconfig   |  8 +++
 drivers/clk/clk-s2mps11.c | 61 +++
 2 files changed, 50 insertions(+), 19 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 v3 resend] clk: s2mps11: Add support for S2MPS14 clocks

[Krzysztof Kozlowski]

This patch adds support for S2MPS14 PMIC clocks (BT and AP) to the
s2mps11 clock driver.

Signed-off-by: Krzysztof Kozlowski 
Cc: Kyungmin Park 
Reviewed-by: Yadwinder Singh Brar 
Reviewed-by: Tomasz Figa 
---
 drivers/clk/Kconfig   |  8 +++
 drivers/clk/clk-s2mps11.c | 61 +++
 2 files changed, 50 insertions(+), 19 deletions(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 6f56d3a4f010..8f9ce8ba036d 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -65,12 +65,12 @@ config COMMON_CLK_SI570
  clock generators.
 
 config COMMON_CLK_S2MPS11
-   tristate "Clock driver for S2MPS11/S5M8767 MFD"
+   tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
---help---
- This driver supports S2MPS11/S5M8767 crystal oscillator clock. These
- multi-function devices have 3 fixed-rate oscillators, clocked at
- 32KHz each.
+ This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
+ clock. These multi-function devices have two (S2MPS14) or three
+ (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
 
 config CLK_TWL6040
tristate "External McPDM functional clock from twl6040"
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index f2f62a1bf61a..b78eafeab038 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -1,7 +1,7 @@
 /*
  * clk-s2mps11.c - Clock driver for S2MPS11.
  *
- * Copyright (C) 2013 Samsung Electornics
+ * Copyright (C) 2013,2014 Samsung Electornics
  *
  * This program is free software; you can redistribute  it and/or modify it
  * under  the terms of  the GNU General  Public License as published by the
@@ -13,10 +13,6 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- *
  */
 
 #include 
@@ -27,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -125,7 +122,21 @@ static struct clk_init_data 
s2mps11_clks_init[S2MPS11_CLKS_NUM] = {
},
 };
 
-static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev)
+static struct clk_init_data s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
+   [S2MPS11_CLK_AP] = {
+   .name = "s2mps14_ap",
+   .ops = &s2mps11_clk_ops,
+   .flags = CLK_IS_ROOT,
+   },
+   [S2MPS11_CLK_BT] = {
+   .name = "s2mps14_bt",
+   .ops = &s2mps11_clk_ops,
+   .flags = CLK_IS_ROOT,
+   },
+};
+
+static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev,
+   struct clk_init_data *clks_init)
 {
struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
struct device_node *clk_np;
@@ -145,9 +156,12 @@ static struct device_node *s2mps11_clk_parse_dt(struct 
platform_device *pdev)
if (!clk_table)
return ERR_PTR(-ENOMEM);
 
-   for (i = 0; i < S2MPS11_CLKS_NUM; i++)
+   for (i = 0; i < S2MPS11_CLKS_NUM; i++) {
+   if (!clks_init[i].name)
+   continue; /* Skip clocks not present in some devices */
of_property_read_string_index(clk_np, "clock-output-names", i,
-   &s2mps11_clks_init[i].name);
+   &clks_init[i].name);
+   }
 
return clk_np;
 }
@@ -158,6 +172,7 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
struct s2mps11_clk *s2mps11_clks, *s2mps11_clk;
struct device_node *clk_np = NULL;
unsigned int s2mps11_reg;
+   struct clk_init_data *clks_init;
int i, ret = 0;
u32 val;
 
@@ -168,25 +183,33 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
 
s2mps11_clk = s2mps11_clks;
 
-   clk_np = s2mps11_clk_parse_dt(pdev);
-   if (IS_ERR(clk_np))
-   return PTR_ERR(clk_np);
-
switch(platform_get_device_id(pdev)->driver_data) {
case S2MPS11X:
s2mps11_reg = S2MPS11_REG_RTC_CTRL;
+   clks_init = s2mps11_clks_init;
+   break;
+   case S2MPS14X:
+   s2mps11_reg = S2MPS14_REG_RTCCTRL;
+   clks_init = s2mps14_clks_init;
break;
case S5M8767X:
s2mps11_reg = S5M8767_REG_CTRL1;
+   clks_init = s2mps11_clks_init;
break;
default:
dev_err(&pdev->dev, "Invalid device type\n");
return -EINVAL;
};
 
+   clk_np = s2mps11_clk_parse_dt(pdev, clks_init);
+   if (IS_ERR(clk_np))
+   return PTR_ERR(clk_np);
+
for (i = 0; i < S2MPS11_CLKS_NUM; i++, s2mps11_clk++) {
+ 

Re: [PATCH] workqueue: fix double unlock bug

[DaeSeok Youn]

2014-04-14 15:50 GMT+09:00 Lai Jiangshan :
> On 04/14/2014 08:58 AM, Daeseok Youn wrote:
>>
>> mutex_unlock() and put_pwq_unlocked() do not need to be called
>> when alloc_unbound_pwq() is failed.
>>
>> Signed-off-by: Daeseok Youn 
>> ---
>>  kernel/workqueue.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>> index 0ee63af..e6e9f6a 100644
>> --- a/kernel/workqueue.c
>> +++ b/kernel/workqueue.c
>> @@ -4100,7 +4100,7 @@ static void wq_update_unbound_numa(struct 
>> workqueue_struct *wq, int cpu,
>>   if (!pwq) {
>>   pr_warning("workqueue: allocation failed while updating NUMA 
>> affinity of \"%s\"\n",
>>  wq->name);
>> - goto out_unlock;
>> + return;
>>   }
>>
>>   /*
>
>
> Nice catch!!!
>
> The supposed correct behavior is documented in the head of
> this function. We forgot to do it.
>
>  * If NUMA affinity can't be adjusted due to memory allocation failure, it
>  * falls back to @wq->dfl_pwq which may not be optimal but is always
>  * correct.
>
> Could you use the following code instead of "goto out_unlock":
> mutex_lock(&wq->mutex);
> if (pwq == wq->dfl_pwq)
> goto out_unlock;
> else
> goto use_dfl_pwq;
>
> Correct&BAD. There are two blocks of suck code in this function:
> if (pwq == wq->dfl_pwq)
> goto out_unlock;
> else
> goto use_dfl_pwq;
>
> You can replace both these two blocks code to the following code:
> goto use_dfl_pwq;
OK. I will remove that "if-else" condition and just use "goto use_dfl_pwq" and
send this patch as V2.

Thanks.
Daeseok Youn
>
> The result is the same as before except it adds some small overhead.
> I don't care the small overhead in this function.
>
> Thanks
> Lai
>
--
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] input: cyapa: enable/disable trackpad device based on LID state

[Dudley Du]

Rely on EV_SW and SW_LID bits to identify a LID device, and hook
up our filter to listen for SW_LID events to enable/disable touchpad when
LID is open/closed.
TEST=test on Chomebooks.

Signed-off-by: Du, Dudley 
---
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 6820b3f..da03427 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -523,6 +523,9 @@ struct cyapa {
int physical_size_x;
int physical_size_y;

+   bool lid_handler_registered;
+   struct input_handler lid_handler;
+
/* used in ttsp and truetouch based trackpad devices. */
u8 x_origin;  /* X Axis Origin: 0 = left side; 1 = rigth side. */
u8 y_origin;  /* Y Axis Origin: 0 = top; 1 = bottom. */
@@ -3107,6 +3110,125 @@ static void cyapa_start_runtime(struct cyapa *cyapa)
 static void cyapa_start_runtime(struct cyapa *cyapa) {}
 #endif /* CONFIG_PM_RUNTIME */

+
+/*
+ * We rely on EV_SW and SW_LID bits to identify a LID device, and hook
+ * up our filter to listen for SW_LID events to enable/disable touchpad when
+ * LID is open/closed.
+ */
+static const struct input_device_id lid_device_ids[] = {
+   {
+   .flags = INPUT_DEVICE_ID_MATCH_EVBIT |
+INPUT_DEVICE_ID_MATCH_SWBIT,
+   .evbit = { BIT_MASK(EV_SW) },
+   .swbit = { BIT_MASK(SW_LID) },
+   },
+   { },
+};
+
+static int lid_device_connect(struct input_handler *handler,
+ struct input_dev *dev,
+ const struct input_device_id *id)
+{
+   struct input_handle *lid_handle;
+   int error;
+
+   lid_handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
+   if (!lid_handle)
+   return -ENOMEM;
+
+   lid_handle->dev = dev;
+   lid_handle->handler = handler;
+   lid_handle->name = "lid_event_handler";
+   lid_handle->private = handler->private;
+
+   error = input_register_handle(lid_handle);
+   if (error)
+   goto err_free;
+
+   error = input_open_device(lid_handle);
+   if (error)
+   goto err_unregister;
+
+   return 0;
+err_unregister:
+   input_unregister_handle(lid_handle);
+err_free:
+   kfree(lid_handle);
+   return error;
+}
+
+static void lid_device_disconnect(struct input_handle *handle)
+{
+   input_close_device(handle);
+   input_unregister_handle(handle);
+   kfree(handle);
+}
+
+static bool lid_event_filter(struct input_handle *handle,
+unsigned int type, unsigned int code, int value)
+{
+   struct cyapa *cyapa = handle->private;
+   struct device *dev = &cyapa->client->dev;
+
+   if (type == EV_SW && code == SW_LID) {
+   if (cyapa->suspended) {
+   /*
+* If the lid event filter is called while suspended,
+* there is no guarantee that the underlying i2cs are
+* resumed at this point, so it is not safe to issue
+* the command to change power modes.
+* Instead, rely on cyapa_resume to set us back to
+* PWR_MODE_FULL_ACTIVE.
+*/
+   return false;
+   }
+   if (value == 0) {
+   if (cyapa->cyapa_set_power_mode)
+   cyapa->cyapa_set_power_mode(cyapa,
+   PWR_MODE_FULL_ACTIVE, 0);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+   } else {
+   pm_runtime_disable(dev);
+   if (cyapa->cyapa_set_power_mode)
+   cyapa->cyapa_set_power_mode(cyapa,
+   PWR_MODE_OFF, 0);
+   }
+   }
+
+   return false;
+}
+
+static void lid_event_register_handler(struct cyapa *cyapa)
+{
+   int error;
+   struct input_handler *lid_handler = &cyapa->lid_handler;
+
+   if (cyapa->lid_handler_registered)
+   return;
+
+   lid_handler->filter = lid_event_filter;
+   lid_handler->connect= lid_device_connect;
+   lid_handler->disconnect = lid_device_disconnect;
+   lid_handler->name   = "cyapa_lid_event_handler";
+   lid_handler->id_table   = lid_device_ids;
+   lid_handler->private= cyapa;
+
+   error = input_register_handler(lid_handler);
+   if (error)
+   return;
+   cyapa->lid_handler_registered = true;
+}
+
+static void lid_event_unregister_handler(struct cyapa *cyapa)
+{
+   if (cyapa->lid_handler_registered) {
+   input_unregister_handler(&cyapa->lid_handler);
+   cyapa->lid_handler_registered = false;
+   }
+}
+
 static void cyapa_detect_async(void *data, async_cookie_t cookie)
 {
str

[PATCH 0/6] input: cyapa: integrated with gen5 trackpad supported in one driver.

[Dudley Du]

This patch set is made based on kernel 3.14.0. It's aimed to
re-architecture the cyapa driver to support the old gen3 trackpad
device and new gen5 trackpad device in one cyapa driver for
easily products support based on customers' requirements,
and add sysfs functions and interfaces supported that required
by users and customers.

Beside this patch, it has 6 patches listed as below.
For these patches each one is patched based on previous one.

patch 1/6: change the architecture of cyapa driver to support function
pointers and applying the device proble function in async thread
to speed up system boot time.

patch 2/6: add gen5 trackpad devices supported in cyapa driver.

patch 3/6: add full power mode and runtime power mode supported.

patch 4/6: enable/disable trackpad device based on LID state.

patch 5/6: add sysfs interfaces supported for gen3 trackpad device.

patch 6/6: add sysfs interfaces supported for gen5 trackpad device.
This message and any attachments may contain Cypress (or its subsidiaries) 
confidential information. If it has been received in error, please advise the 
sender and immediately delete this message.
<>

[PATCH 3/6] input: cyapa: add power mode sleep and runtime power mode supported.

[Dudley Du]

In order to save power when the trackpad device is not used, the sleep power
mode and runtime power mode must be supported. And the enter sleep time can
be configured in the sysfs system.
TEST=test on Chomebooks.

Signed-off-by: Du, Dudley 
---
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 7b269d8..6820b3f 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 

 /* APA trackpad firmware generation */
 #define CYAPA_GEN_UNKNOWN   0x00   /* unknown protocol. */
@@ -505,6 +506,10 @@ struct cyapa {
u16 suspend_sleep_time;
u8 real_power_mode;
u16 real_sleep_time;
+#ifdef CONFIG_PM_RUNTIME
+   u8 runtime_suspend_power_mode;
+   u16 runtime_suspend_sleep_time;
+#endif /* CONFIG_PM_RUNTIME */
bool suspended;

/* read from query data region. */
@@ -1873,6 +1878,13 @@ static int cyapa_gen5_bl_exit(struct cyapa *cyapa)
return -EAGAIN;
 }

+static int cyapa_gen5_sleep_time_check(u16 sleep_time)
+{
+   if (sleep_time > 1000)
+   sleep_time = 1000;
+   return sleep_time;
+}
+
 static int cyapa_gen5_change_power_state(struct cyapa *cyapa, u8 power_state)
 {
int ret;
@@ -2571,6 +2583,9 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
struct input_dev *input = cyapa->input;
int length;

+   pm_runtime_get_sync(dev);
+   pm_runtime_mark_last_busy(dev);
+
if (device_may_wakeup(dev))
pm_wakeup_event(dev, 0);

@@ -2646,6 +2661,7 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)

if (cyapa->cyapa_irq_handler)
cyapa->cyapa_irq_handler(cyapa);
+   pm_runtime_put_sync_autosuspend(dev);

 out:
return IRQ_HANDLED;
@@ -2945,6 +2961,152 @@ static void cyapa_detect(struct cyapa *cyapa)
cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
 }

+
+/*
+ * Sysfs Interface.
+ */
+
+#ifdef CONFIG_PM_SLEEP
+static ssize_t cyapa_show_suspend_scanrate(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct cyapa *cyapa = dev_get_drvdata(dev);
+   u8 pwr_cmd = cyapa->suspend_power_mode;
+   u16 sleep_time;
+   int len;
+
+   if (pwr_cmd == PWR_MODE_BTN_ONLY)
+   len = scnprintf(buf, PAGE_SIZE, "%s\n", BTN_ONLY_MODE_NAME);
+   else if (pwr_cmd == PWR_MODE_OFF)
+   len = scnprintf(buf, PAGE_SIZE, "%s\n", OFF_MODE_NAME);
+   else {
+   if (cyapa->gen == CYAPA_GEN3)
+   sleep_time = cyapa_pwr_cmd_to_sleep_time(pwr_cmd);
+   else
+   sleep_time = cyapa->suspend_sleep_time;
+   len = scnprintf(buf, PAGE_SIZE, "%u\n", sleep_time);
+   }
+
+   return len;
+}
+
+static ssize_t cyapa_update_suspend_scanrate(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct cyapa *cyapa = dev_get_drvdata(dev);
+   u16 sleep_time;
+
+   if (buf == NULL || count == 0)
+   goto invalidparam;
+
+   if (sysfs_streq(buf, BTN_ONLY_MODE_NAME))
+   cyapa->suspend_power_mode = PWR_MODE_BTN_ONLY;
+   else if (sysfs_streq(buf, OFF_MODE_NAME))
+   cyapa->suspend_power_mode = PWR_MODE_OFF;
+   else if (!kstrtou16(buf, 10, &sleep_time)) {
+   cyapa->suspend_power_mode =
+   cyapa_sleep_time_to_pwr_cmd(sleep_time);
+   if (cyapa->gen > CYAPA_GEN3)
+   cyapa->suspend_sleep_time =
+   cyapa_gen5_sleep_time_check(sleep_time);
+   } else
+   goto invalidparam;
+
+   return count;
+
+invalidparam:
+   dev_err(dev, "invalid suspend scanrate ms parameters\n");
+   return -EINVAL;
+}
+
+static DEVICE_ATTR(suspend_scanrate_ms, S_IRUGO|S_IWUSR,
+  cyapa_show_suspend_scanrate,
+  cyapa_update_suspend_scanrate);
+
+static struct attribute *cyapa_power_wakeup_entries[] = {
+   &dev_attr_suspend_scanrate_ms.attr,
+   NULL,
+};
+
+static const struct attribute_group cyapa_power_wakeup_group = {
+   .name = power_group_name,
+   .attrs = cyapa_power_wakeup_entries,
+};
+#endif /* CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_PM_RUNTIME
+static ssize_t cyapa_show_rt_suspend_scanrate(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct cyapa *cyapa = dev_get_drvdata(dev);
+   u8 pwr_cmd = cyapa->runtime_suspend_power_mode;
+
+   if (cyapa->gen == CYAPA_GEN3)
+   return scnprintf(buf, PAGE_SIZE, "%u\n",
+   cyapa_pwr_cmd_to_sleep_time(pwr_cmd));
+   els

Aw: Re: new module to check constant memory for corruption

[Alexander . Kleinsorge]

Hi Andi,

I would like to ask for your help.
Is there a central kernel function that enables/disables write-protection for 
kernel memory?
I only know the place, where its write protected at booting for x86/x64.
If there is one place, it would be much easier, as to hook into many places 
(e.g. ftrace, etc). 

My goal is to verify kernel memory (the constant part), not to rebuild memcheck 
as a process.
In my Ubuntu 12.04 system, this range has never changed during module-runtime 
(many hours).
I think in >90% of all systems is no ftrace (etc) changing this range.

So I need either a trigger when to update my reference sum, or to know when 
ftrace (etc) are really working.
ftrace_enabled = 1 (default) is no indicator, because it is typically on.

Thanks a lot,
Alexander


Gesendet: Sonntag, 13. April 2014 um 05:00 Uhr
Von: "Andi Kleen" 
An: alexander.kleinso...@gmx.de
Cc: linux-kernel@vger.kernel.org
Betreff: Re: new module to check constant memory for corruption
alexander.kleinso...@gmx.de writes:

> ramcheck kernel module
> new module to check constant memory for corruption
>
> detect corruption of constant kernel memory (text and data) periodically.
> runtime costs about 1..2 ms per sec (about 10 mb with 5 mb/ms),
> which is distributed over 8 (BLOCKS) time partitions (less than half
> ms per sec).
> in case of checksum (xor) error, an kernel log is posted.
> manual trigger via /proc/ramcheck is possible.
> range: kallsyms_lookup_name("_text") .. kallsyms_lookup_name("__end_rodata")


Can you explain how this works? How does it handle legal writes?

If it just checks its own memory it could be done in user space.

-Andi

--
a...@linux.intel.com -- Speaking for myself only
--
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 RESEND 22/23] qla4xxx: Use pci_enable_msix_exact() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Vikas Chaudhary 
Cc: iscsi-dri...@qlogic.com
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/qla4xxx/ql4_nx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/qla4xxx/ql4_nx.c b/drivers/scsi/qla4xxx/ql4_nx.c
index 63328c8..a3e69e6 100644
--- a/drivers/scsi/qla4xxx/ql4_nx.c
+++ b/drivers/scsi/qla4xxx/ql4_nx.c
@@ -3787,7 +3787,7 @@ qla4_8xxx_enable_msix(struct scsi_qla_host *ha)
for (i = 0; i < QLA_MSIX_ENTRIES; i++)
entries[i].entry = qla4_8xxx_msix_entries[i].entry;
 
-   ret = pci_enable_msix(ha->pdev, entries, ARRAY_SIZE(entries));
+   ret = pci_enable_msix_exact(ha->pdev, entries, ARRAY_SIZE(entries));
if (ret) {
ql4_printk(KERN_WARNING, ha,
"MSI-X: Failed to enable support -- %d/%d\n",
-- 
1.7.7.6

--
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: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

[Alexandre Julliard]

Linus Torvalds  writes:

> On Fri, Apr 11, 2014 at 11:45 AM, Brian Gerst  wrote:
>>
>> I haven't tested it recently but I do know it has worked on 64-bit
>> kernels.  There is no reason for it not to, the only thing not
>> supported in long mode is vm86.  16-bit protected mode is unchanged.
>
> Afaik 64-bit windows doesn't support 16-bit binaries, so I just
> assumed Wine wouldn't do it either on x86-64. Not for any real
> technical reasons, though.
>
> HOWEVER. I'd like to hear something more definitive than "I haven't
> tested recently". The "we don't break user space" is about having
> actual real *users*, not about test programs.
>
> Are there people actually using 16-bit old windows programs under
> wine? That's what matters.

Yes, there is still a significant number of users, and we still
regularly get bug reports about specific 16-bit apps. It would be really
nice if we could continue to support them on x86-64, particularly since
Microsoft doesn't ;-)

-- 
Alexandre Julliard
julli...@winehq.org
--
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 RESEND 09/23] hpsa: Fallback to MSI rather than to INTx if MSI-X failed

[Alexander Gordeev]

Currently the driver falls back to INTx mode when MSI-X
initialization failed. This is a suboptimal behaviour
for chips that also support MSI. This update changes that
behaviour and falls back to MSI mode in case MSI-X mode
initialization failed.

Signed-off-by: Alexander Gordeev 
Cc: "Stephen M. Cameron" 
Cc: iss_storage...@hp.com
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/hpsa.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8cf4a0c..3284edb 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -6162,7 +6162,6 @@ static void hpsa_interrupt_mode(struct ctlr_info *h)
dev_warn(&h->pdev->dev, "MSI-X init failed %d\n",
   err);
h->msix_vector = 0;
-   goto default_int_mode;
}
}
if (pci_find_capability(h->pdev, PCI_CAP_ID_MSI)) {
-- 
1.7.7.6

--
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 RESEND 10/23] hpsa: Use pci_enable_msix_range() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: "Stephen M. Cameron" 
Cc: iss_storage...@hp.com
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/hpsa.c |   29 +
 1 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 3284edb..36bb1e4 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -6144,26 +6144,23 @@ static void hpsa_interrupt_mode(struct ctlr_info *h)
goto default_int_mode;
if (pci_find_capability(h->pdev, PCI_CAP_ID_MSIX)) {
dev_info(&h->pdev->dev, "MSIX\n");
-   h->msix_vector = MAX_REPLY_QUEUES;
-   err = pci_enable_msix(h->pdev, hpsa_msix_entries,
- h->msix_vector);
-   if (err > 0) {
+   err = pci_enable_msix_range(h->pdev, hpsa_msix_entries,
+   1, MAX_REPLY_QUEUES);
+   if (err < 0) {
+   dev_warn(&h->pdev->dev, "MSI-X init failed %d\n", err);
+   h->msix_vector = 0;
+   goto single_msi_mode;
+   } else if (err < MAX_REPLY_QUEUES) {
dev_warn(&h->pdev->dev, "only %d MSI-X vectors "
   "available\n", err);
-   h->msix_vector = err;
-   err = pci_enable_msix(h->pdev, hpsa_msix_entries,
- h->msix_vector);
-   }
-   if (!err) {
-   for (i = 0; i < h->msix_vector; i++)
-   h->intr[i] = hpsa_msix_entries[i].vector;
-   return;
-   } else {
-   dev_warn(&h->pdev->dev, "MSI-X init failed %d\n",
-  err);
-   h->msix_vector = 0;
}
+
+   h->msix_vector = err;
+   for (i = 0; i < h->msix_vector; i++)
+   h->intr[i] = hpsa_msix_entries[i].vector;
+   return;
}
+single_msi_mode:
if (pci_find_capability(h->pdev, PCI_CAP_ID_MSI)) {
dev_info(&h->pdev->dev, "MSI\n");
if (!pci_enable_msi(h->pdev))
-- 
1.7.7.6

--
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/

linus-next stats (Re: Linux 3.15-rc1 out, merge window closed)

[Stephen Rothwell]

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20140331 was the last linux-next before
v3.14.  I neglected to publish the stats for v3.14-rc1, but they are
mentioned below.)

Commits in v3.15-rc1 (relative to v3.14): 12034 (v3.14-rc1: 10622)
Commits in next-20140331: 11411 (next-20140121:  9792)
Commits with the same SHA1:   10432 (8810)
Commits with the same patch_id: 581 (1) ( 709)
Commits with the same subject line:  74 (1) (  48)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20140331:  11087   92.1%   (9567   90.1%)

Some breakdown of the list of extra commits (relative to next-20140331)
in -rc1:

Top ten first word of commit summary:

103 drm
 41 net
 39 libceph
 33 ceph
 30 media
 25 arm
 24 btrfs
 23 powerpc
 20 alsa
 19 target

Top ten authors:

 61 v...@zeniv.linux.org.uk
 47 ilya.dryo...@inktank.com
 24 zheng.z@intel.com
 19 thellst...@vmware.com
 16 t...@linutronix.de
 16 dbork...@redhat.com
 15 a.ha...@samsung.com
 13 matthew.d.ro...@intel.com
 12 mszer...@suse.cz
 12 dan.carpen...@oracle.com

Top nine commiters:

 90 da...@davemloft.net
 63 v...@zeniv.linux.org.uk
 57 torva...@linux-foundation.org
 56 s...@inktank.com
 31 m.che...@samsung.com
 27 matthew.garr...@nebula.com
 26 jeffrey.t.kirs...@intel.com
 26 b...@kernel.crashing.org
 24 daniel.vet...@ffwll.ch

There are also 325 commits in next-20140331 that didn't make it into
v3.15-rc1.

Top nine first word of commit summary:

 73 arm
 34 mm
 25 drm
 23 asoc
 21 bluetooth
  8 zram
  8 kdb
  8 dm
  6 ocfs2

Top nine authors:

 41 a...@linux-foundation.org
 24 a...@arndb.de
 16 n-horigu...@ah.jp.nec.com
 15 johan.hedb...@intel.com
 14 fabio.este...@freescale.com
 12 he...@sntech.de
 11 bradley.d.vol...@intel.com
  9 mpato...@redhat.com
  8 oder_ch...@realtek.com

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top nine commiters:

120 s...@canb.auug.org.au
 24 daniel.vet...@ffwll.ch
 24 a...@arndb.de
 23 broo...@linaro.org
 21 mar...@holtmann.org
 19 shawn@freescale.com
 17 shawn@linaro.org
 12 kgene@samsung.com
 10 jason.wes...@windriver.com

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp48NjD_q1Xu.pgp
Description: PGP signature

[PATCH v2 RESEND 17/23] pm8001: Fix invalid return when request_irq() failed

[Alexander Gordeev]

When a call to request_irq() failed pm8001_setup_msix()
still returns the success. This udate fixes the described
misbehaviour.

Signed-off-by: Alexander Gordeev 
Cc: xjtu...@gmail.com
Cc: lindar_...@usish.com
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Jack Wang 
---
 drivers/scsi/pm8001/pm8001_init.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/pm8001/pm8001_init.c 
b/drivers/scsi/pm8001/pm8001_init.c
index c4f31b21..df421f5 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -740,9 +740,10 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info 
*pm8001_ha)
pm8001_ha->irq_vector[i].irq_id = i;
pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
 
-   if (request_irq(pm8001_ha->msix_entries[i].vector,
+   rc = request_irq(pm8001_ha->msix_entries[i].vector,
pm8001_interrupt_handler_msix, flag,
-   intr_drvname[i], &(pm8001_ha->irq_vector[i]))) {
+   intr_drvname[i], &(pm8001_ha->irq_vector[i]));
+   if (rc) {
for (j = 0; j < i; j++)
free_irq(
pm8001_ha->msix_entries[j].vector,
-- 
1.7.7.6

--
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] arm64:kconfig: make default for CONFIG_COMPAT

[Chanho Min]

'make savedefconfig' doesn't generate defconfig properly due to
missing COMPAT default. So Add default and set to yes.

Signed-off-by: Chanho Min 
---
 arch/arm64/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4907b85..93b7531 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -294,6 +294,7 @@ source "fs/Kconfig.binfmt"
 
 config COMPAT
bool "Kernel support for 32-bit EL0"
+   default y
depends on !ARM64_64K_PAGES
select COMPAT_BINFMT_ELF
select HAVE_UID16
-- 
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/

[PATCH v2 RESEND 18/23] pm8001: Use pci_enable_msix_exact() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: xjtu...@gmail.com
Cc: lindar_...@usish.com
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/pm8001/pm8001_init.c |   39 +++--
 1 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/scsi/pm8001/pm8001_init.c 
b/drivers/scsi/pm8001/pm8001_init.c
index df421f5..1d3c02d 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -725,34 +725,35 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info 
*pm8001_ha)
sizeof(pm8001_ha->msix_entries[0]);
for (i = 0; i < max_entry ; i++)
pm8001_ha->msix_entries[i].entry = i;
-   rc = pci_enable_msix(pm8001_ha->pdev, pm8001_ha->msix_entries,
+   rc = pci_enable_msix_exact(pm8001_ha->pdev, pm8001_ha->msix_entries,
number_of_intr);
pm8001_ha->number_of_intr = number_of_intr;
-   if (!rc) {
-   PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
-   "pci_enable_msix request ret:%d no of intr %d\n",
-   rc, pm8001_ha->number_of_intr));
+   if (rc)
+   return rc;
 
+   PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
+   "pci_enable_msix_exact request ret:%d no of intr %d\n",
+   rc, pm8001_ha->number_of_intr));
 
-   for (i = 0; i < number_of_intr; i++) {
-   snprintf(intr_drvname[i], sizeof(intr_drvname[0]),
-   DRV_NAME"%d", i);
-   pm8001_ha->irq_vector[i].irq_id = i;
-   pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
+   for (i = 0; i < number_of_intr; i++) {
+   snprintf(intr_drvname[i], sizeof(intr_drvname[0]),
+   DRV_NAME"%d", i);
+   pm8001_ha->irq_vector[i].irq_id = i;
+   pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
 
-   rc = request_irq(pm8001_ha->msix_entries[i].vector,
-   pm8001_interrupt_handler_msix, flag,
-   intr_drvname[i], &(pm8001_ha->irq_vector[i]));
-   if (rc) {
-   for (j = 0; j < i; j++)
-   free_irq(
-   pm8001_ha->msix_entries[j].vector,
+   rc = request_irq(pm8001_ha->msix_entries[i].vector,
+   pm8001_interrupt_handler_msix, flag,
+   intr_drvname[i], &(pm8001_ha->irq_vector[i]));
+   if (rc) {
+   for (j = 0; j < i; j++) {
+   free_irq(pm8001_ha->msix_entries[j].vector,
&(pm8001_ha->irq_vector[i]));
-   pci_disable_msix(pm8001_ha->pdev);
-   break;
}
+   pci_disable_msix(pm8001_ha->pdev);
+   break;
}
}
+
return rc;
 }
 #endif
-- 
1.7.7.6

--
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/4] regulator: s5m8767: Use same binding for external control as in s2mps11

[Krzysztof Kozlowski]

Change the binding for regulators external control to the same used in
s2mps11 driver to be consistent.

Signed-off-by: Krzysztof Kozlowski 
Cc: Tomasz Figa 
Cc: devicet...@vger.kernel.org
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
---
 Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt | 4 ++--
 drivers/regulator/s5m8767.c   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt 
b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
index d290988ed975..558c80345ef0 100644
--- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
@@ -76,7 +76,7 @@ except these properties:
1 - on in normal mode
2 - low power mode
3 - suspend mode
-   - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one
+   - samsung,ext-control-gpios: (optional) GPIO specifier for one
GPIO controlling this regulator (enable/disable); This is
valid only for buck9.
 
@@ -157,7 +157,7 @@ Example:
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
op_mode = <3>; /* Standby Mode */
-   s5m8767,pmic-ext-control-gpios = <&gpk0 2 0>;
+   samsung,ext-control-gpios = <&gpk0 2 0>;
};
};
};
diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 92f19a005dc3..dbfd98b04a77 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -534,7 +534,7 @@ static void s5m8767_pmic_dt_parse_ext_control_gpio(struct 
sec_pmic_dev *iodev,
struct device_node *reg_np)
 {
rdata->ext_control_gpio = of_get_named_gpio(reg_np,
-   "s5m8767,pmic-ext-control-gpios", 0);
+   "samsung,ext-control-gpios", 0);
if (!gpio_is_valid(rdata->ext_control_gpio))
rdata->ext_control_gpio = 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/4] regulator: s2mps11: Add external GPIO control for S2MPS14

[Krzysztof Kozlowski]

Add support for external control over GPIO for LDO10, LDO11 and LDO12
S2MPS14 regulators. External control can be turned on by writing 0x0 to
control register which in case of other regulators is used for disabling
them. These LDO10-LDO12 regulators can be disabled only by I2C GPIO or
PWREN pin so the patch actually allows proper way of disabling them.

Additionally the GPIO control has two benefits:
 - It is faster than toggling it over I2C bus.
 - It allows disabling the regulator during suspend to RAM; The AP will
   enable it during resume.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/s2mps11.c | 67 +++--
 include/linux/mfd/samsung/s2mps14.h |  2 ++
 2 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 3aba0331fb5d..6dad0aa74a47 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -44,6 +45,8 @@ struct s2mps11_info {
 * was enabled.
 */
unsigned int s2mps14_suspend_state:30;
+   /* Array of size rdev_num with GPIO-s for external sleep control */
+   int *ext_control_gpio;
 };
 
 static int get_ramp_delay(int ramp_delay)
@@ -409,6 +412,8 @@ static int s2mps14_regulator_enable(struct regulator_dev 
*rdev)
 
if (s2mps11->s2mps14_suspend_state & (1 << rdev_get_id(rdev)))
val = S2MPS14_ENABLE_SUSPEND;
+   else if (s2mps11->ext_control_gpio[rdev_get_id(rdev)])
+   val = S2MPS14_ENABLE_EXT_CONTROL;
else
val = rdev->desc->enable_mask;
 
@@ -565,9 +570,41 @@ static const struct regulator_desc s2mps14_regulators[] = {
regulator_desc_s2mps14_buck1235(5),
 };
 
-static int s2mps11_pmic_dt_parse(struct platform_device *pdev,
+static int s2mps14_pmic_enable_ext_control(struct s2mps11_info *s2mps11,
+   struct regulator_dev *rdev)
+{
+   return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
+   rdev->desc->enable_mask, S2MPS14_ENABLE_EXT_CONTROL);
+}
+
+static void s2mps14_pmic_dt_parse_ext_control_gpio(struct platform_device 
*pdev,
struct of_regulator_match *rdata, struct s2mps11_info *s2mps11)
 {
+   int *gpio = s2mps11->ext_control_gpio;
+   unsigned int i;
+   unsigned int valid_regulators[3] = { S2MPS14_LDO10, S2MPS14_LDO11,
+   S2MPS14_LDO12 };
+
+   for (i = 0; i < ARRAY_SIZE(valid_regulators); i++) {
+   unsigned int reg = valid_regulators[i];
+
+   if (!rdata[reg].init_data || !rdata[reg].of_node)
+   continue;
+
+   gpio[reg] = of_get_named_gpio(rdata[reg].of_node,
+   "samsung,ext-control-gpios", 0);
+   if (!gpio_is_valid(gpio[reg]))
+   gpio[reg] = 0;
+   else
+   dev_dbg(&pdev->dev, "Using GPIO %d for ext-control over 
%d/%s\n",
+   gpio[reg], reg, rdata[reg].name);
+   }
+}
+
+static int s2mps11_pmic_dt_parse(struct platform_device *pdev,
+   struct of_regulator_match *rdata, struct s2mps11_info *s2mps11,
+   enum sec_device_type dev_type)
+{
struct device_node *reg_np;
 
reg_np = of_get_child_by_name(pdev->dev.parent->of_node, "regulators");
@@ -577,6 +614,9 @@ static int s2mps11_pmic_dt_parse(struct platform_device 
*pdev,
}
 
of_regulator_match(&pdev->dev, reg_np, rdata, s2mps11->rdev_num);
+   if (dev_type == S2MPS14X)
+   s2mps14_pmic_dt_parse_ext_control_gpio(pdev, rdata, s2mps11);
+
of_node_put(reg_np);
 
return 0;
@@ -613,6 +653,12 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
return -EINVAL;
};
 
+   s2mps11->ext_control_gpio = devm_kzalloc(&pdev->dev,
+   sizeof(*s2mps11->ext_control_gpio) * s2mps11->rdev_num,
+   GFP_KERNEL);
+   if (!s2mps11->ext_control_gpio)
+   return -ENOMEM;
+
if (!iodev->dev->of_node) {
if (iodev->pdata) {
pdata = iodev->pdata;
@@ -631,7 +677,7 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
for (i = 0; i < s2mps11->rdev_num; i++)
rdata[i].name = regulators[i].name;
 
-   ret = s2mps11_pmic_dt_parse(pdev, rdata, s2mps11);
+   ret = s2mps11_pmic_dt_parse(pdev, rdata, s2mps11, dev_type);
if (ret)
goto out;
 
@@ -652,6 +698,12 @@ common_reg:
config.of_node = rdata[i].of_node;
}
 
+   if (s2mps11->ext_control_gpio[i]) {
+   config.ena_gpio = s2mps11->ext_control_gpio[i];
+   config.ena_gpio_flags = GPIOF_OUT_INIT_HIGH;
+   } else
+

Re: [PATCH] pwm_lpss: Add support for PCI devices

[Mika Westerberg]

On Sat, Apr 12, 2014 at 09:58:51PM +0800, Chew Chiau Ee wrote:
> From: Alan Cox 
> 
> Not all systems enumerate the PWM devices via ACPI. They can also be exposed
> via the PCI interface.
> 
> Signed-off-by: Alan Cox 
> Signed-off-by: Chew, Chiau Ee 
> ---
>  drivers/pwm/pwm-lpss.c |  160 ++-
>  1 files changed, 129 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index 449e372..6f79bf8 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -6,6 +6,7 @@
>   * Author: Chew Kean Ho 
>   * Author: Chang Rebecca Swee Fun 
>   * Author: Chew Chiau Ee 
> + * Author: Alan Cox 
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 as
> @@ -19,6 +20,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +static int pci_drv, plat_drv;/* So we know which drivers registered 
> */
>  
>  #define PWM  0x
>  #define PWM_ENABLE   BIT(31)
> @@ -34,6 +38,15 @@ struct pwm_lpss_chip {
>   struct pwm_chip chip;
>   void __iomem *regs;
>   struct clk *clk;
> + unsigned long clk_rate;
> +};
> +
> +struct pwm_lpss_boardinfo {
> + unsigned long clk_rate;
> +};
> +
> +static const struct pwm_lpss_boardinfo byt_info = {
> + 2500
>  };
>  
>  static inline struct pwm_lpss_chip *to_lpwm(struct pwm_chip *chip)
> @@ -55,7 +68,7 @@ static int pwm_lpss_config(struct pwm_chip *chip, struct 
> pwm_device *pwm,
>   /* The equation is: base_unit = ((freq / c) * 65536) + correction */
>   base_unit = freq * 65536;
>  
> - c = clk_get_rate(lpwm->clk);
> + c = lpwm->clk_rate;
>   if (!c)
>   return -EINVAL;
>  
> @@ -113,52 +126,47 @@ static const struct pwm_ops pwm_lpss_ops = {
>   .owner = THIS_MODULE,
>  };
>  
> -static const struct acpi_device_id pwm_lpss_acpi_match[] = {
> - { "80860F09", 0 },
> - { },
> -};
> -MODULE_DEVICE_TABLE(acpi, pwm_lpss_acpi_match);
> -
> -static int pwm_lpss_probe(struct platform_device *pdev)
> +static struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev,
> + struct resource *r, struct pwm_lpss_boardinfo *info)
>  {
>   struct pwm_lpss_chip *lpwm;
> - struct resource *r;
>   int ret;
>  
> - lpwm = devm_kzalloc(&pdev->dev, sizeof(*lpwm), GFP_KERNEL);
> + lpwm = devm_kzalloc(dev, sizeof(*lpwm), GFP_KERNEL);
>   if (!lpwm)
> - return -ENOMEM;
> -
> - r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + return ERR_PTR(-ENOMEM);
>  
> - lpwm->regs = devm_ioremap_resource(&pdev->dev, r);
> + lpwm->regs = devm_ioremap_resource(dev, r);
>   if (IS_ERR(lpwm->regs))
> - return PTR_ERR(lpwm->regs);
> -
> - lpwm->clk = devm_clk_get(&pdev->dev, NULL);
> - if (IS_ERR(lpwm->clk)) {
> - dev_err(&pdev->dev, "failed to get PWM clock\n");
> - return PTR_ERR(lpwm->clk);
> + return lpwm->regs;
> +
> + if (info) {
> + lpwm->clk_rate = info->clk_rate;
> + } else {
> + lpwm->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(lpwm->clk)) {
> + dev_err(dev, "failed to get PWM clock\n");
> + return (void *)lpwm->clk;

Why the cast here?

> + }
> + lpwm->clk_rate = clk_get_rate(lpwm->clk);
>   }
>  
> - lpwm->chip.dev = &pdev->dev;
> + lpwm->chip.dev = dev;
>   lpwm->chip.ops = &pwm_lpss_ops;
>   lpwm->chip.base = -1;
>   lpwm->chip.npwm = 1;
>  
>   ret = pwmchip_add(&lpwm->chip);
>   if (ret) {
> - dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);
> - return ret;
> + dev_err(dev, "failed to add PWM chip: %d\n", ret);
> + return ERR_PTR(ret);
>   }
>  
> - platform_set_drvdata(pdev, lpwm);
> - return 0;
> + return lpwm;
>  }
>  
> -static int pwm_lpss_remove(struct platform_device *pdev)
> +static int pwm_lpss_remove(struct pwm_lpss_chip *lpwm)
>  {
> - struct pwm_lpss_chip *lpwm = platform_get_drvdata(pdev);
>   u32 ctrl;
>  
>   ctrl = readl(lpwm->regs + PWM);
> @@ -167,17 +175,107 @@ static int pwm_lpss_remove(struct platform_device 
> *pdev)
>   return pwmchip_remove(&lpwm->chip);
>  }
>  
> -static struct platform_driver pwm_lpss_driver = {
> +static int pwm_lpss_probe_pci(struct pci_dev *pdev,
> +   const struct pci_device_id *id)
> +{
> + struct pwm_lpss_boardinfo *info;
> + struct pwm_lpss_chip *lpwm;
> + int err;
> +
> + err = pci_enable_device(pdev);
> + if (err < 0)
> + return err;
> +
> + info =  (struct pwm_lpss_boardinfo *)id->driver_data;
> + lpwm = pwm_lpss_probe(&pdev->dev, &pdev->resource[0], info);
> + if (IS_ERR(lpwm))
> + return PTR_ERR(l

[PATCH 0/4] regulator: s2mps11: Add external GPIO control for S2MPS14

[Krzysztof Kozlowski]

Hi,

This patchset adds external GPIO control to s2mps11 regulator driver
for some of the S2MPS14 regulators.

Additionally (patch 4/4) it changes the bindings in s5m8767 regulator driver
for external control to match these used here:
"samsung,ext-control-gpios"

Best regards,
Krzysztof

Krzysztof Kozlowski (4):
  regulator: s2mps11: Move DTS parsing code to separate function
  regulator: s2mps11: Add external GPIO control for S2MPS14
  Documentation: regulator: s2mps11: Document external GPIO control
  regulator: s5m8767: Use same binding for external control as in
s2mps11

 Documentation/devicetree/bindings/mfd/s2mps11.txt  | 14 
 .../bindings/regulator/s5m8767-regulator.txt   |  4 +-
 drivers/regulator/s2mps11.c| 98 +++---
 drivers/regulator/s5m8767.c|  2 +-
 include/linux/mfd/samsung/s2mps14.h|  2 +
 5 files changed, 105 insertions(+), 15 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/

Re: Kernel scanning/freeing to relieve cgroup memory pressure

[Glyn Normington]

Johannes/Michal

What are your thoughts on this matter? Do you see this as a valid 
requirement?


Regards,
Glyn

On 02/04/2014 19:00, Tejun Heo wrote:

(cc'ing memcg maintainers and cgroup ML)

On Wed, Apr 02, 2014 at 02:08:04PM +0100, Glyn Normington wrote:

Currently, a memory cgroup can hit its oom limit when pages could, in
principle, be reclaimed by the kernel except that the kernel does not
respond directly to cgroup-local memory pressure.

So, ummm, it does.


A use case where this is important is running a moderately large Java
application in a memory cgroup in a PaaS environment where cost to the
user depends on the memory limit ([1]). Users need to tune the memory
limit to reduce their costs. During application initialisation large
numbers of JAR files are opened (read-only) and read while loading the
application code and its dependencies. This is reflected in a peak of
file cache usage which can push the memory cgroup memory usage
significantly higher than the value actually needed to run the application.

Possible approaches include (1) automatic response to cgroup-local
memory pressure in the kernel, and (2) a kernel API for reclaiming
memory from a cgroup which could be driven under oom notification (with
the oom killer disabled for the cgroup - it would be enabled if the
cgroup was still oom after calling the kernel to reclaim memory).

Clearly (1) is the preferred approach. The closest facility in the
kernel to (2) is to ask the kernel to free pagecache using `echo 1 >
/proc/sys/vms/drop_caches`, but that is too wide-ranging, especially in
a PaaS environment hosting multiple applications. A similar facility
could be provided for a cgroup via a cgroup pseudo-file
`memory.drop_caches`.

Other approaches include a mempressure cgroup ([2]) which would not be
suitable for PaaS applications. See [3] for Andrew Morton's response. A
related workaround ([4]) was included in the 3.6 kernel.

Related discussions:
[1] 
https://groups.google.com/a/cloudfoundry.org/d/topic/vcap-dev/6M8BDV_tq7w/discussion
[2]https://lwn.net/Articles/531077/ 
[3]https://lwn.net/Articles/531138/ 
[4]https://lkml.org/lkml/2013/6/6/462 &
https://github.com/torvalds/linux/commit/e62e384e
.


--
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 RESEND 23/23] vmw_pvscsi: Use pci_enable_msix_exact() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Arvind Kumar 
Cc: pv-driv...@vmware.com
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Arvind Kumar 
---
 drivers/scsi/vmw_pvscsi.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c
index c88e146..598f65e 100644
--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -1194,7 +1194,7 @@ static int pvscsi_setup_msix(const struct pvscsi_adapter 
*adapter,
struct msix_entry entry = { 0, PVSCSI_VECTOR_COMPLETION };
int ret;
 
-   ret = pci_enable_msix(adapter->dev, &entry, 1);
+   ret = pci_enable_msix_exact(adapter->dev, &entry, 1);
if (ret)
return ret;
 
-- 
1.7.7.6

--
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/4] Documentation: regulator: s2mps11: Document external GPIO control

[Krzysztof Kozlowski]

Add documentation for new property for controlling (enable/disable) some
of the S2MPS14 regulators by GPIO.

Signed-off-by: Krzysztof Kozlowski 
Cc: Tomasz Figa 
Cc: devicet...@vger.kernel.org
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
---
 Documentation/devicetree/bindings/mfd/s2mps11.txt | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 802e839b0829..d81ba30c0d8b 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -56,6 +56,20 @@ for a particular group of BUCKs. So provide same 
regulator-ramp-delay.
 Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6],
 BUCK[3, 4], and BUCK[7, 8, 10]
 
+On S2MPS14 the LDO10, LDO11 and LDO12 can be configured to external control
+over GPIO. To turn this feature on this property must be added to the regulator
+sub-node:
+   - samsung,ext-control-gpios: GPIO specifier for one GPIO
+   controlling this regulator (enable/disable);
+Example:
+   LDO12 {
+   regulator-name = "V_EMMC_2.8V";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   samsung,ext-control-gpios = <&gpk0 2 0>;
+   };
+
+
 The regulator constraints inside the regulator nodes use the standard regulator
 bindings which are documented elsewhere.
 
-- 
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] phy: exynos5-usbdrd: Add facility to toggle vbus gpio on/off

[Vivek Gautam]

Hi Felipe,


On Sat, Apr 12, 2014 at 9:07 AM, Felipe Balbi  wrote:
> On Wed, Apr 09, 2014 at 05:24:45PM +0530, Vivek Gautam wrote:
>> Adding support to enable/disable VBUS hooked to a gpio
>> to enable vbus supply on the port.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>
>> Based on 'phy-exynos5-usbdrd' patches:
>> [PATCH V4 0/5] Add Exynos5 USB 3.0 phy driver based on generic PHY framework
>> http://www.spinics.net/lists/linux-usb/msg105507.html
>>
>>  drivers/phy/phy-exynos5-usbdrd.c |   18 ++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/drivers/phy/phy-exynos5-usbdrd.c 
>> b/drivers/phy/phy-exynos5-usbdrd.c
>> index ff54a7c..5ca7485 100644
>> --- a/drivers/phy/phy-exynos5-usbdrd.c
>> +++ b/drivers/phy/phy-exynos5-usbdrd.c
>> @@ -18,6 +18,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -176,6 +177,7 @@ struct exynos5_usbdrd_phy {
>>   struct clk *ref_clk;
>>   unsigned long ref_rate;
>>   unsigned int refclk_reg;
>> + int gpio;
>>  };
>>
>>  #define to_usbdrd_phy(inst) \
>> @@ -460,6 +462,9 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
>>   if (!IS_ERR(phy_drd->usb30_sclk))
>>   clk_prepare_enable(phy_drd->usb30_sclk);
>>
>> + /* Toggle VBUS gpio - on */
>> + gpio_set_value(phy_drd->gpio, 1);
>
> It seems like you'd be better off using a regulator_enable() call for
> this.

Sure, i will use a regulator for this vbus settings.


-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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 RESEND 19/23] pmcraid: Get rid of a redundant assignment

[Alexander Gordeev]

Signed-off-by: Alexander Gordeev 
Cc: Anil Ravindranath 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/pmcraid.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index be8ce54..c06af7f 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4746,7 +4746,6 @@ pmcraid_isr_legacy:
pinstance->hrrq_vector[0].drv_inst = pinstance;
pinstance->hrrq_vector[0].vector = pdev->irq;
pinstance->num_hrrq = 1;
-   rc = 0;
 
rc = request_irq(pdev->irq, pmcraid_isr, IRQF_SHARED,
 PMCRAID_DRIVER_NAME, &pinstance->hrrq_vector[0]);
-- 
1.7.7.6

--
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/4] regulator: s2mps11: Move DTS parsing code to separate function

[Krzysztof Kozlowski]

Refactor code for parsing DTS to increase a little code readability. The
behaviour should not change.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/regulator/s2mps11.c | 35 +++
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index e713c162fbd4..3aba0331fb5d 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -565,12 +565,28 @@ static const struct regulator_desc s2mps14_regulators[] = 
{
regulator_desc_s2mps14_buck1235(5),
 };
 
+static int s2mps11_pmic_dt_parse(struct platform_device *pdev,
+   struct of_regulator_match *rdata, struct s2mps11_info *s2mps11)
+{
+   struct device_node *reg_np;
+
+   reg_np = of_get_child_by_name(pdev->dev.parent->of_node, "regulators");
+   if (!reg_np) {
+   dev_err(&pdev->dev, "could not find regulators sub-node\n");
+   return -EINVAL;
+   }
+
+   of_regulator_match(&pdev->dev, reg_np, rdata, s2mps11->rdev_num);
+   of_node_put(reg_np);
+
+   return 0;
+}
+
 static int s2mps11_pmic_probe(struct platform_device *pdev)
 {
struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
-   struct sec_platform_data *pdata = iodev->pdata;
+   struct sec_platform_data *pdata = NULL;
struct of_regulator_match *rdata = NULL;
-   struct device_node *reg_np = NULL;
struct regulator_config config = { };
struct s2mps11_info *s2mps11;
int i, ret = 0;
@@ -598,7 +614,8 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
};
 
if (!iodev->dev->of_node) {
-   if (pdata) {
+   if (iodev->pdata) {
+   pdata = iodev->pdata;
goto common_reg;
} else {
dev_err(pdev->dev.parent,
@@ -614,15 +631,9 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
for (i = 0; i < s2mps11->rdev_num; i++)
rdata[i].name = regulators[i].name;
 
-   reg_np = of_get_child_by_name(iodev->dev->of_node, "regulators");
-   if (!reg_np) {
-   dev_err(&pdev->dev, "could not find regulators sub-node\n");
-   ret = -EINVAL;
+   ret = s2mps11_pmic_dt_parse(pdev, rdata, s2mps11);
+   if (ret)
goto out;
-   }
-
-   of_regulator_match(&pdev->dev, reg_np, rdata, s2mps11->rdev_num);
-   of_node_put(reg_np);
 
 common_reg:
platform_set_drvdata(pdev, s2mps11);
@@ -633,7 +644,7 @@ common_reg:
for (i = 0; i < s2mps11->rdev_num; i++) {
struct regulator_dev *regulator;
 
-   if (!reg_np) {
+   if (pdata) {
config.init_data = pdata->regulators[i].initdata;
config.of_node = pdata->regulators[i].reg_node;
} else {
-- 
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 v2 RESEND 21/23] qla2xxx: Use pci_enable_msix_range() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Log message code 0x00c6 preserved, although it is reported
after successful call to pci_enable_msix_range(), not before
possibly unsuccessful call to pci_enable_msix(). Consumers
of the error code should not notice the difference.

Signed-off-by: Alexander Gordeev 
Cc: qla2xxx-upstr...@qlogic.com
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/qla2xxx/qla_isr.c |   27 +++
 1 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 95314ef..41eb0dc 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2918,27 +2918,22 @@ qla24xx_enable_msix(struct qla_hw_data *ha, struct 
rsp_que *rsp)
for (i = 0; i < ha->msix_count; i++)
entries[i].entry = i;
 
-   ret = pci_enable_msix(ha->pdev, entries, ha->msix_count);
-   if (ret) {
-   if (ret < MIN_MSIX_COUNT)
-   goto msix_failed;
-
+   ret = pci_enable_msix_range(ha->pdev,
+   entries, MIN_MSIX_COUNT, ha->msix_count);
+   if (ret < 0) {
+   ql_log(ql_log_fatal, vha, 0x00c7,
+   "MSI-X: Failed to enable support, "
+   "giving   up -- %d/%d.\n",
+   ha->msix_count, ret);
+   goto msix_out;
+   } else if (ret < ha->msix_count) {
ql_log(ql_log_warn, vha, 0x00c6,
"MSI-X: Failed to enable support "
"-- %d/%d\n Retry with %d vectors.\n",
ha->msix_count, ret, ret);
-   ha->msix_count = ret;
-   ret = pci_enable_msix(ha->pdev, entries, ha->msix_count);
-   if (ret) {
-msix_failed:
-   ql_log(ql_log_fatal, vha, 0x00c7,
-   "MSI-X: Failed to enable support, "
-   "giving   up -- %d/%d.\n",
-   ha->msix_count, ret);
-   goto msix_out;
-   }
-   ha->max_rsp_queues = ha->msix_count - 1;
}
+   ha->msix_count = ret;
+   ha->max_rsp_queues = ha->msix_count - 1;
ha->msix_entries = kzalloc(sizeof(struct qla_msix_entry) *
ha->msix_count, GFP_KERNEL);
if (!ha->msix_entries) {
-- 
1.7.7.6

--
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 RESEND 16/23] mpt3sas: Use pci_enable_msix_exact() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Nagalakshmi Nandigama 
Cc: Sreekanth Reddy 
Cc: supp...@lsi.com
Cc: dl-mptfusionli...@lsi.com
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/mpt3sas/mpt3sas_base.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 0cf4f70..7b65ec2 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1747,10 +1747,10 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
for (i = 0, a = entries; i < ioc->reply_queue_count; i++, a++)
a->entry = i;
 
-   r = pci_enable_msix(ioc->pdev, entries, ioc->reply_queue_count);
+   r = pci_enable_msix_exact(ioc->pdev, entries, ioc->reply_queue_count);
if (r) {
dfailprintk(ioc, pr_info(MPT3SAS_FMT
-   "pci_enable_msix failed (r=%d) !!!\n",
+   "pci_enable_msix_exact failed (r=%d) !!!\n",
ioc->name, r));
kfree(entries);
goto try_ioapic;
-- 
1.7.7.6

--
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 RESEND 20/23] pmcraid: Use pci_enable_msix_range() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Anil Ravindranath 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/pmcraid.c |   13 ++---
 1 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index c06af7f..6d0f208 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4698,19 +4698,10 @@ pmcraid_register_interrupt_handler(struct 
pmcraid_instance *pinstance)
for (i = 0; i < PMCRAID_NUM_MSIX_VECTORS; i++)
entries[i].entry = i;
 
-   rc = pci_enable_msix(pdev, entries, num_hrrq);
-   if (rc < 0)
+   num_hrrq = pci_enable_msix_range(pdev, entries, 1, num_hrrq);
+   if (num_hrrq < 0)
goto pmcraid_isr_legacy;
 
-   /* Check how many MSIX vectors are allocated and register
-* msi-x handlers for each of them giving appropriate buffer
-*/
-   if (rc > 0) {
-   num_hrrq = rc;
-   if (pci_enable_msix(pdev, entries, num_hrrq))
-   goto pmcraid_isr_legacy;
-   }
-
for (i = 0; i < num_hrrq; i++) {
pinstance->hrrq_vector[i].hrrq_id = i;
pinstance->hrrq_vector[i].drv_inst = pinstance;
-- 
1.7.7.6

--
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/1] X86: Probe for PIC and set legacy_pic appropriately

[Jan Beulich]

>>> On 12.04.14 at 07:56,  wrote:
> --- a/arch/x86/kernel/i8259.c
> +++ b/arch/x86/kernel/i8259.c
> @@ -299,11 +299,30 @@ static void unmask_8259A(void)
>  static void init_8259A(int auto_eoi)
>  {
>   unsigned long flags;
> + unsigned char probe_val = ~(1 << PIC_CASCADE_IR);
> + unsigned char new_val;
>  
>   i8259A_auto_eoi = auto_eoi;
>  
>   raw_spin_lock_irqsave(&i8259A_lock, flags);
>  
> + /*
> +  * Check to see if we have a PIC.
> +  * Mask all except the cascade and read
> +  * back the value we just wrote. If we don't
> +  * have a PIC, we will read 0xff as opposed to the
> +  * value we wrote.
> +  */
> + outb(0xff, PIC_SLAVE_IMR);  /* mask all of 8259A-2 */
> + outb(probe_val, PIC_MASTER_IMR);
> + new_val = inb(PIC_MASTER_IMR);
> + if (probe_val != new_val) {
> + printk(KERN_INFO "Using NULL legacy PIC\n");
> + legacy_pic = &null_legacy_pic;
> + raw_spin_unlock_irqrestore(&i8259A_lock, flags);
> + return;
> + }
> +
>   outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */
>   outb(0xff, PIC_SLAVE_IMR);  /* mask all of 8259A-2 */

And I guess you should delete this last line now that this is already
being done slightly earlier - having it done twice is possibly going to
confuse future readers (in that they might ask themselves or others
whether this really needs to be done twice).

Jan

--
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 RESEND 14/23] megaraid: Use pci_enable_msix_range() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Neela Syam Kolli 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/megaraid/megaraid_sas_base.c |   20 +++-
 1 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 2df717c..26f89d4 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4106,17 +4106,11 @@ static int megasas_init_fw(struct megasas_instance 
*instance)
 (unsigned int)num_online_cpus());
for (i = 0; i < instance->msix_vectors; i++)
instance->msixentry[i].entry = i;
-   i = pci_enable_msix(instance->pdev, instance->msixentry,
-   instance->msix_vectors);
-   if (i >= 0) {
-   if (i) {
-   if (!pci_enable_msix(instance->pdev,
-instance->msixentry, i))
-   instance->msix_vectors = i;
-   else
-   instance->msix_vectors = 0;
-   }
-   } else
+   i = pci_enable_msix_range(instance->pdev, instance->msixentry,
+ 1, instance->msix_vectors);
+   if (i)
+   instance->msix_vectors = i;
+   else
instance->msix_vectors = 0;
 
dev_info(&instance->pdev->dev, "[scsi%d]: FW supports"
@@ -5136,8 +5130,8 @@ megasas_resume(struct pci_dev *pdev)
 
/* Now re-enable MSI-X */
if (instance->msix_vectors &&
-   pci_enable_msix(instance->pdev, instance->msixentry,
-   instance->msix_vectors))
+   pci_enable_msix_exact(instance->pdev, instance->msixentry,
+ instance->msix_vectors))
goto fail_reenable_msix;
 
switch (instance->pdev->device) {
-- 
1.7.7.6

--
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/4] ARM: at91: prepare common clk transition for sam9n12 SoC

[Boris BREZILLON]

This patch encloses sam9n12 old clk registration in
"#if defined(CONFIG_OLD_CLK_AT91) #endif" sections.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/at91sam9n12.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/at91sam9n12.c b/arch/arm/mach-at91/at91sam9n12.c
index f2ea7b0..c8988fe 100644
--- a/arch/arm/mach-at91/at91sam9n12.c
+++ b/arch/arm/mach-at91/at91sam9n12.c
@@ -19,9 +19,10 @@
 #include "board.h"
 #include "soc.h"
 #include "generic.h"
-#include "clock.h"
 #include "sam9_smc.h"
 
+#if defined(CONFIG_OLD_CLK_AT91)
+#include "clock.h"
 /* 
  *  Clocks
  *  */
@@ -215,6 +216,9 @@ static void __init at91sam9n12_register_clocks(void)
 ARRAY_SIZE(periph_clocks_lookups));
 
 }
+#else
+#define at91sam9n12_register_clocks NULL
+#endif
 
 /* 
  *  AT91SAM9N12 processor initialization
-- 
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/4] ARM: at91/dt: define sam9n12 clocks

[Boris BREZILLON]

Define sam9n12 clocks and make use of them in peripheral definitions.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/at91sam9n12.dtsi | 350 -
 1 file changed, 348 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi 
b/arch/arm/boot/dts/at91sam9n12.dtsi
index 9f04808..4d036a3 100644
--- a/arch/arm/boot/dts/at91sam9n12.dtsi
+++ b/arch/arm/boot/dts/at91sam9n12.dtsi
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Atmel AT91SAM9N12 SoC";
@@ -49,6 +50,20 @@
reg = <0x2000 0x1000>;
};
 
+   clocks {
+   slow_xtal: slow_xtal {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
+   main_xtal: main_xtal {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+   };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
@@ -75,8 +90,280 @@
};
 
pmc: pmc@fc00 {
-   compatible = "atmel,at91rm9200-pmc";
-   reg = <0xfc00 0x100>;
+   compatible = "atmel,at91sam9n12-pmc";
+   reg = <0xfc00 0x200>;
+   interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+   interrupt-controller;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #interrupt-cells = <1>;
+
+   main_rc_osc: main_rc_osc {
+   compatible = 
"atmel,at91sam9x5-clk-main-rc-osc";
+   #clock-cells = <0>;
+   interrupts-extended = <&pmc 
AT91_PMC_MOSCRCS>;
+   clock-frequency = <1200>;
+   clock-accuracy = <5000>;
+   };
+
+   main_osc: main_osc {
+   compatible = 
"atmel,at91sam9x5-clk-main-osc";
+   #clock-cells = <0>;
+   interrupts-extended = <&pmc 
AT91_PMC_MOSCS>;
+   clocks = <&main_xtal>;
+   };
+
+   main: mainck {
+   compatible = 
"atmel,at91sam9x5-clk-main";
+   #clock-cells = <0>;
+   interrupts-extended = <&pmc 
AT91_PMC_MOSCSELS>;
+   clocks = <&main_rc_osc>, <&main_osc>;
+   };
+
+   plla: pllack {
+   compatible = "atmel,at91rm9200-clk-pll";
+   #clock-cells = <0>;
+   interrupts-extended = <&pmc 
AT91_PMC_LOCKA>;
+   clocks = <&main>;
+   reg = <0>;
+   atmel,clk-input-range = <200 
3200>;
+   #atmel,pll-clk-output-range-cells = <4>;
+   atmel,pll-clk-output-ranges = 
<74500 8 0 0>,
+ 
<69500 75000 1 0>,
+ 
<64500 7 2 0>,
+ 
<59500 65000 3 0>,
+ 
<54500 6 0 1>,
+ 
<49500 55500 1 1>,
+ 
<44500 5 1 2>,
+ 
<4 45000 1 3>;
+   };
+
+   plladiv: plladivck {
+   compatible = 
"atmel,at91sam9x5-clk-plldiv";
+   #clock-cells = <0>;
+   clocks = <&plla>;
+   };
+
+   pllb: pllbck {
+   compatible = "atmel,at91rm9200-clk-pll";
+   #clock-cells = <0>;
+   interrupts-extended = <&pmc 
AT91_PMC_LOCKB>;
+

[PATCH 3/4] ARM: at91/dt: define sam9n12ek crystal frequencies

[Boris BREZILLON]

Define sam9n12ek's main and slow crystal frequencies.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/at91sam9n12ek.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts 
b/arch/arm/boot/dts/at91sam9n12ek.dts
index 924a6a6..6132769 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -30,6 +30,14 @@
compatible = "atmel,osc", "fixed-clock";
clock-frequency = <1600>;
};
+
+   slow_xtal: slow_xtal {
+   clock-frequency = <32768>;
+   };
+
+   main_xtal: main_xtal {
+   clock-frequency = <1600>;
+   };
};
 
ahb {
-- 
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 4/4] ARM: at91: move sam9n12 SoC to the CCF

[Boris BREZILLON]

This patch removes the selection of AT91_USE_OLD_CLK when selecting
sam9n12 SoC support. This will automatically enable COMMON_CLK_AT91 option
and add support for at91 common clk implementation.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/mach-at91/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index b2d2cf4..a1ac430 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -183,7 +183,6 @@ config SOC_AT91SAM9N12
select HAVE_AT91_DBGU0
select HAVE_FB_ATMEL
select SOC_AT91SAM9
-   select AT91_USE_OLD_CLK
select HAVE_AT91_USB_CLK
help
  Select this if you are using Atmel's AT91SAM9N12 SoC.
-- 
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 0/4] ARM: at91: move sam9n12 SoC and boards to the CCF

[Boris BREZILLON]

Hello,

This series moves the at91sam9n12 SoC and the at91sam9n12-ek board to
the Common Clock Framework.

It depends on this series [1], which introduces new slow clock and main
clock implementation (and DT bindings) for at91 SoCs.

Best Regards,

Boris

[1] http://lkml.iu.edu/hypermail/linux/kernel/1403.3/00074.html

Boris BREZILLON (4):
  ARM: at91: prepare common clk transition for sam9n12 SoC
  ARM: at91/dt: define sam9n12 clocks
  ARM: at91/dt: define sam9n12ek crystal frequencies
  ARM: at91: move sam9n12 SoC to the CCF

 arch/arm/boot/dts/at91sam9n12.dtsi  | 350 +++-
 arch/arm/boot/dts/at91sam9n12ek.dts |   8 +
 arch/arm/mach-at91/Kconfig  |   1 -
 arch/arm/mach-at91/at91sam9n12.c|   6 +-
 4 files changed, 361 insertions(+), 4 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/

clovertrail (z2760) defconfig?

[David Lanzendörfer]

hi
i'm unsuccessfully trying to boot a linux kernel on an intel atom z2760 right
now but somehow the boot up process appears to be crashing the cpu right at
the beginning of the load process.
not even the uefi early_printk's appear to be reached, so it must be the 
setup.S or something like this.
since there are already a lot of patches for this platform in linux-next
i assume the problem is somewhere on my end.
could someone please send me his kernel configuration with which he got
the bzImage booting on this device, so that I can verify, that it isn't an
UEFI bug? (Also I'd like to package a kernel rpm for merproject)

regards
-- 
David Lanzendörfer
OpenSourceSupport GmbH
System engineer and supporter
http://www.o2s.ch/

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/9] crypto: qce: Add core driver implementation

[Stanimir Varbanov]

Hi Courtney,

On 04/09/2014 01:00 AM, Courtney Cavin wrote:
> On Tue, Apr 08, 2014 at 06:26:44PM +0200, Stanimir Varbanov wrote:
>> On 04/04/2014 02:38 AM, Courtney Cavin wrote:
>>> On Thu, Apr 03, 2014 at 06:17:58PM +0200, Stanimir Varbanov wrote:
 This adds core driver files. The core part is implementing a
 platform driver probe and remove callbaks, the probe enables
 clocks, checks crypto version, initialize and request dma
 channels, create done tasklet and work queue and finally
 register the algorithms into crypto subsystem.

 Signed-off-by: Stanimir Varbanov 
 ---
  drivers/crypto/qce/core.c | 333 
 ++
  drivers/crypto/qce/core.h |  69 ++
  2 files changed, 402 insertions(+)
  create mode 100644 drivers/crypto/qce/core.c
  create mode 100644 drivers/crypto/qce/core.h

 diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
>>> [...]
 +static struct qce_algo_ops qce_ops[] = {
 +  {
 +  .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
 +  .register_alg = qce_ablkcipher_register,
 +  },
 +  {
 +  .type = CRYPTO_ALG_TYPE_AHASH,
 +  .register_alg = qce_ahash_register,
 +  },
 +};
 +
 +static void qce_unregister_algs(struct qce_device *qce)
 +{
 +  struct qce_alg_template *tmpl, *n;
 +
 +  list_for_each_entry_safe(tmpl, n, &qce->alg_list, entry) {
 +  if (tmpl->crypto_alg_type == CRYPTO_ALG_TYPE_AHASH)
 +  crypto_unregister_ahash(&tmpl->alg.ahash);
 +  else
 +  crypto_unregister_alg(&tmpl->alg.crypto);
 +
 +  list_del(&tmpl->entry);
 +  kfree(tmpl);
>>>
>>> I find this whole memory/list management to be very disorganised.
>>> ops->register_alg() is supposed to allocate this item--more precisely,
>>> multiple items--using something that must be able to be kfree'd
>>> directly, register it with the crypto core, and put it on this list
>>> manually.  Here we unregister/remove/free this in the core.  Josh's
>>> recommendation of a unregister_alg callback might help, but it all
>>> remains a bit unclear with register_alg/unregister_alg managing X
>>> algorithms per call. 
>>>
>>> Additionally, above you have qce_ops, which clearly defines the
>>> operations for specific algorithms types/groups, which in later patches
>>> are shown to be seperated out into independent implementations.
>>>
>>> From what I can tell, this seems to be a framework with built-in yet
>>> independent crypto implementations which call the crypto API directly.
>>>
>>> It would be more logical to me if this was seperated out into a
>>> "library/core" API, with the individual implementations as platform
>>> drivers of their own.  Then they can register with the core, managing
>>> memory how they please.
>>>
>>> What am I missing?
>>>
>>
>> No, you have not miss nothing.
>>
>> OK I see your point. I made few changes in the core, killed the alg_list
>> and its manipulation function and added a .unregister_algs operation.
>> Now every type of algorithm will handle all core crypto api functions
>> itself. Also I'm using devm_kzalloc() in .register_algs when allocating
>> memory for qce_alg_template structures to avoid kfree(). The callbacks
>> async_req_queue/done are now embedded in qce_device structure and they
>> are invoked directly from algorithm implementations. Thus I have
>> separated the interfaces: functions implemented in core part of the
>> driver and struct qce_algo_ops having the function pointers implemented
>> by every type of algorithm.
>>
>> If you don't have some objections I can send out a version 2.
> 
> 
> Well, I'd have to see the code to understand clearly what you are
> describing here, but the mention of devm_kzalloc() concerns me.  The
> only device which I currently see to which this allocation could be
> associated is the single platform_device in the core.  Associating the
> memory with the core gets rid of the explicit call to kfree() by the
> core, but doesn't rearrange the way the memory is actually managed.

OK, no worries. I have no strong opinion and will use kzalloc() then.

> 
> If you have changed it so that each algorithm "block" has its own
> device, then this would seem more reasonable, but I don't see that in
> the explanation you provided.

No, that is not possible. The platform driver must be one because the
register space is common. The hardware accesses must be serialised from
core part of the driver.

-- 
regards,
Stan
--
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/

Pull request ?

[Alexandre Belloni]

Hi Jonathan,

I realise you didn't send any pull request for 3.15 yet, do you intend
to send it soon. As you know, I have a patch set depending on a few
patches and I'd like to rebase and resend it soon.

Regards,

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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 2/3] sched,numa: retry placement more frequently when misplaced

[Ingo Molnar]

* Rik van Riel  wrote:

> On 04/11/2014 01:46 PM, Joe Perches wrote:
> > On Fri, 2014-04-11 at 13:00 -0400, r...@redhat.com wrote:
> >> This patch reduces the interval at which migration is retried,
> >> when the task's numa_scan_period is small.
> > 
> > More style trivia and a question.

[...]

> > interval = min_t(unsigned long, HZ,
> >  msecs_to_jiffies(p->numa_scan_period) / 16);
> 
> That's what I had before, but spilling things over across multiple 
> lines like that didn't exactly help readability.

Joe, the low quality 'trivial reviews' you are doing are becoming a 
burden on people, so could you please either exclude arch/x86/ from 
your "waste other people's time" email filter; or improve the quality 
(and relevance) of your replies, so that you consider not just 
trivialities but the bigger picture as well?

Most people who enter kernel development start with trivial patches 
and within a few months of learning the kernel ropes rise up to more 
serious, more useful topics.

This process is constructive: it gives the Linux kernel a constant 
influx of useful cleanup patches, while it also gives newbies a 
smooth, easy path of entry into kernel hacking. Thus we maintainers 
are friendly and inclusive to newbie-originated cleanups.

But the problem is that you remained stuck at the cleanup level for 
about a decade, and you don't seem to be willing to improve ...

The thing is, as of today there's hundreds of thousands of 'cleanups' 
flagged by checkpatch.pl on the latest kernel tree. That body of "easy 
changes" is more than enough to keep newbies busy, but had all those 
lines of code been commented on for trivialities by cleanup-only 
people like you - forcing another 1 million often bogus commits into 
the development process - it would have bogged Linux down to a 
standstill and would have prevented _real_ review from occuring.

Every time you comment on a patch, considering only trivialities, you 
risk crowding out some real reviewer who might mistakenly believe when 
seeing a reply to the email thread that the patch in question got a 
thorough review...

So what you are doing is starting to become net destructive:

 - it is crowding out real review

 - the 'solutions' you suggest often result in worse code

 - you burden contributors and maintainers with make-work 'cleanups'
   created by a professional cleanup bureaucrat.

Stop doing these low-substance reviews! Do some real reviews (which 
can very much include trivial comments as well), or try to improve 
your review abilities by writing real kernel code.

Thanks,

Ingo
--
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 RESEND 15/23] mpt2sas: Use pci_enable_msix_exact() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Nagalakshmi Nandigama 
Cc: Sreekanth Reddy 
Cc: supp...@lsi.com
Cc: dl-mptfusionli...@lsi.com
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/mpt2sas/mpt2sas_base.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c 
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index bde63f7..984b605 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1432,10 +1432,10 @@ _base_enable_msix(struct MPT2SAS_ADAPTER *ioc)
for (i = 0, a = entries; i < ioc->reply_queue_count; i++, a++)
a->entry = i;
 
-   r = pci_enable_msix(ioc->pdev, entries, ioc->reply_queue_count);
+   r = pci_enable_msix_exact(ioc->pdev, entries, ioc->reply_queue_count);
if (r) {
-   dfailprintk(ioc, printk(MPT2SAS_INFO_FMT "pci_enable_msix "
-   "failed (r=%d) !!!\n", ioc->name, r));
+   dfailprintk(ioc, printk(MPT2SAS_INFO_FMT
+   "pci_enable_msix_exact failed (r=%d) !!!\n", ioc->name, r));
kfree(entries);
goto try_ioapic;
}
-- 
1.7.7.6

--
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 v4 2/2] reset: Add GPIO support to reset controller framework

[Philipp Zabel]

This adds support for GPIO controlled reset pins on peripheral ICs to the reset
controller framework. Currently there is no support for specifying a delay
between assertion and de-assertion of the reset signal, so this has to be
handled by the drivers.

Signed-off-by: Philipp Zabel 
---
Changes since v3:
 - Rebased onto v3.15-rc1
 - Turned gpiod_get error into debug message, we don't want this to trigger
   for optional resets if no GPIO is given.
---
 drivers/reset/Kconfig  |  17 ++
 drivers/reset/Makefile |   9 ++-
 drivers/reset/core.c   |  29 +-
 drivers/reset/gpio-reset.c | 137 +
 drivers/reset/reset-core.h |  48 
 5 files changed, 225 insertions(+), 15 deletions(-)
 create mode 100644 drivers/reset/gpio-reset.c
 create mode 100644 drivers/reset/reset-core.h

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..26a1d24 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -10,6 +10,23 @@ menuconfig RESET_CONTROLLER
  This framework is designed to abstract reset handling of devices
  via GPIOs or SoC-internal reset controller modules.
 
+ If the device tree contains any resets or reset-gpio properties,
+ this probably should be enabled.
+
  If unsure, say no.
 
+if RESET_CONTROLLER
+
+menuconfig RESET_GPIO
+   bool "GPIO Reset Support"
+   depends on GPIOLIB
+   default y if GPIOLIB
+   help
+ GPIO Reset Controller support.
+
+ This option lets the reset controller framework handle reset lines
+ connected to GPIOs.
+
+endif
+
 source "drivers/reset/sti/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 4f60caf..44c96b3 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,3 +1,10 @@
-obj-$(CONFIG_RESET_CONTROLLER) += core.o
+reset-core-objs := core.o
+
+obj-$(CONFIG_RESET_CONTROLLER) += reset-core.o
+
+ifeq ($(CONFIG_RESET_GPIO),y)
+  reset-core-objs += gpio-reset.o
+endif
+
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index baeaf82..6bfd2d2 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -18,23 +18,12 @@
 #include 
 #include 
 
+#include "reset-core.h"
+
 static DEFINE_MUTEX(reset_controller_list_mutex);
 static LIST_HEAD(reset_controller_list);
 
 /**
- * struct reset_control - a reset control
- * @rcdev: a pointer to the reset controller device
- * this reset control belongs to
- * @id: ID of the reset controller in the reset
- *  controller device
- */
-struct reset_control {
-   struct reset_controller_dev *rcdev;
-   struct device *dev;
-   unsigned int id;
-};
-
-/**
  * of_reset_simple_xlate - translate reset_spec to the reset line number
  * @rcdev: a pointer to the reset controller device
  * @reset_spec: reset line specifier as found in the device tree
@@ -149,6 +138,8 @@ struct reset_control *of_reset_control_get(struct 
device_node *node,
 "reset-names", id);
ret = of_parse_phandle_with_args(node, "resets", "#reset-cells",
 index, &args);
+   if (index == -EINVAL)
+   return ERR_PTR(-ENOENT);
if (ret)
return ERR_PTR(ret);
 
@@ -209,6 +200,13 @@ struct reset_control *reset_control_get(struct device 
*dev, const char *id)
if (!IS_ERR(rstc))
rstc->dev = dev;
 
+   /*
+* If there is no dedicated reset controller device, check if we have
+* a reset line controlled by a GPIO instead.
+*/
+   if (PTR_ERR(rstc) == -ENOENT)
+   return gpio_reset_control_get(dev, id);
+
return rstc;
 }
 EXPORT_SYMBOL_GPL(reset_control_get);
@@ -223,7 +221,10 @@ void reset_control_put(struct reset_control *rstc)
if (IS_ERR(rstc))
return;
 
-   module_put(rstc->rcdev->owner);
+   if (reset_control_is_gpio(rstc))
+   gpio_reset_control_put(rstc);
+   else
+   module_put(rstc->rcdev->owner);
kfree(rstc);
 }
 EXPORT_SYMBOL_GPL(reset_control_put);
diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
new file mode 100644
index 000..4b12136
--- /dev/null
+++ b/drivers/reset/gpio-reset.c
@@ -0,0 +1,137 @@
+/*
+ * GPIO Reset Controller
+ *
+ * Copyright 2013 Philipp Zabel, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "reset-core.h"
+
+/*
+ * Global GPIO reset controller
+ */
+static struct reset_controller_dev *gpio_rcdev;
+
+static int gpio_reset_set(struct

[PATCH v2 RESEND 13/23] megaraid: Fail resume if MSI-X re-initialization failed

[Alexander Gordeev]

Currently the driver fails to analize MSI-X re-enablement
status on resuming and always assumes the success. This
update checks the MSI-X initialization result and fails
to resume if MSI-Xs re-enablement failed.

Signed-off-by: Alexander Gordeev 
---
 drivers/scsi/megaraid/megaraid_sas_base.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index d84d02c..2df717c 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5135,9 +5135,10 @@ megasas_resume(struct pci_dev *pdev)
goto fail_ready_state;
 
/* Now re-enable MSI-X */
-   if (instance->msix_vectors)
-   pci_enable_msix(instance->pdev, instance->msixentry,
-   instance->msix_vectors);
+   if (instance->msix_vectors &&
+   pci_enable_msix(instance->pdev, instance->msixentry,
+   instance->msix_vectors))
+   goto fail_reenable_msix;
 
switch (instance->pdev->device) {
case PCI_DEVICE_ID_LSI_FUSION:
@@ -5246,6 +5247,7 @@ fail_init_mfi:
 
 fail_set_dma_mask:
 fail_ready_state:
+fail_reenable_msix:
 
pci_disable_device(pdev);
 
-- 
1.7.7.6

--
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 v4 1/2] Documentation: Add GPIO reset binding to reset binding documentation

[Philipp Zabel]

This patch adds documentation clarifying the reset GPIO bindings most
commonly in use (reset-gpios and -reset-gpios properties).

Signed-off-by: Philipp Zabel 
---
 Documentation/devicetree/bindings/reset/reset.txt | 26 +--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/reset/reset.txt 
b/Documentation/devicetree/bindings/reset/reset.txt
index 31db6ff..51f9e35 100644
--- a/Documentation/devicetree/bindings/reset/reset.txt
+++ b/Documentation/devicetree/bindings/reset/reset.txt
@@ -2,8 +2,8 @@
 
 This binding is intended to represent the hardware reset signals present
 internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
-standalone chips are most likely better represented as GPIOs, although there
-are likely to be exceptions to this rule.
+standalone chips are most likely better represented as GPIOs, ideally using a
+common scheme as described below.
 
 Hardware blocks typically receive a reset signal. This signal is generated by
 a reset provider (e.g. power management or clock module) and received by a
@@ -56,6 +56,20 @@ reset-names: List of reset signal name strings sorted in the 
same order as
the resets property. Consumers drivers will use reset-names to
match reset signal names with reset specifiers.
 
+= GPIO Reset consumers =
+
+For the common case of reset lines controlled by GPIOs, the GPIO binding
+documented in devicetree/bindings/gpio/gpio.txt should be used:
+
+Required properties:
+reset-gpios or Reset GPIO using standard GPIO bindings,
+-reset-gpios:optionally named to specify the reset line
+
+Optional properties:
+reset-boot-asserted or Boolean. If set, the corresponding reset is
+-reset-boot-asserted:initially asserted and should be kept that way
+   until released by the driver.
+
 For example:
 
device {
@@ -65,6 +79,14 @@ For example:
 
 This represents a device with a single reset signal named "reset".
 
+   device2 {
+   reset-gpios = <&gpio3 15 GPIO_ACTIVE_LOW>;
+   reset-boot-asserted;
+   };
+
+This represents a device with a single reset signal, controlled
+by an active-low GPIO, which is initally kept in reset.
+
bus {
resets = <&rst 10> <&rst 11> <&rst 12> <&rst 11>;
reset-names = "i2s1", "i2s2", "dma", "mixer";
-- 
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 v2 RESEND 11/23] lpfc: Remove superfluous call to pci_disable_msix()

[Alexander Gordeev]

There is no need to call pci_disable_msix() in case
the previous call to pci_enable_msix() failed

Signed-off-by: Alexander Gordeev 
Cc: James Smart 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_init.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 635eeb3..7163f37 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8131,7 +8131,7 @@ lpfc_sli_enable_msix(struct lpfc_hba *phba)
if (rc) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
"0420 PCI enable MSI-X failed (%d)\n", rc);
-   goto msi_fail_out;
+   goto vec_fail_out;
}
for (i = 0; i < LPFC_MSIX_VECTORS; i++)
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
@@ -8209,6 +8209,8 @@ irq_fail_out:
 msi_fail_out:
/* Unconfigure MSI-X capability structure */
pci_disable_msix(phba->pcidev);
+
+vec_fail_out:
return rc;
 }
 
@@ -8701,7 +8703,7 @@ enable_msix_vectors:
} else if (rc) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
"0484 PCI enable MSI-X failed (%d)\n", rc);
-   goto msi_fail_out;
+   goto vec_fail_out;
}
 
/* Log MSI-X vector assignment */
@@ -8764,9 +8766,10 @@ cfg_fail_out:
 &phba->sli4_hba.fcp_eq_hdl[index]);
}
 
-msi_fail_out:
/* Unconfigure MSI-X capability structure */
pci_disable_msix(phba->pcidev);
+
+vec_fail_out:
return rc;
 }
 
-- 
1.7.7.6

--
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 RESEND 08/23] isci: Use pci_enable_msix_exact() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Lukasz Dorau 
Cc: Maciej Patelczyk 
Cc: Dave Jiang 
Cc: intel-linux-...@intel.com
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/isci/init.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
index 695b34e..4198e45 100644
--- a/drivers/scsi/isci/init.c
+++ b/drivers/scsi/isci/init.c
@@ -356,7 +356,7 @@ static int isci_setup_interrupts(struct pci_dev *pdev)
for (i = 0; i < num_msix; i++)
pci_info->msix_entries[i].entry = i;
 
-   err = pci_enable_msix(pdev, pci_info->msix_entries, num_msix);
+   err = pci_enable_msix_exact(pdev, pci_info->msix_entries, num_msix);
if (err)
goto intx;
 
-- 
1.7.7.6

--
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 5/9] crypto: qce: Adds sha and hmac transforms

[Stanimir Varbanov]

Hi Stephen,

On 04/11/2014 11:12 PM, Stephen Boyd wrote:
> On 04/10, Stanimir Varbanov wrote:
>> On 04/09/2014 03:09 AM, Stephen Boyd wrote:
>>> On 04/03, Stanimir Varbanov wrote:
>>>
 +
 +  return 0;
 +}
 +
 +static int qce_ahash_import(struct ahash_request *req, const void *in)
 +{
 +  struct qce_sha_reqctx *rctx = ahash_request_ctx(req);
 +  u32 flags = rctx->flags;
 +  bool hmac = IS_SHA_HMAC(flags);
 +  int ret;
 +
 +  if (IS_SHA1(flags) || IS_SHA1_HMAC(flags)) {
 +  struct sha1_state *state = (struct sha1_state *)in;
>>>
>>> Unnecessary cast from void *.
>>
>> Nope, "in" is "const void *". Cast is needed to avoid compiler warnings.
>>
> 
> Ouch. Why are we casting away const? It should be possible to
> make qce_import_common() take const state and buffer arguments?
> 

Sure, that's possible. Thanks!


-- 
regards,
Stan
--
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 RESEND 12/23] lpfc: Use pci_enable_msix_range() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: James Smart 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/lpfc/lpfc_init.c |   38 +-
 1 files changed, 17 insertions(+), 21 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 7163f37..b109adc 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8100,9 +8100,9 @@ lpfc_sli4_pci_mem_unset(struct lpfc_hba *phba)
  * @phba: pointer to lpfc hba data structure.
  *
  * This routine is invoked to enable the MSI-X interrupt vectors to device
- * with SLI-3 interface specs. The kernel function pci_enable_msix() is
- * called to enable the MSI-X vectors. Note that pci_enable_msix(), once
- * invoked, enables either all or nothing, depending on the current
+ * with SLI-3 interface specs. The kernel function pci_enable_msix_exact()
+ * is called to enable the MSI-X vectors. Note that pci_enable_msix_exact(),
+ * once invoked, enables either all or nothing, depending on the current
  * availability of PCI vector resources. The device driver is responsible
  * for calling the individual request_irq() to register each MSI-X vector
  * with a interrupt handler, which is done in this function. Note that
@@ -8126,8 +8126,8 @@ lpfc_sli_enable_msix(struct lpfc_hba *phba)
phba->msix_entries[i].entry = i;
 
/* Configure MSI-X capability structure */
-   rc = pci_enable_msix(phba->pcidev, phba->msix_entries,
-   ARRAY_SIZE(phba->msix_entries));
+   rc = pci_enable_msix_exact(phba->pcidev, phba->msix_entries,
+  ARRAY_SIZE(phba->msix_entries));
if (rc) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
"0420 PCI enable MSI-X failed (%d)\n", rc);
@@ -8664,15 +8664,13 @@ out:
  * @phba: pointer to lpfc hba data structure.
  *
  * This routine is invoked to enable the MSI-X interrupt vectors to device
- * with SLI-4 interface spec. The kernel function pci_enable_msix() is called
- * to enable the MSI-X vectors. Note that pci_enable_msix(), once invoked,
- * enables either all or nothing, depending on the current availability of
- * PCI vector resources. The device driver is responsible for calling the
- * individual request_irq() to register each MSI-X vector with a interrupt
- * handler, which is done in this function. Note that later when device is
- * unloading, the driver should always call free_irq() on all MSI-X vectors
- * it has done request_irq() on before calling pci_disable_msix(). Failure
- * to do so results in a BUG_ON() and a device will be left with MSI-X
+ * with SLI-4 interface spec. The kernel function pci_enable_msix_range()
+ * is called to enable the MSI-X vectors. The device driver is responsible
+ * for calling the individual request_irq() to register each MSI-X vector
+ * with a interrupt handler, which is done in this function. Note that later
+ * when device is unloading, the driver should always call free_irq() on all
+ * MSI-X vectors it has done request_irq() on before calling pci_disable_msix()
+ * Failure to do so results in a BUG_ON() and a device will be left with MSI-X
  * enabled and leaks its vectors.
  *
  * Return codes
@@ -8694,18 +8692,16 @@ lpfc_sli4_enable_msix(struct lpfc_hba *phba)
phba->sli4_hba.msix_entries[index].entry = index;
vectors++;
}
-enable_msix_vectors:
-   rc = pci_enable_msix(phba->pcidev, phba->sli4_hba.msix_entries,
-vectors);
-   if (rc > 1) {
-   vectors = rc;
-   goto enable_msix_vectors;
-   } else if (rc) {
+
+   rc = pci_enable_msix_range(phba->pcidev, phba->sli4_hba.msix_entries,
+  2, vectors);
+   if (rc < 0) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
"0484 PCI enable MSI-X failed (%d)\n", rc);
goto vec_fail_out;
}
 
+   vectors = rc;
/* Log MSI-X vector assignment */
for (index = 0; index < vectors; index++)
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
-- 
1.7.7.6

--
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 RESEND 05/23] csiostor: Remove superfluous call to pci_disable_msix()

[Alexander Gordeev]

There is no need to call pci_disable_msix() in case
the previous call to pci_enable_msix() failed

Signed-off-by: Alexander Gordeev 
Cc: Naresh Kumar Inna 
Cc: Arvind Bhushan 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/csiostor/csio_isr.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/csiostor/csio_isr.c b/drivers/scsi/csiostor/csio_isr.c
index 7ee9777..91ba91d 100644
--- a/drivers/scsi/csiostor/csio_isr.c
+++ b/drivers/scsi/csiostor/csio_isr.c
@@ -529,10 +529,8 @@ csio_enable_msix(struct csio_hw *hw)
csio_reduce_sqsets(hw, cnt - extra);
}
} else {
-   if (rv > 0) {
-   pci_disable_msix(hw->pdev);
+   if (rv > 0)
csio_info(hw, "Not using MSI-X, remainder:%d\n", rv);
-   }
 
kfree(entries);
return -ENOMEM;
-- 
1.7.7.6

--
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 RESEND 07/23] fnic: Use pci_enable_msix_exact() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Hiral Patel 
Cc: Suma Ramars 
Cc: Brian Uchino 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/fnic/fnic_isr.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/fnic/fnic_isr.c b/drivers/scsi/fnic/fnic_isr.c
index 7d9b54a..a0dd1b6 100644
--- a/drivers/scsi/fnic/fnic_isr.c
+++ b/drivers/scsi/fnic/fnic_isr.c
@@ -257,8 +257,8 @@ int fnic_set_intr_mode(struct fnic *fnic)
fnic->raw_wq_count >= m &&
fnic->wq_copy_count >= o &&
fnic->cq_count >= n + m + o) {
-   if (!pci_enable_msix(fnic->pdev, fnic->msix_entry,
-   n + m + o + 1)) {
+   if (!pci_enable_msix_exact(fnic->pdev, fnic->msix_entry,
+  n + m + o + 1)) {
fnic->rq_count = n;
fnic->raw_wq_count = m;
fnic->wq_copy_count = o;
-- 
1.7.7.6

--
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 RESEND 06/23] csiostor: Use pci_enable_msix_range() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Naresh Kumar Inna 
Cc: Arvind Bhushan 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/csiostor/csio_hw.h  |2 +-
 drivers/scsi/csiostor/csio_isr.c |   22 +-
 2 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/scsi/csiostor/csio_hw.h b/drivers/scsi/csiostor/csio_hw.h
index 49b1daa..5db2d85 100644
--- a/drivers/scsi/csiostor/csio_hw.h
+++ b/drivers/scsi/csiostor/csio_hw.h
@@ -94,7 +94,7 @@ enum {
 };
 
 struct csio_msix_entries {
-   unsigned short  vector; /* Vector assigned by pci_enable_msix */
+   unsigned short  vector; /* Assigned MSI-X vector */
void*dev_id;/* Priv object associated w/ this msix*/
chardesc[24];   /* Description of this vector */
 };
diff --git a/drivers/scsi/csiostor/csio_isr.c b/drivers/scsi/csiostor/csio_isr.c
index 91ba91d..a8c748a 100644
--- a/drivers/scsi/csiostor/csio_isr.c
+++ b/drivers/scsi/csiostor/csio_isr.c
@@ -499,7 +499,7 @@ csio_reduce_sqsets(struct csio_hw *hw, int cnt)
 static int
 csio_enable_msix(struct csio_hw *hw)
 {
-   int rv, i, j, k, n, min, cnt;
+   int i, j, k, n, min, cnt;
struct csio_msix_entries *entryp;
struct msix_entry *entries;
int extra = CSIO_EXTRA_VECS;
@@ -521,19 +521,15 @@ csio_enable_msix(struct csio_hw *hw)
 
csio_dbg(hw, "FW supp #niq:%d, trying %d msix's\n", hw->cfg_niq, cnt);
 
-   while ((rv = pci_enable_msix(hw->pdev, entries, cnt)) >= min)
-   cnt = rv;
-   if (!rv) {
-   if (cnt < (hw->num_sqsets + extra)) {
-   csio_dbg(hw, "Reducing sqsets to %d\n", cnt - extra);
-   csio_reduce_sqsets(hw, cnt - extra);
-   }
-   } else {
-   if (rv > 0)
-   csio_info(hw, "Not using MSI-X, remainder:%d\n", rv);
-
+   cnt = pci_enable_msix_range(hw->pdev, entries, min, cnt);
+   if (cnt < 0) {
kfree(entries);
-   return -ENOMEM;
+   return cnt;
+   }
+
+   if (cnt < (hw->num_sqsets + extra)) {
+   csio_dbg(hw, "Reducing sqsets to %d\n", cnt - extra);
+   csio_reduce_sqsets(hw, cnt - extra);
}
 
/* Save off vectors */
-- 
1.7.7.6

--
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 RESEND 02/23] bfa: Do not call pci_enable_msix() after it failed once

[Alexander Gordeev]

Function pci_enable_msix() should not be called in case
it threw a negative errno from a previous call.

Signed-off-by: Alexander Gordeev 
Cc: Anil Gurumurthy 
Cc: Vijaya Mohan Guvva 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Anil Gurumurthy 
---
 drivers/scsi/bfa/bfad.c |   48 ++
 1 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index cc0fbcd..972ff8d 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -1235,33 +1235,31 @@ bfad_setup_intr(struct bfad_s *bfad)
   (bfa_asic_id_cb(pdev->device) && !msix_disable_cb)) {
 
error = pci_enable_msix(bfad->pcidev, msix_entries, bfad->nvec);
-   if (error) {
-   /* In CT1 & CT2, try to allocate just one vector */
-   if (bfa_asic_id_ctc(pdev->device)) {
-   printk(KERN_WARNING "bfa %s: trying one msix "
-  "vector failed to allocate %d[%d]\n",
-  bfad->pci_name, bfad->nvec, error);
-   bfad->nvec = 1;
-   error = pci_enable_msix(bfad->pcidev,
+   /* In CT1 & CT2, try to allocate just one vector */
+   if (error > 0 && bfa_asic_id_ctc(pdev->device)) {
+   printk(KERN_WARNING "bfa %s: trying one msix "
+  "vector failed to allocate %d[%d]\n",
+  bfad->pci_name, bfad->nvec, error);
+   bfad->nvec = 1;
+   error = pci_enable_msix(bfad->pcidev,
msix_entries, bfad->nvec);
-   }
+   }
 
-   /*
-* Only error number of vector is available.
-* We don't have a mechanism to map multiple
-* interrupts into one vector, so even if we
-* can try to request less vectors, we don't
-* know how to associate interrupt events to
-*  vectors. Linux doesn't duplicate vectors
-* in the MSIX table for this case.
-*/
-   if (error) {
-   printk(KERN_WARNING "bfad%d: "
-  "pci_enable_msix failed (%d), "
-  "use line based.\n",
-   bfad->inst_no, error);
-   goto line_based;
-   }
+   /*
+* Only error number of vector is available.
+* We don't have a mechanism to map multiple
+* interrupts into one vector, so even if we
+* can try to request less vectors, we don't
+* know how to associate interrupt events to
+*  vectors. Linux doesn't duplicate vectors
+* in the MSIX table for this case.
+*/
+   if (error) {
+   printk(KERN_WARNING "bfad%d: "
+  "pci_enable_msix failed (%d), "
+  "use line based.\n",
+   bfad->inst_no, error);
+   goto line_based;
}
 
/* Disable INTX in MSI-X mode */
-- 
1.7.7.6

--
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 RESEND 01/23] be2iscsi: Use pci_enable_msix_exact() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Jayamohan Kallickal 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Jayamohan Kallickal 
---
 drivers/scsi/be2iscsi/be_main.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 0d82229..279b2f9 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -5282,12 +5282,10 @@ static void beiscsi_msix_enable(struct beiscsi_hba 
*phba)
for (i = 0; i <= phba->num_cpus; i++)
phba->msix_entries[i].entry = i;
 
-   status = pci_enable_msix(phba->pcidev, phba->msix_entries,
-(phba->num_cpus + 1));
+   status = pci_enable_msix_exact(phba->pcidev, phba->msix_entries,
+  phba->num_cpus + 1);
if (!status)
phba->msix_enabled = true;
-
-   return;
 }
 
 /*
-- 
1.7.7.6

--
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 RESEND 04/23] bfa: Use pci_enable_msix_exact() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Anil Gurumurthy 
Cc: Vijaya Mohan Guvva 
Cc: linux-s...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/scsi/bfa/bfad.c |   20 ++--
 1 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index e7e4774..839c81c 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -1234,29 +1234,21 @@ bfad_setup_intr(struct bfad_s *bfad)
if ((bfa_asic_id_ctc(pdev->device) && !msix_disable_ct) ||
   (bfa_asic_id_cb(pdev->device) && !msix_disable_cb)) {
 
-   error = pci_enable_msix(bfad->pcidev, msix_entries, bfad->nvec);
+   error = pci_enable_msix_exact(bfad->pcidev,
+ msix_entries, bfad->nvec);
/* In CT1 & CT2, try to allocate just one vector */
-   if (error > 0 && bfa_asic_id_ctc(pdev->device)) {
+   if (error == -ENOSPC && bfa_asic_id_ctc(pdev->device)) {
printk(KERN_WARNING "bfa %s: trying one msix "
   "vector failed to allocate %d[%d]\n",
   bfad->pci_name, bfad->nvec, error);
bfad->nvec = 1;
-   error = pci_enable_msix(bfad->pcidev,
-   msix_entries, bfad->nvec);
+   error = pci_enable_msix_exact(bfad->pcidev,
+ msix_entries, 1);
}
 
-   /*
-* Only error number of vector is available.
-* We don't have a mechanism to map multiple
-* interrupts into one vector, so even if we
-* can try to request less vectors, we don't
-* know how to associate interrupt events to
-*  vectors. Linux doesn't duplicate vectors
-* in the MSIX table for this case.
-*/
if (error) {
printk(KERN_WARNING "bfad%d: "
-  "pci_enable_msix failed (%d), "
+  "pci_enable_msix_exact failed (%d), "
   "use line based.\n",
bfad->inst_no, error);
goto line_based;
-- 
1.7.7.6

--
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/

[no subject]

[Christoph Hellwig]

This is the majority of the blk-mq work still required for switching
over SCSI.  There are a few more bits for I/O completion and requeueing
pending, but they will need further work.

--
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/