Re: [PATCH V2] powerpc/mm: Fix Multi hit ERAT cause by recent THP update

[Kirill A. Shutemov]

On Mon, Feb 08, 2016 at 11:44:22AM +0530, Aneesh Kumar K.V wrote:
> With ppc64 we use the deposited pgtable_t to store the hash pte slot
> information. We should not withdraw the deposited pgtable_t without
> marking the pmd none. This ensure that low level hash fault handling
> will skip this huge pte and we will handle them at upper levels.
> 
> Recent change to pmd splitting changed the above in order to handle the
> race between pmd split and exit_mmap. The race is explained below.
> 
> Consider following race:
> 
>   CPU0CPU1
> shrink_page_list()
>   add_to_swap()
> split_huge_page_to_list()
>   __split_huge_pmd_locked()
> pmdp_huge_clear_flush_notify()
>   // pmd_none() == true
>   exit_mmap()
> unmap_vmas()
>   zap_pmd_range()
> // no action on pmd since 
> pmd_none() == true
>   pmd_populate()
> 
> As result the THP will not be freed. The leak is detected by check_mm():
> 
>   BUG: Bad rss-counter state mm:880058d2e580 idx:1 val:512
> 
> The above required us to not mark pmd none during a pmd split.
> 
> The fix for ppc is to clear the huge pte of _PAGE_USER, so that low
> level fault handling code skip this pte. At higher level we do take ptl
> lock. That should serialze us against the pmd split. Once the lock is
> acquired we do check the pmd again using pmd_same. That should always
> return false for us and hence we should retry the access.

I guess it worth mention that this serialization against ptl happens in
huge_pmd_set_accessed(), if I didn't miss anything.

