Re: [Xen-devel] [PATCH] x86/xen: Fix 64bit kernel pagetable setup of PV guests

[Andrew Cooper]

On 02/09/14 12:01, David Vrabel wrote:
> On 01/09/14 18:34, David Vrabel wrote:
>> On 29/08/14 16:17, Stefan Bader wrote:
>>> This change might not be the fully correct approach as it basically
>>> removes the pre-set page table entry for the fixmap that is compile
>>> time set (level2_fixmap_pgt[506]->level1_fixmap_pgt). For one the
>>> level1 page table is not yet declared in C headers (that might be
>>> fixed). But also with the current bug, it was removed, too. Since
>>> the Xen mappings for level2_kernel_pgt only covered kernel + initrd
>>> and some Xen data this did never reach that far. And still, something
>>> does create entries at level2_fixmap_pgt[506..507]. So it should be
>>> ok. At least I was able to successfully boot a kernel with 1G kernel
>>> image size without any vmalloc whinings.
>> [...]
>>> --- a/arch/x86/xen/mmu.c
>>> +++ b/arch/x86/xen/mmu.c
>>> @@ -1902,8 +1902,22 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, 
>>> unsigned long max_pfn)
>>> /* L3_i[0] -> level2_ident_pgt */
>>> convert_pfn_mfn(level3_ident_pgt);
>>> /* L3_k[510] -> level2_kernel_pgt
>>> -* L3_i[511] -> level2_fixmap_pgt */
>>> +* L3_k[511] -> level2_fixmap_pgt */
>>> convert_pfn_mfn(level3_kernel_pgt);
>>> +
>>> +   /* level2_fixmap_pgt contains a single entry for the
>>> +* fixmap area at offset 506. The correct way would
>>> +* be to convert level2_fixmap_pgt to mfn and set the
>>> +* level1_fixmap_pgt (which is completely empty) to RO,
>>> +* too. But currently this page table is not declared,
>>> +* so it would be a bit of voodoo to get its address.
>>> +* And also the fixmap entry was never set due to using
>>> +* the wrong l2 when getting Xen's tables. So let's just
>>> +* just nuke it.
>>> +* This orphans level1_fixmap_pgt, but that was basically
>>> +* done before the change as well.
>>> +*/
>>> +   memset(level2_fixmap_pgt, 0, 512*sizeof(long));
>> level2_fixmap_pgt etc. are defined for the benefit of Xen only so I
>> think you should add an extern for level1_fixmap_pgt and fix this up
>> properly.
>>
>> It might not matter now, but it might in the future...
> I found some time to look into this and test it.  Including without
> enabling KSLAR, but reproing the vmalloc failure with a large (800 MiB
> module).
>
> I've clarified the change description, can you review my edits?
>
> Thanks for investigating and fixing this!
>
> David
>
> 8<--
> x86/xen: don't copy junk into kernel page tables

Can the patch title and description be adjusted?  It is not junk in the
pagetables, as Xen would reject such a pagetable update.  It is merely a
copy of the valid Xen mappings.

~Andrew

>
> When RANDOMIZE_BASE (KASLR) is enabled; or the sum of all loaded
> modules exceeds 512 MiB, then loading modules fails with a warning
> (and hence a vmalloc allocation failure) because the PTEs for the
> newly-allocated vmalloc address space are not zero.
>
>   WARNING: CPU: 0 PID: 494 at linux/mm/vmalloc.c:128
>vmap_page_range_noflush+0x2a1/0x360()
>
> This is caused by xen_setup_kernel_pagetables() copying junk into the
> page tables (to level2_fixmap_pgt), overwriting many non-present
> entries.
>
> Without KASLR, the normal kernel image size only covers the first half
> of level2_kernel_pgt and module space starts after that.
>
> L4[511]->level3_kernel_pgt[510]->level2_kernel_pgt[  0..255]->kernel
>   [256..511]->module
>   [511]->level2_fixmap_pgt[  0..505]->module
>
> This allows 512 MiB of of module vmalloc space to be used before
> having to use the corrupted level2_fixmap_pgt entries.
>
> With KASLR enabled, the kernel image uses the full PUD range of 1G and
> module space starts in the level2_fixmap_pgt. So basically:
>
> L4[511]->level3_kernel_pgt[510]->level2_kernel_pgt[0..511]->kernel
>   [511]->level2_fixmap_pgt[0..505]->module
>
> And now no module vmalloc space can be used without using the corrupt
> level2_fixmap_pgt entries.
>
> Fix this by properly converting the level2_fixmap_pgt entries to MFNs,
> and setting level1_fixmap_pgt as read-only.
>
> Signed-off-by: Stefan Bader 
> Cc: sta...@vger.kernel.org
> Signed-off-by: David Vrabel 
> ---
>  arch/x86/include/asm/pgtable_64.h |1 +
>  arch/x86/xen/mmu.c|   27 ---
>  2 files changed, 13 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/include/asm/pgtable_64.h 
> b/arch/x86/include/asm/pgtable_64.h
> index 5be9063..3874693 100644
> --- a/arch/x86/include/asm/pgtable_64.h
> +++ b/arch/x86/include/asm/pgtable_64.h
> @@ -19,6 +19,7 @@ extern pud_t level3_ident_pgt[512];
>  extern pmd_t level2_kernel_pgt[512];
>  extern pmd_t level2_fixmap_pgt[512];
>  extern 

Re: [PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Felipe Balbi]

Hi,

On Tue, Sep 02, 2014 at 04:42:18PM +0530, Vivek Gautam wrote:
> Adding phy calibrate callback, which facilitates setting certain
> PHY settings post initialization of the PHY controller.
> Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which
> the Loss-of-Signal (LOS) Detector Threshold Level as well as
> Tx-Vboost-Level should be controlled for Super-Speed operations.
> 
> Additionally set proper time to wait for RxDetect measurement,
> for desired PHY reference clock, so as to solve issue with enumeration
> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
> on the controller.
> We are using CR_port for this purpose to send required data
> to override the LOS values.
> 
> On testing with USB 3.0 devices on USB 3.0 port present on
> SMDK5420, and peach-pit boards should see following message:
> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
> 
> and without this patch, should see below shown message:
> usb 1-1: new high-speed USB device number 2 using xhci-hcd
> 
> [Also removed unnecessary extra lines in the register macro definitions]
> 
> Signed-off-by: Vivek Gautam 
> ---
>  drivers/phy/phy-exynos5-usbdrd.c |  185 
> ++
>  1 file changed, 170 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/phy/phy-exynos5-usbdrd.c 
> b/drivers/phy/phy-exynos5-usbdrd.c
> index 47f47fe..85742b0 100644
> --- a/drivers/phy/phy-exynos5-usbdrd.c
> +++ b/drivers/phy/phy-exynos5-usbdrd.c
> @@ -37,13 +37,11 @@
>  
>  /* EXYNOS5: USB 3.0 DRD PHY registers */
>  #define EXYNOS5_DRD_LINKSYSTEM   0x04
> -
>  #define LINKSYSTEM_FLADJ_MASK(0x3f << 1)
>  #define LINKSYSTEM_FLADJ(_x) ((_x) << 1)
>  #define LINKSYSTEM_XHCI_VERSION_CONTROL  BIT(27)
>  
>  #define EXYNOS5_DRD_PHYUTMI  0x08
> -
>  #define PHYUTMI_OTGDISABLE   BIT(6)
>  #define PHYUTMI_FORCESUSPEND BIT(1)
>  #define PHYUTMI_FORCESLEEP   BIT(0)
> @@ -51,26 +49,20 @@
>  #define EXYNOS5_DRD_PHYPIPE  0x0c
>  
>  #define EXYNOS5_DRD_PHYCLKRST0x10
> -
>  #define PHYCLKRST_EN_UTMISUSPEND BIT(31)
> -
>  #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23)
>  #define PHYCLKRST_SSC_REFCLKSEL(_x)  ((_x) << 23)
> -
>  #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21)
>  #define PHYCLKRST_SSC_RANGE(_x)  ((_x) << 21)
> -
>  #define PHYCLKRST_SSC_EN BIT(20)
>  #define PHYCLKRST_REF_SSP_EN BIT(19)
>  #define PHYCLKRST_REF_CLKDIV2BIT(18)
> -
>  #define PHYCLKRST_MPLL_MULTIPLIER_MASK   (0x7f << 11)
>  #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11)
>  #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF(0x32 << 11)
>  #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF  (0x68 << 11)
>  #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF  (0x7d << 11)
>  #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF   (0x02 << 11)
> -
>  #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5)
>  #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8)
>  #define PHYCLKRST_FSEL(_x)   ((_x) << 5)
> @@ -78,46 +70,68 @@
>  #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5)
>  #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5)
>  #define PHYCLKRST_FSEL_PAD_19_2MHZ   (0x38 << 5)
> -
>  #define PHYCLKRST_RETENABLEN BIT(4)
> -
>  #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2)
>  #define PHYCLKRST_REFCLKSEL_PAD_REFCLK   (0x2 << 2)
>  #define PHYCLKRST_REFCLKSEL_EXT_REFCLK   (0x3 << 2)
> -
>  #define PHYCLKRST_PORTRESET  BIT(1)
>  #define PHYCLKRST_COMMONONN  BIT(0)
>  
>  #define EXYNOS5_DRD_PHYREG0  0x14
> +#define PHYREG0_SSC_REF_CLK_SEL  BIT(21)
> +#define PHYREG0_SSC_RANGEBIT(20)
> +#define PHYREG0_CR_WRITE BIT(19)
> +#define PHYREG0_CR_READ  BIT(18)
> +#define PHYREG0_CR_DATA_IN(_x)   ((_x) << 2)
> +#define PHYREG0_CR_CAP_DATA  BIT(1)
> +#define PHYREG0_CR_CAP_ADDR  BIT(0)
> +
>  #define EXYNOS5_DRD_PHYREG1  0x18
> +#define PHYREG1_CR_DATA_OUT(_x)  ((_x) << 1)
> +#define PHYREG1_CR_ACK   BIT(0)
>  
>  #define EXYNOS5_DRD_PHYPARAM00x1c
> -
>  #define PHYPARAM0_REF_USE_PADBIT(31)
>  #define PHYPARAM0_REF_LOSLEVEL_MASK  (0x1f << 26)
>  #define PHYPARAM0_REF_LOSLEVEL   (0x9 << 26)
>  
>  #define EXYNOS5_DRD_PHYPARAM10x20
> -
>  #define PHYPARAM1_PCS_TXDEEMPH_MASK  (0x1f << 0)
>  #define PHYPARAM1_PCS_TXDEEMPH   (0x1c)
>  
>  #define EXYNOS5_DRD_PHYTERM  0x24
>  
>  #define 

[patch] mm: clean up zone flags

[Johannes Weiner]

Page reclaim tests zone_is_reclaim_dirty(), but the site that actually
sets this state does zone_set_flag(zone, ZONE_TAIL_LRU_DIRTY), sending
the reader through layers indirection just to track down a simple bit.

Remove all zone flag wrappers and just use bitops against zone->flags
directly.  It's just as readable and the lines are barely any longer.

Also rename ZONE_TAIL_LRU_DIRTY to ZONE_DIRTY to match ZONE_WRITEBACK,
and remove the zone_flags_t typedef.

Signed-off-by: Johannes Weiner 
---
 include/linux/mmzone.h | 51 +++---
 mm/backing-dev.c   |  2 +-
 mm/oom_kill.c  |  6 +++---
 mm/page_alloc.c|  8 
 mm/vmscan.c| 28 +--
 5 files changed, 25 insertions(+), 70 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 318df7051850..48bf12ef6620 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -521,13 +521,13 @@ struct zone {
atomic_long_t   vm_stat[NR_VM_ZONE_STAT_ITEMS];
 } cacheline_internodealigned_in_smp;
 
-typedef enum {
+enum zone_flags {
ZONE_RECLAIM_LOCKED,/* prevents concurrent reclaim */
ZONE_OOM_LOCKED,/* zone is in OOM killer zonelist */
ZONE_CONGESTED, /* zone has many dirty pages backed by
 * a congested BDI
 */
-   ZONE_TAIL_LRU_DIRTY,/* reclaim scanning has recently found
+   ZONE_DIRTY, /* reclaim scanning has recently found
 * many dirty file pages at the tail
 * of the LRU.
 */
@@ -535,52 +535,7 @@ typedef enum {
 * many pages under writeback
 */
ZONE_FAIR_DEPLETED, /* fair zone policy batch depleted */
-} zone_flags_t;
-
-static inline void zone_set_flag(struct zone *zone, zone_flags_t flag)
-{
-   set_bit(flag, >flags);
-}
-
-static inline int zone_test_and_set_flag(struct zone *zone, zone_flags_t flag)
-{
-   return test_and_set_bit(flag, >flags);
-}
-
-static inline void zone_clear_flag(struct zone *zone, zone_flags_t flag)
-{
-   clear_bit(flag, >flags);
-}
-
-static inline int zone_is_reclaim_congested(const struct zone *zone)
-{
-   return test_bit(ZONE_CONGESTED, >flags);
-}
-
-static inline int zone_is_reclaim_dirty(const struct zone *zone)
-{
-   return test_bit(ZONE_TAIL_LRU_DIRTY, >flags);
-}
-
-static inline int zone_is_reclaim_writeback(const struct zone *zone)
-{
-   return test_bit(ZONE_WRITEBACK, >flags);
-}
-
-static inline int zone_is_reclaim_locked(const struct zone *zone)
-{
-   return test_bit(ZONE_RECLAIM_LOCKED, >flags);
-}
-
-static inline int zone_is_fair_depleted(const struct zone *zone)
-{
-   return test_bit(ZONE_FAIR_DEPLETED, >flags);
-}
-
-static inline int zone_is_oom_locked(const struct zone *zone)
-{
-   return test_bit(ZONE_OOM_LOCKED, >flags);
-}
+};
 
 static inline unsigned long zone_end_pfn(const struct zone *zone)
 {
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index 1706cbbdf5f0..d7a9051a6db5 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -631,7 +631,7 @@ long wait_iff_congested(struct zone *zone, int sync, long 
timeout)
 * of sleeping on the congestion queue
 */
if (atomic_read(_bdi_congested[sync]) == 0 ||
-   !zone_is_reclaim_congested(zone)) {
+   test_bit(ZONE_CONGESTED, >flags)) {
cond_resched();
 
/* In case we scheduled, work out time remaining */
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 1e11df8fa7ec..bbf405a3a18f 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -565,7 +565,7 @@ bool oom_zonelist_trylock(struct zonelist *zonelist, gfp_t 
gfp_mask)
 
spin_lock(_scan_lock);
for_each_zone_zonelist(zone, z, zonelist, gfp_zone(gfp_mask))
-   if (zone_is_oom_locked(zone)) {
+   if (test_bit(ZONE_OOM_LOCKED, >flags)) {
ret = false;
goto out;
}
@@ -575,7 +575,7 @@ bool oom_zonelist_trylock(struct zonelist *zonelist, gfp_t 
gfp_mask)
 * call to oom_zonelist_trylock() doesn't succeed when it shouldn't.
 */
for_each_zone_zonelist(zone, z, zonelist, gfp_zone(gfp_mask))
-   zone_set_flag(zone, ZONE_OOM_LOCKED);
+   set_bit(ZONE_OOM_LOCKED, >flags);
 
 out:
spin_unlock(_scan_lock);
@@ -594,7 +594,7 @@ void oom_zonelist_unlock(struct zonelist *zonelist, gfp_t 
gfp_mask)
 
spin_lock(_scan_lock);
for_each_zone_zonelist(zone, z, zonelist, gfp_zone(gfp_mask))
-   zone_clear_flag(zone, ZONE_OOM_LOCKED);
+   clear_bit(ZONE_OOM_LOCKED, >flags);
   

Re: [PATCH 1/4] mfd: arizona: Add additional dummy IRQ callbacks

[Lee Jones]

On Tue, 02 Sep 2014, Charles Keepax wrote:

> On Thu, Aug 21, 2014 at 12:56:31PM +0100, Lee Jones wrote:
> > On Tue, 12 Aug 2014, Charles Keepax wrote:
> > 
> > > We use a dummy IRQ chip to dispatch interrupts to the two seperate IRQ
> > > domains on the Arizona devices. Currently only the enable and disable
> > > callbacks are defined however, there are some situations where additional
> > > callbacks will be used from the IRQ core, which currently results in an
> > > NULL pointer deference. Add handlers for more of the IRQ callbacks and
> > > combine these into a single function since they are all identical.
> > > 
> > > Signed-off-by: Charles Keepax 
> > > ---
> > 
> > If you provide .irq_enable(), then .irq_unmask becomes redundant
> > and/or is checked for before invoking.  There is a chance of
> > .irq_mask() being called, but if this is a problem, it should be fixed
> > in the IRQ Chip code.  There is also one unprotected invocation of
> > .irq_ack(), but I think this should be fixed rather than forcing each
> > user of IRQ Chip to provide all of these call-backs.
> 
> So I have been looking at this further and going back over things
> from when the issue was discovered and it looks like it was
> probably the unprotected irq_ack call (in handle_edge_irq) that
> was the problem. But thinking about this more I am fairly
> convinced that the call is unprotected because it is expected that
> an edge IRQ will always have an ack, as it doesn't really make
> sense for an edge IRQ to not have an ack.
> 
> The IRQ chip here is just a software device to distribute the IRQ
> to the two sub-domains. As such I think the problem lies here:
> 
>   irq_set_chip_and_handler(virq, _irq_chip, handle_edge_irq);
> 
> I am pretty sure the correct fix is to change this to a
> handle_simple_irq as it is just a software dummy and there is
> nothing really edge triggered about it. Do you see any problems
> with that as a solution?

I don't pretend to be an expert on the IRQ framework, but this
certainly looks a lot less hacky than your previous submission.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v10 03/19] arm: fiq: Replace default FIQ handler

[Paul E. McKenney]

On Tue, Sep 02, 2014 at 12:49:16PM +0100, Daniel Thompson wrote:
> On 28/08/14 16:01, Russell King - ARM Linux wrote:
> > On Tue, Aug 19, 2014 at 07:12:07PM +0100, Daniel Thompson wrote:
> >> On 19/08/14 18:37, Russell King - ARM Linux wrote:
> >>> On Tue, Aug 19, 2014 at 05:45:53PM +0100, Daniel Thompson wrote:
>  +int register_fiq_nmi_notifier(struct notifier_block *nb)
>  +{
>  +return atomic_notifier_chain_register(_nmi_chain, nb);
>  +}
>  +
>  +asmlinkage void __exception_irq_entry fiq_nmi_handler(struct pt_regs 
>  *regs)
>  +{
>  +struct pt_regs *old_regs = set_irq_regs(regs);
>  +
>  +nmi_enter();
>  +atomic_notifier_call_chain(_nmi_chain, (unsigned long)regs, 
>  NULL);
>  +nmi_exit();
>  +set_irq_regs(old_regs);
>  +}
> >>>
> >>> Really not happy with this.  What happens if a FIQ occurs while we're
> >>> inside register_fiq_nmi_notifier() - more specifically inside
> >>> atomic_notifier_chain_register() ?
> >>
> >> Should depend on which side of the rcu update we're on.
> > 
> > I just asked Paul McKenney, our RCU expert... essentially, yes, RCU
> > stuff itself is safe in this context.  However, RCU stuff can call into
> > lockdep if lockdep is configured, and there are questions over lockdep.
> > 
> > There's some things which can be done to reduce the lockdep exposure
> > to it, such as ensuring that rcu_read_lock() is first called outside
> > of FIQ context.
> > 
> > There's concerns with whether either printk() in check_flags() could
> > be reached too (flags there should always indicate that IRQs were
> > disabled, so that reduces down to a question about just the first
> > printk() there.)
> > 
> > There's also the very_verbose() stuff for RCU lockdep classes which
> > Paul says must not be enabled.
> > 
> > Lastly, Paul isn't a lockdep expert, but he sees nothing that prevents
> > lockdep doing the deadlock checking as a result of the above call.
> > 
> > So... this coupled with my feeling that notifiers make it too easy for
> > unreviewed code to be hooked into this path, I'm fairly sure that we
> > don't want to be calling atomic notifier chains from FIQ context.
> 
> Having esablished (elsewhere in the thread) that RCU usage is safe
> from FIQ I have been working on the assumption that your feeling
> regarding unreviewed code is sufficient on its own to avoid using
> notifiers (and also to avoid a list of function pointers like on x86).

There was a later clarification from a lockdep expert showing that the
code was in fact safe, so the notifier approach should be just fine.

Thanx, Paul

> Therefore I have made the changes requested and produced a
> before/after patch to show the impact of this. I will merge this
> into the FIQ patchset shortly (I need to run a few more build tests
> first).
> 
> Personally I still favour using notifiers and think the coupling below is
> excessive. Nevertheless I've run a couple of basic tests on the code
> below and it works fine.
> 
> 
> diff --git a/arch/arm/include/asm/fiq.h b/arch/arm/include/asm/fiq.h
> index 175bfed..a25c952 100644
> --- a/arch/arm/include/asm/fiq.h
> +++ b/arch/arm/include/asm/fiq.h
> @@ -54,7 +54,6 @@ extern void disable_fiq(int fiq);
>  extern int ack_fiq(int fiq);
>  extern void eoi_fiq(int fiq);
>  extern bool has_fiq(int fiq);
> -extern int register_fiq_nmi_notifier(struct notifier_block *nb);
>  extern void fiq_register_mapping(int irq, struct fiq_chip *chip);
> 
>  /* helpers defined in fiqasm.S: */
> diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
> index 6563da0..cb5ccd6 100644
> --- a/arch/arm/include/asm/kgdb.h
> +++ b/arch/arm/include/asm/kgdb.h
> @@ -51,6 +51,7 @@ extern void kgdb_handle_bus_error(void);
>  extern int kgdb_fault_expected;
> 
>  extern int kgdb_register_fiq(unsigned int fiq);
> +extern void kgdb_handle_fiq(struct pt_regs *regs);
> 
>  #endif /* !__ASSEMBLY__ */
> 
> diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
> index b2bd1c7..7422b58 100644
> --- a/arch/arm/kernel/fiq.c
> +++ b/arch/arm/kernel/fiq.c
> @@ -43,12 +43,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #define FIQ_OFFSET ({\
> @@ -65,7 +67,6 @@ static unsigned long no_fiq_insn;
>  static int fiq_start = -1;
>  static RADIX_TREE(fiq_data_tree, GFP_KERNEL);
>  static DEFINE_MUTEX(fiq_data_mutex);
> -static ATOMIC_NOTIFIER_HEAD(fiq_nmi_chain);
> 
>  /* Default reacquire function
>   * - we always relinquish FIQ control
> @@ -218,17 +219,23 @@ bool has_fiq(int fiq)
>  }
>  EXPORT_SYMBOL(has_fiq);
> 
> -int register_fiq_nmi_notifier(struct notifier_block *nb)
> -{
> - return atomic_notifier_chain_register(_nmi_chain, nb);
> -}
> -
>  asmlinkage void __exception_irq_entry 

Re: [PATCH] Next branch: authgss: authgss.c: Fix warnings for uninitizlized variable expire

[Bruce Fields]

On Tue, Sep 02, 2014 at 04:59:45PM +0300, Boaz Harrosh wrote:
> uninitialized_var was made to be a friend not an enemy, in the face of real
> ugliness it is the best we can do. And that is what it should communicate to
> everyone. Why has it become everyone's favorite blasphemy I do not know.

Not personally claiming it should never be used, just that this
particular case is kind of extreme, since unless I'm missing a real
compilication it's basically just:

if (ctx)
assign to expire
...
if (ctx)
use expire

A compiler wouldn't have to be that smart to actually prove to itself
that expire is initialized at the last step, and that it's not only
failing to do that but actually flagging it as possibly unitialized is
weird.

--b.
--
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 4/4] x86, fpu: irq_fpu_usable: kill all checks except !in_kernel_fpu

[Oleg Nesterov]

Sorry for noise, but just in case...

On 09/02, Oleg Nesterov wrote:
>
> Do you think this can work?

Of course, even if this can work, we should do this later. Let's start
with the simple changes, then we will see if we can actually remove all
other checks.

Oleg.

--
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/4] mfd: arizona: Add additional dummy IRQ callbacks

[Charles Keepax]

On Thu, Aug 21, 2014 at 12:56:31PM +0100, Lee Jones wrote:
> On Tue, 12 Aug 2014, Charles Keepax wrote:
> 
> > We use a dummy IRQ chip to dispatch interrupts to the two seperate IRQ
> > domains on the Arizona devices. Currently only the enable and disable
> > callbacks are defined however, there are some situations where additional
> > callbacks will be used from the IRQ core, which currently results in an
> > NULL pointer deference. Add handlers for more of the IRQ callbacks and
> > combine these into a single function since they are all identical.
> > 
> > Signed-off-by: Charles Keepax 
> > ---
> 
> If you provide .irq_enable(), then .irq_unmask becomes redundant
> and/or is checked for before invoking.  There is a chance of
> .irq_mask() being called, but if this is a problem, it should be fixed
> in the IRQ Chip code.  There is also one unprotected invocation of
> .irq_ack(), but I think this should be fixed rather than forcing each
> user of IRQ Chip to provide all of these call-backs.

So I have been looking at this further and going back over things
from when the issue was discovered and it looks like it was
probably the unprotected irq_ack call (in handle_edge_irq) that
was the problem. But thinking about this more I am fairly
convinced that the call is unprotected because it is expected that
an edge IRQ will always have an ack, as it doesn't really make
sense for an edge IRQ to not have an ack.

The IRQ chip here is just a software device to distribute the IRQ
to the two sub-domains. As such I think the problem lies here:

irq_set_chip_and_handler(virq, _irq_chip, handle_edge_irq);

I am pretty sure the correct fix is to change this to a
handle_simple_irq as it is just a software dummy and there is
nothing really edge triggered about it. Do you see any problems
with that as a solution?

Thanks,
Charles

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Sep 1

[Christoph Lameter]

On Tue, 2 Sep 2014, Bartlomiej Zolnierkiewicz wrote:

> Commit 532d0d0690d1 ("irqchips: Replace __this_cpu_ptr uses")
> incorrectly converted *__this_cpu_ptr() to raw_cpu_read() instead
> of *raw_cpu_ptr().  Fix it.

Oww.. This is double indirection deal there. A percpu offset pointing to
a pointer?

Generally the following is true (definition from
include/asm-generic/percpu.h that is used for ARM for raw_cpu_read):

#define raw_cpu_read_4(pcp) (*raw_cpu_ptr(&(pcp)))



> Index: b/drivers/irqchip/irq-gic.c
> ===
> --- a/drivers/irqchip/irq-gic.c   2014-09-02 14:03:41.026758653 +0200
> +++ b/drivers/irqchip/irq-gic.c   2014-09-02 14:37:04.466811546 +0200
> @@ -102,7 +102,7 @@ static struct gic_chip_data gic_data[MAX
>  #ifdef CONFIG_GIC_NON_BANKED
>  static void __iomem *gic_get_percpu_base(union gic_base *base)
>  {
> - return raw_cpu_read(base->percpu_base);
> + return *raw_cpu_ptr(base->percpu_base);
>  }
>
>  static void __iomem *gic_get_common_base(union gic_base *base)
>
>
--
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] staging: unisys: uislib: uisqueue.c: fixed sparse warning of context imbalance

[Dan Carpenter]

On Tue, Sep 02, 2014 at 04:39:47PM +0530, Sudip Mukherjee wrote:
> fixed sparse warning : context imbalance in 'do_locked_client_insert'
>different lock contexts for basic block
> 
> spin_unlock_irqrestore is called at a later stage before returning 
> from the function if locked is 1.
> 
> Signed-off-by: Sudip Mukherjee 

This doesn't match the email address you are using.

Really, your patch isn't bad but I would prefer if you re-wrote this
entire function because currently it is garbage.

static u8
do_locked_client_insert(struct uisqueue_info *queueinfo,
unsigned int whichqueue,
void *pSignal,
spinlock_t *lock,
unsigned char issueInterruptIfEmpty,
u64 interruptHandle, u8 *channelId)
{
unsigned long flags;
unsigned char queueWasEmpty;

spin_lock_irqsave(lock, flags);

if (!ULTRA_CHANNEL_CLIENT_ACQUIRE_OS(queueinfo->chan, channelId, NULL))
goto unlock;

queueWasEmpty = visor_signalqueue_empty(queueinfo->chan, whichqueue);
if (!visor_signal_insert(queueinfo->chan, whichqueue, pSignal))
goto release;
ULTRA_CHANNEL_CLIENT_RELEASE_OS(queueinfo->chan, channelId, NULL);
spin_unlock_irqrestore(lock, flags);

queueinfo->packets_sent++;

return 1;

release:
ULTRA_CHANNEL_CLIENT_RELEASE_OS(queueinfo->chan, channelId, NULL);
unlock:
spin_unlock_irqrestore(lock, flags);

return 0;
}

The queueWasEmpty variable is kind of silly.  It should just be an int
or maybe a bool if you are being pedantic but instead we very
specifically set it to be an unsigned variable of the incorrect type.
Also we don't use queueWasEmpty at all.  I think we could delete it...

The problem with the original code was that the error paths and the
success paths were mixed together like spaghetti.  If you separate them
out and unwind in the proper order with normal label names then the
code is easy to understand.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] unicore32: Fix build error

[Xuetao Guan]

Signed-off-by: Guan Xuetao 

- Guenter Roeck  写道：
> unicore32 builds fail with
> 
> arch/unicore32/kernel/signal.c: In function ‘setup_frame’:
> arch/unicore32/kernel/signal.c:257: error:
>   ‘usig’ undeclared (first use in this function)
> arch/unicore32/kernel/signal.c:279: error:
>   ‘usig’ undeclared (first use in this function)
> arch/unicore32/kernel/signal.c: In function ‘handle_signal’:
> arch/unicore32/kernel/signal.c:306: warning: unused variable ‘tsk’
> arch/unicore32/kernel/signal.c: In function ‘do_signal’:
> arch/unicore32/kernel/signal.c:376: error:
>   implicit declaration of function ‘get_signsl’
> make[1]: *** [arch/unicore32/kernel/signal.o] Error 1
> make: *** [arch/unicore32/kernel/signal.o] Error 2
> 
> Bisect points to commit 649671c90eaf ("unicore32: Use get_signal()
> signal_setup_done()").
> 
> This code never even compiled. Reverting the patch does not work,
> since previously used functions no longer exist, so try to fix it up.
> Compile tested only.
> 
> Fixes: 649671c90eaf ("unicore32: Use get_signal() signal_setup_done()")
> Cc: Richard Weinberger 
> Signed-off-by: Guenter Roeck 
> ---
> Resending after rebase to current upstream kernel.
> 
> Linus, please consider adding this patch directly to your tree.
> This is the one remaining build failure regression in the upstream kernel.
> 
>  arch/unicore32/kernel/signal.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/unicore32/kernel/signal.c b/arch/unicore32/kernel/signal.c
> index 780d773..7c8fb70 100644
> --- a/arch/unicore32/kernel/signal.c
> +++ b/arch/unicore32/kernel/signal.c
> @@ -254,7 +254,8 @@ static int setup_frame(struct ksignal *ksig, sigset_t 
> *set,
>  
>   err |= setup_sigframe(frame, regs, set);
>   if (err == 0)
> - err |= setup_return(regs, >ka, frame->retcode, frame, 
> usig);
> + err |= setup_return(regs, >ka, frame->retcode, frame,
> + ksig->sig);
>  
>   return err;
>  }
> @@ -276,7 +277,8 @@ static int setup_rt_frame(struct ksignal *ksig, sigset_t 
> *set,
>   err |= __save_altstack(>sig.uc.uc_stack, regs->UCreg_sp);
>   err |= setup_sigframe(>sig, regs, set);
>   if (err == 0)
> - err |= setup_return(regs, >ka, frame->sig.retcode, frame, 
> usig);
> + err |= setup_return(regs, >ka, frame->sig.retcode, frame,
> + ksig->sig);
>  
>   if (err == 0) {
>   /*
> @@ -303,7 +305,6 @@ static void handle_signal(struct ksignal *ksig, struct 
> pt_regs *regs,
> int syscall)
>  {
>   struct thread_info *thread = current_thread_info();
> - struct task_struct *tsk = current;
>   sigset_t *oldset = sigmask_to_save();
>   int usig = ksig->sig;
>   int ret;
> @@ -373,7 +374,7 @@ static void do_signal(struct pt_regs *regs, int syscall)
>   if (!user_mode(regs))
>   return;
>  
> - if (get_signsl()) {
> + if (get_signal()) {
>   handle_signal(, regs, syscall);
>   return;
>   }
> -- 
> 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/

回复： Status of 'unicore32' architecture in Linux kernel

[Xuetao Guan]

Sorry for late reply.

- Guenter Roeck  写道：
> Status of 'unicore32' architecture in Linux kernel
> --
> 
> The idea was to create a working kernel and initramfs for the ongoing Linux
> kernel test project. This summary describes the result of this effort.
> 
> Overall, conclusion is that the architecture would need some work
> (both in qemu and the kernel itself) to make it testable with qemu.

Great. And there's a lot of work to do for unicore32.

> 
> Guenter
> 
> -
> Toolchain used was from [1]. I did not attempt to build my own toolchain.
> 
> Configuration:
> 
> make ARCH=unicore32 defconfig && make ARCH=unicore32
> 
> This configuration currently fails to build in the upstream kernel.
> A patch to fix the problem has been submitted and is pending upstream
> integration [2]. With this patch merged, the 'defconfig' image can
> be built.

Thanks. I'll apply it in my repo.

> 
> 
> qemu
> 
> Attempts to load the unicore32:defconfig image with qemu failed.
> 
> Research points to [3], which includes a working unicore32 linux kernel
> in its linux repository [4], in branch unicore32-working. This branch
> includes a working unicore32 qemu configuration. It also includes
> a critical patch which is not available in the upstream kernel.

Yes. And these patches need to be reviewed and reconsidered.
I'll try to do that in this month.

> 
> unicore32: Add ocd console and qemu-defconfig to support qemu simulator
>   This patch adds a primitive OCD console to communicate with qemu.
>   The same code is already used for early console support.

Do you mean there's the same/similar code in QEMU.

> 
> With this patch added, and with qemu_defconfig as provided by the same patch,
> it is possible to build and load a unicore32 image in qemu using the following
> qemu command line.
> 
> qemu-system-unicore32 -curses -M puv3 -m 512 -kernel 
> arch/unicore32/boot/zImage
> 
> Caveats:
> - The use of -nographic instead of -curses causes a qemu crash
Yes, since qemu curses code was modified to meet the simple OCD console 
requirement.

> - The qemu emulation only accepts a built-in initramfs.
Yes, github version only support built-in initramfs.
NFS+LFS could be also supported, and puv3-pci sim should be added at first.

> - The only working image is arch/unicore32/boot/zImage.
>   All other variants, arch/unicore32/boot/Image and vmlinux, cause a crash.
>   The same (or a similar) crash is also seen if I don't provide a built-in
>   kernel command line and try to load zImage.
Sorry for that. That should be fixed.

> - There is no networking. There is another patch in the github linux
>   respository [4] which is not available upstream. The driver was submitted
>   for integration back in 2011 [5] but it was never accepted or merged.
Yes, exactly.
Thanks Guenter.

> 
> 
> [1] http://mprc.pku.edu.cn/~guanxuetao/linux/
> [2] https://lkml.org/lkml/2014/8/31/86
> [3] https://github.com/gxt
> [4] git://github.com/gxt/linux.git
> [5] https://lkml.org/lkml/2011/5/27/17

--
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] mm: page_alloc: Default to node-ordering on 64-bit NUMA machines

[Kamezawa Hiroyuki]

(2014/09/02 22:51), Johannes Weiner wrote:

On Mon, Sep 01, 2014 at 01:55:51PM +0100, Mel Gorman wrote:

Zones are allocated by the page allocator in either node or zone order.
Node ordering is preferred in terms of locality and is applied automatically
in one of three cases.

   1. If a node has only low memory

   2. If DMA/DMA32 is a high percentage of memory

   3. If low memory on a single node is greater than 70% of the node size

Otherwise zone ordering is used to preserve low memory. Unfortunately
a consequence of this is that a machine with balanced NUMA nodes will
experience different performance characteristics depending on which node
they happen to start from.

The point of zone ordering is to protect lower nodes for devices that require
DMA/DMA32 memory. When NUMA was first introduced, this was critical as 32-bit
NUMA machines commonly suffered from low memory exhaustion problems. On
64-bit machines the primary concern is devices that are 32-bit only which
is less severe than the low memory exhaustion problem on 32-bit NUMA. It
seems there are really few devices that depends on it.

AGP -- I assume this is getting more rare but even then I think the allocations
happen early in boot time where lowmem pressure is less of a problem

DRM -- If the device is 32-bit only then there may be low pressure. I didn't
evaluate these in detail but it looks like some of these are mobile
graphics card. Not many NUMA laptops out there. DRM folk should know
better though.

Some TV cards -- Much demand for 32-bit capable TV cards on NUMA machines?

B43 wireless card -- again not really a NUMA thing.

I cannot find a good reason to incur a performance penalty on all 64-bit NUMA
machines in case someone throws a brain damanged TV or graphics card in there.
This patch defaults to node-ordering on 64-bit NUMA machines. I was tempted
to make it default everywhere but I understand that some embedded arches may
be using 32-bit NUMA where I cannot predict the consequences.


This patch is a step in the right direction, but I'm not too fond of
further fragmenting this code and where it applies, while leaving all
the complexity from the heuristics and the zonelist building in, just
on spec.  Could we at least remove the heuristics too?  If anybody is
affected by this, they can always override the default on the cmdline.


I'm okay with removing heuristics. There were a request to add "automatic 
detection"
at the time this feature was developped. But I'm not sure whether the logic is
still required. i.e. at that age, node-0 memory was small and default node order
can cause OOM easily.

Thanks,
-Kame

--
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 6/6] mm: page_alloc: Reduce cost of the fair zone allocation policy

[Johannes Weiner]

On Mon, Aug 11, 2014 at 02:34:05PM +0200, Vlastimil Babka wrote:
> On 08/11/2014 02:12 PM, Mel Gorman wrote:
> >On Fri, Aug 08, 2014 at 05:27:15PM +0200, Vlastimil Babka wrote:
> >>On 07/09/2014 10:13 AM, Mel Gorman wrote:
> >>>--- a/mm/page_alloc.c
> >>>+++ b/mm/page_alloc.c
> >>>@@ -1604,6 +1604,9 @@ again:
> >>>   }
> >>>
> >>>   __mod_zone_page_state(zone, NR_ALLOC_BATCH, -(1 << order));
> >>
> >>This can underflow zero, right?
> >>
> >
> >Yes, because of per-cpu accounting drift.
> 
> I meant mainly because of order > 0.
> 
> >>>+  if (zone_page_state(zone, NR_ALLOC_BATCH) == 0 &&
> >>
> >>AFAICS, zone_page_state will correct negative values to zero only for
> >>CONFIG_SMP. Won't this check be broken on !CONFIG_SMP?
> >>
> >
> >On !CONFIG_SMP how can there be per-cpu accounting drift that would make
> >that counter negative?
> 
> Well original code used "if (zone_page_state(zone, NR_ALLOC_BATCH) <= 0)"
> elsewhere, that you are replacing with zone_is_fair_depleted check. I
> assumed it's because it can get negative due to order > 0. I might have not
> looked thoroughly enough but it seems to me there's nothing that would
> prevent it, such as skipping a zone because its remaining batch is lower
> than 1 << order.
> So I think the check should be "<= 0" to be safe.

Any updates on this?

The counter can definitely underflow on !CONFIG_SMP, and then the flag
gets out of sync with the actual batch state.  I'd still prefer just
removing this flag again; it's extra complexity and error prone (case
in point) while the upsides are not even measurable in real life.

---

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 318df7051850..0bd77f730b38 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -534,7 +534,6 @@ typedef enum {
ZONE_WRITEBACK, /* reclaim scanning has recently found
 * many pages under writeback
 */
-   ZONE_FAIR_DEPLETED, /* fair zone policy batch depleted */
 } zone_flags_t;
 
 static inline void zone_set_flag(struct zone *zone, zone_flags_t flag)
@@ -572,11 +571,6 @@ static inline int zone_is_reclaim_locked(const struct zone 
*zone)
return test_bit(ZONE_RECLAIM_LOCKED, >flags);
 }
 
-static inline int zone_is_fair_depleted(const struct zone *zone)
-{
-   return test_bit(ZONE_FAIR_DEPLETED, >flags);
-}
-
 static inline int zone_is_oom_locked(const struct zone *zone)
 {
return test_bit(ZONE_OOM_LOCKED, >flags);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 18cee0d4c8a2..d913809a328f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1612,9 +1612,6 @@ again:
}
 
__mod_zone_page_state(zone, NR_ALLOC_BATCH, -(1 << order));
-   if (zone_page_state(zone, NR_ALLOC_BATCH) == 0 &&
-   !zone_is_fair_depleted(zone))
-   zone_set_flag(zone, ZONE_FAIR_DEPLETED);
 
__count_zone_vm_events(PGALLOC, zone, 1 << order);
zone_statistics(preferred_zone, zone, gfp_flags);
@@ -1934,7 +1931,6 @@ static void reset_alloc_batches(struct zone 
*preferred_zone)
mod_zone_page_state(zone, NR_ALLOC_BATCH,
high_wmark_pages(zone) - low_wmark_pages(zone) -
atomic_long_read(>vm_stat[NR_ALLOC_BATCH]));
-   zone_clear_flag(zone, ZONE_FAIR_DEPLETED);
} while (zone++ != preferred_zone);
 }
 