> 
> Also make sure we wait for irq disable section in other cpus to finish
> before flipping a huge pte entry with a regular pmd entry. Code paths
> like find_linux_pte_or_hugepte depend on irq disable to get
> a stable pte_t pointer. A parallel thp split need to make sure we
> don't convert a pmd pte to a regular pmd entry without waiting for the
> irq disable section to finish.
> 
> Signed-off-by: Aneesh Kumar K.V 
> ---
>  arch/powerpc/include/asm/book3s/64/pgtable.h |  4 
>  arch/powerpc/mm/pgtable_64.c | 35 
> +++-
>  include/asm-generic/pgtable.h|  8 +++
>  mm/huge_memory.c |  1 +
>  4 files changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
> b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 8d1c41d28318..0415856941e0 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -281,6 +281,10 @@ extern pgtable_t pgtable_trans_huge_withdraw(struct 
> mm_struct *mm, pmd_t *pmdp);
>  extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long 
> address,
>   pmd_t *pmdp);
>  
> +#define __HAVE_ARCH_PMDP_HUGE_SPLITTING_FLUSH
> +extern void pmdp_huge_splitting_flush(struct vm_area_struct *vma,
> +   unsigned long address, pmd_t *pmdp);
> +
>  #define pmd_move_must_withdraw pmd_move_must_withdraw
>  struct spinlock;
>  static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
> index 3124a20d0fab..e8214b7f2210 100644
> --- a/arch/powerpc/mm/pgtable_64.c
> +++ b/arch/powerpc/mm/pgtable_64.c
> @@ -646,6 +646,30 @@ pgtable_t pgtable_trans_huge_withdraw(struct mm_struct 
> *mm, pmd_t *pmdp)
>   return pgtable;
>  }
>  
> +void pmdp_huge_splitting_flush(struct vm_area_struct *vma,
> +unsigned long address, pmd_t *pmdp)
> +{
> + VM_BUG_ON(address & ~HPAGE_PMD_MASK);
> +
> +#ifdef CONFIG_DEBUG_VM
> + BUG_ON(REGION_ID(address) != USER_REGION_ID);
> +#endif
> + /*
> +  * We can't mark the pmd none here, because that will cause a race
> +  * against exit_mmap. We need to continue mark pmd TRANS HUGE, while
> +  * we spilt, but at the same time we wan't rest of the ppc64 code
> +  * not to insert hash pte on this, because we will be modifying
> +  * the deposited pgtable in the caller of this function. Hence
> +  * clear the _PAGE_USER so that we move the fault handling to
> +  * higher level function and that will serialize against ptl.
> +  * We need to flush existing hash pte entries here even though,
> +  * the translation is still valid, because we will withdraw
> +  * pgtable_t after this.
> +  */
> + pmd_hugepage_update(vma->vm_mm, address, pmdp, _PAGE_USER, 0);
> +}
> +
> +
>  /*
>   * set a new huge pmd. We should not be called for updating
>   * an existing pmd entry. That should go via pmd_hugepage_update.
> @@ -663,10 +687,19 @@ void set_pmd_at(struct mm_struct *mm, unsigned long 
> addr,
>   return set_pte_at(mm, addr, pmdp_ptep(pmdp), pmd_pte(pmd));
>  }

Re: [PATCH] arm64: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

[Andrey Ryabinin]

On 02/06/2016 02:50 AM, Yang Shi wrote:
> To enable UBSAN on arm64, ARCH_HAS_UBSAN_SANITIZE_ALL need to be selected.
> 
> Basic kernel bootup test is passed on arm64 with CONFIG_UBSAN_SANITIZE_ALL
> enabled.
> 
> Signed-off-by: Yang Shi 
> ---


Acked-by: Andrey Ryabinin 

Re: [PATCH -v2] x86: Add an archinfo dumper module

[Boris Petkov]

"H. Peter Anvin"  wrote:
>Is there a reason why all this parsing has to be done in kernel space?

Not at all. What do you have in mind?


-- 
Sent from a small device: formatting sux and brevity is inevitable. 

Re: [PATCH] ubsan: cosmetic fix to Kconfig text

[Andrey Ryabinin]

On 02/06/2016 03:05 AM, Yang Shi wrote:
> When enabling UBSAN_SANITIZE_ALL, the kernel image size gets increased
> significantly (~3x). So, it sounds better to have some note in Kconfig.
> 
> And, fixed a typo.
> 
> Signed-off-by: Yang Shi 
> ---

Acked-by: Andrey Ryabinin 

>  lib/Kconfig.ubsan | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index 49518fb..e07c1ba 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -18,6 +18,8 @@ config UBSAN_SANITIZE_ALL
> This option activates instrumentation for the entire kernel.
> If you don't enable this option, you have to explicitly specify
> UBSAN_SANITIZE := y for the files/directories you want to check for 
> UB.
> +   Enabling this option will get kernel image size increased
> +   significantly.
>  
>  config UBSAN_ALIGNMENT
>   bool "Enable checking of pointers alignment"
> @@ -25,5 +27,5 @@ config UBSAN_ALIGNMENT
>   default y if !HAVE_EFFICIENT_UNALIGNED_ACCESS
>   help
> This option enables detection of unaligned memory accesses.
> -   Enabling this option on architectures that support unalligned
> +   Enabling this option on architectures that support unaligned
> accesses may produce a lot of false positives.
> 

Re: GPIO-driven RTS on TI hardware with 8250_omap driver

[Ильяс Гасанов]

Hello,

2016-01-16 2:55 GMT+03:00 Peter Hurley :
> Please use the helpers in serial_mctrl_gpio.c if you try this.
>
> And please build on top of Matwey's patches, as those will likely be
> the rs485 implementation for the 8250_omap driver soon.

As far as I understand, since em485 callbacks are invoked by timers,
the code is to be executed in atomic context. However certain GPIO
controllers (particularly the OMAP-based one which is used on our
AM335x) require the use of the gpio_*_cansleep() functions, and cannot
work with the atomic-friendly non-cansleep ones. Do the aforementioned
helpers in serial_mctrl_gpio.c address this issue?

Regards,
Ilyas G.

Darlehen anbieten

[UK CREDIT LTD LOAN]

Schönen Tag,
 
   Wir UK CREDIT LTD Darlehen Finanzunternehmen mit Sitz in 
Großbritannien durch die Operationen und eine gute Kundenbasis auf der 
ganzen Welt. Wir bieten Darlehen zu niedrigen Zinssatz von 3%. Liebe 
Leser werden darauf hingewiesen, dass dieses Angebot ist ernst gesinnten 
Individuum, Unternehmen und Konzerne. Holen Sie sich ein Darlehen Ihre 
finanziellen Probleme zu lösen wie Rechnungen zahlen sich aus, ein neues 
Geschäftsfeld, die Wiederherstellung Antiquitätengeschäft. Interessierte 
Einzelpersonen, Firmen und Unternehmen kontaktieren Sie uns bitte über 
diese E-Mail: ukcreditloa...@gmail.com


Sie nicht diese Gelegenheit können Sie vorbei. Holen Sie sich ein 
Darlehen Ihre finanziellen Probleme zu lösen. Wenn Sie in ein Darlehen 
interessiert

Ausfüllen und sofort das Darlehen Antragsformular zurückschicken.

Die Namen sind: ...
Adresse: ...
Telefon: ...
Darlehensbetrag erforderlich: ...
Dauer: ...
Beruf: ...
Monatliches Einkommen Level: ...
Nicht ...
Geburtsdatum: 
Status: ..
Land: .
Postleitzahl: .
Zweck: ..
KONTAKTIERE UNS.

Danke für ihr Verständnis

Treffen Sie Ihre finanziellen Bedürfnisse ist unsere Ziele

James Williams.

[PATCH] mtd: denali: fix property name for Denali DT binding

[Masahiro Yamada]

The property "dma-mask" is used in the Examples section of this
document as well as drivers/mtd/nand/denali_dt.c, so I assume the
correct property name is "dma-mask", not "dm-mask"

Signed-off-by: Masahiro Yamada 
---

 Documentation/devicetree/bindings/mtd/denali-nand.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt 
b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index b04d03a..785b825 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -5,7 +5,7 @@ Required properties:
   - reg : should contain registers location and length for data and reg.
   - reg-names: Should contain the reg names "nand_data" and "denali_reg"
   - interrupts : The interrupt number.
-  - dm-mask : DMA bit mask
+  - dma-mask : DMA bit mask
 
 The device tree may optionally contain sub-nodes describing partitions of the
 address space. See partition.txt for more detail.
-- 
1.9.1

Re: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Hannes Reinecke]

On 02/08/2016 12:07 AM, James Bottomley wrote:
> On Sun, 2016-02-07 at 15:28 -0700, Jens Axboe wrote:
>> On 02/07/2016 09:04 AM, James Bottomley wrote:
>>> On Sun, 2016-02-07 at 10:22 +0100, Christoph Hellwig wrote:
 Keith said it should be on by default, and I promised him to
 change
 it once we run into problems, which I guess this counts as.

 But just curious:  what distro are you using?  Upstream systemd
 explicitly rejected using scsi_id for NVMe here:

https://github.com/systemd/systemd/issues/1453

 and all my test systems don't do this either.
>>>
>>> This was SUSE (in my case, openSUSE Leap).  I just checked the
>>> source
>>> package; they patch the by-id rules back in for NVME:
>>>
>>> # PATCH-FIX-SUSE 1101-rules-persistent-device-names-for-NVMe
>>> -devices.patch (bsc#944132)
>>> Patch1101:  1101-rules-persistent-device-names-for-NVMe
>>> -devices.patch
>>>
>>> The bugzilla is giving access denied for bug id 944132, so it's
>>> likely
>>> some proprietary vendor problem.  The patch has no preamble, so
>>> it's
>>> hard to tell what they were thinking.
>>
>> I run root-on-nvme on my laptop, and I haven't observed any problems.
> 
> Me too apparently.  It looks like this problem may be SUSE specific
> unless another distro has enabled this.  I can see why they would: you
> do need persistent names for devices, even NVMe ones.
> 
>> Generally I hate for options to default y unless absolutely 
>> necessary, it's a sure fire way to feature creep your kernel without 
>> noticing. I don't think getting all hot about this issue is fair, if 
>> the only known case is suse.
> 
> Well, OK, I'm annoyed because it was a systemd system which means
> debugging boot failures are excruciatingly difficult so it took me a
> week and a half to find out what the problem was.  Perhaps I was a bit
> rash to label this as an easily foreseen problem.
> 
> I opened a bug against SUSE to tell them to turn it on:
> 
> https://bugzilla.opensuse.org/show_bug.cgi?id=965497
> 
> The second problem is that there's currently no way to transition to
> using the serial attribute the way the udev 60-persistent-storage.rules
> are written, so if distros have some by-id hack, it will have to be
> maintained for a while.  I annotated the already closed bug on this in
> systemd with the rules that work for me.
> 
Why, but you can.
That's precisely what I did with the transition to sg_inq; I've
added a new set of rules (55-sg_inq.rules and 59-sg-symlinks.rules)
which will override the values from 60-persistent-storage.rules.

Do we have defined sysfs attributes for NVMe devices nowadays?
If so I'd be willing to create/send some sysfs rules for them.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [RFC 2/4] lightnvm: add write buffering for rrpc

[Javier González]

Hi Matias,

Thanks for the quick reply and revision. I’ll add the changes and merge
the other patches for the next version. I have a couple of remarks
inline.


> On 05 Feb 2016, at 15:52, Matias Bjørling  wrote:
> 
> On 02/04/2016 02:08 PM, Javier González wrote:
>> Flash controllers typically define flash pages as a collection of flash
>> sectors of typically 4K. Moreover, flash controllers might program flash
>> pages across several planes. This defines the write granurality at which
>> flash can be programmed. This is different for each flash controller. In
>> rrpc, the assumption has been that flash pages are 4K, thus writes could
>> be sent out to the media as they were received.
>> 
>> This patch adds a per-block write buffer to rrpc. Writes are flushed to
>> the media in chuncks of the minimum granurality allowed by the
>> controller, though the strategy can be changed to, for example, only
>> flush at the maximum supported (64 pages in nvme). Apart from enabling
>> the use of rrpc in real hardware, this buffering strategy will be used
>> for recovery; if a block becomes bad, a new block can be allocated to
>> persist valid data.
> 
> Great work. The code is nearly 2x'ed in size. Can you add a detailed
> explanation on the inner workings of the write buffering to help new
> users to understand its logic?

Thanks. Sure, I’ll add a description of the internals in the next version.

> 
>> Signed-off-by: Javier González 
>> ---
>> drivers/lightnvm/rrpc.c  | 851 
>> ++-
>> drivers/lightnvm/rrpc.h  |  82 -
>> include/linux/lightnvm.h |   6 +-
>> 3 files changed, 771 insertions(+), 168 deletions(-)
>> 
>> diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
>> index 8187bf3..e9fb19d 100644
>> --- a/drivers/lightnvm/rrpc.c
>> +++ b/drivers/lightnvm/rrpc.c
>> @@ -16,11 +16,12 @@
>> 
>> #include "rrpc.h"
>> 
>> -static struct kmem_cache *rrpc_gcb_cache, *rrpc_rq_cache;
>> +static struct kmem_cache *rrpc_gcb_cache, *rrpc_rq_cache, *rrpc_rrq_cache,
>> +*rrpc_buf_rrq_cache, *rrpc_wb_cache, *rrpc_block_cache;
>> static DECLARE_RWSEM(rrpc_lock);
>> 
>> static int rrpc_submit_io(struct rrpc *rrpc, struct bio *bio,
>> -struct nvm_rq *rqd, unsigned long flags);
>> +struct rrpc_rq *rqd, unsigned long flags);
>> 
>> #define rrpc_for_each_lun(rrpc, rlun, i) \
>>  for ((i) = 0, rlun = &(rrpc)->luns[0]; \
>> @@ -62,53 +63,59 @@ static void rrpc_invalidate_range(struct rrpc *rrpc, 
>> sector_t slba,
>>  spin_unlock(&rrpc->rev_lock);
>> }
>> 
>> -static struct nvm_rq *rrpc_inflight_laddr_acquire(struct rrpc *rrpc,
>> +static void rrpc_release_and_free_rrqd(struct kref *ref)
>> +{
>> +struct rrpc_rq *rrqd = container_of(ref, struct rrpc_rq, refs);
>> +struct rrpc *rrpc = rrqd->addr->rblk->rlun->rrpc;
> 
> Wow.. Happy that we got to rrpc :)

Yes, I know… I'll find another way :)

> 
>> +
>> +rrpc_unlock_rq(rrpc, rrqd);
>> +mempool_free(rrqd, rrpc->rrq_pool);
>> +}
>> +
>> +static struct rrpc_rq *rrpc_inflight_laddr_acquire(struct rrpc *rrpc,
>>  sector_t laddr, unsigned int pages)
>> {
>> -struct nvm_rq *rqd;
>> +struct rrpc_rq *rrqd;
>>  struct rrpc_inflight_rq *inf;
>> 
>> -rqd = mempool_alloc(rrpc->rq_pool, GFP_ATOMIC);
>> -if (!rqd)
>> +rrqd = mempool_alloc(rrpc->rrq_pool, GFP_ATOMIC);
>> +if (!rrqd)
>>  return ERR_PTR(-ENOMEM);
>> +kref_init(&rrqd->refs);
>> 
>> -inf = rrpc_get_inflight_rq(rqd);
>> +inf = rrpc_get_inflight_rq(rrqd);
>>  if (rrpc_lock_laddr(rrpc, laddr, pages, inf)) {
>> -mempool_free(rqd, rrpc->rq_pool);
>> +mempool_free(rrqd, rrpc->rrq_pool);
>>  return NULL;
>>  }
>> 
>> -return rqd;
>> +return rrqd;
>> }
>> 
>> -static void rrpc_inflight_laddr_release(struct rrpc *rrpc, struct nvm_rq 
>> *rqd)
>> +static void rrpc_inflight_laddr_release(struct rrpc *rrpc, struct rrpc_rq 
>> *rrqd)
>> {
>> -struct rrpc_inflight_rq *inf = rrpc_get_inflight_rq(rqd);
>> -
>> -rrpc_unlock_laddr(rrpc, inf);
>> -
>> -mempool_free(rqd, rrpc->rq_pool);
>> +kref_put(&rrqd->refs, rrpc_release_and_free_rrqd);
>> }
>> 
>> static void rrpc_discard(struct rrpc *rrpc, struct bio *bio)
>> {
>>  sector_t slba = bio->bi_iter.bi_sector / NR_PHY_IN_LOG;
>>  sector_t len = bio->bi_iter.bi_size / RRPC_EXPOSED_PAGE_SIZE;
>> -struct nvm_rq *rqd;
>> +struct rrpc_rq *rrqd;
>> 
>>  do {
>> -rqd = rrpc_inflight_laddr_acquire(rrpc, slba, len);
>> +rrqd = rrpc_inflight_laddr_acquire(rrpc, slba, len);
>>  schedule();
>> -} while (!rqd);
>> +} while (!rrqd);
>> 
>> -if (IS_ERR(rqd)) {
>> +if (IS_ERR(rrqd)) {
>>  pr_err("rrpc: unable to acquire inflight IO\n");
>>  bio_io_error(bio);
>>  return;
>>  }
>> 
>>  rrpc_invali

Re: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Hannes Reinecke]

On 02/07/2016 05:04 PM, James Bottomley wrote:
> On Sun, 2016-02-07 at 10:22 +0100, Christoph Hellwig wrote:
>> Keith said it should be on by default, and I promised him to change
>> it once we run into problems, which I guess this counts as.
>>
>> But just curious:  what distro are you using?  Upstream systemd
>> explicitly rejected using scsi_id for NVMe here:
>>
>>  https://github.com/systemd/systemd/issues/1453
>>
>> and all my test systems don't do this either.
> 
> This was SUSE (in my case, openSUSE Leap).  I just checked the source
> package; they patch the by-id rules back in for NVME:
> 
> # PATCH-FIX-SUSE 1101-rules-persistent-device-names-for-NVMe-devices.patch 
> (bsc#944132)
> Patch1101:  1101-rules-persistent-device-names-for-NVMe-devices.patch
> 
> The bugzilla is giving access denied for bug id 944132, so it's likely
> some proprietary vendor problem.  The patch has no preamble, so it's
> hard to tell what they were thinking.
> 
They didn't think at all. That abovementioned bug just states 'by-id
symlinks for NVMe drives are missing'.
And they fixed it by add the respective rules (using sg_inq) to udev.

There's no mentioning of any NVMe specific sysfs attributes whatsoever.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: complete boot failure in 4.5-rc1 caused by nvme: make SG_IO support optional

[Christoph Hellwig]

On Sun, Feb 07, 2016 at 03:07:21PM -0800, James Bottomley wrote:
> > I run root-on-nvme on my laptop, and I haven't observed any problems.
> 
> Me too apparently.  It looks like this problem may be SUSE specific
> unless another distro has enabled this.  I can see why they would: you
> do need persistent names for devices, even NVMe ones.

I don't have root on nvme, just my xfstests device, but I still didn't
see the problem, neither did my various nvme development setups.

> I opened a bug against SUSE to tell them to turn it on:
> 
> https://bugzilla.opensuse.org/show_bug.cgi?id=965497
> 
> The second problem is that there's currently no way to transition to
> using the serial attribute the way the udev 60-persistent-storage.rules
> are written, so if distros have some by-id hack, it will have to be
> maintained for a while.  I annotated the already closed bug on this in
> systemd with the rules that work for me.

We now expose the NVMe serial and NGUI, out of which the evpd page is
mangled depending on the NVMe spec version that the device supports as
sysfs attributes, distros can do the same mangling if they want to
support their old ids.

[PATCH] scatterlist: fix a typo in comment block of sg_miter_stop()

[Masahiro Yamada]

Fix the doubled "started" and tidy up the following sentences.

Signed-off-by: Masahiro Yamada 
---

 lib/scatterlist.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index bafa993..004fc70 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -598,9 +598,9 @@ EXPORT_SYMBOL(sg_miter_next);
  *
  * Description:
  *   Stops mapping iterator @miter.  @miter should have been started
- *   started using sg_miter_start().  A stopped iteration can be
- *   resumed by calling sg_miter_next() on it.  This is useful when
- *   resources (kmap) need to be released during iteration.
+ *   using sg_miter_start().  A stopped iteration can be resumed by
+ *   calling sg_miter_next() on it.  This is useful when resources (kmap)
+ *   need to be released during iteration.
  *
  * Context:
  *   Preemption disabled if the SG_MITER_ATOMIC is set.  Don't care
-- 
1.9.1

Re: [PATCH char-misc-next 3/8] misc: mic: MIC VOP Bus

[Greg Kroah-Hartman]

On Mon, Feb 01, 2016 at 08:23:40PM -0800, Sudeep Dutt wrote:
> The Virtio Over PCIe (VOP) bus abstracts the low level hardware
> details like interrupts and mapping remote memory so that the same VOP
> driver can work without changes with different MIC host or card
> drivers as long as the hardware bus operations are implemented. The
> VOP driver registers itself on the VOP bus. The base PCIe drivers
> implement the bus ops and register VOP devices on the bus, resulting
> in the VOP driver being probed with the VOP devices. This allows the
> VOP functionality to be shared between multiple generations of Intel
> MIC products.
> 
> Reviewed-by: Ashutosh Dixit 
> Signed-off-by: Sudeep Dutt 
> ---
>  drivers/misc/mic/Kconfig   |  17 
>  drivers/misc/mic/bus/Makefile  |   1 +
>  drivers/misc/mic/bus/vop_bus.h | 142 
>  drivers/misc/mic/bus/vop_bus.c | 204 
> +
>  4 files changed, 364 insertions(+)
>  create mode 100644 drivers/misc/mic/bus/vop_bus.h
>  create mode 100644 drivers/misc/mic/bus/vop_bus.c
> 
> diff --git a/drivers/misc/mic/Kconfig b/drivers/misc/mic/Kconfig
> index 40677df..840f7ef 100644
> --- a/drivers/misc/mic/Kconfig
> +++ b/drivers/misc/mic/Kconfig
> @@ -32,6 +32,23 @@ config SCIF_BUS
> OS and tools for MIC to use with this driver are available from
> .
>  
> +comment "VOP Bus Driver"
> +
> +config VOP_BUS
> + tristate "VOP Bus Driver"
> + depends on 64BIT && PCI && X86 && X86_DEV_DMA_OPS
> + help
> +   This option is selected by any driver which registers a
> +   device or driver on the VOP Bus, such as CONFIG_INTEL_MIC_HOST
> +   and CONFIG_INTEL_MIC_CARD.
> +
> +   If you are building a host/card kernel with an Intel MIC device
> +   then say M (recommended) or Y, else say N. If unsure say N.
> +
> +   More information about the Intel MIC family as well as the Linux
> +   OS and tools for MIC to use with this driver are available from
> +   .
> +
>  comment "Intel MIC Host Driver"
>  
>  config INTEL_MIC_HOST
> diff --git a/drivers/misc/mic/bus/Makefile b/drivers/misc/mic/bus/Makefile
> index 761842b..8758a7d 100644
> --- a/drivers/misc/mic/bus/Makefile
> +++ b/drivers/misc/mic/bus/Makefile
> @@ -5,3 +5,4 @@
>  obj-$(CONFIG_INTEL_MIC_BUS) += mic_bus.o
>  obj-$(CONFIG_SCIF_BUS) += scif_bus.o
>  obj-$(CONFIG_MIC_COSM) += cosm_bus.o
> +obj-$(CONFIG_VOP_BUS) += vop_bus.o
> diff --git a/drivers/misc/mic/bus/vop_bus.h b/drivers/misc/mic/bus/vop_bus.h
> new file mode 100644
> index 000..97fa5d6
> --- /dev/null
> +++ b/drivers/misc/mic/bus/vop_bus.h
> @@ -0,0 +1,142 @@
> +/*
> + * Intel MIC Platform Software Stack (MPSS)
> + *
> + * Copyright(c) 2016 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License, version 2, as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * The full GNU General Public License is included in this distribution in
> + * the file called "COPYING".
> + *
> + * Intel Virtio over PCIe Bus driver.
> + */
> +#ifndef _VOP_BUS_H_
> +#define _VOP_BUS_H_
> +/*
> + * Everything a vop driver needs to work with any particular vop
> + * implementation.
> + */
> +#include 
> +#include 
> +
> +#include "../common/mic_dev.h"
> +
> +struct vop_device_id {
> + u32 device;
> + u32 vendor;
> +};
> +
> +#define VOP_DEV_TRNSP 1
> +#define VOP_DEV_ANY_ID 0x
> +/*
> + * Size of the internal buffer used during DMA's as an intermediate buffer
> + * for copy to/from user. Must be an integral number of pages.
> + */
> +#define VOP_INT_DMA_BUF_SIZE PAGE_ALIGN(64 * 1024ULL)
> +
> +/**
> + * vop_device - representation of a device using vop
> + * @priv: private pointer for the driver's use.
> + * @hw_ops: the hardware ops supported by this device.
> + * @id: the device type identification (used to match it with a driver).
> + * @dev: underlying device.
> + * @dnode - The destination node which this device will communicate with.
> + * @aper: Aperture memory window
> + * @dma_ch - DMA channel
> + * @index: unique position on the vop bus
> + */
> +struct vop_device {
> + void *priv;

You don't need this pointer, use the one in struct device instead.

Other than that, looks good, nice job with this bus.

greg k-h

Re: [PATCH char-misc-next 1/8] misc: mic: Remove MIC X100 host virtio functionality

[Greg Kroah-Hartman]

On Mon, Feb 01, 2016 at 08:23:38PM -0800, Sudeep Dutt wrote:
> This patch deletes the virtio functionality from the MIC X100 host
> driver. A subsequent patch will re-enable this functionality by
> consolidating the hardware independent logic in a new Virtio over PCIe
> (VOP) driver.
> 
> Reviewed-by: Ashutosh Dixit 
> Signed-off-by: Sudeep Dutt 

This series does apply due to other changes in this subsystem in my
tree.  Can you refresh it against the char-misc-testing branch of my
char-misc.git tree and resend?

thanks,

greg k-h

Re: [PATCH v7 0/4] generic TEE subsystem

[Greg Kroah-Hartman]

On Mon, Feb 01, 2016 at 10:15:36AM +0100, Jens Wiklander wrote:
> Hi,
> 
> This patch set introduces a generic TEE subsystem. The TEE subsystem will
> contain drivers for various TEE implementations. A TEE (Trusted Execution
> Environment) is a trusted OS running in some secure environment, for
> example, TrustZone on ARM CPUs, or a separate secure co-processor etc.
> 
> Regarding use cases, TrustZone has traditionally been used for
> offloading secure tasks to the secure world. Examples include: 
> - Secure key handling where the OS may or may not have direct access to key
>   material.
> - E-commerce and payment technologies. Credentials, credit card numbers etc
>   could be stored in a more secure environment.
> - Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
>   etc.
> - Secure boot to ensure that loaded binaries haven’t been tampered with.
>   It’s not strictly needed for secure boot, but you could enhance security
>   by leveraging a TEE during boot.
> - Digital Rights Management (DRM), the studios provides content with
>   different resolution depending on the security of the device. Higher
>   security means higher resolution.
> 
> A TEE could also be used in existing and new technologies. For example IMA
> (Integrity Measurement Architecture) which has been in the kernel for quite
> a while. Today you can enhance security by using a TPM-chip to sign the IMA
> measurement list. This is something that you also could do by leveraging a
> TEE.
> 
> Another example could be in 2-factor authentication which is becoming
> increasingly more important. FIDO (https://fidoalliance.org) for example
> are using public key cryptography in their 2-factor authentication standard
> (U2F). With FIDO, a private and public key pair will be generated for every
> site you visit and the private key should never leave the local device.
> This is an example where you could use secure storage in a TEE for the
> private key.
> 
> Today you will find a quite a few different out of tree implementations of
> TEE drivers which tends to fragment the TEE ecosystem and development. We
> think it would be a good idea to have a generic TEE driver integrated in
> the kernel which would serve as a base for several different TEE solutions,
> no matter if they are on-chip like TrustZone or if they are on a separate
> crypto co-processor.
> 
> To develop this TEE subsystem we have been using the open source TEE called
> OP-TEE (https://github.com/OP-TEE/optee_os) and therefore this would be the
> first TEE solution supported by this new subsystem. OP-TEE is a
> GlobalPlatform compliant TEE, however this TEE subsystem is not limited to
> only GlobalPlatform TEEs, instead we have tried to design it so that it
> should work with other TEE solutions also.
> 
> "tee: generic TEE subsystem" brings in the generic TEE subsystem which
> helps when writing a driver for a specific TEE, for example, OP-TEE.
> 
> "tee: add OP-TEE driver" is an OP-TEE driver which uses the subsystem to do
> its work.
> 
> This patch set has been prepared in cooperation with Javier González who
> proposed "Generic TrustZone Driver in Linux Kernel" patches 28 Nov 2014,
> https://lwn.net/Articles/623380/ . We've since then changed the scope to
> TEE instead of TrustZone.
> 
> We have discussed the design on tee-...@lists.linaro.org (archive at
> https://lists.linaro.org/pipermail/tee-dev/) with people from other
> companies, including Valentin Manea ,
> Emmanuel MICHEL ,
> Jean-michel DELORME ,
> and Joakim Bech . Our main concern has been to
> agree on something that is generic enough to support many different
> TEEs while still keeping the interface together.
> 
> v7:
> * Rebased on v4.5-rc2
> * Moved the ARM SMC Calling Convention support into a separate patch
>   set, which is now merged

Given this breaks the build on x86-64, I can't take this :(

Please fix up and do a basic bit of build testing...

[PATCH 1/2] Staging:iio:Prefer using BIT macro

[Bhumika Goyal]

This patch replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
 @@ int g; @@
-(1 << g)
+BIT(g)

Signed-off-by: Bhumika Goyal 
---
 drivers/staging/iio/adc/ad7816.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
index 2226051..f631012 100644
--- a/drivers/staging/iio/adc/ad7816.c
+++ b/drivers/staging/iio/adc/ad7816.c
@@ -222,7 +222,7 @@ static ssize_t ad7816_show_value(struct device *dev,
value = (s8)((data >> AD7816_TEMP_FLOAT_OFFSET) - 103);
data &= AD7816_TEMP_FLOAT_MASK;
if (value < 0)
-   data = (1 << AD7816_TEMP_FLOAT_OFFSET) - data;
+   data = BIT(AD7816_TEMP_FLOAT_OFFSET) - data;
return sprintf(buf, "%d.%.2d\n", value, data * 25);
}
return sprintf(buf, "%u\n", data);
-- 
1.9.1

[PATCH 2/2] Staging: iio: adc: Prefer using the BIT macro

[Bhumika Goyal]

This patch replaces bit shifting on 1 with the BIT(x) macro.

This was done with coccinelle:

@@ int g; @@

-(1 << g)
+BIT(g)

Signed-off-by: Bhumika Goyal 
---
 drivers/staging/iio/adc/ad7280a.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7280a.c 
b/drivers/staging/iio/adc/ad7280a.c
index 0c73bce..ccf3157 100644
--- a/drivers/staging/iio/adc/ad7280a.c
+++ b/drivers/staging/iio/adc/ad7280a.c
@@ -117,7 +117,7 @@
  */
 #define POLYNOM0x2F
 #define POLYNOM_ORDER  8
-#define HIGHBIT(1 << (POLYNOM_ORDER - 1))
+#define HIGHBITBIT((POLYNOM_ORDER - 1))
 
 struct ad7280_state {
struct spi_device   *spi;
@@ -388,7 +388,7 @@ static ssize_t ad7280_show_balance_sw(struct device *dev,
 
return sprintf(buf, "%d\n",
   !!(st->cb_mask[this_attr->address >> 8] &
-  (1 << ((this_attr->address & 0xFF) + 2;
+  BIT(((this_attr->address & 0xFF) + 2;
 }
 
 static ssize_t ad7280_store_balance_sw(struct device *dev,
-- 
1.9.1

[PATCH 0/2] Staging:iio:adc:Prefer using BIT macro

[Bhumika Goyal]

This patchset replaces bit shifting on 1 with the BIT(x) macro.
This was done with coccinelle:
@@ int g; @@ 
-(1 << g) 
+BIT(g)

Bhumika Goyal (2):
  Staging:iio:Prefer using BIT macro
  Staging: iio: adc: Prefer using the BIT macro

 drivers/staging/iio/adc/ad7280a.c | 4 ++--
 drivers/staging/iio/adc/ad7816.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH 2/2] mm: Some arch may want to use HPAGE_PMD related values as variables

[Aneesh Kumar K.V]

With next generation power processor, we are having a new mmu model
[1] that require us to maintain a different linux page table format.

Inorder to support both current and future ppc64 systems with a single
kernel we need to make sure kernel can select between different page
table format at runtime. With the new MMU (radix MMU) added, we will
have two different pmd hugepage size 16MB for hash model and 2MB for
Radix model. Hence make HPAGE_PMD related values as a variable.

[1] http://ibm.biz/power-isa3 (Needs registration).

Signed-off-by: Aneesh Kumar K.V 
---
 arch/arm/include/asm/pgtable-3level.h | 8 
 arch/arm64/include/asm/pgtable.h  | 7 +++
 arch/mips/include/asm/pgtable.h   | 8 
 arch/powerpc/mm/pgtable_64.c  | 7 +++
 arch/s390/include/asm/pgtable.h   | 8 
 arch/sparc/include/asm/pgtable_64.h   | 7 +++
 arch/tile/include/asm/pgtable.h   | 9 +
 arch/x86/include/asm/pgtable.h| 8 
 include/linux/huge_mm.h   | 3 ---
 mm/huge_memory.c  | 8 +---
 10 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/pgtable-3level.h 
b/arch/arm/include/asm/pgtable-3level.h
index dc46398bc3a5..4b934de4d088 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -281,6 +281,14 @@ static inline void set_pmd_at(struct mm_struct *mm, 
unsigned long addr,
flush_pmd_entry(pmdp);
 }
 
+#if HPAGE_PMD_ORDER >= MAX_ORDER
+#error "hugepages can't be allocated by the buddy allocator"
+#endif
+
+#if HPAGE_PMD_ORDER < 2
+#error "We need more than 2 pages to do deferred thp split"
+#endif
+
 static inline int has_transparent_hugepage(void)
 {
return 1;
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index bf464de33f52..6bc4605d0d58 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -378,6 +378,13 @@ static inline pgprot_t mk_sect_prot(pgprot_t prot)
 
 #define set_pmd_at(mm, addr, pmdp, pmd)set_pte_at(mm, addr, (pte_t 
*)pmdp, pmd_pte(pmd))
 
+#if HPAGE_PMD_ORDER >= MAX_ORDER
+#error "hugepages can't be allocated by the buddy allocator"
+#endif
+
+#if HPAGE_PMD_ORDER < 2
+#error "We need more than 2 pages to do deferred thp split"
+#endif
 static inline int has_transparent_hugepage(void)
 {
return 1;
diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index 9a4fe0133ff1..005839fd438d 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -468,6 +468,14 @@ static inline int io_remap_pfn_range(struct vm_area_struct 
*vma,
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 
+#if HPAGE_PMD_ORDER >= MAX_ORDER
+#error "hugepages can't be allocated by the buddy allocator"
+#endif
+
+#if HPAGE_PMD_ORDER < 2
+#error "We need more than 2 pages to do deferred thp split"
+#endif
+
 extern int has_transparent_hugepage(void);
 
 static inline int pmd_trans_huge(pmd_t pmd)
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index e8214b7f2210..8840d31a5586 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -818,6 +818,13 @@ pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
 
 int has_transparent_hugepage(void)
 {
+
+   BUILD_BUG_ON_MSG((PMD_SHIFT - PAGE_SHIFT) >= MAX_ORDER,
+   "hugepages can't be allocated by the buddy allocator");
+
+   BUILD_BUG_ON_MSG((PMD_SHIFT - PAGE_SHIFT) < 2,
+"We need more than 2 pages to do deferred thp split");
+
if (!mmu_has_feature(MMU_FTR_16M_PAGE))
return 0;
/*
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 64ead8091248..79e7ea6e272c 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1617,6 +1617,14 @@ static inline int pmd_trans_huge(pmd_t pmd)
return pmd_val(pmd) & _SEGMENT_ENTRY_LARGE;
 }
 
+#if HPAGE_PMD_ORDER >= MAX_ORDER
+#error "hugepages can't be allocated by the buddy allocator"
+#endif
+
+#if HPAGE_PMD_ORDER < 2
+#error "We need more than 2 pages to do deferred thp split"
+#endif
+
 static inline int has_transparent_hugepage(void)
 {
return MACHINE_HAS_HPAGE ? 1 : 0;
diff --git a/arch/sparc/include/asm/pgtable_64.h 
b/arch/sparc/include/asm/pgtable_64.h
index 7a38d6a576c5..1f3884687f80 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -681,6 +681,13 @@ static inline unsigned long pmd_trans_huge(pmd_t pmd)
return pte_val(pte) & _PAGE_PMD_HUGE;
 }
 
+#if HPAGE_PMD_ORDER >= MAX_ORDER
+#error "hugepages can't be allocated by the buddy allocator"
+#endif
+
+#if HPAGE_PMD_ORDER < 2
+#error "We need more than 2 pages to do deferred thp split"
+#endif
 #define has_transparent_hugepage() 1
 
 static inline pmd_t pmd_mkold(pmd_t pmd)
diff --git a/arch/tile/include/asm/pgtable.h b/arch/tile/include/asm/pgtable.h
index

[PATCH v2 2/2] ARM: descend into arch/arm/boot only once to generate boot images

[Masahiro Yamada]

Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not
generate invalid images") fixed bad images generation in the parallel
building, but it is not efficient to descend into arch/arm/boot over
and over again.  It is also clumsy to display the same log message
"Kernel: arch/arm/boot/Image is ready" a couple of times.

  $ make ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage
  [snip]
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
Building modules, stage 2.
MODPOST 279 modules
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
UIMAGE  arch/arm/boot/uImage
  Image Name:   Linux-4.5.0-rc3
  Created:  Mon Feb  8 13:22:53 2016
  Image Type:   ARM Linux Kernel Image (uncompressed)
  Data Size:6768768 Bytes = 6610.12 kB = 6.46 MB
  Load Address: 80208000
  Entry Point:  80208000
Image arch/arm/boot/uImage is ready

This commit allows arch/arm/boot/Makefile to build boot images at once
instead of generating them one by one.  Of course, it works correctly
also in parallel building.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Fix build error

 arch/arm/Makefile | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index d6d453f..be1e146 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -315,13 +315,17 @@ archprepare:
 BOOT_TARGETS   = zImage Image xipImage bootpImage uImage
 INSTALL_TARGETS= zinstall uinstall install
 
-PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS) __build_images
 
-bootpImage uImage: zImage
-zImage: Image
+$(BOOT_TARGETS): __build_images
+   @:
 
-$(BOOT_TARGETS): vmlinux
-   $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
+__build_images: vmlinux
+   $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) \
+   $(addprefix $(boot)/, \
+   $(sort $(filter $(BOOT_TARGETS),$(MAKECMDGOALS)) \
+   $(if $(filter all,$(MAKECMDGOALS)), $(KBUILD_IMAGE)) \
+   $(if $(MAKECMDGOALS),,$(KBUILD_IMAGE
 
 $(INSTALL_TARGETS):
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
-- 
1.9.1

[PATCH v2 1/2] ARM: remove bzImage target

[Masahiro Yamada]

bzImage has been just an alias for zImage for more than a decade.
It would not hurt to delete it.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 arch/arm/Makefile | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 46fb1ca..d6d453f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -312,13 +312,10 @@ boot := arch/arm/boot
 archprepare:
$(Q)$(MAKE) $(build)=arch/arm/tools include/generated/mach-types.h
 
-# Convert bzImage to zImage
-bzImage: zImage
-
 BOOT_TARGETS   = zImage Image xipImage bootpImage uImage
 INSTALL_TARGETS= zinstall uinstall install
 
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS)
 
 bootpImage uImage: zImage
 zImage: Image
-- 
1.9.1

[PATCH 1/2] mm: Make vm_get_page_prot arch specific.

[Aneesh Kumar K.V]

With next generation power processor, we are having a new mmu model
[1] that require us to maintain a different linux page table format.

Inorder to support both current and future ppc64 systems with a single
kernel we need to make sure kernel can select between different page
table format at runtime. With the new MMU (radix MMU) added, we will
have to dynamically switch between different protection map. Hence
override vm_get_page_prot instead of using arch_vm_get_page_prot. We
also drop arch_vm_get_page_prot since only powerpc used it.

[1] http://ibm.biz/power-isa3 (Needs registration).

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/book3s/64/hash.h |  3 +++
 arch/powerpc/include/asm/mman.h   |  6 --
 arch/powerpc/mm/hash_utils_64.c   | 19 +++
 include/linux/mman.h  |  4 
 mm/mmap.c |  9 ++---
 5 files changed, 28 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/hash.h 
b/arch/powerpc/include/asm/book3s/64/hash.h
index 6aae0b0b649b..c568eaa1c26d 100644
--- a/arch/powerpc/include/asm/book3s/64/hash.h
+++ b/arch/powerpc/include/asm/book3s/64/hash.h
@@ -538,6 +538,9 @@ static inline pgprot_t pgprot_writecombine(pgprot_t prot)
return pgprot_noncached_wc(prot);
 }
 
+extern pgprot_t vm_get_page_prot(unsigned long vm_flags);
+#define vm_get_page_prot vm_get_page_prot
+
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 extern void hpte_do_hugepage_flush(struct mm_struct *mm, unsigned long addr,
   pmd_t *pmdp, unsigned long old_pmd);
diff --git a/arch/powerpc/include/asm/mman.h b/arch/powerpc/include/asm/mman.h
index 8565c254151a..9f48698af024 100644
--- a/arch/powerpc/include/asm/mman.h
+++ b/arch/powerpc/include/asm/mman.h
@@ -24,12 +24,6 @@ static inline unsigned long arch_calc_vm_prot_bits(unsigned 
long prot)
 }
 #define arch_calc_vm_prot_bits(prot) arch_calc_vm_prot_bits(prot)
 
-static inline pgprot_t arch_vm_get_page_prot(unsigned long vm_flags)
-{
-   return (vm_flags & VM_SAO) ? __pgprot(_PAGE_SAO) : __pgprot(0);
-}
-#define arch_vm_get_page_prot(vm_flags) arch_vm_get_page_prot(vm_flags)
-
 static inline int arch_validate_prot(unsigned long prot)
 {
if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_SAO))
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index ba59d5977f34..3199bbc654c5 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1564,3 +1564,22 @@ void setup_initial_memory_limit(phys_addr_t 
first_memblock_base,
/* Finally limit subsequent allocations */
memblock_set_current_limit(ppc64_rma_size);
 }
+
+static pgprot_t hash_protection_map[16] = {
+   __P000, __P001, __P010, __P011, __P100,
+   __P101, __P110, __P111, __S000, __S001,
+   __S010, __S011, __S100, __S101, __S110, __S111
+};
+
+pgprot_t vm_get_page_prot(unsigned long vm_flags)
+{
+   pgprot_t prot_soa = __pgprot(0);
+
+   if (vm_flags & VM_SAO)
+   prot_soa = __pgprot(_PAGE_SAO);
+
+   return __pgprot(pgprot_val(hash_protection_map[vm_flags &
+   (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
+   pgprot_val(prot_soa));
+}
+EXPORT_SYMBOL(vm_get_page_prot);
diff --git a/include/linux/mman.h b/include/linux/mman.h
index 16373c8f5f57..d44abea464e2 100644
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -38,10 +38,6 @@ static inline void vm_unacct_memory(long pages)
 #define arch_calc_vm_prot_bits(prot) 0
 #endif
 
-#ifndef arch_vm_get_page_prot
-#define arch_vm_get_page_prot(vm_flags) __pgprot(0)
-#endif
-
 #ifndef arch_validate_prot
 /*
  * This is called from mprotect().  PROT_GROWSDOWN and PROT_GROWSUP have
diff --git a/mm/mmap.c b/mm/mmap.c
index cfc0cdca421e..aa2e901029d0 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -92,6 +92,10 @@ static void unmap_region(struct mm_struct *mm,
  * x: (no) no  x: (no) yes x: (no) yes x: (yes) yes
  *
  */
+/*
+ * Give arch an option to override the below in dynamic matter
+ */
+#ifndef vm_get_page_prot
 pgprot_t protection_map[16] = {
__P000, __P001, __P010, __P011, __P100, __P101, __P110, __P111,
__S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111
@@ -99,11 +103,10 @@ pgprot_t protection_map[16] = {
 
 pgprot_t vm_get_page_prot(unsigned long vm_flags)
 {
-   return __pgprot(pgprot_val(protection_map[vm_flags &
-   (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
-   pgprot_val(arch_vm_get_page_prot(vm_flags)));
+   return protection_map[vm_flags & (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)];
 }
 EXPORT_SYMBOL(vm_get_page_prot);
+#endif
 
 static pgprot_t vm_pgprot_modify(pgprot_t oldprot, unsigned long vm_flags)
 {
-- 
2.5.0

[PATCHv2] staging: dgnc: convert to wait_event_interruptible_timeout

[Gujulan Elango, Hari Prasath (H.)]

From: Hari Prasath Gujulan Elango 

This patch makes use of wait_event_interruptible_timeout to achieve
timeout functionality.This is a TODO mentiond in the comment which is also
removed.It also aligns with what the function is supposed to do as in the
comments.

Signed-off-by: Hari Prasath Gujulan Elango 
---
v2: Patch introduced checkpatch warning on the 80 character
limit & it was pointed out by Greg.Hence resubmitting
---
 drivers/staging/dgnc/dgnc_neo.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 39c76e7..ee3155b 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -1306,10 +1306,10 @@ static int neo_drain(struct tty_struct *tty, uint 
seconds)
/*
 * Go to sleep waiting for the tty layer to wake me back up when
 * the empty flag goes away.
-*
-* NOTE: TODO: Do something with time passed in.
 */
-   rc = wait_event_interruptible(un->un_flags_wait, ((un->un_flags & 
UN_EMPTY) == 0));
+   rc = wait_event_interruptible_timeout(un->un_flags_wait,
+ ((un->un_flags & UN_EMPTY) == 0),
+ msecs_to_jiffies(seconds * 1000));
 
/* If ret is non-zero, user ctrl-c'ed us */
return rc;
-- 
1.9.1

Re: [RFC PATCH 3/3] debugfs: make __debugfs_remove wait for dentry release

[Greg Kroah-Hartman]

On Thu, Dec 10, 2015 at 01:47:14PM +0100, Roman Pen wrote:
> __debugfs_remove does not wait for dentry release, thus dentry can still be
> alive and file operations can still be invoked after the function returns.
> 
> >From debugfs point of view this behaviour is definitely ok, but that can be
> critical for users of debugfs and lead to usage-after-free: file operations
> can be called after dentry is considered as removed.
> 
> Simple grep over the sources shows that dynamic debugfs file creation and
> removal is exactly the case, and common usage is the following:
> 
>   create_dev():
>   dev = kmalloc();
>   dev->debugfs_dentry = debugfs_create_file("my_dev", , dev, dev_fops);
> ^^^
> !! pointer is passed to file
> !! operations as private data
> 
>   remove_dev(dev):
>   debugfs_remove(dev->debugfs_dentry);
>   kfree(dev);
> ^^^
>   !! memory is freed, but fops->open/read/write
>   !! can still be called and lead to usage-after-free
> 
> Here is quick grep output of the case described above:
> 
>*** drivers/block/pktcdvd.c:
>pkt_debugfs_dev_remove[489]debugfs_remove(pd->dfs_f_info);
>pkt_debugfs_dev_remove[490]debugfs_remove(pd->dfs_d_root);
> 
>*** drivers/char/virtio_console.c:
>unplug_port[1595]  debugfs_remove(port->debugfs_file);
> 
>*** drivers/crypto/qat/qat_common/adf_cfg.c:
>adf_cfg_dev_remove[187]debugfs_remove(dev_cfg_data->debug);
> 
>*** drivers/gpu/drm/drm_debugfs.c:
>drm_debugfs_remove_files[203]  debugfs_remove(tmp->dent);
> 
>    and more and more and more ...
> 
> In my grep output each third line is exactly this case: people expect that
> debugfs_remove() is a barrier and file operations won't be invoked after it
> (same behaviour as kobject_del(),kobject_put() tuple).
> 
> So in this patch debugfs_remove() waits for completion of final dentry release
> callback.
> 
> BUT! I am not sure that nobody tries to remove the dentry from it's own file
> operation (dentry suicide).  And if so - deadlock will happen.
> 
> Probably, dentry_remove_self() should be implemented for such cases, which is
> similar to sysfs_remove_file_self().  But for now I do not want to add new
> function which can be useless in the nearest future.
> 
> Signed-off-by: Roman Pen 
> Cc: Greg Kroah-Hartman 
> Cc: linux-kernel@vger.kernel.org
> ---
>  fs/debugfs/inode.c | 26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)

Without a real user, I don't want to take this, as it's "odd".  Also
this is debugfs, you shouldn't be using this for any "real" code, it's
only for debugging.  If you want this for a real api, use configfs.

thanks,

greg k-h

Re: [RFC PATCH 1/3] debugfs: fix automount inode i_nlink references

[Greg Kroah-Hartman]

On Thu, Dec 10, 2015 at 01:47:12PM +0100, Roman Pen wrote:
> Directory inodes should start off with i_nlink == 2 (for "." entry).
> Of course the same rule should be applied to automount dentries for
> child and parent inodes as well.
> 
> Also now automount dentry does fsnotify_mkdir.
> 
> Without this patch kernel complains when sees i_nlink == 0:

How can the kernel see this?  What did you do to trigger this?

thanks,

greg k-h

Re: [PATCH 2/2] debugfs: prevent access to removed files' private data

[Greg Kroah-Hartman]

On Tue, Dec 01, 2015 at 12:26:41AM +0100, Nicolai Stange wrote:
> Upon return of debugfs_remove()/debugfs_remove_recursive(), it might
> still be attempted to access associated private file data through
> previously opened struct file objects. If that data has been freed by
> the caller of debugfs_remove*() in the meanwhile, the reading/writing
> process would either encounter a fault or, if the memory address in
> question has been reassigned again, unrelated data structures could get
> overwritten.
> 
> However, since debugfs files are seldomly removed, usually from module
> exit handlers only, the impact is very low.
> 
> Since debugfs_remove() and debugfs_remove_recursive() are already
> waiting for a SRCU grace period before returning to their callers,
> enclosing the access to private file data from ->read() and ->write()
> within a SRCU read-side critical section does the trick:
> - Introduce the debugfs_file_use_data_start() and
>   debugfs_file_use_data_finish() helpers which just enter and leave
>   a SRCU read-side critical section. The former also reports whether the
>   file is still alive, that is if d_delete() has _not_ been called on
>   the corresponding dentry.
> - Introduce the DEFINE_DEBUGFS_ATTRIBUTE() macro which is completely
>   equivalent to the DEFINE_SIMPLE_ATTRIBUTE() macro except that
>   ->read() and ->write are set to SRCU protecting wrappers around the
>   original simple_read() and simple_write() helpers.
> - Use that DEFINE_DEBUGFS_ATTRIBUTE() macro for all debugfs_create_*()
>   attribute creation variants where appropriate.
> - Manually introduce SRCU protection to the debugfs-predefined readers
>   and writers not covered by the above DEFINE_SIMPLE_ATTRIBUTE()->
>   DEFINE_DEBUGFS_ATTRIBUTE() replacement.
> 
> Finally, it should be worth to note that in the vast majority of cases
> where debugfs users are handing in a "custom" struct file_operations
> object to debugfs_create_file(), an attribute's associated data's
> lifetime is bound to the one of the containing module and thus,
> taking a reference on ->owner during file opening acts as a proxy here.
> There is no need to do a mass replace of DEFINE_SIMPLE_ATTRIBUTE() to
> DEFINE_DEBUGFS_ATTRIBUTE() outside of debugfs.
> 
> Signed-off-by: Nicolai Stange 
> ---
>  Applicable to the Linus tree.
>  The second of the two patches depends on the first one

This needs a refresh as well.

And:

> diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
> index 8ae2e1a..37222c9 100644
> --- a/fs/debugfs/inode.c
> +++ b/fs/debugfs/inode.c
> @@ -31,6 +31,7 @@
>  #define DEBUGFS_DEFAULT_MODE 0700
>  
>  DEFINE_SRCU(debugfs_srcu);
> +EXPORT_SYMBOL_GPL(debugfs_srcu);

You shouldn't need to export this, because:

>  static struct vfsmount *debugfs_mount;
>  static int debugfs_mount_count;
> diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> index f8c7494..ba1a299 100644
> --- a/include/linux/debugfs.h
> +++ b/include/linux/debugfs.h
> @@ -20,6 +20,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  struct device;
>  struct file_operations;
> @@ -128,6 +129,71 @@ ssize_t debugfs_read_file_bool(struct file *file, char 
> __user *user_buf,
>  ssize_t debugfs_write_file_bool(struct file *file, const char __user 
> *user_buf,
>   size_t count, loff_t *ppos);
>  
> +int __debugfs_file_use_data_start(struct file *file, int *srcu_idx)
> + __acquires(&debugfs_srcu);
> +
> +/**
> + * debugfs_file_use_data_start - mark the beginning of file data access
> + * @file: the file object whose data is being accessed.
> + * @srcu_idx: a pointer to some memory to store a SRCU index in.
> + *
> + * Up to a matching call to debugfs_file_use_data_finish(), any
> + * successive call into the file removing functions debugfs_remove()
> + * and debugfs_remove_recursive() will block. Since associated private
> + * file data may only get freed after a successful return of any of
> + * the removal functions, you may safely access it after a successful
> + * call to debugfs_file_use_data_start() without worrying about
> + * lifetime issues.
> + *
> + * If -%EIO is returned, the file has already been removed and thus,
> + * it is not safe to access any of its data. If, on the other hand,
> + * it is allowed to access the file data, zero is returned.
> + *
> + * Regardless of the return code, any call to
> + * debugfs_file_use_data_start() must be followed by a matching call
> + * to debugfs_file_use_data_finish().
> + */
> +static inline int debugfs_file_use_data_start(struct file *file, int 
> *srcu_idx)
> + __acquires(&debugfs_srcu)
> +{
> + return __debugfs_file_use_data_start(file, srcu_idx);
> +}
> +
> +/**
> + * debugfs_file_use_data_finish - mark the end of file data access
> + * @srcu_idx: the SRCU index "created" by a former call to
> + *debugfs_file_use_data_start().
> + *
> + * Allow any ongoing concurrent call into debugfs_remove() or
> + * debugfs_remove_recursive() blocked by a former 

Re: [PATCH 1/2] debugfs: prevent access to possibly dead file_operations at file open

[Greg Kroah-Hartman]

On Tue, Dec 01, 2015 at 12:21:31AM +0100, Nicolai Stange wrote:
> Nothing prevents a dentry found by path lookup before a return of
> __debugfs_remove() to actually get opened after that return. Now, after
> the return of __debugfs_remove(), there are no guarantees whatsoever
> regarding the memory the corresponding inode's file_operations object
> had been kept in.
> 
> Since __debugfs_remove() is seldomly invoked, usually from module exit
> handlers only, the race is hard to trigger and the impact is very low.
> 
> A discussion of the problem outlined above as well as a suggested
> solution can be found in the (sub-)thread rooted at
> 
>   http://lkml.kernel.org/g/20130401203445.ga20...@zeniv.linux.org.uk
>   ("Yet another pipe related oops.")
> 
> Basically, Greg KH suggests to introduce an intermediate fops and
> Al Viro points out that a pointer to the original ones may be stored in
> ->d_fsdata.
> 
> Follow this line of reasoning:
> - Add SRCU as a reverse dependency of DEBUG_FS.
> - Introduce a srcu_struct object for the debugfs subsystem.
> - In debugfs_create_file(), store a pointer to the original
>   file_operations object in ->d_fsdata.
> - In __debugfs_remove(), clear out that dentry->d_fsdata member again.
>   debugfs_remove() and debugfs_remove_recursive() wait for a SRCU grace
>   period before returning to their caller.
> - Introduce an intermediate file_operations object named
>   "debugfs_proxy_file_operations". It's ->open() functions checks,
>   under the protection of a SRCU read lock, whether the "original"
>   file_operations pointed to by ->d_fsdata is still valid and if so,
>   tries to acquire a reference on the owning module. On success, it sets
>   the file object's ->f_op to the original file_operations and forwards
>   the ongoing open() call to the original ->open().
> - For clarity, rename the former debugfs_file_operations to
>   debugfs_noop_file_operations -- they are in no way canonical.
> 
> The choice of SRCU over "normal" RCU is justified by the fact, that the
> former may also be used to protect ->i_private data from going away
> during the execution of a file's readers and writers which may (and do)
> sleep.
> 
> Signed-off-by: Nicolai Stange 
> ---
>  Applicable to the Linus tree.
>  The second of the two patches depends on the first one

This doesn't apply to Linus's tree anymore, due to vfs changes, can you
refresh it?

Also, one other request below:

> --- a/include/linux/debugfs.h
> +++ b/include/linux/debugfs.h
> @@ -19,6 +19,7 @@
>  #include 
>  
>  #include 
> +#include 
>  
>  struct device;
>  struct file_operations;
> @@ -44,7 +45,10 @@ extern struct dentry *arch_debugfs_dir;
>  #if defined(CONFIG_DEBUG_FS)
>  
>  /* declared over in file.c */
> -extern const struct file_operations debugfs_file_operations;
> +extern const struct file_operations debugfs_noop_file_operations;
> +extern const struct file_operations debugfs_proxy_file_operations;
> +
> +extern struct srcu_struct debugfs_srcu;
>  
>  struct dentry *debugfs_create_file(const char *name, umode_t mode,
>  struct dentry *parent, void *data,

We really need an "internal" .h file for debugfs for these things you
are adding, no need to add them so that the whole kernel can see them.

Can you create a fs/debugfs/internal.h file for these structures and
then you don't need the addition of the linux/srcu.h in this file
either.

thanks,

greg k-h

Re: [PATCH 5/5] mm: workingset: make shadow node shrinker memcg aware

[Johannes Weiner]

On Sun, Feb 07, 2016 at 08:27:35PM +0300, Vladimir Davydov wrote:
> Workingset code was recently made memcg aware, but shadow node shrinker
> is still global. As a result, one small cgroup can consume all memory
> available for shadow nodes, possibly hurting other cgroups by reclaiming
> their shadow nodes, even though reclaim distances stored in its shadow
> nodes have no effect. To avoid this, we need to make shadow node
> shrinker memcg aware.
> 
> Signed-off-by: Vladimir Davydov 

This patch is straight forward, but there is one tiny thing that bugs
me about it, and that is switching from available memory to the size
of the active list. Because the active list can shrink drastically at
runtime.

It's true that both the shrinking of the active list and subsequent
activations to regrow it will reduce the number of actionable
refaults, and so it wouldn't be unreasonable to also shrink shadow
nodes when the active list shrinks.

However, I think these are too many assumptions to encode in the
shrinker, because it is only meant to prevent a worst-case explosion
of radix tree nodes. I'd prefer it to be dumb and conservative.

Could we instead go with the current usage of the memcg? Whether
reclaim happens globally or due to the memory limit, the usage at the
time of reclaim gives a good idea of the memory is available to the
group. But it's making less assumptions about the internal composition
of the memcg's memory, and the consequences associated with that.

What do you think?

Re: drivres/hv

[Greg KH]

On Mon, Nov 30, 2015 at 01:15:32PM -0800, K. Y. Srinivasan wrote:
>  
> Greg, over the last month or more we have sent numerous Hyper-V patches and
> these are yet to be comitted (all review comments have been addressed
> for these patches). Please let me know if I should resend these patches.

All should now be applied.

[PATCH] ARM: mvebu: add missing of_node_put()

[Masahiro Yamada]

This node pointer is returned by of_find_compatible_node() in this
function.  It should be put before exitting this function.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-mvebu/platsmp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index f9597b7..46c742d 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -140,6 +140,7 @@ static void __init armada_xp_smp_prepare_cpus(unsigned int 
max_cpus)
panic("Cannot find 'marvell,bootrom' compatible node");
 
err = of_address_to_resource(node, 0, &res);
+   of_node_put(node);
if (err < 0)
panic("Cannot get 'bootrom' node address");
 
-- 
1.9.1

[PATCH V2] powerpc/mm: Fix Multi hit ERAT cause by recent THP update

[Aneesh Kumar K.V]

With ppc64 we use the deposited pgtable_t to store the hash pte slot
information. We should not withdraw the deposited pgtable_t without
marking the pmd none. This ensure that low level hash fault handling
will skip this huge pte and we will handle them at upper levels.

Recent change to pmd splitting changed the above in order to handle the
race between pmd split and exit_mmap. The race is explained below.

Consider following race:

CPU0CPU1
shrink_page_list()
  add_to_swap()
split_huge_page_to_list()
  __split_huge_pmd_locked()
pmdp_huge_clear_flush_notify()
// pmd_none() == true
exit_mmap()
  unmap_vmas()
zap_pmd_range()
  // no action on pmd since 
pmd_none() == true
pmd_populate()

As result the THP will not be freed. The leak is detected by check_mm():

BUG: Bad rss-counter state mm:880058d2e580 idx:1 val:512

The above required us to not mark pmd none during a pmd split.

The fix for ppc is to clear the huge pte of _PAGE_USER, so that low
level fault handling code skip this pte. At higher level we do take ptl
lock. That should serialze us against the pmd split. Once the lock is
acquired we do check the pmd again using pmd_same. That should always
return false for us and hence we should retry the access.

Also make sure we wait for irq disable section in other cpus to finish
before flipping a huge pte entry with a regular pmd entry. Code paths
like find_linux_pte_or_hugepte depend on irq disable to get
a stable pte_t pointer. A parallel thp split need to make sure we
don't convert a pmd pte to a regular pmd entry without waiting for the
irq disable section to finish.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/book3s/64/pgtable.h |  4 
 arch/powerpc/mm/pgtable_64.c | 35 +++-
 include/asm-generic/pgtable.h|  8 +++
 mm/huge_memory.c |  1 +
 4 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 8d1c41d28318..0415856941e0 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -281,6 +281,10 @@ extern pgtable_t pgtable_trans_huge_withdraw(struct 
mm_struct *mm, pmd_t *pmdp);
 extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp);
 
+#define __HAVE_ARCH_PMDP_HUGE_SPLITTING_FLUSH
+extern void pmdp_huge_splitting_flush(struct vm_area_struct *vma,
+ unsigned long address, pmd_t *pmdp);
+
 #define pmd_move_must_withdraw pmd_move_must_withdraw
 struct spinlock;
 static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 3124a20d0fab..e8214b7f2210 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -646,6 +646,30 @@ pgtable_t pgtable_trans_huge_withdraw(struct mm_struct 
*mm, pmd_t *pmdp)
return pgtable;
 }
 
+void pmdp_huge_splitting_flush(struct vm_area_struct *vma,
+  unsigned long address, pmd_t *pmdp)
+{
+   VM_BUG_ON(address & ~HPAGE_PMD_MASK);
+
+#ifdef CONFIG_DEBUG_VM
+   BUG_ON(REGION_ID(address) != USER_REGION_ID);
+#endif
+   /*
+* We can't mark the pmd none here, because that will cause a race
+* against exit_mmap. We need to continue mark pmd TRANS HUGE, while
+* we spilt, but at the same time we wan't rest of the ppc64 code
+* not to insert hash pte on this, because we will be modifying
+* the deposited pgtable in the caller of this function. Hence
+* clear the _PAGE_USER so that we move the fault handling to
+* higher level function and that will serialize against ptl.
+* We need to flush existing hash pte entries here even though,
+* the translation is still valid, because we will withdraw
+* pgtable_t after this.
+*/
+   pmd_hugepage_update(vma->vm_mm, address, pmdp, _PAGE_USER, 0);
+}
+
+
 /*
  * set a new huge pmd. We should not be called for updating
  * an existing pmd entry. That should go via pmd_hugepage_update.
@@ -663,10 +687,19 @@ void set_pmd_at(struct mm_struct *mm, unsigned long addr,
return set_pte_at(mm, addr, pmdp_ptep(pmdp), pmd_pte(pmd));
 }
 
+/*
+ * We use this to invalidate a pmdp entry before switching from a
+ * hugepte to regular pmd entry.
+ */
 void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
 pmd_t *pmdp)
 {
-   pmd_hugepage_update(vma->vm_mm, address, pmdp, _PAGE_PRESENT, 0);
+   pmd_hugepage_update(vma->vm_mm, address, pmdp, ~0UL, 0

Re: [PATCH 4/5] radix-tree: account radix_tree_node to memory cgroup

[Johannes Weiner]

On Sun, Feb 07, 2016 at 08:27:34PM +0300, Vladimir Davydov wrote:
> Allocation of radix_tree_node objects can be easily triggered from
> userspace, so we should account them to memory cgroup. Besides, we need
> them accounted for making shadow node shrinker per memcg (see
> mm/workingset.c).
> 
> A tricky thing about accounting radix_tree_node objects is that they are
> mostly allocated through radix_tree_preload(), so we can't just set
> SLAB_ACCOUNT for radix_tree_node_cachep - that would likely result in a
> lot of unrelated cgroups using objects from each other's caches.
> 
> One way to overcome this would be making radix tree preloads per memcg,
> but that would probably look cumbersome and overcomplicated.
> 
> Instead, we make radix_tree_node_alloc() first try to allocate from the
> cache with __GFP_ACCOUNT, no matter if the caller has preloaded or not,
> and only if it fails fall back on using per cpu preloads. This should
> make most allocations accounted.
> 
> Signed-off-by: Vladimir Davydov 

Acked-by: Johannes Weiner 

I'm not too stoked about the extra slab call. But the preload call
allocates nodes for the worst-case insertion, so you are absolutely
right that charging there would not make sense for cgroup ownership.
And I can't think of anything better to do here.

Re: [mpt3sas driver 06/10] mpt3sas: Added smp_affinity_enable module parameter.

[Suganath Prabu Subramani]

Hi Tomas,
Initially, we posted this patch with "zalloc_cpumassk_var" and Robert
has suggested to use "alloc_cpumask_var". Please check the below link.
"http://www.gossamer-threads.com/lists/linux/kernel/2068280?do=post_view_threaded#2068280";

We incorporated other review comments for freeing reply_q and
cpumask_var in this patch and sending it soon.

Thanks,
Suganath prabu S

On Thu, Feb 4, 2016 at 8:31 PM, Tomas Henzl  wrote:
> On 28.1.2016 07:37, Suganath prabu Subaramani wrote:
>> From: Suganath prabu Subramani 
>>
>> Module parameter to enable/disable configuring
>> affinity hint for msix vector.
>> SMP affinity feature can be enabled/disabled by setting
>> module parameter "smp_affinity_enable" to 1/0.
>> By default this feature is enabled. (smp_affinity_enable = 1 enabled).
>>
>> Signed-off-by: Suganath prabu Subramani 
>> 
>> Signed-off-by: Chaitra P B 
>> ---
>>  drivers/scsi/mpt3sas/mpt3sas_base.c | 34 +++---
>>  1 file changed, 23 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
>> b/drivers/scsi/mpt3sas/mpt3sas_base.c
>> index 31838d9a..a1a3b39 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
>> @@ -83,6 +83,10 @@ static int msix_disable = -1;
>>  module_param(msix_disable, int, 0);
>>  MODULE_PARM_DESC(msix_disable, " disable msix routed interrupts 
>> (default=0)");
>>
>> +static int smp_affinity_enable = 1;
>> +module_param(smp_affinity_enable, int, S_IRUGO);
>> +MODULE_PARM_DESC(smp_affinity_enable, "SMP affinity feature enable/disbale 
>> Default: enable(1)");
>> +
>>  static int max_msix_vectors = -1;
>>  module_param(max_msix_vectors, int, 0);
>>  MODULE_PARM_DESC(max_msix_vectors,
>> @@ -1812,8 +1816,10 @@ _base_free_irq(struct MPT3SAS_ADAPTER *ioc)
>>
>>   list_for_each_entry_safe(reply_q, next, &ioc->reply_queue_list, list) {
>>   list_del(&reply_q->list);
>> - irq_set_affinity_hint(reply_q->vector, NULL);
>> - free_cpumask_var(reply_q->affinity_hint);
>> + if (smp_affinity_enable) {
>> + irq_set_affinity_hint(reply_q->vector, NULL);
>> + free_cpumask_var(reply_q->affinity_hint);
>> + }
>>   synchronize_irq(reply_q->vector);
>>   free_irq(reply_q->vector, reply_q);
>>   kfree(reply_q);
>> @@ -1844,9 +1850,11 @@ _base_request_irq(struct MPT3SAS_ADAPTER *ioc, u8 
>> index, u32 vector)
>>   reply_q->msix_index = index;
>>   reply_q->vector = vector;
>>
>> - if (!alloc_cpumask_var(&reply_q->affinity_hint, GFP_KERNEL))
>> - return -ENOMEM;
>> - cpumask_clear(reply_q->affinity_hint);
>> + if (smp_affinity_enable) {
>> + if (!alloc_cpumask_var(&reply_q->affinity_hint, GFP_KERNEL))
>
> a kfree(reply_q); should go here
>
>> + return -ENOMEM;
>> + cpumask_clear(reply_q->affinity_hint);
>
> maybe zalloc_cpumask_var ?
>
>> + }
>
> if (r) {
> pr_err(MPT3SAS_FMT "unable to allocate interrupt %d!\n",
> reply_q->name, vector);
> kfree(reply_q);
> and a  free_cpumask_var (..)  here ?
> return -EBUSY;
>
>
> cheers,
> tomash
>

Re: [PATCH 3/5] mm: memcontrol: zap memcg_kmem_online helper

[Johannes Weiner]

On Sun, Feb 07, 2016 at 08:27:33PM +0300, Vladimir Davydov wrote:
> As kmem accounting is now either enabled for all cgroups or disabled
> system-wide, there's no point in having memcg_kmem_online() helper -
> instead one can use memcg_kmem_enabled() and mem_cgroup_online(), as
> shrink_slab() now does.
> 
> There are only two places left where this helper is used -
> __memcg_kmem_charge() and memcg_create_kmem_cache(). The former can only
> be called if memcg_kmem_enabled() returned true. Since the cgroup it
> operates on is online, mem_cgroup_is_root() check will be enough.
> 
> memcg_create_kmem_cache() can't use mem_cgroup_online() helper instead
> of memcg_kmem_online(), because it relies on the fact that in
> memcg_offline_kmem() memcg->kmem_state is changed before
> memcg_deactivate_kmem_caches() is called, but there we can just
> open-code the check.
> 
> Signed-off-by: Vladimir Davydov 

Nice. I like the direct check for the root memcg.

Acked-by: Johannes Weiner 

Re: [PATCH 2/5] mm: vmscan: pass root_mem_cgroup instead of NULL to memcg aware shrinker

[Johannes Weiner]

On Sun, Feb 07, 2016 at 08:27:32PM +0300, Vladimir Davydov wrote:
> It's just convenient to implement a memcg aware shrinker when you know
> that shrink_control->memcg != NULL unless memcg_kmem_enabled() returns
> false.
> 
> Signed-off-by: Vladimir Davydov 

Acked-by: Johannes Weiner 

Re: [PATCH 1/5] mm: memcontrol: enable kmem accounting for all cgroups in the legacy hierarchy

[Johannes Weiner]

On Sun, Feb 07, 2016 at 08:27:31PM +0300, Vladimir Davydov wrote:
> Currently, in the legacy hierarchy kmem accounting is off for all
> cgroups by default and must be enabled explicitly by writing something
> to memory.kmem.limit_in_bytes. Since we don't support reclaim on hitting
> kmem limit, nor do we have any plans to implement it, this is likely to
> be -1, just to enable kmem accounting and limit kernel memory
> consumption by the memory.limit_in_bytes along with user memory.
> 
> This user API was introduced when the implementation of kmem accounting
> lacked slab shrinker support and hence was useless in practice. Things
> have changed since then - slab shrinkers were made memcg aware, the
> accounting overhead seems to be negligible, and a failure to charge a
> kmem allocation should not have critical consequences, because we only
> account those kernel objects that should be safe to fail. That's why
> kmem accounting is enabled by default for all cgroups in the default
> hierarchy, which will eventually replace the legacy one.
> 
> The ability to enable kmem accounting for some cgroups while keeping it
> disabled for others is getting difficult to maintain. E.g. to make
> shadow node shrinker memcg aware (see mm/workingset.c), we need to know
> the relationship between the number of shadow nodes allocated for a
> cgroup and the size of its lru list. If kmem accounting is enabled for
> all cgroups there is no problem, but what should we do if kmem
> accounting is enabled only for half of cgroups? We've no other choice
> but use global lru stats while scanning root cgroup's shadow nodes, but
> that would be wrong if kmem accounting was enabled for all cgroups
> (which is the case if the unified hierarchy is used), in which case we
> should use lru stats of the root cgroup's lruvec.
> 
> That being said, let's enable kmem accounting for all memory cgroups by
> default. If one finds it unstable or too costly, it can always be
> disabled system-wide by passing cgroup.memory=nokmem to the kernel at
> boot time.
> 
> Signed-off-by: Vladimir Davydov 

Acked-by: Johannes Weiner 

A little bolder than I would have preferred for legacy memcg, but I
don't think we have another choice here. And you're right, accounting
costs are a far cry from what they once were. So I'm okay with this.

Re: [PATCH v11 1/1] efi: a misc char interface for user to update efi firmware

[Greg Kroah-Hartman]

On Fri, Jan 29, 2016 at 12:39:54PM +0800, Kweh, Hock Leong wrote:
> From: "Kweh, Hock Leong" 
> 
> Introducing a kernel module to expose capsule loader interface
> (misc char device file note) for users to upload capsule binaries.
> 
> Example:
> cat firmware.bin > /dev/efi_capsule_loader
> 
> This patch also export efi_capsule_supported() function symbol for
> verifying the submitted capsule header in this kernel module.
> 
> Cc: Matt Fleming 
> Signed-off-by: Kweh, Hock Leong 
> ---
>  drivers/firmware/efi/Kconfig  |9 +
>  drivers/firmware/efi/Makefile |1 +
>  drivers/firmware/efi/capsule-loader.c |  334 
> +
>  drivers/firmware/efi/capsule.c|1 +
>  4 files changed, 345 insertions(+)
>  create mode 100644 drivers/firmware/efi/capsule-loader.c

I need an ack from the efi maintainer, or at least someone else
reviewing / testing this, before I can accept it.

thanks,

greg k-h

Re: [PATCH V2 06/13] Drivers: hv: vmbus: define the new offer type for Hyper-V socket (hvsock)

[Greg KH]

On Wed, Jan 27, 2016 at 10:29:38PM -0800, K. Y. Srinivasan wrote:
> From: Dexuan Cui 
> 
> A helper function is also added.
> 
> Signed-off-by: Dexuan Cui 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  include/linux/hyperv.h |7 +++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index 4af51a3..79c4aa7 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -235,6 +235,7 @@ struct vmbus_channel_offer {
>  #define VMBUS_CHANNEL_LOOPBACK_OFFER 0x100
>  #define VMBUS_CHANNEL_PARENT_OFFER   0x200
>  #define VMBUS_CHANNEL_REQUEST_MONITORED_NOTIFICATION 0x400
> +#define VMBUS_CHANNEL_TLNPI_PROVIDER_OFFER   0x2000

In the future the BIT() macro might be good here...

Re: [PATCH] w1: w1_process() is not freezable kthread

[GregKH]

On Thu, Nov 19, 2015 at 04:49:41PM +0100, Jiri Kosina wrote:
> On Thu, 5 Nov 2015, Evgeniy Polyakov wrote:
> 
> > > I fail to see why this kthread should be freezable at all. There is no way
> > > for w1 device to generate new I/O requests that should be written out to
> > > filesystem, is it?
> > 
> > w1 doesn't generate such requests, but it was more to make this thread
> > consistent with majority of other threads in the kernel.
> 
> Most of which actually don't need freezer at all, and only contribute to 
> the overall confusion regarding what kthread freezer is actually for.
> 
> It's my long-term goal to fix this situation (and this patch is part of 
> some preparatory steps :) ).
> 
> > Ok, I'm not against it, Greg please pull this patch into your tree.
> > 
> > Acked-by: Evgeniy Polyakov 
> 
> Greg, do you plan to take this please? I don't seem to see it in 
> linux-next as of today.

I can't find this patch anywhere in my queue, can you please resend it
to me with the ack so I can apply it?

thanks,

greg k-h

Re: [PATCH v3] misc: ibmasm: Replace timeval with timespec64

[Greg KH]

On Fri, Oct 23, 2015 at 08:37:49PM +0530, Amitoj Kaur Chawla wrote:
> This patch replaces timeval with timespec64 as 32 bit 'struct timeval'
> will not give current time beyond 2038.
> 
> The patch changes the code to use ktime_get_real_ts64() which returns
> a 'struct timespec64' instead of do_gettimeofday() which returns a
> 'struct timeval'
> 
> This patch also alters the format strings in sprintf() for now.tv_sec
> and now.tv_nsec to incorporate 'long long' on 32 bit architectures and
> leading zeroes respectively.
> 
> Signed-off-by: Amitoj Kaur Chawla 
> Reviewed-by: Arnd Bergmann 
> ---
> Changes in v2:
> -change format string of now.tv_sec to '%llu'
> -change format string of now.tv_nsec to '%.08lu'
> Changes in v3:
> -Replace tv_usec with tv_nsec, error made in v2
> -Build tested
> 
>  drivers/misc/ibmasm/ibmasm.h | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/misc/ibmasm/ibmasm.h b/drivers/misc/ibmasm/ibmasm.h
> index 9b08344..82380ae 100644
> --- a/drivers/misc/ibmasm/ibmasm.h
> +++ b/drivers/misc/ibmasm/ibmasm.h
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* Driver identification */
>  #define DRIVER_NAME  "ibmasm"
> @@ -53,9 +54,10 @@ extern int ibmasm_debug;
>  
>  static inline char *get_timestamp(char *buf)
>  {
> - struct timeval now;
> - do_gettimeofday(&now);
> - sprintf(buf, "%lu.%lu", now.tv_sec, now.tv_usec);
> + struct timespec64 now;
> + ktime_get_real_ts64(&now);
> + sprintf(buf, "%llu.%.08lu", (long long)now.tv_sec, 
> + now.tv_nsec / NSEC_PER_USEC);
>   return buf;
>  }
>  

Always run your patches through checkpatch so that a maintainer doesn't
have to be grumpy and tell you to fix up the obvious checkpatch issues
in it...

thanks,

greg k-h

Re: [PATCH] Platform: goldfish: goldfish_pipe.c: Add DMA support using managed version

[Greg Kroah-Hartman]

On Sat, Feb 06, 2016 at 10:36:20AM +0530, Shraddha Barke wrote:
> setup_access_params_addr has 2 goals-
> 
> -Initialize the access_params field so that it can be used to send and read
> commands from the device in access_with_param
> -Get a bus address for the allocated memory to transfer to the device.
> 
> Replace the combination of devm_kzalloc and _pa() with dmam_alloc_coherent.
> Coherent mapping guarantees that the device and CPU are in sync.
> 
> Signed-off-by: Shraddha Barke 
> ---
>  drivers/platform/goldfish/goldfish_pipe.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)

Doesn't apply to my char-misc tree anymore due to other changes in the
driver, can you rebase and resend?

thanks,

greg k-h

[PATCH v2 0/4] iommu/arm-smmu: misc fixes for SMMUv1/SMMUv2

[Anup Patel]

The intention behind this patchset is to allow usage of IOMMU based
DMA mappings for 32bit devices. It is based on '4.5-rc3' tag of linux
mainline tree and Robin's SMMU patchset "[PATCH 0/4] Miscellaneous
ARM SMMU patches".

This patchset and its dependent patches are available in smmu_v2
branch of https://github.com/Broadcom/arm64-linux.git

All patches have been tested on Broadcom SoCs having SMMU-500.

Anup Patel (3):
  iommu/arm-smmu: Invoke DT probe from arm_smmu_of_setup()
  of: iommu: Increment DT node refcount in of_iommu_set_ops()
  iommu/arm-smmu: Add stub of_xlate() operation in SMMUv1/SMMUv2 driver

Sricharan R (1):
  iommu/arm-smmu: Init driver using IOMMU_OF_DECLARE

 drivers/iommu/arm-smmu.c | 52 
 drivers/iommu/of_iommu.c |  1 +
 2 files changed, 40 insertions(+), 13 deletions(-)

-- 
1.9.1

[PATCH v2 4/4] iommu/arm-smmu: Add stub of_xlate() operation in SMMUv1/SMMUv2 driver

[Anup Patel]

To allow use of large memory (> 4Gb) with 32bit devices we need to use
IOMMU based DMA mappings for such 32bit devices. The IOMMU dt-bindings
allows us do this by specifying 'iommus' attribute in 32bit device DT
node. Unfortunately, specifying 'iommus' attribute does not work with
current SMMUv1/SMMUv2 driver because it requires of_xlate() operation
to be implemented by the driver.

This patch adds a stub implementation of of_xlate() in SMMUv1/SMMUv2
driver to allow usage of 'iommus' attribute in DT for 32bit devices.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/iommu/arm-smmu.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 02cd67d..8e090d8 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1398,6 +1398,16 @@ static int arm_smmu_init_platform_device(struct device 
*dev,
return 0;
 }
 
+int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
+{
+   /*
+* Nothing to do here because SMMU is already aware of all
+* MMU masters and their stream IDs using mmu-master attibute
+* SMMU DT node.
+*/
+   return 0;
+}
+
 static int arm_smmu_add_device(struct device *dev)
 {
struct iommu_group *group;
@@ -1495,6 +1505,7 @@ static struct iommu_ops arm_smmu_ops = {
.unmap  = arm_smmu_unmap,
.map_sg = default_iommu_map_sg,
.iova_to_phys   = arm_smmu_iova_to_phys,
+   .of_xlate   = arm_smmu_of_xlate,
.add_device = arm_smmu_add_device,
.remove_device  = arm_smmu_remove_device,
.device_group   = arm_smmu_device_group,
-- 
1.9.1

[PATCH v2 3/4] of: iommu: Increment DT node refcount in of_iommu_set_ops()

[Anup Patel]

We are saving pointer to iommu DT node in of_iommu_set_ops()
hence we should increment DT node ref count.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Reviewed-by: Robin Murphy 
---
 drivers/iommu/of_iommu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 60ba238..5fea665 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -110,6 +110,7 @@ void of_iommu_set_ops(struct device_node *np, struct 
iommu_ops *ops)
if (WARN_ON(!iommu))
return;
 
+   of_node_get(np);
INIT_LIST_HEAD(&iommu->list);
iommu->np = np;
iommu->ops = ops;
-- 
1.9.1

[PATCH v2 2/4] iommu/arm-smmu: Invoke DT probe from arm_smmu_of_setup()

[Anup Patel]

The SMMUv1/SMMUv2 driver is initialized very early using the
IOMMU_OF_DECLARE() but the actual platform device is probed
via normal DT probing.

This patch uses of_platform_device_create() from arm_smmu_of_setup()
to ensure that SMMU platform device is probed immediately.

Signed-off-by: Anup Patel 
---
 drivers/iommu/arm-smmu.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 2c8f871..02cd67d 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1956,10 +1957,15 @@ static int __init arm_smmu_init(void)
 
 static int __init arm_smmu_of_setup(struct device_node *np)
 {
+   struct platform_device *pdev;
 
if (!init_done)
arm_smmu_init();
 
+   pdev = of_platform_device_create(np, NULL, NULL);
+   if (IS_ERR(pdev))
+   return PTR_ERR(pdev);
+
of_iommu_set_ops(np, &arm_smmu_ops);
 
return 0;
-- 
1.9.1

[PATCH v2 1/4] iommu/arm-smmu: Init driver using IOMMU_OF_DECLARE

[Anup Patel]

From: Sricharan R 

This patch uses IOMMU_OF_DECLARE to register the driver
and the iommu_ops. So when master devices of the iommu are
registered, of_xlate callback can be used to add the master
configurations to the smmu driver.

Signed-off-by: Sricharan R 
Signed-off-by: Anup Patel 
Tested-by: Anup Patel 
---
 drivers/iommu/arm-smmu.c | 35 ++-
 1 file changed, 22 insertions(+), 13 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index bf1895c..2c8f871 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -265,6 +266,8 @@
 #define FSYNR0_WNR (1 << 4)
 
 static int force_stage;
+static bool init_done;
+
 module_param_named(force_stage, force_stage, int, S_IRUGO);
 MODULE_PARM_DESC(force_stage,
"Force SMMU mappings to be installed at a particular stage of 
translation. A value of '1' or '2' forces the corresponding stage. All other 
values are ignored (i.e. no stage is forced). Note that selecting a specific 
stage will disable support for nested translation.");
@@ -1926,20 +1929,8 @@ static struct platform_driver arm_smmu_driver = {
 
 static int __init arm_smmu_init(void)
 {
-   struct device_node *np;
int ret;
 
-   /*
-* Play nice with systems that don't have an ARM SMMU by checking that
-* an ARM SMMU exists in the system before proceeding with the driver
-* and IOMMU bus operation registration.
-*/
-   np = of_find_matching_node(NULL, arm_smmu_of_match);
-   if (!np)
-   return 0;
-
-   of_node_put(np);
-
ret = platform_driver_register(&arm_smmu_driver);
if (ret)
return ret;
@@ -1958,15 +1949,33 @@ static int __init arm_smmu_init(void)
bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
 #endif
 
+   init_done = true;
+
return 0;
 }
 
+static int __init arm_smmu_of_setup(struct device_node *np)
+{
+
+   if (!init_done)
+   arm_smmu_init();
+
+   of_iommu_set_ops(np, &arm_smmu_ops);
+
+   return 0;
+}
+
+IOMMU_OF_DECLARE(arm_smmu_v1, "arm,smmu-v1", arm_smmu_of_setup);
+IOMMU_OF_DECLARE(arm_smmu_v2, "arm,smmu-v2", arm_smmu_of_setup);
+IOMMU_OF_DECLARE(arm_smmu_400, "arm,mmu-400", arm_smmu_of_setup);
+IOMMU_OF_DECLARE(arm_smmu_401, "arm,mmu-401", arm_smmu_of_setup);
+IOMMU_OF_DECLARE(arm_smmu_500, "arm,mmu-500", arm_smmu_of_setup);
+
 static void __exit arm_smmu_exit(void)
 {
return platform_driver_unregister(&arm_smmu_driver);
 }
 
-subsys_initcall(arm_smmu_init);
 module_exit(arm_smmu_exit);
 
 MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
-- 
1.9.1

linux-next: Tree for Feb 8

[Stephen Rothwell]

Hi all,

Changes since 20160205:

The sunxi tree lost its build failure.

The ext4 tree gained a build failure so I used the version from
next-20160205.

The tty tree gained a conflict against the tty.current tree.

The gpio tree still had its build failure so I used the version from
next-20160128.

The aio tree still had a build failure so I used the version from
next-20160111.

The akpm-current tree gained a build failure for which I reverted
a commit.

Non-merge commits (relative to Linus' tree): 3039
 2735 files changed, 100907 insertions(+), 48230 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  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 a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 239 trees (counting Linus' and 36 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 my 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.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (46df55ceeaf3 Merge tag 'usb-4.5-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (74bf8efb5fa6 Linux 4.4-rc7)
Merging arm-current/fixes (03590cb56d5d ARM: wire up copy_file_range() syscall)
Merging m68k-current/for-linus (daf670bc9d36 m68k/defconfig: Update defconfigs 
for v4.5-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (19f97c983071 powerpc/book3s_32: Fix build error 
with checkpoint restart)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (ca0bb0798022 Add sun4v_wdt watchdog driver)
Merging net/master (aa7b45378059 update be2net maintainers' email addresses)
Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops)
Merging ipvs/master (b16c29191dc8 netfilter: nf_conntrack: use safer way to 
lock all buckets)
Merging wireless-drivers/master (d76d65fd2695 rtlwifi: fix broken VHT support)
Merging mac80211/master (212c5a5e6ba6 mac80211: minstrel: Change expected 
throughput unit back to Kbps)
Merging sound-current/for-linus (6c361d10e0eb Revert "ALSA: hda - Fix noise on 
Gigabyte Z170X mobo")
Merging pci-current/for-linus (0cf1337e0b83 PCI: rcar: Add device tree support 
for r8a7793)
Merging driver-core.current/driver-core-linus (36f90b0a2ddd Linux 4.5-rc2)
Merging tty.current/tty-linus (1f55c718c290 pty: make sure super_block is still 
valid in final /dev/tty close)
Merging usb.current/usb-linus (89140fdaf11a xhci: harden xhci_find_next_ext_cap 
against device removal)
Merging usb-gadget-fixes/fixes (6a4290cc28be usb: dwc3: gadget: set the OTG 
flag in dwc3 gadget driver.)
Merging usb-serial-fixes/usb-linus (4152b387da81 USB: option: fix Cinterion 
AHxx enumeration)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: 
fix a possible NULL dereference)
Merging staging.current/staging-linus (5982557ac6ee Merge tag 
'iio-fixes-for-4.5b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into staging-linus)
Merging char-misc.current/char-misc-linus (7326fffb712f mei: validate request 
value in client notify request ioctl)
Merging input-current/for-linus (d4f1b06d685d Input: vmmouse - fix absolute 
device registration)
Merging crypto-current/master (8a3978ad55fb crypto: marvell/cesa - fix test in 
mv_cesa_dev_dma_init())
Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver 
explici

Re: [PATCH 1/2] dax: pass bdev argument to dax_clear_blocks()

[Dave Chinner]

On Sun, Feb 07, 2016 at 06:44:09PM -0700, Ross Zwisler wrote:
> On Mon, Feb 08, 2016 at 09:03:29AM +1100, Dave Chinner wrote:
> > On Sun, Feb 07, 2016 at 12:19:12AM -0700, Ross Zwisler wrote:
> > > dax_clear_blocks() needs a valid struct block_device and previously it was
> > > using inode->i_sb->s_bdev in all cases.  This is correct for normal inodes
> > > on mounted ext2, ext4 and XFS filesystems, but is incorrect for DAX raw
> > > block devices and for XFS real-time devices.
> > > 
> > > Instead, have the caller pass in a struct block_device pointer which it
> > > knows to be correct.
> > 
> > > diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
> > > index 07ef29b..f722ba2 100644
> > > --- a/fs/xfs/xfs_bmap_util.c
> > > +++ b/fs/xfs/xfs_bmap_util.c
> > > @@ -73,9 +73,11 @@ xfs_zero_extent(
> > >   xfs_daddr_t sector = xfs_fsb_to_db(ip, start_fsb);
> > >   sector_tblock = XFS_BB_TO_FSBT(mp, sector);
> > >   ssize_t size = XFS_FSB_TO_B(mp, count_fsb);
> > > + struct inode*inode = VFS_I(ip);
> > >  
> > >   if (IS_DAX(VFS_I(ip)))
> > > - return dax_clear_blocks(VFS_I(ip), block, size);
> > > + return dax_clear_blocks(inode, xfs_find_bdev_for_inode(inode),
> > > + block, size);
> > 
> > Get rid of the local inode variable and use VFS_I(ip) like the code
> > originally did. Do not change code that is unrelated to the
> > modifcation being made, especially when it results in making
> > the code an inconsistent mess of mixed pointer constructs
> 
> The local 'inode' variable was added to avoid multiple calls for VFS_I() for
> the same 'ip'.

My point is you didn't achieve that. The end result of your patch
is:

struct inode*inode = VFS_I(ip);

if (IS_DAX(VFS_I(ip)))
return dax_clear_blocks(inode, xfs_find_bdev_for_inode(inode),
block, size);

So now we have a local variable, but we still have 2 calls to
VFS_I(ip). i.e. this makes the code harder to read and understand
than before for no benefit.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH 1/2] dt/bindings: Add bindings for the PIC32 SPI peripheral

[Purna Chandra Mandal]

On 02/05/2016 07:02 PM, Sergei Shtylyov wrote:

> Hello.
> On 2/5/2016 8:08 AM, Purna Chandra Mandal wrote:
 From: Purna Chandra Mandal 
 Document the devicetree bindings for the SPI peripheral found
 on Microchip PIC32 class devices.
 Signed-off-by: Purna Chandra Mandal 
 Signed-off-by: Joshua Henderson 
 ---
.../bindings/spi/microchip,spi-pic32.txt   |   44 
 
1 file changed, 44 insertions(+)
create mode 100644 
 Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
 diff --git 
 a/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt 
 b/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
 new file mode 100644
 index 000..a555618
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
 @@ -0,0 +1,44 @@
 +* Microchip PIC32 SPI device
> [...]
 +Example:
 +
 +spi1:spi@0x1f821000 {
>>> Please insert spaces after colon.
>> ack
>>
> And please drop "0x" from the  part of the name.

ack.

> MBR, Sergei

[PATCH 1/2] ARM: remove bzImage target

[Masahiro Yamada]

bzImage has been just an alias for zImage for more than a decade.
It would not hurt to delete it.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/Makefile | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 46fb1ca..d6d453f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -312,13 +312,10 @@ boot := arch/arm/boot
 archprepare:
$(Q)$(MAKE) $(build)=arch/arm/tools include/generated/mach-types.h
 
-# Convert bzImage to zImage
-bzImage: zImage
-
 BOOT_TARGETS   = zImage Image xipImage bootpImage uImage
 INSTALL_TARGETS= zinstall uinstall install
 
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS)
 
 bootpImage uImage: zImage
 zImage: Image
-- 
1.9.1

[PATCH 2/2] ARM: descend into arch/arm/boot only once to generate boot images

[Masahiro Yamada]

Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not
generate invalid images") fixed bad images generation in the parallel
building, but it is not efficient to descend into arch/arm/boot over
and over again.  It is also clumsy to display the same log message
"Kernel: arch/arm/boot/Image is ready" a couple of times.

  $ make ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage
  [snip]
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
Building modules, stage 2.
MODPOST 279 modules
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
UIMAGE  arch/arm/boot/uImage
  Image Name:   Linux-4.5.0-rc3
  Created:  Mon Feb  8 13:22:53 2016
  Image Type:   ARM Linux Kernel Image (uncompressed)
  Data Size:6768768 Bytes = 6610.12 kB = 6.46 MB
  Load Address: 80208000
  Entry Point:  80208000
Image arch/arm/boot/uImage is ready

This commit allows arch/arm/boot/Makefile to build boot images at once
instead of generating them one by one.  Of course, it works correctly
also in parallel building.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/Makefile | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index d6d453f..6db669e 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -315,13 +315,17 @@ archprepare:
 BOOT_TARGETS   = zImage Image xipImage bootpImage uImage
 INSTALL_TARGETS= zinstall uinstall install
 
-PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS) __build_images
 
-bootpImage uImage: zImage
-zImage: Image
+$(BOOT_TARGETS): __build_images
+   @:
 
-$(BOOT_TARGETS): vmlinux
-   $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
+__build_images: vmlinux
+   $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) \
+   $(addprefix $(boot)/,
+   $(sort $(filter $(BOOT_TARGETS),$(MAKECMDGOALS)) \
+   $(if $(filter all,$(MAKECMDGOALS)), $(KBUILD_IMAGE)) \
+   $(if $(MAKECMDGOALS),,$(KBUILD_IMAGE
 
 $(INSTALL_TARGETS):
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
-- 
1.9.1

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/mm/hash_utils_64.c: In function 'htab_bolt_mapping':
arch/powerpc/mm/hash_utils_64.c:260:28: error: 'linear_map_hash_count' 
undeclared (first use in this function)
(paddr >> PAGE_SHIFT) < linear_map_hash_count)
^
arch/powerpc/mm/hash_utils_64.c:260:28: note: each undeclared identifier is 
reported only once for each function it appears in
arch/powerpc/mm/hash_utils_64.c:261:4: error: 'linear_map_hash_slots' 
undeclared (first use in this function)
linear_map_hash_slots[paddr >> PAGE_SHIFT] = ret | 0x80;
^
arch/powerpc/mm/hash_utils_64.c: In function 'htab_initialize':
arch/powerpc/mm/hash_utils_64.c:724:3: error: 'linear_map_hash_count' 
undeclared (first use in this function)
   linear_map_hash_count = memblock_end_of_DRAM() >> PAGE_SHIFT;
   ^
arch/powerpc/mm/hash_utils_64.c:725:3: error: 'linear_map_hash_slots' 
undeclared (first use in this function)
   linear_map_hash_slots = __va(memblock_alloc_base(
   ^

Caused by commit

  79581c9f284e ("powerpc: query dynamic DEBUG_PAGEALLOC setting")

The CONFIG_DEBUG_PAGEALLOC stuff in this file depends on extra data
being kept which was left under CONFIG_DEBUG_PAGEALLOC protection.

I just reverted this commit for today.

-- 
Cheers,
Stephen Rothwell

[PATCHv2] staging: rtl8192e: prefer using eth_broadcast_addr()

[Gujulan Elango, Hari Prasath (H.)]

From: Hari Prasath Gujulan Elango 

Prefer using the eth_broadcast_addr() instead of memset to broadcast
address 0xFF to the array.

Signed-off-by: Hari Prasath Gujulan Elango 
---
v2: From email address was missing as pointed by Greg.
---
 drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c 
b/drivers/staging/rtl8192e/rtllib_softmac.c
index d0fedb0..2a57640 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -355,9 +355,9 @@ static inline struct sk_buff *rtllib_probe_req(struct 
rtllib_device *ieee)
req->header.frame_ctl = cpu_to_le16(RTLLIB_STYPE_PROBE_REQ);
req->header.duration_id = 0;
 
-   memset(req->header.addr1, 0xff, ETH_ALEN);
+   eth_broadcast_addr(req->header.addr1);
ether_addr_copy(req->header.addr2, ieee->dev->dev_addr);
-   memset(req->header.addr3, 0xff, ETH_ALEN);
+   eth_broadcast_addr(req->header.addr3);
 
tag = (u8 *) skb_put(skb, len + 2 + rate_len);
 
-- 
1.9.1

Re: [PATCH 1/2] dax: pass bdev argument to dax_clear_blocks()

[Ross Zwisler]

> On Feb 7, 2016, at 6:46 PM, Ross Zwisler  wrote:
> 
>> On Sun, Feb 07, 2016 at 10:19:29AM -0800, Dan Williams wrote:
>> On Sat, Feb 6, 2016 at 11:19 PM, Ross Zwisler
>>  wrote:
>>> dax_clear_blocks() needs a valid struct block_device and previously it was
>>> using inode->i_sb->s_bdev in all cases.  This is correct for normal inodes
>>> on mounted ext2, ext4 and XFS filesystems, but is incorrect for DAX raw
>>> block devices and for XFS real-time devices.
>>> 
>>> Instead, have the caller pass in a struct block_device pointer which it
>>> knows to be correct.
>>> 
>>> Signed-off-by: Ross Zwisler 
>>> ---
>>> fs/dax.c   | 4 ++--
>>> fs/ext2/inode.c| 5 +++--
>>> fs/xfs/xfs_aops.c  | 2 +-
>>> fs/xfs/xfs_aops.h  | 1 +
>>> fs/xfs/xfs_bmap_util.c | 4 +++-
>>> include/linux/dax.h| 3 ++-
>>> 6 files changed, 12 insertions(+), 7 deletions(-)
>>> 
>>> diff --git a/fs/dax.c b/fs/dax.c
>>> index 227974a..4592241 100644
>>> --- a/fs/dax.c
>>> +++ b/fs/dax.c
>>> @@ -83,9 +83,9 @@ struct page *read_dax_sector(struct block_device *bdev, 
>>> sector_t n)
>>>  * and hence this means the stack from this point must follow GFP_NOFS
>>>  * semantics for all operations.
>>>  */
>>> -int dax_clear_blocks(struct inode *inode, sector_t block, long _size)
>>> +int dax_clear_blocks(struct inode *inode, struct block_device *bdev,
>>> +   sector_t block, long _size)
>> 
>> Since this is a bdev relative routine we should also resolve the
>> sector, i.e. the signature should drop the inode:
>> 
>> int dax_clear_sectors(struct block_device *bdev, sector_t sector, long _size)
> 
> The inode is still needed because dax_clear_blocks() needs inode->i_blkbits.
> Unless there is some easy way to get this from the bdev that I'm not seeing?

Never mind, you are passing in the sector, not the block.  Sure, this seems 
better - I'll fix this for v2.

[PATCH v3] vsprintf: kptr_restrict is okay in IRQ when 2

[Jason A. Donenfeld]

The kptr_restrict flag, when set to 1, only prints the kernel
address when the user has CAP_SYSLOG. When it is set to 2, the
kernel address is always printed as zero. When set to 1, this
needs to check whether or not we're in IRQ. However, when set to
2, this check is unneccessary, and produces confusing results
in dmesg. Thus, only make sure we're not in IRQ when mode 1 is
used, but not mode 2.

Signed-off-by: Jason A. Donenfeld 
---
 lib/vsprintf.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 80d8ce5..37c7068 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1605,22 +1605,23 @@ char *pointer(const char *fmt, char *buf, char *end, 
void *ptr,
return buf;
}
case 'K':
-   /*
-* %pK cannot be used in IRQ context because its test
-* for CAP_SYSLOG would be meaningless.
-*/
-   if (kptr_restrict && (in_irq() || in_serving_softirq() ||
- in_nmi())) {
-   if (spec.field_width == -1)
-   spec.field_width = default_width;
-   return string(buf, end, "pK-error", spec);
-   }
-
switch (kptr_restrict) {
case 0:
/* Always print %pK values */
break;
case 1: {
+   const struct cred *cred;
+
+   /*
+* kptr_restrict==1 cannot be used in IRQ context 
because
+* its test for CAP_SYSLOG would be meaningless.
+*/
+   if (in_irq() || in_serving_softirq() || in_nmi()) {
+   if (spec.field_width == -1)
+   spec.field_width = default_width;
+   return string(buf, end, "pK-error", spec);
+   }
+
/*
 * Only print the real pointer value if the current
 * process has CAP_SYSLOG and is running with the
@@ -1630,8 +1631,7 @@ char *pointer(const char *fmt, char *buf, char *end, void 
*ptr,
 * leak pointer values if a binary opens a file using
 * %pK and then elevates privileges before reading it.
 */
-   const struct cred *cred = current_cred();
-
+   cred = current_cred();
if (!has_capability_noaudit(current, CAP_SYSLOG) ||
!uid_eq(cred->euid, cred->uid) ||
!gid_eq(cred->egid, cred->gid))
-- 
2.7.0

Re: [PATCH] tty: serial: meson: Add earlycon support

[Peter Hurley]

Hi Nicolas,

On 02/07/2016 05:38 PM, Nicolas Saenz Julienne wrote:
> Signed-off-by: Nicolas Saenz Julienne 
> ---
>  Documentation/kernel-parameters.txt |  6 ++
>  drivers/tty/serial/meson_uart.c | 22 ++
>  2 files changed, 28 insertions(+)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 551ecf0..1661af4 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1025,6 +1025,12 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   the driver will use only 32-bit accessors to read/write
>   the device registers.
>  
> + meson,
> + Start an early, polled-mode console on an meson serial
> + port at the specified address. The serial port
> + must already be setup and configured. Options are not
> + yet supported.
> +
>   msm_serial,
>   Start an early, polled-mode console on an msm serial
>   port at the specified address. The serial port
> diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
> index b12a37b..f6ff2fa 100644
> --- a/drivers/tty/serial/meson_uart.c
> +++ b/drivers/tty/serial/meson_uart.c
> @@ -548,6 +548,28 @@ static int __init meson_serial_console_init(void)
>  }
>  console_initcall(meson_serial_console_init);
>  
> +static void meson_early_console_write(struct console *con, const char *s,
> +   unsigned n)
  
I don't really care, but it's customary to use 'unsigned int'.


> +{
> + struct earlycon_device *dev = con->data;
> +
> + uart_console_write(&dev->port, s, n, meson_console_putchar);
> +}
> +
> +static int __init meson_early_console_setup(struct earlycon_device *device,
> + const char *opt)
> +{
> + if (!device->port.membase)
> + return -ENODEV;
> +
> + device->con->write = meson_early_console_write;
> + return 0;
> +}
> +
> +EARLYCON_DECLARE(meson, meson_early_console_setup);
> +OF_EARLYCON_DECLARE(meson, "amlogic,meson-uart",
> + meson_early_console_setup);
> +

With today's linux-next (or Greg's tty-next tree), it is no longer necessary to
declare separate earlycon's when you want both; OF_EARLYCON_DECLARE() declares
both a devicetree-enabled earlycon and automatically provides for a command line
earlycon of the same name.

Regards,
Peter Hurley

>  #define MESON_SERIAL_CONSOLE (&meson_serial_console)
>  #else
>  #define MESON_SERIAL_CONSOLE NULL
> 

Re: [PATCH] tty: serial: meson: Implement earlycon support

[Peter Hurley]

Hi Andreas,

On 02/07/2016 12:57 PM, Andreas Färber wrote:
> Reuse the existing console write implementation for implementing
> DT-based and command-line-based earlycon support.
> 
> Signed-off-by: Andreas Färber 
> ---
>  Documentation/kernel-parameters.txt |  6 ++
>  drivers/tty/serial/meson_uart.c | 13 +
>  2 files changed, 19 insertions(+)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 602065c..90801ac 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1030,6 +1030,12 @@ Such letter suffixes can also be entirely omitted.
>   the driver will use only 32-bit accessors to read/write
>   the device registers.
>  
> + meson_serial,
> + Start an early, polled-mode console on a meson serial
> + port at the specified address. The serial port must
> + already be setup and configured. Options are not yet
> + supported.
> +
>   msm_serial,
>   Start an early, polled-mode console on an msm serial
>   port at the specified address. The serial port
> diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
> index b12a37b..6f89567 100644
> --- a/drivers/tty/serial/meson_uart.c
> +++ b/drivers/tty/serial/meson_uart.c
> @@ -548,6 +548,19 @@ static int __init meson_serial_console_init(void)
>  }
>  console_initcall(meson_serial_console_init);
>  
> +static int __init
> +meson_serial_early_console_setup(struct earlycon_device *device, const char 
> *opt)
> +{
> + if (!device->port.membase)
> + return -ENODEV;
> +
> + device->con->write = meson_serial_console_write;

meson_serial_console_write() is not appropriate for earlycon; it assumes the
earlycon port is the same as the driver port (it isn't).


> + return 0;
> +}
> +EARLYCON_DECLARE(meson_serial, meson_serial_early_console_setup);
> +OF_EARLYCON_DECLARE(meson_serial, "amlogic,meson-uart",
> + meson_serial_early_console_setup);

With today's linux-next (or Greg's tty-next tree), it is no longer necessary to
declare separate earlycon's when you want both; OF_EARLYCON_DECLARE() declares
both a devicetree-enabled earlycon and automatically provides for a command line
earlycon of the same name.

Regards,
Peter Hurley

> +
>  #define MESON_SERIAL_CONSOLE (&meson_serial_console)
>  #else
>  #define MESON_SERIAL_CONSOLE NULL
> 

Re: [PATCH RESEND 1/2] dmaengine: added MIC X200 Coprocessor DMA driver

[Vinod Koul]

On Thu, Feb 04, 2016 at 04:10:49PM +0100, Jacek Lawrynowicz wrote:
> This patch implements the DMA Engine driver for the DMA controller on
> MIC X200 Coprocessors which are PCIe cards running Linux. Separate but
> identical DMA channels are available for the host and card. DMA
> transfers can be done from both the host and card in host<->card and
> host<->host directions.
> 
> Signed-off-by: Jacek Lawrynowicz 
> Signed-off-by: Sudeep Dutt 
> Signed-off-by: Ashutosh Dixit 
> Signed-off-by: Andrzej Kacprowski 
> ---
>  drivers/dma/Kconfig|   18 +
>  drivers/dma/Makefile   |1 +
>  drivers/dma/mic_x200_dma.c | 1114 
> 
>  3 files changed, 1133 insertions(+)
>  create mode 100644 drivers/dma/mic_x200_dma.c
> 
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 79b1390..a3ea8b9 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -277,6 +277,24 @@ config INTEL_MIC_X100_DMA
> OS and tools for MIC to use with this driver are available from
> .
>  
> +config INTEL_MIC_X200_DMA
> + tristate "Intel MIC X200 DMA Driver"
> +depends on 64BIT && X86 && PCI

X86_64?

How different is this from x100 controller and why do we need a new driver?

> + select DMAENGINE
> + help
> +   This enables DMA support for the Intel Many Integrated Core
> +   (MIC) family of PCIe form factor coprocessor X200 devices that
> +   run a 64 bit Linux OS. This driver will be used by both MIC
> +   host and card drivers.
> +
> +   If you are building host kernel with a MIC device or a card
> +   kernel for a MIC device, then say M (recommended) or Y, else
> +   say N. If unsure say N.
> +
> +   More information about the Intel MIC family as well as the Linux
> +   OS and tools for MIC to use with this driver are available from
> +   .
> +
>  config K3_DMA
>   tristate "Hisilicon K3 DMA support"
>   depends on ARCH_HI3xxx
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index 2dd0a067..a3756f5 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_INTEL_IDMA64) += idma64.o
>  obj-$(CONFIG_INTEL_IOATDMA) += ioat/
>  obj-$(CONFIG_INTEL_IOP_ADMA) += iop-adma.o
>  obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
> +obj-$(CONFIG_INTEL_MIC_X200_DMA) += mic_x200_dma.o
>  obj-$(CONFIG_K3_DMA) += k3dma.o
>  obj-$(CONFIG_LPC18XX_DMAMUX) += lpc18xx-dmamux.o
>  obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
> diff --git a/drivers/dma/mic_x200_dma.c b/drivers/dma/mic_x200_dma.c
> new file mode 100644
> index 000..80c4959
> --- /dev/null
> +++ b/drivers/dma/mic_x200_dma.c
> @@ -0,0 +1,1114 @@
> +/*
> + * Intel MIC Platform Software Stack (MPSS)
> + *
> + * Copyright(c) 2016 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License, version 2, as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * The full GNU General Public License is included in this distribution in
> + * the file called "COPYING".
> + *
> + * Intel MIC X200 DMA driver
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "dmaengine.h"
> +
> +#define MIC_DMA_DRV_NAME "mic_x200_dma"
> +
> +#define MIC_DMA_DESC_RX_SIZE (128 * 1024)
> +#define MIC_DMA_ABORT_TO_MS  3000
> +#define MIC_DMA_RING_TO_MS   20
> +#define MIC_DMA_PENDING_LEVEL16
> +#define MIC_DMA_ABORT_LIMIT  5
> +
> +/* DMA Descriptor related flags */
> +#define MIC_DMA_DESC_VALID   BIT(31)
> +#define MIC_DMA_DESC_INTR_ENABLE BIT(30)
> +#define MIC_DMA_DESC_SRC_LINK_ERRBIT(29)
> +#define MIC_DMA_DESC_DST_LINK_ERRBIT(28)
> +#define MIC_DMA_DESC_LOW_MASK(0xUL)
> +#define MIC_DMA_DESC_SRC_LOW_SHIFT   32
> +#define MIC_DMA_DESC_BITS_32_TO_47   (0xUL << 32)
> +#define MIC_DMA_DESC_SIZE_MASK   ((1UL << 27) - 1)
> +
> +#define MIC_DMA_DESC_RING_ADDR_LOW   0x214
> +#define MIC_DMA_DESC_RING_ADDR_HIGH  0x218
> +#define MIC_DMA_NEXT_DESC_ADDR_LOW   0x21C
> +#define MIC_DMA_DESC_RING_SIZE   0x220
> +#define MIC_DMA_LAST_DESC_ADDR_LOW   0x224
> +#define MIC_DMA_LAST_DESC_XFER_SIZE  0x228
> +
> +#define MIC_DMA_CTRL_STATUS  0x238
> +#define MIC_DMA_CTRL_PAUSE   BIT(0)
> +#define MIC_DMA_CTRL_ABORT   BIT(1)
> +#define MIC_DMA_CTRL_WB_ENABLE   BIT(2)
> +#define MIC_DMA_CTRL_START   BIT(3)
> +#define MIC_DMA_CTRL_RING_STOP  

Re: [PATCH] Staging: xgifb: vgatypes.h: Coding style warning fix for block comments

[Kroah-Hartman]

On Fri, Jan 15, 2016 at 05:30:02PM +0800, YU Bo wrote:
> This patch is to vgatypes.h file that fixes up following warnings
> reported by checkpatch.pl tool
> 
> Signed-off-by: YU Bo 
> ---
>  drivers/staging/xgifb/vgatypes.h |   12 
>  1 file changed, 8 insertions(+), 4 deletions(-)

None of your patches applied, are you sure you are sending them
properly?

Re: [PATCH] drivers: staging: xgifb: vgatypes.h: fixed coding style warnings

[Greg KH]

On Wed, Jan 13, 2016 at 05:11:56PM +0530, Saatvik Arya wrote:
> fixed warnings about comment block coding style
> 
> Signed-off-by: Saatvik Arya 
> ---
>  drivers/staging/xgifb/vgatypes.h | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 

Why did you resend this without saying why you resent it?  It just
confuses us...

Please fix up and resend properly.

thanks,

greg k-h

Re: [PATCH] staging: dgnc: convert to wait_event_interruptible_timeout

[gre...@linuxfoundation.org]

On Thu, Dec 24, 2015 at 01:54:12PM +, Gujulan Elango, Hari Prasath (H.) 
wrote:
> This patch makes use of wait_event_interruptible_timeout to achieve timeout
> functionality.This is a TODO mentiond in the comment which is also removed.
> It also aligns with what the function is supposed to do as in the
> comments.
> 
> Signed-off-by: Hari Prasath Gujulan Elango 
> ---
>  drivers/staging/dgnc/dgnc_neo.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
> index 39c76e7..7d9efe0 100644
> --- a/drivers/staging/dgnc/dgnc_neo.c
> +++ b/drivers/staging/dgnc/dgnc_neo.c
> @@ -1306,10 +1306,8 @@ static int neo_drain(struct tty_struct *tty, uint 
> seconds)
>   /*
>* Go to sleep waiting for the tty layer to wake me back up when
>* the empty flag goes away.
> -  *
> -  * NOTE: TODO: Do something with time passed in.
>*/
> - rc = wait_event_interruptible(un->un_flags_wait, ((un->un_flags & 
> UN_EMPTY) == 0));
> + rc = wait_event_interruptible_timeout(un->un_flags_wait, ((un->un_flags 
> & UN_EMPTY) == 0), msecs_to_jiffies(seconds * 1000));

Any reason you didn't properly wrap your line at the 80 column limit?

Please fix and resend.

thanks,

greg k-h

Re: [PATCH] staging: netlogic: Coding Style Alignment should match open parenthesis

[Greg KH]

On Sat, Dec 12, 2015 at 09:49:37PM -0800, Benjamin Young wrote:
> Fixed alignment issues with parenthesis so the code is easier to read.
> 
> Signed-off-by: Benjamin Young 
> ---
>  drivers/staging/netlogic/platform_net.c |  12 +--
>  drivers/staging/netlogic/xlr_net.c  | 159 
> +---
>  2 files changed, 91 insertions(+), 80 deletions(-)

Also does not apply :(

Re: [PATCH] staging: netlogic: Coding Style Fix Comparison to NULL could be written with !

[Greg Kroah-Hartman]

On Sat, Dec 12, 2015 at 06:45:59AM -0800, Benjamin Young wrote:
> Fixed coding style for null comparisons in netlogic driver to be more 
> consistant
> with the rest of the kernel coding style
> 
> Signed-off-by: Benjamin Young 
> ---
>  drivers/staging/netlogic/xlr_net.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Doesn't apply to my tree at all :(

Re: [PATCH] staging: clocking-wizard: add blank line after struct declaration.

[Greg KH]

On Sun, Feb 07, 2016 at 08:06:16PM -0800, Greg KH wrote:
> On Tue, Dec 01, 2015 at 01:56:01PM +0100, Christian Colic wrote:
> > Add blank line after struct declaration to fix checkpatch check.
> > 
> > Signed-off-by: Christian Colic 
> > Reviewed-by: Soren Brinkmann 
> > 
> > ---
> >  drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c 
> > b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> > index b8e2f61..1cbf5eb 100644
> > --- a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> > +++ b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> > @@ -71,6 +71,7 @@ struct clk_wzrd {
> > int speed_grade;
> > bool suspended;
> >  };
> > +
> >  #define to_clk_wzrd(_nb) container_of(_nb, struct clk_wzrd, nb)
> >  
> >  /* maximum frequencies for input/output clocks per speed grade */
> > -- 
> > 2.5.0
> > 
> 
> Doesn't apply :(

Because I took another patch, which was sent after yours, sorry about
that, my fault.

Re: [PATCH] staging: clocking-wizard: add blank line after struct declaration.

[Greg KH]

On Tue, Dec 01, 2015 at 01:56:01PM +0100, Christian Colic wrote:
> Add blank line after struct declaration to fix checkpatch check.
> 
> Signed-off-by: Christian Colic 
> Reviewed-by: Soren Brinkmann 
> 
> ---
>  drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c 
> b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> index b8e2f61..1cbf5eb 100644
> --- a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> +++ b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> @@ -71,6 +71,7 @@ struct clk_wzrd {
>   int speed_grade;
>   bool suspended;
>  };
> +
>  #define to_clk_wzrd(_nb) container_of(_nb, struct clk_wzrd, nb)
>  
>  /* maximum frequencies for input/output clocks per speed grade */
> -- 
> 2.5.0
> 

Doesn't apply :(

Re: [PATCH] staging: olpc_dcon: Added a space

[Greg KH]

On Tue, Nov 24, 2015 at 10:41:03PM +0530, Anjali Menon wrote:
> Added a space around '/' to remove the check detected by
> the checkpatch.pl.
> 
> CHECK: spaces preferred around that '/' (ctx:VxV)
> 
> Signed-off-by: Anjali Menon 
> ---
>  drivers/staging/olpc_dcon/olpc_dcon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This driver has been deleted from the kernel tree :(

Re: [PATCH 2/2] Staging: rts5208: Add missing dma_mapping_error

[Greg KH]

On Mon, Jan 25, 2016 at 06:27:28PM -0800, Shaun Ren wrote:
> Signed-off-by: Shaun Ren 
> ---

I can't take a patch without a changelog entry, sorry.

Re: [PATCH 1/2] Staging: rts5208: Cleanup rtsx_transport.c

[Greg KH]

On Mon, Jan 25, 2016 at 06:27:27PM -0800, Shaun Ren wrote:
> This patch fixes coding style issues in rtsx_transport.c.
> 
> Signed-off-by: Shaun Ren 
> ---
>  drivers/staging/rts5208/rtsx_transport.c | 115 
> +--
>  1 file changed, 65 insertions(+), 50 deletions(-)

What coding style issues?  Please be specific, and only do one type of
cleanup per patch, otherwise it's hard to review them.

thanks,

greg k-h

Re: [PATCH] staging: rtl8192e: prefer using eth_broadcast_addr()

[gre...@linuxfoundation.org]

On Wed, Jan 20, 2016 at 01:06:13PM +, Gujulan Elango, Hari Prasath (H.) 
wrote:
> From: Hari Prasath Gujulan Elango

When you do this, you need an email address after the name, otherwise
git complains and refuses to apply the patch.

Please fix up and resend.

thanks,

greg k-h

Re: [PATCH v2] staging/dgap: move duplicated code from the dgap_cm.* functions

[Greg Kroah-Hartman]

On Wed, Nov 25, 2015 at 11:51:21PM +0600, Alexander Kuleshov wrote:
> The dgap driver contains three functions: dgap_cmdb(), dgap_cmdw()
> and dgap_cmdw_exit which are contain duplicated code which waits
> if necessary before updating the pointer to limit outstanding
> commands. This patch introduces the wait_for_fep_cmds_limit()
> function which is will be called from these functions to prevent
> code duplication.
> 
> Signed-off-by: Alexander Kuleshov 
> ---
> Forgot Signed-off-by line
> 
>  drivers/staging/dgap/dgap.c | 103 
> 
>  1 file changed, 37 insertions(+), 66 deletions(-)

This driver is now deleted from the kernel tree, sorry :(

Re: [PATCH 4/4] staging: rtl8192u: r8192U_core: use kmalloc_array instead of kmalloc

[Greg Kroah-Hartman]

On Sun, Nov 08, 2015 at 10:17:54PM +0800, Geliang Tang wrote:
> Use kmalloc_array instead of kmalloc to allocate memory for an array.
> 
> Signed-off-by: Geliang Tang 
> ---
>  drivers/staging/rtl8192u/r8192U_core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
> index e06864f..07a1447 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -1725,8 +1725,8 @@ static short rtl8192_usb_initendpoints(struct 
> net_device *dev)
>  {
>   struct r8192_priv *priv = ieee80211_priv(dev);
>  
> - priv->rx_urb = kmalloc(sizeof(struct urb *) * (MAX_RX_URB + 1),
> -GFP_KERNEL);
> + priv->rx_urb = kmalloc_array(MAX_RX_URB + 1, sizeof(struct urb *),
> +  GFP_KERNEL);

I don't see the benefit here with this change, do you?

Re: [PATCH] staging: rtl8712: Fix Comparison with constant warning.

[Greg Kroah-Hartman]

On Sat, Feb 06, 2016 at 08:11:11PM +0530, Pinkesh Badjatiya wrote:
> Fix Comparisons with constant on the left side of the test.
> Checkpatch.pl warning.
> --
> WARNING: Comparisons should place the constant on the right side of the
> test
> 296: FILE: ./rtl8712_cmd.c:296:
>   while ((0 != r8712_read32(pAdapter, IOCMD_CTRL_REG)) &&
> 
> Signed-off-by: Pinkesh Badjatiya 
> Acked-by: Larry Finger 
> ---
>  drivers/staging/rtl8712/rtl8712_cmd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Someone else sent this before you did, sorry :(

Very Urgent,response needed.

[Ms Ayala]

Hi,

I am Ms. Ayala; I am getting in touch with you regarding an extremely
important and urgent matter.If you would oblige me the opportunity,I shall
provide you with details upon your response.Please respond to: 
msayalabrnaca...@163.com

Faithfully,
Ms. Ayala Bracha

Re: [PATCH] staging: rtl8712: Fix typos and checkpatch warnings.

[Greg KH]

On Tue, Nov 17, 2015 at 01:23:54PM +0100, Christian Colic wrote:
> Fix typo SUCESS -> SUCCESS and multiple
> checkpatch checks (blank line, indentation).

That's multiple different things, please break this into multiple
patches, each one only doing one thing.

thanks,

greg k-h

Re: [PATCH] staging: rtl8712: Fix Comparison with constant warning.

[Greg Kroah-Hartman]

On Sat, Feb 06, 2016 at 08:53:57AM -0600, Larry Finger wrote:
> On 02/06/2016 08:41 AM, Pinkesh Badjatiya wrote:
> >Fix Comparisons with constant on the left side of the test.
> >Checkpatch.pl warning.
> >--
> >WARNING: Comparisons should place the constant on the right side of the
> >test
> >296: FILE: ./rtl8712_cmd.c:296:
> > while ((0 != r8712_read32(pAdapter, IOCMD_CTRL_REG)) &&
> >
> >Signed-off-by: Pinkesh Badjatiya 
> >---
> >  drivers/staging/rtl8712/rtl8712_cmd.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> This is another case where the writers of checkpatch are forcing their ideas
> of style on the whole world. The problem is that if I reject your patch, it
> will be submitted by someone else. Thus, reluctantly
> 
> Acked-by: Larry Finger 

Well, the general kernel coding style is to put constants on the right
hand of the expression, so it is good to have it this way...

thanks,

greg k-h

Re: [PATCH 13/13] staging: fbtft: Remove unused and duplicated defines

[Greg Kroah-Hartman]

On Sun, Feb 07, 2016 at 07:40:06PM -0800, Greg Kroah-Hartman wrote:
> On Sun, Dec 20, 2015 at 08:36:07PM +0200, Priit Laes wrote:
> > This patch makes use of the standard MIPI Display Command Set to remove
> > some of duplicate defines from the headers.
> > 
> > Signed-off-by: Priit Laes 
> > ---
> >  drivers/staging/fbtft/fb_hx8357d.h | 32 
> >  drivers/staging/fbtft/fbtft.h  |  8 
> >  2 files changed, 40 deletions(-)
> 
> This patch causes build errors, I can't apply it.  Please be more
> careful in the future...

Oh nevermind, that was my fault, sorry for the noise, this was fine...

Re: [PATCH 13/13] staging: fbtft: Remove unused and duplicated defines

[Greg Kroah-Hartman]

On Sun, Dec 20, 2015 at 08:36:07PM +0200, Priit Laes wrote:
> This patch makes use of the standard MIPI Display Command Set to remove
> some of duplicate defines from the headers.
> 
> Signed-off-by: Priit Laes 
> ---
>  drivers/staging/fbtft/fb_hx8357d.h | 32 
>  drivers/staging/fbtft/fbtft.h  |  8 
>  2 files changed, 40 deletions(-)

This patch causes build errors, I can't apply it.  Please be more
careful in the future...

Re: [PATCH v2 1/2] staging: fwserial: Fix pointer comparison to NULL checkpatch problem

[Greg KH]

On Tue, Dec 01, 2015 at 03:18:11PM +0530, Rajan Vaja wrote:
> Fix pointer comparison to NULL problem reported by checkpatch.
> 
> Signed-off-by: Rajan Vaja 
> ---
>  drivers/staging/fwserial/dma_fifo.c |   10 +-
>  drivers/staging/fwserial/fwserial.c |4 ++--
>  2 files changed, 7 insertions(+), 7 deletions(-)

Someone else sent this, and patch 2/2 already before you did, sorry.

Re: [PATCH RESEND v2 1/8] staging: fsl-mc: static inline function to differentiate root dprc

[Greg KH]

On Fri, Dec 11, 2015 at 01:25:47PM -0600, Lijun Pan wrote:
> Define a static inline function is_root_dprc(dev) to tell whether
> a device is root dprc or not via platform_bus_type.
> Remove fsl_mc_is_root_dprc() because is_root_dprc() is simpler
> and easier to understand.
> 
> Signed-off-by: Lijun Pan 
> ---
> v2: use static inline function instead of macro
> replace the fsl_mc_is_root_dprc with is_root_dprc


This series doesn't apply to my tree anymore, due to another big
patcheset for this subsystem being applied.  Can you please rebase it
against my staging-testing branch of staging.git and resend?

thanks,

greg k-h

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

[Eric Dumazet]

On Sun, 2016-02-07 at 22:24 +, Rainer Weikusat wrote:
> Rainer Weikusat  writes:
> 
> [...]
> 
> > The start uses that to record an error which might need to be
> > reported, the return statement uses it to indicate that an error has
> > occurred. Hence, some kind of in-between translation must occur.  The
> > mutex_lock_interruptible happened to do that but that was never it's
> > intended purpose.
> 
> Additional information: The 'trick' of using recvmsg w/o a receive
> buffer in order to retrieve control messages in fact wouldn't have
> worked with the unix_stream_recvmsg prior to introduction of the
> interruptible lock as that (judging from the git source) would have
> triggered all the same issues,
> 
>   - -EOPNOTSUP if a msg was available
> 
> - -EAGAIN if the code had to wait
> 
> - not receiving the creds if the -EAGAIN hadn't happened because
>   of the continue (that's the other patch)
> 
> IOW, that's a feature inadvertendly added by an otherwise useless code
> change (mea culpa).

This is exactly the needed information for stable teams.

Goal is here is not to blame someone (you, me ... it does not matter) ,
but give to stable teams the point the problem showed up.

See the 'Fixes' tag as a time saver for people like me.

It is incredibly useful when hutting bugs, because each commit can
easily point to the 'bug origin'.

Having spent time lately in af_unix code insanity, I really can tell.

At the time someone fixes a bug, he/she has a clear view of what is
happening, but months later, he/she often has to start again the commits
analysis.

Thanks a lot.

Re: [PATCH 1/6] dma: enable mxs-dma for imx6ul

[Vinod Koul]

On Tue, Feb 02, 2016 at 02:23:16PM +0800, Shawn Guo wrote:
> On Mon, Jan 25, 2016 at 05:40:43PM +0530, Vinod Koul wrote:
> > On Wed, Jan 20, 2016 at 01:57:01PM +0100, Lothar Waßmann wrote:
> > > The mxs-dma unit is also available on i.MX6UL. Make it possible to
> > > select it in Kconfig.
> > 
> > It should be dmaengine:xxx
> > 
> > With that
> > 
> > Acked-by: Vinod Koul 
> 
> I think this can go separately via dma tree.

Okay, pls resend :)

-- 
~Vinod

Re: [PATCH v4] dmaengine: edma: fix residue race for cyclic

[Vinod Koul]

On Thu, Jan 28, 2016 at 11:29:08AM +0100, John Ogness wrote:
> When retrieving the residue value, the SRC/DST fields of the
> active PaRAM are read to determine the current position of
> the DMA engine. However, the AM335x Technical Reference Manual
> states:
> 
>   11.3.3.6 Parameter Set Updates
> 
>   After the TR is read from the PaRAM (and is in the process
>   of being submitted to the EDMA3TC), the following fields are
>   updated as needed: ... SRC DST
> 
> This means SRC/DST is incremented even though the DMA transfer
> may not have started yet or is in progress. Thus if the reader
> of the residue accesses the DMA buffer too quickly, the CPU is
> misinformed about the data that has been successfully processed.
> 
> The CCSTAT.ACTV register is a boolean that is set if any TR is
> being processed by either the EMDA3CC or EDMA3TC. By polling
> this register it is possible to ensure that the residue value
> returned is valid for immediate processing. However, since the
> DMA engine may be active, polling may never hit a moment where
> no TR is being processed. To handle this, the SRC/DST is also
> polled to see if it changes. And as a last resort, a max loop
> count for the busy waiting exists to avoid an infinite loop.

Applied, thanks

-- 
~Vinod

Re: [PATCH v7 0/9] Fix broken DMAFLUSHP on Rockchips platform

[Vinod Koul]

On Mon, Feb 01, 2016 at 02:56:54PM +0800, Caesar Wang wrote:
> Hello Vinod,
> 
> Is there any chance apply the DMA patches?:-)

I was waiting for any ACKs on ARM patches before I merge this series.

> 在 2016年01月22日 19:06, Caesar Wang 写道:
> >This series patches are apply on linus master branch.
> >Okay, this series patches verified on my github.
> >(https://github.com/Caesar-github/rockchip/commits/for-dma-tests)
> >
> >Linux version 4.4.0+ (wxt@ubuntu)  (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #14
> >SMP Fri Jan 22 18:13:12 CST 2016
> >
> >The perious version 6 from Shawn.
> >(http://www.spinics.net/lists/dmaengine/msg06606.html)
> >I pick them up to go on upstream since Shawn hasn't much time to track them.
> >
> >
> >The purpose of the DMAFLUSHP instruction:
> >- Tell the peripheral to clear its status and control registers.
> >- Send a message to the peripheral to resend its level status.
> >
> >There are 3 timings described in PL330 Technical Reference Manual:
> >- Timing 1: Burst request, can work well without DMAFLUSHP.
> >- Timing 2: Single and burst request, DMAC will ignore the single
> > transfer request. This timing happens if there are single
> > and burst request.
> >- Timing 3: Single transfers for a burst request, DMAC should signals
> > datype to request the peripheral to flush the contents of
> > any control registers. This timing happens if there is
> > not enough MFIFO to places the burst data.
> >
> >A peripheral may signal a DMA request during the execution of
> >DMAFLUSHP instruction, that cause DMA request being ignored by DMAC.
> >
> >But DMAC and all peripherals on RK3X SoCs DO NOT support DMAFLUSHP.
> >It can't send a message to the peripheral to resend DMA request,
> >and the peripheral can't acknowledge a flush request from DMAC.
> >So all DMA requests should NOT be ignored by DMAC, and DMAC will not
> >notify the peripheral to flush.
> >
> >To fix this problem, we need:
> >- Do NOT execute DMAFLUSHP instruction.
> >- Timing 2 and timing 3 should not happen.
> >
> >Because on RK3X SoCs, there are 6 or below  channels and 32 MFIFO depth
> >for DMAC_BUS, and 8 channels and 64 MFIFO depth for DMAC_PERI, it is
> >impossible to hit the timing 3 if burst length is equal or less than 4.
> >
> >Since the request type signal by the peripheral can only be set by
> >software. We can set Rockchip Soc's GRF_PERIDMAC_CON0[2:1] to select single
> >or burst request, if it is set b01,  all of the peripharals will signal a 
> >brust
> >request. So the timing 2 will not happen, too.
> >
> >So DMAC on RK3X can support single or burst transfer, but can't support
> >mixed transfer.
> >
> >Because burst transfer is more efficient than single transfer, this is
> >confirmed by our ASIC team, who strongly suggest to use burst transfer.
> >And this is confirmed by Addy's test on RK3288-Pink2 board, the speed of
> >spi flash burst transfer will increase about two times than single transfer.
> >Also, I have tested dw_mmc with pl330 on RK3188 platform to double confirm
> >the result. That means burst transfer is reansonable.
> >
> >So we need a quirk not to execute DMAFLUSHP instruction and to use burst
> >transfer.
> >
> >Note:
> >- The Rockchip Soc default value of GRF_PERIDMAC_CON0[2:1] is b01. To
> >   support brust transfer, these bits should not be changed in bootloader.
> >
> >Todo:
> >remove the patches releated to i2s, that will send them at later.
> >- https://patchwork.kernel.org/patch/7399581/
> >- https://patchwork.kernel.org/patch/7399671/
> >
> >
> >Changes in v7:
> >- As vinod comments, fix the subsystem name.
> >- modify the subject to be better match.
> >- fix the subsystem.
> >- fix the subject.
> >- fix the subject.
> >
> >Changes in v6:
> >- remove expose quirk and add dma max_burst caps for clients
> >- remove expose quirks and add max_burst for dmaengine
> >- remove quirks and get dma caps in order to limit burst
> >
> >Changes in v5:
> >- add Mark's tag for spi changes
> >- remove unnecessary whitespace change
> >- use switch statement for i2s quirk
> >
> >Changes in v4:
> >- remove spi & i2s dts changes and query quirk from dmaengine API
> >   suggeseted by Mark.
> >- fix typo
> >- Add dmaengine_get_quirk hook and implement it for pl330
> >
> >Changes in v3:
> >- add Sunny's tag
> >- add more rockchip drivers' changes in this patchset
> >- add Reviewed-by: Sonny Rao 
> >- add Reviewed-by: Sonny Rao 
> >- add Reviewed-by: Sonny Rao 
> >
> >Changes in v2:
> >- amend the author
> >- reorder the patches suggested by Doug
> >- add Reviewed-by: Doug Anderson  for
> >   rk3288.dtsi patch and arm-pl330.txt patch
> >- add Reviewed-by: Doug Anderson 
> >- amend the author
> >- fix Olof's mail address
> >- amend the author
> >- add Reviewed-by: Doug Anderson 
> >- amend Olof's mail address
> >
> >Changes in v1:
> >- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
> >   by Krzysztof.
> >- add From original author.
> >- re

Re: [PATCH] Staging: wlan-ng: prism2mgmt.h: Coding style warning fix for block comments

[Kroah-Hartman]

On Sun, Jan 17, 2016 at 05:48:49AM +0800, YU Bo wrote:
> This patch is to prism2mgmt.h file that fixes up following warnings
> reported by checkpatch.pl:
> A): Block comments use a trailing */ on a separate line
> 
> Signed-off-by: YU BO 
> ---
>  drivers/staging/wlan-ng/prism2mgmt.h |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Didn't apply :(

Re: [PATCH 3/5] gpio: ath79: Make the driver removable

[Alexandre Courbot]

On Fri, Jan 29, 2016 at 4:44 AM, Alban Bedel  wrote:
> As we now allow the driver to be built as a module it should be
> removable.
>
> Signed-off-by: Alban Bedel 
> ---
>  drivers/gpio/gpio-ath79.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c
> index afb535e..6b15792 100644
> --- a/drivers/gpio/gpio-ath79.c
> +++ b/drivers/gpio/gpio-ath79.c
> @@ -46,6 +46,7 @@ static int ath79_gpio_probe(struct platform_device *pdev)
> ctrl = devm_kzalloc(&pdev->dev, sizeof(*ctrl), GFP_KERNEL);
> if (!ctrl)
> return -ENOMEM;
> +   platform_set_drvdata(pdev, ctrl);
>
> if (np) {
> err = of_property_read_u32(np, "ngpios", &ath79_gpio_count);
> @@ -97,12 +98,21 @@ static int ath79_gpio_probe(struct platform_device *pdev)
> return 0;
>  }
>
> +static int ath79_gpio_remove(struct platform_device *pdev)
> +{
> +   struct ath79_gpio_ctrl *ctrl = platform_get_drvdata(pdev);

platform_get_drvdata will return a gpio_chip *. I agree the address
will be the same, but for correctness you should use the expected
type. Especially since you will not use a member of ath79_gpio_ctrl in
this function anyway.

> +
> +   gpiochip_remove(&ctrl->gc);
> +   return 0;
> +}

I suspect this removal pattern to be quite common, maybe we should
just export bgpio_pdev_remove() to allow other drivers to use it
instead of rewriting their own version?

Re: [PATCH] staging: vt6655: rf.c: checkpatch fixes

[Greg Kroah-Hartman]

On Mon, Jan 11, 2016 at 11:16:08PM +, Lewis Eason wrote:
> This patch fixes "spaces preferred around that $operator" checks.
> 
> Signed-off-by: Lewis Eason 
> ---
>  drivers/staging/vt6655/rf.c | 638 
> ++--
>  1 file changed, 319 insertions(+), 319 deletions(-)

Doesn't apply to my tree :(

Re: [PATCH 1/5] gpio: ath79: Move to the generic GPIO driver

[Alexandre Courbot]

On Fri, Jan 29, 2016 at 4:44 AM, Alban Bedel  wrote:
> Drop most of the code in favor of the generic MMIO GPIO driver.
> As the driver now depend on CONFIG_GPIO_GENERIC also add a Kconfig
> entry to make the driver optional.
>
> We leave the base pointer and lock in the data struct because they are
> needed for the IRQ support.
>
> Signed-off-by: Alban Bedel 
> ---
>  drivers/gpio/Kconfig  |   9 
>  drivers/gpio/Makefile |   2 +-
>  drivers/gpio/gpio-ath79.c | 126 
> ++
>  3 files changed, 24 insertions(+), 113 deletions(-)

Nice, much less code!

Acked-by: Alexandre Courbot 

Re: [PATCH v2 05/12] staging: rtl8188eu: kzalloc replaced by kmalloc

[Greg Kroah-Hartman]

On Wed, Nov 11, 2015 at 05:17:50PM +0700, Ivan Safonov wrote:
> On 11/11/2015 04:43 PM, Dan Carpenter wrote:
> >On Sun, Nov 08, 2015 at 02:11:08PM +0700, Ivan Safonov wrote:
> >>_rtl88e_fill_dummy fills the array elemets with zeros if necessary.
> >>
> >_rtl88e_fill_dummy() fills the last sizeof(u32) or whatever so the code
> >is aligned but it doesn't fill up to the end of FW_8188E_SIZE.  Why do
> >we even allocate that much memory.  Why don't we just allocate:
> >
> > pfwdata = kmalloc(round_up(fwsize, sizeof(u32)), GFP_KERNEL);
> >
> >regards,
> >dan carpenter
> 
> Yes, it will save about 2 KB. I will correct it in the next patch.

Please send a v3 series with this fixed up.

Also, please properly thread your patches so they all show up grouped
together.

thanks,

greg k-h

Re: [PATCH] staging: sm750fb: Fix comments style

[Greg Kroah-Hartman]

On Wed, Dec 02, 2015 at 08:18:11PM +0100, sebastian.lawnic...@yahoo.com wrote:
> From: Sebastian Lawniczak 
> 
> Fix warnings reported by checkpatch.pl in block comments.
> 
> Signed-off-by: Sebastian Lawniczak 
> ---
>  drivers/staging/sm750fb/ddk750_chip.c | 70 
> +++
>  1 file changed, 39 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
> b/drivers/staging/sm750fb/ddk750_chip.c
> index 0331d34..01ddf44 100644
> --- a/drivers/staging/sm750fb/ddk750_chip.c
> +++ b/drivers/staging/sm750fb/ddk750_chip.c
> @@ -86,8 +86,10 @@ static void setMemoryClock(unsigned int frequency)
>   return;
>  
>   if (frequency) {
> - /* Set the frequency to the maximum frequency that the DDR 
> Memory can take
> - which is 336MHz. */
> + /*
> + * Set the frequency to the maximum frequency that the DDR 
> Memory can take
> + * which is 336MHz.
> + */

It should look like:
/*
 * Set the frequency to the maximum frequency that the DDR 
Memory can take
 * which is 336MHz.
 */

So I can't take this patch, sorry.

Please fix it up and resend.

thanks,

greg k-h

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

[Peter Hurley]

On 02/07/2016 06:21 PM, Greg KH wrote:
> Peter, is the merge above correct?

Yes, thanks.

Re: [PATCH] gpio/sysfs: Add ID parameter for GPIO lines

[Alexandre Courbot]

On Tue, Jan 26, 2016 at 7:25 PM, Ricardo Ribalda Delgado
 wrote:
> Hello!
>
> Any comment on this?

Oops, sorry for the delay...

>
>
> Thanks!
>
> On Thu, Dec 17, 2015 at 5:48 PM, Ricardo Ribalda Delgado
>  wrote:
>> On named GPIOs there is currently no find out their numerical id.
>>
>> Because of this, a GPIO pin named like:
>> /sys/class/gpio/PROG_B
>>
>> cannot be unexported by an application different than the one that
>> exported it.

On the other hand, do you want other applications to be able to
arbitrarily unexport GPIOs they don't own? Well, it's not like it is
not already possible anyway.

>>
>> This patch adds a new parameter to the GPIO line called id, that
>> shows the numerical id of a given GPIO. E.g.:
>>
>> $ cat /sys/class/gpio/PROG_B/id
>> 496
>> $ echo 496 > unexport

What we *really* ought to do is have GPIOs behave like other resources
and be automatically freed when the application using them exits. This
will be made possible by the chardev interface, but is impossible to
achieve using sysfs by design.

Adding Linus to get his thoughts, but this simple read-only attribute
does make sense to me.

Acked-by: Alexandre Courbot 

>>
>> Signed-off-by: Ricardo Ribalda Delgado 
>> ---
>>  Documentation/ABI/testing/sysfs-gpio |  1 +
>>  Documentation/gpio/sysfs.txt |  3 +++
>>  drivers/gpio/gpiolib-sysfs.c | 10 ++
>>  3 files changed, 14 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-gpio 
>> b/Documentation/ABI/testing/sysfs-gpio
>> index 55ffa2df1c10..53d78abef4f3 100644
>> --- a/Documentation/ABI/testing/sysfs-gpio
>> +++ b/Documentation/ABI/testing/sysfs-gpio
>> @@ -21,6 +21,7 @@ Description:
>> /value ... always readable, writes fail for input GPIOs
>> /direction ... r/w as: in, out (default low); write: high, low
>> /edge ... r/w as: none, falling, rising, both
>> +   /id ... r only, GPIO number
>> /gpiochipN ... for each gpiochip; #N is its first GPIO
>> /base ... (r/o) same as N
>> /label ... (r/o) descriptive, not necessarily unique
>> diff --git a/Documentation/gpio/sysfs.txt b/Documentation/gpio/sysfs.txt
>> index aeab01aa4d00..68e1b16e747b 100644
>> --- a/Documentation/gpio/sysfs.txt
>> +++ b/Documentation/gpio/sysfs.txt
>> @@ -96,6 +96,9 @@ and have the following read/write attributes:
>> for "rising" and "falling" edges will follow this
>> setting.
>>
>> +   "id" ... ID used for export/unxexport the GPIO. This value may
>> +   be used by named GPIOs, to find out their numerical id.
>> +
>>  GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the
>>  controller implementing GPIOs starting at #42) and have the following
>>  read-only attributes:
>> diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
>> index b57ed8e55ab5..3fc5c7231aae 100644
>> --- a/drivers/gpio/gpiolib-sysfs.c
>> +++ b/drivers/gpio/gpiolib-sysfs.c
>> @@ -350,6 +350,15 @@ static ssize_t active_low_store(struct device *dev,
>>  }
>>  static DEVICE_ATTR_RW(active_low);
>>
>> +static ssize_t id_show(struct device *dev,
>> +   struct device_attribute *attr, char *buf)
>> +{
>> +   struct gpiod_data *data = dev_get_drvdata(dev);
>> +
>> +   return  sprintf(buf, "%d\n", desc_to_gpio(data->desc));
>> +}
>> +static DEVICE_ATTR_RO(id);
>> +
>>  static umode_t gpio_is_visible(struct kobject *kobj, struct attribute *attr,
>>int n)
>>  {
>> @@ -377,6 +386,7 @@ static struct attribute *gpio_attrs[] = {
>> &dev_attr_edge.attr,
>> &dev_attr_value.attr,
>> &dev_attr_active_low.attr,
>> +   &dev_attr_id.attr,
>> NULL,
>>  };
>>
>> --
>> 2.6.4
>>
>
>
>
> --
> Ricardo Ribalda

Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset

[Paul Walmsley]

On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:

> Paul, what do you think is the best way forward to perform reset?

Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
Those often need special reset handling to ensure that WFI/HLT-like 
instructions are executed after reset.  This special handling ensures that 
the IP blocks' bus initiator interfaces indicate that they are in standby 
to the PRCM - thus allowing power management for the rest of the chip to 
work correctly.

But that doesn't seem to be the case with PCIe - and maybe others - 
possibly some of the MMUs?  So how about just creating a new hwmod flag to 
mark all of the initiator IP blocks that require driver-based special 
handling during _enable() - i.e., most of the processor IP blocks. Then 
for the rest, like PCIe, implement a default behavior in the hwmod code to 
automatically release the IP block's hardreset lines in 
omap_hwmod.c:_enable()?  Something similar to what's enclosed at the 
bottom of this message.  I've annotated what will be needed in the 
OMAP44xx file; similar flags will be needed in any other hwmod data file 
that contains IP blocks with hard reset lines defined.

Either that - or you could write custom reset handlers for all of the 
processor IP blocks that put them into WFI/HLT.

I leave it to you TI folks to write and test the actual patches, since as 
you probably know, I don't have any DRA7xx/AM57xx boards in the testbed.  

As far as reasserting hardreset in *remove(), there's already hwmod code 
to do that in omap_hwmod.c:_shutdown().  I don't recall any more if we 
currently have code in the stack that calls it.  Ideally the device model 
code should call that during or after a .remove() call.


- Paul


---
 arch/arm/mach-omap2/omap_hwmod.c   | 16 +++-
 arch/arm/mach-omap2/omap_hwmod.h   | 12 
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  6 ++
 3 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e9f65fec55c0..ab66dd988709 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2077,7 +2077,7 @@ static int _enable_preprogram(struct omap_hwmod *oh)
  */
 static int _enable(struct omap_hwmod *oh)
 {
-   int r;
+   int r, i;
int hwsup = 0;
 
pr_debug("omap_hwmod: %s: enabling\n", oh->name);
@@ -2109,17 +2109,23 @@ static int _enable(struct omap_hwmod *oh)
}
 
/*
-* If an IP block contains HW reset lines and all of them are
-* asserted, we let integration code associated with that
-* block handle the enable.  We've received very little
+* If an IP block contains HW reset lines, all of them are
+* asserted, and the IP block is marked as requiring a custom
+* hardreset handler, we let integration code associated with
+* that block handle the enable.  We've received very little
 * information on what those driver authors need, and until
 * detailed information is provided and the driver code is
 * posted to the public lists, this is probably the best we
 * can do.
 */
-   if (_are_all_hardreset_lines_asserted(oh))
+   if ((oh->flags & HWMOD_CUSTOM_HARDRESET) &&
+   _are_all_hardreset_lines_asserted(oh))
return 0;
 
+   /* If the IP block is an initiator, release it from hardreset */
+   for (i = 0; i < oh->rst_lines_cnt; i++)
+   _deassert_hardreset(oh, oh->rst_lines[i].name);
+
/* Mux pins for device runtime if populated */
if (oh->mux && (!oh->mux->enabled ||
((oh->_state == _HWMOD_STATE_IDLE) &&
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 76bce11c85a4..4198829551a4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -525,6 +525,17 @@ struct omap_hwmod_omap4_prcm {
  * or idled.
  * HWMOD_OPT_CLKS_NEEDED: The optional clocks are needed for the module to
  * operate and they need to be handled at the same time as the main_clk.
+ * HWMOD_CUSTOM_HARDRESET: By default, if a hwmod has PRCM hardreset
+ * lines associated with it (i.e., a populated .rst_lines field in
+ * the hwmod), the hwmod code will assert the hardreset lines when
+ * the IP block is initially reset, deassert the hardreset lines
+ * in _enable(), and reassert them in _shutdown().  If this flag
+ * is set, the hwmod code will not deassert the hardreset lines in
+ * _enable(), leaving this responsibility to the driver code.  This flag 
may
+ * be needed for processor IP blocks that must be put into a WFI/HLT
+ * state after reset is deasserted, lest the processor leave its MSTANDBY
+ * signal deasserted, thus blocking the chip from entering a system-wide
+ * low power state.
  */
 #define HWMOD_SWSUP_SIDLE

Quick Loans

[Financial Service]

Apply for a loan at 3% reply to this Email for more Info

Re: [PATCH] staging: drop kbuild workaround dummy module from top dir

[Greg Kroah-Hartman]

On Wed, Dec 09, 2015 at 04:06:10PM -0500, Paul Gortmaker wrote:
> [Re: [PATCH] staging: drop kbuild workaround dummy module from top dir] On 
> 18/11/2015 (Wed 09:53) Greg Kroah-Hartman wrote:
> 
> > On Wed, Nov 18, 2015 at 06:45:11PM +0100, Michal Marek wrote:
> > > Dne 17.11.2015 v 01:58 Paul Gortmaker napsal(a):
> > > > This is essentially a revert of 86f69fe9c069dd8608d238581eea259caa1dfc99
> > > > ("Staging: workaround build system bug"), but to call it a revert would
> > > > imply it was wrong -- rather it seems more like it is just no longer
> > > > required anymore.
> > > 
> > > Acked-by: Michal Marek 
> > > 
> > > In fact, I can't even reproduce the original bug with 2.6.27 + the
> > > initial staging series. I also do not remember any fix for such bug in
> > > the recent years. 4b024242e8a4 ("kbuild: Fix linking error built-in.o no
> > > such file or directory") is related, but fixing a different problem.
> > 
> > I can't remember the issue at the moment either, but it was a problem
> > with some sort of config, I'll queue this up and see if anything breaks
> > :)
> 
> Did you detect any fallout?  Just wondering since I didn't see it loop
> around in linux-next via staging #staging-next yet...

Sorry, it now just got applied, got way behind on patches :(

Re: [PATCH] Staging: comedi: fix more characters coding style issue in comedi_pcmcia.h

[Kroah-Hartman]

On Thu, Jan 14, 2016 at 09:46:57PM +0800, YU Bo wrote:
> This is a patch to the comedi_pcmcia.h file that fixes up a "line over
> 80 characters" warning  found by the checkpatch.pl tool
> 
> Signed-off-by: YU Bo 
> ---
>  drivers/staging/comedi/comedi_pcmcia.h |3 ++-
>  1 个文件被修改，插入 2 行(+)，删除 1 行(-)
> 
> diff --git a/drivers/staging/comedi/comedi_pcmcia.h 
> b/drivers/staging/comedi/comedi_pcmcia.h
> index 5d3db2b..3d076e7 100644
> --- a/drivers/staging/comedi/comedi_pcmcia.h
> +++ b/drivers/staging/comedi/comedi_pcmcia.h
> @@ -39,7 +39,8 @@ void comedi_pcmcia_driver_unregister(struct comedi_driver *,
>struct pcmcia_driver *);
> 
>  /**
> - * module_comedi_pcmcia_driver() - Helper macro for registering a comedi 
> PCMCIA driver
> + * module_comedi_pcmcia_driver() - Helper
> + * macro for registering a comedi PCMCIA driver
>   * @__comedi_driver: comedi_driver struct
>   * @__pcmcia_driver: pcmcia_driver struct
>   *
> --
> 1.7.10.4
> 

Also did not apply :(

Re: [PATCH] Staging: comedi.h: Fix coding style issue in comedi.h

[Kroah-Hartman]

On Thu, Jan 14, 2016 at 11:06:25PM +0800, YU Bo wrote:
> This is a patch to the comedi.h file that fixes up warnings found by the
> checkpatch.pl tool
> 
> Signed-off-by: YU Bo 
> ---
>  drivers/staging/comedi/comedi.h |  260 
> +++
>  1 个文件被修改，插入 154 行(+)，删除 106 行(-)

This didn't apply either :(

Re: [PATCH] Staging: comedi: fix coding style issue in comedilib.h

[Greg KH]

On Thu, Jan 14, 2016 at 09:40:14AM +0800, Bo YU wrote:
> This is a patch to the comedilib.h file that fixes "bloch comment use
> * on subsequent lines" warning found by the checkpatch.pl tool
> 
> Signed-off-by: YU Bo 
> ---
>   drivers/staging/comedi/comedilib.h |   32 
>   1 个文件被修改，插入 16 行(+)，删除 16 行(-)

Did not apply to my tree :(

Re: [PATCH v2 0/2] Staging: goldfish: Checkpatch cleanups

[Greg Kroah-Hartman]

On Thu, Jan 07, 2016 at 11:08:36PM +0530, Shraddha Barke wrote:
> These patches remove the last few checkpatch warnings in staging/goldfish 
> directory
> 
> Shraddha Barke (2):
>   Staging: goldfish: Add space around +
>   Staging: goldfish: Remove explicit NULL comparison
> 
>  drivers/staging/goldfish/goldfish_audio.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Someone else did these changes before you did, sorry.

greg k-h

Re: [PATCH] staging: goldfish: Coding Style Fix Comparison to NULL could be written "!r"

[Greg KH]

On Fri, Dec 11, 2015 at 04:39:26PM -0500, Benjamin Young wrote:
> Fixed coding style for null comparisons in goldfish_audio.c to be more 
> consistant
> with the rest of the kernel coding style
> 
> Signed-off-by: Benjamin Young 
> ---
>  drivers/staging/goldfish/goldfish_audio.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/goldfish/goldfish_audio.c 
> b/drivers/staging/goldfish/goldfish_audio.c
> index f1e1838..364fdcd 100644
> --- a/drivers/staging/goldfish/goldfish_audio.c
> +++ b/drivers/staging/goldfish/goldfish_audio.c
> @@ -280,12 +280,12 @@ static int goldfish_audio_probe(struct platform_device 
> *pdev)
>   platform_set_drvdata(pdev, data);
>  
>   r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (r == NULL) {
> + if (!r) {
>   dev_err(&pdev->dev, "platform_get_resource failed\n");
>   return -ENODEV;
>   }
>   data->reg_base = devm_ioremap(&pdev->dev, r->start, PAGE_SIZE);
> - if (data->reg_base == NULL)
> + if (!data->reg_base)
>   return -ENOMEM;
>  
>   data->irq = platform_get_irq(pdev, 0);
> @@ -295,7 +295,7 @@ static int goldfish_audio_probe(struct platform_device 
> *pdev)
>   }
>   data->buffer_virt = dmam_alloc_coherent(&pdev->dev,
>   COMBINED_BUFFER_SIZE, &buf_addr, GFP_KERNEL);
> - if (data->buffer_virt == NULL) {
> + if (!data->buffer_virt) {
>   dev_err(&pdev->dev, "allocate buffer failed\n");
>   return -ENOMEM;
>   }

Same here, someone beat you to it.

Re: [PATCH] staging: goldfish: Coding Style Fix - spaces preferred around that '+'

[Greg KH]

On Fri, Dec 11, 2015 at 04:38:59PM -0500, Benjamin Young wrote:
> Helped improve coding style to make arithemethic easier to read
> 
> Signed-off-by: Benjamin Young 
> ---
>  drivers/staging/goldfish/goldfish_audio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/goldfish/goldfish_audio.c 
> b/drivers/staging/goldfish/goldfish_audio.c
> index b0927e4..f1e1838 100644
> --- a/drivers/staging/goldfish/goldfish_audio.c
> +++ b/drivers/staging/goldfish/goldfish_audio.c
> @@ -63,7 +63,7 @@ struct goldfish_audio {
>  #define AUDIO_READ(data, addr)   (readl(data->reg_base + addr))
>  #define AUDIO_WRITE(data, addr, x)   (writel(x, data->reg_base + addr))
>  #define AUDIO_WRITE64(data, addr, addr2, x)  \
> - (gf_write_dma_addr((x), data->reg_base + addr, data->reg_base+addr2))
> + (gf_write_dma_addr((x), data->reg_base + addr, data->reg_base + addr2))
>  
>  /*
>   *  temporary variable used between goldfish_audio_probe() and

Someone else sent this before you did, sorry.

thanks,

greg k-h