@@ -1985,7 +1981,7 @@ zonelist_scan:
if (alloc_flags & ALLOC_FAIR) {
if (!zone_local(preferred_zone, zone))
break;
-   if (zone_is_fair_depleted(zone)) {
+   if (zone_page_state(zone, NR_ALLOC_BATCH) <= 0) {
nr_fair_skipped++;
continue;
}
--
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] Next branch: authgss: authgss.c: Fix warnings for uninitizlized variable expire

[Boaz Harrosh]

On 09/02/2014 04:21 PM, Bruce Fields wrote:
> 
> You'd rather avoid sprinkling that all over, though.  If nothing else it
> increases the chances you'll suppress a legimate warning some day.
> 

But this is exactly why it was created.

If you do the "= 0" then it is gone forever. If you have missed a legitimate
needed assignment, it will be missed as well.

But if you do the uninitialized_var() dance then there is a make option that 
turns
it off and every once in a while people do a make with it to see if it still
holds.

The diff between foo = 0; and uninitialized_var(foo) is that the programmer is
communicating to his friends that:
"I have encountered a bogus compiler, this is falsely initialized"

As opposed to =0 the compiler bug is covered up and forgotten

> And unless I'm missing something this one really does look like an
> unambiguous compiler bug.
> 

Right! so that is how you specify this in code at Linux: uninitialized_var(foo);

Putting =0 is way way worse, because it will never be revised and specially
not automatically with a make switch.

And leaving the warning on is even worse because two three of these and people
start to ignore warnings.

> --b.
> 

uninitialized_var was made to be a friend not an enemy, in the face of real
ugliness it is the best we can do. And that is what it should communicate to
everyone. Why has it become everyone's favorite blasphemy I do not know.

Cheers
Boaz

--
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 v11 17/19] serial: asc: Adopt readl_/writel_relaxed()

[Maxime Coquelin]

Hi Daniel,

On 09/02/2014 03:00 PM, Daniel Thompson wrote:

The architectures where this peripheral exists (ARM and SH) have expensive
implementations of writel(), reliant on spin locks and explicit L2 cache
management. These architectures provide a cheaper writel_relaxed() which
is much better suited to peripherals that do not perform DMA. The
situation with readl()/readl_relaxed()is similar although less acute.

This driver does not use DMA and will be more power efficient and more
robust (due to absense of spin locks during console I/O) if it uses the
relaxed variants.

This change means the driver is no longer portable and therefore no
longer suitable for compile testing.

Signed-off-by: Daniel Thompson 
Cc: Srinivas Kandagatla 
Cc: Maxime Coquelin 
Cc: Patrice Chotard 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: ker...@stlinux.com
Cc: linux-ser...@vger.kernel.org
---
  drivers/tty/serial/Kconfig  | 2 +-
  drivers/tty/serial/st-asc.c | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)




You can add my:
Acked-by: Maxime Coquelin 

thanks!
Maxime

--
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] apf27dev: add max1027 in the dts

[Shawn Guo]

On Mon, Sep 01, 2014 at 08:44:32PM +0200, Philippe Reynes wrote:
> 
> Signed-off-by: Philippe Reynes 

Added "ARM: dts: " as the patch subject prefix, and applied the patch.

Shawn

> ---
>  arch/arm/boot/dts/imx27-apf27dev.dts |   17 +
>  1 files changed, 17 insertions(+), 0 deletions(-)
> 
> Changelog:
> v4: (thanks Shawn Guo for the feedback)
> - put max1027 pinctl in the right place
> - use 0x0 instead of 0
> 
> v3: (thanks Alexander Shiyan for the feedback)
> - add datasheet pin name as comment
> 
> v2: (thanks Alexander Shiyan for the feedback)
> - spi mode 0 is the default so no need to explicitly define it
> 
> diff --git a/arch/arm/boot/dts/imx27-apf27dev.dts 
> b/arch/arm/boot/dts/imx27-apf27dev.dts
> index b982309..bba3f41 100644
> --- a/arch/arm/boot/dts/imx27-apf27dev.dts
> +++ b/arch/arm/boot/dts/imx27-apf27dev.dts
> @@ -82,6 +82,16 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <_cspi1 _cspi1_cs>;
>   status = "okay";
> +
> + adc@0 {
> + compatible = "maxim,max1027";
> + reg = <0>;
> + interrupt-parent = <>;
> + interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_max1027>;
> + spi-max-frequency = <1000>;
> + };
>  };
>  
>   {
> @@ -210,6 +220,13 @@
>   >;
>   };
>  
> + pinctrl_max1027: max1027 {
> +  fsl,pins = <
> +  MX27_PAD_UART1_CTS__GPIO5_14 0x0 /* CNVST */
> +  MX27_PAD_UART1_RTS__GPIO5_15 0x0 /* EOC */
> + >;
> + };
> +
>   pinctrl_pwm: pwmgrp {
>   fsl,pins = <
>   MX27_PAD_PWMO__PWMO 0x0
> -- 
> 1.7.4.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] mm: page_alloc: Default to node-ordering on 64-bit NUMA machines

[Johannes Weiner]

On Mon, Sep 01, 2014 at 01:55:51PM +0100, Mel Gorman wrote:
> Zones are allocated by the page allocator in either node or zone order.
> Node ordering is preferred in terms of locality and is applied automatically
> in one of three cases.
> 
>   1. If a node has only low memory
> 
>   2. If DMA/DMA32 is a high percentage of memory
> 
>   3. If low memory on a single node is greater than 70% of the node size
> 
> Otherwise zone ordering is used to preserve low memory. Unfortunately
> a consequence of this is that a machine with balanced NUMA nodes will
> experience different performance characteristics depending on which node
> they happen to start from.
> 
> The point of zone ordering is to protect lower nodes for devices that require
> DMA/DMA32 memory. When NUMA was first introduced, this was critical as 32-bit
> NUMA machines commonly suffered from low memory exhaustion problems. On
> 64-bit machines the primary concern is devices that are 32-bit only which
> is less severe than the low memory exhaustion problem on 32-bit NUMA. It
> seems there are really few devices that depends on it.
> 
> AGP -- I assume this is getting more rare but even then I think the 
> allocations
>   happen early in boot time where lowmem pressure is less of a problem
> 
> DRM -- If the device is 32-bit only then there may be low pressure. I didn't
>   evaluate these in detail but it looks like some of these are mobile
>   graphics card. Not many NUMA laptops out there. DRM folk should know
>   better though.
> 
> Some TV cards -- Much demand for 32-bit capable TV cards on NUMA machines?
> 
> B43 wireless card -- again not really a NUMA thing.
> 
> I cannot find a good reason to incur a performance penalty on all 64-bit NUMA
> machines in case someone throws a brain damanged TV or graphics card in there.
> This patch defaults to node-ordering on 64-bit NUMA machines. I was tempted
> to make it default everywhere but I understand that some embedded arches may
> be using 32-bit NUMA where I cannot predict the consequences.

This patch is a step in the right direction, but I'm not too fond of
further fragmenting this code and where it applies, while leaving all
the complexity from the heuristics and the zonelist building in, just
on spec.  Could we at least remove the heuristics too?  If anybody is
affected by this, they can always override the default on the cmdline.
--
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 v5 3/3] kprobes: arm: enable OPTPROBES for ARM 32

[Jon Medhurst (Tixy)]

I gave the patches a quick test and in doing so found a bug which stops
any probes actually being optimised, and the same bug should affect X86,
see comment below...

On Wed, 2014-08-27 at 21:02 +0800, Wang Nan wrote:
[...]
> +int arch_prepare_optimized_kprobe(struct optimized_kprobe *op)
> +{
> + u8 *buf;
> + unsigned long rel_chk;
> + unsigned long val;
> +
> + if (!can_optimize(op))
> + return -EILSEQ;
> +
> + op->optinsn.insn = get_optinsn_slot();
> + if (!op->optinsn.insn)
> + return -ENOMEM;
> +
> + /*
> +  * Verify if the address gap is in 32MiB range, because this uses
> +  * a relative jump.
> +  *
> +  * kprobe opt use a 'b' instruction to branch to optinsn.insn.
> +  * According to ARM manual, branch instruction is:
> +  *
> +  *   31  28 27   24 23 0
> +  *  +--+---+---+---+---++
> +  *  | cond | 1 | 0 | 1 | 0 |  imm24 |
> +  *  +--+---+---+---+---++
> +  *
> +  * imm24 is a signed 24 bits integer. The real branch offset is computed
> +  * by: imm32 = SignExtend(imm24:'00', 32);
> +  *
> +  * So the maximum forward branch should be:
> +  *   (0x007f << 2) = 0x01fc =  0x1fc
> +  * The maximum backword branch should be:
> +  *   (0xff80 << 2) = 0xfe00 = -0x200
> +  *
> +  * We can simply check (rel & 0xfe03):
> +  *  if rel is positive, (rel & 0xfe00) shoule be 0
> +  *  if rel is negitive, (rel & 0xfe00) should be 0xfe00
> +  *  the last '3' is used for alignment checking.
> +  */
> + rel_chk = (unsigned long)((long)op->optinsn.insn -
> + (long)op->kp.addr + 8) & 0xfe03;

This check always fails because op->kp.addr is zero. Debugging this I
found that this function is called from alloc_aggr_kprobe() and that
copies the real kprobe into op->kp using copy_kprobe(), which doesn't
actually copy the 'addr' value...

static inline void copy_kprobe(struct kprobe *ap, struct kprobe *p)
{
memcpy(>opcode, >opcode, sizeof(kprobe_opcode_t));
memcpy(>ainsn, >ainsn, sizeof(struct 
arch_specific_insn));
}

Thing is, the new ARM code is a close copy of the existing X86 version
so that would also suffer the same problem of kp.addr always being zero.
So either I've miss understood something or this is fundamental bug no
one has noticed before.

Throwing in 'p->addr = ap->addr' into the copy_kprobe function fixed the
behaviour arch_prepare_optimized_kprobe.

I was testing this by running the kprobes tests
(CONFIG_ARM_KPROBES_TEST=y) and putting a few printk's in strategic
places in kprobes-opt.c to check to see what code paths got executed,
which is how I discovered the problem.

Two things to note when running kprobes tests...

1. On SMP systems it's very slow because of kprobe's use of stop_machine
for applying and removing probes, this forces the system to idle and
wait for the next scheduler tick for each probe change.

2. It's a good idea to enable VERBOSE in kprobes-test.h to get output
for each test case instruction, this reassures you things are
progressing and if things explode lets you know what instruction type
triggered it.

-- 
Tixy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL 4/4] at91: dt for 3.18 #2

[Nicolas Ferre]

On 01/09/2014 19:38, Nicolas Ferre :
> Arnd, Olof, Kevin,
> 
> A little bit more material for the DT branch. I didn't want to the one I've
> just sent you because this material is not related to the big cleanup 
> addressed
> by previous 3 pull-requests.
> It is very basic and simple DT updates and a use of phy fixup infrastructure
> that is now present in phy subsystem.
> 
> Thanks, best regards,
> 
> The following changes since commit 464d6e18639c4347dafd8dbcee270674dd3d8fba:
> 
>   Merge tag 'at91-dt-for-3.17' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux (2014-08-19 
> 16:04:10 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-dt2

FYI, I've just pushed a branch to show the conflict resolution while
merging this tag with the tree previous pull-requests:

https://github.com/at91linux/linux-at91/commits/at91-3.18-resolved

or:

git://github.com/at91linux/linux-at91.git at91-3.18-resolved

Best regards,

> for you to fetch changes up to 5f8157309624929e05ece846d3ca8a3a64988378:
> 
>   ARM: at91: remove phy fixup for sama5d3xek boards (2014-09-01 19:30:44 
> +0200)
> 
> 
> Second batch of AT91 DT patches for 3.18:
> - 2 little fixes for at91sam9x5 and at91sam9n12ek
> - removal of a board specific hook for sama5d3xek about phy fixup
>   replaced with proper DT property definition.
> 
> 
> Alexandre Belloni (1):
>   ARM: at91/dt: sam9x5: fix ADC compatible string
> 
> Bo Shen (1):
>   ARM: at91/dt: sam9n12ek: ohci: add port and vbus property
> 
> Boris BREZILLON (2):
>   ARM: at91/dt: describe rgmii ethernet phy connected to sama5d3xek boards
>   ARM: at91: remove phy fixup for sama5d3xek boards
> 
>  arch/arm/boot/dts/at91sam9n12ek.dts |  2 ++
>  arch/arm/boot/dts/at91sam9x5.dtsi   |  2 +-
>  arch/arm/boot/dts/sama5d3xcm.dtsi   | 30 ++
>  arch/arm/mach-at91/board-dt-sama5.c | 22 --
>  4 files changed, 33 insertions(+), 23 deletions(-)
> 


-- 
Nicolas Ferre
--
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: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver

[Arnd Bergmann]

On Tuesday 02 September 2014 08:20:53 Rob Herring wrote:
> >>
> >> This alone is not okay. There is no such implementation of hardware.
> >
> > But the SBSA explicitly allows this. I don't know of any vendor who just
> > implements the subset, but I've been told that this has been asked for.
> 
> To use baudrate as an example, that must be configurable somehow
> either with pl011 registers or in a vendor specific way. I suppose you
> could do an actual implementation with all those things hardcoded in
> the design, but that seems unlikely.

Why does the baudrate need to be configurable? I think it's completely
reasonable to specify a console port that has a fixed (as in the
OS must not care) rate, and that can be implemented either as a UART
with a programmable rate or as a set of registers that directly talks
to a remote system management device over whatever hardware protocol
they choose.

> >> The DT must specify the implementation such as pl011.
> >
> > If it is a full featured PL011: sure. Then we don't need this driver at
> > all and just use the SBSA UART spec as a guideline for our earlycon
> > implementation.
> > I will try to learn if there is someone actually implementing only the
> > subset.
> 
> I would have assumed you knew someone is. Otherwise, I don't really
> think anything should be implemented at this point. Perhaps adding
> SBSA uart as an explicit earlycon option would be worthwhile. Also, we
> should consider using ttySx instead of ttyAMAx for SBSA compliant
> systems (including ones with pl011).

What about systems that have both a SBSA debug port and a 8250
compatible UART? That sounds like a very realistic hardware design
choice for someone coming from an older x86/powerpc/mips/... chip
that has 8250 and adds the extra port for SBSA compliance.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] ARM: dts: Add Peach Pit dts entry for Atmel touchpad

[Nick Dyer]

On 27/08/14 15:22, Javier Martinez Canillas wrote:
>>> If there was a BTN_NONE or KEY_UNUSED it would had been better but I think
>>> that making a distinction between these two cases (reserved pin vs GPIO
>>> available but not used) is useful.
>>
>> Maybe Nick can comment here.

Yes, this is probably useful to document. However, I fear that it's not
going to be obvious what the distinction is to someone who doesn't have the
Atmel docs. Perhaps it would be clearer to just do something like:

linux,gpio-keymap = ;   /* GPIO3 */

If you omit any trailing KEY_RESERVED values it doesn't affect anything.

I was also going to suggest that you put something like "/* Atmel mXT224SL
*/" in your .dts file so it's clear what version of the maXTouch device you
are configuring.
--
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: [Linaro-acpi] [RFC PATCH for Juno 1/2] net: smsc911x add support for probing from ACPI

[Arnd Bergmann]

On Tuesday 02 September 2014 14:26:52 Catalin Marinas wrote:
> 
> Not much at the KS, I think it will need to be followed up on lkml
> (https://lkml.org/lkml/2014/8/17/10 is the last I'm aware of, not sure
> about any updates in the meantime).
> 
> While the above gets sorted, what's the position from an ARM
> perspective (and covered by Documentation/arm64/arm-acpi.txt)? I think
> the "Device Enumeration" section in this document is fine, it's just the
> kernel infrastructure missing.
> 
> Alternatively, you can say _DSD is not allowed (yet?) but I don't
> particularly like basing the configuration on acpi_device_id like in
> this patch. Which would leave us with ignoring any SoC containing
> devices that require such specific configuration.

The way I recall the discussion, most people were on one extreme
side of the discussion or the other:

a) We should use _DSD for ARM64 servers to maximize code reuse with
DT-enabled drivers, work around the slow UEFI standardization process,
remain in control of the actual bindings, and avoid the need for
endless per-ID platform-data definitions in drivers.

b) We should never use _DSD at all, since doing that would have no
advantage over using DT directly, and we should force every device
manufacturer to specify their bindings in an official ACPI document
to prevent random incompatible bindings from being established.
Any device that shows up in servers should not need arbitrary detailed
properties anyway, as the details are supposed to be hidden in AML.

I can understand the reasons for both approaches, and I find it hard
to say either one is invalid. However, the worst possible outcome in
my opinion would be having to support a mix of the two.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [STLinux Kernel] [PATCH v11 17/19] serial: asc: Adopt readl_/writel_relaxed()

[Peter Griffin]

On Tue, 02 Sep 2014, Daniel Thompson wrote:

> The architectures where this peripheral exists (ARM and SH) have expensive
> implementations of writel(), reliant on spin locks and explicit L2 cache
> management. These architectures provide a cheaper writel_relaxed() which
> is much better suited to peripherals that do not perform DMA. The
> situation with readl()/readl_relaxed()is similar although less acute.
> 
> This driver does not use DMA and will be more power efficient and more
> robust (due to absense of spin locks during console I/O) if it uses the
> relaxed variants.
> 
> This change means the driver is no longer portable and therefore no
> longer suitable for compile testing.
> 
> Signed-off-by: Daniel Thompson 
> Cc: Srinivas Kandagatla 
> Cc: Maxime Coquelin 
> Cc: Patrice Chotard 
> Cc: Greg Kroah-Hartman 
> Cc: Jiri Slaby 
> Cc: ker...@stlinux.com
> Cc: linux-ser...@vger.kernel.org

Acked-by: Peter Griffin 

--
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: nohz fail (was: perf related boot hang.)

[Dave Jones]

On Mon, Sep 01, 2014 at 10:14:31PM +0200, Frederic Weisbecker wrote:
 > On Fri, Aug 22, 2014 at 10:00:09AM -0400, Dave Jones wrote:
 > > On Fri, Aug 22, 2014 at 08:01:48AM +0200, Catalin Iacob wrote:
 > >  > On Thu, Aug 21, 2014 at 4:56 PM, Frederic Weisbecker 
 > >  wrote:
 > >  > > Can you please test the series I just posted: "[RFC PATCH 0/9] nohz:
 > >  > > Nohz full kick fixes"?
 > >  > 
 > >  > Before applying the series I tried one more Firefox build which
 > >  > triggered the panic after less than 5 minutes.
 > >  > 
 > >  > After applying the series I did 2 full builds (around 60 minutes in
 > >  > total) with no problem.
 > > 
 > > Seems to be working fine here too after fuzzing for 17 hours so far.
 > 
 > Thanks a lot for testing this guys!
 > 
 > I'll send "nohz: Restore NMI safe local irq work for local nohz kick"
 > as a fix for 3.17 and the rest will have to wait for 3.18 as it's a 
 > complicated
 > fix for a long standing bug.
 > 
 > Can I apply your Tested-by from you both?

Sure, I haven't seen any recurrance of this since applying your patches.

Dave


--
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 01/12] Staging: rtl8821ae: hal_bt_coexist: fix commenting style

[Dan Carpenter]

On Tue, Sep 02, 2014 at 07:22:12AM -0400, An Tuan Ha wrote:
> I see, thanks, I will fix it, I was just worried about the subjects
> being too long so I just stuck with the same subject; is there a
> character limit on how long the subject line should be? Or as long as
> it's reasonable, it'll be fine?

Reasonable is fine.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] fat: Simplify calc_fat_clusters code

[Seunghun Lee]

Code for fat12 and fat16/32 can be merged to one.

Signed-off-by: Seunghun Lee 
---
 fs/fat/inode.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 756aead..6992dea 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -1307,12 +1307,9 @@ static unsigned long calc_fat_clusters(struct 
super_block *sb)
struct msdos_sb_info *sbi = MSDOS_SB(sb);
 
/* Divide first to avoid overflow */
-   if (sbi->fat_bits != 12) {
-   unsigned long ent_per_sec = sb->s_blocksize * 8 / sbi->fat_bits;
-   return ent_per_sec * sbi->fat_length;
-   }
+   unsigned long ent_per_sec = sb->s_blocksize * 8 / sbi->fat_bits;
 
-   return sbi->fat_length * sb->s_blocksize * 8 / sbi->fat_bits;
+   return ent_per_sec * sbi->fat_length;
 }
 
 static bool fat_bpb_is_zero(struct fat_boot_sector *b)
-- 
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: [RFC PATCH for Juno 1/2] net: smsc911x add support for probing from ACPI

[Catalin Marinas]

On Mon, Sep 01, 2014 at 06:32:45PM +0100, Graeme Gregory wrote:
> On Mon, Sep 01, 2014 at 07:11:44PM +0200, Arnd Bergmann wrote:
> > On Monday 01 September 2014 18:04:47 Catalin Marinas wrote:
> > > On Mon, Sep 01, 2014 at 04:06:00PM +0100, Hanjun Guo wrote:
> > > > +#ifdef CONFIG_ACPI
> > > > +/* Configure some sensible defaults for ACPI mode */
> > > > +static int smsc911x_probe_config_acpi(struct smsc911x_platform_config 
> > > > *config,
> > > > + acpi_handle *ahandle)
> > > > +{
> > > > + if (!ahandle)
> > > > + return -ENOSYS;
> > > > +
> > > > + config->phy_interface = PHY_INTERFACE_MODE_MII;
> > > > +
> > > > + config->flags |= SMSC911X_USE_32BIT;
> > > > +
> > > > + config->irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH;
> > > > +
> > > > + config->irq_type = SMSC911X_IRQ_TYPE_PUSH_PULL;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +#else
> > > 
> > > I don't like this and it shows issues we have with ACPI on certain ARM
> > > platforms. You hard-code these values to match the Juno platform. What
> > > if we get another SoC which has different configuration here? For DT, we
> > > have the smsc911x_probe_config_dt() which reads the relevant information
> > > from DT. I think this kind of configuration would be more suitable as
> > > _DSD properties and sharing the similar names with DT (but we go back to
> > > the question about who's in charge of the _DSD properties).
> > 
> > Good point, I totally missed that.
> > 
> > There is of course the possibility to set those values based on the
> > acpi_device_id, but that is exactly the part that _DSD is trying to
> > avoid.
> 
> This will of course most likely be replaced by _DSD values. I just
> hardcoded for now as _DSD is not yet in the kernel and issues around
> maintenance of bindings are not solved (unless this happened at KS where
> I was not present).

Not much at the KS, I think it will need to be followed up on lkml
(https://lkml.org/lkml/2014/8/17/10 is the last I'm aware of, not sure
about any updates in the meantime).

While the above gets sorted, what's the position from an ARM
perspective (and covered by Documentation/arm64/arm-acpi.txt)? I think
the "Device Enumeration" section in this document is fine, it's just the
kernel infrastructure missing.

Alternatively, you can say _DSD is not allowed (yet?) but I don't
particularly like basing the configuration on acpi_device_id like in
this patch. Which would leave us with ignoring any SoC containing
devices that require such specific configuration.

-- 
Catalin
--
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 2/3] ARM: dts: exynos3250: Add CMU node for DMC domain clocks

[Krzysztof Kozlowski]

Add CMU (Clock Management Unit) node for DMC (Dynamic Memory Controller)
domain clocks on Exynos3250.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos3250.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 429a6c6cfcf9..8c3a9cc0a4d1 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -163,6 +163,12 @@
#clock-cells = <1>;
};
 
+   cmu_dmc: clock-controller@105C {
+   compatible = "samsung,exynos3250-cmu-dmc";
+   reg = <0x105C 0x2000>;
+   #clock-cells = <1>;
+   };
+
rtc: rtc@1007 {
compatible = "samsung,exynos3250-rtc";
reg = <0x1007 0x100>;
-- 
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 3/3] dt-bindings: clk: samsung: Document the DMC domain of Exynos3250 CMU

[Krzysztof Kozlowski]

Document the new compatible for clock in DMC (Dynamic Memory
Controller) domain of Exynos3250 Clock Management Unit (CMU).

Signed-off-by: Krzysztof Kozlowski 
---
 Documentation/devicetree/bindings/clock/exynos3250-clock.txt | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
index aadc9c59e2d1..f57d9dd9ea85 100644
--- a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
@@ -7,6 +7,8 @@ Required Properties:
 
 - compatible: should be one of the following.
   - "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC.
+  - "samsung,exynos3250-cmu-dmc" - controller compatible with
+Exynos3250 SoC for Dynamic Memory Controller domain.
 
 - reg: physical base address of the controller and length of memory mapped
   region.
@@ -20,7 +22,7 @@ All available clocks are defined as preprocessor macros in
 dt-bindings/clock/exynos3250.h header and can be used in device
 tree sources.
 
-Example 1: An example of a clock controller node is listed below.
+Example 1: Examples of clock controller nodes are listed below.
 
cmu: clock-controller@1003 {
compatible = "samsung,exynos3250-cmu";
@@ -28,6 +30,12 @@ Example 1: An example of a clock controller node is listed 
below.
#clock-cells = <1>;
};
 
+   cmu_dmc: clock-controller@105C {
+   compatible = "samsung,exynos3250-cmu-dmc";
+   reg = <0x105C 0x2000>;
+   #clock-cells = <1>;
+   };
+
 Example 2: 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.
-- 
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] Next branch: authgss: authgss.c: Fix warnings for uninitizlized variable expire

[Bruce Fields]

On Tue, Sep 02, 2014 at 01:52:15PM +0300, Boaz Harrosh wrote:
> On 09/01/2014 04:50 PM, Trond Myklebust wrote:
> > On Mon, Sep 1, 2014 at 7:32 AM, Shakil A Khan  wrote:
> >> Signed-off-by : Shakil A Khan 
> >> ---
> >>  net/sunrpc/auth_gss/auth_gss.c |2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/net/sunrpc/auth_gss/auth_gss.c 
> >> b/net/sunrpc/auth_gss/auth_gss.c
> >> index afb292c..bea0951 100644
> >> --- a/net/sunrpc/auth_gss/auth_gss.c
> >> +++ b/net/sunrpc/auth_gss/auth_gss.c
> >> @@ -1387,7 +1387,7 @@ gss_key_timeout(struct rpc_cred *rc)
> >> struct gss_cred *gss_cred = container_of(rc, struct gss_cred, 
> >> gc_base);
> >> struct gss_cl_ctx *ctx;
> >> unsigned long now = jiffies;
> >> -   unsigned long expire;
> >> +   unsigned long expire = 0;
> >>
> >> rcu_read_lock();
> >> ctx = rcu_dereference(gss_cred->gc_ctx);
> >> --
> >> 1.7.1
> > 
> > That would be a compiler bug, not a kernel bug. The kernel code is
> > perfectly correct as it stands, and will never access the
> > uninitialised variable.
> > 
> 
> Than you will need the infamous uninitialised_var()

You'd rather avoid sprinkling that all over, though.  If nothing else it
increases the chances you'll suppress a legimate warning some day.

And unless I'm missing something this one really does look like an
unambiguous compiler bug.

--b.

> 
> diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
> index afb292c..bea0951 100644
> --- a/net/sunrpc/auth_gss/auth_gss.c
> +++ b/net/sunrpc/auth_gss/auth_gss.c
> @@ -1387,7 +1387,7 @@ gss_key_timeout(struct rpc_cred *rc)
>   struct gss_cred *gss_cred = container_of(rc, struct gss_cred, gc_base);
>   struct gss_cl_ctx *ctx;
>   unsigned long now = jiffies;
> - unsigned long expire;
> + unsigned long uninitialised_var(expire);
>  
>   rcu_read_lock();
>   ctx = rcu_dereference(gss_cred->gc_ctx);
> 
> Cheers
> Boaz
--
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 1/3] clk: samsung: exynos3250: Register DMC clk provider

[Krzysztof Kozlowski]

Add clock provider for clocks in DMC domain including EPLL and BPLL. The
DMC clocks are necessary for Exynos3 devfreq driver.

The DMC clock domain uses different address space (0x105C) than
standard clock domain (0x1003 - 0x1005). The difference is huge
enough to add new DT node for the clock provider, rather than extending
existing address space.

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
=
1. Fix overwritteing main clock provider reg_base with DMC clock domain
   reg_basr. This leads to OOPS in suspend.
---
 drivers/clk/samsung/clk-exynos3250.c   | 195 +
 include/dt-bindings/clock/exynos3250.h |  27 +
 2 files changed, 222 insertions(+)

diff --git a/drivers/clk/samsung/clk-exynos3250.c 
b/drivers/clk/samsung/clk-exynos3250.c
index dc85f8e7a2d7..6840dc71c72b 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -110,7 +110,14 @@ enum exynos3250_plls {
nr_plls
 };
 
+/* list of PLLs in DMC block to be registered */
+enum exynos3250_dmc_plls {
+   bpll, epll,
+   nr_dmc_plls
+};
+
 static void __iomem *reg_base;
+static void __iomem *dmc_reg_base;
 
 /*
  * Support for CMU save/restore across system suspends
@@ -724,6 +731,25 @@ static struct samsung_pll_rate_table 
exynos3250_pll_rates[] = {
{ /* sentinel */ }
 };
 
+/* EPLL */
+static struct samsung_pll_rate_table exynos3250_epll_rates[] = {
+   PLL_36XX_RATE(8, 200, 3, 1, 0),
+   PLL_36XX_RATE(28800,  96, 2, 2, 0),
+   PLL_36XX_RATE(19200, 128, 2, 3, 0),
+   PLL_36XX_RATE(14400,  96, 2, 3, 0),
+   PLL_36XX_RATE( 9600, 128, 2, 4, 0),
+   PLL_36XX_RATE( 8400, 112, 2, 4, 0),
+   PLL_36XX_RATE( 8004, 106, 2, 4, 43691),
+   PLL_36XX_RATE( 73728000,  98, 2, 4, 19923),
+   PLL_36XX_RATE( 67737598, 270, 3, 5, 62285),
+   PLL_36XX_RATE( 65535999, 174, 2, 5, 49982),
+   PLL_36XX_RATE( 5000, 200, 3, 5, 0),
+   PLL_36XX_RATE( 49152002, 131, 2, 5,  4719),
+   PLL_36XX_RATE( 4800, 128, 2, 5, 0),
+   PLL_36XX_RATE( 45158401, 180, 3, 5, 41524),
+   { /* sentinel */ }
+};
+
 /* VPLL */
 static struct samsung_pll_rate_table exynos3250_vpll_rates[] = {
PLL_36XX_RATE(6, 100, 2, 1, 0),
@@ -821,3 +847,172 @@ static void __init exynos3250_cmu_init(struct device_node 
*np)
samsung_clk_of_add_provider(np, ctx);
 }
 CLK_OF_DECLARE(exynos3250_cmu, "samsung,exynos3250-cmu", exynos3250_cmu_init);
+
+/*
+ * CMU DMC
+ */
+
+#define BPLL_LOCK  0x0118
+#define BPLL_CON0  0x0218
+#define BPLL_CON1  0x021c
+#define BPLL_CON2  0x0220
+#define SRC_DMC0x0300
+#define DIV_DMC1   0x0504
+#define GATE_BUS_DMC0  0x0700
+#define GATE_BUS_DMC1  0x0704
+#define GATE_BUS_DMC2  0x0708
+#define GATE_BUS_DMC3  0x070c
+#define GATE_SCLK_DMC  0x0800
+#define GATE_IP_DMC0   0x0900
+#define GATE_IP_DMC1   0x0904
+#define EPLL_LOCK  0x1110
+#define EPLL_CON0  0x1114
+#define EPLL_CON1  0x1118
+#define EPLL_CON2  0x111c
+#define SRC_EPLL   0x1120
+
+/*
+ * Support for CMU save/restore across system suspends
+ */
+#ifdef CONFIG_PM_SLEEP
+static struct samsung_clk_reg_dump *exynos3250_dmc_clk_regs;
+
+static unsigned long exynos3250_cmu_dmc_clk_regs[] __initdata = {
+   BPLL_LOCK,
+   BPLL_CON0,
+   BPLL_CON1,
+   BPLL_CON2,
+   SRC_DMC,
+   DIV_DMC1,
+   GATE_BUS_DMC0,
+   GATE_BUS_DMC1,
+   GATE_BUS_DMC2,
+   GATE_BUS_DMC3,
+   GATE_SCLK_DMC,
+   GATE_IP_DMC0,
+   GATE_IP_DMC1,
+   EPLL_LOCK,
+   EPLL_CON0,
+   EPLL_CON1,
+   EPLL_CON2,
+   SRC_EPLL,
+};
+
+static int exynos3250_dmc_clk_suspend(void)
+{
+   samsung_clk_save(dmc_reg_base, exynos3250_dmc_clk_regs,
+   ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+   return 0;
+}
+
+static void exynos3250_dmc_clk_resume(void)
+{
+   samsung_clk_restore(dmc_reg_base, exynos3250_dmc_clk_regs,
+   ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+}
+
+static struct syscore_ops exynos3250_dmc_clk_syscore_ops = {
+   .suspend = exynos3250_dmc_clk_suspend,
+   .resume = exynos3250_dmc_clk_resume,
+};
+
+static void exynos3250_dmc_clk_sleep_init(void)
+{
+   exynos3250_dmc_clk_regs =
+   samsung_clk_alloc_reg_dump(exynos3250_cmu_dmc_clk_regs,
+  ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+   if (!exynos3250_dmc_clk_regs) {
+   pr_warn("%s: Failed to allocate sleep save data\n", __func__);
+   goto err;
+   }
+
+   register_syscore_ops(_dmc_clk_syscore_ops);
+   return;
+err:
+   kfree(exynos3250_dmc_clk_regs);
+}
+#else
+static inline void 

Re: early microcode: how to disable at runtime?

[Henrique de Moraes Holschuh]

On Tue, 02 Sep 2014, Borislav Petkov wrote:
> > This can be a very big deal when things go wrong: it is hard for the
> > regular user to recover from an initramfs image that crashes the
> > system, and the early initramfs has no "disable" trigger.
> 
> This maybe is a serious problem but disabling microcode loading is not
> the proper solution. If the microcode in the initrd is corrupted, it
> should simply not get loaded and system should continue as much as it
> can - it *should* *not* be a requirement to disable the ucode loader in
> order to workaround corrupted initrds.

Things do go wrong in other ways, not just corrupt microcode data/initramfs
images.

This stuff runs too early.  It is easy to break, and annoying to debug.

> And frankly, I'm trying to imagine how a corrupted microcode in an
> initrd would ever fail the booting. So Henrique, if you have something
> which is *not* hypothetical, please say so. It needs to be fixed
> properly and not with disabling the ucode loader.

I am not worried about corrupted microcode, or even corrupted initramfs
images.  I am just worried about regular bugs introduced by a kernel update
causing systems to fail to reboot later.

I don't want to tell an user he has to use rescue media to get his system
back into working order when a kernel parameter would have been enough to
get it to boot.

Although, on the corrupted microcode topic, I have this very strong feeling
that at least the Intel driver would benefit from a careful audit on the
microcode container handling if we want to be sure it won't do stupid things
when fed specially crafted hostile data.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Sep 1

[Bartlomiej Zolnierkiewicz]

[ this time with the patch and right cc: list, sorry for the noise ]

Hi,

On Tuesday, September 02, 2014 12:07:28 AM Mark Brown wrote:
> Changes since 20140829:
> 
> The akpm-current gained a conflict against Linus' tree.
> 
> Non-merge commits (relative to Linus' tree): 2553
>  2686 files changed, 98625 insertions(+), 79475 deletions(-)
> 
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git .
> If you are tracking the linux-next tree using git, you should not use
> "git pull" to do so as that will try to merge the new linux-next release
> with the old one.  You should use "git fetch" and checkout or reset to
> the new master.
> 
> You can see which trees have been included by looking in the Next/Trees
> file in the source.  There are also quilt-import.log and merge.log files
> in the Next directory.  Between each merge, the tree was built with an
> allmodconfig for x86_64 and a multi_v7_defconfig for arm.
> 
> Below is a summary of the state of the merge.
> 
> I am currently merging 214 trees (counting Linus' and 30 trees of patches
> pending for Linus' tree).
> 
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
> 
> Status of Stephen's local build tests will be at
> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.

I need following patch to make it boot on ODROID U3 board
(ARM Exynos4412 SoC based).  next-20140825 was good, next-20140828
is bad (I haven't tried next-20140826 and next-20140827).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


From: Bartlomiej Zolnierkiewicz 
Subject: [RFC PATCH] irqchips: gic_get_percpu_base() fix

Commit 532d0d0690d1 ("irqchips: Replace __this_cpu_ptr uses")
incorrectly converted *__this_cpu_ptr() to raw_cpu_read() instead
of *raw_cpu_ptr().  Fix it.

Fixes following panic on ODROID U3 board (using ARM Exynos4412 SoC):

Unable to handle kernel NULL pointer dereference at virtual address 0004
pgd = c0004000
[0004] *pgd=
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc2-next-20140828-dirty #837
task: c05ece28 ti: c05e2000 task.ti: c05e2000
PC is at gic_init_bases+0x170/0x380
LR is at gic_init_bases+0x170/0x380
pc : []lr : []psr: 61d3
sp : c05e3f18  ip : 0004  fp : c05edd7c
r10: c05ea560  r9 : c05ea488  r8 : 0010
r7 : 4000  r6 : c05ea93c  r5 : c05ea93c  r4 : c05ea93c
r3 : 2a1a  r2 :   r1 : 0008  r0 : 
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 4000404a  DAC: 0015
Process swapper/0 (pid: 0, stack limit = 0xc05e2240)
Stack: (0xc05e3f18 to 0xc05e4000)
3f00:   c05e3f88 c040b2bc
3f20: c061c3b8  0004 c05e3f64  ea7a3b20 c05c5ff0 
3f40: f882 f881 c05de880 00200200 c05e3f88 c05b157c 4000 ea7a3b20
3f60: c061c3b8 4000 ea0027c0 ea002800 c05e3f80  00100100 c05b89c8
3f80: ea002800 ea002800 c05e3f88 c05e3f88 413fc090 c05c3f50  c0626600
3fa0: c05c3f60 eb7ff780 413fc090   c05a2e80 c05c3f50 c059e1c4
3fc0: 0001 c059ba24   c059b600   c05c3f60
3fe0: c06269d4 c05ea47c c05c3f5c c05edeac 4000406a 40008074  
[] (gic_init_bases) from [] (gic_of_init+0xb0/0x118)
[] (gic_of_init) from [] (of_irq_init+0x164/0x29c)
[] (of_irq_init) from [] (exynos_init_irq+0x8/0x50)
[] (exynos_init_irq) from [] (init_IRQ+0x24/0x74)
[] (init_IRQ) from [] (start_kernel+0x200/0x384)
[] (start_kernel) from [<40008074>] (0x40008074)
Code: e59f61d8 e5953594 e1a6 e12fff33 (e5907004) 
---[ end trace cb88537fdc8fa200 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task!

Signed-off-by: Bartlomiej Zolnierkiewicz 
Acked-by: Kyungmin Park 
Cc: nicolas.pi...@linaro.org
Cc: Russell King 
Cc: Christoph Lameter 
Cc: Tejun Heo 
---
I'm not sure that it is a correct fix but some other *__this_cpu_ptr()
usages were not converted to raw_cpu_read() but also to *raw_cpu_ptr()
(like arch_local_irqs_enabled() in arch/tile/include/asm/irqflags.h).

 drivers/irqchip/irq-gic.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/irqchip/irq-gic.c
===
--- a/drivers/irqchip/irq-gic.c 2014-09-02 14:03:41.026758653 +0200
+++ b/drivers/irqchip/irq-gic.c 2014-09-02 14:37:04.466811546 +0200
@@ -102,7 +102,7 @@ static struct gic_chip_data gic_data[MAX
 #ifdef CONFIG_GIC_NON_BANKED
 static void __iomem *gic_get_percpu_base(union gic_base *base)
 {
-   return raw_cpu_read(base->percpu_base);
+   return *raw_cpu_ptr(base->percpu_base);
 }
 
 static 

Re: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver

[Rob Herring]

On Tue, Sep 2, 2014 at 5:06 AM, Andre Przywara  wrote:
> Hi Rob,
>
> thanks for looking at this.
>
> On 02/09/14 04:06, Rob Herring wrote:
>> On Fri, Aug 29, 2014 at 11:13 AM, Andre Przywara  
>> wrote:
>>> The ARM Server Base System Architecture (SBSA) describes a generic
>>> UART which all compliant level 1 systems should implement. This is
>>> actually a PL011 subset, so a full PL011 implementation will satisfy
>>> this requirement.
>>> However if a system does not have a PL011, a very stripped down
>>> implementation complying to the SBSA defined specification will
>>> suffice. The Linux PL011 driver is not guaranteed to drive this
>>> limited device (and indeed the fast model implentation hangs the
>>> kernel if driven by the PL011 driver).
>>> So introduce a new driver just implementing the part specified by the
>>> SBSA (which lacks DMA, the modem control signals and many of the
>>> registers including baud rate control). This driver has been derived
>>> by the actual PL011 one, removing all unnecessary code.
>>>
>>> Signed-off-by: Andre Przywara 
>>> ---
>>>  .../devicetree/bindings/serial/arm_sbsa_uart.txt   |6 +
>>>  drivers/tty/serial/Kconfig |   28 +
>>>  drivers/tty/serial/Makefile|1 +
>>>  drivers/tty/serial/sbsa_uart.c |  793 
>>> 
>>>  include/uapi/linux/serial_core.h   |1 +
>>
>> Sorry, but I think this is all wrong. We've now just duplicated some
>> subset of the pl011 driver leaving out the parts like setting baudrate
>> which can never be added since those things could be different for
>> every vendor.
>>
>> The original intent of the SBSA uart was to provide a common early
>> debug uart. It was not to have a full fledged driver. I think the SBSA
>> has failed in this area and created the potential to create a mess of
>> serial drivers different for every vendor. Reality will hopefully not
>> be that extreme and most vendors will just use the pl011 and create
>> their value add somewhere besides the uart. For the purpose of debug
>> output, we already support that as the pl011 earlycon only touches
>> SBSA compatible registers.
>
> I see your point (and was actually looking for those kind of comments
> when posting this).
> I agree to that debug aspect and understand that earlycon already does
> this, but I think we need some support beyond earlycon, to be able to
> login and use it as a console (which is not possible with earlycon,
> right?) This is probably still for debugging or emergency access to the
> system only, but maybe also for logging - actually quite similar to how
> UARTs are used on today's x86 servers.
> So after having written three incarnations of this driver (goldfish
> based, PL010 based, PL011 based) I wonder if supporting the SBSA subset
> in the real PL011 driver is an option. Either this would be enabled by a
> new explicit DT property or preferably by a clever compatible string.
> Ideally we would just provide a different set of "struct uart_ops"
> members, with some pointing to generic PL011 routines, some to SBSA UART
> specific ones.
> Maybe we make the full featured PL011 support a config option
> (defaulting to y), allowing people to only use the SBSA subset in their
> kernel?

I think your choices are add the option into pl011 driver or move the
common parts of pl011 driver into a common lib.

>
> Does that make more sense? (for a general SBSA h/w rationale see below)
>
>>>  5 files changed, 829 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
>>>  create mode 100644 drivers/tty/serial/sbsa_uart.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt 
>>> b/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
>>> new file mode 100644
>>> index 000..8e2c5d6
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
>>> @@ -0,0 +1,6 @@
>>> +* ARM SBSA defined generic UART
>>> +
>>> +Required properties:
>>> +- compatible: must be "arm,sbsa-uart"
>>
>> This alone is not okay. There is no such implementation of hardware.
>
> But the SBSA explicitly allows this. I don't know of any vendor who just
> implements the subset, but I've been told that this has been asked for.

To use baudrate as an example, that must be configurable somehow
either with pl011 registers or in a vendor specific way. I suppose you
could do an actual implementation with all those things hardcoded in
the design, but that seems unlikely.

Regardless of config registers, if you have 10 different implementers
of a spec, you need 10 different compatible strings because you will
have 10 different sets of quirks. See the 8250 driver if you need
proof of that.

>> The DT must specify the implementation such as pl011.
>
> If it is a full featured PL011: sure. Then we don't need this driver at
> all and just use the SBSA UART spec as a guideline for our earlycon
> 

Re: linux-next: Tree for Sep 1

[Bartlomiej Zolnierkiewicz]

Hi,

On Tuesday, September 02, 2014 12:07:28 AM Mark Brown wrote:
> Changes since 20140829:
> 
> The akpm-current gained a conflict against Linus' tree.
> 
> Non-merge commits (relative to Linus' tree): 2553
>  2686 files changed, 98625 insertions(+), 79475 deletions(-)
> 
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git .
> If you are tracking the linux-next tree using git, you should not use
> "git pull" to do so as that will try to merge the new linux-next release
> with the old one.  You should use "git fetch" and checkout or reset to
> the new master.
> 
> You can see which trees have been included by looking in the Next/Trees
> file in the source.  There are also quilt-import.log and merge.log files
> in the Next directory.  Between each merge, the tree was built with an
> allmodconfig for x86_64 and a multi_v7_defconfig for arm.
> 
> Below is a summary of the state of the merge.
> 
> I am currently merging 214 trees (counting Linus' and 30 trees of patches
> pending for Linus' tree).
> 
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
> 
> Status of Stephen's local build tests will be at
> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.

I need following patch to make it boot on ODROID U3 board
(ARM Exynos4412 SoC based).  next-20140825 was good, next-20140828
is bad (I haven't tried next-20140826 and next-20140827).


--
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] Drivers:firewire: fix style errors in core-card.c This is a patch in the core-card.c file which fixes up 2 warnings found by the checkpatch.pl tool Signed-off-by: Sander Nemvalts

[Stefan Richter]

Folding two replies into one.

On Sep 02 Sander Nemvalts wrote:
> On Sep 2, 2014 12:56 AM, "Stefan Richter"  wrote:
> 
> > On Sep 01 Sander Nemvalts wrote:
> > > --- a/drivers/firewire/core-card.c
> > > +++ b/drivers/firewire/core-card.c
> > > @@ -89,7 +89,8 @@ static size_t config_rom_length = 1 + 4 + 1 + 1;
> > >  #define BIB_ISC  ((1) << 29)
> > >  #define BIB_CMC  ((1) << 30)
> > >  #define BIB_IRMC ((1) << 31)
> > > -#define NODE_CAPABILITIES0x0c0083c0 /* per IEEE 1394 clause 
> > > 8.3.2.6.5.2 */
> > > +/* per IEEE 1394 clause 8.3.2.6.5.2 */
> > > +#define NODE_CAPABILITIES0x0c0083c0
> >
> > This is no improvement.
> >
> The comment after NODE_CAPABILITIES was moved to front of statement because
> the line would otherwise be over 80 characters long.

There is no problem with this line's remaining 81 characters long.

> Also, commenting before the line is demonstrated in the next statement.

This block of statements is entirely unrelated to the next statement;
furthermore the nature and form of this and the next comment are unrelated.


On Sep 02 Paul Bolle wrote:
> On Mon, 2014-09-01 at 23:56 +0200, Stefan Richter wrote:
> > On Sep 01 Sander Nemvalts wrote:
> > > @@ -132,7 +133,7 @@ static void generate_config_rom(struct fw_card *card, 
> > > __be32 *config_rom)
> > >   j = 7 + descriptor_count;
> > >  
> > >   /* Generate root directory entries for descriptors. */
> > > - list_for_each_entry (desc, _list, link) {
> > > + list_for_each_entry(desc, _list, link) {
> > >   if (desc->immediate > 0)
> > >   config_rom[i++] = cpu_to_be32(desc->immediate);
> > >   config_rom[i] = cpu_to_be32(desc->key | (j - i));
> > 
> > We are writing
> > for (a; b; c);
> > not
> > for(a; b; c);
> > and thus a space after list_for_each and friends makes sense.
> 
> $ git grep "list_for_each_entry (" | wc -l
> 52
> $ git grep "list_for_each_entry(" | wc -l
> 5991
> 
> So "list_for_each_entry(" (without space) seems to be the preferred
> style.

'Seems to be' is an appropriate wording indeed, since grep shows
occurrences, not preferences.


All,

here are some tips for whitespace changes and similar patches:

  - As a general rule, do not propose style changes to code on which you
are not working on.

  - Do not propose style changes to code on which you are working on,
unless you can significantly improve the code this way.

Rationale:  Style changes (outside of drivers/staging/) tend to worsen
rather than improve code.  Style changes obfuscate code history.  Style
changes are of doubtfule value but create nonzero work for those who
handle the code together with you or after you.

  - checkpatch.pl is a help for you to evaluate stylistic conformance of
your own new code submissions.  Use checkpatch.pl for its original
purpose.
-- 
Stefan Richter
-=-- =--= ---=-
http://arcgraph.de/sr/
--
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 3/4] ARM: dts: qcom: Add TLMM DT node for APQ8084

[Georgi Djakov]

This patch adds the TLMM node for the APQ8084 platform.

Reviewed-by: Bjorn Andersson 
Signed-off-by: Georgi Djakov 
---
 arch/arm/boot/dts/qcom-apq8084.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi 
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index b9ac63c..1f130bc 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -186,6 +186,16 @@
reg = <0xfc40 0x4000>;
};
 
+   tlmm: pinctrl@fd51 {
+   compatible = "qcom,apq8084-pinctrl";
+   reg = <0xfd51 0x4000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   interrupts = <0 208 0>;
+   };
+
serial@f995e000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0xf995e000 0x1000>;
-- 
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: [REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station

[Theodore Ts'o]

On Tue, Sep 02, 2014 at 09:23:16PM +1000, Dave Airlie wrote:
> 
> Interesting, I have the same combo of hw available on my desk at work,
> but it might be a couple of days before I can get to the office to
> debug it,
> 
> can you boot with drm.debug=6 and get me the dmesg?

I'll do that when I get home.  In the meantime, here's an additional
data point.  At work, I have the same model docking station connected
to a 2011 Dell 2410f Rev A04 (max resolution 1920x1200, and I suspect
not DP 1.2 capable; at least, it doesn't mention DP in monitor menu)
--- and connecting through the docking station, it does work
(connecting through either DVI or DisplayPort).

Here's the drm.debug=6 connecting to the docking station via DVI.  I
can get a drm.debug=6 connecting via the DP and the docking station if
that would be helpful.  Similarly, if you want, I can also try to get
a debug run connecting to the HP ZRW30 monitor (either direct or via
the docking station), since that's the monitor on the walkstation.  :-)

Cheers,

- Ted



drm-debug.xz
Description: Binary data

[GIT PULL] arm64: second wave of arm64 fixes for 3.17

[Will Deacon]

Hello Linus,

Please can you pull these fixes for arm64? They address some issues found
by running smatch on the arch code (ignoring the false positives) and also
stop 32-bit Android from losing track of its stack.

There's one additional irq migration fix in the pipeline, but it came in
after I'd tagged and tested this set.

Thanks,

Will

--->8

The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef:

  Linux 3.17-rc2 (2014-08-25 15:36:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes

for you to fetch changes up to 5e39977edf6500fd12f169e6c458d33b0ef62feb:

  Revert "arm64: cpuinfo: print info for all CPUs" (2014-09-01 15:55:22 +0100)


arm64 fixes for -rc4

Another handful of arm64 fixes here:

  - A few fixes for real issues found by smatch (after Dan's talk at KS)
  - Revert the /proc/cpuinfo changes merged during the merge window.
We've opened a can of worms here, so we need to find out where we
stand before we change this interface.
  - Implement KSTK_ESP for compat tasks, otherwise 32-bit Android gets
confused wondering where its [stack] has gone
  - Misc fixes (fpsimd context handling, crypto, ...)


Catalin Marinas (1):
  arm64: Add brackets around user_stack_pointer()

Colin Ian King (1):
  arm64/crypto: remove redundant update of data

Geoff Levand (1):
  arm64: Remove unused variable in head.S

Leo Yan (1):
  arm64: fix bug for reloading FPSIMD state after cpu power off

Will Deacon (5):
  arm64: ptrace: fix compat hardware watchpoint reporting
  arm64: ptrace: fix compat reg getter/setter return values
  arm64: perf: don't rely on layout of pt_regs when grabbing sp or pc
  arm64: report correct stack pointer in KSTK_ESP for compat tasks
  Revert "arm64: cpuinfo: print info for all CPUs"

 arch/arm64/crypto/sha2-ce-glue.c   |  1 -
 arch/arm64/include/asm/hw_breakpoint.h |  1 -
 arch/arm64/include/asm/processor.h |  2 +-
 arch/arm64/include/asm/ptrace.h|  2 +-
 arch/arm64/kernel/fpsimd.c |  1 +
 arch/arm64/kernel/head.S   |  4 
 arch/arm64/kernel/perf_regs.c  |  6 +
 arch/arm64/kernel/ptrace.c | 13 +++
 arch/arm64/kernel/setup.c  | 40 +++---
 9 files changed, 40 insertions(+), 30 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 v3 1/4] pinctrl: qcom: Add APQ8084 pinctrl support

[Georgi Djakov]

This patchset adds pinctrl support for the Qualcomm APQ8084 platform.

Reviewed-by: Andy Gross 
Signed-off-by: Georgi Djakov 
---
 drivers/pinctrl/qcom/Kconfig   |8 +
 drivers/pinctrl/qcom/Makefile  |1 +
 drivers/pinctrl/qcom/pinctrl-apq8084.c | 1243 
 3 files changed, 1252 insertions(+)
 create mode 100644 drivers/pinctrl/qcom/pinctrl-apq8084.c

diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index d160a71..81275af 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -15,6 +15,14 @@ config PINCTRL_APQ8064
  This is the pinctrl, pinmux, pinconf and gpiolib driver for the
  Qualcomm TLMM block found in the Qualcomm APQ8064 platform.
 
+config PINCTRL_APQ8084
+   tristate "Qualcomm APQ8084 pin controller driver"
+   depends on GPIOLIB && OF
+   select PINCTRL_MSM
+   help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm TLMM block found in the Qualcomm APQ8084 platform.
+
 config PINCTRL_IPQ8064
tristate "Qualcomm IPQ8064 pin controller driver"
depends on GPIOLIB && OF
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 2a02602..ba8519f 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -1,6 +1,7 @@
 # Qualcomm pin control drivers
 obj-$(CONFIG_PINCTRL_MSM)  += pinctrl-msm.o
 obj-$(CONFIG_PINCTRL_APQ8064)  += pinctrl-apq8064.o
+obj-$(CONFIG_PINCTRL_APQ8084)  += pinctrl-apq8084.o
 obj-$(CONFIG_PINCTRL_IPQ8064)  += pinctrl-ipq8064.o
 obj-$(CONFIG_PINCTRL_MSM8960)  += pinctrl-msm8960.o
 obj-$(CONFIG_PINCTRL_MSM8X74)  += pinctrl-msm8x74.o
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8084.c 
b/drivers/pinctrl/qcom/pinctrl-apq8084.c
new file mode 100644
index 000..5362959
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-apq8084.c
@@ -0,0 +1,1243 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-msm.h"
+
+static const struct pinctrl_pin_desc apq8084_pins[] = {
+   PINCTRL_PIN(0, "GPIO_0"),
+   PINCTRL_PIN(1, "GPIO_1"),
+   PINCTRL_PIN(2, "GPIO_2"),
+   PINCTRL_PIN(3, "GPIO_3"),
+   PINCTRL_PIN(4, "GPIO_4"),
+   PINCTRL_PIN(5, "GPIO_5"),
+   PINCTRL_PIN(6, "GPIO_6"),
+   PINCTRL_PIN(7, "GPIO_7"),
+   PINCTRL_PIN(8, "GPIO_8"),
+   PINCTRL_PIN(9, "GPIO_9"),
+   PINCTRL_PIN(10, "GPIO_10"),
+   PINCTRL_PIN(11, "GPIO_11"),
+   PINCTRL_PIN(12, "GPIO_12"),
+   PINCTRL_PIN(13, "GPIO_13"),
+   PINCTRL_PIN(14, "GPIO_14"),
+   PINCTRL_PIN(15, "GPIO_15"),
+   PINCTRL_PIN(16, "GPIO_16"),
+   PINCTRL_PIN(17, "GPIO_17"),
+   PINCTRL_PIN(18, "GPIO_18"),
+   PINCTRL_PIN(19, "GPIO_19"),
+   PINCTRL_PIN(20, "GPIO_20"),
+   PINCTRL_PIN(21, "GPIO_21"),
+   PINCTRL_PIN(22, "GPIO_22"),
+   PINCTRL_PIN(23, "GPIO_23"),
+   PINCTRL_PIN(24, "GPIO_24"),
+   PINCTRL_PIN(25, "GPIO_25"),
+   PINCTRL_PIN(26, "GPIO_26"),
+   PINCTRL_PIN(27, "GPIO_27"),
+   PINCTRL_PIN(28, "GPIO_28"),
+   PINCTRL_PIN(29, "GPIO_29"),
+   PINCTRL_PIN(30, "GPIO_30"),
+   PINCTRL_PIN(31, "GPIO_31"),
+   PINCTRL_PIN(32, "GPIO_32"),
+   PINCTRL_PIN(33, "GPIO_33"),
+   PINCTRL_PIN(34, "GPIO_34"),
+   PINCTRL_PIN(35, "GPIO_35"),
+   PINCTRL_PIN(36, "GPIO_36"),
+   PINCTRL_PIN(37, "GPIO_37"),
+   PINCTRL_PIN(38, "GPIO_38"),
+   PINCTRL_PIN(39, "GPIO_39"),
+   PINCTRL_PIN(40, "GPIO_40"),
+   PINCTRL_PIN(41, "GPIO_41"),
+   PINCTRL_PIN(42, "GPIO_42"),
+   PINCTRL_PIN(43, "GPIO_43"),
+   PINCTRL_PIN(44, "GPIO_44"),
+   PINCTRL_PIN(45, "GPIO_45"),
+   PINCTRL_PIN(46, "GPIO_46"),
+   PINCTRL_PIN(47, "GPIO_47"),
+   PINCTRL_PIN(48, "GPIO_48"),
+   PINCTRL_PIN(49, "GPIO_49"),
+   PINCTRL_PIN(50, "GPIO_50"),
+   PINCTRL_PIN(51, "GPIO_51"),
+   PINCTRL_PIN(52, "GPIO_52"),
+   PINCTRL_PIN(53, "GPIO_53"),
+   PINCTRL_PIN(54, "GPIO_54"),
+   PINCTRL_PIN(55, "GPIO_55"),
+   PINCTRL_PIN(56, "GPIO_56"),
+   PINCTRL_PIN(57, "GPIO_57"),
+   PINCTRL_PIN(58, "GPIO_58"),
+   PINCTRL_PIN(59, "GPIO_59"),
+   PINCTRL_PIN(60, "GPIO_60"),
+   PINCTRL_PIN(61, "GPIO_61"),
+   PINCTRL_PIN(62, "GPIO_62"),
+   PINCTRL_PIN(63, "GPIO_63"),
+   PINCTRL_PIN(64, "GPIO_64"),
+   PINCTRL_PIN(65, "GPIO_65"),
+   PINCTRL_PIN(66, 

[PATCH v3 2/4] dt: Document Qualcomm APQ8084 pinctrl binding

[Georgi Djakov]

Define a new binding for the Qualcomm TLMM (Top-Level Mode Mux) based pin
controller inside the APQ8084.

Acked-by: Bjorn Andersson 
Signed-off-by: Georgi Djakov 
---
 .../bindings/pinctrl/qcom,apq8084-pinctrl.txt  |  179 
 1 file changed, 179 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
new file mode 100644
index 000..9d95700
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
@@ -0,0 +1,179 @@
+Qualcomm APQ8084 TLMM block
+
+This binding describes the Top Level Mode Multiplexer block found in the
+MSM8960 platform.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,apq8084-pinctrl"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: the base address and size of the TLMM register space.
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: should specify the TLMM summary IRQ.
+
+- interrupt-controller:
+   Usage: required
+   Value type: 
+   Definition: identifies this node as an interrupt controller
+
+- #interrupt-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 2. Specifying the pin number and flags, as defined
+   in 
+
+- gpio-controller:
+   Usage: required
+   Value type: 
+   Definition: identifies this node as a gpio controller
+
+- #gpio-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 2. Specifying the pin number and flags, as defined
+   in 
+
+Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
+a general description of GPIO and interrupt bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+The pin configuration nodes act as a container for an abitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+
+PIN CONFIGURATION NODES:
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+
+- pins:
+   Usage: required
+   Value type: 
+   Definition: List of gpio pins affected by the properties specified in
+   this subnode.  Valid pins are:
+   gpio0-gpio146,
+   sdc1_clk,
+   sdc1_cmd,
+   sdc1_data
+   sdc3_clk,
+   sdc3_cmd,
+   sdc3_data
+
+- function:
+   Usage: required
+   Value type: 
+   Definition: Specify the alternative function to be configured for the
+   specified pins. Functions are only valid for gpio pins.
+   Valid values are:
+   adsp_ext, audio_ref, blsp_i2c1, blsp_i2c2, blsp_i2c3,
+   blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8,
+   blsp_i2c9, blsp_i2c10, blsp_i2c11, blsp_i2c12,
+   blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5,
+   blsp_spi6, blsp_spi7, blsp_spi8, blsp_spi9, blsp_spi10,
+   blsp_spi11, blsp_spi12, blsp_uart1, blsp_uart2, blsp_uart3,
+   blsp_uart4, blsp_uart5, blsp_uart6, blsp_uart7, blsp_uart8,
+   blsp_uart9, blsp_uart10, blsp_uart11, blsp_uart12,
+   blsp_uim1, blsp_uim2, blsp_uim3, blsp_uim4, blsp_uim5,
+   blsp_uim6, blsp_uim7, blsp_uim8, blsp_uim9, blsp_uim10,
+   blsp_uim11, blsp_uim12, cam_mclk0, cam_mclk1, cam_mclk2,
+   cam_mclk3, cci_async, cci_async_in0, cci_i2c0, cci_i2c1,
+   cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4,
+   edp_hpd, gcc_gp1, gcc_gp2, gcc_gp3, gcc_obt, gcc_vtt,i
+   gp_mn, gp_pdm0, gp_pdm1, gp_pdm2, gp0_clk, gp1_clk, gpio,
+   hdmi_cec, hdmi_ddc, hdmi_dtest, hdmi_hpd, hdmi_rcv, hsic,
+   ldo_en, ldo_update, mdp_vsync, 

[PATCH v3 0/4] pinctrl: qcom: Add APQ8084 pinctrl support

[Georgi Djakov]

This set of patches adds pinctrl support for the Qualcomm APQ8084 platform.
The first patch adds the pin definitions. The second patch contains the
devicetree binding documentation. The third patch adds the DT node.
The last patch makes the INTR_TARGET_PROC_APPS value configurable and
defines it for each existing SoC.

Tested on IFC6540 board.

Changes since v2:
 - Fixed some incorrect bits and offsets. (suggested by Bjorn Andersson)
 - Updated binding documentation to follow the format of msm8960.
   (suggested by Bjorn Andersson)
 - Added fourth patch, which removes the hardcoded INTR_TARGET_PROC_APPS
   value and makes it configurable. Also we keep the current value for
   existing SoCs. (suggested by Bjorn Andersson)

Changes since v1:
 - Updated the total number of pins (suggested by Bjorn Andersson)
 - Added the missing pin info (provided by Andy Gross)
 - Updated groups and functions to be consistent with other pinctrls.
   (suggested by Andy Gross)
 - Removed unused functions, qdss and test pins. (suggested by Andy Gross)
 - Updated the documentation with the possible functions.

Georgi Djakov (4):
  pinctrl: qcom: Add APQ8084 pinctrl support
  dt: Document Qualcomm APQ8084 pinctrl binding
  ARM: dts: qcom: Add TLMM DT node for APQ8084
  pinctrl: qcom: Make the target processor value configurable

 .../bindings/pinctrl/qcom,apq8084-pinctrl.txt  |  179 +++
 arch/arm/boot/dts/qcom-apq8084.dtsi|   10 +
 drivers/pinctrl/qcom/Kconfig   |8 +
 drivers/pinctrl/qcom/Makefile  |1 +
 drivers/pinctrl/qcom/pinctrl-apq8064.c |2 +
 drivers/pinctrl/qcom/pinctrl-apq8084.c | 1245 
 drivers/pinctrl/qcom/pinctrl-ipq8064.c |2 +
 drivers/pinctrl/qcom/pinctrl-msm.c |4 +-
 drivers/pinctrl/qcom/pinctrl-msm.h |3 +
 drivers/pinctrl/qcom/pinctrl-msm8960.c |2 +
 drivers/pinctrl/qcom/pinctrl-msm8x74.c |2 +
 11 files changed, 1455 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
 create mode 100644 drivers/pinctrl/qcom/pinctrl-apq8084.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 4/4] pinctrl: qcom: Make the target processor value configurable

[Georgi Djakov]

Currently the value used for specify that interrupts from the gpio should
be routed to the application processor is hardcoded for all Qualcomm SoCs.
But the new APQ8084 SoC uses a different value. To resolve this, we make
this value configurable for each SoC. For all existing SoCs we continue
to use the current value, and only for APQ8084 we use the new value.

Suggested-by: Bjorn Andersson 
Signed-off-by: Georgi Djakov 
---
 drivers/pinctrl/qcom/pinctrl-apq8064.c |2 ++
 drivers/pinctrl/qcom/pinctrl-apq8084.c |2 ++
 drivers/pinctrl/qcom/pinctrl-ipq8064.c |2 ++
 drivers/pinctrl/qcom/pinctrl-msm.c |4 +---
 drivers/pinctrl/qcom/pinctrl-msm.h |3 +++
 drivers/pinctrl/qcom/pinctrl-msm8960.c |2 ++
 drivers/pinctrl/qcom/pinctrl-msm8x74.c |2 ++
 7 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-apq8064.c 
b/drivers/pinctrl/qcom/pinctrl-apq8064.c
index feb6f15..f877aed 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8064.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8064.c
@@ -258,6 +258,7 @@ static const unsigned int sdc3_data_pins[] = { 95 };
.intr_status_bit = 0,   \
.intr_ack_high = 1, \
.intr_target_bit = 0,   \
+   .intr_target_kpss_val = 4,  \
.intr_raw_status_bit = 3,   \
.intr_polarity_bit = 1, \
.intr_detection_bit = 2,\
@@ -283,6 +284,7 @@ static const unsigned int sdc3_data_pins[] = { 95 };
.intr_enable_bit = -1,  \
.intr_status_bit = -1,  \
.intr_target_bit = -1,  \
+   .intr_target_kpss_val = -1, \
.intr_raw_status_bit = -1,  \
.intr_polarity_bit = -1,\
.intr_detection_bit = -1,   \
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8084.c 
b/drivers/pinctrl/qcom/pinctrl-apq8084.c
index 5362959..138cbf6 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8084.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8084.c
@@ -371,6 +371,7 @@ static const unsigned int sdc2_data_pins[] = { 152 };
.intr_status_bit = 0,   \
.intr_ack_high = 0, \
.intr_target_bit = 5,   \
+   .intr_target_kpss_val = 3,  \
.intr_raw_status_bit = 4,   \
.intr_polarity_bit = 1, \
.intr_detection_bit = 2,\
@@ -396,6 +397,7 @@ static const unsigned int sdc2_data_pins[] = { 152 };
.intr_enable_bit = -1,  \
.intr_status_bit = -1,  \
.intr_target_bit = -1,  \
+   .intr_target_kpss_val = -1, \
.intr_raw_status_bit = -1,  \
.intr_polarity_bit = -1,\
.intr_detection_bit = -1,   \
diff --git a/drivers/pinctrl/qcom/pinctrl-ipq8064.c 
b/drivers/pinctrl/qcom/pinctrl-ipq8064.c
index 767cf11..81f49a9 100644
--- a/drivers/pinctrl/qcom/pinctrl-ipq8064.c
+++ b/drivers/pinctrl/qcom/pinctrl-ipq8064.c
@@ -211,6 +211,7 @@ static const unsigned int sdc3_data_pins[] = { 71 };
.intr_status_bit = 0,   \
.intr_ack_high = 1, \
.intr_target_bit = 0,   \
+   .intr_target_kpss_val = 4,  \
.intr_raw_status_bit = 3,   \
.intr_polarity_bit = 1, \
.intr_detection_bit = 2,\
@@ -236,6 +237,7 @@ static const unsigned int sdc3_data_pins[] = { 71 };
.intr_enable_bit = -1,  \
.intr_status_bit = -1,  \
.intr_target_bit = -1,  \
+   .intr_target_kpss_val = -1, \
.intr_raw_status_bit = -1,  \
.intr_polarity_bit = -1,\
.intr_detection_bit = -1,   \
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 2738108..592c6fc 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -649,8 +649,6 @@ static void msm_gpio_irq_ack(struct irq_data *d)
spin_unlock_irqrestore(>lock, flags);
 }
 
-#define INTR_TARGET_PROC_APPS4
-
 static int msm_gpio_irq_set_type(struct irq_data *d, unsigned int type)
 {
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
@@ -674,7 +672,7 @@ static int msm_gpio_irq_set_type(struct irq_data *d, 
unsigned int type)
/* Route interrupts to application cpu */

Re: [PATCH] kernel/signal.c: whitespace fixes

[Oleg Nesterov]

On 09/02, Jiri Kosina wrote:
>
> On Tue, 2 Sep 2014, Vishnu Pratap Singh wrote:
>
> > From: "vishnu.ps" 
> >
> > Fix minor errors and warning messages in kernel/signal.c.  These errors were
> > reported by checkpatch while working with some modifications in signal.c
> > file.
> >
> > ERROR: code indent should use tabs where possible - 18
> > ERROR: need consistent spacing around '&' (ctx:WxO) - 11
> > ERROR: space prohibited after that '~' (ctx:OxW) - 11
> > ERROR: trailing whitespace - 4
> > ERROR: space required after that ',' (ctx:VxV) - 4
> > ERROR: trailing statements should be on next line - 3
> > ERROR: "foo * bar" should be "foo *bar" - 1
> >
> > total 52 errors fixed.
>
> I am not taking this through trivial.git; it just clutters results of 'git
> blame' horribly for no measurable gain.
>
> Changes like this are reasonable only if you make any real changes to the
> code at the same time.

I agree very much.

Vishnu, please think about those (me in particular ;) who need to backport
the fixes from time to time. Just suppose we have a bug in, say,
do_notify_parent_cldstop(), and it is fixed later. Now I will likely need
to backport your change too, and this is not trivial in general, plus this
adds the additional risk.

Oleg.

--
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 v11 16/19] serial: asc: Add support for KGDB's FIQ/NMI mode

[Daniel Thompson]

Add a .poll_init() function that enables UART RX and registers the
UART's irq with KGDB. By providing this information to KGDB the serial
driver offers "permission" for KGDB to route the UART interrupt signal
from the drivers own handler to KGDBs FIQ handler (which will eventually
use the UART's polled I/O callbacks to interact with the user).

Note that the RX is not only enabled but also unmasked. This is required
because otherwise the FIQ handler could never trigger. This unmask is
copied from similar code in amba-pl011.c .

Signed-off-by: Daniel Thompson 
Cc: Srinivas Kandagatla 
Cc: Maxime Coquelin 
Cc: Patrice Chotard 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: ker...@stlinux.com
Cc: linux-ser...@vger.kernel.org
---
 drivers/tty/serial/st-asc.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index 8b2d735..2b5eb6e 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DRIVER_NAME "st-asc"
 #define ASC_SERIAL_NAME "ttyAS"
@@ -607,6 +608,25 @@ asc_verify_port(struct uart_port *port, struct 
serial_struct *ser)
 }
 
 #ifdef CONFIG_CONSOLE_POLL
+
+#ifdef CONFIG_KGDB_FIQ
+/*
+ * Prepare the UART to be used from kgdb's NMI support.
+ */
+static int asc_poll_init(struct uart_port *port)
+{
+   struct asc_port *ascport = container_of(port, struct asc_port, port);
+
+   /* register the FIQ with kgdb */
+   kgdb_register_fiq(ascport->port.irq);
+
+   /* enable RX interrupts in case the interrupt is used for NMI entry. */
+   asc_enable_rx_interrupts(port);
+
+   return 0;
+}
+#endif /* CONFIG_KGDB_FIQ */
+
 /*
  * Console polling routines for writing and reading from the uart while
  * in an interrupt or debug context (i.e. kgdb).
@@ -649,6 +669,9 @@ static struct uart_ops asc_uart_ops = {
.verify_port= asc_verify_port,
.pm = asc_pm,
 #ifdef CONFIG_CONSOLE_POLL
+#ifdef CONFIG_KGDB_FIQ
+   .poll_init = asc_poll_init,
+#endif /* CONFIG_KGDB_FIQ */
.poll_get_char = asc_get_poll_char,
.poll_put_char = asc_put_poll_char,
 #endif /* CONFIG_CONSOLE_POLL */
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 15/19] serial: amba-pl011: Pass FIQ information to KGDB.

[Daniel Thompson]

Speculatively register a FIQ resource with KGDB. KGDB will only
accept it if the kgdb/fiq feature is enabled (both with compile time and
runtime switches) and the interrupt controller supports FIQ.

By providing this information to KGDB the serial driver offers
"permission" for KGDB to route the UART interrupt signal from the
drivers own handler to KGDBs FIQ handler (which will eventually use the
UART's polled I/O callbacks to interact with the user). This permission
also implies the amba-pl011 driver has already unmasked RX interrupts
(otherwise the FIQ handler will never trigger).

Signed-off-by: Daniel Thompson 
Cc: Russell King 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
---
 drivers/tty/serial/amba-pl011.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 0b06dcf..63c67b0 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -58,6 +58,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define UART_NR14
 
@@ -1466,6 +1467,18 @@ static int pl011_hwinit(struct uart_port *port)
 
 #ifdef CONFIG_CONSOLE_POLL
 
+static int pl011_poll_init(struct uart_port *port)
+{
+   int retval = pl011_hwinit(port);
+
+#ifdef CONFIG_KGDB_FIQ
+   if (retval == 0)
+   kgdb_register_fiq(port->irq);
+#endif
+
+   return retval;
+}
+
 static void pl011_quiesce_irqs(struct uart_port *port)
 {
struct uart_amba_port *uap =
@@ -1905,7 +1918,7 @@ static struct uart_ops amba_pl011_pops = {
.config_port= pl011_config_port,
.verify_port= pl011_verify_port,
 #ifdef CONFIG_CONSOLE_POLL
-   .poll_init = pl011_hwinit,
+   .poll_init = pl011_poll_init,
.poll_get_char = pl011_get_poll_char,
.poll_put_char = pl011_put_poll_char,
 #endif
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 12/19] serial: kgdb_nmi: No CON_ENABLED by default

[Daniel Thompson]

At present this console is selectively enabled/disabled by NULL checking
arch_kgdb_ops.enable_nmi. In practice this requires the architecture
dependant code to implement some kind of control (e.g. module arguments)
to enable/disable the feature.

The kernel already provide the perfectly adequade console= argument to
do this. Let's us that instead, if nothing else, it makes any
documentation architecture neutral.

Signed-off-by: Daniel Thompson 
---
 drivers/tty/serial/kgdb_nmi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/kgdb_nmi.c b/drivers/tty/serial/kgdb_nmi.c
index 6ec7501..129dc5b 100644
--- a/drivers/tty/serial/kgdb_nmi.c
+++ b/drivers/tty/serial/kgdb_nmi.c
@@ -46,6 +46,8 @@ static atomic_t kgdb_nmi_num_readers = ATOMIC_INIT(0);
 
 static int kgdb_nmi_console_setup(struct console *co, char *options)
 {
+   arch_kgdb_ops.enable_nmi(1);
+
/* The NMI console uses the dbg_io_ops to issue console messages. To
 * avoid duplicate messages during kdb sessions we must inform kdb's
 * I/O utilities that messages sent to the console will automatically
@@ -77,7 +79,7 @@ static struct console kgdb_nmi_console = {
.setup  = kgdb_nmi_console_setup,
.write  = kgdb_nmi_console_write,
.device = kgdb_nmi_console_device,
-   .flags  = CON_PRINTBUFFER | CON_ANYTIME | CON_ENABLED,
+   .flags  = CON_PRINTBUFFER | CON_ANYTIME,
.index  = -1,
 };
 
@@ -354,7 +356,6 @@ int kgdb_register_nmi_console(void)
}
 
register_console(_nmi_console);
-   arch_kgdb_ops.enable_nmi(1);
 
return 0;
 err_drv_reg:
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 13/19] serial: amba-pl011: Use container_of() to get uart_amba_port

[Daniel Thompson]

Universally adopt container_of() for all pointer conversion from
uart_port to uart_amba_port.

Signed-off-by: Daniel Thompson 
---
 drivers/tty/serial/amba-pl011.c | 54 +++--
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 8572f2a..02016fc 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -678,7 +678,8 @@ static void pl011_dma_flush_buffer(struct uart_port *port)
 __releases(>port.lock)
 __acquires(>port.lock)
 {
-   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
 
if (!uap->using_tx_dma)
return;
@@ -1163,7 +1164,8 @@ static inline bool pl011_dma_rx_running(struct 
uart_amba_port *uap)
 
 static void pl011_stop_tx(struct uart_port *port)
 {
-   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
 
uap->im &= ~UART011_TXIM;
writew(uap->im, uap->port.membase + UART011_IMSC);
@@ -1172,7 +1174,8 @@ static void pl011_stop_tx(struct uart_port *port)
 
 static void pl011_start_tx(struct uart_port *port)
 {
-   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
 
if (!pl011_dma_tx_start(uap)) {
uap->im |= UART011_TXIM;
@@ -1182,7 +1185,8 @@ static void pl011_start_tx(struct uart_port *port)
 
 static void pl011_stop_rx(struct uart_port *port)
 {
-   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
 
uap->im &= ~(UART011_RXIM|UART011_RTIM|UART011_FEIM|
 UART011_PEIM|UART011_BEIM|UART011_OEIM);
@@ -1193,7 +1197,8 @@ static void pl011_stop_rx(struct uart_port *port)
 
 static void pl011_enable_ms(struct uart_port *port)
 {
-   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
 
uap->im |= UART011_RIMIM|UART011_CTSMIM|UART011_DCDMIM|UART011_DSRMIM;
writew(uap->im, uap->port.membase + UART011_IMSC);
@@ -1349,14 +1354,16 @@ static irqreturn_t pl011_int(int irq, void *dev_id)
 
 static unsigned int pl011_tx_empty(struct uart_port *port)
 {
-   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
unsigned int status = readw(uap->port.membase + UART01x_FR);
return status & (UART01x_FR_BUSY|UART01x_FR_TXFF) ? 0 : TIOCSER_TEMT;
 }
 
 static unsigned int pl011_get_mctrl(struct uart_port *port)
 {
-   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
unsigned int result = 0;
unsigned int status = readw(uap->port.membase + UART01x_FR);
 
@@ -1374,7 +1381,8 @@ static unsigned int pl011_get_mctrl(struct uart_port 
*port)
 
 static void pl011_set_mctrl(struct uart_port *port, unsigned int mctrl)
 {
-   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
unsigned int cr;
 
cr = readw(uap->port.membase + UART011_CR);
@@ -1402,7 +1410,8 @@ static void pl011_set_mctrl(struct uart_port *port, 
unsigned int mctrl)
 
 static void pl011_break_ctl(struct uart_port *port, int break_state)
 {
-   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
unsigned long flags;
unsigned int lcr_h;
 
@@ -1420,7 +1429,8 @@ static void pl011_break_ctl(struct uart_port *port, int 
break_state)
 
 static void pl011_quiesce_irqs(struct uart_port *port)
 {
-   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
unsigned char __iomem *regs = uap->port.membase;
 
writew(readw(regs + UART011_MIS), regs + UART011_ICR);
@@ -1442,7 +1452,8 @@ static void pl011_quiesce_irqs(struct uart_port *port)
 
 static int pl011_get_poll_char(struct uart_port *port)
 {
-   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
unsigned int status;
 
/*
@@ -1461,7 +1472,8 @@ static int pl011_get_poll_char(struct uart_port *port)
 static void pl011_put_poll_char(struct uart_port *port,
 unsigned char 

Re: [PATCH v2 6/6] mm/balloon_compaction: general cleanup

[Rafael Aquini]

On Sat, Aug 30, 2014 at 08:41:27PM +0400, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov 
> 
> * move special branch for balloon migraion into migrate_pages
> * remove special mapping for balloon and its flag AS_BALLOON_MAP
> * embed struct balloon_dev_info into struct virtio_balloon
> * cleanup balloon_page_dequeue, kill balloon_page_free
> 
> Signed-off-by: Konstantin Khlebnikov 
> ---
>  drivers/virtio/virtio_balloon.c|   77 -
>  include/linux/balloon_compaction.h |  127 ++---
>  include/linux/migrate.h|   11 --
>  include/linux/pagemap.h|   18 ---
>  mm/balloon_compaction.c|  214 
> 
>  mm/migrate.c   |   29 +
>  6 files changed, 134 insertions(+), 342 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 25ebe8e..c84d6a8 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -59,7 +59,7 @@ struct virtio_balloon
>* Each page on this list adds VIRTIO_BALLOON_PAGES_PER_PAGE
>* to num_pages above.
>*/
> - struct balloon_dev_info *vb_dev_info;
> + struct balloon_dev_info vb_dev_info;
>  
>   /* Synchronize access/update to this struct virtio_balloon elements */
>   struct mutex balloon_lock;
> @@ -127,7 +127,7 @@ static void set_page_pfns(u32 pfns[], struct page *page)
>  
>  static void fill_balloon(struct virtio_balloon *vb, size_t num)
>  {
> - struct balloon_dev_info *vb_dev_info = vb->vb_dev_info;
> + struct balloon_dev_info *vb_dev_info = >vb_dev_info;
>  
>   /* We can only do one array worth at a time. */
>   num = min(num, ARRAY_SIZE(vb->pfns));
> @@ -163,15 +163,15 @@ static void release_pages_by_pfn(const u32 pfns[], 
> unsigned int num)
>   /* Find pfns pointing at start of each page, get pages and free them. */
>   for (i = 0; i < num; i += VIRTIO_BALLOON_PAGES_PER_PAGE) {
>   struct page *page = balloon_pfn_to_page(pfns[i]);
> - balloon_page_free(page);
>   adjust_managed_page_count(page, 1);
> + put_page(page);
>   }
>  }
>  
>  static void leak_balloon(struct virtio_balloon *vb, size_t num)
>  {
>   struct page *page;
> - struct balloon_dev_info *vb_dev_info = vb->vb_dev_info;
> + struct balloon_dev_info *vb_dev_info = >vb_dev_info;
>  
>   /* We can only do one array worth at a time. */
>   num = min(num, ARRAY_SIZE(vb->pfns));
> @@ -353,12 +353,11 @@ static int init_vqs(struct virtio_balloon *vb)
>   return 0;
>  }
>  
> -static const struct address_space_operations virtio_balloon_aops;
>  #ifdef CONFIG_BALLOON_COMPACTION
>  /*
>   * virtballoon_migratepage - perform the balloon page migration on behalf of
>   *a compation thread. (called under page lock)
> - * @mapping: the page->mapping which will be assigned to the new migrated 
> page.
> + * @vb_dev_info: the balloon device
>   * @newpage: page that will replace the isolated page after migration 
> finishes.
>   * @page   : the isolated (old) page that is about to be migrated to newpage.
>   * @mode   : compaction mode -- not used for balloon page migration.
> @@ -373,17 +372,13 @@ static const struct address_space_operations 
> virtio_balloon_aops;
>   * This function preforms the balloon page migration task.
>   * Called through balloon_mapping->a_ops->migratepage
>   */
> -static int virtballoon_migratepage(struct address_space *mapping,
> +static int virtballoon_migratepage(struct balloon_dev_info *vb_dev_info,
>   struct page *newpage, struct page *page, enum migrate_mode mode)
>  {
> - struct balloon_dev_info *vb_dev_info = balloon_page_device(page);
> - struct virtio_balloon *vb;
> + struct virtio_balloon *vb = container_of(vb_dev_info,
> + struct virtio_balloon, vb_dev_info);
>   unsigned long flags;
>  
> - BUG_ON(!vb_dev_info);
> -
> - vb = vb_dev_info->balloon_device;
> -
>   /*
>* In order to avoid lock contention while migrating pages concurrently
>* to leak_balloon() or fill_balloon() we just give up the balloon_lock
> @@ -395,42 +390,34 @@ static int virtballoon_migratepage(struct address_space 
> *mapping,
>   if (!mutex_trylock(>balloon_lock))
>   return -EAGAIN;
>  
> + get_page(newpage); /* balloon reference */
> +
>   /* balloon's page migration 1st step  -- inflate "newpage" */
>   spin_lock_irqsave(_dev_info->pages_lock, flags);
> - balloon_page_insert(newpage, mapping, _dev_info->pages);
> + balloon_page_insert(vb_dev_info, newpage);
>   vb_dev_info->isolated_pages--;
>   spin_unlock_irqrestore(_dev_info->pages_lock, flags);
>   vb->num_pfns = VIRTIO_BALLOON_PAGES_PER_PAGE;
>   set_page_pfns(vb->pfns, newpage);
>   tell_host(vb, vb->inflate_vq);
>  
> - /*
> -  * balloon's page 

[PATCH v11 18/19] serial: imx: clean up imx_poll_get_char()

[Daniel Thompson]

From: Dirk Behme 

Looking at the get_poll_char() function of the 8250.c serial driver,
we learn:

* poll_get_char() doesn't have to save/disable/restore the interrupt
  registers. No interrupt handling is needed in this function at all.
  Remove it.

* Don't block in case there is no data available. So instead blocking
  in the do {} while loop, just return with NO_POLL_CHAR, immediately .

Additionally, while the i.MX6 register URXD[7-0] contain the RX_DATA,
the upper bits of this register (URXD[15-10]) might contain some
control flags. To ensure that these are not returned with the data
read, just mask out URXD[7-0].

These changes fix the 'hang' working with kdb:

$ echo ttymxc3 > /sys/module/kgdboc/parameters/kgdboc
$ echo g >/proc/sysrq-trigger
[0]kdb> help
...


Signed-off-by: Dirk Behme 
Signed-off-by: Daniel Thompson 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
---
 drivers/tty/serial/imx.c | 29 -
 1 file changed, 4 insertions(+), 25 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 044e86d..983668a 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -80,6 +80,7 @@
 #define URXD_FRMERR(1<<12)
 #define URXD_BRK   (1<<11)
 #define URXD_PRERR (1<<10)
+#define URXD_RX_DATA   (0xFF<<0)
 #define UCR1_ADEN  (1<<15) /* Auto detect interrupt */
 #define UCR1_ADBR  (1<<14) /* Auto detect baud rate */
 #define UCR1_TRDYEN(1<<13) /* Transmitter ready interrupt enable */
@@ -1506,32 +1507,10 @@ imx_verify_port(struct uart_port *port, struct 
serial_struct *ser)
 #if defined(CONFIG_CONSOLE_POLL)
 static int imx_poll_get_char(struct uart_port *port)
 {
-   struct imx_port_ucrs old_ucr;
-   unsigned int status;
-   unsigned char c;
-
-   /* save control registers */
-   imx_port_ucrs_save(port, _ucr);
-
-   /* disable interrupts */
-   writel(UCR1_UARTEN, port->membase + UCR1);
-   writel(old_ucr.ucr2 & ~(UCR2_ATEN | UCR2_RTSEN | UCR2_ESCI),
-  port->membase + UCR2);
-   writel(old_ucr.ucr3 & ~(UCR3_DCD | UCR3_RI | UCR3_DTREN),
-  port->membase + UCR3);
-
-   /* poll */
-   do {
-   status = readl(port->membase + USR2);
-   } while (~status & USR2_RDR);
-
-   /* read */
-   c = readl(port->membase + URXD0);
-
-   /* restore control registers */
-   imx_port_ucrs_restore(port, _ucr);
+   if (!(readl(port->membase + USR2) & USR2_RDR))
+   return NO_POLL_CHAR;
 
-   return c;
+   return readl(port->membase + URXD0) & URXD_RX_DATA;
 }
 
 static void imx_poll_put_char(struct uart_port *port, unsigned char c)
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 17/19] serial: asc: Adopt readl_/writel_relaxed()

[Daniel Thompson]

The architectures where this peripheral exists (ARM and SH) have expensive
implementations of writel(), reliant on spin locks and explicit L2 cache
management. These architectures provide a cheaper writel_relaxed() which
is much better suited to peripherals that do not perform DMA. The
situation with readl()/readl_relaxed()is similar although less acute.

This driver does not use DMA and will be more power efficient and more
robust (due to absense of spin locks during console I/O) if it uses the
relaxed variants.

This change means the driver is no longer portable and therefore no
longer suitable for compile testing.

Signed-off-by: Daniel Thompson 
Cc: Srinivas Kandagatla 
Cc: Maxime Coquelin 
Cc: Patrice Chotard 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: ker...@stlinux.com
Cc: linux-ser...@vger.kernel.org
---
 drivers/tty/serial/Kconfig  | 2 +-
 drivers/tty/serial/st-asc.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 26cec64d..e9b1735 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1527,7 +1527,7 @@ config SERIAL_FSL_LPUART_CONSOLE
 config SERIAL_ST_ASC
tristate "ST ASC serial port support"
select SERIAL_CORE
-   depends on ARM || COMPILE_TEST
+   depends on ARM
help
  This driver is for the on-chip Asychronous Serial Controller on
  STMicroelectronics STi SoCs.
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index 2b5eb6e..df709ee 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -152,12 +152,12 @@ static inline struct asc_port *to_asc_port(struct 
uart_port *port)
 
 static inline u32 asc_in(struct uart_port *port, u32 offset)
 {
-   return readl(port->membase + offset);
+   return readl_relaxed(port->membase + offset);
 }
 
 static inline void asc_out(struct uart_port *port, u32 offset, u32 value)
 {
-   writel(value, port->membase + offset);
+   writel_relaxed(value, port->membase + offset);
 }
 
 /*
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 19/19] serial: imx: Add support for KGDB's FIQ/NMI mode

[Daniel Thompson]

This patch makes it possible to use the imx uart with KGDB's FIQ/NMI
mode.

Main changes are:

.poll_init() will, if KGDB+FIQ are enabled, perform deeper hardware
initialization to ensure the serial port is always active (required
otherwise FIQ is not triggered by UART activity). This has an impact on
power usage so it is conservatively enabled.

imx_put_poll_char() has been simplified to remove the code to disable
interrupts. The present code can corrupt register state when re-entered
from FIQ handler.

Both imx_put_poll_char() and imx_get_poll_char() adopt _relaxed()
MMIO functions (which are safe for polled I/O and needed to avoid taking
spin locks).

Signed-off-by: Daniel Thompson 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
Acked-by: Dirk Behme 
---
 drivers/tty/serial/imx.c | 71 +++-
 1 file changed, 52 insertions(+), 19 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 983668a..a201c61 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1505,44 +1506,73 @@ imx_verify_port(struct uart_port *port, struct 
serial_struct *ser)
 }
 
 #if defined(CONFIG_CONSOLE_POLL)
+
+#if defined(CONFIG_KGDB_FIQ)
+/*
+ * Prepare the UART to be used from kgdb's NMI support.
+ */
+static int imx_poll_init(struct uart_port *port)
+{
+   struct imx_port *sport = (struct imx_port *)port;
+   unsigned long flags;
+   unsigned long temp;
+   int retval;
+
+   retval = clk_prepare_enable(sport->clk_ipg);
+   if (retval)
+   return retval;
+   retval = clk_prepare_enable(sport->clk_per);
+   if (retval)
+   clk_disable_unprepare(sport->clk_ipg);
+
+   imx_setup_ufcr(sport, 0);
+
+   spin_lock_irqsave(>port.lock, flags);
+
+   temp = readl(sport->port.membase + UCR1);
+   if (is_imx1_uart(sport))
+   temp |= IMX1_UCR1_UARTCLKEN;
+   temp |= UCR1_UARTEN | UCR1_RRDYEN;
+   temp &= ~(UCR1_TXMPTYEN | UCR1_RTSDEN);
+   writel(temp, sport->port.membase + UCR1);
+
+   temp = readl(sport->port.membase + UCR2);
+   temp |= UCR2_RXEN;
+   writel(temp, sport->port.membase + UCR2);
+
+   spin_unlock_irqrestore(>port.lock, flags);
+
+   /* register the FIQ with kgdb */
+   kgdb_register_fiq(sport->port.irq);
+
+   return 0;
+}
+#endif /* CONFIG_KGDB_FIQ */
+
 static int imx_poll_get_char(struct uart_port *port)
 {
-   if (!(readl(port->membase + USR2) & USR2_RDR))
+   if (!(readl_relaxed(port->membase + USR2) & USR2_RDR))
return NO_POLL_CHAR;
 
-   return readl(port->membase + URXD0) & URXD_RX_DATA;
+   return readl_relaxed(port->membase + URXD0) & URXD_RX_DATA;
 }
 
 static void imx_poll_put_char(struct uart_port *port, unsigned char c)
 {
-   struct imx_port_ucrs old_ucr;
unsigned int status;
 
-   /* save control registers */
-   imx_port_ucrs_save(port, _ucr);
-
-   /* disable interrupts */
-   writel(UCR1_UARTEN, port->membase + UCR1);
-   writel(old_ucr.ucr2 & ~(UCR2_ATEN | UCR2_RTSEN | UCR2_ESCI),
-  port->membase + UCR2);
-   writel(old_ucr.ucr3 & ~(UCR3_DCD | UCR3_RI | UCR3_DTREN),
-  port->membase + UCR3);
-
/* drain */
do {
-   status = readl(port->membase + USR1);
+   status = readl_relaxed(port->membase + USR1);
} while (~status & USR1_TRDY);
 
/* write */
-   writel(c, port->membase + URTX0);
+   writel_relaxed(c, port->membase + URTX0);
 
/* flush */
do {
-   status = readl(port->membase + USR2);
+   status = readl_relaxed(port->membase + USR2);
} while (~status & USR2_TXDC);
-
-   /* restore control registers */
-   imx_port_ucrs_restore(port, _ucr);
 }
 #endif
 
@@ -1563,6 +1593,9 @@ static struct uart_ops imx_pops = {
.config_port= imx_config_port,
.verify_port= imx_verify_port,
 #if defined(CONFIG_CONSOLE_POLL)
+#if defined(CONFIG_KGDB_FIQ)
+   .poll_init  = imx_poll_init,
+#endif
.poll_get_char  = imx_poll_get_char,
.poll_put_char  = imx_poll_put_char,
 #endif
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: lustre: declare some functions as static

[Zheng Di]

Declare these functions as static:
llog_alloc_handle() is used in llog_open() only.
llog_free_handle() is used in llog_close() only.

Signed-off-by: Zheng Di 
---
 drivers/staging/lustre/lustre/obdclass/llog.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/obdclass/llog.c 
b/drivers/staging/lustre/lustre/obdclass/llog.c
index cce8689..ebdc42f 100644
--- a/drivers/staging/lustre/lustre/obdclass/llog.c
+++ b/drivers/staging/lustre/lustre/obdclass/llog.c
@@ -56,7 +56,7 @@
  * Allocate a new log or catalog handle
  * Used inside llog_open().
  */
-struct llog_handle *llog_alloc_handle(void)
+static struct llog_handle *llog_alloc_handle(void)
 {
struct llog_handle *loghandle;
 
@@ -75,7 +75,7 @@ struct llog_handle *llog_alloc_handle(void)
 /*
  * Free llog handle and header data if exists. Used in llog_close() only
  */
-void llog_free_handle(struct llog_handle *loghandle)
+static void llog_free_handle(struct llog_handle *loghandle)
 {
LASSERT(loghandle != NULL);
 
-- 
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 v11 14/19] serial: amba-pl011: Move pl011_hwinit()

[Daniel Thompson]

This patch hoists pl011_hwinit() further up within the driver. This
permits a later patch to introduce an extended .poll_init callback
that does more than pure hardware initialization.

Signed-off-by: Daniel Thompson 
Cc: Russell King 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
---
 drivers/tty/serial/amba-pl011.c | 78 -
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 02016fc..0b06dcf 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1425,6 +1425,45 @@ static void pl011_break_ctl(struct uart_port *port, int 
break_state)
spin_unlock_irqrestore(>port.lock, flags);
 }
 
+static int pl011_hwinit(struct uart_port *port)
+{
+   struct uart_amba_port *uap =
+   container_of(port, struct uart_amba_port, port);
+   int retval;
+
+   /* Optionaly enable pins to be muxed in and configured */
+   pinctrl_pm_select_default_state(port->dev);
+
+   /*
+* Try to enable the clock producer.
+*/
+   retval = clk_prepare_enable(uap->clk);
+   if (retval)
+   return retval;
+
+   uap->port.uartclk = clk_get_rate(uap->clk);
+
+   /* Clear pending error and receive interrupts */
+   writew(UART011_OEIS | UART011_BEIS | UART011_PEIS | UART011_FEIS |
+  UART011_RTIS | UART011_RXIS, uap->port.membase + UART011_ICR);
+
+   /*
+* Save interrupts enable mask, and enable RX interrupts in case if
+* the interrupt is used for NMI entry.
+*/
+   uap->im = readw(uap->port.membase + UART011_IMSC);
+   writew(UART011_RTIM | UART011_RXIM, uap->port.membase + UART011_IMSC);
+
+   if (dev_get_platdata(uap->port.dev)) {
+   struct amba_pl011_data *plat;
+
+   plat = dev_get_platdata(uap->port.dev);
+   if (plat->init)
+   plat->init();
+   }
+   return 0;
+}
+
 #ifdef CONFIG_CONSOLE_POLL
 
 static void pl011_quiesce_irqs(struct uart_port *port)
@@ -1483,45 +1522,6 @@ static void pl011_put_poll_char(struct uart_port *port,
 
 #endif /* CONFIG_CONSOLE_POLL */
 
-static int pl011_hwinit(struct uart_port *port)
-{
-   struct uart_amba_port *uap =
-   container_of(port, struct uart_amba_port, port);
-   int retval;
-
-   /* Optionaly enable pins to be muxed in and configured */
-   pinctrl_pm_select_default_state(port->dev);
-
-   /*
-* Try to enable the clock producer.
-*/
-   retval = clk_prepare_enable(uap->clk);
-   if (retval)
-   return retval;
-
-   uap->port.uartclk = clk_get_rate(uap->clk);
-
-   /* Clear pending error and receive interrupts */
-   writew(UART011_OEIS | UART011_BEIS | UART011_PEIS | UART011_FEIS |
-  UART011_RTIS | UART011_RXIS, uap->port.membase + UART011_ICR);
-
-   /*
-* Save interrupts enable mask, and enable RX interrupts in case if
-* the interrupt is used for NMI entry.
-*/
-   uap->im = readw(uap->port.membase + UART011_IMSC);
-   writew(UART011_RTIM | UART011_RXIM, uap->port.membase + UART011_IMSC);
-
-   if (dev_get_platdata(uap->port.dev)) {
-   struct amba_pl011_data *plat;
-
-   plat = dev_get_platdata(uap->port.dev);
-   if (plat->init)
-   plat->init();
-   }
-   return 0;
-}
-
 static void pl011_write_lcr_h(struct uart_amba_port *uap, unsigned int lcr_h)
 {
writew(lcr_h, uap->port.membase + uap->lcrh_rx);
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 11/19] irqchip: vic: Add support for FIQ management

[Daniel Thompson]

This patch introduces callbacks to route interrupts to or away
from the FIQ signal. It also causes these callbacks to be registered
with the FIQ infrastructure.

This patch enable FIQ support for mach-versatile whilst mach-ep93xx,
mach-netx, mach-s3c64xx and plat-samsung are unmodified (and can therefore
continue to use init_FIQ() as before).

Signed-off-by: Daniel Thompson 
Cc: Hartley Sweeten 
Cc: Ryan Mallon 
Cc: Russell King 
Cc: Ben Dooks 
Cc: Kukjin Kim 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: linux-samsung-...@vger.kernel.org
---
 arch/arm/mach-versatile/core.c  |  2 +-
 drivers/irqchip/irq-gic.c   | 21 --
 drivers/irqchip/irq-vic.c   | 92 -
 include/linux/irqchip/arm-gic.h |  3 ++
 include/linux/irqchip/arm-vic.h |  6 ++-
 5 files changed, 88 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 08fb8c8..bad1d30 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -108,7 +108,7 @@ void __init versatile_init_irq(void)
 
np = of_find_matching_node_by_address(NULL, vic_of_match,
  VERSATILE_VIC_BASE);
-   __vic_init(VA_VIC_BASE, 0, IRQ_VIC_START, ~0, 0, np);
+   __vic_init(VA_VIC_BASE, 0, IRQ_VIC_START, ~0, 0, np ? false : true, np);
 
writel(~0, VA_SIC_BASE + SIC_IRQ_ENABLE_CLEAR);
 
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index bda5a91..8821160 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -502,13 +502,17 @@ static void __init gic_init_fiq(struct gic_chip_data *gic,
 /*
  * Fully acknowledge (both ack and eoi) a FIQ-based IPI
  */
-static int gic_handle_fiq_ipi(struct notifier_block *nb, unsigned long regs,
-  void *data)
+void gic_handle_fiq_ipi(void)
 {
struct gic_chip_data *gic = _data[0];
-   void __iomem *cpu_base = gic_data_cpu_base(gic);
+   void __iomem *cpu_base;
unsigned long irqstat, irqnr;
 
+   if (!gic || !gic->fiq_enable)
+   return;
+
+   cpu_base = gic_data_cpu_base(gic);
+
if (WARN_ON(!in_nmi()))
return NOTIFY_BAD;
 
@@ -525,13 +529,6 @@ static int gic_handle_fiq_ipi(struct notifier_block *nb, 
unsigned long regs,
 
return NOTIFY_OK;
 }
-
-/*
- * Notifier to ensure IPI FIQ is acknowledged correctly.
- */
-static struct notifier_block gic_fiq_ipi_notifier = {
-   .notifier_call = gic_handle_fiq_ipi,
-};
 #else /* CONFIG_FIQ */
 static inline void gic_set_group_irq(void __iomem *base, unsigned int hwirq,
 int group) {}
@@ -1250,10 +1247,6 @@ void __init gic_init_bases(unsigned int gic_nr, int 
irq_start,
 #ifdef CONFIG_SMP
set_smp_cross_call(gic_raise_softirq);
register_cpu_notifier(_cpu_notifier);
-#ifdef CONFIG_FIQ
-   if (gic_data_fiq_enable(gic))
-   register_fiq_nmi_notifier(_fiq_ipi_notifier);
-#endif
 #endif
set_handle_irq(gic_handle_irq);
}
diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c
index 7d35287..22aa126 100644
--- a/drivers/irqchip/irq-vic.c
+++ b/drivers/irqchip/irq-vic.c
@@ -36,6 +36,9 @@
 
 #include 
 #include 
+#ifdef CONFIG_FIQ
+#include 
+#endif
 
 #include "irqchip.h"
 
@@ -261,11 +264,53 @@ static struct irq_domain_ops vic_irqdomain_ops = {
.xlate = irq_domain_xlate_onetwocell,
 };
 
+#ifdef CONFIG_FIQ
+static DEFINE_RAW_SPINLOCK(irq_controller_lock);
+
+static void vic_set_fiq(struct irq_data *d, bool enable)
+{
+   void __iomem *base = irq_data_get_irq_chip_data(d);
+   unsigned int irq = d->hwirq;
+   u32 val;
+
+   raw_spin_lock(_controller_lock);
+   val = readl(base + VIC_INT_SELECT);
+   if (enable)
+   val |= 1 << irq;
+   else
+   val &= ~(1 << irq);
+   writel(val, base + VIC_INT_SELECT);
+   raw_spin_unlock(_controller_lock);
+}
+
+static void vic_enable_fiq(struct irq_data *d)
+{
+   vic_set_fiq(d, true);
+}
+
+static void vic_disable_fiq(struct irq_data *d)
+{
+   vic_set_fiq(d, false);
+}
+
+struct fiq_chip vic_fiq = {
+   .fiq_enable = vic_enable_fiq,
+   .fiq_disable = vic_disable_fiq,
+};
+
+static void vic_register_fiq(int irq)
+{
+   fiq_register_mapping(irq, _fiq);
+}
+#else /* CONFIG_FIQ */
+static inline void vic_register_fiq(int irq) {}
+#endif /* CONFIG_FIQ */
+
 /**
  * vic_register() - Register a VIC.
  * @base: The base address of the VIC.
  * @parent_irq: The parent IRQ if cascaded, else 0.
- * @irq: The base IRQ for the VIC.
+ * @irq_start: The base IRQ for the VIC.
  * @valid_sources: bitmask of valid interrupts
  * @resume_sources: bitmask of interrupts allowed for resume sources.
  * @node: The device tree node associated with the VIC.
@@ -277,12 +322,13 @@ static struct irq_domain_ops vic_irqdomain_ops = {
  * This also configures 

[PATCH v11 02/19] arm: fiq: Allow ACK and EOI to be passed to the intc

[Daniel Thompson]

Modern ARM interrupt controllers require an ACK as interrupts are taken
and an EOI on completion. The FIQ code currently does not provide any
API to perform this.

This patch provides this API, implemented by adding two callbacks to the
fiq_chip structure.

Signed-off-by: Daniel Thompson 
Acked-by: Nicolas Pitre 
Cc: Russell King 
Cc: Fabio Estevam 
---
 arch/arm/include/asm/fiq.h |  9 +
 arch/arm/kernel/fiq.c  | 19 +++
 2 files changed, 28 insertions(+)

diff --git a/arch/arm/include/asm/fiq.h b/arch/arm/include/asm/fiq.h
index ed44528..a25c952 100644
--- a/arch/arm/include/asm/fiq.h
+++ b/arch/arm/include/asm/fiq.h
@@ -22,6 +22,13 @@
 struct fiq_chip {
void (*fiq_enable)(struct irq_data *data);
void (*fiq_disable)(struct irq_data *data);
+
+   /* .fiq_ack() and .fiq_eoi() will be called from the FIQ
+* handler. For this reason they must not use spin locks (or any
+* other locks).
+*/
+   int (*fiq_ack)(struct irq_data *data);
+   void (*fiq_eoi)(struct irq_data *data);
 };
 
 struct fiq_handler {
@@ -44,6 +51,8 @@ extern void release_fiq(struct fiq_handler *f);
 extern void set_fiq_handler(void *start, unsigned int length);
 extern void enable_fiq(int fiq);
 extern void disable_fiq(int fiq);
+extern int ack_fiq(int fiq);
+extern void eoi_fiq(int fiq);
 extern bool has_fiq(int fiq);
 extern void fiq_register_mapping(int irq, struct fiq_chip *chip);
 
diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index 5d831cf..3ccaa8c 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -183,6 +183,25 @@ void disable_fiq(int fiq)
disable_irq(fiq + fiq_start);
 }
 
+int ack_fiq(int fiq)
+{
+   struct fiq_data *data = lookup_fiq_data(fiq);
+
+   if (data && data->fiq_chip->fiq_ack)
+   return data->fiq_chip->fiq_ack(data->irq_data);
+
+   return fiq;
+}
+
+void eoi_fiq(int fiq)
+{
+   struct fiq_data *data = lookup_fiq_data(fiq);
+
+   if (data && data->fiq_chip->fiq_eoi)
+   data->fiq_chip->fiq_eoi(data->irq_data);
+}
+EXPORT_SYMBOL(eoi_fiq);
+
 bool has_fiq(int fiq)
 {
struct fiq_data *data = lookup_fiq_data(fiq);
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 03/19] arm: fiq: Replace default FIQ handler

[Daniel Thompson]

This patch introduces a new default FIQ handler that is structured in a
similar way to the existing ARM exception handler and result in the FIQ
being handled by C code running on the SVC stack (despite this code run
in the FIQ handler is subject to severe limitations with respect to
locking making normal interaction with the kernel impossible).

This default handler allows concepts that on x86 would be handled using
NMIs to be realized on ARM.

Credit:

This patch is a near complete re-write of a patch originally
provided by Anton Vorontsov. Today only a couple of small fragments
survive, however without Anton's work to build from this patch would
not exist.

Signed-off-by: Daniel Thompson 
Cc: Russell King 
Cc: Nicolas Pitre 
Cc: Catalin Marinas 
---
 arch/arm/kernel/entry-armv.S | 129 +++
 arch/arm/kernel/fiq.c|  19 +++
 arch/arm/kernel/setup.c  |   8 ++-
 3 files changed, 145 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 36276cd..ef64333 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -79,6 +79,15 @@
 #endif
.endm
 
+   .macro  fiq_handler
+   ldr r1, =.LChandle_fiq
+   mov r0, sp
+   adr lr, BSYM(9998f)
+   ldr pc, [r1]
+9998:
+   .endm
+
+
 #ifdef CONFIG_KPROBES
.section.kprobes.text,"ax",%progbits
 #else
@@ -146,7 +155,7 @@ ENDPROC(__und_invalid)
 #define SPFIX(code...)
 #endif
 
-   .macro  svc_entry, stack_hole=0
+   .macro  svc_entry, stack_hole=0, call_trace=1
  UNWIND(.fnstart   )
  UNWIND(.save {r0 - pc})
sub sp, sp, #(S_FRAME_SIZE + \stack_hole - 4)
@@ -183,10 +192,35 @@ ENDPROC(__und_invalid)
stmia   r7, {r2 - r6}
 
 #ifdef CONFIG_TRACE_IRQFLAGS
+   .if \call_trace
bl  trace_hardirqs_off
+   .endif
 #endif
.endm
 
+@
+@ svc_exit_via_fiq - similar to svc_exit but switches to FIQ mode before exit
+@
+@ This macro acts in a similar manner to svc_exit but switches to FIQ
+@ mode to restore the final part of the register state.
+@
+@ We cannot use the normal svc_exit procedure because that would
+@ clobber spsr_svc (FIQ could be delivered during the first few instructions
+@ of vector_swi meaning its contents have not been saved anywhere).
+@
+   .macro  svc_exit_via_fiq, rpsr
+
+   mov r0, sp
+   ldmib   r0, {r1 - r14}  @ abort is deadly from here onward (it will
+   @ clobber state restored below)
+   msr cpsr_c, #FIQ_MODE | PSR_I_BIT | PSR_F_BIT
+   add r8, r0, #S_PC
+   ldr r9, [r0, #S_PSR]
+   msr spsr_cxsf, r9
+   ldr r0, [r0, #S_R0]
+   ldmia   r8, {pc}^
+   .endm
+
.align  5
 __dabt_svc:
svc_entry
@@ -295,6 +329,14 @@ __pabt_svc:
 ENDPROC(__pabt_svc)
 
.align  5
+__fiq_svc:
+   svc_entry 0, 0
+   fiq_handler
+   svc_exit_via_fiq r5
+ UNWIND(.fnend )
+ENDPROC(__fiq_svc)
+
+   .align  5
 .LCcralign:
.word   cr_alignment
 #ifdef MULTI_DABORT
@@ -303,6 +345,43 @@ ENDPROC(__pabt_svc)
 #endif
 .LCfp:
.word   fp_enter
+.LChandle_fiq:
+#ifdef CONFIG_FIQ
+   .word   fiq_nmi_handler
+#else
+   .word   do_unexp_fiq
+#endif
+
+/*
+ * Abort mode handlers
+ */
+
+@
+@ Taking a FIQ in abort mode is similar to taking a FIQ in SVC mode
+@ and reuses the same macros. However in abort mode we must also
+@ save/restore lr_abt and spsr_abt to make nested aborts safe.
+@
+   .align 5
+__fiq_abt:
+   svc_entry 0, 0
+
+   msr cpsr_c, #ABT_MODE | PSR_I_BIT | PSR_F_BIT
+   mov r0, lr  @ Save lr_abt
+   mrs r1, spsr@ Save spsr_abt, abort is now safe
+   msr cpsr_c, #SVC_MODE | PSR_I_BIT | PSR_F_BIT
+   push{r0 - r1}
+
+   fiq_handler
+
+   pop {r0 - r1}
+   msr cpsr_c, #ABT_MODE | PSR_I_BIT | PSR_F_BIT
+   mov lr, r0  @ Restore lr_abt, abort is unsafe
+   msr spsr_cxsf, r1   @ Restore spsr_abt
+   msr cpsr_c, #SVC_MODE | PSR_I_BIT | PSR_F_BIT
+
+   svc_exit_via_fiq r5
+ UNWIND(.fnend )
+ENDPROC(__fiq_svc)
 
 /*
  * User mode handlers
@@ -683,6 +762,17 @@ ENTRY(ret_from_exception)
 ENDPROC(__pabt_usr)
 ENDPROC(ret_from_exception)
 
+   .align  5
+__fiq_usr:
+   usr_entry
+   kuser_cmpxchg_check
+   fiq_handler
+   get_thread_info tsk
+   mov why, #0
+   b   ret_to_user_from_irq
+ UNWIND(.fnend )
+ENDPROC(__fiq_usr)
+
 /*
  * Register switch for ARMv3 and ARMv4 processors
  * r0 = previous task_struct, r1 = previous thread_info, r2 = next thread_info
@@ -1118,17 +1208,36 @@ vector_addrexcptn:
b   vector_addrexcptn
 
 /*=
- * Undefined FIQs
+ * FIQ "NMI" handler
  

[PATCH v11 06/19] irqchip: gic: Provide support for interrupt grouping

[Daniel Thompson]

All GIC hardware except GICv1-without-TrustZone support provides a means
to group exceptions into group 0 (which can optionally be signally using
use FIQ) and group 1. The kernel currently provides no means to exploit
this. This patch alters the initialization of the GIC to place all
interrupts into group 1 which is the foundational requirement to meaningfully
use FIQ.

Note that the hardware functionality is unavailable to the kernel when a
secure monitor is present because access to the grouping registers are
prohibited outside "secure world" (this feature allows grouping to be
used to allow hardware peripherals to send interrupts into the secure
world). The GIC driver will automatically detect this and disable its
attempts to group interrupts.

On systems without TrustZone support the kernel has the power to route
interrupt sources to FIQ, potentially allowing a driver to exploit the
NMI-like properties of FIQ.

Tested on Freescale i.MX6 (quad A9), STiH416 (dual A9) and a self-written
qemu GICv2 model.

Signed-off-by: Daniel Thompson 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Nicolas Pitre 
Cc: Christoffer Dall 
Cc: Sricharan R 
Cc: Marc Zyngier 
Acked-by: Dirk Behme 
---
 drivers/irqchip/irq-gic.c | 99 ---
 1 file changed, 94 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 4b959e6..423707c 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -41,6 +41,9 @@
 #include 
 
 #include 
+#ifdef CONFIG_FIQ
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -68,6 +71,9 @@ struct gic_chip_data {
 #ifdef CONFIG_GIC_NON_BANKED
void __iomem *(*get_base)(union gic_base *);
 #endif
+#ifdef CONFIG_FIQ
+   bool fiq_enable;
+#endif
 };
 
 static DEFINE_RAW_SPINLOCK(irq_controller_lock);
@@ -131,6 +137,16 @@ static inline void gic_set_base_accessor(struct 
gic_chip_data *data,
 #define gic_set_base_accessor(d, f)
 #endif
 
+#ifdef CONFIG_FIQ
+static inline bool gic_data_fiq_enable(struct gic_chip_data *data)
+{
+   return data->fiq_enable;
+}
+#else
+static inline bool gic_data_fiq_enable(
+   struct gic_chip_data *data) { return false; }
+#endif
+
 static inline void __iomem *gic_dist_base(struct irq_data *d)
 {
struct gic_chip_data *gic_data = irq_data_get_irq_chip_data(d);
@@ -325,6 +341,42 @@ static struct irq_chip gic_chip = {
.irq_set_wake   = gic_set_wake,
 };
 
+#ifdef CONFIG_FIQ
+static void __init gic_init_fiq(struct gic_chip_data *gic,
+   irq_hw_number_t first_irq,
+   unsigned int num_irqs)
+{
+   void __iomem *dist_base = gic_data_dist_base(gic_data);
+   unsigned int i;
+
+   /*
+* FIQ can only be supported on platforms without an extended irq_eoi
+* method (otherwise we take a lock during eoi handling).
+*/
+   if (gic_arch_extn.irq_eoi)
+   return;
+
+   /*
+* If grouping is not available (not implemented or prohibited by
+* security mode) these registers a read-as-zero/write-ignored.
+* However as a precaution we restore the reset default regardless of
+* the result of the test.
+*/
+   writel_relaxed(1, dist_base + GIC_DIST_IGROUP + 0);
+   gic->fiq_enable = readl_relaxed(dist_base + GIC_DIST_IGROUP + 0);
+   writel_relaxed(0, dist_base + GIC_DIST_IGROUP + 0);
+   pr_debug("gic: FIQ support %s\n",
+gic->fiq_enable ? "enabled" : "disabled");
+
+   if (!gic->fiq_enable)
+   return;
+}
+#else /* CONFIG_FIQ */
+static inline void gic_init_fiq(struct gic_chip_data *gic,
+   irq_hw_number_t first_irq,
+   unsigned int num_irqs) {}
+#endif /* CONFIG_FIQ */
+
 void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
 {
if (gic_nr >= MAX_GIC_NR)
@@ -373,7 +425,22 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
 
gic_dist_config(base, gic_irqs, NULL);
 
-   writel_relaxed(1, base + GIC_DIST_CTRL);
+   /*
+* Optionally set all global interrupts to be group 1.
+*/
+   if (gic_data_fiq_enable(gic))
+   for (i = 32; i < gic_irqs; i += 32)
+   writel_relaxed(0x,
+  base + GIC_DIST_IGROUP + i * 4 / 32);
+
+   /*
+* Set EnableGrp1/EnableGrp0 (bit 1 and 0) or EnableGrp (bit 0 only,
+* bit 1 ignored)
+*/
+   if (gic_data_fiq_enable(gic))
+   writel_relaxed(3, base + GIC_DIST_CTRL);
+   else
+   writel_relaxed(1, base + GIC_DIST_CTRL);
 }
 
 static void gic_cpu_init(struct gic_chip_data *gic)
@@ -400,8 +467,20 @@ static void gic_cpu_init(struct gic_chip_data *gic)
 
gic_cpu_config(dist_base, NULL);
 
+   /*
+* Set all PPI and SGI interrupts to be group 1.
+*
+

[PATCH v11 09/19] irqchip: gic: Add support for IPI FIQ

[Daniel Thompson]

To support IPI FIQ we alter gic_cpu_init() to honour SMP_IPI_FIQ_MASK and
register a fairly high priority notifier to acknowledge and clear the IPI
when it is triggered.

For the IPI FIQ to be useful we must also make it safe to call
gic_raise_softirq() from the FIQ handler by altering the locking
strategy slightly.

Signed-off-by: Daniel Thompson 
---
 arch/arm/kernel/fiq.c |   3 ++
 drivers/irqchip/irq-gic.c | 125 ++
 2 files changed, 107 insertions(+), 21 deletions(-)

diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index c6b3bed..115d319 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -232,6 +232,9 @@ asmlinkage void __exception_irq_entry 
fiq_nmi_handler(struct pt_regs *regs)
 #ifdef CONFIG_KGDB_FIQ
kgdb_handle_fiq(regs);
 #endif
+#ifdef CONFIG_ARM_GIC
+   gic_handle_fiq_ipi();
+#endif
 
nmi_exit();
set_irq_regs(old_regs);
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d928912..8834749 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #ifdef CONFIG_FIQ
@@ -51,6 +52,10 @@
 #include "irq-gic-common.h"
 #include "irqchip.h"
 
+#ifndef SMP_IPI_FIQ_MASK
+#define SMP_IPI_FIQ_MASK 0
+#endif
+
 union gic_base {
void __iomem *common_base;
void __percpu * __iomem *percpu_base;
@@ -77,6 +82,8 @@ struct gic_chip_data {
 };
 
 static DEFINE_RAW_SPINLOCK(irq_controller_lock);
+/* A fiq-safe spinlock must only be locked when the FIQ is masked */
+static DEFINE_RAW_SPINLOCK(fiq_safe_migration_lock);
 
 /*
  * The GIC mapping of CPU interfaces does not necessarily match
@@ -346,20 +353,21 @@ static struct irq_chip gic_chip = {
  * match what "ARM strongly recommends" for a system where no Group 1
  * interrupt must ever preempt a Group 0 interrupt.
  */
-static void gic_set_group_irq(struct irq_data *d, int group)
+static void gic_set_group_irq(void __iomem *base, unsigned int hwirq,
+   int group)
 {
-   unsigned int grp_reg = gic_irq(d) / 32 * 4;
-   u32 grp_mask = 1 << (gic_irq(d) % 32);
+   unsigned int grp_reg = hwirq / 32 * 4;
+   u32 grp_mask = 1 << (hwirq % 32);
u32 grp_val;
 
-   unsigned int pri_reg = (gic_irq(d) / 4) * 4;
-   u32 pri_mask = 1 << (7 + ((gic_irq(d) % 4) * 8));
+   unsigned int pri_reg = (hwirq / 4) * 4;
+   u32 pri_mask = 1 << (7 + ((hwirq % 4) * 8));
u32 pri_val;
 
raw_spin_lock(_controller_lock);
 
-   grp_val = readl_relaxed(gic_dist_base(d) + GIC_DIST_IGROUP + grp_reg);
-   pri_val = readl_relaxed(gic_dist_base(d) + GIC_DIST_PRI + pri_reg);
+   grp_val = readl_relaxed(base + GIC_DIST_IGROUP + grp_reg);
+   pri_val = readl_relaxed(base + GIC_DIST_PRI + pri_reg);
 
if (group) {
grp_val |= grp_mask;
@@ -369,20 +377,20 @@ static void gic_set_group_irq(struct irq_data *d, int 
group)
pri_val &= ~pri_mask;
}
 
-   writel_relaxed(grp_val, gic_dist_base(d) + GIC_DIST_IGROUP + grp_reg);
-   writel_relaxed(pri_val, gic_dist_base(d) + GIC_DIST_PRI + pri_reg);
+   writel_relaxed(grp_val, base + GIC_DIST_IGROUP + grp_reg);
+   writel_relaxed(pri_val, base + GIC_DIST_PRI + pri_reg);
 
raw_spin_unlock(_controller_lock);
 }
 
 static void gic_enable_fiq(struct irq_data *d)
 {
-   gic_set_group_irq(d, 0);
+   gic_set_group_irq(gic_dist_base(d), gic_irq(d), 0);
 }
 
 static void gic_disable_fiq(struct irq_data *d)
 {
-   gic_set_group_irq(d, 1);
+   gic_set_group_irq(gic_dist_base(d), gic_irq(d), 1);
 }
 
 static int gic_ack_fiq(struct irq_data *d)
@@ -390,8 +398,22 @@ static int gic_ack_fiq(struct irq_data *d)
struct gic_chip_data *gic = irq_data_get_irq_chip_data(d);
u32 irqstat, irqnr;
 
-   irqstat = readl_relaxed(gic_data_cpu_base(gic) + GIC_CPU_INTACK);
-   irqnr = irqstat & GICC_IAR_INT_ID_MASK;
+   while (1) {
+   writel_relaxed(0x70, gic_data_cpu_base(gic) + GIC_CPU_PRIMASK);
+   irqstat =
+   readl_relaxed(gic_data_cpu_base(gic) + GIC_CPU_INTACK);
+   writel_relaxed(0xf0, gic_data_cpu_base(gic) + GIC_CPU_PRIMASK);
+
+   irqnr = irqstat & GICC_IAR_INT_ID_MASK;
+   if (irqnr > 15)
+   break;
+
+   /* we've got an IPI which we can simply acknowledge
+* and move on
+*/
+   gic_eoi_irq(d);
+   }
+
return irq_find_mapping(gic->domain, irqnr);
 }
 
@@ -430,7 +452,43 @@ static void __init gic_init_fiq(struct gic_chip_data *gic,
for (i = 0; i < num_irqs; i++)
fiq_register_mapping(first_irq + i, _fiq);
 }
+
+/*
+ * Fully acknowledge (both ack and eoi) a FIQ-based IPI
+ */
+static int gic_handle_fiq_ipi(struct notifier_block *nb, unsigned long regs,
+ 

[PATCH v11 07/19] irqchip: gic: Add support for FIQ management

[Daniel Thompson]

This patch introduces callbacks to route interrupts to or away
from the FIQ signal and registers these callbacks with the FIQ
infrastructure (if the device can supports it).

Both these aspects combine and allow a driver to deploy a FIQ handler
without any machine specific knowledge; it can be used effectively on
multi-platform kernels.

Signed-off-by: Daniel Thompson 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Nicolas Pitre 
Cc: Christoffer Dall 
Cc: Sricharan R 
---
 drivers/irqchip/irq-gic.c | 69 +++
 1 file changed, 69 insertions(+)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 423707c..6fa0542 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -342,6 +342,69 @@ static struct irq_chip gic_chip = {
 };
 
 #ifdef CONFIG_FIQ
+/*
+ * Shift an interrupt between Group 0 and Group 1.
+ *
+ * In addition to changing the group we also modify the priority to
+ * match what "ARM strongly recommends" for a system where no Group 1
+ * interrupt must ever preempt a Group 0 interrupt.
+ */
+static void gic_set_group_irq(struct irq_data *d, int group)
+{
+   unsigned int grp_reg = gic_irq(d) / 32 * 4;
+   u32 grp_mask = 1 << (gic_irq(d) % 32);
+   u32 grp_val;
+
+   unsigned int pri_reg = (gic_irq(d) / 4) * 4;
+   u32 pri_mask = 1 << (7 + ((gic_irq(d) % 4) * 8));
+   u32 pri_val;
+
+   raw_spin_lock(_controller_lock);
+
+   grp_val = readl_relaxed(gic_dist_base(d) + GIC_DIST_IGROUP + grp_reg);
+   pri_val = readl_relaxed(gic_dist_base(d) + GIC_DIST_PRI + pri_reg);
+
+   if (group) {
+   grp_val |= grp_mask;
+   pri_val |= pri_mask;
+   } else {
+   grp_val &= ~grp_mask;
+   pri_val &= ~pri_mask;
+   }
+
+   writel_relaxed(grp_val, gic_dist_base(d) + GIC_DIST_IGROUP + grp_reg);
+   writel_relaxed(pri_val, gic_dist_base(d) + GIC_DIST_PRI + pri_reg);
+
+   raw_spin_unlock(_controller_lock);
+}
+
+static void gic_enable_fiq(struct irq_data *d)
+{
+   gic_set_group_irq(d, 0);
+}
+
+static void gic_disable_fiq(struct irq_data *d)
+{
+   gic_set_group_irq(d, 1);
+}
+
+static int gic_ack_fiq(struct irq_data *d)
+{
+   struct gic_chip_data *gic = irq_data_get_irq_chip_data(d);
+   u32 irqstat, irqnr;
+
+   irqstat = readl_relaxed(gic_data_cpu_base(gic) + GIC_CPU_INTACK);
+   irqnr = irqstat & GICC_IAR_INT_ID_MASK;
+   return irq_find_mapping(gic->domain, irqnr);
+}
+
+static struct fiq_chip gic_fiq = {
+   .fiq_enable = gic_enable_fiq,
+   .fiq_disable= gic_disable_fiq,
+   .fiq_ack= gic_ack_fiq,
+   .fiq_eoi= gic_eoi_irq,
+};
+
 static void __init gic_init_fiq(struct gic_chip_data *gic,
irq_hw_number_t first_irq,
unsigned int num_irqs)
@@ -370,6 +433,12 @@ static void __init gic_init_fiq(struct gic_chip_data *gic,
 
if (!gic->fiq_enable)
return;
+
+   /*
+* FIQ is supported on this device! Register our chip data.
+*/
+   for (i = 0; i < num_irqs; i++)
+   fiq_register_mapping(first_irq + i, _fiq);
 }
 #else /* CONFIG_FIQ */
 static inline void gic_init_fiq(struct gic_chip_data *gic,
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 08/19] irqchip: gic: Remove spin locks from eoi_irq

[Daniel Thompson]

This patch is motivated by the comment it removes from gic_init_fiq,
namely that the spin locks in eoi_irq preclude certain platforms from
supporting FIQ.

Currently there is only one upstream platform (tegra) that actually
hooks gic_arch_extn.irq_eoi and it does not require these spin locks.

Signed-off-by: Daniel Thompson 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Peter De Schrijver 
---
 drivers/irqchip/irq-gic.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 6fa0542..d928912 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -191,11 +191,8 @@ static void gic_unmask_irq(struct irq_data *d)
 
 static void gic_eoi_irq(struct irq_data *d)
 {
-   if (gic_arch_extn.irq_eoi) {
-   raw_spin_lock(_controller_lock);
+   if (gic_arch_extn.irq_eoi)
gic_arch_extn.irq_eoi(d);
-   raw_spin_unlock(_controller_lock);
-   }
 
writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
 }
@@ -413,13 +410,6 @@ static void __init gic_init_fiq(struct gic_chip_data *gic,
unsigned int i;
 
/*
-* FIQ can only be supported on platforms without an extended irq_eoi
-* method (otherwise we take a lock during eoi handling).
-*/
-   if (gic_arch_extn.irq_eoi)
-   return;
-
-   /*
 * If grouping is not available (not implemented or prohibited by
 * security mode) these registers a read-as-zero/write-ignored.
 * However as a precaution we restore the reset default regardless of
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 00/19] arm: KGDB NMI/FIQ support

[Daniel Thompson]

This patchset makes it possible to use kgdb's NMI infrastructure on ARM
platforms.

The patches are seperated into three distinct groups:

1. arm specific changes; these provide multi-platform support for FIQ
   (including raising an IPI using FIQ to ensure effective SMP support)
   and extend ARM KGDB support to use the features provided.

2. irqchip changes; updates to the gic and vic drivers to provide
   support for routing certain interrupt sources to FIQ.

3. serial changes; driver support to allow the UART interrupt to be
   routed to FIQ. The already mainlined kgdb NMI infrastructure (mostly
   found in drivers/tty/serial/kgdb_nmi.c) will re-route the kgdb
   console UART's interrupt signal from IRQ to FIQ. Naturally the UART
   will no longer function normally and will instead be managed by kgdb
   using the polled I/O functions. Any character delivered to the UART
   causes the kgdb handler function to be called.

Tested on qemu (versatile), STiH416 (B2020 board) and Freescale i.MX6
quad (wandboard).

Changes since v10:

- Removed use of RCU notifier chains to encourage code review by
  ensuring no driver can use FIQ without touching code in arch/arm/kernel
  (Russell King)

Changes since v9:

- Split PL011 code movement into a seperate patch (Peter Hurley)
- Use container_of() to convert pointers to uart_amba_port (Peter
  Hurley)
- Clean up redundant code from pl011_poll_init (Peter Hurley)
- Call do_unexp_fiq() if we receive a FIQ and CONFIG_FIQ is not set.
- Ensure irq-gic.c does not call FIQ functions unless CONFIG_FIQ is set.
- Introduced patch to avoid ttyNMI0 being enabled by default
  (replaces architecture dependant enable/disable logic).
- Fixed bug in kgdb_fiq_enable_nmi() that causes SysRq-g (non-NMI
  debugging) to wedge the debugger.

Changes since v8:

- Significant rework to separate the FIQ exception handler from kgdb.
  This allows other features typically implemented using NMI on x86
  to reuse the same exception handling code (Russell King)
- Reunited arch/arm and driver code into a single patch series again.
- Added support for raising IPIs using FIQ (makes kgdb quiesce must
  more robust).
- Introduced a workaround for GICv1 devices to avoid FIQs being
  spuriously handled as IRQs.

Changes since v7:

- Introduced ack_fiq() to complement eoi_fiq(). Without this it is
  not possible to meet the GIC specification (previous versions worked
  when tested but are unpredictable according to the specification).
  ack_fiq() also makes is possible for drivers for devices with multiple
  interrupt lines to discover the interrupt source correctly.

Changes since v6:

- Corrected off-by-one comparison in has_fiq() (Nicolas Pitre)
- Rewrote the FIQ stack initialization (Nicolas Pitre). This fixes a
  serious data corruption bug due to bad stack mismanagement.
- Introduced __fiq_abt to ensure lr_abt and spsr_abt are saved and
  restored if we fast-interrupt an abort (Russell King).
- Significantly improved the commenting of the exception handlers.
- Added a call to trace_hardirqs_on() if we clear the I bit as we
  exit the exception handler.

Changes since v5:

- Separated anything not strictly impacting arch/arm.
- Fixed a spurious add/remove of code within the series (there was
  broken code in intermediate patches)

For previous changes see:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/333901

Daniel Thompson (18):
  arm: fiq: Add callbacks to manage FIQ routings
  arm: fiq: Allow ACK and EOI to be passed to the intc
  arm: fiq: Replace default FIQ handler
  arm: smp: Introduce a special IPI signalled using FIQ
  arm: KGDB/KDB FIQ support
  irqchip: gic: Provide support for interrupt grouping
  irqchip: gic: Add support for FIQ management
  irqchip: gic: Remove spin locks from eoi_irq
  irqchip: gic: Add support for IPI FIQ
  irqchip: gic: Group 0 workaround.
  irqchip: vic: Add support for FIQ management
  serial: kgdb_nmi: No CON_ENABLED by default
  serial: amba-pl011: Use container_of() to get uart_amba_port
  serial: amba-pl011: Move pl011_hwinit()
  serial: amba-pl011: Pass FIQ information to KGDB.
  serial: asc: Add support for KGDB's FIQ/NMI mode
  serial: asc: Adopt readl_/writel_relaxed()
  serial: imx: Add support for KGDB's FIQ/NMI mode

Dirk Behme (1):
  serial: imx: clean up imx_poll_get_char()

 arch/arm/Kconfig|   2 +
 arch/arm/Kconfig.debug  |  19 +++
 arch/arm/include/asm/fiq.h  |  17 +++
 arch/arm/include/asm/hardirq.h  |   2 +-
 arch/arm/include/asm/kgdb.h |   5 +
 arch/arm/include/asm/smp.h  |   7 +
 arch/arm/kernel/entry-armv.S| 129 +++--
 arch/arm/kernel/fiq.c   | 146 ++-
 arch/arm/kernel/kgdb.c  | 112 ++-
 arch/arm/kernel/setup.c |   8 +-
 arch/arm/kernel/smp.c   |  15 ++
 arch/arm/mach-versatile/core.c  |   2 +-
 drivers/irqchip/irq-gic.c   | 302 +---
 drivers/irqchip/irq-vic.c   |  92 +---

[PATCH v11 10/19] irqchip: gic: Group 0 workaround.

[Daniel Thompson]

An ARM system based on GICv1 that runs by default in secure mode and
uses both group 0 and group 1 interrupts (in order to exploit FIQ)
will suffer a problem where the IRQ handler occasionally spuriously
acknowledges a group 0 (FIQ) interrupt.

This can be prevented by ensuring the IRQ handler makes non-secure
memory access to the GIC registers but this is complex because
the non-secure bits cannot be apply to 4k pages (the bit is one level
up in the page table and applies to 1MB at a time).

This workaround uses an alternative approach that spots the spurious
acknowledgment and regenerates the FIQ. This keeps the workaround
exclusively within the GIC driver (although there is a runtime
perforamnce penalty resulting from this approach).

Reported-by: Harro Haan 
Signed-off-by: Daniel Thompson 
Tested-by: Harro Haan 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
---
 drivers/irqchip/irq-gic.c | 52 ---
 1 file changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 8834749..bda5a91 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -279,14 +279,59 @@ static int gic_set_wake(struct irq_data *d, unsigned int 
on)
 #define gic_set_wake   NULL
 #endif
 
+#ifdef CONFIG_FIQ
+/* This is a software emulation of the Aliased Interrupt Acknowledge Register
+ * (GIC_AIAR) found in GICv2+.
+ */
+static u32 gic_handle_spurious_group_0(struct gic_chip_data *gic, u32 irqstat)
+{
+   u32 irqnr = irqstat & GICC_IAR_INT_ID_MASK;
+   void __iomem *dist_base = gic_data_dist_base(gic);
+   u32 offset, mask;
+
+   if (!gic_data_fiq_enable(gic) || irqnr >= 1021)
+   return irqstat;
+
+   offset = irqnr / 32 * 4;
+   mask = 1 << (irqnr % 32);
+   if (readl_relaxed(dist_base + GIC_DIST_IGROUP + offset) & mask)
+   return irqstat;
+
+   /* this interrupt must be taken as a FIQ so put it back into the
+* pending state and end our own servicing of it.
+*/
+   writel_relaxed(mask, dist_base + GIC_DIST_PENDING_SET + offset);
+   readl_relaxed(dist_base + GIC_DIST_PENDING_SET + offset);
+   writel_relaxed(irqstat, gic_data_cpu_base(gic) + GIC_CPU_EOI);
+
+   return 1023;
+}
+
+static u32 gic_ack_irq(struct gic_chip_data *gic)
+{
+   u32 irqstat;
+
+   local_fiq_disable();
+   irqstat = readl_relaxed(gic_data_cpu_base(gic) + GIC_CPU_INTACK);
+   irqstat = gic_handle_spurious_group_0(gic, irqstat);
+   local_fiq_enable();
+
+   return irqstat;
+}
+#else
+static u32 gic_ack_irq(struct gic_chip_data *gic)
+{
+   return readl_relaxed(gic_data_cpu_base(gic) + GIC_CPU_INTACK);
+}
+#endif
+
 static void __exception_irq_entry gic_handle_irq(struct pt_regs *regs)
 {
u32 irqstat, irqnr;
struct gic_chip_data *gic = _data[0];
-   void __iomem *cpu_base = gic_data_cpu_base(gic);
 
do {
-   irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK);
+   irqstat = gic_ack_irq(gic);
irqnr = irqstat & GICC_IAR_INT_ID_MASK;
 
if (likely(irqnr > 15 && irqnr < 1021)) {
@@ -295,7 +340,8 @@ static void __exception_irq_entry gic_handle_irq(struct 
pt_regs *regs)
continue;
}
if (irqnr < 16) {
-   writel_relaxed(irqstat, cpu_base + GIC_CPU_EOI);
+   writel_relaxed(irqstat,
+  gic_data_cpu_base(gic) + GIC_CPU_EOI);
 #ifdef CONFIG_SMP
handle_IPI(irqnr, regs);
 #endif
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 01/19] arm: fiq: Add callbacks to manage FIQ routings

[Daniel Thompson]

Currently enable_fiq/disable_fiq use a simple offset to convert an IRQ
virq into a FIQ virq. This is too inflexible for multi-platform kernels
and makes runtime error checking impossible.

We solve this by introducing a flexible mapping that allows interrupt
controllers that support FIQ to register those mappings. This, in turn,
makes it much possible for drivers in DT kernels to install FIQ handlers
without knowing anything about the interrupt controller.

Signed-off-by: Daniel Thompson 
Acked-by: Nicolas Pitre 
Cc: Russell King 
Cc: Fabio Estevam 
---
 arch/arm/include/asm/fiq.h |   8 
 arch/arm/kernel/fiq.c  | 103 -
 2 files changed, 109 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/fiq.h b/arch/arm/include/asm/fiq.h
index d493d0b..ed44528 100644
--- a/arch/arm/include/asm/fiq.h
+++ b/arch/arm/include/asm/fiq.h
@@ -16,8 +16,14 @@
 #ifndef __ASM_FIQ_H
 #define __ASM_FIQ_H
 
+#include 
 #include 
 
+struct fiq_chip {
+   void (*fiq_enable)(struct irq_data *data);
+   void (*fiq_disable)(struct irq_data *data);
+};
+
 struct fiq_handler {
struct fiq_handler *next;
/* Name
@@ -38,6 +44,8 @@ extern void release_fiq(struct fiq_handler *f);
 extern void set_fiq_handler(void *start, unsigned int length);
 extern void enable_fiq(int fiq);
 extern void disable_fiq(int fiq);
+extern bool has_fiq(int fiq);
+extern void fiq_register_mapping(int irq, struct fiq_chip *chip);
 
 /* helpers defined in fiqasm.S: */
 extern void __set_fiq_regs(unsigned long const *regs);
diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index 918875d..5d831cf 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -40,6 +40,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -52,7 +55,15 @@
(unsigned)_fiq_offset;   \
})
 
+struct fiq_data {
+   struct fiq_chip *fiq_chip;
+   struct irq_data *irq_data;
+};
+
 static unsigned long no_fiq_insn;
+static int fiq_start = -1;
+static RADIX_TREE(fiq_data_tree, GFP_KERNEL);
+static DEFINE_MUTEX(fiq_data_mutex);
 
 /* Default reacquire function
  * - we always relinquish FIQ control
@@ -127,18 +138,65 @@ void release_fiq(struct fiq_handler *f)
while (current_fiq->fiq_op(current_fiq->dev_id, 0));
 }
 
-static int fiq_start;
+static struct fiq_data *lookup_fiq_data(int fiq)
+{
+   struct fiq_data *data;
+
+   rcu_read_lock();
+   data = radix_tree_lookup(_data_tree, fiq);
+   rcu_read_unlock();
+
+   return data;
+}
 
 void enable_fiq(int fiq)
 {
+   struct fiq_data *data = lookup_fiq_data(fiq);
+
+   if (data) {
+   if (data->fiq_chip->fiq_enable)
+   data->fiq_chip->fiq_enable(data->irq_data);
+   enable_irq(fiq);
+   return;
+   }
+
+   if (WARN_ON(fiq_start == -1))
+   return;
+
enable_irq(fiq + fiq_start);
 }
 
 void disable_fiq(int fiq)
 {
+   struct fiq_data *data = lookup_fiq_data(fiq);
+
+   if (data) {
+   if (data->fiq_chip->fiq_disable)
+   data->fiq_chip->fiq_disable(data->irq_data);
+   disable_irq(fiq);
+   return;
+   }
+
+   if (WARN_ON(fiq_start == -1))
+   return;
+
disable_irq(fiq + fiq_start);
 }
 
+bool has_fiq(int fiq)
+{
+   struct fiq_data *data = lookup_fiq_data(fiq);
+
+   if (data)
+   return true;
+
+   if (fiq_start == -1)
+   return false;
+
+   return fiq >= fiq_start;
+}
+EXPORT_SYMBOL(has_fiq);
+
 EXPORT_SYMBOL(set_fiq_handler);
 EXPORT_SYMBOL(__set_fiq_regs); /* defined in fiqasm.S */
 EXPORT_SYMBOL(__get_fiq_regs); /* defined in fiqasm.S */
@@ -147,9 +205,50 @@ EXPORT_SYMBOL(release_fiq);
 EXPORT_SYMBOL(enable_fiq);
 EXPORT_SYMBOL(disable_fiq);
 
+/*
+ * Add a mapping from a Linux irq to the fiq data.
+ */
+void fiq_register_mapping(int irq, struct fiq_chip *chip)
+{
+   struct fiq_data *fiq_data = NULL;
+   int res;
+
+   /* fiq_register_mapping can't be mixed with init_FIQ */
+   BUG_ON(fiq_start != -1);
+
+   fiq_data = kmalloc(sizeof(*fiq_data), GFP_KERNEL);
+   if (!fiq_data)
+   goto err;
+
+   fiq_data->fiq_chip = chip;
+   fiq_data->irq_data = irq_get_irq_data(irq);
+   BUG_ON(!fiq_data->irq_data);
+
+   mutex_lock(_data_mutex);
+   res = radix_tree_insert(_data_tree, irq, fiq_data);
+   mutex_unlock(_data_mutex);
+   if (res)
+   goto err;
+
+   return;
+
+err:
+   kfree(fiq_data);
+   pr_err("fiq: Cannot register mapping %d\n", irq);
+}
+
+/*
+ * Set the offset between normal IRQs and their FIQ shadows.
+ */
 void __init init_FIQ(int start)
 {
+   fiq_start = start;
+}
+
+static int __init init_default_fiq_handler(void)
+{
unsigned offset = FIQ_OFFSET;
no_fiq_insn = *(unsigned long *)(0x + 

[PATCH v11 05/19] arm: KGDB/KDB FIQ support

[Daniel Thompson]

The FIQ debugger may be used to debug situations when the kernel stuck
in uninterruptable sections, e.g. the kernel infinitely loops or
deadlocked in an interrupt or with interrupts disabled.

Credit:

This patch is a near complete re-write of a patch originally
provided by Anton Vorontsov. Today only a couple of comments and
other small fragments still survive, however without Anton's work
to build from this patch would not exist.

Signed-off-by: Daniel Thompson 
Cc: Russell King 
Cc: Ben Dooks 
Cc: Omar Sandoval 
---
 arch/arm/Kconfig|   2 +
 arch/arm/Kconfig.debug  |  19 
 arch/arm/include/asm/kgdb.h |   5 ++
 arch/arm/kernel/fiq.c   |   4 +-
 arch/arm/kernel/kgdb.c  | 112 +---
 5 files changed, 135 insertions(+), 7 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c49a775..e6380b3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -305,6 +305,7 @@ choice
 config ARCH_MULTIPLATFORM
bool "Allow multiple platforms to be selected"
depends on MMU
+   select ARCH_MIGHT_HAVE_KGDB_FIQ
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARM_HAS_SG_CHAIN
select ARM_PATCH_PHYS_VIRT
@@ -352,6 +353,7 @@ config ARCH_REALVIEW
 
 config ARCH_VERSATILE
bool "ARM Ltd. Versatile family"
+   select ARCH_MIGHT_HAVE_KGDB_FIQ
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARM_AMBA
select ARM_TIMER_SP804
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index b11ad54..df3f0bf 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -2,6 +2,25 @@ menu "Kernel hacking"
 
 source "lib/Kconfig.debug"
 
+config ARCH_MIGHT_HAVE_KGDB_FIQ
+   bool
+
+config KGDB_FIQ
+   bool "KGDB FIQ support"
+   depends on KGDB_KDB && ARCH_MIGHT_HAVE_KGDB_FIQ && !THUMB2_KERNEL
+   select FIQ
+   help
+ The FIQ debugger may be used to debug situations when the
+ kernel stuck in uninterruptable sections, e.g. the kernel
+ infinitely loops or deadlocked in an interrupt or with
+ interrupts disabled.
+
+ By default KGDB FIQ is disabled at runtime, but can be enabled
+ by setting the console to ttyNMI0 (and choosing the underlying
+ serial port using kgdboc)
+
+ If unsure, say N.
+
 config ARM_PTDUMP
bool "Export kernel pagetable layout to userspace via debugfs"
depends on DEBUG_KERNEL
diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
index 0a9d5dd..cb5ccd6 100644
--- a/arch/arm/include/asm/kgdb.h
+++ b/arch/arm/include/asm/kgdb.h
@@ -11,7 +11,9 @@
 #define __ARM_KGDB_H__
 
 #include 
+#include 
 #include 
+#include 
 
 /*
  * GDB assumes that we're a user process being debugged, so
@@ -48,6 +50,9 @@ static inline void arch_kgdb_breakpoint(void)
 extern void kgdb_handle_bus_error(void);
 extern int kgdb_fault_expected;
 
+extern int kgdb_register_fiq(unsigned int fiq);
+extern void kgdb_handle_fiq(struct pt_regs *regs);
+
 #endif /* !__ASSEMBLY__ */
 
 /*
diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index 77c62b2..c6b3bed 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -229,7 +229,9 @@ asmlinkage void __exception_irq_entry 
fiq_nmi_handler(struct pt_regs *regs)
 * order to ensure code review happens (drivers cannot "secretly"
 * employ FIQ without modifying this chain of calls).
 */
-   /* list is currently empty */
+#ifdef CONFIG_KGDB_FIQ
+   kgdb_handle_fiq(regs);
+#endif
 
nmi_exit();
set_irq_regs(old_regs);
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index a74b53c..630a3ef 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -12,8 +12,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
+static unsigned int kgdb_fiq;
+
 struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] =
 {
{ "r0", 4, offsetof(struct pt_regs, ARM_r0)},
@@ -175,14 +178,26 @@ static struct undef_hook kgdb_compiled_brkpt_hook = {
 
 static void kgdb_call_nmi_hook(void *ignored)
 {
-   kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
+   kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
 }
 
 void kgdb_roundup_cpus(unsigned long flags)
 {
-   local_irq_enable();
-   smp_call_function(kgdb_call_nmi_hook, NULL, 0);
-   local_irq_disable();
+#if defined CONFIG_KGDB_FIQ && defined CONFIG_SMP
+   struct cpumask mask;
+
+   if (in_nmi()) {
+   cpumask_copy(, cpu_online_mask);
+   cpumask_clear_cpu(raw_smp_processor_id(), );
+   if (!cpumask_empty())
+   send_fiq_ipi_mask();
+   return;
+   }
+#endif
+
+   local_irq_enable();
+   smp_call_function(kgdb_call_nmi_hook, NULL, 0);
+   local_irq_disable();
 }
 
 static int __kgdb_notify(struct die_args *args, unsigned long cmd)
@@ -244,6 +259,43 @@ void kgdb_arch_exit(void)

Re: [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support

[Marc Zyngier]

On 02/09/14 12:48, Tomasz Nowicki wrote:
> On 01.09.2014 19:35, Marc Zyngier wrote:
>> On 01/09/14 15:57, Hanjun Guo wrote:
>>> From: Tomasz Nowicki 
>>>
>>> ACPI kernel uses MADT table for proper GIC initialization. It needs to
>>> parse GIC related subtables, collect CPU interface and distributor
>>> addresses and call driver initialization function (which is hardware
>>> abstraction agnostic). In a similar way, FDT initialize GICv1/2.
>>>
>>> NOTE: This commit allow to initialize GICv1/2 only.
>>
>> I cannot help but notice that there is no support for KVM here. It'd be
>> good to add a note to that effect, so that people do not expect
>> virtualization support to be working when booting with ACPI.
> 
> yes, it is worth mentioning!
> 
>>
>>> Signed-off-by: Tomasz Nowicki 
>>> Signed-off-by: Hanjun Guo 
>>> ---
>>>   arch/arm64/include/asm/acpi.h|2 -
>>>   arch/arm64/kernel/acpi.c |   23 +++
>>>   arch/arm64/kernel/irq.c  |5 ++
>>>   drivers/irqchip/irq-gic.c|  114 
>>> ++
>>>   include/linux/irqchip/arm-gic-acpi.h |   33 ++
>>>   5 files changed, 175 insertions(+), 2 deletions(-)
>>>   create mode 100644 include/linux/irqchip/arm-gic-acpi.h
>>>
>>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>>> index a867467..5d2ab63 100644
>>> --- a/arch/arm64/include/asm/acpi.h
>>> +++ b/arch/arm64/include/asm/acpi.h
>>> @@ -97,8 +97,6 @@ void __init acpi_smp_init_cpus(void);
>>>   extern int (*acpi_suspend_lowlevel)(void);
>>>   #define acpi_wakeup_address 0
>>>
>>> -#define ACPI_MAX_GIC_CPU_INTERFACE_ENTRIES 65535
>>> -
>>>   #else
>>>
>>>   static inline bool acpi_psci_present(void) { return false; }
>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>> index 354b912..b3b82b0 100644
>>> --- a/arch/arm64/kernel/acpi.c
>>> +++ b/arch/arm64/kernel/acpi.c
>>> @@ -23,6 +23,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>
>>>   #include 
>>>   #include 
>>> @@ -313,6 +314,28 @@ void __init acpi_boot_table_init(void)
>>>  pr_err("Can't find FADT or error happened during parsing 
>>> FADT\n");
>>>   }
>>>
>>> +void __init acpi_gic_init(void)
>>> +{
>>> +struct acpi_table_header *table;
>>> +acpi_status status;
>>> +acpi_size tbl_size;
>>> +int err;
>>> +
>>> +status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, , _size);
>>> +if (ACPI_FAILURE(status)) {
>>> +const char *msg = acpi_format_exception(status);
>>> +
>>> +pr_err("Failed to get MADT table, %s\n", msg);
>>> +return;
>>> +}
>>> +
>>> +err = gic_v2_acpi_init(table);
>>> +if (err)
>>> +pr_err("Failed to initialize GIC IRQ controller");
>>
>> What will happen when you get to implement GICv3 support? Another entry
>> like this? Why isn't this entirely contained in the GIC driver? Do I
>> sound like a stuck record?
> 
> There will be another call to GICv3 init:
> [...]
> err = gic_v3_acpi_init(table);
> if (err)
> err = gic_v2_acpi_init(table);
> if (err)
> pr_err("Failed to initialize GIC IRQ controller");
> [...]
> This is the main reason I put common code here.
> 
>>
>>> +
>>> +early_acpi_os_unmap_memory((char *)table, tbl_size);
>>> +}
>>> +
>>>   /*
>>>* acpi_suspend_lowlevel() - save kernel state and suspend.
>>>*
>>> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
>>> index 0f08dfd..c074d60 100644
>>> --- a/arch/arm64/kernel/irq.c
>>> +++ b/arch/arm64/kernel/irq.c
>>> @@ -28,6 +28,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>
>>>   unsigned long irq_err_count;
>>>
>>> @@ -78,6 +79,10 @@ void __init set_handle_irq(void (*handle_irq)(struct 
>>> pt_regs *))
>>>   void __init init_IRQ(void)
>>>   {
>>>  irqchip_init();
>>> +
>>> +if (!handle_arch_irq)
>>> +acpi_gic_init();
>>> +
>>
>> Why isn't this called from irqchip_init? It would seem like the logical
>> spot to probe an interrupt controller.
> 
> irqchip.c is OF dependent, I want to decouple these from the very
> beginning.

No. irqchip.c is not OF dependent, it is just that DT is the only thing
we support so far. I don't think duplicating the kernel infrastructure
"because we're different" is the right way.

There is no reason for your probing structure to be artificially
different (you're parsing the same information, at the same time). Just
put in place a similar probing mechanism, and this will look a lot better.

>>
>>>  if (!handle_arch_irq)
>>>  panic("No interrupt controller found.");
>>>   }
>>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>>> index 4b959e6..85cbf43 100644
>>> --- a/drivers/irqchip/irq-gic.c
>>> +++ b/drivers/irqchip/irq-gic.c
>>> @@ -33,12 +33,14 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>   #include 

[PATCH v11 04/19] arm: smp: Introduce a special IPI signalled using FIQ

[Daniel Thompson]

Cross CPU signalling based on FIQ is especially useful for kgdb since
it makes stopping all the CPUs during breakpointing more robust (some
of the other architectures already roundup the CPUs using NMIs).

The approach taken provides infrastructure that can be called (or not) by
the driver's FIQ handler depending upon it requirements. In other words
nothing is added here that prevents the driver from accessing "bare metal"
performance.

Signed-off-by: Daniel Thompson 
---
 arch/arm/include/asm/hardirq.h |  2 +-
 arch/arm/include/asm/smp.h |  7 +++
 arch/arm/kernel/smp.c  | 15 +++
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index fe3ea77..5df33e3 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-#define NR_IPI 8
+#define NR_IPI 9
 
 typedef struct {
unsigned int __softirq_pending;
diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index 2ec765c..215c927 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -20,6 +20,9 @@
 
 #define raw_smp_processor_id() (current_thread_info()->cpu)
 
+/* bitmap of IPIs that must be signalled using FIQ */
+#define SMP_IPI_FIQ_MASK 0x0100
+
 struct seq_file;
 
 /*
@@ -87,6 +90,10 @@ extern void arch_send_wakeup_ipi_mask(const struct cpumask 
*mask);
 
 extern int register_ipi_completion(struct completion *completion, int cpu);
 
+#ifdef CONFIG_FIQ
+extern void send_fiq_ipi_mask(const struct cpumask *);
+#endif
+
 struct smp_operations {
 #ifdef CONFIG_SMP
/*
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 9388a3d..d386c32 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -72,6 +72,7 @@ enum ipi_msg_type {
IPI_CPU_STOP,
IPI_IRQ_WORK,
IPI_COMPLETION,
+   IPI_FIQ,
 };
 
 static DECLARE_COMPLETION(cpu_running);
@@ -451,6 +452,7 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
S(IPI_CPU_STOP, "CPU stop interrupts"),
S(IPI_IRQ_WORK, "IRQ work interrupts"),
S(IPI_COMPLETION, "completion interrupts"),
+   S(IPI_FIQ, "FIQ interrupts"),
 };
 
 static void smp_cross_call(const struct cpumask *target, unsigned int ipinr)
@@ -552,6 +554,13 @@ static void ipi_complete(unsigned int cpu)
complete(per_cpu(cpu_completion, cpu));
 }
 
+#ifdef CONFIG_FIQ
+void send_fiq_ipi_mask(const struct cpumask *mask)
+{
+   smp_cross_call(mask, IPI_FIQ);
+}
+#endif
+
 /*
  * Main handler for inter-processor interrupts
  */
@@ -618,6 +627,12 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
irq_exit();
break;
 
+#ifdef CONFIG_FIQ
+   case IPI_FIQ:
+   pr_crit("CPU%u: IPI FIQ delivered via IRQ vector\n", cpu);
+   break;
+#endif
+
default:
printk(KERN_CRIT "CPU%u: Unknown IPI message 0x%x\n",
   cpu, ipinr);
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] x86, fpu: irq_fpu_usable: kill all checks except !in_kernel_fpu

[Oleg Nesterov]

On 09/02, Suresh Siddha wrote:
>
> On Fri, Aug 29, 2014 at 11:17 AM, Oleg Nesterov  wrote:
> > ONCE AGAIN, THIS IS MORE THE QUESTION THAN THE PATCH.
>
> this patch I think needs more thought for sure. please see below.

Of course.

> > interrupted_kernel_fpu_idle() does:
> >
> > if (use_eager_fpu())
> > return true;
> >
> > return !__thread_has_fpu(current) &&
> > (read_cr0() & X86_CR0_TS);
> >
> > and it is absolutely not clear why these 2 cases differ so much.
> >
> > To remind, the use_eager_fpu() case is buggy; __save_init_fpu() in
> > __kernel_fpu_begin() can race with math_state_restore() which does
> > __thread_fpu_begin() + restore_fpu_checking(). So we should fix this
> > race anyway and we can't require __thread_has_fpu() == F likes the
> > !use_eager_fpu() case does, in this case kernel_fpu_begin() will not
> > work if it interrupts the idle thread (this will reintroduce the
> > performance regression fixed by 5187b28f).
> >
> > Probably math_state_restore() can use kernel_fpu_disable/end() which
> > sets/clears in_kernel_fpu, or it can disable irqs. Doesn't matter, we
> > should fix this bug anyway.
> >
> > And if we fix this bug, why else !use_eager_fpu() case needs the much
> > more strict check? Why we can't handle the __thread_has_fpu(current)
> > case the same way?
> >
> > The comment deleted by this change says:
> >
> > and TS must be set so that the clts/stts pair does nothing
> >
> > and can explain the difference, but I can not understand this (again,
> > assuming that we fix the race(s) mentoined above).
> >
> > Say, user_fpu_begin(). Yes, kernel_fpu_begin/end() can restore X86_CR0_TS.
> > But this should be fine?
>
> No. The reason is that has_fpu state and cr0.TS can get out of sync.
>
> Let's say you get an interrupt after clts() in __thread_fpu_begin()
> called as part of user_fpu_begin().
>
> And because of this proposed change, irq_fpu_usable() returns true and
> an interrupt can end-up using fpu and after the return from interrupt
> we can have a state where cr0.TS is set but we end up resuming the
> execution from __thread_set_has_fpu(). Now after this point has_fpu is
> set but cr0.TS is set. And now any schedule() with this state (let's
> say immd after preemption_enable() at the end of user_fpu_begin()) is
> dangerous. We can get a dna fault in the middle of __switch_to() which
> can lead to subtle bugs.

Thanks. Yes, I thought about this race, but I didn't realize that a DNA
inside __switch_to() is dangerous.

Thanks a lot. OK, this is trivially fixable. I had this v2 in mind from
the very beginning because I was not really sure that unconditional stts()
in kernel_fpu_end() is safe (but yes, I didn't realize why). Just we need
to save X86_CR0_TS in the same per-cpu in_kernel_fpu,

static DEFINE_PER_CPU(int, in_kernel_fpu);

void __kernel_fpu_begin(void)
{
struct task_struct *me = current;

this_cpu_write(in_kernel_fpu, 1);

if (__thread_has_fpu(me)) {
__save_init_fpu(me);
} else if (!use_eager_fpu()) {
this_cpu_write(fpu_owner_task, NULL);
if ((read_cr0() & X86_CR0_TS))
this_cpu_write(in_kernel_fpu, 2);
clts();
}
}
}

void __kernel_fpu_end(void)
{
struct task_struct *me = current;

if (__thread_has_fpu(me)) {
if (WARN_ON(restore_fpu_checking(me)))
drop_init_fpu(me);
} else if (!use_eager_fpu()) {
if (this_cpu_read(in_kernel_fpu) == 2)
stts();
}

this_cpu_write(in_kernel_fpu, 0);
}

Or, perhaps better, we can turn user_fpu_begin()->preempt_disable()
into kernel_fpu_disable().

Do you think this can work?

> other than this patch, rest of the changes look ok to me. Can you
> please resend this patchset with the math_state_restore() race
> addressed aswell?

OK, will do, but probably next week.

Will you agree if I add kernel_fpu_disable/enable to fix this race?
It can probably have more users (see above).

Thanks!

Oleg.

--
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 5/6] mm/balloon_compaction: use common page ballooning

[Rafael Aquini]

On Sat, Aug 30, 2014 at 08:41:23PM +0400, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov 
> 
> This patch replaces checking AS_BALLOON_MAP in page->mapping->flags
> with PageBalloon which is stored directly in the struct page.
> All code of balloon_compaction now under CONFIG_MEMORY_BALLOON.
> 
> Signed-off-by: Konstantin Khlebnikov 
> ---
>  drivers/virtio/Kconfig |1 
>  include/linux/balloon_compaction.h |  135 
> ++--
>  mm/Kconfig |2 -
>  mm/Makefile|3 +
>  mm/balloon_compaction.c|7 +-
>  mm/compaction.c|9 +-
>  mm/migrate.c   |6 +-
>  mm/vmscan.c|2 -
>  8 files changed, 39 insertions(+), 126 deletions(-)
> 
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index c6683f2..00b2286 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -25,6 +25,7 @@ config VIRTIO_PCI
>  config VIRTIO_BALLOON
>   tristate "Virtio balloon driver"
>   depends on VIRTIO
> + select MEMORY_BALLOON
>   ---help---
>This driver supports increasing and decreasing the amount
>of memory within a KVM guest.
> diff --git a/include/linux/balloon_compaction.h 
> b/include/linux/balloon_compaction.h
> index 284fc1d..09f8c5a 100644
> --- a/include/linux/balloon_compaction.h
> +++ b/include/linux/balloon_compaction.h
> @@ -46,6 +46,8 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_MEMORY_BALLOON
> +
>  /*
>   * Balloon device information descriptor.
>   * This struct is used to allow the common balloon compaction interface
> @@ -93,91 +95,6 @@ static inline void balloon_page_free(struct page *page)
>   __free_page(page);
>  }
>  
> -#ifdef CONFIG_BALLOON_COMPACTION
> -extern bool balloon_page_isolate(struct page *page);
> -extern void balloon_page_putback(struct page *page);
> -extern int balloon_page_migrate(struct page *newpage,
> - struct page *page, enum migrate_mode mode);
> -extern struct address_space
> -*balloon_mapping_alloc(struct balloon_dev_info *b_dev_info,
> - const struct address_space_operations *a_ops);
> -
> -static inline void balloon_mapping_free(struct address_space 
> *balloon_mapping)
> -{
> - kfree(balloon_mapping);
> -}
> -
> -/*
> - * page_flags_cleared - helper to perform balloon @page ->flags tests.
> - *
> - * As balloon pages are obtained from buddy and we do not play with 
> page->flags
> - * at driver level (exception made when we get the page lock for compaction),
> - * we can safely identify a ballooned page by checking if the
> - * PAGE_FLAGS_CHECK_AT_PREP page->flags are all cleared.  This approach also
> - * helps us skip ballooned pages that are locked for compaction or release, 
> thus
> - * mitigating their racy check at balloon_page_movable()
> - */
> -static inline bool page_flags_cleared(struct page *page)
> -{
> - return !(page->flags & PAGE_FLAGS_CHECK_AT_PREP);
> -}
> -
> -/*
> - * __is_movable_balloon_page - helper to perform @page mapping->flags tests
> - */
> -static inline bool __is_movable_balloon_page(struct page *page)
> -{
> - struct address_space *mapping = page->mapping;
> - return !PageAnon(page) && mapping_balloon(mapping);
> -}
> -
> -/*
> - * balloon_page_movable - test page->mapping->flags to identify balloon pages
> - * that can be moved by compaction/migration.
> - *
> - * This function is used at core compaction's page isolation scheme, 
> therefore
> - * most pages exposed to it are not enlisted as balloon pages and so, to 
> avoid
> - * undesired side effects like racing against __free_pages(), we cannot 
> afford
> - * holding the page locked while testing page->mapping->flags here.
> - *
> - * As we might return false positives in the case of a balloon page being 
> just
> - * released under us, the page->mapping->flags need to be re-tested later,
> - * under the proper page lock, at the functions that will be coping with the
> - * balloon page case.
> - */
> -static inline bool balloon_page_movable(struct page *page)
> -{
> - /*
> -  * Before dereferencing and testing mapping->flags, let's make sure
> -  * this is not a page that uses ->mapping in a different way
> -  */
> - if (page_flags_cleared(page) && !page_mapped(page) &&
> - page_count(page) == 1)
> - return __is_movable_balloon_page(page);
> -
> - return false;
> -}
> -
> -/*
> - * isolated_balloon_page - identify an isolated balloon page on private
> - *  compaction/migration page lists.
> - *
> - * After a compaction thread isolates a balloon page for migration, it raises
> - * the page refcount to prevent concurrent compaction threads from 
> re-isolating
> - * the same page. For that reason putback_movable_pages(), or other routines
> - * that need to identify isolated balloon pages on 

[PATCH v3 17/17] drm/exynos/ipp: add file checks for ioctls

[Andrzej Hajda]

Process should not have access to ipp nodes created by another
process. The patch adds necessary checks.
It also simplifies lookup for command node.

Signed-off-by: Andrzej Hajda 
---
v3:
- added file check from previous commit
- simplified c_node lookup
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 69 +++--
 1 file changed, 22 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 9e9714a..4f36a9d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -318,44 +318,6 @@ static void ipp_print_property(struct 
drm_exynos_ipp_property *property,
sz->hsize, sz->vsize, config->flip, config->degree);
 }
 
-static int ipp_find_and_set_property(struct drm_exynos_ipp_property *property)
-{
-   struct exynos_drm_ippdrv *ippdrv;
-   struct drm_exynos_ipp_cmd_node *c_node;
-   u32 prop_id = property->prop_id;
-
-   DRM_DEBUG_KMS("prop_id[%d]\n", prop_id);
-
-   ippdrv = ipp_find_drv_by_handle(prop_id);
-   if (IS_ERR(ippdrv)) {
-   DRM_ERROR("failed to get ipp driver.\n");
-   return -EINVAL;
-   }
-
-   /*
-* Find command node using command list in ippdrv.
-* when we find this command no using prop_id.
-* return property information set in this command node.
-*/
-   mutex_lock(>cmd_lock);
-   list_for_each_entry(c_node, >cmd_list, list) {
-   if ((c_node->property.prop_id == prop_id) &&
-   (c_node->state == IPP_STATE_STOP)) {
-   mutex_unlock(>cmd_lock);
-   DRM_DEBUG_KMS("found cmd[%d]ippdrv[0x%x]\n",
-   property->cmd, (int)ippdrv);
-
-   c_node->property = *property;
-   return 0;
-   }
-   }
-   mutex_unlock(>cmd_lock);
-
-   DRM_ERROR("failed to search property.\n");
-
-   return -EINVAL;
-}
-
 static struct drm_exynos_ipp_cmd_work *ipp_create_cmd_work(void)
 {
struct drm_exynos_ipp_cmd_work *cmd_work;
@@ -391,6 +353,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, 
void *data,
struct drm_exynos_ipp_property *property = data;
struct exynos_drm_ippdrv *ippdrv;
struct drm_exynos_ipp_cmd_node *c_node;
+   u32 prop_id;
int ret, i;
 
if (!ctx) {
@@ -403,6 +366,8 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev, 
void *data,
return -EINVAL;
}
 
+   prop_id = property->prop_id;
+
/*
 * This is log print for user application property.
 * user application set various property.
@@ -411,14 +376,24 @@ int exynos_drm_ipp_set_property(struct drm_device 
*drm_dev, void *data,
ipp_print_property(property, i);
 
/*
-* set property ioctl generated new prop_id.
-* but in this case already asigned prop_id using old set property.
-* e.g PAUSE state. this case supports find current prop_id and use it
-* instead of allocation.
+* In case prop_id is not zero try to set existing property.
 */
-   if (property->prop_id) {
-   DRM_DEBUG_KMS("prop_id[%d]\n", property->prop_id);
-   return ipp_find_and_set_property(property);
+   if (prop_id) {
+   c_node = ipp_find_obj(>prop_idr, >prop_lock, prop_id);
+
+   if (!c_node || c_node->filp != file) {
+   DRM_DEBUG_KMS("prop_id[%d] not found\n", prop_id);
+   return -EINVAL;
+   }
+
+   if (c_node->state != IPP_STATE_STOP) {
+   DRM_DEBUG_KMS("prop_id[%d] not stopped\n", prop_id);
+   return -EINVAL;
+   }
+
+   c_node->property = *property;
+
+   return 0;
}
 
/* find ipp driver using ipp id */
@@ -897,7 +872,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
void *data,
/* find command node */
c_node = ipp_find_obj(>prop_idr, >prop_lock,
qbuf->prop_id);
-   if (!c_node) {
+   if (!c_node || c_node->filp != file) {
DRM_ERROR("failed to get command node.\n");
return -ENODEV;
}
@@ -1032,7 +1007,7 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, 
void *data,
 
c_node = ipp_find_obj(>prop_idr, >prop_lock,
cmd_ctrl->prop_id);
-   if (!c_node) {
+   if (!c_node || c_node->filp != file) {
DRM_ERROR("invalid command node list.\n");
return -ENODEV;
}
-- 
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  

Re: [PATCH] security: Silence shadow warning

[James Morris]

On Thu, 28 Aug 2014, Jeff Kirsher wrote:

> From: Mark Rustad 
> 
> Renaming an unused formal parameter in the static inline function
> security_inode_init_security eliminates many W=2 warnings.
> 
> Signed-off-by: Mark Rustad 
> Signed-off-by: Jeff Kirsher 


Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next


-- 
James Morris


--
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 16/17] drm/exynos/ipp: remove file argument from node related functions

[Andrzej Hajda]

Since file pointer is preserved in c_node passing it
as argument in node functions is redundant.

Signed-off-by: Andrzej Hajda 
---
v3:
- file check moved to next patch
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 05f0f4e..9e9714a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
 
 static struct drm_exynos_ipp_mem_node
*ipp_get_mem_node(struct drm_device *drm_dev,
-   struct drm_file *file,
struct drm_exynos_ipp_cmd_node *c_node,
struct drm_exynos_ipp_queue_buf *qbuf)
 {
@@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node
dma_addr_t *addr;
 
addr = exynos_drm_gem_get_dma_addr(drm_dev,
-   qbuf->handle[i], file);
+   qbuf->handle[i], c_node->filp);
if (IS_ERR(addr)) {
DRM_ERROR("failed to get addr.\n");
ipp_put_mem_node(drm_dev, c_node, m_node);
@@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event *event)
 }
 
 static int ipp_get_event(struct drm_device *drm_dev,
-   struct drm_file *file,
struct drm_exynos_ipp_cmd_node *c_node,
struct drm_exynos_ipp_queue_buf *qbuf)
 {
@@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
e = kzalloc(sizeof(*e), GFP_KERNEL);
if (!e) {
spin_lock_irqsave(_dev->event_lock, flags);
-   file->event_space += sizeof(e->event);
+   c_node->filp->event_space += sizeof(e->event);
spin_unlock_irqrestore(_dev->event_lock, flags);
return -ENOMEM;
}
@@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
e->event.prop_id = qbuf->prop_id;
e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
e->base.event = >event.base;
-   e->base.file_priv = file;
+   e->base.file_priv = c_node->filp;
e->base.destroy = ipp_free_event;
mutex_lock(_node->event_lock);
list_add_tail(>base.link, _node->event_list);
@@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
void *data,
switch (qbuf->buf_type) {
case IPP_BUF_ENQUEUE:
/* get memory node */
-   m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf);
+   m_node = ipp_get_mem_node(drm_dev, c_node, qbuf);
if (IS_ERR(m_node)) {
DRM_ERROR("failed to get m_node.\n");
return PTR_ERR(m_node);
@@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
void *data,
 */
if (qbuf->ops_id == EXYNOS_DRM_OPS_DST) {
/* get event for destination buffer */
-   ret = ipp_get_event(drm_dev, file, c_node, qbuf);
+   ret = ipp_get_event(drm_dev, c_node, qbuf);
if (ret) {
DRM_ERROR("failed to get event.\n");
goto err_clean_node;
-- 
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 v2 4/6] mm: introduce common page state for ballooned memory

[Rafael Aquini]

On Sat, Aug 30, 2014 at 08:41:20PM +0400, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov 
> 
> This patch adds page state PageBallon() and functions __Set/ClearPageBalloon.
> Like PageBuddy() PageBalloon() looks like page-flag but actually this is 
> special
> state of page->_mapcount counter. There is no conflict because ballooned pages
> cannot be mapped and cannot be in buddy allocator.
> 
> Ballooned pages are counted in vmstat counter NR_BALLOON_PAGES, it's shown 
> them
> in /proc/meminfo and /proc/meminfo. Also this patch it exports PageBallon into
> userspace via /proc/kpageflags as KPF_BALLOON.
> 
> All new code is under CONFIG_MEMORY_BALLOON, it should be selected by
> ballooning driver which wants use this feature.
> 
> Signed-off-by: Konstantin Khlebnikov 
> ---
>  Documentation/filesystems/proc.txt |2 ++
>  drivers/base/node.c|   16 ++--
>  fs/proc/meminfo.c  |6 ++
>  fs/proc/page.c |3 +++
>  include/linux/mm.h |   20 
>  include/linux/mmzone.h |3 +++
>  include/uapi/linux/kernel-page-flags.h |1 +
>  mm/Kconfig |5 +
>  mm/vmstat.c|8 +++-
>  tools/vm/page-types.c  |1 +
>  10 files changed, 58 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/filesystems/proc.txt 
> b/Documentation/filesystems/proc.txt
> index eb8a10e..154a345 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -796,6 +796,7 @@ VmallocTotal:   112216 kB
>  VmallocUsed:   428 kB
>  VmallocChunk:   111088 kB
>  AnonHugePages:   49152 kB
> +BalloonPages:0 kB
>  
>  MemTotal: Total usable ram (i.e. physical ram minus a few reserved
>bits and the kernel binary code)
> @@ -838,6 +839,7 @@ MemAvailable: An estimate of how much memory is available 
> for starting new
> Writeback: Memory which is actively being written back to the disk
> AnonPages: Non-file backed pages mapped into userspace page tables
>  AnonHugePages: Non-file backed huge pages mapped into userspace page tables
> +BalloonPages: Memory which was ballooned, not included into MemTotal
>Mapped: files which have been mmaped, such as libraries
>  Slab: in-kernel data structures cache
>  SReclaimable: Part of Slab, that might be reclaimed, such as caches
> diff --git a/drivers/base/node.c b/drivers/base/node.c
> index c6d3ae0..59e565c 100644
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -120,6 +120,9 @@ static ssize_t node_read_meminfo(struct device *dev,
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  "Node %d AnonHugePages:  %8lu kB\n"
>  #endif
> +#ifdef CONFIG_MEMORY_BALLOON
> +"Node %d BalloonPages:   %8lu kB\n"
> +#endif
>   ,
>  nid, K(node_page_state(nid, NR_FILE_DIRTY)),
>  nid, K(node_page_state(nid, NR_WRITEBACK)),
> @@ -136,14 +139,15 @@ static ssize_t node_read_meminfo(struct device *dev,
>  nid, K(node_page_state(nid, NR_SLAB_RECLAIMABLE) +
>   node_page_state(nid, NR_SLAB_UNRECLAIMABLE)),
>  nid, K(node_page_state(nid, NR_SLAB_RECLAIMABLE)),
> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  nid, K(node_page_state(nid, NR_SLAB_UNRECLAIMABLE))
> - , nid,
> - K(node_page_state(nid, NR_ANON_TRANSPARENT_HUGEPAGES) *
> - HPAGE_PMD_NR));
> -#else
> -nid, K(node_page_state(nid, NR_SLAB_UNRECLAIMABLE)));
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +,nid, K(node_page_state(nid,
> + NR_ANON_TRANSPARENT_HUGEPAGES) * HPAGE_PMD_NR)
> +#endif
> +#ifdef CONFIG_MEMORY_BALLOON
> +,nid, K(node_page_state(nid, NR_BALLOON_PAGES))
>  #endif
> +);
>   n += hugetlb_report_node_meminfo(nid, buf + n);
>   return n;
>  }
> diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
> index aa1eee0..f897fbf 100644
> --- a/fs/proc/meminfo.c
> +++ b/fs/proc/meminfo.c
> @@ -138,6 +138,9 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>   "AnonHugePages:  %8lu kB\n"
>  #endif
> +#ifdef CONFIG_MEMORY_BALLOON
> + "BalloonPages:   %8lu kB\n"
> +#endif
>   ,
>   K(i.totalram),
>   K(i.freeram),
> @@ -193,6 +196,9 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>   ,K(global_page_state(NR_ANON_TRANSPARENT_HUGEPAGES) *
>  HPAGE_PMD_NR)
>  #endif
> +#ifdef CONFIG_MEMORY_BALLOON
> + ,K(global_page_state(NR_BALLOON_PAGES))
> +#endif
>   );
>  
>   hugetlb_report_meminfo(m);
> diff --git a/fs/proc/page.c 

[PATCH 1/5] KEYS: Increase root_maxkeys and root_maxbytes sizes

[David Howells]

From: Steve Dickson 

Now that NFS client uses the kernel key ring facility to store the NFSv4
id/gid mappings, the defaults for root_maxkeys and root_maxbytes need to be
substantially increased.

These values have been soak tested:

https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c73

Signed-off-by: Steve Dickson 
Signed-off-by: David Howells 
---

 security/keys/key.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/keys/key.c b/security/keys/key.c
index b90a68c4e2c4..6d0cad16f002 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -27,8 +27,8 @@ DEFINE_SPINLOCK(key_serial_lock);
 struct rb_root key_user_tree; /* tree of quota records indexed by UID */
 DEFINE_SPINLOCK(key_user_lock);
 
-unsigned int key_quota_root_maxkeys = 200; /* root's key count quota */
-unsigned int key_quota_root_maxbytes = 2;  /* root's key space quota */
+unsigned int key_quota_root_maxkeys = 100; /* root's key count quota */
+unsigned int key_quota_root_maxbytes = 2500; /* root's key space quota */
 unsigned int key_quota_maxkeys = 200;  /* general key count quota */
 unsigned int key_quota_maxbytes = 2;   /* general key space quota */
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] PEFILE: Relax the check on the length of the PKCS#7 cert

[David Howells]

Relax the check on the length of the PKCS#7 cert as it appears that the PE
file wrapper size gets rounded up to the nearest 8.

The debugging output looks like this:

PEFILE: ==> verify_pefile_signature()
PEFILE: ==> pefile_parse_binary()
PEFILE: checksum @ 110
PEFILE: header size = 200
PEFILE: cert = 968 @547be0 [68 09 00 00 00 02 02 00 30 82 09 56 ]
PEFILE: sig wrapper = { 968, 200, 2 }
PEFILE: Signature data not PKCS#7

The wrapper is the first 8 bytes of the hex dump inside [].  This indicates a
length of 0x968 bytes, including the wrapper header - so 0x960 bytes of
payload.

The ASN.1 wrapper begins [ ... 30 82 09 56 ].  That indicates an object of size
0x956 - a four byte discrepency, presumably just padding for alignment
purposes.

So we just check that the ASN.1 container is no bigger than the payload and
reduce the recorded size appropriately.

Whilst we're at it, allow shorter PKCS#7 objects that manage to squeeze within
127 or 255 bytes.  It's just about conceivable if no X.509 certs are included
in the PKCS#7 message.

Reported-by: Vivek Goyal 
Signed-off-by: David Howells 
Acked-by: Vivek Goyal 
Acked-by: Peter Jones 
---

 crypto/asymmetric_keys/verify_pefile.c |   49 ++--
 1 file changed, 33 insertions(+), 16 deletions(-)

diff --git a/crypto/asymmetric_keys/verify_pefile.c 
b/crypto/asymmetric_keys/verify_pefile.c
index 79175e6ea0b2..90122831b818 100644
--- a/crypto/asymmetric_keys/verify_pefile.c
+++ b/crypto/asymmetric_keys/verify_pefile.c
@@ -128,6 +128,7 @@ static int pefile_strip_sig_wrapper(const void *pebuf,
 {
struct win_certificate wrapper;
const u8 *pkcs7;
+   unsigned len;
 
if (ctx->sig_len < sizeof(wrapper)) {
pr_debug("Signature wrapper too short\n");
@@ -154,33 +155,49 @@ static int pefile_strip_sig_wrapper(const void *pebuf,
return -ENOTSUPP;
}
 
-   /* Looks like actual pkcs signature length is in wrapper->length.
-* size obtained from data dir entries lists the total size of
-* certificate table which is also aligned to octawrod boundary.
-*
-* So set signature length field appropriately.
+   /* It looks like the pkcs signature length in wrapper->length and the
+* size obtained from the data dir entries, which lists the total size
+* of certificate table, are both aligned to an octaword boundary, so
+* we may have to deal with some padding.
 */
ctx->sig_len = wrapper.length;
ctx->sig_offset += sizeof(wrapper);
ctx->sig_len -= sizeof(wrapper);
-   if (ctx->sig_len == 0) {
+   if (ctx->sig_len < 4) {
pr_debug("Signature data missing\n");
return -EKEYREJECTED;
}
 
-   /* What's left should a PKCS#7 cert */
+   /* What's left should be a PKCS#7 cert */
pkcs7 = pebuf + ctx->sig_offset;
-   if (pkcs7[0] == (ASN1_CONS_BIT | ASN1_SEQ)) {
-   if (pkcs7[1] == 0x82 &&
-   pkcs7[2] == (((ctx->sig_len - 4) >> 8) & 0xff) &&
-   pkcs7[3] ==  ((ctx->sig_len - 4)   & 0xff))
-   return 0;
-   if (pkcs7[1] == 0x80)
-   return 0;
-   if (pkcs7[1] > 0x82)
-   return -EMSGSIZE;
+   if (pkcs7[0] != (ASN1_CONS_BIT | ASN1_SEQ))
+   goto not_pkcs7;
+   
+   switch (pkcs7[1]) {
+   case 0 ... 0x7f:
+   len = pkcs7[1] + 2;
+   goto check_len;
+   case ASN1_INDEFINITE_LENGTH:
+   return 0;
+   case 0x81:
+   len = pkcs7[2] + 3;
+   goto check_len;
+   case 0x82:
+   len = ((pkcs7[2] << 8) | pkcs7[3]) + 4;
+   goto check_len;
+   case 0x83 ... 0xff:
+   return -EMSGSIZE;
+   default:
+   goto not_pkcs7;
}
 
+check_len:
+   if (len <= ctx->sig_len) {
+   /* There may be padding */
+   ctx->sig_len = len;
+   return 0;
+   }
+not_pkcs7:
pr_debug("Signature data not PKCS#7\n");
return -ELIBBAD;
 }

--
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 net-next 2/2] r8152: use eth_hw_addr_random

[Sergei Shtylyov]

Hello.

On 9/2/2014 1:55 PM, Hayes Wang wrote:


If the hw doesn't have a valid MAC address, give a random one and
set it to the hw.



Signed-off-by: Hayes Wang 
---
  drivers/net/usb/r8152.c | 39 ---
  1 file changed, 24 insertions(+), 15 deletions(-)



diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b5ff933..2bc1b8d 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -992,32 +992,41 @@ static int rtl8152_set_mac_address(struct net_device 
*netdev, void *p)
return 0;
  }

-static inline void set_ethernet_addr(struct r8152 *tp)
+static int set_ethernet_addr(struct r8152 *tp)
  {
struct net_device *dev = tp->netdev;
+   struct sockaddr sa;
int ret;
-   u8 node_id[8] = {0};

if (tp->version == RTL_VER_01)
-   ret = pla_ocp_read(tp, PLA_IDR, sizeof(node_id), node_id);
+   ret = pla_ocp_read(tp, PLA_IDR, 8, sa.sa_data);
else
-   ret = pla_ocp_read(tp, PLA_BACKUP, sizeof(node_id), node_id);
+   ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);

if (ret < 0) {
-   netif_notice(tp, probe, dev, "inet addr fail\n");
+   netif_err(tp, probe, dev, "Get ether addr fail\n");
+   } else if (!is_valid_ether_addr(sa.sa_data)) {
+   netif_err(tp, probe, dev,
+ "Invalid ether addr %02x:%02x:%02x:%02x:%02x:%02x\n",


  There's now "%pM" format specifier for printing a MAC address.


+ sa.sa_data[0], sa.sa_data[1], sa.sa_data[2],
+ sa.sa_data[3], sa.sa_data[4], sa.sa_data[5]);
+   eth_hw_addr_random(dev);
+   ether_addr_copy(sa.sa_data, dev->dev_addr);
+   ret = rtl8152_set_mac_address(dev, );
+   netif_info(tp, probe, dev,
+  "Random ether addr %02x:%02x:%02x:%02x:%02x:%02x\n",


   Likewise.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] KEYS: Fix public_key asymmetric key subtype name

[David Howells]

The length of the name of an asymmetric key subtype must be stored in struct
asymmetric_key_subtype::name_len so that it can be matched by a search for
":".  Fix the public_key subtype to have
name_len set.

Signed-off-by: David Howells 
---

 crypto/asymmetric_keys/public_key.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/crypto/asymmetric_keys/public_key.c 
b/crypto/asymmetric_keys/public_key.c
index 97eb001960b9..2f6e4fb1a1ea 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -121,6 +121,7 @@ static int public_key_verify_signature_2(const struct key 
*key,
 struct asymmetric_key_subtype public_key_subtype = {
.owner  = THIS_MODULE,
.name   = "public_key",
+   .name_len   = sizeof("public_key") - 1,
.describe   = public_key_describe,
.destroy= public_key_destroy,
.verify_signature   = public_key_verify_signature_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/5] KEYS: Fix use-after-free in assoc_array_gc()

[David Howells]

An edit script should be considered inaccessible by a function once it has
called assoc_array_apply_edit() or assoc_array_cancel_edit().

However, assoc_array_gc() is accessing the edit script just after the
gc_complete: label.

Reported-by: Andreea-Cristina Bernat 
Signed-off-by: David Howells 
Reviewed-by: Andreea-Cristina Bernat 
cc: shemm...@brocade.com
cc: paul...@linux.vnet.ibm.com
---

 lib/assoc_array.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/assoc_array.c b/lib/assoc_array.c
index c0b1007011e1..ae146f0734eb 100644
--- a/lib/assoc_array.c
+++ b/lib/assoc_array.c
@@ -1735,7 +1735,7 @@ ascend_old_tree:
 gc_complete:
edit->set[0].to = new_root;
assoc_array_apply_edit(edit);
-   edit->array->nr_leaves_on_tree = nr_leaves_on_tree;
+   array->nr_leaves_on_tree = nr_leaves_on_tree;
return 0;
 
 enomem:

--
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/5] KEYS: Set pr_fmt() in asymmetric key signature handling

[David Howells]

Printing in base signature handling should have a prefix, so set pr_fmt().

Signed-off-by: David Howells 
---

 crypto/asymmetric_keys/signature.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/crypto/asymmetric_keys/signature.c 
b/crypto/asymmetric_keys/signature.c
index 50b3f880b4ff..7525fd183574 100644
--- a/crypto/asymmetric_keys/signature.c
+++ b/crypto/asymmetric_keys/signature.c
@@ -11,6 +11,7 @@
  * 2 of the Licence, or (at your option) any later version.
  */
 
+#define pr_fmt(fmt) "SIG: "fmt
 #include 
 #include 
 #include 

--
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/5] KEYS: Miscellaneous fixes

[David Howells]

Hi James,

Here are some fixes to go upstream:

 (1) Increase root's key quotas so that the DNS resolver doesn't run out of
 capacity.  This is a bit of a stop-gap whilst I try to improve quota
 recycling, but that's proving to be a bit tricky.

 (2) Fix the definition of the public_key subtype to give the name length.

 (3) Set a prefix for printing from signature handling.

 (4) Fix a use after free in assoc_array_gc().

 (5) Relax a check in the PKCS#7 parser to allow for padding inserted after a
 PKCS#7 message.

They can be found here also:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes

Tagged with:

keys-fixes-20140902

David
---
David Howells (4):
  KEYS: Fix public_key asymmetric key subtype name
  KEYS: Set pr_fmt() in asymmetric key signature handling
  KEYS: Fix use-after-free in assoc_array_gc()
  PEFILE: Relax the check on the length of the PKCS#7 cert

Steve Dickson (1):
  KEYS: Increase root_maxkeys and root_maxbytes sizes


 crypto/asymmetric_keys/public_key.c|1 +
 crypto/asymmetric_keys/signature.c |1 +
 crypto/asymmetric_keys/verify_pefile.c |   49 ++--
 lib/assoc_array.c  |2 +
 security/keys/key.c|4 +--
 5 files changed, 38 insertions(+), 19 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] kernel/signal.c: whitespace fixes

[Richard Weinberger]

Hi!

Am 02.09.2014 14:40, schrieb Vishnu Pratap Singh:
> From: "vishnu.ps" 
> 
> Fix minor errors and warning messages in kernel/signal.c.  These errors were
> reported by checkpatch while working with some modifications in signal.c
> file.
> 
> ERROR: code indent should use tabs where possible - 18
> ERROR: need consistent spacing around '&' (ctx:WxO) - 11
> ERROR: space prohibited after that '~' (ctx:OxW) - 11
> ERROR: trailing whitespace - 4
> ERROR: space required after that ',' (ctx:VxV) - 4
> ERROR: trailing statements should be on next line - 3
> ERROR: "foo * bar" should be "foo *bar" - 1
> 
> total 52 errors fixed.

Please don't run checkpatch.pl on in-kernel files.
The tool is designed to check patches, not files.
Such whitespace cleanups pollute the kernel history, i.e. such that
git blame returns false positives.

The purpose of --file is:
- Checking out-of-tree files (like existing drivers to be imported)
- One notable exception is drivers/staging/, you can run it on these files.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] ARM: at91: update defconfigs

[Nicolas Ferre]

On 02/09/2014 10:49, Alexandre Belloni :
> Following recent work on the AT91 platforms, update the defconfigs to include
> the new power and reset driver, the ADC and touchscreen driver, the new PWM
> driver using the generic PWM framework.
> 
> Also remove deprecated options like CONFIG_PROC_DEVICETREE,
> CONFIG_SCSI_MULTI_LUN, CONFIG_MII, CONFIG_MTD_CHAR.

Nice: to the whole series:

Acked-by: Nicolas Ferre 

Thanks.

> Alexandre Belloni (7):
>   ARM: at91: at91_dt: update defconfig
>   ARM: at91: at91sam9260_9g20: update defconfig
>   ARM: at91: at91sam9261_9g10: update defconfig
>   ARM: at91: at91sam9263: update defconfig
>   ARM: at91: at91sam9g45: update defconfig
>   ARM: at91: at91sam9rl: update defconfig
>   ARM: at91: sama5: update defconfig
> 
>  arch/arm/configs/at91_dt_defconfig  | 25 +
>  arch/arm/configs/at91sam9260_9g20_defconfig | 13 +
>  arch/arm/configs/at91sam9261_9g10_defconfig |  5 ++---
>  arch/arm/configs/at91sam9263_defconfig  | 13 ++---
>  arch/arm/configs/at91sam9g45_defconfig  | 19 +++
>  arch/arm/configs/at91sam9rl_defconfig   | 19 ++-
>  arch/arm/configs/sama5_defconfig| 12 ++--
>  7 files changed, 57 insertions(+), 49 deletions(-)
> 


-- 
Nicolas Ferre
--
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] kernel/signal.c: whitespace fixes

[Jiri Kosina]

On Tue, 2 Sep 2014, Vishnu Pratap Singh wrote:

> From: "vishnu.ps" 
> 
> Fix minor errors and warning messages in kernel/signal.c.  These errors were
> reported by checkpatch while working with some modifications in signal.c
> file.
> 
> ERROR: code indent should use tabs where possible - 18
> ERROR: need consistent spacing around '&' (ctx:WxO) - 11
> ERROR: space prohibited after that '~' (ctx:OxW) - 11
> ERROR: trailing whitespace - 4
> ERROR: space required after that ',' (ctx:VxV) - 4
> ERROR: trailing statements should be on next line - 3
> ERROR: "foo * bar" should be "foo *bar" - 1
> 
> total 52 errors fixed.

I am not taking this through trivial.git; it just clutters results of 'git 
blame' horribly for no measurable gain.

Changes like this are reasonable only if you make any real changes to the 
code at the same time.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: gadget: f_fs: add usb_functionfs_descs_head_v2

[Michal Nazarewicz]

On Tue, Sep 02 2014, Zhuang Jin Can  wrote:
> Add usb_functionfs_descs_head_v2 structure for the new layout of
> descriptors.

NAK.  It's a duplicate of  and even
more importantly, the format of the header is not fixed past the flags
field (e.g. fs_count may be missing), so fs_count, hs_count and ss_count
cannot be in the structure.

> Signed-off-by: Zhuang Jin Can 
> ---
>  include/uapi/linux/usb/functionfs.h |9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/include/uapi/linux/usb/functionfs.h 
> b/include/uapi/linux/usb/functionfs.h
> index 0154b28..0b3f9fc 100644
> --- a/include/uapi/linux/usb/functionfs.h
> +++ b/include/uapi/linux/usb/functionfs.h
> @@ -32,6 +32,15 @@ struct usb_endpoint_descriptor_no_audio {
>   __u8  bInterval;
>  } __attribute__((packed));
>  
> +struct usb_functionfs_descs_head_v2 {
> + __le32 magic;
> + __le32 length;
> + __le32 flags;
> + __le32 fs_count;
> + __le32 hs_count;
> + __le32 ss_count;
> +} __attribute__((packed));
> +
>  /* Legacy format, deprecated as of 3.14. */
>  struct usb_functionfs_descs_head {
>   __le32 magic;

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
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] kernel/signal.c: whitespace fixes

[Vishnu Pratap Singh]

From: "vishnu.ps" 

Fix minor errors and warning messages in kernel/signal.c.  These errors were
reported by checkpatch while working with some modifications in signal.c
file.

ERROR: code indent should use tabs where possible - 18
ERROR: need consistent spacing around '&' (ctx:WxO) - 11
ERROR: space prohibited after that '~' (ctx:OxW) - 11
ERROR: trailing whitespace - 4
ERROR: space required after that ',' (ctx:VxV) - 4
ERROR: trailing statements should be on next line - 3
ERROR: "foo * bar" should be "foo *bar" - 1

total 52 errors fixed.

Signed-off-by: Vishnu Pratap Singh 
---
 kernel/signal.c | 75 ++---
 1 file changed, 39 insertions(+), 36 deletions(-)

diff --git a/kernel/signal.c b/kernel/signal.c
index 8f0876f..06e3d72 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -109,25 +109,28 @@ static inline int has_pending_signals(sigset_t *signal, 
sigset_t *blocked)
switch (_NSIG_WORDS) {
default:
for (i = _NSIG_WORDS, ready = 0; --i >= 0 ;)
-   ready |= signal->sig[i] &~ blocked->sig[i];
+   ready |= signal->sig[i] & ~blocked->sig[i];
break;
 
-   case 4: ready  = signal->sig[3] &~ blocked->sig[3];
-   ready |= signal->sig[2] &~ blocked->sig[2];
-   ready |= signal->sig[1] &~ blocked->sig[1];
-   ready |= signal->sig[0] &~ blocked->sig[0];
+   case 4:
+   ready  = signal->sig[3] & ~blocked->sig[3];
+   ready |= signal->sig[2] & ~blocked->sig[2];
+   ready |= signal->sig[1] & ~blocked->sig[1];
+   ready |= signal->sig[0] & ~blocked->sig[0];
break;
 
-   case 2: ready  = signal->sig[1] &~ blocked->sig[1];
-   ready |= signal->sig[0] &~ blocked->sig[0];
+   case 2:
+   ready  = signal->sig[1] & ~blocked->sig[1];
+   ready |= signal->sig[0] & ~blocked->sig[0];
break;
 
-   case 1: ready  = signal->sig[0] &~ blocked->sig[0];
+   case 1:
+   ready  = signal->sig[0] & ~blocked->sig[0];
}
return ready != 0;
 }
 
-#define PENDING(p,b) has_pending_signals(&(p)->signal, (b))
+#define PENDING(p, b) has_pending_signals(&(p)->signal, (b))
 
 static int recalc_sigpending_tsk(struct task_struct *t)
 {
@@ -180,7 +183,7 @@ int next_signal(struct sigpending *pending, sigset_t *mask)
 * Handle the first word specially: it contains the
 * synchronous signals that need to be dequeued first.
 */
-   x = *s &~ *m;
+   x = *s & ~*m;
if (x) {
if (x & SYNCHRONOUS_MASK)
x &= SYNCHRONOUS_MASK;
@@ -191,7 +194,7 @@ int next_signal(struct sigpending *pending, sigset_t *mask)
switch (_NSIG_WORDS) {
default:
for (i = 1; i < _NSIG_WORDS; ++i) {
-   x = *++s &~ *++m;
+   x = *++s & ~*++m;
if (!x)
continue;
sig = ffz(~x) + i*_NSIG_BPW + 1;
@@ -200,7 +203,7 @@ int next_signal(struct sigpending *pending, sigset_t *mask)
break;
 
case 2:
-   x = s[1] &~ m[1];
+   x = s[1] & ~m[1];
if (!x)
break;
sig = ffz(~x) + _NSIG_BPW + 1;
@@ -1431,7 +1434,7 @@ static int kill_something_info(int sig, struct siginfo 
*info, pid_t pid)
pid ? find_vpid(-pid) : task_pgrp(current));
} else {
int retval = 0, count = 0;
-   struct task_struct * p;
+   struct task_struct *p;
 
for_each_process(p) {
if (task_pid_vnr(p) > 1 &&
@@ -1622,8 +1625,8 @@ bool do_notify_parent(struct task_struct *tsk, int sig)
 
BUG_ON(sig == -1);
 
-   /* do_notify_parent_cldstop should have been called instead.  */
-   BUG_ON(task_is_stopped_or_traced(tsk));
+   /* do_notify_parent_cldstop should have been called instead.  */
+   BUG_ON(task_is_stopped_or_traced(tsk));
 
BUG_ON(!tsk->ptrace &&
   (tsk->group_leader != tsk || !thread_group_empty(tsk)));
@@ -1745,20 +1748,20 @@ static void do_notify_parent_cldstop(struct task_struct 
*tsk,
info.si_utime = cputime_to_clock_t(utime);
info.si_stime = cputime_to_clock_t(stime);
 
-   info.si_code = why;
-   switch (why) {
-   case CLD_CONTINUED:
-   info.si_status = SIGCONT;
-   break;
-   case CLD_STOPPED:
-   info.si_status = tsk->signal->group_exit_code & 0x7f;
-   break;
-   case CLD_TRAPPED:
-   info.si_status = tsk->exit_code & 0x7f;
-   break;
-   default:
-   BUG();
-   }
+   info.si_code = why;
+   switch (why) {
+   case CLD_CONTINUED:
+   

Re: [PATCH v3 4/4] pinctrl: qcom: Add support for reset for apq8064

[Linus Walleij]

On Fri, Aug 29, 2014 at 4:30 PM, Pramod Gurav
 wrote:

> This patch adds support for reset functions to reboot the boards
> with soc apq8064.
>
> CC: Linus Walleij 
> CC: Bjorn Andersson 
> CC: "Ivan T. Ivanov" 
> CC: Stephen Boyd 
> CC: Andy Gross 
> Signed-off-by: Pramod Gurav 

OK patch applied with Björn's ACK.

A bit dirty to have this in this driver, but who cares.

Does the APQ8064 accompanying PMIC also have the ability to
completely shut the system down?

Yours,
Linus Walleij
--
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 3/6] mm/balloon_compaction: isolate balloon pages without lru_lock

[Rafael Aquini]

On Sat, Aug 30, 2014 at 08:41:17PM +0400, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov 
> 
> LRU-lock isn't required for balloon page isolation. This check makes migration
> of some ballooned pages mostly impossible because isolate_migratepages_range()
> drops LRU lock periodically.
> 
> Signed-off-by: Konstantin Khlebnikov 
> Cc: stable  # v3.8
> ---
>  mm/compaction.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 73466e1..ad58f73 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -643,7 +643,7 @@ isolate_migratepages_block(struct compact_control *cc, 
> unsigned long low_pfn,
>*/
>   if (!PageLRU(page)) {
>   if (unlikely(balloon_page_movable(page))) {
> - if (locked && balloon_page_isolate(page)) {
> + if (balloon_page_isolate(page)) {
>   /* Successfully isolated */
>   goto isolate_success;
>   }
> 
Acked-by: Rafael Aquini 

--
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 3/4] pinctrl: msm: Add ps_hold function in pinctrl-apq8064 binding documentation

[Linus Walleij]

On Fri, Aug 29, 2014 at 4:30 PM, Pramod Gurav
 wrote:

> This adds a function ps_hold (Power Suppy Hold Signal) in pinctrl-ap8064
> documentation which was missing. This function is used to reset the targets
> with apq8064 soc.
>
> CC: Linus Walleij 
> Acked-by: Bjorn Andersson 
> CC: "Ivan T. Ivanov" 
> CC: Stephen Boyd 
> CC: Andy Gross 
> Signed-off-by: Pramod Gurav 

Patch applied.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/6] mm/balloon_compaction: keep ballooned pages away from normal migration path

[Rafael Aquini]

On Sat, Aug 30, 2014 at 08:41:13PM +0400, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov 
> 
> Proper testing shows yet another problem in balloon migration: it works only
> once for each page. balloon_page_movable() check page flags and page_count.
> In __unmap_and_move page is locked, reference counter is elevated, so
> balloon_page_movable() _always_ fails here. As result in __unmap_and_move()
> migration goes to the normal migration path.
> 
> Balloon ->migratepage() is so special, it returns MIGRATEPAGE_BALLOON_SUCCESS
> instead of MIGRATEPAGE_SUCCESS. After that in move_to_new_page() successfully
> migrated page got NULL into its mapping pointer and loses connectivity with
> balloon and ability for further migration.
> 
> It's safe to use __is_movable_balloon_page here: page is isolated and pinned.
> 
> Signed-off-by: Konstantin Khlebnikov 
> Cc: stable  # v3.8
> ---
>  include/linux/balloon_compaction.h |5 +
>  mm/migrate.c   |2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/balloon_compaction.h 
> b/include/linux/balloon_compaction.h
> index 53d482e..284fc1d 100644
> --- a/include/linux/balloon_compaction.h
> +++ b/include/linux/balloon_compaction.h
> @@ -258,6 +258,11 @@ static inline void balloon_page_delete(struct page *page)
>   list_del(>lru);
>  }
>  
> +static inline bool __is_movable_balloon_page(struct page *page)
> +{
> + return false;
> +}
> +
>  static inline bool balloon_page_movable(struct page *page)
>  {
>   return false;
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 905b1aa..57c94f9 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -873,7 +873,7 @@ static int __unmap_and_move(struct page *page, struct 
> page *newpage,
>   }
>   }
>  
> - if (unlikely(balloon_page_movable(page))) {
> + if (unlikely(__is_movable_balloon_page(page))) {
>   /*
>* A ballooned page does not need any special attention from
>* physical to virtual reverse mapping procedures.
> 
Acked-by: Rafael Aquini 

--
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/6] mm/balloon_compaction: ignore anonymous pages

[Rafael Aquini]

On Sat, Aug 30, 2014 at 08:41:09PM +0400, Konstantin Khlebnikov wrote:
> From: Konstantin Khlebnikov 
> 
> Sasha Levin reported KASAN splash inside isolate_migratepages_range().
> Problem is in function __is_movable_balloon_page() which tests AS_BALLOON_MAP
> in page->mapping->flags. This function has no protection against anonymous
> pages. As result it tried to check address space flags in inside anon-vma.
> 
> Signed-off-by: Konstantin Khlebnikov 
> Reported-by: Sasha Levin 
> Link: http://lkml.kernel.org/p/53e6ceaa.9020...@oracle.com
> Cc: stable  # v3.8
> ---
>  include/linux/balloon_compaction.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/balloon_compaction.h 
> b/include/linux/balloon_compaction.h
> index 089743a..53d482e 100644
> --- a/include/linux/balloon_compaction.h
> +++ b/include/linux/balloon_compaction.h
> @@ -128,7 +128,7 @@ static inline bool page_flags_cleared(struct page *page)
>  static inline bool __is_movable_balloon_page(struct page *page)
>  {
>   struct address_space *mapping = page->mapping;
> - return mapping_balloon(mapping);
> + return !PageAnon(page) && mapping_balloon(mapping);
>  }
>  
>  /*
> 
Acked-by: Rafael Aquini 

--
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] pinctrl: qcom: Release pin ranges when gpiochip_irqchip_add fails

[Linus Walleij]

On Wed, Aug 27, 2014 at 12:57 PM, Pramod Gurav
 wrote:

> This patches adds a call to gpiochip_remove_pin_ranges when
> gpiochip_irqchip_add fails to release memory allocated for pin_ranges.
>
> CC: Ivan T. Ivanov 
> CC: Bjorn Andersson 
> CC: Linus Walleij 
> Signed-off-by: Pramod Gurav 

Dropping this one as the gpiochip_remove() patch fixes the
problem.

Yours,
Linus Walleij
--
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] pinctrl: qcom: remove gpiochip in failure cases

[Linus Walleij]

On Fri, Aug 29, 2014 at 10:11 AM, Pramod Gurav
 wrote:

> This patch releases gpiochip related resources by calling
> gpiochip_remove when either of gpiochip_add_pin_range and
> gpiochip_irqchip_add fails.
>
> CC: Linus Walleij 
> CC: Bjorn Andersson 
> CC: "Ivan T. Ivanov" 
> Signed-off-by: Pramod Gurav 
> ---
>
> Changes since v1:
> - In v1 of this patch gpiochip_remove was called only in failure case of
>   gpiochip_irqchip_add. This patchs adds a call to gpiochip_remove in failure
>   case of gpiochip_add_pin_range as well.

Patch applied with Björn's ACK.

Yours,
Linus Walleij
--
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: [uas/3.16.1] panic in uas_data_cmplt()

[Chunwei Chen]

On 西元2014年09月02日 14:50, Hans de Goede wrote:
> Hi,
> 
> On 09/02/2014 06:18 AM, Chunwei Chen wrote:
>> Dear all:
>>
>> The kernel version is 3.16.1-1-ARCH
>>
>> Today I keep getting this panic when booting up.
>> http://i.imgur.com/0Rx93Kr.jpg
>>
>> It might be that the UAS device was in some strange state,
>> because that after I unplugged and power-cycled the UAS,
>> everything went normal again.
>>
>> Does anyone know what's the root cause of this issue?
>> Or could anyone provide some instruction on how to debug this issue?
> 
> There seem to be some issues in the error handling paths of the uas
> driver. I plan to rewrite them completely for robustness and go
> through them with a fine comb to fix any possible bugs while at it.
> 
> I'll send out a mail when I've a new version ready for testing.
> 
> Regards,
> 
> Hans
> 

Hi Hans,

Thanks for looking into this.

Kind regards,
Chunwei
--
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] i2c: i2c-tegra: Move clk_prepare/clk_set_rate to probe

[Wolfram Sang]

On Fri, Aug 15, 2014 at 10:18:15AM -0600, Stephen Warren wrote:
> On 08/15/2014 03:47 AM, Mikko Perttunen wrote:
> >Currently the i2c-tegra bus driver prepares, enables
> >and set_rates its clocks separately for each transfer.
> >This causes locking problems when doing I2C transfers
> >from clock notifiers; see
> >http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/268653.html
> >
> >This patch moves clk_prepare/unprepare and clk_set_rate calls to
> >the probe function, leaving only clk_enable/disable to be
> >done on each transfer. This solves the locking issue.
> 
> >diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> 
> >@@ -380,34 +380,33 @@ static inline int tegra_i2c_clock_enable(struct 
> >tegra_i2c_dev *i2c_dev)
> >  {
> > int ret;
> > if (!i2c_dev->hw->has_single_clk_source) {
> >-ret = clk_prepare_enable(i2c_dev->fast_clk);
> >+ret = clk_enable(i2c_dev->fast_clk);
> 
> Here, both the prepare and enable wrap just the I2C transfer, ...
> 
> >@@ -428,9 +427,6 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
> > i2c_writel(i2c_dev, val, I2C_CNFG);
> > i2c_writel(i2c_dev, 0, I2C_INT_MASK);
> >
> >-clk_multiplier *= (i2c_dev->hw->clk_divisor_std_fast_mode + 1);
> >-clk_set_rate(i2c_dev->div_clk, i2c_dev->bus_clk_rate * clk_multiplier);
> 
> ... whereas the rate is set up when the controller is initialized, i.e. much
> earlier.
> 
> >@@ -777,17 +774,39 @@ static int tegra_i2c_probe(struct platform_device 
> >*pdev)
> 
> >+if (!i2c_dev->hw->has_single_clk_source) {
> >+ret = clk_prepare(i2c_dev->fast_clk);
> >+if (ret < 0) {
> >+dev_err(i2c_dev->dev, "Clock prepare failed %d\n", ret);
> >+return ret;
> >+}
> >+}
> >+
> >+ret = clk_prepare(i2c_dev->div_clk);
> >+if (ret < 0) {
> >+dev_err(i2c_dev->dev, "Clock prepare failed %d\n", ret);
> >+goto unprepare_fast_clk;
> >+}
> >+
> >+clk_multiplier *= (i2c_dev->hw->clk_divisor_std_fast_mode + 1);
> >+ret = clk_set_rate(i2c_dev->div_clk,
> >+   i2c_dev->bus_clk_rate * clk_multiplier);
> >+if (ret) {
> >+dev_err(i2c_dev->dev, "Clock rate change failed %d\n", ret);
> >+goto unprepare_div_clk;
> >+}
> 
> However, the new code sets the clock rate after the clock is prepared. I
> think the rate should be set first, then the clock prepared. While this
> likely doesn't apply to the Tegra clock controller, prepare() is allowed to
> enable the clock if enable() can't be implemented in an atomic fashion (in
> which case enable/disable would be no-ops), and we should make sure that the
> driver correctly configures the clock before potentially enabling it.
> 
> I'm not sure if a similar change to our SPI drivers is possible; after all,
> the SPI transfer rate can vary per message, so if clk_set_rate() acquires a
> lock, it seems there's no way to avoid the issue there. Luckily, we don't
> have any SPI-based chips that do anything related to clocks on any of our
> current boards...
> 
> Aside from this issue, the patch looks fine to me.

May I count this as an Ack?



signature.asc
Description: Digital signature

Re: [PATCH v2 4/4] mfd: lpc_sch: remove FSF address

[Lee Jones]

On Tue, 02 Sep 2014, Andy Shevchenko wrote:

> This patch removes FSF address because it can be changed. While here, update
> the copyright lines by adding Intel Corp. to them.
> 
> There is no functional change.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mfd/lpc_sch.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/lpc_sch.c b/drivers/mfd/lpc_sch.c
> index ae614b2..c980da4 100644
> --- a/drivers/mfd/lpc_sch.c
> +++ b/drivers/mfd/lpc_sch.c
> @@ -7,6 +7,7 @@
>   *  Configuration Registers.
>   *
>   *  Copyright (c) 2010 CompuLab Ltd
> + *  Copyright (c) 2014 Intel Corp.
>   *  Author: Denis Turischev 
>   *
>   *  This program is free software; you can redistribute it and/or modify
> @@ -17,10 +18,6 @@
>   *  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; see the file COPYING.  If not, write to
> - *  the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
>   */
>  
>  #include 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 3/4] mfd: lpc_sch: Add support for Intel Quark X1000

[Lee Jones]

On Tue, 02 Sep 2014, Andy Shevchenko wrote:

> Intel Quark X1000 SoC supports IRQ based GPIO. This patch will
> enable MFD support for Quark X1000 and provide IRQ resources
> to Quark X1000 GPIO device driver.
> 
> Signed-off-by: Chang Rebecca Swee Fun 
> Tested-by: Chang Rebecca Swee Fun 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mfd/lpc_sch.c | 37 +++--
>  1 file changed, 31 insertions(+), 6 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/lpc_sch.c b/drivers/mfd/lpc_sch.c
> index bde070a..ae614b2 100644
> --- a/drivers/mfd/lpc_sch.c
> +++ b/drivers/mfd/lpc_sch.c
> @@ -37,6 +37,9 @@
>  #define GPIO_IO_SIZE 64
>  #define GPIO_IO_SIZE_CENTERTON   128
>  
> +/* Intel Quark X1000 GPIO IRQ Number */
> +#define GPIO_IRQ_QUARK_X1000 9
> +
>  #define WDTBASE  0x84
>  #define WDT_IO_SIZE  64
>  
> @@ -44,28 +47,37 @@ enum sch_chipsets {
>   LPC_SCH = 0,/* Intel Poulsbo SCH */
>   LPC_ITC,/* Intel Tunnel Creek */
>   LPC_CENTERTON,  /* Intel Centerton */
> + LPC_QUARK_X1000,/* Intel Quark X1000 */
>  };
>  
>  struct lpc_sch_info {
>   unsigned int io_size_smbus;
>   unsigned int io_size_gpio;
>   unsigned int io_size_wdt;
> + int irq_gpio;
>  };
>  
>  static struct lpc_sch_info sch_chipset_info[] = {
>   [LPC_SCH] = {
>   .io_size_smbus = SMBUS_IO_SIZE,
>   .io_size_gpio = GPIO_IO_SIZE,
> + .irq_gpio = -1,
>   },
>   [LPC_ITC] = {
>   .io_size_smbus = SMBUS_IO_SIZE,
>   .io_size_gpio = GPIO_IO_SIZE,
>   .io_size_wdt = WDT_IO_SIZE,
> + .irq_gpio = -1,
>   },
>   [LPC_CENTERTON] = {
>   .io_size_smbus = SMBUS_IO_SIZE,
>   .io_size_gpio = GPIO_IO_SIZE_CENTERTON,
>   .io_size_wdt = WDT_IO_SIZE,
> + .irq_gpio = -1,
> + },
> + [LPC_QUARK_X1000] = {
> + .io_size_gpio = GPIO_IO_SIZE,
> + .irq_gpio = GPIO_IRQ_QUARK_X1000,
>   },
>  };
>  
> @@ -73,6 +85,7 @@ static const struct pci_device_id lpc_sch_ids[] = {
>   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SCH_LPC), LPC_SCH },
>   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ITC_LPC), LPC_ITC },
>   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_CENTERTON_ILB), LPC_CENTERTON 
> },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB), 
> LPC_QUARK_X1000 },
>   { 0, }
>  };
>  MODULE_DEVICE_TABLE(pci, lpc_sch_ids);
> @@ -110,13 +123,13 @@ static int lpc_sch_get_io(struct pci_dev *pdev, int 
> where, const char *name,
>  }
>  
>  static int lpc_sch_populate_cell(struct pci_dev *pdev, int where,
> -  const char *name, int size, int id,
> -  struct mfd_cell *cell)
> +  const char *name, int size, int irq,
> +  int id, struct mfd_cell *cell)
>  {
>   struct resource *res;
>   int ret;
>  
> - res = devm_kzalloc(>dev, sizeof(*res), GFP_KERNEL);
> + res = devm_kcalloc(>dev, 2, sizeof(*res), GFP_KERNEL);
>   if (!res)
>   return -ENOMEM;
>  
> @@ -132,6 +145,18 @@ static int lpc_sch_populate_cell(struct pci_dev *pdev, 
> int where,
>   cell->ignore_resource_conflicts = true;
>   cell->id = id;
>  
> + /* Check if we need to add an IRQ resource */
> + if (irq < 0)
> + return 0;
> +
> + res++;
> +
> + res->start = irq;
> + res->end = irq;
> + res->flags = IORESOURCE_IRQ;
> +
> + cell->num_resources++;
> +
>   return 0;
>  }
>  
> @@ -143,7 +168,7 @@ static int lpc_sch_probe(struct pci_dev *dev, const 
> struct pci_device_id *id)
>   int ret;
>  
>   ret = lpc_sch_populate_cell(dev, SMBASE, "isch_smbus",
> - info->io_size_smbus,
> + info->io_size_smbus, -1,
>   id->device, _sch_cells[cells]);
>   if (ret < 0)
>   return ret;
> @@ -151,7 +176,7 @@ static int lpc_sch_probe(struct pci_dev *dev, const 
> struct pci_device_id *id)
>   cells++;
>  
>   ret = lpc_sch_populate_cell(dev, GPIOBASE, "sch_gpio",
> - info->io_size_gpio,
> + info->io_size_gpio, info->irq_gpio,
>   id->device, _sch_cells[cells]);
>   if (ret < 0)
>   return ret;
> @@ -159,7 +184,7 @@ static int lpc_sch_probe(struct pci_dev *dev, const 
> struct pci_device_id *id)
>   cells++;
>  
>   ret = lpc_sch_populate_cell(dev, WDTBASE, "ie6xx_wdt",
> - info->io_size_wdt,
> + info->io_size_wdt, -1,
>   id->device, _sch_cells[cells]);
>   if (ret < 0)
>   return ret;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead

Re: [PATCH v2 2/4] pci_ids: add support for Intel Quark ILB

[Lee Jones]

On Tue, 02 Sep 2014, Andy Shevchenko wrote:

> From: Josef Ahmad 
> 
> This patch adds the PCI id for Intel Quark ILB.
> It will be used for GPIO and Multifunction device driver.
> 
> Signed-off-by: Josef Ahmad 
> Acked-by: Bjorn Helgaas 
> Signed-off-by: Andy Shevchenko 
> ---
>  include/linux/pci_ids.h | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 6ed0bb7..4e82195 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2557,6 +2557,7 @@
>  #define PCI_DEVICE_ID_INTEL_MFD_EMMC00x0823
>  #define PCI_DEVICE_ID_INTEL_MFD_EMMC10x0824
>  #define PCI_DEVICE_ID_INTEL_MRST_SD2 0x084F
> +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB  0x095E
>  #define PCI_DEVICE_ID_INTEL_I960 0x0960
>  #define PCI_DEVICE_ID_INTEL_I960RM   0x0962
>  #define PCI_DEVICE_ID_INTEL_CENTERTON_ILB0x0c60

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/4] mfd: lpc_sch: reduce duplicate code and improve manageability

[Lee Jones]

On Tue, 02 Sep 2014, Andy Shevchenko wrote:

> This patch refactors the driver to use helper functions instead of
> copy'n'pasted pieces of code.
> 
> It also introduces an additional struct to hold a chipset info. The chipset
> info will be used to store features that are supported by specific processor 
> or
> chipset. LPC_SCH supports SMBUS, GPIO and WDT features. As this code base 
> might
> expand further to support more processors, this implementation will help to
> keep code base clean and manageable.
> 
> The patch is partially based on the work done by Chang Rebecca Swee Fun.
> 
> Tested-by: Chang Rebecca Swee Fun 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mfd/lpc_sch.c | 181 
> +++---
>  1 file changed, 99 insertions(+), 82 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/lpc_sch.c b/drivers/mfd/lpc_sch.c
> index 4ee7550..bde070a 100644
> --- a/drivers/mfd/lpc_sch.c
> +++ b/drivers/mfd/lpc_sch.c
> @@ -40,120 +40,137 @@
>  #define WDTBASE  0x84
>  #define WDT_IO_SIZE  64
>  
> -static struct resource smbus_sch_resource = {
> - .flags = IORESOURCE_IO,
> +enum sch_chipsets {
> + LPC_SCH = 0,/* Intel Poulsbo SCH */
> + LPC_ITC,/* Intel Tunnel Creek */
> + LPC_CENTERTON,  /* Intel Centerton */
>  };
>  
> -static struct resource gpio_sch_resource = {
> - .flags = IORESOURCE_IO,
> +struct lpc_sch_info {
> + unsigned int io_size_smbus;
> + unsigned int io_size_gpio;
> + unsigned int io_size_wdt;
>  };
>  
> -static struct resource wdt_sch_resource = {
> - .flags = IORESOURCE_IO,
> -};
> -
> -static struct mfd_cell lpc_sch_cells[3];
> -
> -static struct mfd_cell isch_smbus_cell = {
> - .name = "isch_smbus",
> - .num_resources = 1,
> - .resources = _sch_resource,
> - .ignore_resource_conflicts = true,
> -};
> -
> -static struct mfd_cell sch_gpio_cell = {
> - .name = "sch_gpio",
> - .num_resources = 1,
> - .resources = _sch_resource,
> - .ignore_resource_conflicts = true,
> -};
> -
> -static struct mfd_cell wdt_sch_cell = {
> - .name = "ie6xx_wdt",
> - .num_resources = 1,
> - .resources = _sch_resource,
> - .ignore_resource_conflicts = true,
> +static struct lpc_sch_info sch_chipset_info[] = {
> + [LPC_SCH] = {
> + .io_size_smbus = SMBUS_IO_SIZE,
> + .io_size_gpio = GPIO_IO_SIZE,
> + },
> + [LPC_ITC] = {
> + .io_size_smbus = SMBUS_IO_SIZE,
> + .io_size_gpio = GPIO_IO_SIZE,
> + .io_size_wdt = WDT_IO_SIZE,
> + },
> + [LPC_CENTERTON] = {
> + .io_size_smbus = SMBUS_IO_SIZE,
> + .io_size_gpio = GPIO_IO_SIZE_CENTERTON,
> + .io_size_wdt = WDT_IO_SIZE,
> + },
>  };
>  
>  static const struct pci_device_id lpc_sch_ids[] = {
> - { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SCH_LPC) },
> - { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ITC_LPC) },
> - { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_CENTERTON_ILB) },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SCH_LPC), LPC_SCH },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ITC_LPC), LPC_ITC },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_CENTERTON_ILB), LPC_CENTERTON 
> },
>   { 0, }
>  };
>  MODULE_DEVICE_TABLE(pci, lpc_sch_ids);
>  
> -static int lpc_sch_probe(struct pci_dev *dev,
> - const struct pci_device_id *id)
> +#define LPC_NO_RESOURCE  1
> +#define LPC_SKIP_RESOURCE2
> +
> +static int lpc_sch_get_io(struct pci_dev *pdev, int where, const char *name,
> +   struct resource *res, int size)
>  {
>   unsigned int base_addr_cfg;
>   unsigned short base_addr;
> - int i, cells = 0;
> - int ret;
>  
> - pci_read_config_dword(dev, SMBASE, _addr_cfg);
> + if (size == 0)
> + return LPC_NO_RESOURCE;
> +
> + pci_read_config_dword(pdev, where, _addr_cfg);
>   base_addr = 0;
>   if (!(base_addr_cfg & (1 << 31)))
> - dev_warn(>dev, "Decode of the SMBus I/O range disabled\n");
> + dev_warn(>dev, "Decode of the %s I/O range disabled\n",
> +  name);
>   else
>   base_addr = (unsigned short)base_addr_cfg;
>  
>   if (base_addr == 0) {
> - dev_warn(>dev, "I/O space for SMBus uninitialized\n");
> - } else {
> - lpc_sch_cells[cells++] = isch_smbus_cell;
> - smbus_sch_resource.start = base_addr;
> - smbus_sch_resource.end = base_addr + SMBUS_IO_SIZE - 1;
> + dev_warn(>dev, "I/O space for %s uninitialized\n", name);
> + return LPC_SKIP_RESOURCE;
>   }
>  
> - pci_read_config_dword(dev, GPIOBASE, _addr_cfg);
> - base_addr = 0;
> - if (!(base_addr_cfg & (1 << 31)))
> - dev_warn(>dev, "Decode of the GPIO I/O range 

[char-misc-next 5/6] mei: push pci cfg structure me hw

[Tomas Winkler]

Device specific configurations are currently only needed by me hw
so we can remove it from txe

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/hw-me.c   |  7 +--
 drivers/misc/mei/hw-me.h   | 26 +-
 drivers/misc/mei/hw-txe.c  | 22 +++---
 drivers/misc/mei/hw-txe.h  |  5 +
 drivers/misc/mei/mei_dev.h | 20 
 drivers/misc/mei/pci-txe.c |  6 +++---
 6 files changed, 41 insertions(+), 45 deletions(-)

diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index da86310..77166ea 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -110,8 +110,9 @@ static inline void mei_hcsr_set(struct mei_me_hw *hw, u32 
hcsr)
 static int mei_me_fw_status(struct mei_device *dev,
struct mei_fw_status *fw_status)
 {
-   const struct mei_fw_status *fw_src = >cfg->fw_status;
struct pci_dev *pdev = to_pci_dev(dev->dev);
+   struct mei_me_hw *hw = to_me_hw(dev);
+   const struct mei_fw_status *fw_src = >cfg->fw_status;
int ret;
int i;
 
@@ -846,14 +847,16 @@ struct mei_device *mei_me_dev_init(struct pci_dev *pdev,
   const struct mei_cfg *cfg)
 {
struct mei_device *dev;
+   struct mei_me_hw *hw;
 
dev = kzalloc(sizeof(struct mei_device) +
 sizeof(struct mei_me_hw), GFP_KERNEL);
if (!dev)
return NULL;
+   hw = to_me_hw(dev);
 
mei_device_init(dev, >dev, _me_hw_ops);
-   dev->cfg  = cfg;
+   hw->cfg = cfg;
return dev;
 }
 
diff --git a/drivers/misc/mei/hw-me.h b/drivers/misc/mei/hw-me.h
index 12b0f4b..b0001b3 100644
--- a/drivers/misc/mei/hw-me.h
+++ b/drivers/misc/mei/hw-me.h
@@ -19,14 +19,38 @@
 #ifndef _MEI_INTERFACE_H_
 #define _MEI_INTERFACE_H_
 
-#include 
 #include 
+#include 
+#include 
+
 #include "mei_dev.h"
 #include "client.h"
 
+/*
+ * mei_cfg - mei device configuration
+ *
+ * @fw_status: FW status
+ * @quirk_probe: device exclusion quirk
+ */
+struct mei_cfg {
+   const struct mei_fw_status fw_status;
+   bool (*quirk_probe)(struct pci_dev *pdev);
+};
+
+
+#define MEI_PCI_DEVICE(dev, cfg) \
+   .vendor = PCI_VENDOR_ID_INTEL, .device = (dev), \
+   .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, \
+   .driver_data = (kernel_ulong_t)&(cfg)
+
+
 #define MEI_ME_RPM_TIMEOUT500 /* ms */
 
+/**
+ * @cfg: per device generation config and ops
+ */
 struct mei_me_hw {
+   const struct mei_cfg *cfg;
void __iomem *mem_addr;
/*
 * hw states of host and fw(ME)
diff --git a/drivers/misc/mei/hw-txe.c b/drivers/misc/mei/hw-txe.c
index 6eef676..f33fbcb 100644
--- a/drivers/misc/mei/hw-txe.c
+++ b/drivers/misc/mei/hw-txe.c
@@ -573,6 +573,11 @@ static int mei_txe_readiness_wait(struct mei_device *dev)
return 0;
 }
 
+const struct mei_fw_status mei_txe_fw_sts = {
+   .count = 2,
+   .status[0] = PCI_CFG_TXE_FW_STS0,
+   .status[1] = PCI_CFG_TXE_FW_STS1
+};
 
 /**
  * mei_txe_fw_status - read fw status register from pci config space
@@ -583,7 +588,7 @@ static int mei_txe_readiness_wait(struct mei_device *dev)
 static int mei_txe_fw_status(struct mei_device *dev,
 struct mei_fw_status *fw_status)
 {
-   const struct mei_fw_status *fw_src = >cfg->fw_status;
+   const struct mei_fw_status *fw_src = _txe_fw_sts;
struct pci_dev *pdev = to_pci_dev(dev->dev);
int ret;
int i;
@@ -1120,27 +1125,15 @@ static const struct mei_hw_ops mei_txe_hw_ops = {
 
 };
 
-#define MEI_CFG_TXE_FW_STS\
-   .fw_status.count = 2, \
-   .fw_status.status[0] = PCI_CFG_TXE_FW_STS0,   \
-   .fw_status.status[1] = PCI_CFG_TXE_FW_STS1
-
-const struct mei_cfg mei_txe_cfg = {
-   MEI_CFG_TXE_FW_STS,
-};
-
-
 /**
  * mei_txe_dev_init - allocates and initializes txe hardware specific structure
  *
  * @pdev - pci device
- * @cfg - per device generation config
  *
  * returns struct mei_device * on success or NULL;
  *
  */
-struct mei_device *mei_txe_dev_init(struct pci_dev *pdev,
-   const struct mei_cfg *cfg)
+struct mei_device *mei_txe_dev_init(struct pci_dev *pdev)
 {
struct mei_device *dev;
struct mei_txe_hw *hw;
@@ -1156,7 +1149,6 @@ struct mei_device *mei_txe_dev_init(struct pci_dev *pdev,
 
init_waitqueue_head(>wait_aliveness_resp);
 
-   dev->cfg  = cfg;
return dev;
 }
 
diff --git a/drivers/misc/mei/hw-txe.h b/drivers/misc/mei/hw-txe.h
index e244af7..e8dd2d1 100644
--- a/drivers/misc/mei/hw-txe.h
+++ b/drivers/misc/mei/hw-txe.h
@@ -61,10 +61,7 @@ static inline struct mei_device *hw_txe_to_mei(struct 
mei_txe_hw *hw)
return container_of((void *)hw, struct mei_device, hw);
 }
 
-extern const struct mei_cfg mei_txe_cfg;
-
-struct mei_device *mei_txe_dev_init(struct pci_dev *pdev,
-   const struct mei_cfg