Re: [Linux 4.2-rc8+...v4.3-rc2] REGRESSION: ppp: circular locking dependency detected: [pppd] ppp_dev_uninit() | rtnl_lock()
On Thu, Sep 24, 2015 at 8:00 PM, David Miller wrote: > From: Sedat Dilek > Date: Thu, 24 Sep 2015 18:19:16 +0200 > >> OK, I guess DaveM will take your patch into net.git#master first... >> and tag it there with CC-stable? > > I do not tag anything with stable. > > I queue it up into a patchwork bundle and explicitly submit those > patches to sta...@vger.kernel.org at a time of my own choosing. > > This is a FAQ, documented in the kernel Documentation/ subdirectory. OK, so this is a special handling for netdev? I normally look at "SubmittingPatches" documentation [1] and looked in this case especially at [2]. Can you point me to this "FAQ"? Where do you include Guillaume's patch - in net.git#master? Since Linux v4.2 my Internet connection via UMTS/HSPA USB modem is "unstable". For me this is an important fix. Thanks. - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n297 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] zbud: allow up to PAGE_SIZE allocations
>From e219a88f4cd68842e7e04e37461aba6e06555d6a Mon Sep 17 00:00:00 2001
From: Vitaly Vul
Date: Tue, 22 Sep 2015 14:07:01 +0200
Subject: [PATCH] zbud: allow up to PAGE_SIZE allocations
Currently zbud is only capable of allocating not more than
PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE. This is okay as
long as only zswap is using it, but other users of zbud may
(and likely will) want to allocate up to PAGE_SIZE. This patch
addresses that by skipping the creation of zbud internal
structure in the beginning of an allocated page. As a zbud page
is no longer guaranteed to contain zbud header, the following
changes have to be applied throughout the code:
* page->lru to be used for zbud page lists
* page->private to hold 'under_reclaim' flag
page->private will also be used to indicate if this page contains
a zbud header in the beginning or not ('headless' flag).
This patch incorporates minor fixups after Seth's comments.
Signed-off-by: Vitaly Wool
---
mm/zbud.c | 168 ++
1 file changed, 114 insertions(+), 54 deletions(-)
diff --git a/mm/zbud.c b/mm/zbud.c
index fa48bcdf..619beba 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -105,18 +105,20 @@ struct zbud_pool {
/*
* struct zbud_header - zbud page metadata occupying the first chunk of each
- * zbud page.
+ * zbud page, except for HEADLESS pages
* @buddy: links the zbud page into the unbuddied/buddied lists in the pool
- * @lru: links the zbud page into the lru list in the pool
* @first_chunks: the size of the first buddy in chunks, 0 if free
* @last_chunks: the size of the last buddy in chunks, 0 if free
*/
struct zbud_header {
struct list_head buddy;
- struct list_head lru;
unsigned int first_chunks;
unsigned int last_chunks;
- bool under_reclaim;
+};
+
+enum zbud_page_flags {
+ ZPF_UNDER_RECLAIM,
+ ZPF_HEADLESS,
};
/*
@@ -221,6 +223,7 @@ MODULE_ALIAS("zpool-zbud");
*/
/* Just to make the code easier to read */
enum buddy {
+ HEADLESS,
FIRST,
LAST
};
@@ -238,18 +241,26 @@ static int size_to_chunks(size_t size)
static struct zbud_header *init_zbud_page(struct page *page)
{
struct zbud_header *zhdr = page_address(page);
+
+ INIT_LIST_HEAD(>lru);
+ page->private = 0;
+
zhdr->first_chunks = 0;
zhdr->last_chunks = 0;
INIT_LIST_HEAD(>buddy);
- INIT_LIST_HEAD(>lru);
- zhdr->under_reclaim = 0;
return zhdr;
}
/* Resets the struct page fields and frees the page */
static void free_zbud_page(struct zbud_header *zhdr)
{
- __free_page(virt_to_page(zhdr));
+ struct page *page = virt_to_page(zhdr);
+
+ /* do some cleanup */
+ INIT_LIST_HEAD(>lru);
+ page->private = 0;
+
+ __free_page(page);
}
/*
@@ -267,11 +278,17 @@ static unsigned long encode_handle(struct zbud_header
*zhdr, enum buddy bud)
* over the zbud header in the first chunk.
*/
handle = (unsigned long)zhdr;
- if (bud == FIRST)
+ switch (bud) {
+ case FIRST:
/* skip over zbud header */
handle += ZHDR_SIZE_ALIGNED;
- else /* bud == LAST */
+ break;
+ case LAST:
handle += PAGE_SIZE - (zhdr->last_chunks << CHUNK_SHIFT);
+ break;
+ case HEADLESS:
+ break;
+ }
return handle;
}
@@ -287,6 +304,7 @@ static int num_free_chunks(struct zbud_header *zhdr)
/*
* Rather than branch for different situations, just use the fact that
* free buddies have a length of zero to simplify everything.
+* NB: can't be used with HEADLESS pages.
*/
return NCHUNKS - zhdr->first_chunks - zhdr->last_chunks;
}
@@ -360,24 +378,33 @@ int zbud_alloc(struct zbud_pool *pool, size_t size, gfp_t
gfp,
if (!size || (gfp & __GFP_HIGHMEM))
return -EINVAL;
- if (size > PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE)
+
+ if (size > PAGE_SIZE)
return -ENOSPC;
- chunks = size_to_chunks(size);
- spin_lock(>lock);
- /* First, try to find an unbuddied zbud page. */
- zhdr = NULL;
- for_each_unbuddied_list(i, chunks) {
- if (!list_empty(>unbuddied[i])) {
- zhdr = list_first_entry(>unbuddied[i],
- struct zbud_header, buddy);
- list_del(>buddy);
- if (zhdr->first_chunks == 0)
- bud = FIRST;
- else
- bud = LAST;
- goto found;
+ if (size > PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE) {
+ chunks = 0;
+ bud = HEADLESS;
+ } else {
+ chunks =
Re: [PATCH v2] zbud: allow up to PAGE_SIZE allocations
Hello Seth,
On Thu, Sep 24, 2015 at 12:41 AM, Seth Jennings
wrote:
> On Wed, Sep 23, 2015 at 10:59:00PM +0200, Vitaly Wool wrote:
>> Okay, how about this? It's gotten smaller BTW :)
>>
>> zbud: allow up to PAGE_SIZE allocations
>>
>> Currently zbud is only capable of allocating not more than
>> PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE. This is okay as
>> long as only zswap is using it, but other users of zbud may
>> (and likely will) want to allocate up to PAGE_SIZE. This patch
>> addresses that by skipping the creation of zbud internal
>> structure in the beginning of an allocated page. As a zbud page
>> is no longer guaranteed to contain zbud header, the following
>> changes have to be applied throughout the code:
>> * page->lru to be used for zbud page lists
>> * page->private to hold 'under_reclaim' flag
>>
>> page->private will also be used to indicate if this page contains
>> a zbud header in the beginning or not ('headless' flag).
>>
>> Signed-off-by: Vitaly Wool
>> ---
>> mm/zbud.c | 167
>> ++
>> 1 file changed, 113 insertions(+), 54 deletions(-)
>>
>> diff --git a/mm/zbud.c b/mm/zbud.c
>> index fa48bcdf..3946fba 100644
>> --- a/mm/zbud.c
>> +++ b/mm/zbud.c
>> @@ -105,18 +105,20 @@ struct zbud_pool {
>>
>> /*
>> * struct zbud_header - zbud page metadata occupying the first chunk of each
>> - * zbud page.
>> + * zbud page, except for HEADLESS pages
>> * @buddy: links the zbud page into the unbuddied/buddied lists in the
>> pool
>> - * @lru: links the zbud page into the lru list in the pool
>> * @first_chunks:the size of the first buddy in chunks, 0 if free
>> * @last_chunks: the size of the last buddy in chunks, 0 if free
>> */
>> struct zbud_header {
>> struct list_head buddy;
>> - struct list_head lru;
>> unsigned int first_chunks;
>> unsigned int last_chunks;
>> - bool under_reclaim;
>> +};
>> +
>> +enum zbud_page_flags {
>> + UNDER_RECLAIM = 0,
>
> Don't need the "= 0"
>
>> + PAGE_HEADLESS,
>
> Also I think we should prefix the enum values here. With ZPF_ ?
>
>> };
>>
>> /*
>> @@ -221,6 +223,7 @@ MODULE_ALIAS("zpool-zbud");
>> */
>> /* Just to make the code easier to read */
>> enum buddy {
>> + HEADLESS,
>> FIRST,
>> LAST
>> };
>> @@ -238,11 +241,14 @@ static int size_to_chunks(size_t size)
>> static struct zbud_header *init_zbud_page(struct page *page)
>> {
>> struct zbud_header *zhdr = page_address(page);
>> +
>> + INIT_LIST_HEAD(>lru);
>> + clear_bit(UNDER_RECLAIM, >private);
>> + clear_bit(HEADLESS, >private);
>
> I know we are using private in a bitwise flags mode, but maybe we
> should just init with page->private = 0
>
>> +
>> zhdr->first_chunks = 0;
>> zhdr->last_chunks = 0;
>> INIT_LIST_HEAD(>buddy);
>> - INIT_LIST_HEAD(>lru);
>> - zhdr->under_reclaim = 0;
>> return zhdr;
>> }
>>
>> @@ -267,11 +273,22 @@ static unsigned long encode_handle(struct zbud_header
>> *zhdr, enum buddy bud)
>>* over the zbud header in the first chunk.
>>*/
>> handle = (unsigned long)zhdr;
>> - if (bud == FIRST)
>> + switch (bud) {
>> + case FIRST:
>> /* skip over zbud header */
>> handle += ZHDR_SIZE_ALIGNED;
>> - else /* bud == LAST */
>> + break;
>> + case LAST:
>> handle += PAGE_SIZE - (zhdr->last_chunks << CHUNK_SHIFT);
>> + break;
>> + case HEADLESS:
>> + break;
>> + default:
>> + /* this should never happen */
>> + pr_err("zbud: invalid buddy value %d\n", bud);
>> + handle = 0;
>> + break;
>> + }
>
> Don't need this default case since we have a case for each valid value
> of the enum.
>
> Also, I think we want to add some code to free_zbud_page() to clear
> page->private and init page->lru so we don't leave dangling pointers.
Right, maybe it makes sense for free_zbud_page() to take struct page
pointer as an argument, too, to minimize back-and-forth conversions?
> Looks good though :)
Thanks, I'll come up with the new version shortly. :)
~vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ibm/emac: bump version numbers for correct work with ethtool
From: Ivan Mikhaylov Date: Fri, 25 Sep 2015 08:07:52 +0400 > Ben proposed one, is it eligible? > Need I resubmit patch with sign and detailed description? If I genuinely need to answer that question, maybe you should sit back for a little while and think about it yourself, ok? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v10 3/5] CPM/QE: use genalloc to manage CPM/QE muram
On Fri, Sep 25, 2015 at 1:08 PM +0800, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, September 25, 2015 1:08 PM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH v10 3/5] CPM/QE: use genalloc to manage CPM/QE muram
>
> On Thu, 2015-09-24 at 21:50 -0500, Zhao Qiang-B45475 wrote:
> > On Fri, Sep 25, 2015 at 7:30 AM +0800, Wood Scott-B07421 wrote:
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, September 25, 2015 7:30 AM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > Li Yang-Leo-R58472; pau...@samba.org
> > > Subject: Re: [PATCH v10 3/5] CPM/QE: use genalloc to manage CPM/QE
> > > muram
> > >
> > > On Wed, 2015-09-23 at 00:28 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wen, Sep 23, 2015 at 12:03 AM +0800, Wood Scott-B07421 wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 23, 2015 12:03 PM
> > > > > To: Zhao Qiang-B45475
> > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > > lau...@codeaurora.org; Xie Xiaobo-R63061;
> > > > > b...@kernel.crashing.org; Li Yang-Leo-R58472; pau...@samba.org
> > > > > Subject: Re: [PATCH v10 3/5] CPM/QE: use genalloc to manage
> > > > > CPM/QE muram
> > > > >
> > > > > On Tue, 2015-09-22 at 21:20 -0500, Zhao Qiang-B45475 wrote:
> > > > > > On Wen, Sep 23, 2015 at 8:19 AM +0800, Wood Scott-B07421 wrote:
> > > > > >
> > > > > > > > > > {
> > > > > > > > > > - int ret;
> > > > > > > > > > +
> > > > > > > > > > + unsigned long start;
> > > > > > > > > > unsigned long flags;
> > > > > > > > > > + unsigned long size_alloc = size; struct muram_block
> > > > > > > > > > + *entry; int end_bit; int order =
> > > > > > > > > > + muram_pool->min_alloc_order;
> > > > > > > > > >
> > > > > > > > > > spin_lock_irqsave(_muram_lock, flags);
> > > > > > > > > > - ret = rh_free(_muram_info, offset);
> > > > > > > > > > + end_bit = (offset >> order) + ((size + (1UL <<
> > > > > > > > > > + order) -
> > > > > > > > > > + 1)
> > > > > > > > > > + >>
> > > > > > > > > order);
> > > > > > > > > > + if ((offset + size) > (end_bit << order))
> > > > > > > > > > + size_alloc = size + (1UL << order);
> > > > > > > > >
> > > > > > > > > Why do you need to do all these calculations here?
> > > > > > > >
> > > > > > > > So do it in gen_pool_fixed_alloc?
> > > > > > >
> > > > > > > Could you explain why they're needed at all?
> > > > > >
> > > > > > Why it does the calculations?
> > > > > > If the min block of gen_pool is 8 bytes, and I want to
> > > > > > allocate a Region with offset=7, size=8bytes, I actually need
> > > > > > block 0 and block 1, And the allocation will give me block 0.
> > > > >
> > > > > How can you have offset 7 if the minimum order is 2 bytes?
> > > >
> > > > Offset has no relationship with minimum order, it is not decided
> > > > by minimum order.
> > >
> > > All allocations begin and end on a multiple of the minimum order.
> >
> > So it is the problem. CPM require to allocate a specific region, who
> > can ensure that the specific is just the begin of minimum order.
>
> Do you have any reason to believe that there is any caller of this
> function with an odd address?
>
> If so, set the minimum order to zero. If not, what is the problem?
Setting minimum order to zero is ok.
-Zhao
Re: [PATCH v3 9/9] zram: use crypto decompress_noctx API
On Mon, Sep 21, 2015 at 02:29:18PM +0900, Sergey Senozhatsky wrote:
> On (09/18/15 14:19), Joonsoo Kim wrote:
> > -/* Never return NULL, may sleep */
> > +/* May return NULL, may sleep */
> > struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp)
> > {
> > + if (comp->tfm_noctx)
> > + return NULL;
> > +
> > return zcomp_strm_find(comp);
> > }
> >
> > @@ -346,11 +349,18 @@ int zcomp_decompress(struct zcomp *comp, struct
> > zcomp_strm *zstrm,
> > {
> > unsigned int size = PAGE_SIZE;
> >
> > + if (!zstrm) {
> > + return crypto_comp_decompress_noctx(comp->tfm_noctx,
> > + src, src_len, dst, );
> > + }
>
> unneeded braces.
It's more readable for me. But, if you don't like it, I will remove brace.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
On Thu, 2015-09-24 at 23:38 +0800, Yingjoe Chen wrote:
> Add arch timer node to enable arch-timer support. MT8135 firmware
> doesn't correctly setup arch-timer frequency and CNTVOFF, add
> properties to workaround this.
>
> This also set cpu enable-method to enable SMP.
>
> Signed-off-by: Yingjoe Chen
> ---
> arch/arm/boot/dts/mt8135.dtsi | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt8135.dtsi b/arch/arm/boot/dts/mt8135.dtsi
> index 08371db..c3c90f2 100644
> --- a/arch/arm/boot/dts/mt8135.dtsi
> +++ b/arch/arm/boot/dts/mt8135.dtsi
> @@ -46,6 +46,7 @@
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> + enable-method = "mediatek,mt81xx-tz-smp";
>
> cpu0: cpu@0 {
> device_type = "cpu";
> @@ -72,6 +73,17 @@
> };
> };
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + trustzone-bootinfo: trustzone-bootinfo@80002000 {
Sorry, this should be
+ trustzone-bootinfo@80002000 {
I'll fix this in next version.
Joe.C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 9/9] zram: use crypto decompress_noctx API
On Mon, Sep 21, 2015 at 04:56:00PM +0900, Sergey Senozhatsky wrote: > On (09/18/15 14:19), Joonsoo Kim wrote: > [..] > > + /* > > +* Prepare to use crypto decompress_noctx API. One tfm is required > > +* to initialize crypto algorithm properly and fetch corresponding > > +* function pointer. But, it is sharable for multiple concurrent > > +* decompress users. > > +*/ > > if comp algorithm require zstrm for both compression and decompression, > then there seems to be no need in allocating sharable ->tfm_noctx, we > will never use it. > Yes, in that case, NULL will be returned. I should describe it on somewhere. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 9/9] zram: use crypto decompress_noctx API
On Mon, Sep 21, 2015 at 12:51:28PM +0900, Minchan Kim wrote:
> On Fri, Sep 18, 2015 at 02:19:24PM +0900, Joonsoo Kim wrote:
> > Crypto subsystem now supports decompress_noctx API that requires
> > special tfm_noctx. This tfm can be shared by multiple concurrent
> > decompress user because this API doesn't rely on this tfm object
> > except to fetch decompress function pointer.
> >
> > Until changing to use crypto API, zram doesn't require any zstrm
> > on decompress so decompress is parallelized unlimitedly. But, previous
> > patch make zram to use crypto API and this requires one zstrm on every
> > decompress users so, in some zstrm contended situations, zram's
> > performance would be degraded.
> >
> > This patch makes zram use decompress_noctx API and restore zram's
> > performance as the time that zram doesn't use crypto API.
> >
> > Following is zram's read performance number.
> >
> > * iozone -t 4 -R -r 16K -s 60M -I +Z -i 0 -i 1
> > * max_stream is set to 1
> > * Output is in Kbytes/sec
> >
> > zram-base vs zram-crypto vs zram-crypto-noctx
> >
> > Read10411701.88 6426911.62 9423894.38
> > Re-read 10017386.62 6428218.88 1163.50
> >
> > Signed-off-by: Joonsoo Kim
> > ---
> > drivers/block/zram/zcomp.c | 24 +++-
> > drivers/block/zram/zcomp.h | 1 +
> > 2 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> > index c2ed7c8..a020200 100644
> > --- a/drivers/block/zram/zcomp.c
> > +++ b/drivers/block/zram/zcomp.c
> > @@ -319,9 +319,12 @@ void zcomp_compress_end(struct zcomp *comp, struct
> > zcomp_strm *zstrm)
> > zcomp_strm_release(comp, zstrm);
> > }
> >
> > -/* Never return NULL, may sleep */
> > +/* May return NULL, may sleep */
> > struct zcomp_strm *zcomp_decompress_begin(struct zcomp *comp)
> > {
> > + if (comp->tfm_noctx)
> > + return NULL;
>
> Hmm,, I understand why returns NULL but it seems to be awkward to use NULL
> to express meaningful semantic and following functions relies on.
> If I have a time, I will think over.
I also think that it's not good thing but I can't think any better
idea. Please let me know if you have better one.
>
> > +
> > return zcomp_strm_find(comp);
> > }
> >
> > @@ -346,11 +349,18 @@ int zcomp_decompress(struct zcomp *comp, struct
> > zcomp_strm *zstrm,
> > {
> > unsigned int size = PAGE_SIZE;
> >
> > + if (!zstrm) {
> > + return crypto_comp_decompress_noctx(comp->tfm_noctx,
> > + src, src_len, dst, );
> > + }
> > +
> > return crypto_comp_decompress(zstrm->tfm, src, src_len, dst, );
> > }
> >
> > void zcomp_destroy(struct zcomp *comp)
> > {
> > + if (comp->tfm_noctx)
> > + crypto_free_comp_noctx(comp->tfm_noctx);
> > comp->destroy(comp);
> > kfree(comp);
> > }
> > @@ -366,6 +376,7 @@ struct zcomp *zcomp_create(const char *compress, int
> > max_strm)
> > {
> > struct zcomp *comp;
> > const char *backend;
> > + struct crypto_comp *tfm;
> >
> > backend = find_backend(compress);
> > if (!backend)
> > @@ -384,5 +395,16 @@ struct zcomp *zcomp_create(const char *compress, int
> > max_strm)
> > kfree(comp);
> > return ERR_PTR(-ENOMEM);
> > }
> > +
> > + /*
> > +* Prepare to use crypto decompress_noctx API. One tfm is required
> > +* to initialize crypto algorithm properly and fetch corresponding
> > +* function pointer. But, it is sharable for multiple concurrent
> > +* decompress users.
> > +*/
>
> Please comment out that this API will return NULL if the compressor doesn't
> support noctx mode.
Will do.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 8/9] zram: use crypto API for compression
On Mon, Sep 21, 2015 at 12:45:12PM +0900, Minchan Kim wrote: > Hi Joonsoo, > > On Fri, Sep 18, 2015 at 02:19:23PM +0900, Joonsoo Kim wrote: > > Until now, zram uses compression algorithm through direct call > > to core algorithm function, but, it has drawback that we need to add > > compression algorithm manually to zram if needed. Without this work, > > we cannot utilize various compression algorithms in the system. > > Moreover, to add new compression algorithm, we need to know how to use it > > and this is somewhat time-consuming. > > > > When I tested new algorithms such as zlib, these problems make me hard > > to test them. To prevent these problem in the future, I think that > > using crypto API for compression is better approach and this patch > > implements it. > > > > The reason we need to support vairous compression algorithms is that > > zram's performance is highly depend on workload and compression algorithm > > and architecture. Every compression algorithm has it's own strong point. > > For example, zlib is the best for compression ratio, but, it's > > (de)compression speed is rather slow. Against my expectation, in my kernel > > build test with zram swap, in low-memory condition on x86, zlib shows best > > performance than others. In this case, I guess that compression ratio is > > the most important factor. Unlike this situation, on ARM, maybe fast > > (de)compression speed is the most important because it's computation speed > > is slower than x86. > > > > We can't expect what algorithm is the best fit for one's system, because > > it needs too complex calculation. We need to test it in case by case and > > easy to use new compression algorithm by this patch will help > > that situation. > > > > There is one problem that crypto API requires tfm object to (de)compress > > something and zram abstract it on zstrm which is very limited resource. > > If number of zstrm is set to low and is contended, zram's performace could > > be down-graded due to this change. But, following patch support to use > > crypto decompress_noctx API and would restore the performance as is. > > > > Signed-off-by: Joonsoo Kim > > --- > > drivers/block/zram/Kconfig | 8 +++ > > drivers/block/zram/Makefile| 4 +--- > > drivers/block/zram/zcomp.c | 54 > > +++--- > > drivers/block/zram/zcomp.h | 30 ++- > > drivers/block/zram/zcomp_lz4.c | 47 > > drivers/block/zram/zcomp_lz4.h | 17 - > > drivers/block/zram/zcomp_lzo.c | 47 > > drivers/block/zram/zcomp_lzo.h | 17 - > > drivers/block/zram/zram_drv.c | 6 ++--- > > 9 files changed, 44 insertions(+), 186 deletions(-) > > delete mode 100644 drivers/block/zram/zcomp_lz4.c > > delete mode 100644 drivers/block/zram/zcomp_lz4.h > > delete mode 100644 drivers/block/zram/zcomp_lzo.c > > delete mode 100644 drivers/block/zram/zcomp_lzo.h > > > > diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig > > index 386ba3d..7619bed 100644 > > --- a/drivers/block/zram/Kconfig > > +++ b/drivers/block/zram/Kconfig > > @@ -1,8 +1,7 @@ > > config ZRAM > > tristate "Compressed RAM block device support" > > depends on BLOCK && SYSFS && ZSMALLOC > > - select LZO_COMPRESS > > - select LZO_DECOMPRESS > > + select CRYPTO_LZO > > default n > > help > > Creates virtual block devices called /dev/zramX (X = 0, 1, ...). > > @@ -18,9 +17,8 @@ config ZRAM > > config ZRAM_LZ4_COMPRESS > > bool "Enable LZ4 algorithm support" > > depends on ZRAM > > - select LZ4_COMPRESS > > - select LZ4_DECOMPRESS > > + select CRYPTO_LZ4 > > It is out of my expectation. > > When I heard crypto support for zRAM first, I imagined zram user can > use any crypto compressor algorithm easily if system has the algorithm. > IOW, I expect zRAM shouldn't bind CONFIG_CRYPTO_ALGONAME statically > except the default one(ie, CONFIG_CRYPTO_LZO) like zswap and It seems > you did in eariler version. > > You seem to have a trouble to adapt crypto to current comp_algorithm > because crypto doesn't export any API to enumerate algorithm name > while zram should export supporting algorithm name via comp_algorithm > and I heard crypto maintainer doesn't want to export it. Instead, > user can use /proc/crypto to know what kinds of compressor system > can support. > > Hmm, > At the first glance, I was about to say "let's sort it out with > futher patches" but I changed my mind. ;-). > > We should sort it out before you are adding zlib support(ie, please > include zlib support patch with number data in this patchset). Otherwise, > we should add new hard-wired stuff for zlib like lzo, lz4 to > comp_algorithm and will depreate soon. > > My idea is ABI change of comp_algorithm. Namely, let's deprecate it > and guide to use /proc/crypto to show available compressor. > Someday, we removes backends
Re: [PATCH] pidns: fix set/getpriority and ioprio_set/get in PRIO_USER mode
bseg...@google.com writes:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
>> Andrew Morton writes:
>>
>>> On Wed, 16 Sep 2015 12:58:04 -0700 bseg...@google.com wrote:
>>>
setpriority(PRIO_USER, 0, x) will change the priority of tasks outside
of the current pid namespace. This is in contrast to both the other
modes of setpriority and the example of kill(-1). Fix this. getpriority
and ioprio have the same failure mode, fix them too.
>>>
>>> (cc Eric)
>> (cc Containers)
>>
>> Interesting. Strictly speaking the current behavior is not wrong.
>> Searching for all threads with a given uid has nothing to do with pids
>> so the pid namespace not limiting them is natural.
>>
>> In practice I don't think anyone cares either way (except people with
>> one color or another of security hat on) so this might be a change we
>> can actually make.
>>
>> In general it is probably better not to share uids and gids between
>> containers.
>>
>> Ben do you have a use case where this actually matters? Or was this a
>> case of "That looks wrong..."?
>>
>> Eric
>
> I believe we generally want this for isolation of a process, without
> requiring root initially (and a non-trivial uid_map, not to mention
> creating the extra users, requires root). There are probably other holes
> in using namespaces like this, but are they intended?
After some more thinking about it this patch sounds justifiable.
My goal with namespaces is not to build perfect isolation mechanisms
as that can get into ill defined territory, but to build well defined
mechanisms. And to handle the corner cases so you can use only
a single namespace with well defined results.
In this case you have found the two interfaces I am aware of that
identify processes by uid instead of by pid. Which quite frankly is
weird. Unfortunately the weird unexpected cases are hard to handle
in the usual way.
I was hoping for a little more information. Changes like this one we
have to be careful of because someone might be depending on the current
behavior. I don't think they are and I do think this make sense as part
of the pid namespace.
Acked-by: "Eric W. Biederman"
> (Cc the relevant team member at google)
>
>>
Signed-off-by: Ben Segall
Cc: Oleg Nesterov
Cc: Al Viro
---
block/ioprio.c | 6 --
kernel/sys.c | 4 ++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/block/ioprio.c b/block/ioprio.c
index 31666c9..cc7800e 100644
--- a/block/ioprio.c
+++ b/block/ioprio.c
@@ -123,7 +123,8 @@ SYSCALL_DEFINE3(ioprio_set, int, which, int, who, int,
ioprio)
break;
do_each_thread(g, p) {
- if (!uid_eq(task_uid(p), uid))
+ if (!uid_eq(task_uid(p), uid) ||
+ !task_pid_vnr(p))
continue;
ret = set_task_ioprio(p, ioprio);
if (ret)
@@ -220,7 +221,8 @@ SYSCALL_DEFINE2(ioprio_get, int, which, int, who)
break;
do_each_thread(g, p) {
- if (!uid_eq(task_uid(p), user->uid))
+ if (!uid_eq(task_uid(p), user->uid) ||
+ !task_pid_vnr(p))
continue;
tmpio = get_task_ioprio(p);
if (tmpio < 0)
diff --git a/kernel/sys.c b/kernel/sys.c
index fa2f2f6..6af9212 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -222,7 +222,7 @@ SYSCALL_DEFINE3(setpriority, int, which, int, who,
int, niceval)
goto out_unlock;/* No processes for
this user */
}
do_each_thread(g, p) {
- if (uid_eq(task_uid(p), uid))
+ if (uid_eq(task_uid(p), uid) && task_pid_vnr(p))
error = set_one_prio(p, niceval, error);
} while_each_thread(g, p);
if (!uid_eq(uid, cred->uid))
@@ -290,7 +290,7 @@ SYSCALL_DEFINE2(getpriority, int, which, int, who)
goto out_unlock;/* No processes for
this user */
}
do_each_thread(g, p) {
- if (uid_eq(task_uid(p), uid)) {
+ if (uid_eq(task_uid(p), uid) && task_pid_vnr(p)) {
niceval = nice_to_rlimit(task_nice(p));
if (niceval > retval)
retval = niceval;
--
2.6.0.rc0.131.gf624c3d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Re: [PATCH v3 8/9] zram: use crypto API for compression
On Mon, Sep 21, 2015 at 02:19:03PM +0900, Sergey Senozhatsky wrote:
> On (09/18/15 14:19), Joonsoo Kim wrote:
> [..]
> > -static struct zcomp_backend *find_backend(const char *compress)
> > +static const char *find_backend(const char *compress)
> > {
> > int i = 0;
> > while (backends[i]) {
> > - if (sysfs_streq(compress, backends[i]->name))
> > + if (sysfs_streq(compress, backends[i]) &&
> > + crypto_has_comp(compress, 0, 0))
>
> ok, just for note. zcomp does sysfs_streq(), because sysfs data
> usually contain a trailing new line, crypto_has_comp() does strcmp().
Okay. Will check.
>
>
> > int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
> > - const unsigned char *src, size_t *dst_len)
> > + const unsigned char *src, unsigned int *dst_len)
> > {
> > - return comp->backend->compress(src, zstrm->buffer, dst_len,
> > - zstrm->private);
> > + *dst_len = PAGE_SIZE << 1;
> > +
>
> hm... wouldn't it be better to say crypto api that we have a PAGE_SIZE
> buffer instead of PAGE_SIZE << 1, so in case of buffer overrun (or
> whatever is the correct term here) it will stop compression earlier
> (well, possibly)? zram will drop compressed data larger than PAGE_SIZE
> anyway, so if passing a smaller buffer size can save us CPU time then
> let's do it.
It can be implemented and maybe good way to go. But, in this patchset,
it isn't needed. It is better to do in separate patch.
>
> > + return crypto_comp_compress(zstrm->tfm, src, PAGE_SIZE,
> > + zstrm->buffer, dst_len);
> > }
> >
> > int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
> > const unsigned char *src,
> > - size_t src_len, unsigned char *dst)
> > + unsigned int src_len, unsigned char *dst)
> > {
> > - return comp->backend->decompress(src, src_len, dst);
> > + unsigned int size = PAGE_SIZE;
> > +
> > + return crypto_comp_decompress(zstrm->tfm, src, src_len, dst, );
>
> tab?
>
> > }
> >
> > void zcomp_destroy(struct zcomp *comp)
> > @@ -359,7 +365,7 @@ void zcomp_destroy(struct zcomp *comp)
> > struct zcomp *zcomp_create(const char *compress, int max_strm)
> > {
> > struct zcomp *comp;
> > - struct zcomp_backend *backend;
> > + const char *backend;
>
> rebase against the current linux-next. this and the next patch do not
> apply cleanly. the function was touched recently: '+int error'.
Okay.
>
> >
> > backend = find_backend(compress);
> > if (!backend)
> > diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> > index 4c09c01..4f9df8e 100644
> > --- a/drivers/block/zram/zcomp.h
> > +++ b/drivers/block/zram/zcomp.h
> > @@ -11,38 +11,22 @@
> > #define _ZCOMP_H_
> >
> > #include
> > +#include
> >
> > struct zcomp_strm {
> > + struct crypto_comp *tfm;
> > +
> > /* compression/decompression buffer */
> > void *buffer;
> > - /*
> > -* The private data of the compression stream, only compression
> > -* stream backend can touch this (e.g. compression algorithm
> > -* working memory)
> > -*/
> > - void *private;
> > +
> > /* used in multi stream backend, protected by backend strm_lock */
> > struct list_head list;
> > };
> >
> > -/* static compression backend */
> > -struct zcomp_backend {
> > - int (*compress)(const unsigned char *src, unsigned char *dst,
> > - size_t *dst_len, void *private);
> > -
> > - int (*decompress)(const unsigned char *src, size_t src_len,
> > - unsigned char *dst);
> > -
> > - void *(*create)(void);
> > - void (*destroy)(void *private);
> > -
> > - const char *name;
> > -};
> > -
> > /* dynamic per-device compression frontend */
> > struct zcomp {
> > void *stream;
> > - struct zcomp_backend *backend;
> > + const char *backend;
>
> ^^ what for?
Will remove.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Glibc recvmsg from kernel netlink socket hangs forever
Herbert, On 09/24/2015 09:58 PM, Herbert Xu wrote: On Thu, Sep 24, 2015 at 09:36:53PM -0700, Guenter Roeck wrote: http://comments.gmane.org/gmane.linux.network/363085 might explain your problem. I thought this was resolved in 4.1, but it looks like the problem still persists there. At least I have reports from my workplace that 4.1.6 and 4.1.7 are still affected. I don't know if there have been any relevant changes in 4.2. Copying Herbert and Eric for additional input. There was a separate bug discovered by Tejun recently. You need to apply the patches https://patchwork.ozlabs.org/patch/519245/ https://patchwork.ozlabs.org/patch/520824/ I assume this is on top of mainline ? There is another follow-up but it shouldn't make any difference in practice. Any idea what may be needed for 4.1 ? I am currently trying https://patchwork.ozlabs.org/patch/473041/, but I have no idea if that will help with the problem we are seeing there. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/9] zram: introduce crypto decompress noctx API and use it on zram
On Mon, Sep 21, 2015 at 12:58:12PM +0900, Minchan Kim wrote: > On Fri, Sep 18, 2015 at 02:19:15PM +0900, Joonsoo Kim wrote: > > This patchset makes zram to use crypto API in order to support > > more compression algorithm. > > > > The reason we need to support vairous compression algorithms is that > > zram's performance is highly depend on workload and compression algorithm > > and architecture. Every compression algorithm has it's own strong point. > > For example, zlib is the best for compression ratio, but, it's > > (de)compression speed is rather slow. Against my expectation, in my kernel > > build test with zram swap, in low-memory condition on x86, zlib shows best > > performance than others. In this case, I guess that compression ratio is > > the most important factor. Unlike this situation, on ARM, maybe fast > > (de)compression speed is the most important because it's computation speed > > is slower than x86. > > Fair enough. lzo and lz4 cannot cover all of workloads so surely, there are > workloads other compressor algorithm can win. As well, we could support > H/W compressor with crypto support so I think crypto is a way to go. Hello, Minchan. Good! > > One thing I have a concern is I don't want to bind some of compressor > algorithm to zram statically. User can see what kinds of crypto compressor > support in his system via /proc/crypto and use it dynamically. > I hope zram supports it. Okay. I will handle it next version. > > > > Anyway, there is a concern from Sergey to use crypto API in zram. Current > > crypto API has a limitation that always require tfm object to (de)compress > > something because some of (de)compression function requires scratch buffer > > embedded on tfm even if some of (de)compression function doesn't > > require it. Due to above reason, using crypto API rather than calling > > Nice catch from Sergey! > > > compression library directly causes more memory footprint and this is > > why zram doesn't use crypto API before. > > > > In this patchset, crypto compress noctx API is introduced to reduce memory > > footprint caused by maintaining multiple tfm and zram uses it. Before > > noctx API, zram's performace is down-graded if tfm is insufficient. But, > > after applying noctx API, performace is restored. > > > > This addresses Sergey's concern perfectly and provides possibility to use > > various compression algorithm in zram. > > > > Following is zram's read performance number. > > > > * iozone -t 4 -R -r 16K -s 60M -I +Z -i 0 -i 1 > > * max_stream is set to 1 > > * Output is in Kbytes/sec > > > > zram-base vs zram-crypto vs zram-crypto-noctx > > > > Read10411701.88 6426911.62 9423894.38 > > Re-read 10017386.62 6428218.88 1163.50 > > Another patch and number we need to merge this patchset is zlib support > patchset and number you had experiement. Okay. Will include. Thanks. > > > > Thanks. > > > > Joonsoo Kim (7): > > crypto: introduce decompression API that can be called via sharable > > tfm object > > crypto/lzo: support decompress_noctx > > crypyo/lz4: support decompress_noctx > > crypto/lz4hc: support decompress_noctx > > crypto/842: support decompress_noctx > > zram: use crypto API for compression > > zram: use crypto decompress_noctx API > > > > Sergey Senozhatsky (2): > > zram: make stream find and release functions static > > zram: pass zstrm down to decompression path > > > > crypto/842.c | 9 +++- > > crypto/compress.c | 36 +++ > > crypto/crypto_null.c | 3 +- > > crypto/deflate.c | 3 +- > > crypto/lz4.c | 9 +++- > > crypto/lz4hc.c | 9 +++- > > crypto/lzo.c | 9 +++- > > drivers/block/zram/Kconfig | 8 ++-- > > drivers/block/zram/Makefile| 4 +- > > drivers/block/zram/zcomp.c | 102 > > +++-- > > drivers/block/zram/zcomp.h | 42 +++-- > > drivers/block/zram/zcomp_lz4.c | 47 --- > > drivers/block/zram/zcomp_lz4.h | 17 --- > > drivers/block/zram/zcomp_lzo.c | 47 --- > > drivers/block/zram/zcomp_lzo.h | 17 --- > > drivers/block/zram/zram_drv.c | 32 + > > include/linux/crypto.h | 20 > > 17 files changed, 211 insertions(+), 203 deletions(-) > > delete mode 100644 drivers/block/zram/zcomp_lz4.c > > delete mode 100644 drivers/block/zram/zcomp_lz4.h > > delete mode 100644 drivers/block/zram/zcomp_lzo.c > > delete mode 100644 drivers/block/zram/zcomp_lzo.h > > > > -- > > 1.9.1 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line
Re: [PATCH v3 1/9] crypto: introduce decompression API that can be called via sharable tfm object
On Mon, Sep 21, 2015 at 02:38:59PM +0900, Sergey Senozhatsky wrote:
> On (09/18/15 14:19), Joonsoo Kim wrote:
> [..]
> > @@ -61,7 +61,8 @@ static struct crypto_alg alg = {
> > .cra_module = THIS_MODULE,
> > .cra_u = { .compress = {
> > .coa_compress = crypto842_compress,
> > - .coa_decompress = crypto842_decompress } }
> > + .coa_decompress = crypto842_decompress,
> > + .coa_decompress_noctx = NULL } }
> > };
> >
> > static int __init crypto842_mod_init(void)
> > diff --git a/crypto/compress.c b/crypto/compress.c
> > index c33f076..abb36a8 100644
> > --- a/crypto/compress.c
> > +++ b/crypto/compress.c
> > @@ -33,12 +33,21 @@ static int crypto_decompress(struct crypto_tfm *tfm,
> >dlen);
> > }
> >
> > +static int crypto_decompress_noctx(struct crypto_tfm *tfm,
> > + const u8 *src, unsigned int slen,
> > + u8 *dst, unsigned int *dlen)
> > +{
> > + return tfm->__crt_alg->cra_compress.coa_decompress_noctx(src, slen,
> > + dst, dlen);
> > +}
>
>
> hm... well... sorry, if irrelevant.
> if the algorithm can have a _noctx() decompression function, does it
> automatically guarantee that this algorithm never dereferences a passed
> `struct crypto_tfm *tfm' pointer in its decompress function? in other words,
> can we simply pass that `shared tfm pointer' to the existing decompress
> function instead of defining new symbols, new callbacks, etc.?
>
> cot_decompress_noctx() == cot_decompress(shared_ftm) ?
>
> just a thought.
Will think it if I implement next version in this way. Due to Herbert
comment, interface will be changed so much in next version.
>
> [..]
> > +struct crypto_comp *crypto_alloc_comp_noctx(const char *alg_name,
> > + u32 type, u32 mask)
> > +{
> > + struct crypto_comp *comp;
> > + struct crypto_tfm *tfm;
> > + struct compress_tfm *ops;
> > +
> > + comp = crypto_alloc_comp(alg_name, type, mask);
> > + if (IS_ERR(comp))
> > + return comp;
> > +
> > + tfm = crypto_comp_tfm(comp);
> > + if (!tfm->__crt_alg->cra_compress.coa_decompress_noctx) {
> > + crypto_free_comp(comp);
> > + return ERR_PTR(-EINVAL);
>
> -ENOMEM?
No, it's failure isn't related to NOMEM. Just not support it.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/9] crypto: introduce decompression API that can be called via sharable tfm object
On Tue, Sep 22, 2015 at 08:43:46PM +0800, Herbert Xu wrote: > On Fri, Sep 18, 2015 at 02:19:16PM +0900, Joonsoo Kim wrote: > > Until now, tfm object embeds (de)compression context in it and > > (de)compression in crypto API requires tfm object to use > > this context. But, there are some algorithms that doesn't need > > such context to operate. Therefore, this patch introduce new crypto > > decompression API that calls decompression function via sharable tfm > > object. Concurrent calls to decompress_noctx function through sharable > > tfm object will be okay because caller don't need any context in tfm and > > tfm is only used for fetching function pointer to decompress_noctx > > function. This can reduce overhead of maintaining multiple tfm > > if decompression doesn't require any context to operate. > > > > Signed-off-by: Joonsoo Kim > > Have you looked into include/crypto/compress.h? Okay. Now, I have looked it. > > The compress type itself is obsolete and should be replaced with > the pcomp interface. > > However, we made some mistakes with the pcomp interface. First > of all it doesn't have a non-partial interface like the digest > function for crypto_shash. > > But the biggest problem is that it should be completely stateless > but is not. IOW we should not store anything in the tfm that > is per-request. That should all go into the request structure. I'm not a expert on this area but I have different opinion. IIUC, what partial compression aims at is to support partial data compression. It isn't for stateless compression and they are different. Current implementation would work well for it's own purpose. And, making it stateless looks not good to me. If we make it stateless, we should include algorithm's state in request object. It enforces much memory to request object and, unlike crypto_shash which can be allocated in stack, user needs to manage life time of request objects and it requires additional complexity to compression user. Moreover, to use sharable tfm concurrently from my original intend, many request objects would be needed and if it cannot be allocated in the stack, it requires much memory. It's not suitable for my purpose. If compression is obsolete, what I think the best is leaving pcomp as is and implementing sharable tfm in pcomp, And then, make lzo and others support pcomp interface and sharable tfm. Maybe, I'm wrong so please correct me. Thanks. > Fortunately it seems that pcomp doesn't actually have any users > so we can just rip it out and start from scratch and redo it > properly. > > So to recap, please abandon any efforts on the crypto_compress > interface as it is old and obsolete. Instead reshape crypto_pcomp > into a proper stateless interface which should then give you what > you want. > > When you do so, just keep in mind that we need to find a way to > support IPComp. That means the ability to allocate requests in > thread context and then use them to compress/decompress in IRQ > context. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/9] crypto: introduce decompression API that can be called via sharable tfm object
On Mon, Sep 21, 2015 at 03:18:17PM +0900, Sergey Senozhatsky wrote:
> On (09/18/15 14:19), Joonsoo Kim wrote:
> [..]
> > static int __init lzo_mod_init(void)
> > diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> > index e71cb70..31152b1 100644
> > --- a/include/linux/crypto.h
> > +++ b/include/linux/crypto.h
> > @@ -355,6 +355,8 @@ struct compress_alg {
> > unsigned int slen, u8 *dst, unsigned int *dlen);
> > int (*coa_decompress)(struct crypto_tfm *tfm, const u8 *src,
> > unsigned int slen, u8 *dst, unsigned int *dlen);
> > + int (*coa_decompress_noctx)(const u8 *src, unsigned int slen,
> > + u8 *dst, unsigned int *dlen);
> > };
> >
> >
> > @@ -538,6 +540,9 @@ struct compress_tfm {
> > int (*cot_decompress)(struct crypto_tfm *tfm,
> > const u8 *src, unsigned int slen,
> > u8 *dst, unsigned int *dlen);
> > + int (*cot_decompress_noctx)(struct crypto_tfm *tfm,
> > + const u8 *src, unsigned int slen,
> > + u8 *dst, unsigned int *dlen);
> > };
> >
> > #define crt_ablkcipher crt_u.ablkcipher
> > @@ -1836,6 +1841,14 @@ static inline void crypto_free_comp(struct
> > crypto_comp *tfm)
> > crypto_free_tfm(crypto_comp_tfm(tfm));
> > }
> >
> > +struct crypto_comp *crypto_alloc_comp_noctx(const char *alg_name,
> > + u32 type, u32 mask);
> > +
>
> this should be EXPORT_SYMBOL_GPL().
>
Will do in next version.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] kexec: Use file name as the output message prefix
On 09/25/15 at 01:04pm, Dave Young wrote: > On 09/24/15 at 02:07pm, Minfei Huang wrote: > > kexec output message misses the prefix "kexec", when Dave Young split > > the kexec code. Now, we use file name as the output message prefix. > > > > Currectly, the format of output message: s/Currectly/Currently > > [ 140.290795] SYSC_kexec_load: hello, world > > [ 140.291534] kexec: sanity_check_segment_list: hello, world > > > > Ideally, the format of output message: > > [ 30.791503] kexec: SYSC_kexec_load, Hello, world > > [ 79.182752] kexec_core: sanity_check_segment_list, Hello, world > > > > Remove the custom prefix "kexec" in output message. > > > > Signed-off-by: Minfei Huang > > --- > > v2: Use KBUILD_MODNAME as prefix, instead of custom string "kexec" > > --- > > kernel/kexec.c | 2 ++ > > kernel/kexec_core.c | 4 ++-- > > kernel/kexec_file.c | 2 ++ > > 3 files changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/kernel/kexec.c b/kernel/kexec.c > > index 4c5edc3..df772fc 100644 > > --- a/kernel/kexec.c > > +++ b/kernel/kexec.c > > @@ -18,6 +18,8 @@ > > > > #include "kexec_internal.h" > > > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > + > > Move the micro to the top of the c file is better, ditto for other two files. s/micro/macro > > Otherwise: > Acked-by: Dave Young > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ethtool: add new emac_regs struct from driver, add new chip types.
* add new version of emac_regs struct from driver structure perspective
and passing size from actual struct size, not from memory area variable
which set in dts file.
* add three types of network chips for new struct : emac, emac4, emac4sync.
* add emac4sync processing in print_emac_regs.
* this commit fixing problem with output of MII sections for new driver
versions.
Signed-off-by: Ivan Mikhaylov
---
ibm_emac.c | 161 ++--
1 file changed, 125 insertions(+), 36 deletions(-)
diff --git a/ibm_emac.c b/ibm_emac.c
index e128e48..75cb560 100644
--- a/ibm_emac.c
+++ b/ibm_emac.c
@@ -22,6 +22,10 @@
#define EMAC_ETHTOOL_REGS_RGMII0x0002
#define EMAC_ETHTOOL_REGS_TAH 0x0004
+#define EMAC_VERSION 3
+#define EMAC4_VERSION 4
+#define EMAC4SYNC_VERSION 5
+
struct emac_ethtool_regs_hdr {
u32 components;
};
@@ -32,35 +36,78 @@ struct emac_ethtool_regs_subhdr {
};
struct emac_regs {
- u32 mr0;
- u32 mr1;
- u32 tmr0;
- u32 tmr1;
- u32 rmr;
- u32 isr;
- u32 iser;
- u32 iahr;
- u32 ialr;
- u32 vtpid;
- u32 vtci;
- u32 ptr;
- u32 iaht1;
- u32 iaht2;
- u32 iaht3;
- u32 iaht4;
- u32 gaht1;
- u32 gaht2;
- u32 gaht3;
- u32 gaht4;
+ /* Common registers across all EMAC implementations. */
+ u32 mr0;/* Special */
+ u32 mr1;/* Reset*/
+ u32 tmr0; /* Special */
+ u32 tmr1; /* Special */
+ u32 rmr;/* Reset*/
+ u32 isr;/* Always */
+ u32 iser; /* Reset*/
+ u32 iahr; /* Reset, R, T */
+ u32 ialr; /* Reset, R, T */
+ u32 vtpid; /* Reset, R, T */
+ u32 vtci; /* Reset, R, T */
+ u32 ptr;/* Reset,T */
+ union {
+ /* Registers unique to EMAC4 implementations */
+ struct {
+ u32 iaht1; /* Reset, R */
+ u32 iaht2; /* Reset, R */
+ u32 iaht3; /* Reset, R */
+ u32 iaht4; /* Reset, R */
+ u32 gaht1; /* Reset, R */
+ u32 gaht2; /* Reset, R */
+ u32 gaht3; /* Reset, R */
+ u32 gaht4; /* Reset, R */
+ } emac4;
+ /* Registers unique to EMAC4SYNC implementations */
+ struct {
+ u32 mahr; /* Reset, R, T */
+ u32 malr; /* Reset, R, T */
+ u32 mmahr; /* Reset, R, T */
+ u32 mmalr; /* Reset, R, T */
+ u32 rsvd0[4];
+ } emac4sync;
+ } u0;
+ /* Common registers across all EMAC implementations. */
u32 lsah;
u32 lsal;
- u32 ipgvr;
- u32 stacr;
- u32 trtr;
- u32 rwmr;
+ u32 ipgvr; /* Reset,T */
+ u32 stacr; /* Special */
+ u32 trtr; /* Special */
+ u32 rwmr; /* Reset*/
u32 octx;
u32 ocrx;
- u32 ipcr;
+ union {
+ /* Registers unique to EMAC4 implementations */
+ struct {
+ u32 ipcr;
+ } emac4;
+ /* Registers unique to EMAC4SYNC implementations */
+ struct {
+ u32 rsvd1;
+ u32 revid;
+ u32 rsvd2[2];
+ u32 iaht1; /* Reset, R */
+ u32 iaht2; /* Reset, R */
+ u32 iaht3; /* Reset, R */
+ u32 iaht4; /* Reset, R */
+ u32 iaht5; /* Reset, R */
+ u32 iaht6; /* Reset, R */
+ u32 iaht7; /* Reset, R */
+ u32 iaht8; /* Reset, R */
+ u32 gaht1; /* Reset, R */
+ u32 gaht2; /* Reset, R */
+ u32 gaht3; /* Reset, R */
+ u32 gaht4; /* Reset, R */
+ u32 gaht5; /* Reset, R */
+ u32 gaht6; /* Reset, R */
+ u32 gaht7; /* Reset, R */
+ u32 gaht8; /* Reset, R */
+ u32
Error: arch/arm/boot/dts/mt8127.dtsi:56.21-22 syntax error
Hi Yingjoe, FYI, build test results on v4.3-rc2 (pls ignore if it's inappropriate base for your patch). config: arm-multi_v7_defconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 41626f34b6fad3bd9f733a6d8f5542683d2356d5 # save the attached .config to linux build tree make.cross ARCH=arm All error/warnings (new ones prefixed by >>): >> Error: arch/arm/boot/dts/mt8127.dtsi:56.21-22 syntax error FATAL ERROR: Unable to parse input tree --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/arm 4.3.0-rc2 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_NO_IOPORT_MAP=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ZONE_DMA=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_PGTABLE_LEVELS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_HANDLE_DOMAIN_IRQ=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_EXPEDITE_BOOT is not set # CONFIG_BUILD_BIN2C is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_PIDS is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_MEMCG is not set # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_MULTIUSER=y # CONFIG_SGETMASK_SYSCALL is not set CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_BPF_SYSCALL is not set CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ADVISE_SYSCALLS=y # CONFIG_USERFAULTFD is not set CONFIG_PCI_QUIRKS=y CONFIG_MEMBARRIER=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not
Re: [PATCH v10 3/5] CPM/QE: use genalloc to manage CPM/QE muram
On Thu, 2015-09-24 at 21:50 -0500, Zhao Qiang-B45475 wrote:
> On Fri, Sep 25, 2015 at 7:30 AM +0800, Wood Scott-B07421 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, September 25, 2015 7:30 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> > Yang-Leo-R58472; pau...@samba.org
> > Subject: Re: [PATCH v10 3/5] CPM/QE: use genalloc to manage CPM/QE muram
> >
> > On Wed, 2015-09-23 at 00:28 -0500, Zhao Qiang-B45475 wrote:
> > > On Wen, Sep 23, 2015 at 12:03 AM +0800, Wood Scott-B07421 wrote:
> > >
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 23, 2015 12:03 PM
> > > > To: Zhao Qiang-B45475
> > > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > > Li Yang-Leo-R58472; pau...@samba.org
> > > > Subject: Re: [PATCH v10 3/5] CPM/QE: use genalloc to manage CPM/QE
> > > > muram
> > > >
> > > > On Tue, 2015-09-22 at 21:20 -0500, Zhao Qiang-B45475 wrote:
> > > > > On Wen, Sep 23, 2015 at 8:19 AM +0800, Wood Scott-B07421 wrote:
> > > > >
> > > > > > > > > {
> > > > > > > > > - int ret;
> > > > > > > > > +
> > > > > > > > > + unsigned long start;
> > > > > > > > > unsigned long flags;
> > > > > > > > > + unsigned long size_alloc = size; struct muram_block
> > > > > > > > > + *entry; int end_bit; int order =
> > > > > > > > > + muram_pool->min_alloc_order;
> > > > > > > > >
> > > > > > > > > spin_lock_irqsave(_muram_lock, flags);
> > > > > > > > > - ret = rh_free(_muram_info, offset);
> > > > > > > > > + end_bit = (offset >> order) + ((size + (1UL << order) -
> > > > > > > > > + 1)
> > > > > > > > > + >>
> > > > > > > > order);
> > > > > > > > > + if ((offset + size) > (end_bit << order))
> > > > > > > > > + size_alloc = size + (1UL << order);
> > > > > > > >
> > > > > > > > Why do you need to do all these calculations here?
> > > > > > >
> > > > > > > So do it in gen_pool_fixed_alloc?
> > > > > >
> > > > > > Could you explain why they're needed at all?
> > > > >
> > > > > Why it does the calculations?
> > > > > If the min block of gen_pool is 8 bytes, and I want to allocate a
> > > > > Region with offset=7, size=8bytes, I actually need block 0 and
> > > > > block 1, And the allocation will give me block 0.
> > > >
> > > > How can you have offset 7 if the minimum order is 2 bytes?
> > >
> > > Offset has no relationship with minimum order, it is not decided by
> > > minimum order.
> >
> > All allocations begin and end on a multiple of the minimum order.
>
> So it is the problem. CPM require to allocate a specific region,
> who can ensure that the specific is just the begin of minimum order.
Do you have any reason to believe that there is any caller of this function
with an odd address?
If so, set the minimum order to zero. If not, what is the problem?
> So the algo will find the first block covering the specific region's
> Start address, then because my specific region's start address is not equal
> To the address returned by algo, the end address is not equal to my
> specific region's end address, so the calculation is to keep the end
> address larger than specific region's end address.
>
> >
> > > I want to allocate a specific region with offset=7, then algo to
> > > calculate the block bit.
> > > And I just take it for example, it is not I really need to region
> > offset=7.
> >
> > Do you really need any fixed allocations that begin on an odd address?
>
> Maybe I don’t need an odd address, but the calculation is needed in case.
No. "In case" the caller does something that is not allowed, the allocation
should fail.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ibm/emac: bump version numbers for correct work with ethtool
On Wed, 23 Sep 2015 11:05:49 -0700 (PDT) "David Miller" wrote: > From: Ivan Mikhaylov > Date: Wed, 23 Sep 2015 14:42:22 +0400 > > > Register dump out work preventing with > > old ethtool + new driver and new ethtool + old driver. > > First of all you didn't provide a proper Signoff. > > Second of all, there was so much discussion about whether this does > or does not break things for various combinations of old/new ethtool > and kernel. > > Therefore I want a real detailed commit message that explains why this > is all OK. After so much confusion and discussion, providing a patch > with absolutely no commit message is completely inappropriate. David, my apologies for signoff and description, I admit that is inappropriate. Ben proposed one, is it eligible? Need I resubmit patch with sign and detailed description? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] kexec: Use file name as the output message prefix
On 09/24/15 at 02:07pm, Minfei Huang wrote:
> kexec output message misses the prefix "kexec", when Dave Young split
> the kexec code. Now, we use file name as the output message prefix.
>
> Currectly, the format of output message:
> [ 140.290795] SYSC_kexec_load: hello, world
> [ 140.291534] kexec: sanity_check_segment_list: hello, world
>
> Ideally, the format of output message:
> [ 30.791503] kexec: SYSC_kexec_load, Hello, world
> [ 79.182752] kexec_core: sanity_check_segment_list, Hello, world
>
> Remove the custom prefix "kexec" in output message.
>
> Signed-off-by: Minfei Huang
> ---
> v2: Use KBUILD_MODNAME as prefix, instead of custom string "kexec"
> ---
> kernel/kexec.c | 2 ++
> kernel/kexec_core.c | 4 ++--
> kernel/kexec_file.c | 2 ++
> 3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 4c5edc3..df772fc 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -18,6 +18,8 @@
>
> #include "kexec_internal.h"
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
Move the micro to the top of the c file is better, ditto for other two files.
Otherwise:
Acked-by: Dave Young
> static int copy_user_segment_list(struct kimage *image,
> unsigned long nr_segments,
> struct kexec_segment __user *segments)
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 201b453..dd21c78 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -6,7 +6,7 @@
> * Version 2. See the file COPYING for more details.
> */
>
> -#define pr_fmt(fmt) "kexec: " fmt
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include
> #include
> @@ -1027,7 +1027,7 @@ static int __init crash_notes_memory_init(void)
>
> crash_notes = __alloc_percpu(size, align);
> if (!crash_notes) {
> - pr_warn("Kexec: Memory allocation for saving cpu register
> states failed\n");
> + pr_warn("Memory allocation for saving cpu register states
> failed\n");
> return -ENOMEM;
> }
> return 0;
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 6a9a3f2..66a5dc8 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -22,6 +22,8 @@
> #include
> #include "kexec_internal.h"
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> /*
> * Declare these symbols weak so that if architecture provides a purgatory,
> * these will be overridden.
> --
> 1.9.1
>
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Sep 25
Hi all, Changes since 20150924: The berlin tree lost its build failure. I used the h8300 tree from next-20150828 since the current tree has been rebased onto something very old :-( The net-next tree gained a conflict against the net tree. The cgroup tree gained a build failure for which I applied a supplied merge fix patch. The pinctrl tree gained a build failure so I used the verison from next-20150924. Non-merge commits (relative to Linus' tree): 2851 2430 files changed, 127835 insertions(+), 36323 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 for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 226 trees (counting Linus' and 33 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 Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (cc8b8faea417 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (7ae85dc7687c ARM: 8425/1: kgdb: Don't try to stop the machine when setting breakpoints) Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather than duplicating its implementation) 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 (d6eb71a6d2ed cxl: Fix lockdep warning while creating afu_err_buff attribute) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave) Merging net/master (deccbe80be94 Merge tag 'mac80211-for-davem-2015-09-22' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging ipsec/master (04a6b8bfee06 xfrm6: Fix ICMPv6 and MH header checks in _decode_session6) Merging sound-current/for-linus (7f57d803ee03 ALSA: hda - Disable power_save_node for Thinkpads) Merging pci-current/for-linus (de24c18c0fac PCI: rcar: Add R8A7794 support) Merging wireless-drivers/master (c2e7204d180f tcp_cubic: do not set epoch_start in the future) Merging driver-core.current/driver-core-linus (2110d70c5e58 cpu/cacheinfo: Fix teardown path) Merging tty.current/tty-linus (f7a7651fcd40 tty: serial: Add missing module license for 8250_base.ko) Merging usb.current/usb-linus (cbb4be652d37 USB: whiteheat: fix potential null-deref at probe) Merging usb-gadget-fixes/fixes (a66c275b3d5d usb: dwc3: gadget: Fix BUG in RT config) Merging usb-serial-fixes/usb-linus (19ab6bc5674a USB: option: add ZTE PIDs) Merging staging.current/staging-linus (74c600e36455 MAINTAINERS: Update email address for Martyn Welch) Merging char-misc.current/char-misc-linus (50314035d6b1 Merge tag 'extcon-fixes-for-4.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-linus) Merging input-current/for-linus (72d4736253af Input: uinput - fix crash when using ABS events) Merging crypto-current/master (09185e2756a8 hwrng: xgene - fix handling platform_get_irq) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()) Merging vfio-fixes/for-linus (4b
Re: Glibc recvmsg from kernel netlink socket hangs forever
On Thu, Sep 24, 2015 at 09:36:53PM -0700, Guenter Roeck wrote: > > http://comments.gmane.org/gmane.linux.network/363085 > > might explain your problem. > > I thought this was resolved in 4.1, but it looks like the problem still > persists > there. At least I have reports from my workplace that 4.1.6 and 4.1.7 are > still > affected. I don't know if there have been any relevant changes in 4.2. > > Copying Herbert and Eric for additional input. There was a separate bug discovered by Tejun recently. You need to apply the patches https://patchwork.ozlabs.org/patch/519245/ https://patchwork.ozlabs.org/patch/520824/ There is another follow-up but it shouldn't make any difference in practice. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sunxi, Allwinner TDM Support?
Hi, I was wondering if the sunxi parts support TDM mode on their DAI ports? Those parts sure have attractive pricing, and as you may have gathered, I'm all about many microphone channels. :-) Thanks, -Caleb -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Error: arch/arm/boot/dts/mt8135.dtsi:81.21-22 syntax error
Hi Yingjoe, FYI, build test results on v4.3-rc2 (pls ignore if it's inappropriate base for your patch). config: arm-multi_v7_defconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 8a73387f4d2fc100197bd3a0d05398b7e243237d # save the attached .config to linux build tree make.cross ARCH=arm All error/warnings (new ones prefixed by >>): >> Error: arch/arm/boot/dts/mt8135.dtsi:81.21-22 syntax error FATAL ERROR: Unable to parse input tree --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/arm 4.3.0-rc2 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_NO_IOPORT_MAP=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ZONE_DMA=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_PGTABLE_LEVELS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_HANDLE_DOMAIN_IRQ=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_EXPEDITE_BOOT is not set # CONFIG_BUILD_BIN2C is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_PIDS is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_MEMCG is not set # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_MULTIUSER=y # CONFIG_SGETMASK_SYSCALL is not set CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_BPF_SYSCALL is not set CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ADVISE_SYSCALLS=y # CONFIG_USERFAULTFD is not set CONFIG_PCI_QUIRKS=y CONFIG_MEMBARRIER=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not
Re: Glibc recvmsg from kernel netlink socket hangs forever
On Thu, Sep 24, 2015 at 05:29:34PM -0700, Steven Schlansker wrote:
> Hello linux-kernel,
>
> I write to you on behalf of many developers at my company, who
> are having trouble with their applications endlessly locking up
> inside of libc code, with no hope of recovery.
>
> Currently it affects our Mono and Node processes mostly, and the
> symptoms are the same: user code invokes getaddrinfo, and libc
> attempts to determine whether ipv4 or ipv6 is appropriate, by using
> the RTM_GETADDR netlink message. The write into the netlink socket
> succeeds, and it immediately reads back the results ... and waits
> forever. The read never returns. The stack looks like this:
>
> #0 0x7fd7d8d214ad in recvmsg () at ../sysdeps/unix/syscall-template.S:81
> #1 0x7fd7d8d3e44d in make_request (fd=fd@entry=13, pid=1) at
> ../sysdeps/unix/sysv/linux/check_pf.c:177
> #2 0x7fd7d8d3e9a4 in __check_pf
> (seen_ipv4=seen_ipv4@entry=0x7fd7d37fdd00,
> seen_ipv6=seen_ipv6@entry=0x7fd7d37fdd10,
> in6ai=in6ai@entry=0x7fd7d37fdd40, in6ailen=in6ailen@entry=0x7fd7d37fdd50)
> at ../sysdeps/unix/sysv/linux/check_pf.c:341
> #3 0x7fd7d8cf64e1 in __GI_getaddrinfo (name=0x31216e0
> "mesos-slave4-prod-uswest2.otsql.opentable.com", service=0x0,
> hints=0x31216b0, pai=0x31f09e8) at ../sysdeps/posix/getaddrinfo.c:2355
> #4 0x00e101c8 in uv__getaddrinfo_work (w=0x31f09a0) at
> ../deps/uv/src/unix/getaddrinfo.c:102
> #5 0x00e09179 in worker (arg=) at
> ../deps/uv/src/threadpool.c:91
> #6 0x00e16eb1 in uv__thread_start (arg=) at
> ../deps/uv/src/unix/thread.c:49
> #7 0x7fd7d8ff3182 in start_thread (arg=0x7fd7d37fe700) at
> pthread_create.c:312
> #8 0x7fd7d8d2047d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>
> (libuv is part of Node and makes DNS lookups "asynchronous" by having
> a thread pool in the background working)
>
> The applications will run for hours or days successfully, until eventually
> hanging with
> no apparent pattern or cause. And once this hang happens it hangs badly,
> because
> check_pf is holding a lock during the problematic recvmsg call.
>
> I raised this issue on the libc-help mailing list, but I'm hoping that lkml
> will
> have a higher number of people familiar with netlink that may better offer
> advice.
> The original thread is here:
> https://sourceware.org/ml/libc-help/2015-09/msg00014.html
>
> Looking at the getaddrinfo / check_pf source code:
> https://fossies.org/dox/glibc-2.22/sysdeps_2unix_2sysv_2linux_2check__pf_8c_source.html
>
> 146 if (TEMP_FAILURE_RETRY (__sendto (fd, (void *) , sizeof (req), 0,
> 147 (struct sockaddr *) ,
> 148 sizeof (nladdr))) < 0)
> 149goto out_fail;
> 150
> 151 bool done = false;
> 152
> 153 bool seen_ipv4 = false;
> 154 bool seen_ipv6 = false;
> 155
> 156 do
> 157 {
> 158struct msghdr msg =
> 159{
> 160 (void *) , sizeof (nladdr),
> 161 , 1,
> 162 NULL, 0,
> 163 0
> 164};
> 165
> 166 ssize_t read_len = TEMP_FAILURE_RETRY (__recvmsg (fd, , 0));
> 167 if (read_len <= 0)
> 168goto out_fail;
> 169
> 170 if (msg.msg_flags & MSG_TRUNC)
> 171goto out_fail;
> 172
>
> I notice that there is possibility that if messages are dropped either on send
> or receive side, maybe this code will hang forever? The netlink(7) man page
> makes
> me slightly worried:
>
> > Netlink is not a reliable protocol. It tries its best to deliver a message
> > to its destination(s), but may drop messages when an out-of-memory
> > condition or other error occurs.
> > However, reliable transmissions from kernel to user are impossible in any
> > case. The kernel can't send a netlink message if the socket buffer is
> > full: the message will be dropped and the kernel and the user-space process
> > will no longer have the same view of kernel state. It is up to the
> > application to detect when this happens (via the ENOBUFS error returned
> > by recvmsg(2)) and resynchronize.
>
>
> I have taken the glibc code and created a simple(r) program to attempt to
> reproduce this issue.
> I inserted some simple polling between the sendto and recvmsg calls to make
> the failure case more evident:
>
> struct pollfd pfd;
> pfd.fd = fd;
> pfd.events = POLLIN;
> pfd.revents = 0;
>
> int pollresult = poll(, 1, 1000);
> if (pollresult < 0) {
> perror("glibc: check_pf: poll");
> abort();
> } else if (pollresult == 0 || pfd.revents & POLLIN == 0) {
> fprintf(stderr, "[%ld] glibc: check_pf: netlink socket read
> timeout\n", gettid());
> abort();
> }
>
> I have placed the full source code and strace output here:
> https://gist.github.com/stevenschlansker/6ad46c5ccb22bc4f3473
>
> The process quickly sends off hundreds of threads which sit in a
> loop attempting this RTM_GETADDR message exchange.
>
> The code may be compiled as "gcc -o pf_dump -pthread
Re: [RFC] PCI: Unassigned Expansion ROM BARs
On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote:
> Or do we want to keep a white list to say which device should have
> ROM bar as mush have, and other is optional to have ?
Subject: [RFC PATCH] PCI: Add pci_dev_need_rom_bar()
Only set that for
1. if BIOS/firmware already set ROM bar.
2. via quirks for some devices.
We assign those needed ROM bar as required
and other ROM bars as optional resources.
Signed-off-by: Yinghai Lu
---
arch/x86/pci/i386.c|9 +-
drivers/dma/pch_dma.c |1
drivers/gpio/gpio-ml-ioh.c |2 -
drivers/misc/pch_phub.c| 12
drivers/pci/probe.c|7 +
drivers/pci/quirks.c | 63 +
drivers/pci/setup-bus.c| 18 ++--
include/linux/pci.h| 13 +
include/linux/pci_ids.h|7 +
9 files changed, 112 insertions(+), 20 deletions(-)
Index: linux-2.6/arch/x86/pci/i386.c
===
--- linux-2.6.orig/arch/x86/pci/i386.c
+++ linux-2.6/arch/x86/pci/i386.c
@@ -377,11 +377,16 @@ static void pcibios_allocate_rom_resourc
}
}
+bool pci_assign_roms(void)
+{
+return !!(pci_probe & PCI_ASSIGN_ROMS);
+}
+
static int __init pcibios_assign_resources(void)
{
struct pci_host_bridge *host_bridge = NULL;
-if (!(pci_probe & PCI_ASSIGN_ROMS))
+if (!pci_assign_roms())
for_each_pci_host_bridge(host_bridge)
pcibios_allocate_rom_resources(host_bridge->bus);
@@ -406,7 +411,7 @@ void pcibios_resource_survey_bus(struct
pcibios_allocate_resources(bus, 0);
pcibios_allocate_resources(bus, 1);
-if (!(pci_probe & PCI_ASSIGN_ROMS))
+if (!pci_assign_roms())
pcibios_allocate_rom_resources(bus);
}
Index: linux-2.6/drivers/pci/probe.c
===
--- linux-2.6.orig/drivers/pci/probe.c
+++ linux-2.6/drivers/pci/probe.c
@@ -224,6 +224,13 @@ int __pci_read_base(struct pci_dev *dev,
l64 = l & PCI_ROM_ADDRESS_MASK;
sz64 = sz & PCI_ROM_ADDRESS_MASK;
mask64 = (u32)PCI_ROM_ADDRESS_MASK;
+/* simple validation */
+if (l64 && sz64 &&
+(l64 & 0xff00) != 0xff00 &&
+system_state == SYSTEM_BOOTING) {
+dev_printk(KERN_DEBUG, >dev, "set dev_flags NEED_ROM_BAR\n");
+pci_dev_set_need_rom_bar(dev);
+}
}
if (res->flags & IORESOURCE_MEM_64) {
Index: linux-2.6/drivers/pci/quirks.c
===
--- linux-2.6.orig/drivers/pci/quirks.c
+++ linux-2.6/drivers/pci/quirks.c
@@ -4197,3 +4197,66 @@ static void quirk_intel_qat_vf_cap(struc
}
}
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);
+
+/* from drivers/mtd/maps/pci.c */
+static void quirk_set_need_rom_bar(struct pci_dev *pdev)
+{
+if (!pci_dev_need_rom_bar(pdev)) {
+dev_printk(KERN_DEBUG, >dev, "set dev_flags NEED_ROM_BAR\n");
+pci_dev_set_need_rom_bar(pdev);
+}
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_DEC_21285,
+ quirk_set_need_rom_bar);
+
+#ifdef CONFIG_PARISC
+/* from drivers/video/console/sticore.c */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_VISUALIZE_EG,
+ quirk_set_need_rom_bar);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_VISUALIZE_FX6,
+ quirk_set_need_rom_bar);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_VISUALIZE_FX4,
+ quirk_set_need_rom_bar);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_VISUALIZE_FX2,
+ quirk_set_need_rom_bar);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_VISUALIZE_FXE,
+ quirk_set_need_rom_bar);
+#endif
+
+/* from drivers/misc/pch_phub.c */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_PCH1_PHUB,
+ quirk_set_need_rom_bar);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ROHM, PCI_DEVICE_ID_ROHM_ML7213_PHUB,
+ quirk_set_need_rom_bar);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ROHM, PCI_DEVICE_ID_ROHM_ML7223_mPHUB,
+ quirk_set_need_rom_bar);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ROHM, PCI_DEVICE_ID_ROHM_ML7223_nPHUB,
+ quirk_set_need_rom_bar);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ROHM, PCI_DEVICE_ID_ROHM_ML7831_PHUB,
+ quirk_set_need_rom_bar);
+
+/* from drivers/net/ethernet/sun/sungem.c */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SUN, PCI_DEVICE_ID_SUN_GEM,
+ quirk_set_need_rom_bar);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SUN, PCI_DEVICE_ID_SUN_RIO_GEM,
+ quirk_set_need_rom_bar);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_UNI_N_GMAC,
+ quirk_set_need_rom_bar);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_UNI_N_GMACP,
+ quirk_set_need_rom_bar);
[PATCH] mm doc: Fix misleading code reference of overcommit_memory
The origin document references to cap_vm_enough_memory is because cap_vm_enough_memory invoked __vm_enough_memory before and it no longer does now. Signed-off-by: Chun Chen --- Documentation/sysctl/vm.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index a4482fc..f72370b 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -639,7 +639,7 @@ and don't use much of it. The default value is 0. See Documentation/vm/overcommit-accounting and -security/commoncap.c::cap_vm_enough_memory() for more information. +mm/mmap.c::__vm_enough_memory() for more information. == -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: netlink: Add barrier to netlink_connect for theoretical case
On Thu, Sep 24, 2015 at 08:24:56PM -0700, Linus Torvalds wrote:
>
> The above looks very suspicious.
You're right Linus. I've added the READ_ONCE there. The reason I
kept the conditional is because the helper is always called in a
context where the result is used as part of an if statement. The
assembly actually looks sane, e.g., for netlink_bind:
3a06: 41 0f b6 94 24 e8 02movzbl 0x2e8(%r12),%edx
3a0d: 00 00
3a0f: 84 d2 test %dl,%dl
3a11: 0f 85 97 00 00 00 jne3aae
3a17: 49 83 bc 24 98 03 00cmpq $0x0,0x398(%r12)
3a1e: 00 00
...
3aae: 41 8b 84 24 a0 02 00mov0x2a0(%r12),%eax
3ab5: 00
3ab6: 41 39 46 04 cmp%eax,0x4(%r14)
3aba: 0f 84 57 ff ff ff je 3a17
3ac0: b8 ea ff ff ff mov$0xffea,%eax
3ac5: eb d1 jmp3a98
So there is no unnecessary jumping around. I checked the other
two call sites and they look the same. I'm on a fairly old compiler
though (4.7.2) so it is possible that newer gcc's may do silly things.
Thanks,
---8<---
If a netlink_connect call is followed by a netlink_getname call
the portid returned may not be up-to-date. This patch adds a
barrier for that case.
As all nlk->bound dereferences now have barriers this patch also
adds a netlink_bound helper to encapsulate the barrier, as was
suggested by Tejun. Also as suggested by Linus, the lockless
read of nlk->bound is now protected with READ_ONCE to ensure that
the compiler doesn't do double reads that may screw up our use
of the barrier.
Fixes: da314c9923fe ("netlink: Replace rhash_portid with bound")
Reported-by: Tejun Heo
Signed-off-by: Herbert Xu
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 2c15fae..dd0a294 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -125,6 +125,17 @@ static inline u32 netlink_group_mask(u32 group)
return group ? 1 << (group - 1) : 0;
}
+static inline bool netlink_bound(struct netlink_sock *nlk)
+{
+ bool bound = READ_ONCE(nlk->bound);
+
+ /* Ensure nlk is hashed and visible. */
+ if (bound)
+ smp_rmb();
+
+ return bound;
+}
+
int netlink_add_tap(struct netlink_tap *nt)
{
if (unlikely(nt->dev->type != ARPHRD_NETLINK))
@@ -1524,14 +1535,10 @@ static int netlink_bind(struct socket *sock, struct
sockaddr *addr,
return err;
}
- bound = nlk->bound;
- if (bound) {
- /* Ensure nlk->portid is up-to-date. */
- smp_rmb();
-
+ bound = netlink_bound(nlk);
+ if (bound)
if (nladdr->nl_pid != nlk->portid)
return -EINVAL;
- }
if (nlk->netlink_bind && groups) {
int group;
@@ -1547,9 +1554,6 @@ static int netlink_bind(struct socket *sock, struct
sockaddr *addr,
}
}
- /* No need for barriers here as we return to user-space without
-* using any of the bound attributes.
-*/
if (!bound) {
err = nladdr->nl_pid ?
netlink_insert(sk, nladdr->nl_pid) :
@@ -1598,10 +1602,7 @@ static int netlink_connect(struct socket *sock, struct
sockaddr *addr,
!netlink_allowed(sock, NL_CFG_F_NONROOT_SEND))
return -EPERM;
- /* No need for barriers here as we return to user-space without
-* using any of the bound attributes.
-*/
- if (!nlk->bound)
+ if (!netlink_bound(nlk))
err = netlink_autobind(sock);
if (err == 0) {
@@ -2442,13 +2443,10 @@ static int netlink_sendmsg(struct socket *sock, struct
msghdr *msg, size_t len)
dst_group = nlk->dst_group;
}
- if (!nlk->bound) {
+ if (!netlink_bound(nlk)) {
err = netlink_autobind(sock);
if (err)
goto out;
- } else {
- /* Ensure nlk is hashed and visible. */
- smp_rmb();
}
/* It's a really convoluted way for userland to ask for mmaped
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the pinctrl tree
Hi Linus,
After merging the pinctrl tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/pinctrl/pinctrl-at91-pio4.c: In function 'atmel_gpio_irq_set_type':
drivers/pinctrl/pinctrl-at91-pio4.c:170:3: error: implicit declaration of
function '__irq_set_handler_locked' [-Werror=implicit-function-declaration]
__irq_set_handler_locked(d->irq, handle_edge_irq);
^
drivers/pinctrl/pinctrl-at91-pio4.c: In function 'atmel_pinctrl_probe':
drivers/pinctrl/pinctrl-at91-pio4.c:925:3: warning: passing argument 2 of
'irq_set_chained_handler' from incompatible pointer type
irq_set_chained_handler(res->start, atmel_gpio_irq_handler);
^
In file included from include/linux/gpio/driver.h:6:0,
from include/asm-generic/gpio.h:12,
from arch/arm/include/asm/gpio.h:9,
from include/linux/gpio.h:48,
from drivers/pinctrl/pinctrl-at91-pio4.c:18:
include/linux/irq.h:548:1: note: expected 'irq_flow_handler_t' but argument is
of type 'void (*)(unsigned int, struct irq_desc *)'
irq_set_chained_handler(unsigned int irq, irq_flow_handler_t handle)
^
Caused by commit
776180848b57 ("pinctrl: introduce driver for Atmel PIO4 controller")
I have used the pinctrl tree from next-20150924 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Update the default value of crashkernel low
On 09/24/15 at 03:44pm, Jonathan Corbet wrote:
> On Thu, 24 Sep 2015 16:51:25 +0800
> Baoquan He wrote:
>
> > In commit 94fb933 ("x86/crash: Allocate enough low memory when
> > crashkernel=high") the default value of crashkernel low memory
> > is changed to 256M. In this patch update it accordingly.
>
> Applied to the docs tree, thanks.
Thanks, Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v3 10/10] regulator: qcom-smd: Add support for PMA8084
On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote:
> This patch adds support and documentation for the PMA8084 regulators
> found on APQ8084 platforms.
>
Acked-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Andy Gross
> ---
> .../bindings/soc/qcom/qcom,smd-rpm-regulator.txt | 35
> drivers/regulator/qcom_smd-regulator.c | 95
>
> 2 files changed, 130 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
> b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
> index e74ffe1..22b3506 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
> @@ -19,6 +19,7 @@ Regulator nodes are identified by their compatible:
> "qcom,rpm-pm8841-regulators"
> "qcom,rpm-pm8916-regulators"
> "qcom,rpm-pm8941-regulators"
> + "qcom,rpm-pma8084-regulators"
>
> - vdd_s1-supply:
> - vdd_s2-supply:
> @@ -64,6 +65,35 @@ Regulator nodes are identified by their compatible:
> Definition: reference to regulator supplying the input pin, as
> described in the data sheet
>
> +- vdd_s1-supply:
> +- vdd_s2-supply:
> +- vdd_s3-supply:
> +- vdd_s4-supply:
> +- vdd_s5-supply:
> +- vdd_s6-supply:
> +- vdd_s7-supply:
> +- vdd_s8-supply:
> +- vdd_s9-supply:
> +- vdd_s10-supply:
> +- vdd_s11-supply:
> +- vdd_s12-supply:
> +- vdd_l1_l11-supply:
> +- vdd_l2_l3_l4_l27-supply:
> +- vdd_l5_l7-supply:
> +- vdd_l6_l12_l14_l15_l26-supply:
> +- vdd_l8-supply:
> +- vdd_l9_l10_l13_l20_l23_l24-supply:
> +- vdd_l16_l25-supply:
> +- vdd_l17-supply:
> +- vdd_l18-supply:
> +- vdd_l19-supply:
> +- vdd_l21-supply:
> +- vdd_l22-supply:
> + Usage: optional (pma8084 only)
> + Value type:
> + Definition: reference to regulator supplying the input pin, as
> + described in the data sheet
> +
> The regulator node houses sub-nodes for each regulator within the device.
> Each
> sub-node is identified using the node's name, with valid values listed for
> each
> of the pmics below.
> @@ -80,6 +110,11 @@ pm8941:
> l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
> lvs3, 5vs1, 5vs2
>
> +pma8084:
> + s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5,
> + l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20,
> + l21, l22, l23, l24, l25, l26, l27, lvs1, lvs2, lvs3, lvs4, 5vs1
> +
> The content of each sub-node is defined by the standard binding for
> regulators -
> see regulator.txt.
>
> diff --git a/drivers/regulator/qcom_smd-regulator.c
> b/drivers/regulator/qcom_smd-regulator.c
> index e9b07cc3..24f4be7 100644
> --- a/drivers/regulator/qcom_smd-regulator.c
> +++ b/drivers/regulator/qcom_smd-regulator.c
> @@ -153,6 +153,49 @@ static const struct regulator_ops rpm_switch_ops = {
> .is_enabled = rpm_reg_is_enabled,
> };
>
> +static const struct regulator_desc pma8084_hfsmps = {
> + .linear_ranges = (struct regulator_linear_range[]) {
> + REGULATOR_LINEAR_RANGE(375000, 0, 95, 12500),
> + REGULATOR_LINEAR_RANGE(155, 96, 158, 25000),
> + },
> + .n_linear_ranges = 2,
> + .n_voltages = 159,
> + .ops = _smps_ldo_ops,
> +};
> +
> +static const struct regulator_desc pma8084_ftsmps = {
> + .linear_ranges = (struct regulator_linear_range[]) {
> + REGULATOR_LINEAR_RANGE(35, 0, 184, 5000),
> + REGULATOR_LINEAR_RANGE(70, 185, 339, 1),
> + },
> + .n_linear_ranges = 2,
> + .n_voltages = 340,
> + .ops = _smps_ldo_ops,
> +};
> +
> +static const struct regulator_desc pma8084_pldo = {
> + .linear_ranges = (struct regulator_linear_range[]) {
> + REGULATOR_LINEAR_RANGE(75, 0, 30, 25000),
> + REGULATOR_LINEAR_RANGE(150, 31, 99, 5),
> + },
> + .n_linear_ranges = 2,
> + .n_voltages = 100,
> + .ops = _smps_ldo_ops,
> +};
> +
> +static const struct regulator_desc pma8084_nldo = {
> + .linear_ranges = (struct regulator_linear_range[]) {
> + REGULATOR_LINEAR_RANGE(75, 0, 63, 12500),
> + },
> + .n_linear_ranges = 1,
> + .n_voltages = 64,
> + .ops = _smps_ldo_ops,
> +};
> +
> +static const struct regulator_desc pma8084_switch = {
> + .ops = _switch_ops,
> +};
> +
> static const struct regulator_desc pm8x41_hfsmps = {
> .linear_ranges = (struct regulator_linear_range[]) {
> REGULATOR_LINEAR_RANGE( 375000, 0, 95, 12500),
> @@ -335,10 +378,62 @@ static const struct rpm_regulator_data
> rpm_pm8941_regulators[] = {
> {}
> };
>
> +static const struct rpm_regulator_data rpm_pma8084_regulators[] = {
> + { "s1", QCOM_SMD_RPM_SMPA, 1, _ftsmps, "vdd_s1" },
> + { "s2", QCOM_SMD_RPM_SMPA, 2, _ftsmps, "vdd_s2" },
> + {
linux-next: build failure after merge of the cgroup tree
Hi Tejun,
After merging the cgroup tree, today's linux-next build (x86_64
allmodconfig) failed like this:
mm/vmscan.c: In function 'sane_reclaim':
mm/vmscan.c:178:2: error: implicit declaration of function 'cgroup_on_dfl'
[-Werror=implicit-function-declaration]
if (cgroup_on_dfl(memcg->css.cgroup))
^
Caused by commit
d5028f9f7d8d ("vmscan: fix sane_reclaim helper for legacy memcg")
from Linus' tree interacting with commit
9e10a130d9b6 ("cgroup: replace cgroup_on_dfl() tests in controllers with
cgroup_subsys_on_dfl()")
from the cgroup tree.
We new this was coming, so I have applied the following merge fix patch from
Andrew's tree and can carry it as necessary:
From: Michal Hocko
Subject: vmscan build fix
Signed-off-by: Andrew Morton
---
mm/vmscan.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/vmscan.c~vmscan-build-fix mm/vmscan.c
--- a/mm/vmscan.c~vmscan-build-fix
+++ a/mm/vmscan.c
@@ -175,7 +175,7 @@ static bool sane_reclaim(struct scan_con
if (!memcg)
return true;
#ifdef CONFIG_CGROUP_WRITEBACK
- if (cgroup_on_dfl(memcg->css.cgroup))
+ if (cgroup_subsys_on_dfl(memory_cgrp_subsys))
return true;
#endif
return false;
_
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: netlink: Add barrier to netlink_connect for theoretical case
On Thu, Sep 24, 2015 at 6:43 PM, Herbert Xu wrote:
> On Thu, Sep 24, 2015 at 04:05:10PM -0400, Tejun Heo wrote:
>
> +static inline bool netlink_bound(struct netlink_sock *nlk)
> +{
> + /* Ensure nlk is hashed and visible. */
> + if (nlk->bound)
> + smp_rmb();
> +
> + return nlk->bound;
> +}
The above looks very suspicious.
If "nlk->bound" isn't stable, then you might read 0 the first time,
not do the smp_rmb(), and then read 1 on the second access to
nlk->bound.
In other words, you just ended up returning 1 without actually doing
the mb, so there will be no serialization between the "bound" variable
and reading the portid afterwards.
That makes no sense.
And if nlk->bound *is* stable, then the smp_rmb() doesn't make any
sense that I can see.
So for the code to actually make sense, it should either do:
int bound = nlk->bound;
smp_rmb();
return bound;
which is fine on x86, but might be expensive on other architectures
due to the unconditional rmb.
So you *could* write it with a conditional rmb, but then you need to
use a READ_ONCE(), to make sure that gcc really does the read exactly
once, because at that point the "rmb" no longer keeps gcc from playing
tricks. So
int bound = READ_ONCE(nlk->bound);
if (bound)
smp_rmb();
return bound;
could also be correct. Sadly, while "smp_rmb()" is a no-op on x86, it
*is* a barrier, so the above conditional smp_rmb() actually sucks on
x86, because I suspect that gcc will create a jump around an empty
asm. So the unconditional rmb is actually simpler better on at least
x86.
But the function as you wrote it does not make sense. When you do a
barrier, you really have to think about where the accesses are.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v3 09/10] arm: dts: Add support for PMA8084 on APQ8084
On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote: > This patch adds support for the PMA8084 regulators found on APQ8084 > platforms. > Acked-by: Bjorn Andersson Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v3 08/10] arm: dts: Add RPM/SMD support on APQ8084
On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote: > This patch adds support for RPM and SMD nodes that are present on APQ8084 > platforms. > Acked-by: Bjorn Andersson Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v3 05/10] arm64: dts: Add PM8916 support on MSM8916
On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote: > This patch adds the PM8916 regulator nodes found on MSM8916 platforms. > Acked-by: Bjorn Andersson Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v3 07/10] arm: dts: Add APQ8084 SMEM nodes
On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote: > This patch adds all the required nodes to support SMEM on APQ8084 > Acked-by: Bjorn Andersson Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v3 03/10] arm64: dts: qcom: Add MSM8916 SMEM nodes
On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote: > This patch adds the nodes necessary to support the SMEM driver on MSM8916 > platforms. > Looks reasonable, I've not reviewed the addresses of things, but I presume you have :) Acked-by: Bjorn Andersson Reards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v3 04/10] arm64: dts: qcom: Add RPM/SMD support on MSM8916
On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote: > Add support for the SMD and RPM devices found on MSM8916 platforms. > Looks reasonable Acked-by: Bjorn Andersson Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] perf tools: Enable event_config terms to tracepoint events
This patch enable config terms for tracepoint perf events. Valid terms
for tracepoint events are call-graph and stack-size, so we can use
different callgraph settings for each event and eliminate unnecessary
overhead.
Here is an example for using different call-graph config for each
tracepoint.
$ perf record -e syscalls:sys_enter_write/call-graph=fp/
-e syscalls:sys_exit_write/call-graph=no/
dd if=/dev/zero of=test bs=4k count=10
$ perf report --stdio
#
# Total Lost Samples: 0
#
# Samples: 13 of event 'syscalls:sys_enter_write'
# Event count (approx.): 13
#
# Children Self Command Shared Object Symbol
# ... .. ..
#
76.92%76.92% dd libpthread-2.20.so [.] __write_nocancel
|
---__write_nocancel
23.08%23.08% dd libc-2.20.so[.] write
|
---write
|
|--33.33%-- 0x2031342820736574
|
|--33.33%-- 0xa6e69207364726f
|
--33.33%-- 0x34202c7320393039
...
# Samples: 13 of event 'syscalls:sys_exit_write'
# Event count (approx.): 13
#
# Children Self Command Shared Object Symbol
# ... .. ..
#
76.92%76.92% dd libpthread-2.20.so [.] __write_nocancel
23.08%23.08% dd libc-2.20.so[.] write
7.69% 0.00% dd [unknown] [.] 0x0a6e69207364726f
7.69% 0.00% dd [unknown] [.] 0x2031342820736574
7.69% 0.00% dd [unknown] [.] 0x34202c7320393039
Signed-off-by: He Kuang
---
tools/perf/util/parse-events.c | 89 --
tools/perf/util/parse-events.h | 3 +-
tools/perf/util/parse-events.y | 46 +-
3 files changed, 107 insertions(+), 31 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index f624b99..e5cc112 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -27,6 +27,8 @@
extern int parse_events_debug;
#endif
int parse_events_parse(void *data, void *scanner);
+static int get_config_terms(struct list_head *head_config,
+ struct list_head *head_terms __maybe_unused);
static struct perf_pmu_event_symbol *perf_pmu_events_list;
/*
@@ -416,7 +418,8 @@ static void tracepoint_error(struct parse_events_error
*error, int err,
static int add_tracepoint(struct list_head *list, int *idx,
char *sys_name, char *evt_name,
- struct parse_events_error *error __maybe_unused)
+ struct parse_events_error *error __maybe_unused,
+ struct list_head *head_config)
{
struct perf_evsel *evsel;
@@ -426,13 +429,22 @@ static int add_tracepoint(struct list_head *list, int
*idx,
return PTR_ERR(evsel);
}
+ if (head_config) {
+ LIST_HEAD(config_terms);
+
+ if (get_config_terms(head_config, _terms))
+ return -ENOMEM;
+ list_splice(_terms, >config_terms);
+ }
+
list_add_tail(>node, list);
return 0;
}
static int add_tracepoint_multi_event(struct list_head *list, int *idx,
char *sys_name, char *evt_name,
- struct parse_events_error *error)
+ struct parse_events_error *error,
+ struct list_head *head_config)
{
char evt_path[MAXPATHLEN];
struct dirent *evt_ent;
@@ -456,7 +468,8 @@ static int add_tracepoint_multi_event(struct list_head
*list, int *idx,
if (!strglobmatch(evt_ent->d_name, evt_name))
continue;
- ret = add_tracepoint(list, idx, sys_name, evt_ent->d_name,
error);
+ ret = add_tracepoint(list, idx, sys_name, evt_ent->d_name,
+error, head_config);
}
closedir(evt_dir);
@@ -465,16 +478,20 @@ static int add_tracepoint_multi_event(struct list_head
*list, int *idx,
static int add_tracepoint_event(struct list_head *list, int *idx,
char *sys_name, char *evt_name,
- struct parse_events_error *error)
+ struct parse_events_error *error,
+ struct list_head *head_config)
{
return strpbrk(evt_name, "*?") ?
- add_tracepoint_multi_event(list, idx, sys_name, evt_name, error)
:
- add_tracepoint(list, idx, sys_name, evt_name, error);
+
[PATCH 1/2] perf tools: Prompt error message for wrong terms of hw/sw events
Prompt proper error message when wrong config terms is specificed for
hw/sw type perf events. Currently, unknown terms is not reported as an
error because pmu events have valid terms in sysfs. But for hw/sw
events, valid config terms are fixed and it should be reported if
wrong terms are given.
Before this patch:
$ perf record -e 'cpu-clock/freq=200/' -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.028 MB perf.data (202 samples) ]
$ perf record -e 'cpu-clock/freqx=200/' -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.042 MB perf.data (506 samples) ]
After this patch:
$ perf record -e 'cpu-clock/freqx=200/' -a sleep 1
event syntax error: 'cpu-clock/freqx=200/'
\___ unknown term
valid terms:
config,config1,config2,name,period,freq,branch_type,time,call-graph,stack-size
Run 'perf list' for a list of valid events
usage: perf record [] []
or: perf record [] -- []
-e, --eventevent selector. use 'perf list' to list available
events
Signed-off-by: He Kuang
---
tools/perf/util/parse-events.c | 60 +++---
tools/perf/util/parse-events.h | 1 +
tools/perf/util/pmu.c | 35 +---
3 files changed, 63 insertions(+), 33 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 61c2bc2..f624b99 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -599,7 +599,11 @@ static int check_type_val(struct parse_events_term *term,
return -EINVAL;
}
-static int config_term(struct perf_event_attr *attr,
+typedef int config_term_func_t(struct perf_event_attr *attr,
+ struct parse_events_term *term,
+ struct parse_events_error *err);
+
+static int config_term_common(struct perf_event_attr *attr,
struct parse_events_term *term,
struct parse_events_error *err)
{
@@ -610,12 +614,6 @@ do {
\
} while (0)
switch (term->type_term) {
- case PARSE_EVENTS__TERM_TYPE_USER:
- /*
-* Always succeed for sysfs terms, as we dont know
-* at this point what type they need to have.
-*/
- return 0;
case PARSE_EVENTS__TERM_TYPE_CONFIG:
CHECK_TYPE_VAL(NUM);
attr->config = term->val.num;
@@ -658,6 +656,9 @@ do {
\
CHECK_TYPE_VAL(STR);
break;
default:
+ err->str = strdup("unknown term");
+ err->idx = term->err_term;
+ err->help = parse_events_formats_error_string(NULL);
return -EINVAL;
}
@@ -665,9 +666,24 @@ do {
\
#undef CHECK_TYPE_VAL
}
+static int config_term_pmu(struct perf_event_attr *attr,
+ struct parse_events_term *term,
+ struct parse_events_error *err)
+{
+ if (term->type_term == PARSE_EVENTS__TERM_TYPE_USER)
+ /*
+* Always succeed for sysfs terms, as we dont know
+* at this point what type they need to have.
+*/
+ return 0;
+ else
+ return config_term_common(attr, term, err);
+}
+
static int config_attr(struct perf_event_attr *attr,
struct list_head *head,
- struct parse_events_error *err)
+ struct parse_events_error *err,
+ config_term_func_t config_term)
{
struct parse_events_term *term;
@@ -735,7 +751,8 @@ int parse_events_add_numeric(struct parse_events_evlist
*data,
attr.config = config;
if (head_config) {
- if (config_attr(, head_config, data->error))
+ if (config_attr(, head_config, data->error,
+ config_term_common))
return -EINVAL;
if (get_config_terms(head_config, _terms))
@@ -795,7 +812,7 @@ int parse_events_add_pmu(struct parse_events_evlist *data,
* Configure hardcoded terms first, no need to check
* return value when called with fail == 0 ;)
*/
- if (config_attr(, head_config, data->error))
+ if (config_attr(, head_config, data->error, config_term_pmu))
return -EINVAL;
if (get_config_terms(head_config, _terms))
@@ -1861,3 +1878,26 @@ void parse_events_evlist_error(struct
parse_events_evlist *data,
err->str = strdup(str);
WARN_ONCE(!err->str, "WARNING: failed to allocate error string");
}
+
+char
Re: [Patch v3 01/10] soc: qcom: documentation: Update SMD/RPM Docs
On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote: > This patch moves the qcom,smd-rpm.txt to the correct location and splits > out the smd and rpm documentation. In addition, a smd-rpm-regulator > document is added. > Acked-by: Bjorn Andersson Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/1] USB DWC2 parity fix in isochronous mode
On 9/24/2015 10:28 AM, Roman Bacik wrote:
>> -Original Message-
>> From: John Youn [mailto:john.y...@synopsys.com]
>> Sent: September-23-15 9:21 PM
>> To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
>> u...@vger.kernel.org; Roman Bacik
>> Cc: linux-kernel@vger.kernel.org; bcm-kernel-feedback-list
>> Subject: Re: [PATCH v3 0/1] USB DWC2 parity fix in isochronous mode
>>
>> On 9/10/2015 6:14 PM, Scott Branden wrote:
>>> This patch contains a fix for a real world interop problem found when
>>> using the Synopsis DWC2 USB controller with isochronous audio as
>>> detailed in the commit message.
>>>
>>> Changes from v2:
>>> - created s2c_hsotg_chage_ep_iso_parity function to call function in
>>> 3 places in code
>>> - used hsotg->num_of_eps instead of MAX_EPS_CHANNELS
>>>
>>> Changes from v1:
>>> - Address code review comments as per previous responses:
>>> - renamed parity_set to has_correct_parity and reorder some logic
>>>
>>>
>>> Roman Bacik (1):
>>> usb: dwc2: gadget: parity fix in isochronous mode
>>>
>>> drivers/usb/dwc2/core.h | 1 +
>>> drivers/usb/dwc2/gadget.c | 58
>> ++-
>>> drivers/usb/dwc2/hw.h | 1 +
>>> 3 files changed, 54 insertions(+), 6 deletions(-)
>>>
>>
>> This seems to break slave mode on my platform. It seems to be dropping a
>> lot of packets. I tried bInterval=4,5,6, ISO OUT.
>> I'll need to take a closer look to determine why. Probably later this week.
>>
>> Are you able to run in slave mode on your platform? If so can you try it out?
>>
>> Regards,
>> John
>
> Our current test procedure is as follows:
>
> Build Linux kernel with:
>
> Device Drivers
> - Sound Card Support 'SOUND=y': ALSA 'SND=y'
> - Generic sound devices: Dummy (/dev/null) soundcard 'SND_DUMMY=y'
> - USB support 'USB_SUPPORT=y':
> DesignWare USB2 DRD Core support 'USB_DWC2=y'
> - Gadget only mode 'USB_DWC2_PERIPHERAL=y'
> DWC2 Platform 'USB_DWC2_PLATFORM=y'
> - USB Gadget Support 'USB_GADGET=y': Audio Gadget 'USB_AUDIO=y'
> - PHY Subsystem: Broadcom Kona USB2 PHY Driver 'BCM_KONA_USB2_PHY=y'
>
> If you have only even hosts, you can change the default micro frame parity to
> odd:
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index ad45b0b..80bde75 100644
> @@ -2709,7 +2709,7 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
> switch (desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) {
> case USB_ENDPOINT_XFER_ISOC:
> epctrl |= DXEPCTL_EPTYPE_ISO;
> -epctrl |= DXEPCTL_SETEVENFR;
> +epctrl |= DXEPCTL_SETODDFR;
> hs_ep->isochronous = 1;
> if (dir_in)
> hs_ep->periodic = 1;
> @@ -2777,7 +2777,7 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
>
> /* for non control endpoints, set PID to D0 */
> if (index)
> -epctrl |= DXEPCTL_SETD0PID;
> +epctrl |= DXEPCTL_SETD1PID;
>
> dev_dbg(hsotg->dev, "%s: write DxEPCTL=0x%08x\n",
> __func__, epctrl);
>
> To test OUT direction:
> Host:
> aplay -D plughw:2 -r 48000 -f S16_LE tone_48stereo.wav
> Device:
> arecord -D plughw:0 -r 48000 -f S16_LE -c 1 /tmp/rec.pcm
>
> To test IN direction:
> Host:
> arecord -D plughw:2 -r 48000 -f S16_LE -c 1 /tmp/rec.pcm
> Device:
> aplay -D plughw:0 -r 48000 -f S16_LE /tmp/rec.pcm
>
> If you would like, we can try to test your procedure provided you send us
> enough details.
> Regards,
>
> Roman
>
>
I looked at it a bit more and I think there are two issues.
In slave-mode, the xfercomplete interrupt is not used for OUT
transfers, so the has_correct_parity flag is never set.
The other issue is that we occasionally get the incomplete
interrupt twice in a microframe causing the parity to be set
incorrectly for the next frame. Thus we will continuously miss
until this occurs again, correcting it.
These two problems in combination cause dropped packets
throughout operation.
If you give me some time I can see if I can fix up this patch to
work with slave mode.
I've tried all our hosts here and they are all even hosts, so I
tried flipping the default parity. The issue exists in either
case.
Regards,
John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] KVM: introduce __vmx_flush_tlb to handle specific vpid
On 9/25/15 12:12 AM, Bandan Das wrote:
Wanpeng Li writes:
Introduce __vmx_flush_tlb() to handle specific vpid.
Signed-off-by: Wanpeng Li
---
arch/x86/kvm/vmx.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 794c529..7188c5e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1343,13 +1343,13 @@ static void loaded_vmcs_clear(struct loaded_vmcs
*loaded_vmcs)
__loaded_vmcs_clear, loaded_vmcs, 1);
}
-static inline void vpid_sync_vcpu_single(struct vcpu_vmx *vmx)
+static inline void vpid_sync_vcpu_single(int vpid)
{
- if (vmx->vpid == 0)
+ if (vpid == 0)
return;
if (cpu_has_vmx_invvpid_single())
- __invvpid(VMX_VPID_EXTENT_SINGLE_CONTEXT, vmx->vpid, 0);
+ __invvpid(VMX_VPID_EXTENT_SINGLE_CONTEXT, vpid, 0);
}
static inline void vpid_sync_vcpu_global(void)
@@ -1358,10 +1358,10 @@ static inline void vpid_sync_vcpu_global(void)
__invvpid(VMX_VPID_EXTENT_ALL_CONTEXT, 0, 0);
}
-static inline void vpid_sync_context(struct vcpu_vmx *vmx)
+static inline void vpid_sync_context(int vpid)
{
if (cpu_has_vmx_invvpid_single())
- vpid_sync_vcpu_single(vmx);
+ vpid_sync_vcpu_single(vpid);
else
vpid_sync_vcpu_global();
}
Not sure myself what's the right thing to do but this may be undesirable
in a nested environment. Assuming the processor supports global invalidation
only, this seems like a easy way for the nested guest to invalidate *all*
mappings - even the L1 specific mappings.
Indeed, however, there's no easy way to handle the w/o single
invalidation case, we can improve it if you have any idea, otherwise, it
can be left to further optimization. :-)
Regards,
Wanpeng Li
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dax: fix deadlock in __dax_fault
On Thu, Sep 24, 2015 at 09:50:29AM -0600, Ross Zwisler wrote:
> On Thu, Sep 24, 2015 at 12:52:25PM +1000, Dave Chinner wrote:
> > On Wed, Sep 23, 2015 at 02:40:00PM -0600, Ross Zwisler wrote:
> > > Fix the deadlock exposed by xfstests generic/075. Here is the sequence
> > > that was causing us to deadlock:
> > >
> > > 1) enter __dax_fault()
> > > 2) page = find_get_page() gives us a page, so skip
> > > i_mmap_lock_write(mapping)
> > > 3) if (!buffer_mapped() && !buffer_unwritten() && !vmf->cow_page)
> > > passes, enter this block
> > > 4) if (vmf->flags & FAULT_FLAG_WRITE) fails, so do the else case and
> > > i_mmap_unlock_write(mapping);
> > > return dax_load_hole(mapping, page, vmf);
> > >
> > > This causes us to up_write() a semaphore that we weren't holding.
> > >
> > > The up_write() on a semaphore we didn't down_write() happens twice in
> > > a row, and then the next time we try and i_mmap_lock_write(), we hang.
> > >
> > > Signed-off-by: Ross Zwisler
> > > Reported-by: Dave Chinner
> > > ---
> > > fs/dax.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/fs/dax.c b/fs/dax.c
> > > index 7ae6df7..df1b0ac 100644
> > > --- a/fs/dax.c
> > > +++ b/fs/dax.c
> > > @@ -405,7 +405,8 @@ int __dax_fault(struct vm_area_struct *vma, struct
> > > vm_fault *vmf,
> > > if (error)
> > > goto unlock;
> > > } else {
> > > - i_mmap_unlock_write(mapping);
> > > + if (!page)
> > > + i_mmap_unlock_write(mapping);
> > > return dax_load_hole(mapping, page, vmf);
> > > }
> > > }
> >
> > I can't review this properly because I can't work out how this
> > locking is supposed to work. Captain, we have a Charlie Foxtrot
> > situation here:
> >
> > page = find_get_page(mapping, vmf->pgoff)
> > if (page) {
> >
> > } else {
> > i_mmap_lock_write(mapping);
> > }
> >
> > So if there's no page in the page cache, we lock the i_mmap_lock.
> > The we have the case the above patch fixes. Then later:
> >
> > if (vmf->cow_page) {
> > .
> > if (!page) {
> > /* can fall through */
> > }
> > return VM_FAULT_LOCKED;
> > }
> >
> > Which means __dax_fault() can also return here with the
> > i_mmap_lock_write() held. There's no documentation to indicate why
> > this is valid, and only by looking about 4 function calls higher up
> > the stack can I see that there's some attempt to handle this
> > *specific return condition* (in do_cow_fault()). That also is
> > lacking in documentation explaining the circumstances where we might
> > have the i_mmap_lock_write() held and have to release it. (Not to
> > mention the beautiful copy-n-waste of the unlock code, either.)
> >
> > The above code in __dax_fault() is then followed by this gem:
> >
> > /* Check we didn't race with a read fault installing a new page */
> > if (!page && major)
> > page = find_lock_page(mapping, vmf->pgoff);
> >
> > if (page) {
> > /* mapping invalidation */
> > }
> > .
> >
> > if (!page)
> > i_mmap_unlock_write(mapping);
> >
> > Which means that if we had a race with another read fault, we'll
> > remove the page from the page cache, insert the new direct mapped
> > pfn into the mapping, and *then fail to unlock the i_mmap lock*.
> >
> > Is this supposed to work this way? Or is it another bug?
> >
> > Another difficult question this change of locking raised that I
> > can't answer: is it valid to call into the filesystem via getblock()
> > or complete_unwritten() while holding the i_mmap_rwsem? This puts
> > filesystem transactions and locks inside the scope of i_mmap_rwsem,
> > which may have impact on the fact that we already have an inode lock
> > order dependency w.r.t. i_mmap_rwsem through truncate (and probably
> > other paths, too).
> >
> > So, please document the locking model, explain the corner cases and
> > the intricacies like why *unbalanced, return value conditional
> > locking* is necessary, and update the charts of lock order
> > dependencies in places like mm/filemap.c, and then we might have
> > some idea of how much of a train-wreck this actually is
>
> Yep, I saw these too, but didn't yet know how to deal with them. We have at
> similar issues with __dax_pmd_fault():
>
> i_mmap_lock_write(mapping);
> length = get_block(inode, block, , write);
> if (length)
> return VM_FAULT_SIGBUS;
>
> Whoops, we just took the mmap semaphore, and then we have a return that
> doesn't release it. A quick test confirms that this will deadlock the next
> fault that tries to take the mmap semaphore.
Ugh. So there's more than one broken commit and code path we are
talking about here.
Oh, even the "fallback" path is broken there - it
RE: [PATCH v10 3/5] CPM/QE: use genalloc to manage CPM/QE muram
On Fri, Sep 25, 2015 at 7:30 AM +0800, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, September 25, 2015 7:30 AM
> To: Zhao Qiang-B45475
> Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH v10 3/5] CPM/QE: use genalloc to manage CPM/QE muram
>
> On Wed, 2015-09-23 at 00:28 -0500, Zhao Qiang-B45475 wrote:
> > On Wen, Sep 23, 2015 at 12:03 AM +0800, Wood Scott-B07421 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 23, 2015 12:03 PM
> > > To: Zhao Qiang-B45475
> > > Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org;
> > > Li Yang-Leo-R58472; pau...@samba.org
> > > Subject: Re: [PATCH v10 3/5] CPM/QE: use genalloc to manage CPM/QE
> > > muram
> > >
> > > On Tue, 2015-09-22 at 21:20 -0500, Zhao Qiang-B45475 wrote:
> > > > On Wen, Sep 23, 2015 at 8:19 AM +0800, Wood Scott-B07421 wrote:
> > > >
> > > > > > > > {
> > > > > > > > - int ret;
> > > > > > > > +
> > > > > > > > + unsigned long start;
> > > > > > > > unsigned long flags;
> > > > > > > > + unsigned long size_alloc = size; struct muram_block
> > > > > > > > + *entry; int end_bit; int order =
> > > > > > > > + muram_pool->min_alloc_order;
> > > > > > > >
> > > > > > > > spin_lock_irqsave(_muram_lock, flags);
> > > > > > > > - ret = rh_free(_muram_info, offset);
> > > > > > > > + end_bit = (offset >> order) + ((size + (1UL << order) -
> > > > > > > > + 1)
> > > > > > > > + >>
> > > > > > > order);
> > > > > > > > + if ((offset + size) > (end_bit << order))
> > > > > > > > + size_alloc = size + (1UL << order);
> > > > > > >
> > > > > > > Why do you need to do all these calculations here?
> > > > > >
> > > > > > So do it in gen_pool_fixed_alloc?
> > > > >
> > > > > Could you explain why they're needed at all?
> > > >
> > > > Why it does the calculations?
> > > > If the min block of gen_pool is 8 bytes, and I want to allocate a
> > > > Region with offset=7, size=8bytes, I actually need block 0 and
> > > > block 1, And the allocation will give me block 0.
> > >
> > > How can you have offset 7 if the minimum order is 2 bytes?
> >
> > Offset has no relationship with minimum order, it is not decided by
> > minimum order.
>
> All allocations begin and end on a multiple of the minimum order.
So it is the problem. CPM require to allocate a specific region,
who can ensure that the specific is just the begin of minimum order.
So the algo will find the first block covering the specific region's
Start address, then because my specific region's start address is not equal
To the address returned by algo, the end address is not equal to my
specific region's end address, so the calculation is to keep the end
address larger than specific region's end address.
>
> > I want to allocate a specific region with offset=7, then algo to
> > calculate the block bit.
> > And I just take it for example, it is not I really need to region
> offset=7.
>
> Do you really need any fixed allocations that begin on an odd address?
Maybe I don’t need an odd address, but the calculation is needed in case.
>
> > So, now minimum order is 2 bytes. If offset=7, size=4bytes needed, it
> > actually allocate 6-12 to me.
>
> Why 6-12 and not 6-10?
It is just a example
-Zhao
Re: [regression] Re: Linux 4.3-rc1
On Wed, Sep 23, 2015 at 11:37 PM, Sedat Dilek wrote: > On Wed, Sep 23, 2015 at 10:48 PM, Sedat Dilek wrote: >> On Wed, Sep 23, 2015 at 3:31 PM, Shuah Khan wrote: >>> On 09/23/2015 02:56 AM, Daniel Vetter wrote: Another regression for Jairo to track. -Daniel >>> >>> Saw the same problem in 4.3-rc2 as well. Not a one time >>> deal and easily reproducible. >>> >> >> Looks like the patch "drm/i915: Add primary plane to mask if it's >> visible" is the correct fix. >> Did not try it. >> >> - sed@ - >> >> [1] >> http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes=721a09f7393de6c28a07516dccd654c6e995944a >> > > Pulled in d-i-f [1] on top of Linux v4.3-rc2 and the issue is gone. > The patch is now in Linus tree. - Sedat - [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=721a09f7393de6c28a07516dccd654c6e995944a > - sed@ - > > [1] http://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-fixes > >>> thanks, >>> -- Shuah On Tue, Sep 15, 2015 at 03:26:13AM +0200, Sedat Dilek wrote: > Hi, > > I have reported the same issue in [0]... > > You write in [1]... > > [ cut here ] > WARNING: CPU: 3 PID: 24 at drivers/gpu/drm/i915/intel_display.c:1377 > assert_planes_disabled+0xe4/0x150 [i915]() > plane A assertion failure, should be disabled but not > ... > > I can confirm this was not seen in v4.2 here on Ubuntu/precise AMD64. > > Regards, > - Sedat - > > [0] http://marc.info/?t=14417666342=1=2 > [1] http://marc.info/?l=linux-kernel=144227950327112=2 >>> >>> >>> -- >>> Shuah Khan >>> Sr. Linux Kernel Developer >>> Open Source Innovation Group >>> Samsung Research America (Silicon Valley) >>> shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/16] mm: sanitize page->mapping for tail pages
On Thu, Sep 24, 2015 at 05:51:04PM +0300, Kirill A. Shutemov wrote:
> We don't define meaning of page->mapping for tail pages. Currently it's
> always NULL, which can be inconsistent with head page and potentially lead
> to problems.
>
> Let's poison the pointer to catch all illigal uses.
>
> page_rmapping(), page_mapping() and page_anon_vma() are changed to look on
> head page.
>
> The only illegal use I've caught so far is __GPF_COMP pages from sound
> subsystem, mapped with PTEs. do_shared_fault() is changed to use
> page_rmapping() instead of direct access to fault_page->mapping.
>
> Signed-off-by: Kirill A. Shutemov
Just a nitpick but page_rmapping() is already using compound_head() and
thus commit message is missleading. I was expecting to see some changes
to page_rmapping(). Anyway:
Reviewed-by: Jérôme Glisse
> ---
> include/linux/poison.h | 4
> mm/huge_memory.c | 2 +-
> mm/memory.c| 2 +-
> mm/page_alloc.c| 6 ++
> mm/util.c | 10 ++
> 5 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/poison.h b/include/linux/poison.h
> index 317e16de09e5..76c3b6c38c16 100644
> --- a/include/linux/poison.h
> +++ b/include/linux/poison.h
> @@ -32,6 +32,10 @@
> /** mm/debug-pagealloc.c **/
> #define PAGE_POISON 0xaa
>
> +/** mm/page_alloc.c /
> +
> +#define TAIL_MAPPING ((void *) 0x01014A11 + POISON_POINTER_DELTA)
> +
> /** mm/slab.c **/
> /*
> * Magic nums for obj red zoning.
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 244c852d565c..65ab7858bbcc 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1836,7 +1836,7 @@ static void __split_huge_page_refcount(struct page
> *page,
> */
> page_tail->_mapcount = page->_mapcount;
>
> - BUG_ON(page_tail->mapping);
> + BUG_ON(page_tail->mapping != TAIL_MAPPING);
> page_tail->mapping = page->mapping;
>
> page_tail->index = page->index + i;
> diff --git a/mm/memory.c b/mm/memory.c
> index caecc64301e9..3bd465a6fa0d 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3087,7 +3087,7 @@ static int do_shared_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
>* pinned by vma->vm_file's reference. We rely on unlock_page()'s
>* release semantics to prevent the compiler from undoing this copying.
>*/
> - mapping = fault_page->mapping;
> + mapping = page_rmapping(fault_page);
> unlock_page(fault_page);
> if ((dirtied || vma->vm_ops->page_mkwrite) && mapping) {
> /*
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 321a91747949..9bcfd70b1eb8 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -473,6 +473,7 @@ void prep_compound_page(struct page *page, unsigned int
> order)
> for (i = 1; i < nr_pages; i++) {
> struct page *p = page + i;
> set_page_count(p, 0);
> + p->mapping = TAIL_MAPPING;
> set_compound_head(p, page);
> }
> }
> @@ -864,6 +865,10 @@ static int free_tail_pages_check(struct page *head_page,
> struct page *page)
> ret = 0;
> goto out;
> }
> + if (page->mapping != TAIL_MAPPING) {
> + bad_page(page, "corrupted mapping in tail page", 0);
> + goto out;
> + }
> if (unlikely(!PageTail(page))) {
> bad_page(page, "PageTail not set", 0);
> goto out;
> @@ -874,6 +879,7 @@ static int free_tail_pages_check(struct page *head_page,
> struct page *page)
> }
> ret = 0;
> out:
> + page->mapping = NULL;
> clear_compound_head(page);
> return ret;
> }
> diff --git a/mm/util.c b/mm/util.c
> index 9af1c12b310c..902b65a43899 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -355,7 +355,9 @@ struct anon_vma *page_anon_vma(struct page *page)
>
> struct address_space *page_mapping(struct page *page)
> {
> - unsigned long mapping;
> + struct address_space *mapping;
> +
> + page = compound_head(page);
>
> /* This happens if someone calls flush_dcache_page on slab page */
> if (unlikely(PageSlab(page)))
> @@ -368,10 +370,10 @@ struct address_space *page_mapping(struct page *page)
> return swap_address_space(entry);
> }
>
> - mapping = (unsigned long)page->mapping;
> - if (mapping & PAGE_MAPPING_FLAGS)
> + mapping = page->mapping;
> + if ((unsigned long)mapping & PAGE_MAPPING_FLAGS)
> return NULL;
> - return page->mapping;
> + return mapping;
> }
>
> int overcommit_ratio_handler(struct ctl_table *table, int write,
> --
> 2.5.1
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
To
Re: [PATCH v1 1/3] clocksource: rockchip: Make the driver more readability and compatible
Daniel,
在 2015年09月25日 08:25, Daniel Lezcano 写道:
Hi Caesar,
so thinking a bit more about this patch. I would like to split it into
two. One fixing the NO_IRQ and another fixing the dsb().
IIUC, the ARMv8 support is not yet ready and dsb() is not necessary as
a fix for the previous kernel version. However, the timer is used with
the ARMv7 boards and the NO_IRQ should be merged into tip-urgent.
I already done the fix and I am ready to submit it (for the timer
keystone also). So I suggest your resend the dsb() fix only.
Regarding the indentation, I prefer you do that in a separate patch by
cleaning up the macros (if relevant) or send the patch to trivial@
I know the indentation is trivial for this driver, but I just send the
patch v2.
-- Daniel
On 09/22/2015 07:15 AM, Caesar Wang wrote:
Hi Heiko,
在 2015年09月22日 22:00, Heiko Stübner 写道:
Hi Caesar,
Am Freitag, 18. September 2015, 16:51:09 schrieb Caesar Wang:
Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for rockchip.
logs:
...
drivers/clocksource/rockchip_timer.c:156:13: error: 'NO_IRQ'
undeclared
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at operand
1 --
`dsb`
...
The problem was different semantics of dsb on btw arm32 and arm64,
Here we can convert the dsb with insteading of dsb(sy).
NO_IRQ definition is missing for ARM64, since NO_IRQ being -1 is a
legacy thing for ARM - all ARM drivers are supposed to be converted to
use <= 0 or == 0 to detect invalid IRQs, and _eventually_ once all
users
are gone, NO_IRQ deleted. Modern drivers should _all_ be using !irq to
detect invalid IRQs, and not using NO_IRQ.
Meanwhile, I change a bit to make the code more readability for driver
when I check the code style.
Signed-off-by: Caesar Wang
---
Changes in v1:
- As Russell, Thomas, Daniel comments, let's replace NO_IRQ by '!irq'.
drivers/clocksource/rockchip_timer.c | 29
+++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/clocksource/rockchip_timer.c
b/drivers/clocksource/rockchip_timer.c index bb2c2b0..e1af449 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -17,16 +17,16 @@
#define TIMER_NAME "rk_timer"
-#define TIMER_LOAD_COUNT0 0x00
-#define TIMER_LOAD_COUNT1 0x04
-#define TIMER_CONTROL_REG 0x10
-#define TIMER_INT_STATUS 0x18
+#define TIMER_LOAD_COUNT00x00
+#define TIMER_LOAD_COUNT10x04
+#define TIMER_CONTROL_REG0x10
+#define TIMER_INT_STATUS0x18
-#define TIMER_DISABLE 0x0
-#define TIMER_ENABLE 0x1
-#define TIMER_MODE_FREE_RUNNING (0 << 1)
-#define TIMER_MODE_USER_DEFINED_COUNT (1 << 1)
-#define TIMER_INT_UNMASK (1 << 2)
+#define TIMER_DISABLE(0 << 0)
+#define TIMER_ENABLE(1 << 0)
+#define TIMER_MODE_FREE_RUNNING(0 << 1)
+#define TIMER_MODE_USER_DEFINED_COUNT(1 << 1)
+#define TIMER_INT_UNMASK(1 << 2)
not sure how Daniel sees this, but those could count as "unrelated
change", as
they have nothing to do with the arm64 build-fixes.
Yep, it's no related to the arm64 uild fixes.
I only make the code more readability for driver.
struct bc_timer {
struct clock_event_device ce;
@@ -49,14 +49,14 @@ static inline void __iomem *rk_base(struct
clock_event_device *ce) static inline void rk_timer_disable(struct
clock_event_device *ce) {
writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
-dsb();
+dsb(sy);
}
static inline void rk_timer_enable(struct clock_event_device *ce,
u32
flags) {
writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
rk_base(ce) + TIMER_CONTROL_REG);
-dsb();
+dsb(sy);
}
static void rk_timer_update_counter(unsigned long cycles,
@@ -64,13 +64,13 @@ static void rk_timer_update_counter(unsigned long
cycles, {
writel_relaxed(cycles, rk_base(ce) + TIMER_LOAD_COUNT0);
writel_relaxed(0, rk_base(ce) + TIMER_LOAD_COUNT1);
-dsb();
+dsb(sy);
}
static void rk_timer_interrupt_clear(struct clock_event_device *ce)
{
writel_relaxed(1, rk_base(ce) + TIMER_INT_STATUS);
-dsb();
+dsb(sy);
}
static inline int rk_timer_set_next_event(unsigned long cycles,
@@ -148,7 +148,7 @@ static void __init rk_timer_init(struct
device_node *np)
bc_timer.freq = clk_get_rate(timer_clk);
irq = irq_of_parse_and_map(np, 0);
-if (irq == NO_IRQ) {
+if (!irq) {
pr_err("Failed to map interrupts for '%s'\n", TIMER_NAME);
return;
}
@@ -173,4 +173,5 @@ static void __init rk_timer_init(struct
device_node *np)
clockevents_config_and_register(ce, bc_timer.freq, 1, UINT_MAX);
}
+
unnecessary addition of a blank line (same reasons as above)
It's the same reason with the above.
CHECK: Please use a blank line after function/struct/union/enum
declarations
#176: FILE: rockchip_timer.c:176:
+}
+CLOCKSOURCE_OF_DECLARE(rk_timer, "rockchip,rk3288-timer",
[PATCH v2 0/4] Support the timer on RK3368 SoC
Timer0~11 count up from zero to a programmed value and generate an interrupt when the count reaches the programmed value. TIMER0, TIMER1, TIMER2, Timer3, TIMER4 and TIMER5 are in the CPU subsystem, using timer ch0 ~ ch5 respectively. The timer clock is 24MHz OSC. This series are found on RK3368 SoC, verified on rk3368 evb board. Changes in v2: - As Heiko/Daniel comments, let's split it into two patch. Changes in v1: - As Russell, Thomas, Daniel comments, let's replace NO_IRQ by '!irq'. - As the Heiko comments, add the "rockchip,rk3368-timer" for timer. Although the 'rockchip,rk3288-timer' is working for RK3368, need to add the 'rockchip,rk3368-timer' for the rk3368-spec timer in the future. Caesar Wang (4): clocksource: rockchip: Make the driver more compatible clocksource: rockchip: trivial: Make the driver more readability arm64: Enable the timer on Rockchip architecture arm64: dts: rockchip: Add the needed timer for RK3368 SoC arch/arm64/Kconfig.platforms | 1 + arch/arm64/boot/dts/rockchip/rk3368.dtsi | 6 ++ drivers/clocksource/rockchip_timer.c | 27 ++- 3 files changed, 21 insertions(+), 13 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] arm64: dts: rockchip: Add the needed timer for RK3368 SoC
There is a need of a broadcast timer in this case to ensure proper
wakeup when the cpus are in sleep mode and a timer expires.
Signed-off-by: Caesar Wang
---
Changes in v2: None
Changes in v1:
- As the Heiko comments, add the "rockchip,rk3368-timer" for timer.
Although the 'rockchip,rk3288-timer' is working for RK3368, need to add the
'rockchip,rk3368-timer' for the rk3368-spec timer in the future.
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index a712bea..c4b3870 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -214,6 +214,12 @@
(GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ timer@ff81 {
+ compatible = "rockchip,rk3368-timer", "rockchip,rk3288-timer";
+ reg = <0x0 0xff81 0x0 0x20>;
+ interrupts = ;
+ };
+
xin24m: oscillator {
compatible = "fixed-clock";
clock-frequency = <2400>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] clocksource: rockchip: trivial: Make the driver more readability
Let's checkstyle to clean up the macros with such trivial details.
Signed-off-by: Caesar Wang
---
Changes in v2: None
Changes in v1: None
drivers/clocksource/rockchip_timer.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/clocksource/rockchip_timer.c
b/drivers/clocksource/rockchip_timer.c
index 3ace7ac..9ed662a 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -17,16 +17,16 @@
#define TIMER_NAME "rk_timer"
-#define TIMER_LOAD_COUNT0 0x00
-#define TIMER_LOAD_COUNT1 0x04
-#define TIMER_CONTROL_REG 0x10
-#define TIMER_INT_STATUS 0x18
+#define TIMER_LOAD_COUNT0 0x00
+#define TIMER_LOAD_COUNT1 0x04
+#define TIMER_CONTROL_REG 0x10
+#define TIMER_INT_STATUS 0x18
-#define TIMER_DISABLE 0x0
-#define TIMER_ENABLE 0x1
-#define TIMER_MODE_FREE_RUNNING (0 << 1)
-#define TIMER_MODE_USER_DEFINED_COUNT (1 << 1)
-#define TIMER_INT_UNMASK (1 << 2)
+#define TIMER_DISABLE 0x0
+#define TIMER_ENABLE 0x1
+#define TIMER_MODE_FREE_RUNNING(0 << 1)
+#define TIMER_MODE_USER_DEFINED_COUNT (1 << 1)
+#define TIMER_INT_UNMASK (1 << 2)
struct bc_timer {
struct clock_event_device ce;
@@ -173,4 +173,5 @@ static void __init rk_timer_init(struct device_node *np)
clockevents_config_and_register(ce, bc_timer.freq, 1, UINT_MAX);
}
+
CLOCKSOURCE_OF_DECLARE(rk_timer, "rockchip,rk3288-timer", rk_timer_init);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] clocksource: rockchip: Make the driver more compatible
Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for rockchip.
Says:
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at operand 1 --
`dsb`
...
The problem was different semantics of dsb on btw arm32 and arm64,
Here we can convert the dsb with insteading of dsb(sy).The "sy" param
is the default which you are allow to omit, so on arm32 dsb()and dsb(sy)
are the same.
Signed-off-by: Caesar Wang
---
Changes in v2:
- As Heiko/Daniel comments, let's split it into two patch.
Changes in v1:
- As Russell, Thomas, Daniel comments, let's replace NO_IRQ by '!irq'.
drivers/clocksource/rockchip_timer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clocksource/rockchip_timer.c
b/drivers/clocksource/rockchip_timer.c
index bb2c2b0..3ace7ac 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -49,14 +49,14 @@ static inline void __iomem *rk_base(struct
clock_event_device *ce)
static inline void rk_timer_disable(struct clock_event_device *ce)
{
writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
- dsb();
+ dsb(sy);
}
static inline void rk_timer_enable(struct clock_event_device *ce, u32 flags)
{
writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
rk_base(ce) + TIMER_CONTROL_REG);
- dsb();
+ dsb(sy);
}
static void rk_timer_update_counter(unsigned long cycles,
@@ -64,13 +64,13 @@ static void rk_timer_update_counter(unsigned long cycles,
{
writel_relaxed(cycles, rk_base(ce) + TIMER_LOAD_COUNT0);
writel_relaxed(0, rk_base(ce) + TIMER_LOAD_COUNT1);
- dsb();
+ dsb(sy);
}
static void rk_timer_interrupt_clear(struct clock_event_device *ce)
{
writel_relaxed(1, rk_base(ce) + TIMER_INT_STATUS);
- dsb();
+ dsb(sy);
}
static inline int rk_timer_set_next_event(unsigned long cycles,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] arm64: Enable the timer on Rockchip architecture
On the RK3368 SoC, support the APB timers for rockchip platform. Signed-off-by: Caesar Wang --- Changes in v2: None Changes in v1: None arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 23800a1..0dae08d 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -57,6 +57,7 @@ config ARCH_ROCKCHIP select ARCH_REQUIRE_GPIOLIB select PINCTRL select PINCTRL_ROCKCHIP + select ROCKCHIP_TIMER help This enables support for the ARMv8 based Rockchip chipsets, like the RK3368. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] zbud: allow up to PAGE_SIZE allocations
Hello, On Wed, Sep 23, 2015 at 04:57:26PM -0500, Seth Jennings wrote: > On Wed, Sep 23, 2015 at 09:54:02AM +0200, Vitaly Wool wrote: > > On Wed, Sep 23, 2015 at 5:18 AM, Seth Jennings > > wrote: > > > On Tue, Sep 22, 2015 at 02:17:33PM +0200, Vitaly Wool wrote: > > >> Currently zbud is only capable of allocating not more than > > >> PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE. This is okay as > > >> long as only zswap is using it, but other users of zbud may > > >> (and likely will) want to allocate up to PAGE_SIZE. This patch > > >> addresses that by skipping the creation of zbud internal > > >> structure in the beginning of an allocated page (such pages are > > >> then called 'headless'). > > > > > > I guess I'm having trouble with this. If you store a PAGE_SIZE > > > allocation in zbud, then the zpage can only have one allocation as there > > > is no room for a buddy. So... we have an allocator for that: the > > > page allocator. > > > > > > zbud doesn't support this by design because, if you are only storing one > > > allocation per page, you don't gain anything. > > > > > > This functionality creates many new edge cases for the code. > > > > > > What is this use case you envision? I think we need to discuss > > > whether the use case exists and if it justifies the added complexity. > > > > The use case is to use zram with zbud as allocator via the common > > zpool api. Sometimes determinism and better worst-case time are more > > important than high compression ratio. > > As far as I can see, I'm not the only one who wants this case > > supported in mainline. > > Ok, I can see that having the allocator backends for zpool > have the same set of constraints is nice. Sorry for delay. I'm on vacation until next week. It seems Seth was missed in previous discusstion which was not the end. I already said questions, opinion and concerns but anything is not clear until now. Only clear thing I could hear is just "compaction stats are better" which is not enough for me. Sorry. 1) https://lkml.org/lkml/2015/9/15/33 2) https://lkml.org/lkml/2015/9/21/2 Vitally, Please say what's the root cause of your problem and if it is external fragmentation, what's the problem of my approach? 1) make non-LRU page migrate 2) provide zsmalloc's migratpage We should provide it for CMA as well as external fragmentation. I think we could solve your issue with above approach and it fundamentally makes zsmalloc/zbud happy in future. Also, please keep it in mind that zram has been in linux kernel for memory efficiency for a long time and later zswap/zbud was born for *determinism* at the cost of memory efficiency. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] i2c: uniphier: add two I2C controller drivers for UniPhier SoC platform
Hi Wolfram, Could you have some time for reviewing this series? Perhaps, after ELCE? 2015-07-30 17:12 GMT+09:00 Masahiro Yamada : > > This series adds two I2C controller drivers. > (they are completely different IPs.) > > The first one is a very simple FIFO-less I2C controller, > which is used on some older UniPhier SoCs. > > The other one is higher-performance I2C controller with TX/RX FIFO, > used on newer UniPhier SoCs. > > > > Masahiro Yamada (3): > i2c: uniphier: add UniPhier FIFO-less I2C driver > i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver > i2c: uniphier: add bindings for UniPhier I2C controllers > > .../devicetree/bindings/i2c/i2c-uniphier.txt | 46 ++ > drivers/i2c/busses/Kconfig | 16 + > drivers/i2c/busses/Makefile| 2 + > drivers/i2c/busses/i2c-uniphier-f.c| 589 > + > drivers/i2c/busses/i2c-uniphier.c | 446 > 5 files changed, 1099 insertions(+) > create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier.txt > create mode 100644 drivers/i2c/busses/i2c-uniphier-f.c > create mode 100644 drivers/i2c/busses/i2c-uniphier.c > > -- > 1.9.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/19] dmaengine: xgene-dma: fix handling xgene_dma_get_ring_size result
On Thu, Sep 24, 2015 at 04:00:17PM +0200, Andrzej Hajda wrote: > The function can return negative value. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. This has a bad code indentation, which if you had ran checkpatch would have been found very easily. I have applied now with that fixed -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] perf probe: Fix module probing with shortname
From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org]
>> >Sent: Thursday, September 24, 2015 10:50 AM
>> >To: Wangnan (F)
>> >Cc: linux-kernel@vger.kernel.org; lize...@huawei.com; pi3or...@163.com;
>> >Namhyung Kim; Jiri Olsa; 平松雅巳 / HIRAMATU，MASAMI
>> >Subject: Re: [PATCH] perf probe: Fix module probing with shortname
>> >
>> >Em Wed, Sep 23, 2015 at 01:03:19PM -0300, Arnaldo Carvalho de Melo escreveu:
>> >> Em Tue, Sep 22, 2015 at 11:49:02PM -0300, Arnaldo Carvalho de Melo
>> >> escreveu:
>> >> > Em Wed, Sep 23, 2015 at 09:14:44AM +0800, Wangnan (F) escreveu:
>> >> > > On 2015/9/22 21:35, Arnaldo Carvalho de Melo wrote:
>> >> > > >Em Tue, Sep 22, 2015 at 03:34:32AM +, Wang Nan escreveu:
>> >> > > >>This is caused by a misunderstood of dso->kernel in
>> >> > > >>kernel_get_module_dso()
>> >> > > >>that, for kernel module, dso->kernel is DSO_TYPE_USER. dso->kernel
>> >> > > >>is DSO_TYPE_KERNEL
>> >> > > >>iff dso is vmlinux.
>> >> > > >Kernel modules having DSO_TYPE_USER seems to be the bug, no? I'll
>> >> > > >try to
>> >> > > >check that...
>> >
>> >> > > I also noticed this problem when I working on commit
>> >> > > 1f121b03d058dd07199d8924373d3c52a207f63b ("perf tools: Deal with
>> >> > > kernel module names in '[]' correctly") ;)
>> >
>> >> > Thanks for working on this, it is an area that needs cleaning up, too
>> >> > many ways to say what a dso is, will study your findings and try to come
>> >> > up with a patch proposal tomorrow.
>> >> > > So care must be taken.
>> >>
>> >> So, yes, there are multiple uses for this dso->kernel thing, we need to
>> >> look at each one and go on clarifying it so that this gets corrected and
>> >> sane, but I think we need some helpers to clarify all this, namely:
>> >>
>> >> Adding DSO_TYPE_KMODULE and DSO_TYPE_GUEST_KMODULE, setting
>> >> dso->kernel with it when loading host and guest kernel modules and
>> >> adding:
>> >>
>> >> bool dso__is_host_kernel(struct dso *dso)
>> >> bool dso__is_host_kmodule(struct dso *dso)
>> >>
>> >> bool dso__is_guest_kernel(struct dso *dso)
>> >
>> >So I tried this, ended up basically using __map__is_kernel(), in several
>> >places, which I think is right, and I've stashed in my tmp.perf/core
>> >branch so that you can take a look.
>> >
>> >But then I realized that we already have a better way to achieve what is
>> >needed in that function, see the patch below, fixed things for me:
>>
>> Hmm, this is a bit hacky, but yes, it looks good to me.
>
>You mean the [] dso->short_name part? But that was already being taken
>into account by the previous, dso list search.
Ah, OK. I didn't know that...
>But yeah, probably we should remove those brackets, anything requiring
>full disambiguation should use the dso->long_name anyway, but I'll
>leave this for later :)
OK, thanks,
>
>> However, I hope to have above solution, for future use.
>
>Right, my work now is to reduce the use of dso->kernel, using
>__map__is_kernel(map), we'll see what is left.
>
>> Acked-by: Masami Hiramatsu
>
>Thanks!
Thanks!
>
>> Thanks!
>>
>> >
>> >diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
>> >index 2b78e8f19b45..7fb0533ab18c 100644
>> >--- a/tools/perf/util/probe-event.c
>> >+++ b/tools/perf/util/probe-event.c
>> >@@ -269,12 +269,13 @@ static int kernel_get_module_dso(const char *module,
>> >struct dso **pdso)
>> >int ret = 0;
>> >
>> >if (module) {
>> >- list_for_each_entry(dso, _machine->dsos.head, node) {
>> >- if (!dso->kernel)
>> >- continue;
>> >- if (strncmp(dso->short_name + 1, module,
>> >- dso->short_name_len - 2) == 0)
>> >- goto found;
>> >+ char module_name[128];
>> >+
>> >+ snprintf(module_name, sizeof(module_name), "[%s]", module);
>> >+ map = map_groups__find_by_name(_machine->kmaps,
>> >MAP__FUNCTION, module_name);
>> >+ if (map) {
>> >+ dso = map->dso;
>> >+ goto found;
>> >}
>> >pr_debug("Failed to find module %s.\n", module);
>> >return -ENOENT;
RE: [PATCH v9 00/18] Add VT-d Posted-Interrupts support - including prerequisite series
Hi Paolo, Thanks for your review on this series! I'd like to confirm this series (plus the patch fixing the compilation error) is okay to you and I don't need to do extra things for it, right? Thanks, Feng > -Original Message- > From: Wu, Feng > Sent: Friday, September 18, 2015 10:30 PM > To: pbonz...@redhat.com; alex.william...@redhat.com; j...@8bytes.org; > mtosa...@redhat.com > Cc: eric.au...@linaro.org; k...@vger.kernel.org; > io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; Wu, Feng > Subject: [PATCH v9 00/18] Add VT-d Posted-Interrupts support - including > prerequisite series > > VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt. > With VT-d Posted-Interrupts enabled, external interrupts from > direct-assigned devices can be delivered to guests without VMM > intervention when guest is running in non-root mode. > > You can find the VT-d Posted-Interrtups Spec. in the following URL: > http://www.intel.com/content/www/us/en/intelligent-systems/intel-technolog > y/vt-directed-io-spec.html > > v9: > - Include the whole series: > [01/18]: irq bypasser manager > [02/18] - [06/18]: Common non-architecture part for VT-d PI and ARM side > forwarded irq > [07/18] - [18/18]: VT-d PI part > > v8: > refer to the changelog in each patch > > v7: > * Define two weak irq bypass callbacks: > - kvm_arch_irq_bypass_start() > - kvm_arch_irq_bypass_stop() > * Remove the x86 dummy implementation of the above two functions. > * Print some useful information instead of WARN_ON() when the > irq bypass consumer unregistration fails. > * Fix an issue when calling pi_pre_block and pi_post_block. > > v6: > * Rebase on 4.2.0-rc6 > * Rebase on https://lkml.org/lkml/2015/8/6/526 and > http://www.gossamer-threads.com/lists/linux/kernel/2235623 > * Make the add_consumer and del_consumer callbacks static > * Remove pointless INIT_LIST_HEAD to 'vdev->ctx[vector].producer.node)' > * Use dev_info instead of WARN_ON() when irq_bypass_register_producer fails > * Remove optional dummy callbacks for irq producer > > v4: > * For lowest-priority interrupt, only support single-CPU destination > interrupts at the current stage, more common lowest priority support > will be added later. > * Accoring to Marcelo's suggestion, when vCPU is blocked, we handle > the posted-interrupts in the HLT emulation path. > * Some small changes (coding style, typo, add some code comments) > > v3: > * Adjust the Posted-interrupts Descriptor updating logic when vCPU is > preempted or blocked. > * KVM_DEV_VFIO_DEVICE_POSTING_IRQ --> > KVM_DEV_VFIO_DEVICE_POST_IRQ > * __KVM_HAVE_ARCH_KVM_VFIO_POSTING --> > __KVM_HAVE_ARCH_KVM_VFIO_POST > * Add KVM_DEV_VFIO_DEVICE_UNPOST_IRQ attribute for VFIO irq, which > can be used to change back to remapping mode. > * Fix typo > > v2: > * Use VFIO framework to enable this feature, the VFIO part of this series is > base on Eric's patch "[PATCH v3 0/8] KVM-VFIO IRQ forward control" > * Rebase this patchset on > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git, > then revise some irq logic based on the new hierarchy irqdomain patches > provided > by Jiang Liu > > > *** BLURB HERE *** > > Alex Williamson (1): > virt: IRQ bypass manager > > Eric Auger (4): > KVM: arm/arm64: select IRQ_BYPASS_MANAGER > KVM: create kvm_irqfd.h > KVM: introduce kvm_arch functions for IRQ bypass > KVM: eventfd: add irq bypass consumer management > > Feng Wu (13): > KVM: x86: select IRQ_BYPASS_MANAGER > KVM: Extend struct pi_desc for VT-d Posted-Interrupts > KVM: Add some helper functions for Posted-Interrupts > KVM: Define a new interface kvm_intr_is_single_vcpu() > KVM: Make struct kvm_irq_routing_table accessible > KVM: make kvm_set_msi_irq() public > vfio: Register/unregister irq_bypass_producer > KVM: x86: Update IRTE for posted-interrupts > KVM: Implement IRQ bypass consumer callbacks for x86 > KVM: Add an arch specific hooks in 'struct kvm_kernel_irqfd' > KVM: Update Posted-Interrupts Descriptor when vCPU is preempted > KVM: Update Posted-Interrupts Descriptor when vCPU is blocked > iommu/vt-d: Add a command line parameter for VT-d posted-interrupts > > Documentation/kernel-parameters.txt | 1 + > Documentation/virtual/kvm/locking.txt | 12 ++ > MAINTAINERS | 7 + > arch/arm/kvm/Kconfig | 2 + > arch/arm/kvm/Makefile | 1 + > arch/arm64/kvm/Kconfig| 2 + > arch/arm64/kvm/Makefile | 1 + > arch/x86/include/asm/kvm_host.h | 24 +++ > arch/x86/kvm/Kconfig | 3 + > arch/x86/kvm/Makefile | 3 + > arch/x86/kvm/irq_comm.c | 32 ++- > arch/x86/kvm/lapic.c | 59 ++ > arch/x86/kvm/lapic.h | 2 + > arch/x86/kvm/trace.h | 33 > arch/x86/kvm/vmx.c| 361 > +- >
Re: [PATCH] dmaengine: pxa_dma: fix initial list move
On Thu, Sep 24, 2015 at 09:39:32PM +0200, Robert Jarzmik wrote: > Vinod Koul writes: > > > On Mon, Sep 21, 2015 at 11:06:32AM +0200, Robert Jarzmik wrote: > >> Since the commit to have an allocated list of virtual descriptors was > >> reverted, the pxa_dma driver is broken, as it assumes the descriptor is > >> placed on the allocated list upon allocation. > >> > >> Fix the issue in pxa_dma by making an allocated virtual descriptor a > >> singleton. > > > > This seems okay, simpler and safer. Do you want me to apply this instead > > while detailed approach can be reviewed and discussed > Yes, please. Having the guarantee this gets into the next or next after next > -rc > will enable me to do my pull request, and repair pxa. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Thermal management updates for v4.3-rc3
Hi, Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next to receive the latest Thermal Management updates for 4.3-rc3 with top-most commit 97584d1838b7e2545c3b10aacef3327fcaa9531b: thermal: power_allocator: exit early if there are no cooling devices (2015-09-20 15:37:16 +0800) on top of commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) Specifics: - Power allocator governor changes to allow binding on thermal zones with missing power estimates information. From: Javi Merino. - Add compile test flags on thermal drivers that allow it without producing compilation errors. From: Eduardo Valentin. - Fixes around memory allocation on cpu_cooling. From: Javi Merino. - Fix on db8500 cpufreq code to allow autoload. From: Luis de Bethencourt. - Maintainer entries for cpu cooling device. thanks, rui Eduardo Valentin (10): thermal: hisi: allow compile test thermal: spear: allow compile test thermal: rockchip: allow compile test thermal: kirkwood: allow compile test thermal: dove: allow compile test thermal: armada: allow compile test thermal: exynos: allow compile test thermal: qcom_spmi: allow compile test thermal: ti-soc: allow compile test thermal: ti-soc: Kconfig fix to avoid menu showing wrongly Javi Merino (7): thermal: cpu_cooling: don't call kcalloc() under rcu_read_lock thermal: cpu_cooling: free power table on error or when unregistering thermal: Add a function to get the minimum power thermal: power_allocator: relax the requirement of a sustainable_power in tzp thermal: power_allocator: relax the requirement of two passive trip points thermal: power_allocator: don't require tzp to be present for the thermal zone thermal: power_allocator: exit early if there are no cooling devices Luis de Bethencourt (1): thermal: db8500_cpufreq_cooling: Fix module autoload for OF platform driver Punit Agrawal (1): thermal: Fix thermal_zone_of_sensor_register to match documentation Viresh Kumar (1): thermal: cpu_cooling: Add MAINTAINERS entry Documentation/thermal/power_allocator.txt | 2 +- MAINTAINERS | 10 ++ drivers/thermal/Kconfig | 17 ++- drivers/thermal/cpu_cooling.c | 52 --- drivers/thermal/db8500_cpufreq_cooling.c | 1 + drivers/thermal/power_allocator.c | 243 ++ drivers/thermal/thermal_core.c| 28 drivers/thermal/ti-soc-thermal/Kconfig| 8 +- include/linux/thermal.h | 8 +- 9 files changed, 269 insertions(+), 100 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
netlink: Add barrier to netlink_connect for theoretical case
On Thu, Sep 24, 2015 at 04:05:10PM -0400, Tejun Heo wrote:
>
> > I've decided to apply this and queue it up for -stable.
Thanks Dave!
> This is mostly correct; however, if there are or can be in-kernel
> users which create the client side of netlink socket, it isn't. Let's
> say such in-kernel user does kernel_connect() and then query the
> assigned port number by kernel_getsockname(). That can just return
> zero. Maybe such scenario is not possible for some combination of
> reasons but why leak this level of synchronization detail to the users
> in the first place? This should be terminated from the site where
> such synchronization scheme is implemented. This expands the scope of
> correctness verification to all possible users of these functions.
Well had you said this in the first place I would've fixed it a
long time ago. There aren't any in-kernel users right now and
even if there were they'd have to do a connect/bind/sendmsg on
the same socket in two threads at the same time. But let's close
this theoretical hole:
---8<---
If a netlink_connect call is followed by a netlink_getname call
the portid returned may not be up-to-date. This patch adds a
barrier for that case.
As all nlk->bound dereferences now have barriers this patch also
adds a netlink_bound helper to encapsulate the barrier, as was
suggested by Tejun.
Fixes: da314c9923fe ("netlink: Replace rhash_portid with bound")
Reported-by: Tejun Heo
Signed-off-by: Herbert Xu
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 2c15fae..02121e1 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -125,6 +125,15 @@ static inline u32 netlink_group_mask(u32 group)
return group ? 1 << (group - 1) : 0;
}
+static inline bool netlink_bound(struct netlink_sock *nlk)
+{
+ /* Ensure nlk is hashed and visible. */
+ if (nlk->bound)
+ smp_rmb();
+
+ return nlk->bound;
+}
+
int netlink_add_tap(struct netlink_tap *nt)
{
if (unlikely(nt->dev->type != ARPHRD_NETLINK))
@@ -1524,14 +1533,10 @@ static int netlink_bind(struct socket *sock, struct
sockaddr *addr,
return err;
}
- bound = nlk->bound;
- if (bound) {
- /* Ensure nlk->portid is up-to-date. */
- smp_rmb();
-
+ bound = netlink_bound(nlk);
+ if (bound)
if (nladdr->nl_pid != nlk->portid)
return -EINVAL;
- }
if (nlk->netlink_bind && groups) {
int group;
@@ -1547,9 +1552,6 @@ static int netlink_bind(struct socket *sock, struct
sockaddr *addr,
}
}
- /* No need for barriers here as we return to user-space without
-* using any of the bound attributes.
-*/
if (!bound) {
err = nladdr->nl_pid ?
netlink_insert(sk, nladdr->nl_pid) :
@@ -1598,10 +1600,7 @@ static int netlink_connect(struct socket *sock, struct
sockaddr *addr,
!netlink_allowed(sock, NL_CFG_F_NONROOT_SEND))
return -EPERM;
- /* No need for barriers here as we return to user-space without
-* using any of the bound attributes.
-*/
- if (!nlk->bound)
+ if (!netlink_bound(nlk))
err = netlink_autobind(sock);
if (err == 0) {
@@ -2442,13 +2441,10 @@ static int netlink_sendmsg(struct socket *sock, struct
msghdr *msg, size_t len)
dst_group = nlk->dst_group;
}
- if (!nlk->bound) {
+ if (!netlink_bound(nlk)) {
err = netlink_autobind(sock);
if (err)
goto out;
- } else {
- /* Ensure nlk is hashed and visible. */
- smp_rmb();
}
/* It's a really convoluted way for userland to ask for mmaped
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes
On 24/09/15 12:17, Russell King - ARM Linux wrote: > Hi, > > The third version of this series fixes the build error which David > identified, and drops the broken changes for the Cavium Thunger BGX > ethernet driver as this driver requires some complex changes to > resolve the leakage - and this is best done by people who can test > the driver. > > Compared to v2, the only patch which has changed is patch 6 > "net: fix phy refcounting in a bunch of drivers" > > I _think_ I've been able to build-test all the drivers touched by > that patch to some degree now, though several of them needed the > Kconfig hacked to allow it (not all had || COMPILE_TEST clause on > their dependencies.) Tested-by: Florian Fainelli Reviewed-by: Florian Fainelli Thanks for fixing that. > > Previous cover letters below: > > This is the second version of the series, with the comments David had > on the first patch fixed up. Original series description with updated > diffstat below. > > While looking at the DSA code, I noticed we have a > of_find_net_device_by_node(), and it looks like users of that are > similarly buggy - it looks like net/dsa/dsa.c is the only user. Fix > that too. > > Hi, > > While looking at the phy code, I identified a number of weaknesses > where refcounting on device structures was being leaked, where > modules could be removed while in-use, and where the fixed-phy could > end up having unintended consequences caused by incorrect calls to > fixed_phy_update_state(). > > This patch series resolves those issues, some of which were discovered > with testing on an Armada 388 board. Not all patches are fully tested, > particularly the one which touches several network drivers. > > When resolving the struct device refcounting problems, several different > solutions were considered before settling on the implementation here - > one of the considerations was to avoid touching many network drivers. > The solution here is: > > phy_attach*() - takes a refcount > phy_detach*() - drops the phy_attach refcount > > Provided drivers always attach and detach their phys, which they should > already be doing, this should change nothing, even if they leak a refcount. > > of_phy_find_device() and of_* functions which use that take > a refcount. Arrange for this refcount to be dropped once > the phy is attached. > > This is the reason why the previous change is important - we can't drop > this refcount taken by of_phy_find_device() until something else holds > a reference on the device. This resolves the leaked refcount caused by > using of_phy_connect() or of_phy_attach(). > > Even without the above changes, these drivers are leaking by calling > of_phy_find_device(). These drivers are addressed by adding the > appropriate release of that refcount. > > The mdiobus code also suffered from the same kind of leak, but thankfully > this only happened in one place - the mdio-mux code. > > I also found that the try_module_get() in the phy layer code was utterly > useless: phydev->dev.driver was guaranteed to always be NULL, so > try_module_get() was always being called with a NULL argument. I proved > this with my SFP code, which declares its own MDIO bus - the module use > count was never incremented irrespective of how I set the MDIO bus up. > This allowed the MDIO bus code to be removed from the kernel while there > were still PHYs attached to it. > > One other bug was discovered: while using in-band-status with mvneta, it > was found that if a real phy is attached with in-band-status enabled, > and another ethernet interface is using the fixed-phy infrastructure, the > interface using the fixed-phy infrastructure is configured according to > the other interface using the in-band-status - which is caused by the > fixed-phy code not verifying that the phy_device passed in is actually > a fixed-phy device, rather than a real MDIO phy. > > Lastly, having mdio_bus reversing phy_device_register() internals seems > like a layering violation - it's trivial to move that code to the phy > device layer. > > drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 24 ++ > drivers/net/ethernet/freescale/gianfar.c | 6 ++- > drivers/net/ethernet/freescale/ucc_geth.c | 8 +++- > drivers/net/ethernet/marvell/mvneta.c | 2 + > drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 + > drivers/net/phy/fixed_phy.c| 2 +- > drivers/net/phy/mdio-mux.c | 19 +--- > drivers/net/phy/mdio_bus.c | 24 ++ > drivers/net/phy/phy_device.c | 62 > -- > drivers/of/of_mdio.c | 27 +-- > include/linux/phy.h| 6 ++- > net/core/net-sysfs.c | 9 > net/dsa/dsa.c | 41 ++--- > 13 files changed, 181 insertions(+), 51 deletions(-) >
[PATCH] soc: qcom: smd: Reject send of too big packets
Attempting to find room for a packet that's bigger than the fifo will never succeed and the calling process will be sleeping forever in the loop, waiting for enough room. So fail early instead. Reported-by: Courtney Cavin Signed-off-by: Bjorn Andersson --- drivers/soc/qcom/smd.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c index 18964f154383..88353bda1ea4 100644 --- a/drivers/soc/qcom/smd.c +++ b/drivers/soc/qcom/smd.c @@ -723,6 +723,10 @@ int qcom_smd_send(struct qcom_smd_channel *channel, const void *data, int len) if (channel->info_word && len % 4) return -EINVAL; + /* Reject packets that are too big */ + if (tlen >= channel->fifo_size) + return -EINVAL; + ret = mutex_lock_interruptible(>tx_lock); if (ret) return ret; -- 1.8.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: move aliases back to .dts in Cygnus
On 24/09/15 15:21, Ray Jui wrote: > Move aliases from bcm-cygnus.dtsi back to individual .dts files. Also > clean up the chosen node to have the stdout-path using the proper alias > > Signed-off-by: Ray Jui Applied to devicetree/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] dt-binding: soc: qcom: Introduce qcom,smp2p binding documentation
Introduce binding documentation for the Qualcomm Shared Memory Point 2 Point
protocol.
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- No longer representing outgoing state as gpio-controller
.../devicetree/bindings/soc/qcom/qcom,smp2p.txt| 104 +
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
new file mode 100644
index ..5cc82b8353d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
@@ -0,0 +1,104 @@
+Qualcomm Shared Memory Point 2 Point binding
+
+The Shared Memory Point to Point (SMP2P) protocol facilitates communication of
+a single 32-bit value between two processors. Each value has a single writer
+(the local side) and a single reader (the remote side). Values are uniquely
+identified in the system by the directed edge (local processor ID to remote
+processor ID) and a string identifier.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,smp2p"
+
+- interrupts:
+ Usage: required
+ Value type:
+ Definition: one entry specifying the smp2p notification interrupt
+
+- qcom,ipc:
+ Usage: required
+ Value type:
+ Definition: three entries specifying the outgoing ipc bit used for
+ signaling the remote end of the smp2p edge:
+ - phandle to a syscon node representing the apcs registers
+ - u32 representing offset to the register within the syscon
+ - u32 representing the ipc bit within the register
+
+- qcom,smem:
+ Usage: required
+ Value type:
+ Definition: two identifiers of the inbound and outbound smem items used
+ for this edge
+
+- qcom,local-pid:
+ Usage: required
+ Value type:
+ Definition: specifies the identfier of the local endpoint of this edge
+
+- qcom,remote-pid:
+ Usage: required
+ Value type:
+ Definition: specifies the identfier of the remote endpoint of this edge
+
+= SUBNODES
+Each SMP2P pair contain a set of inbound and outbound entries, these are
+described in subnodes of the smp2p device node. The node names are not
+important.
+
+- qcom,entry-name:
+ Usage: required
+ Value type:
+ Definition: specifies the name of this entry, for inbound entries this
+ will be used to match against the remotely allocated entry
+ and for outbound entries this name is used for allocating
+ entries
+
+- interrupt-controller:
+ Usage: required for incoming entries
+ Value type:
+ Definition: marks the entry as inbound; the node should be specified
+ as a two cell interrupt-controller as defined in
+ "../interrupt-controller/interrupts.txt"
+ If not specified this node will denote the outgoing entry
+
+- #interrupt-cells:
+ Usage: required for incoming entries
+ Value type:
+ Definition: must be 2 - denoting the bit in the entry and IRQ flags
+
+- #qcom,state-cells:
+ Usage: required for outgoing entries
+ Value type:
+ Definition: must be 1 - denoting the bit in the entry
+
+= EXAMPLE
+The following example shows the SMP2P setup with the wireless processor,
+defined from the 8974 apps processor's point-of-view. It encompasses one
+inbound and one outbound entry:
+
+wcnss-smp2p {
+ compatible = "qcom,smp2p";
+ qcom,smem = <431>, <451>;
+
+ interrupts = <0 143 1>;
+
+ qcom,ipc = < 8 18>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <4>;
+
+ wcnss_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+
+ #qcom,state-cells = <1>;
+ };
+
+ wcnss_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+};
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] soc: qcom: smsm: Add driver for Qualcomm SMSM
This driver exposed the Qualcomm Shared Memory State Machine bits.
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Use the newly created smem state helper instead of gpiolib
drivers/soc/qcom/Kconfig | 8 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/smsm.c | 625 ++
3 files changed, 634 insertions(+)
create mode 100644 drivers/soc/qcom/smsm.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 68b261677046..015baf47874c 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -51,3 +51,11 @@ config QCOM_SMD_RPM
config QCOM_SMEM_STATE
bool
+
+config QCOM_SMSM
+ bool "Qualcomm Shared Memory State Machine"
+ depends on QCOM_SMEM
+ select QCOM_SMEM_STATE
+ help
+ Say yes here to support the Qualcomm Shared Memory State Machine.
+ The state machine is represented by bits in shared memory.
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index d756033a4630..452c505dafe4 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_QCOM_SMD) += smd.o
obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
obj-$(CONFIG_QCOM_SMEM) += smem.o
obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
+obj-$(CONFIG_QCOM_SMSM)+= smsm.o
diff --git a/drivers/soc/qcom/smsm.c b/drivers/soc/qcom/smsm.c
new file mode 100644
index ..6b777af1bc19
--- /dev/null
+++ b/drivers/soc/qcom/smsm.c
@@ -0,0 +1,625 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * This driver implements the Qualcomm Shared Memory State Machine, a mechanism
+ * for communicating single bit state information to remote processors.
+ *
+ * The implementation is based on two sections of shared memory; the first
+ * holding the state bits and the second holding a matrix of subscription bits.
+ *
+ * The state bits are structured in entries of 32 bits, each belonging to one
+ * system in the SoC. The entry belonging to the local system is considered
+ * read-write, while the rest should be considered read-only.
+ *
+ * The subscription matrix consists of N bitmaps per entry, denoting interest
+ * in updates of the entry for each of the N hosts. Upon updating a state bit
+ * each host's subscription bitmap should be queried and the remote system
+ * should be interrupted if they request so.
+ *
+ * The subscription matrix is laid out in entry-major order:
+ * entry0: [host0 ... hostN]
+ * .
+ * .
+ * entryM: [host0 ... hostN]
+ *
+ * A third, optional, shared memory region might contain information regarding
+ * the number of entries in the state bitmap as well as number of columns in
+ * the subscription matrix.
+ */
+
+/*
+ * Shared memory identifiers, used to acquire handles to respective memory
+ * region.
+ */
+#define SMEM_SMSM_SHARED_STATE 85
+#define SMEM_SMSM_CPU_INTR_MASK333
+#define SMEM_SMSM_SIZE_INFO419
+
+/*
+ * Default sizes, in case SMEM_SMSM_SIZE_INFO is not found.
+ */
+#define SMSM_DEFAULT_NUM_ENTRIES 8
+#define SMSM_DEFAULT_NUM_HOSTS 3
+
+struct smsm_entry;
+struct smsm_host;
+
+/**
+ * struct qcom_smsm - smsm driver context
+ * @dev: smsm device pointer
+ * @local_host:column in the subscription matrix representing this
system
+ * @num_hosts: number of columns in the subscription matrix
+ * @num_entries: number of entries in the state map and rows in the
subscription
+ * matrix
+ * @local_state: pointer to the local processor's state bits
+ * @subscription: pointer to local processor's row in subscription matrix
+ * @state: smem state handle
+ * @lock: spinlock for read-modify-write of the outgoing state
+ * @entries: context for each of the entries
+ * @hosts: context for each of the hosts
+ */
+struct qcom_smsm {
+ struct device *dev;
+
+ u32 local_host;
+
+ u32 num_hosts;
+ u32 num_entries;
+
+ u32 *local_state;
+ u32 *subscription;
+ struct qcom_smem_state *state;
+
+ spinlock_t lock;
+
+ struct smsm_entry *entries;
+ struct smsm_host *hosts;
+};
+
+/**
+ * struct smsm_entry - per remote processor entry context
+ * @smsm: back-reference to driver context
+ * @domain:IRQ domain for this entry, if
[PATCH v2 3/5] soc: qcom: Introduce common SMEM state machine code
This implements a common API for handling and exposing SMP2P and SMSM
state information.
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Introduced this file with stuff we previously got free from gpiolib
drivers/soc/qcom/Kconfig| 3 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/smem_state.c | 201
include/linux/soc/qcom/smem_state.h | 18
4 files changed, 223 insertions(+)
create mode 100644 drivers/soc/qcom/smem_state.c
create mode 100644 include/linux/soc/qcom/smem_state.h
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 3e4d2133c3d2..68b261677046 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -48,3 +48,6 @@ config QCOM_SMD_RPM
Say M here if you want to include support for the Qualcomm RPM as a
module. This will build a module called "qcom-smd-rpm".
+
+config QCOM_SMEM_STATE
+ bool
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 10a93d168e0e..d756033a4630 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_QCOM_PM) += spm.o
obj-$(CONFIG_QCOM_SMD) += smd.o
obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
obj-$(CONFIG_QCOM_SMEM) += smem.o
+obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
diff --git a/drivers/soc/qcom/smem_state.c b/drivers/soc/qcom/smem_state.c
new file mode 100644
index ..54261decb369
--- /dev/null
+++ b/drivers/soc/qcom/smem_state.c
@@ -0,0 +1,201 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+static LIST_HEAD(smem_states);
+static DEFINE_MUTEX(list_lock);
+
+/**
+ * struct qcom_smem_state - state context
+ * @refcount: refcount for the state
+ * @orphan:boolean indicator that this state has been unregistered
+ * @list: entry in smem_states list
+ * @of_node: of_node to use for matching the state in DT
+ * @priv: implementation private data
+ * @ops: ops for the state
+ */
+struct qcom_smem_state {
+ struct kref refcount;
+ bool orphan;
+
+ struct list_head list;
+ struct device_node *of_node;
+
+ void *priv;
+
+ struct qcom_smem_state_ops ops;
+};
+
+/**
+ * qcom_smem_state_update_bits() - update the masked bits in state with value
+ * @state: state handle acquired by calling qcom_smem_state_get()
+ * @mask: bit mask for the change
+ * @value: new value for the masked bits
+ *
+ * Returns 0 on success, otherwise negative errno.
+ */
+int qcom_smem_state_update_bits(struct qcom_smem_state *state,
+ u32 mask,
+ u32 value)
+{
+ if (state->orphan)
+ return -ENXIO;
+
+ if (!state->ops.update_bits)
+ return -ENOTSUPP;
+
+ return state->ops.update_bits(state->priv, mask, value);
+}
+EXPORT_SYMBOL_GPL(qcom_smem_state_update_bits);
+
+static struct qcom_smem_state *of_node_to_state(struct device_node *np)
+{
+ struct qcom_smem_state *state;
+
+ mutex_lock(_lock);
+
+ list_for_each_entry(state, _states, list) {
+ if (state->of_node == np) {
+ kref_get(>refcount);
+ goto unlock;
+ }
+ }
+ state = ERR_PTR(-EPROBE_DEFER);
+
+unlock:
+ mutex_unlock(_lock);
+
+ return state;
+}
+
+/**
+ * qcom_smem_state_get() - acquire handle to a state
+ * @dev: client device pointer
+ * @con_id:name of the state to lookup
+ * @bit: flags from the state reference, indicating which bit's affected
+ *
+ * Returns handle to the state, or ERR_PTR(). qcom_smem_state_put() must be
+ * called to release the returned state handle.
+ */
+struct qcom_smem_state *qcom_smem_state_get(struct device *dev,
+ const char *con_id,
+ unsigned *bit)
+{
+ struct qcom_smem_state *state;
+ struct of_phandle_args args;
+ int index = 0;
+ int ret;
+
+ if (con_id) {
+ index = of_property_match_string(dev->of_node,
+"qcom,state-names",
+con_id);
+ if (index < 0) {
+ dev_err(dev, "missing
[PATCH v2 0/5] Qualcomm Shared Memory State Machines
This series implements the two different mechanisms for propagating single bit state information, used on the various Qualcomm platforms. The system was traditionally used by the modem and application processor to convey information about boot progress, power states, error handling and so on. This was implemented as SMSM, with status bits representing a single local state. As the complexity of the SoC grew the state bits array grew and the need for targeting specific state information at specific remote processors appeared. SMP2P solves this by having separate shared memory regions per processor-pair. This state information is e.g. used to convey progress and status of remote firmware loading. Individual bits maps to various stages of the boot and error states. Changed since v1: - The series moved away from representing outgoing bits as gpios Bjorn Andersson (5): dt-binding: soc: qcom: Add Qualcomm SMSM device tree documentation dt-binding: soc: qcom: Introduce qcom,smp2p binding documentation soc: qcom: Introduce common SMEM state machine code soc: qcom: smsm: Add driver for Qualcomm SMSM soc: qcom: smp2p: Qualcomm Shared Memory Point to Point .../devicetree/bindings/soc/qcom/qcom,smp2p.txt| 104 .../devicetree/bindings/soc/qcom/qcom,smsm.txt | 104 drivers/soc/qcom/Kconfig | 19 + drivers/soc/qcom/Makefile | 3 + drivers/soc/qcom/smem_state.c | 201 +++ drivers/soc/qcom/smp2p.c | 578 +++ drivers/soc/qcom/smsm.c| 625 + include/linux/soc/qcom/smem_state.h| 18 + 8 files changed, 1652 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt create mode 100644 drivers/soc/qcom/smem_state.c create mode 100644 drivers/soc/qcom/smp2p.c create mode 100644 drivers/soc/qcom/smsm.c create mode 100644 include/linux/soc/qcom/smem_state.h -- 1.8.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/5] dt-binding: soc: qcom: Add Qualcomm SMSM device tree documentation
This documents a device tree binding for the Qualcomm Shared Memory
State Machine.
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- No longer representing outgoing state as gpio-controller
.../devicetree/bindings/soc/qcom/qcom,smsm.txt | 104 +
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt
new file mode 100644
index ..a6634c70850d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt
@@ -0,0 +1,104 @@
+Qualcomm Shared Memory State Machine
+
+The Shared Memory State Machine facilitates broadcasting of single bit state
+information between the processors in a Qualcomm SoC. Each processor is
+assigned 32 bits of state that can be modified. A processor can through a
+matrix of bitmaps signal subscription of notifications upon changes to a
+certain bit owned by a certain remote processor.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,smsm"
+
+- qcom,ipc-N:
+ Usage: required
+ Value type:
+ Definition: three entries specifying the outgoing ipc bit used for
+ signaling the N:th remote processor
+ - phandle to a syscon node representing the apcs registers
+ - u32 representing offset to the register within the syscon
+ - u32 representing the ipc bit within the register
+
+- qcom,local-host:
+ Usage: optional
+ Value type:
+ Definition: identifier of the local processor in the list of hosts, or
+ in other words specifier of the column in the subscription
+ matrix representing the local processor
+ defaults to host 0
+
+- #address-cells:
+ Usage: required
+ Value type:
+ Definition: must be 1
+
+- #size-cells:
+ Usage: required
+ Value type:
+ Definition: must be 0
+
+= SUBNODES
+Each processor's state bits are described by a subnode of the smsm device node.
+Nodes can either be flagged as an interrupt-controller to denote a remote
+processor's state bits or the local processors bits. The node names are not
+important.
+
+- reg:
+ Usage: required
+ Value type:
+ Definition: specifies the offset, in words, of the first bit for this
+ entry
+
+- #qcom,state-cells:
+ Usage: required for local entry
+ Value type:
+ Definition: must be 1 - denotes bit number
+
+- interrupt-controller:
+ Usage: required for remote entries
+ Value type:
+ Definition: marks the entry as a interrupt-controller and the state bits
+ to belong to a remote processor
+
+- #interrupt-cells:
+ Usage: required for remote entries
+ Value type:
+ Definition: must be 2 - denotes bit number and IRQ flags
+
+- interrupts:
+ Usage: required for remote entries
+ Value type:
+ Definition: one entry specifying remote IRQ used by the remote processor
+ to signal changes of its state bits
+
+
+= EXAMPLE
+The following example shows the SMEM setup for controlling properties of the
+wireless processor, defined from the 8974 apps processor's point-of-view. It
+encompasses one outbound entry and the outgoing interrupt for the wireless
+processor.
+
+smsm {
+ compatible = "qcom,smsm";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ qcom,ipc-3 = < 8 19>;
+
+ apps_smsm: apps@0 {
+ reg = <0>;
+
+ #qcom,state-cells = <1>;
+ };
+
+ wcnss_smsm: wcnss@7 {
+ reg = <7>;
+ interrupts = <0 144 1>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+};
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/5] soc: qcom: smp2p: Qualcomm Shared Memory Point to Point
Introduce the Qualcomm Shard Memory Point to Point driver.
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Use the newly created smem state helper instead of gpiolib
drivers/soc/qcom/Kconfig | 8 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/smp2p.c | 578 ++
3 files changed, 587 insertions(+)
create mode 100644 drivers/soc/qcom/smp2p.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 015baf47874c..7fc0d08c6f14 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -52,6 +52,14 @@ config QCOM_SMD_RPM
config QCOM_SMEM_STATE
bool
+config QCOM_SMP2P
+ bool "Qualcomm Shared Memory Point to Point support"
+ depends on QCOM_SMEM
+ select QCOM_SMEM_STATE
+ help
+ Say yes here to support the Qualcomm Shared Memory Point to Point
+ protocol.
+
config QCOM_SMSM
bool "Qualcomm Shared Memory State Machine"
depends on QCOM_SMEM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 452c505dafe4..69886e0f7ef8 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -4,4 +4,5 @@ obj-$(CONFIG_QCOM_SMD) += smd.o
obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
obj-$(CONFIG_QCOM_SMEM) += smem.o
obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
+obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
obj-$(CONFIG_QCOM_SMSM)+= smsm.o
diff --git a/drivers/soc/qcom/smp2p.c b/drivers/soc/qcom/smp2p.c
new file mode 100644
index ..f1eed7f9dd67
--- /dev/null
+++ b/drivers/soc/qcom/smp2p.c
@@ -0,0 +1,578 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications AB.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * The Shared Memory Point to Point (SMP2P) protocol facilitates communication
+ * of a single 32-bit value between two processors. Each value has a single
+ * writer (the local side) and a single reader (the remote side). Values are
+ * uniquely identified in the system by the directed edge (local processor ID
+ * to remote processor ID) and a string identifier.
+ *
+ * Each processor is responsible for creating the outgoing SMEM items and each
+ * item is writable by the local processor and readable by the remote
+ * processor. By using two separate SMEM items that are single-reader and
+ * single-writer, SMP2P does not require any remote locking mechanisms.
+ *
+ * The driver uses the Linux GPIO and interrupt framework to expose a virtual
+ * GPIO for each outbound entry and a virtual interrupt controller for each
+ * inbound entry.
+ */
+
+#define SMP2P_MAX_ENTRY 16
+#define SMP2P_MAX_ENTRY_NAME 16
+
+#define SMP2P_FEATURE_SSR_ACK 0x1
+
+#define SMP2P_MAGIC 0x504d5324
+
+/**
+ * struct smp2p_smem_item - in memory communication structure
+ * @magic: magic number
+ * @version: version - must be 1
+ * @features: features flag - currently unused
+ * @local_pid: processor id of sending end
+ * @remote_pid:processor id of receiving end
+ * @total_entries: number of entries - always SMP2P_MAX_ENTRY
+ * @valid_entries: number of allocated entries
+ * @flags:
+ * @entries: individual communication entries
+ * @name: name of the entry
+ * @value: content of the entry
+ */
+struct smp2p_smem_item {
+ u32 magic;
+ u8 version;
+ unsigned features:24;
+ u16 local_pid;
+ u16 remote_pid;
+ u16 total_entries;
+ u16 valid_entries;
+ u32 flags;
+
+ struct {
+ u8 name[SMP2P_MAX_ENTRY_NAME];
+ u32 value;
+ } entries[SMP2P_MAX_ENTRY];
+} __packed;
+
+/**
+ * struct smp2p_entry - driver context matching one entry
+ * @node: list entry to keep track of allocated entries
+ * @smp2p: reference to the device driver context
+ * @name: name of the entry, to match against smp2p_smem_item
+ * @value: pointer to smp2p_smem_item entry value
+ * @last_value:last handled value
+ * @domain:irq_domain for inbound entries
+ * @irq_enabled:bitmap to track enabled irq bits
+ * @irq_rising:bitmap to mark irq bits for rising detection
+ * @irq_falling:bitmap to mark irq bits for falling detection
+ * @state: smem state handle
+ * @lock: spinlock to protect read-modify-write of
Re: [PATCH] HID: multitouch: Do not fetch initial feature reports for Win8 devices
Hi Mika,
On Sep 24 2015 or thereabouts, Mika Westerberg wrote:
> Some newer Intel Skylake based Dell laptops with Win8 precision touchpad
> fail when initial feature reports are fetched from it. Below is an
That is unfortunate.
> example output with some additional debug included:
>
> i2c_hid i2c-DLL0704:01: Fetching the HID descriptor
> i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00
> i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ...
> ...
> i2c_hid i2c-DLL0704:01: i2c_hid_get_report
> i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00
> i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05
> i2c_hid i2c-DLL0704:01: report id 13
> i2c_hid i2c-DLL0704:01: i2c_hid_get_report
> i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00
> i2c_hid i2c-DLL0704:01: failed to retrieve report from device.
> i2c_hid i2c-DLL0704:01: report id 7
> i2c_hid i2c-DLL0704:01: i2c_hid_get_report
> i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00
> i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ...
> i2c_hid i2c-DLL0704:01: report id 4
> i2c_hid i2c-DLL0704:01: i2c_hid_get_report
> i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00
>
> We manage to fetch few reports but then the touchpad dies:
>
> i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration
> i2c_hid i2c-DLL0704:01: failed to retrieve report from device.
>
> it eventually pulls the whole I2C bus low:
>
> i2c_designware i2c_designware.1: controller timed out
> i2c_hid i2c-DLL0704:01: failed to set a report to device.
>
> Fix this by preventing initial feature report fetch for Win8 devices. It
> should not be needed anyway according to [1] because the two "GET"
> feature reports for these devices are about device capabilities and Win8
> certification status which are not related to input events.
>
> [1]
> https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspx
>
> Signed-off-by: Mika Westerberg
> ---
> drivers/hid/hid-multitouch.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 426b2f1a3450..1911f7698511 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -1020,14 +1020,16 @@ static int mt_probe(struct hid_device *hdev, const
> struct hid_device_id *id)
> /*
>* Handle special quirks for Windows 8 certified devices.
>*/
> - if (id->group == HID_GROUP_MULTITOUCH_WIN_8)
> + if (id->group == HID_GROUP_MULTITOUCH_WIN_8) {
> /*
>* Some multitouch screens do not like to be polled for input
> - * reports. Fortunately, the Win8 spec says that all touches
> - * should be sent during each report, making the initialization
> - * of input reports unnecessary.
> + * and feature reports. Fortunately, the Win8 spec says that all
> + * touches should be sent during each report, making the
> + * initialization of input reports unnecessary.
>*/
> hdev->quirks |= HID_QUIRK_NO_INIT_INPUT_REPORTS;
> + hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
Problem is that with this quirk, event the features we are interested in
(and that the device should support or Microsoft would complain) are not
pre-read. I think we should set HID_QUIRK_NO_INIT_REPORTS (and remove
HID_QUIRK_NO_INIT_INPUT_REPORTS BTW), and set up a quirk to actually
retrieve the value of the feature in mt_feature_mapping. This way, we
would be sure to only probe for features that are supported (contact
count is the most important one).
Cheers,
Benjamin
> + }
>
> td = devm_kzalloc(>dev, sizeof(struct mt_device), GFP_KERNEL);
> if (!td) {
> --
> 2.5.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: dts: >: fix address translation for pbias
* Kishon Vijay Abraham I [150904 05:12]:
> "ARM: dts: : add minimal l4 bus
> layout with control module support" moved pbias_regulator dt node
> from being a child node of ocp to be the child node of
> 'syscon'. Since 'syscon' doesn't have the 'ranges' property,
> address translation fails while trying to convert the address
> to resource. Fix it here by populating 'ranges' property in
> syscon dt node.
I'm applying the following version of this with omap3 device
tree booting fixed for MMC.
Regards,
Tony
8<---From 9a5e3f27d1b8ca349b79e8b5fe1874db6f45 Mon Sep
17 00:00:00 2001
From: Kishon Vijay Abraham I
Date: Fri, 4 Sep 2015 17:38:24 +0530
Subject: [PATCH] ARM: dts: fix omap2+ address translation for pbias
"ARM: dts: : add minimal l4 bus
layout with control module support" moved pbias_regulator dt node
from being a child node of ocp to be the child node of
'syscon'. Since 'syscon' doesn't have the 'ranges' property,
address translation fails while trying to convert the address
to resource. Fix it here by populating 'ranges' property in
syscon dt node.
Fixes: 72b10ac00eb1 ("ARM: dts: omap24xx: add minimal l4 bus
layout with control module support")
Fixes: 7415b0b4c645 ("ARM: dts: omap4: add minimal l4 bus layout
with control module support")
Fixes: ed8509edddeb ("ARM: dts: omap5: add minimal l4 bus
layout with control module support")
Fixes: d919501feffa ("ARM: dts: dra7: add minimal l4 bus
layout with control module support")
Signed-off-by: Kishon Vijay Abraham I
[t...@atomide.com: fixed omap3 pbias to work]
Signed-off-by: Tony Lindgren
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -120,6 +120,7 @@
reg = <0x0 0x1400>;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0x0 0x1400>;
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-dra7",
"ti,pbias-omap";
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -56,6 +56,7 @@
reg = <0x270 0x240>;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0x270 0x240>;
scm_clocks: clocks {
#address-cells = <1>;
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,10 +113,22 @@
};
scm_conf: scm_conf@270 {
- compatible = "syscon";
+ compatible = "syscon", "simple-bus";
reg = <0x270 0x330>;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0x270 0x330>;
+
+ pbias_regulator: pbias_regulator {
+ compatible = "ti,pbias-omap3",
"ti,pbias-omap";
+ reg = <0x2b0 0x4>;
+ syscon = <_conf>;
+ pbias_mmc_reg:
pbias_mmc_omap2430 {
+ regulator-name =
"pbias_mmc_omap2430";
+ regulator-min-microvolt
= <180>;
+ regulator-max-microvolt
= <300>;
+ };
+ };
scm_clocks: clocks {
#address-cells = <1>;
@@ -202,17 +214,6 @@
dma-requests = <96>;
};
- pbias_regulator: pbias_regulator {
- compatible = "ti,pbias-omap3", "ti,pbias-omap";
- reg = <0x2b0 0x4>;
- syscon = <_conf>;
- pbias_mmc_reg: pbias_mmc_omap2430 {
- regulator-name = "pbias_mmc_omap2430";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <300>;
- };
- };
-
gpio1: gpio@4831 {
compatible = "ti,omap3-gpio";
reg = <0x4831 0x200>;
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,7 @@
reg = <0x5a0 0x170>;
Re: [PATCH v3 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver
Alexander Popov wrote:
+struct mpc512x_lpbfifo_request {
+ phys_addr_t bus_phys; /* physical address of some device on LPB */
Is this a phys_addr_t or a dma_addr_t? It can't be both a physical
address and a bus address.
+ void *ram_virt; /* virtual address of some region in RAM */
+ u32 size;
+ enum lpb_dev_portsize portsize;
+ enum mpc512x_lpbfifo_req_dir dir;
+ void (*callback)(struct mpc512x_lpbfifo_request *);
+};
+
+int mpc512x_lpbfifo_submit(struct mpc512x_lpbfifo_request *req);
+
#endif /* __ASM_POWERPC_MPC5121_H__ */
diff --git a/arch/powerpc/platforms/512x/Kconfig
b/arch/powerpc/platforms/512x/Kconfig
index 48bf38d..f09016f 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -10,6 +10,12 @@ config PPC_MPC512x
select USB_EHCI_BIG_ENDIAN_MMIO if USB_EHCI_HCD
select USB_EHCI_BIG_ENDIAN_DESC if USB_EHCI_HCD
+config MPC512x_LPBFIFO
+ tristate "MPC512x LocalPlus Bus FIFO driver"
+ depends on PPC_MPC512x && MPC512X_DMA
+ help
+ Enable support for Freescale MPC512x LocalPlus Bus FIFO (SCLPC).
+
config MPC5121_ADS
bool "Freescale MPC5121E ADS"
depends on PPC_MPC512x
diff --git a/arch/powerpc/platforms/512x/Makefile
b/arch/powerpc/platforms/512x/Makefile
index 0169312..f47d422 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_COMMON_CLK)+= clock-commonclk.o
obj-y += mpc512x_shared.o
obj-$(CONFIG_MPC5121_ADS) += mpc5121_ads.o mpc5121_ads_cpld.o
obj-$(CONFIG_MPC512x_GENERIC) += mpc512x_generic.o
+obj-$(CONFIG_MPC512x_LPBFIFO) += mpc512x_lpbfifo.o
obj-$(CONFIG_PDM360NG)+= pdm360ng.o
diff --git a/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
b/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
new file mode 100644
index 000..e6f2c6b
--- /dev/null
+++ b/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
@@ -0,0 +1,560 @@
+/*
+ * The driver for Freescale MPC512x LocalPlus Bus FIFO
+ * (called SCLPC in the Reference Manual).
+ *
+ * Copyright (C) 2013-2015 Alexander Popov.
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "mpc512x_lpbfifo"
+
+struct cs_range {
+ u32 csnum;
+ u32 base; /* must be zero */
+ u32 addr;
+ u32 size;
+};
+
+static struct lpbfifo_data {
+ spinlock_t lock; /* for protecting lpbfifo_data */
+ phys_addr_t regs_phys;
+ resource_size_t regs_size;
+ struct mpc512x_lpbfifo __iomem *regs;
+ int irq;
+ struct cs_range *cs_ranges;
+ size_t cs_n;
+ struct dma_chan *chan;
+ struct mpc512x_lpbfifo_request *req;
+ dma_addr_t ram_bus_addr;
+ bool wait_lpbfifo_irq;
+ bool wait_lpbfifo_callback;
+} lpbfifo;
+
+/*
+ * A data transfer from RAM to some device on LPB is finished
+ * when both mpc512x_lpbfifo_irq() and mpc512x_lpbfifo_callback()
+ * have been called. We execute the callback registered in
+ * mpc512x_lpbfifo_request just after that.
+ * But for a data transfer from some device on LPB to RAM we don't enable
+ * LPBFIFO interrupt because clearing MPC512X_SCLPC_SUCCESS interrupt flag
+ * automatically disables LPBFIFO reading request to the DMA controller
+ * and the data transfer hangs. So the callback registered in
+ * mpc512x_lpbfifo_request is executed at the end of
mpc512x_lpbfifo_callback().
+ */
+
+/*
+ * mpc512x_lpbfifo_irq - IRQ handler for LPB FIFO
+ */
+static irqreturn_t mpc512x_lpbfifo_irq(int irq, void *param)
+{
+ struct device *d = (struct device *)param;
Please use the variable name 'dev' instead of 'd', for consistency.
+ struct mpc512x_lpbfifo_request *req = lpbfifo.req;
+ unsigned long flags;
+ u32 status;
+
+ spin_lock_irqsave(, flags);
+
+ if (!lpbfifo.regs)
+ goto end0;
+
+ if (!req || req->dir == MPC512X_LPBFIFO_REQ_DIR_READ) {
+ dev_err(d, "bogus LPBFIFO IRQ\n");
+ goto end0;
+ }
So this might be an obscure bug. The code says that "req = lpbfifo.req"
above. However, it doesn't know that this block is in a critical
section, so it will initialize 'req' not on the top line of the
function, but rather right here. That means that although you think
that you're initializing 'req' before the spin_lock_irqsave(), the code
might actually initialize it after the spin_lock_irqsave().
My suggestion is that you explicitly initialize 'req' after
spin_lock_irqsave(). Or better yet, don't use 'req' and explicitly
reference lpbfifo.req every time.
+
+ status = in_be32(>status);
+ if (status != MPC512X_SCLPC_SUCCESS) {
+ dev_err(d, "DMA transfer between RAM and peripheral failed\n");
+
Re: [PATCH][RFC] ACPI / PM: Fix incorrect wakeup irq setting before suspend-to-idle
On Monday, August 10, 2015 10:11:26 AM Chen Yu wrote:
> For ACPI compatible system, SCI(ACPI System Control
> Interrupt) is used to wake system up from suspend-to-idle.
> Once CPU is woken up by SCI, interrupt handler will
> firstly checks if current interrupt is legal to wake up
> the whole system, thus irq_pm_check_wakeup is invoked
> to validate the irq number. However, before suspend-to-idle,
> acpi_gbl_FADT.sci_interrupt is marked rather than actual
> irq number in acpi_freeze_prepare, this might lead to unable
> to wake up the system.
>
> This patch fixes this problem by marking the irq number
> return by acpi_gsi_to_irq as IRQD_WAKEUP_STATE, rather than
> marking the acpi_gbl_FADT.sci_interrupt.
>
> Signed-off-by: Chen Yu
That would only really matter if GPE devices were used, but I've never seen
a system using them in practice, so this is more of a theoretical issue.
> ---
> drivers/acpi/osl.c | 5 -
> drivers/acpi/sleep.c | 20 ++--
> drivers/acpi/sleep.h | 5 +
> 3 files changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 3b8963f..8e1420a 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -49,6 +49,7 @@
> #include
>
> #include "internal.h"
> +#include "sleep.h"
>
> #define _COMPONENT ACPI_OS_SERVICES
> ACPI_MODULE_NAME("osl");
> @@ -850,7 +851,9 @@ acpi_os_install_interrupt_handler(u32 gsi,
> acpi_osd_handler handler,
> gsi);
> return AE_OK;
> }
> -
> +#ifdef CONFIG_SUSPEND
> + set_wake_irq_freeze(irq);
> +#endif
Please don't use #ifdefs in function bodies. You can use IS_ENABLED() for that.
> acpi_irq_handler = handler;
> acpi_irq_context = context;
> if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) {
> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
> index 2f0d4db..9e7b54e 100644
> --- a/drivers/acpi/sleep.c
> +++ b/drivers/acpi/sleep.c
> @@ -620,6 +620,22 @@ static const struct platform_suspend_ops
> acpi_suspend_ops_old = {
> .end = acpi_pm_end,
> .recover = acpi_pm_finish,
> };
> +static int wake_irq_freeze = -EINVAL;
There may be more than one of these in theory.
> +
> +int get_wake_irq_freeze(void)
> +{
> + if (IS_ERR_VALUE(wake_irq_freeze))
> + return acpi_gbl_FADT.sci_interrupt;
> + else
> + return wake_irq_freeze;
That would look better this way IMO:
return IS_ERR_VALUE(wake_irq_freeze) ?
acpi_gbl_FADT.sci_interrupt : wake_irq_freeze;
> +}
> +EXPORT_SYMBOL_GPL(get_wake_irq_freeze);
> +
> +void set_wake_irq_freeze(unsigned int irq)
> +{
> + wake_irq_freeze = (int)irq;
> +}
> +EXPORT_SYMBOL_GPL(set_wake_irq_freeze);
>
> static int acpi_freeze_begin(void)
> {
> @@ -632,14 +648,14 @@ static int acpi_freeze_prepare(void)
> acpi_enable_wakeup_devices(ACPI_STATE_S0);
> acpi_enable_all_wakeup_gpes();
> acpi_os_wait_events_complete();
> - enable_irq_wake(acpi_gbl_FADT.sci_interrupt);
> + enable_irq_wake(get_wake_irq_freeze());
> return 0;
> }
>
> static void acpi_freeze_restore(void)
> {
> acpi_disable_wakeup_devices(ACPI_STATE_S0);
> - disable_irq_wake(acpi_gbl_FADT.sci_interrupt);
> + disable_irq_wake(get_wake_irq_freeze());
> acpi_enable_all_runtime_gpes();
> }
>
> diff --git a/drivers/acpi/sleep.h b/drivers/acpi/sleep.h
> index c797ffa..eca4fda 100644
> --- a/drivers/acpi/sleep.h
> +++ b/drivers/acpi/sleep.h
> @@ -6,3 +6,8 @@ extern struct list_head acpi_wakeup_device_list;
> extern struct mutex acpi_device_lock;
>
> extern void acpi_resume_power_resources(void);
> +
> +#ifdef CONFIG_SUSPEND
> +extern int get_wake_irq_freeze(void);
> +extern void set_wake_irq_freeze(unsigned int irq);
> +#endif
Is the #ifdef needed here at all?
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] extcon: arizona: Add device binding for second jack detect pin on GPIO5
Hi Charles,
I have one comment.
I think current extcon-arizona.c has the many platform data
so, extcon-arizona.c use the too much if statement to support each feature
for different wolfsonmicro codec. I think it cause the complicated code.
For example,
You may use 'struct of_device_id' as following. You used already this method
on drivers/mfd/arizona-core.c. If you separate the function of each wm
arizona,
it makes improved readability for extcon-arizona.c and some user will use
extcon-arizora
more easily.
struct arizona_extcon_data {
void (*init)(...);
void (*irq_handler)(...);
...
};
struct arizona_extcon_data wm8994_data {
.init = wm8994_extcon_init,
.irq_handler = wm8994_extcon_irq_handler;
...
};
static const struct of_device_id arizona_extcon_dt_match[] = {
{
.compatible = "wm8994-arizona-extcon",
.data = (void *)wm8994_data;
}, {
.compatible = "wm-arizona-extcon",
.data = (void *)wm_data;
},
};
I expect that you will revise the arizona-extcon.c driver on next time.
Thanks,
Chanwoo Choi
On 2015년 09월 16일 18:56, Charles Keepax wrote:
> Some Arizona devices have the option to use the GPIO5 pin as a second
> jack detection pin. This patch adds device bindings to specify to the
> driver that it should use this pin. Note that the second jack detection
> pin is hard wired in the chip so can only be enabled through the
> binding, rather than a pin being specified.
>
> Signed-off-by: Charles Keepax
> Acked-by: Chanwoo Choi
> ---
> drivers/extcon/extcon-arizona.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index dc1910d..992f80e 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1235,6 +1235,11 @@ static int arizona_extcon_device_get_pdata(struct
> arizona *arizona)
>
> device_property_read_u32(arizona->dev, "wlf,gpsw", >gpsw);
>
> + pdata->jd_gpio5 = device_property_read_bool(arizona->dev,
> + "wlf,use-jd-gpio");
> + pdata->jd_gpio5_nopull = device_property_read_bool(arizona->dev,
> + "wlf,use-jd-gpio-nopull");
> +
> return 0;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] extcon: arizona: Add device binding to enable ADC mode micdet
Hi Charles, On 2015년 09월 16일 18:56, Charles Keepax wrote: > Add a simple boolean binding to turn on and off the use of ADC > microphone detection mode to determine 3/4 pole jack. > > Signed-off-by: Charles Keepax > --- > drivers/extcon/extcon-arizona.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c > index 4479781..869a920 100644 > --- a/drivers/extcon/extcon-arizona.c > +++ b/drivers/extcon/extcon-arizona.c > @@ -1227,6 +1227,9 @@ static int arizona_extcon_device_get_pdata(struct > arizona *arizona) > pdata->micd_force_micbias = device_property_read_bool(arizona->dev, > "wlf,micd-force-micbias"); > > + pdata->micd_software_compare = device_property_read_bool(arizona->dev, > + "wlf,micd-software-compare"); > + > return 0; > } > > Acked-by: Chanwoo Choi Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] extcon: arizona: Add device binding for the general purpose switch
Hi Charles, On 2015년 09월 16일 18:56, Charles Keepax wrote: > The switch is generally used in conjunction with the MICDET clamp to > suppress pops and clicks associated with jack insertion. This patch adds > a binding that allows the user to select the mode of operation for this > switch. > > Signed-off-by: Charles Keepax > --- > drivers/extcon/extcon-arizona.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c > index 869a920..5b4bc2f 100644 > --- a/drivers/extcon/extcon-arizona.c > +++ b/drivers/extcon/extcon-arizona.c > @@ -1230,6 +1230,8 @@ static int arizona_extcon_device_get_pdata(struct > arizona *arizona) > pdata->micd_software_compare = device_property_read_bool(arizona->dev, > "wlf,micd-software-compare"); > > + device_property_read_u32(arizona->dev, "wlf,gpsw", >gpsw); > + > return 0; > } > > Acked-by: Chanwoo Choi Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] bus: omap-ocp2scp: Fix module alias
Remove extra space between platform prefix and driver name in MODULE_ALIAS.
Signed-off-by: Axel Lin
---
This patch was sent on https://lkml.org/lkml/2015/5/19/1150
Re-sent on https://lkml.org/lkml/2015/8/14/141
No response so far, so CC Andrew.
drivers/bus/omap-ocp2scp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
index 9f18569..bf500e0 100644
--- a/drivers/bus/omap-ocp2scp.c
+++ b/drivers/bus/omap-ocp2scp.c
@@ -117,7 +117,7 @@ static struct platform_driver omap_ocp2scp_driver = {
module_platform_driver(omap_ocp2scp_driver);
-MODULE_ALIAS("platform: omap-ocp2scp");
+MODULE_ALIAS("platform:omap-ocp2scp");
MODULE_AUTHOR("Texas Instruments Inc.");
MODULE_DESCRIPTION("OMAP OCP2SCP driver");
MODULE_LICENSE("GPL v2");
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/arp.c
between commit:
63d008a4e9ee ("ipv4: send arp replies to the correct tunnel")
from the net tree and commit:
0c4b51f0054c ("netfilter: Pass net into okfn")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/ipv4/arp.c
index f03db8b7abee,61ff5ea31283..
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@@ -651,8 -654,6 +657,7 @@@ static int arp_process(struct net *net
u16 dev_type = dev->type;
int addr_type;
struct neighbour *n;
- struct net *net = dev_net(dev);
+ struct dst_entry *reply_dst = NULL;
bool is_garp = false;
/* arp_rcv below verifies the ARP header and verifies the device
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] phy: sun4i-usb: Use devm_gpiod_get_optional for optional GPIOs
Both data->id_det_gpio and data->vbus_det_gpio are optional, so use
devm_gpiod_get_optional for them.
Signed-off-by: Axel Lin
Reviewed-by: Hans de Goede
---
This patch was sent on https://lkml.org/lkml/2015/8/21/177
drivers/phy/phy-sun4i-usb.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 731b395..b12964b 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -551,19 +551,15 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
if (IS_ERR(data->base))
return PTR_ERR(data->base);
- data->id_det_gpio = devm_gpiod_get(dev, "usb0_id_det", GPIOD_IN);
- if (IS_ERR(data->id_det_gpio)) {
- if (PTR_ERR(data->id_det_gpio) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
- data->id_det_gpio = NULL;
- }
-
- data->vbus_det_gpio = devm_gpiod_get(dev, "usb0_vbus_det", GPIOD_IN);
- if (IS_ERR(data->vbus_det_gpio)) {
- if (PTR_ERR(data->vbus_det_gpio) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
- data->vbus_det_gpio = NULL;
- }
+ data->id_det_gpio = devm_gpiod_get_optional(dev, "usb0_id_det",
+ GPIOD_IN);
+ if (IS_ERR(data->id_det_gpio))
+ return PTR_ERR(data->id_det_gpio);
+
+ data->vbus_det_gpio = devm_gpiod_get_optional(dev, "usb0_vbus_det",
+ GPIOD_IN);
+ if (IS_ERR(data->vbus_det_gpio))
+ return PTR_ERR(data->vbus_det_gpio);
if (of_find_property(np, "usb0_vbus_power-supply", NULL)) {
data->vbus_power_supply = devm_power_supply_get_by_phandle(dev,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Glibc recvmsg from kernel netlink socket hangs forever
Hello linux-kernel,
I write to you on behalf of many developers at my company, who
are having trouble with their applications endlessly locking up
inside of libc code, with no hope of recovery.
Currently it affects our Mono and Node processes mostly, and the
symptoms are the same: user code invokes getaddrinfo, and libc
attempts to determine whether ipv4 or ipv6 is appropriate, by using
the RTM_GETADDR netlink message. The write into the netlink socket
succeeds, and it immediately reads back the results ... and waits
forever. The read never returns. The stack looks like this:
#0 0x7fd7d8d214ad in recvmsg () at ../sysdeps/unix/syscall-template.S:81
#1 0x7fd7d8d3e44d in make_request (fd=fd@entry=13, pid=1) at
../sysdeps/unix/sysv/linux/check_pf.c:177
#2 0x7fd7d8d3e9a4 in __check_pf (seen_ipv4=seen_ipv4@entry=0x7fd7d37fdd00,
seen_ipv6=seen_ipv6@entry=0x7fd7d37fdd10,
in6ai=in6ai@entry=0x7fd7d37fdd40, in6ailen=in6ailen@entry=0x7fd7d37fdd50)
at ../sysdeps/unix/sysv/linux/check_pf.c:341
#3 0x7fd7d8cf64e1 in __GI_getaddrinfo (name=0x31216e0
"mesos-slave4-prod-uswest2.otsql.opentable.com", service=0x0,
hints=0x31216b0, pai=0x31f09e8) at ../sysdeps/posix/getaddrinfo.c:2355
#4 0x00e101c8 in uv__getaddrinfo_work (w=0x31f09a0) at
../deps/uv/src/unix/getaddrinfo.c:102
#5 0x00e09179 in worker (arg=) at
../deps/uv/src/threadpool.c:91
#6 0x00e16eb1 in uv__thread_start (arg=) at
../deps/uv/src/unix/thread.c:49
#7 0x7fd7d8ff3182 in start_thread (arg=0x7fd7d37fe700) at
pthread_create.c:312
#8 0x7fd7d8d2047d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(libuv is part of Node and makes DNS lookups "asynchronous" by having
a thread pool in the background working)
The applications will run for hours or days successfully, until eventually
hanging with
no apparent pattern or cause. And once this hang happens it hangs badly,
because
check_pf is holding a lock during the problematic recvmsg call.
I raised this issue on the libc-help mailing list, but I'm hoping that lkml will
have a higher number of people familiar with netlink that may better offer
advice.
The original thread is here:
https://sourceware.org/ml/libc-help/2015-09/msg00014.html
Looking at the getaddrinfo / check_pf source code:
https://fossies.org/dox/glibc-2.22/sysdeps_2unix_2sysv_2linux_2check__pf_8c_source.html
146 if (TEMP_FAILURE_RETRY (__sendto (fd, (void *) , sizeof (req), 0,
147 (struct sockaddr *) ,
148 sizeof (nladdr))) < 0)
149goto out_fail;
150
151 bool done = false;
152
153 bool seen_ipv4 = false;
154 bool seen_ipv6 = false;
155
156 do
157 {
158struct msghdr msg =
159{
160 (void *) , sizeof (nladdr),
161 , 1,
162 NULL, 0,
163 0
164};
165
166 ssize_t read_len = TEMP_FAILURE_RETRY (__recvmsg (fd, , 0));
167 if (read_len <= 0)
168goto out_fail;
169
170 if (msg.msg_flags & MSG_TRUNC)
171goto out_fail;
172
I notice that there is possibility that if messages are dropped either on send
or receive side, maybe this code will hang forever? The netlink(7) man page
makes
me slightly worried:
> Netlink is not a reliable protocol. It tries its best to deliver a message
> to its destination(s), but may drop messages when an out-of-memory condition
> or other error occurs.
> However, reliable transmissions from kernel to user are impossible in any
> case. The kernel can't send a netlink message if the socket buffer is full:
> the message will be dropped and the kernel and the user-space process will no
> longer have the same view of kernel state. It is up to the application to
> detect when this happens (via the ENOBUFS error returned by recvmsg(2)) and
> resynchronize.
I have taken the glibc code and created a simple(r) program to attempt to
reproduce this issue.
I inserted some simple polling between the sendto and recvmsg calls to make the
failure case more evident:
struct pollfd pfd;
pfd.fd = fd;
pfd.events = POLLIN;
pfd.revents = 0;
int pollresult = poll(, 1, 1000);
if (pollresult < 0) {
perror("glibc: check_pf: poll");
abort();
} else if (pollresult == 0 || pfd.revents & POLLIN == 0) {
fprintf(stderr, "[%ld] glibc: check_pf: netlink socket read timeout\n",
gettid());
abort();
}
I have placed the full source code and strace output here:
https://gist.github.com/stevenschlansker/6ad46c5ccb22bc4f3473
The process quickly sends off hundreds of threads which sit in a
loop attempting this RTM_GETADDR message exchange.
The code may be compiled as "gcc -o pf_dump -pthread pf_dump.c"
An example invocation that quickly fails:
root@24bf2e440b5e:/# strace -ff -o pfd ./pf_dump
[3700] exit success
glibc: check_pf: netlink socket read timeout
Aborted (core dumped)
Interestingly, this seems to be very easy to reproduce using pthreads, but much
less
common with fork() or clone()d threads. I'm
Re: [PATCH v1 1/3] clocksource: rockchip: Make the driver more readability and compatible
Hi Caesar,
so thinking a bit more about this patch. I would like to split it into
two. One fixing the NO_IRQ and another fixing the dsb().
IIUC, the ARMv8 support is not yet ready and dsb() is not necessary as a
fix for the previous kernel version. However, the timer is used with the
ARMv7 boards and the NO_IRQ should be merged into tip-urgent.
I already done the fix and I am ready to submit it (for the timer
keystone also). So I suggest your resend the dsb() fix only.
Regarding the indentation, I prefer you do that in a separate patch by
cleaning up the macros (if relevant) or send the patch to trivial@
-- Daniel
On 09/22/2015 07:15 AM, Caesar Wang wrote:
Hi Heiko,
在 2015年09月22日 22:00, Heiko Stübner 写道:
Hi Caesar,
Am Freitag, 18. September 2015, 16:51:09 schrieb Caesar Wang:
Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for rockchip.
logs:
...
drivers/clocksource/rockchip_timer.c:156:13: error: 'NO_IRQ' undeclared
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at operand 1 --
`dsb`
...
The problem was different semantics of dsb on btw arm32 and arm64,
Here we can convert the dsb with insteading of dsb(sy).
NO_IRQ definition is missing for ARM64, since NO_IRQ being -1 is a
legacy thing for ARM - all ARM drivers are supposed to be converted to
use <= 0 or == 0 to detect invalid IRQs, and _eventually_ once all users
are gone, NO_IRQ deleted. Modern drivers should _all_ be using !irq to
detect invalid IRQs, and not using NO_IRQ.
Meanwhile, I change a bit to make the code more readability for driver
when I check the code style.
Signed-off-by: Caesar Wang
---
Changes in v1:
- As Russell, Thomas, Daniel comments, let's replace NO_IRQ by '!irq'.
drivers/clocksource/rockchip_timer.c | 29
+++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/clocksource/rockchip_timer.c
b/drivers/clocksource/rockchip_timer.c index bb2c2b0..e1af449 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -17,16 +17,16 @@
#define TIMER_NAME "rk_timer"
-#define TIMER_LOAD_COUNT0 0x00
-#define TIMER_LOAD_COUNT1 0x04
-#define TIMER_CONTROL_REG 0x10
-#define TIMER_INT_STATUS 0x18
+#define TIMER_LOAD_COUNT00x00
+#define TIMER_LOAD_COUNT10x04
+#define TIMER_CONTROL_REG0x10
+#define TIMER_INT_STATUS0x18
-#define TIMER_DISABLE 0x0
-#define TIMER_ENABLE 0x1
-#define TIMER_MODE_FREE_RUNNING (0 << 1)
-#define TIMER_MODE_USER_DEFINED_COUNT (1 << 1)
-#define TIMER_INT_UNMASK (1 << 2)
+#define TIMER_DISABLE(0 << 0)
+#define TIMER_ENABLE(1 << 0)
+#define TIMER_MODE_FREE_RUNNING(0 << 1)
+#define TIMER_MODE_USER_DEFINED_COUNT(1 << 1)
+#define TIMER_INT_UNMASK(1 << 2)
not sure how Daniel sees this, but those could count as "unrelated
change", as
they have nothing to do with the arm64 build-fixes.
Yep, it's no related to the arm64 uild fixes.
I only make the code more readability for driver.
struct bc_timer {
struct clock_event_device ce;
@@ -49,14 +49,14 @@ static inline void __iomem *rk_base(struct
clock_event_device *ce) static inline void rk_timer_disable(struct
clock_event_device *ce) {
writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
-dsb();
+dsb(sy);
}
static inline void rk_timer_enable(struct clock_event_device *ce, u32
flags) {
writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
rk_base(ce) + TIMER_CONTROL_REG);
-dsb();
+dsb(sy);
}
static void rk_timer_update_counter(unsigned long cycles,
@@ -64,13 +64,13 @@ static void rk_timer_update_counter(unsigned long
cycles, {
writel_relaxed(cycles, rk_base(ce) + TIMER_LOAD_COUNT0);
writel_relaxed(0, rk_base(ce) + TIMER_LOAD_COUNT1);
-dsb();
+dsb(sy);
}
static void rk_timer_interrupt_clear(struct clock_event_device *ce)
{
writel_relaxed(1, rk_base(ce) + TIMER_INT_STATUS);
-dsb();
+dsb(sy);
}
static inline int rk_timer_set_next_event(unsigned long cycles,
@@ -148,7 +148,7 @@ static void __init rk_timer_init(struct
device_node *np)
bc_timer.freq = clk_get_rate(timer_clk);
irq = irq_of_parse_and_map(np, 0);
-if (irq == NO_IRQ) {
+if (!irq) {
pr_err("Failed to map interrupts for '%s'\n", TIMER_NAME);
return;
}
@@ -173,4 +173,5 @@ static void __init rk_timer_init(struct
device_node *np)
clockevents_config_and_register(ce, bc_timer.freq, 1, UINT_MAX);
}
+
unnecessary addition of a blank line (same reasons as above)
It's the same reason with the above.
CHECK: Please use a blank line after function/struct/union/enum
declarations
#176: FILE: rockchip_timer.c:176:
+}
+CLOCKSOURCE_OF_DECLARE(rk_timer, "rockchip,rk3288-timer", rk_timer_init);
I know, we can ignore the above warning.
That's a bit better, I thnik.
CLOCKSOURCE_OF_DECLARE(rk_timer,
Re: [PATCH v3 2/3] powerpc/512x: add a device tree binding for LocalPlus Bus FIFO
Alexander Popov wrote: +- dma-names: should be "rx-tx"; Why bother, if it can only be one value? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] DeviceTree fixes for 4.3
Hi Linus, Please pull DT fixes for 4.3. Details below. Rob The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-fixes-for-4.3 for you to fetch changes up to a13f18f59d2646754cda3662a9e215ff43e7a7d5: Documentation: arm: Fix typo in the idle-states bindings examples (2015-09-24 17:55:32 -0500) DeviceTree fixes for 4.3: - Silence bogus warning for of_irq_parse_pci - Fix typo in ARM idle-states binding doc and dts files - Various minor binding documentation updates David Daney (1): of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages. Hans de Goede (1): devicetree: bindings: Extend the bma180 bindings with bma250 info Javier Martinez Canillas (1): gpio: mention in DT binding doc that -gpio is deprecated Lorenzo Pieralisi (1): Documentation: arm: Fix typo in the idle-states bindings examples Mark Rutland (1): Docs: dt: add #msi-cells to GICv3 ITS binding Masahiro Yamada (1): of: add vendor prefix for Socionext Inc. Punit Agrawal (2): of: thermal: Fix inconsitency between cooling-*-state and cooling-*-level of: thermal: Mark cooling-*-level properties optional Documentation/devicetree/bindings/arm/gic-v3.txt | 5 .../devicetree/bindings/arm/idle-states.txt| 2 +- Documentation/devicetree/bindings/gpio/gpio.txt| 4 +++- .../devicetree/bindings/iio/accel/bma180.txt | 8 +-- .../devicetree/bindings/thermal/thermal.txt| 27 +++--- .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +- arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +- drivers/of/of_pci_irq.c| 22 +++--- 9 files changed, 46 insertions(+), 27 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] dmaengine: mpc512x: initialize with subsys_initcall()
Alexander Popov wrote: Initialize Freescale MPC512x DMA driver with subsys_initcall() to allow the depending drivers to call dma_request_slave_channel() during their probe. Signed-off-by: Alexander Popov Is there any way we can use -EPROBEDEFER instead? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend
On Wednesday, September 23, 2015 10:55:52 AM Alan Stern wrote:
> On Wed, 23 Sep 2015, Oliver Neukum wrote:
>
> > On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote:
> > > On Tue, 22 Sep 2015, Oliver Neukum wrote:
> > >
> > > > Cancel, yes, going to low power is a consequence which needn't bother
> > > > the power subsystem.
> > >
> > > Going to low power needn't involve the power subsystem? That sounds
> > > weird.
> >
> > Think of it like rfkill. It makes sense to suspend an rfkilled device.
> > It still is the job of the driver to report that its device is idle.
>
> Reporting that the device is idle _does_ involve the power subsystem.
> But never mind...
>
> > > So my next question is: _How_ can this help PM to do a better job?
> > > That is, what are the mechanisms?
> >
> > "inhibit" -> driver stops input -> driver sets PM count to zero
> > -> PM subsystem acts
>
> Your third step here poses problems. There is no runtime-PM API a
> driver or subsystem can use to set its usage counter to 0. All it can
> do is increment or decrement the counter.
>
> > To go from the first to the second step a callback is needed
> >
> > > One you have already stated: Lack of spurious events will help prevent
> > > unwanted wakeups (or unwanted failures to go to sleep).
> >
> > That too. We also save CPU cycles.
> >
> > > But Dmitry made a stronger claim: Inhibiting an input device should
> > > allow the device to go to low power. I would like to know how we can
> > > implement this cleanly. The most straightforward approach is to use
> > > runtime PM, but it's not obvious how this can be made to work with the
> > > current API.
> >
> > Yes, we can use the current API.
> > The key is that you think of the mechanism as induced idleness,
> > not forced suspend. We already have a perfectly working mechanism
> > for suspending idle devices.
>
> After thinking some more about this, here's what I've got.
>
> Let's talk about input-only devices being in an "idle" state or a
> "running" state:
>
> When the device is in the idle state, its driver does not
> communicate with the device. In particular, the driver does
> not monitor for events or report them to the rest of the
> kernel. It is appropriate to put the device in runtime suspend
> with remote wakeup disabled.
>
> When the device is in the running state, its driver receives
> event reports from the device and propagates them forward.
> The subsystem/driver may choose to put the device in runtime
> suspend between events with remote wakeup enabled (like we do
> for USB keyboards if no LEDs are on) or it may choose to leave
> the device at full power the whole time.
>
> The idea is that a device is in the idle state whenever the open file
> count is 0 _or_ it is "inhibited"; otherwise it is in the running
> state.
>
> I tried to come up with a way to do some of this work in a central
> core. All I could think of was that the core should detect state
> changes and inform the subsystem/driver when they occur. Everything
> else (starting and stopping I/O, adjusting the runtime-PM usage
> counter) would have to be done by the subsystem/driver.
>
> The problem is that a core generally isn't aware of when a file
> reference is opened or released. Only the driver is. Which means
> there's nothing that the core can do here; the driver and subsystem
> have to manage pretty much the whole thing. A simple example:
>
> open()
> {
> mutex_lock(>open_mutex);
> if (dev->open_count++ == 0 && !dev->inhibited) {
> pm_runtime_get_sync(dev);
> start_io(dev);
> }
> mutex_unlock(>open_mutex);
> }
>
> release()
> {
> mutex_lock(>open_mutex);
> if (--dev->open_count == 0 && !dev->inhibited) {
> stop_io(dev);
> pm_runtime_put(dev);
> }
> mutex_unlock(>open_mutex);
> }
>
> inhibit()
> {
> mutex_lock(>open_mutex);
> dev->inhibited = true;
> if (dev->open_count > 0) {
> stop_io(dev);
> pm_runtime_put(dev);
> }
> mutex_unlock(>open_mutex);
> }
>
> uninhibit()
> {
> mutex_lock(>open_mutex);
> dev->inhibited = false;
> if (dev->open_count > 0) {
> pm_runtime_get_sync(dev);
> start_io(dev);
> }
> mutex_unlock(>open_mutex);
> }
>
> This doesn't leave much room for the PM core or anything else.
We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag,
but it isn't very useful, so I'd prefer to replace it with a "no remote wakeup"
bit in struct dev_pm_info or something similar).
That is actually quite important, because (a) we can save energy but not
configuring the device to do remote wakeup in the first place and (b) that
may involve more than just the driver (for example, disabling PCI or ACPI
remote wakeup involves the bus type or similar).
So it
Re: [PATCH 0/9] Arizona Extcon Bug Fixes and Improvements
Hi Charles and Lee, I create the immutable branch[1] for this patch-set. [1] https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/ (branch: ib-extcon-mfd-4.4) I'll send pull request to Lee Jones today. Best Regards, Chanwoo Choi On 2015년 09월 16일 18:42, Charles Keepax wrote: > Hi, > > Ok I have split these patches out into 2 chains; this chain > contains no device tree changes so that should let us merge > these now and at least get the benefit of the bug fixes > etc. whilst we work on getting the necessary ACKs for the > DT changes. The DT changes themselves should be simpler to > merge as there are no build dependencies there between the > extcon and MFD patches so they can just each go through > their respective trees. Whereas this chain needs to all go > through one tree. > > These patches add support for the ADC mode microphone > detection, and the general purpose switch for pop > suppression. The bug fixes include fixing the headphone > detection accuracy at the top end of the range and some > corrections around the use of the microphone clamps. > > Thanks, > Charles > > Charles Keepax (8): > mfd: arizona: Add registers for ADC microphone detection > mfd: arizona: Add register bits for general purpose switch > mfd: arizona: Add TST_CAP bits for headphone detection > extcon: arizona: Add support for new ADC value mic detect > extcon: arizona: Add support for general purpose switch > extcon: arizona: Additional settings to improve accuracy of HP detect > extcon: arizona: Use the micd_clamp for interrupts if it is available > extcon: arizona: Don't disable debounce for inverted jacks > > Nariman Poushin (1): > extcon: arizona: Ignore jd_invert for MICD_CLAMP_STS > > drivers/extcon/extcon-arizona.c | 106 > +++-- > drivers/mfd/wm5110-tables.c |6 ++ > include/dt-bindings/mfd/arizona.h |2 + > include/linux/mfd/arizona/pdata.h |6 ++ > include/linux/mfd/arizona/registers.h | 14 - > 5 files changed, 113 insertions(+), 21 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'
On 25-09-15, 02:17, Rafael J. Wysocki wrote:
> Actually, what about adding a local u32 variable, say val, here and doing
>
> > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)_ec->gpe))
> > goto error;
> > if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > -(u32 *)_ec->global_lock))
> > +_ec->global_lock))
>
> if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, ))
>
> > goto error;
>
> first_ec->global_lock = val;
>
> And then you can turn val into bool just fine without changing the structure
> definition.
sure. Looks good.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/15] block, dax, pmem: reference counting infrastructure
On Thu, Sep 24, 2015 at 8:15 AM, Christoph Hellwig wrote: > On Wed, Sep 23, 2015 at 12:41:55AM -0400, Dan Williams wrote: >> Enable DAX to use a reference count for keeping the virtual address >> returned by ->direct_access() valid for the duration of its usage in >> fs/dax.c, or otherwise hold off blk_cleanup_queue() while >> pmem_make_request is active. The blk-mq code is already in a position >> to need low overhead referece counting for races against request_queue >> destruction (blk_cleanup_queue()). Given DAX-enabled block drivers do >> not enable blk-mq, share the storage in 'struct request_queue' between >> the two implementations. > > Can we just move the refcounting to common code with the same field > name, and even initialize it for non-mq, non-dax queues but just never > tage a reference there (for now)? That makes sense to me, especially because drivers/nvdimm/blk.c is broken in the same way as drivers/nvdimm/pmem.c and it would be awkward to have it use blk_dax_get() / blk_dax_put(). The percpu_refcount should be valid for all queues and it will only ever be > 1 in the blk_mq and libnvdimm cases (for now). Will fix. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] acpi-dma: Add support for "dma-names" device property
On Thursday, September 24, 2015 09:05:28 PM Vinod Koul wrote:
> On Mon, Sep 14, 2015 at 05:37:36PM +0300, Mika Westerberg wrote:
> > The current implementation hard codes the two supported channels so that
> > "tx" is always 0 and "rx" is always 1. This is because there has been no
> > suitable way in ACPI to name resources.
> >
> > With _DSD device properties we can finally do this:
> >
> > Device (SPI1) {
> > Name (_CRS, ResourceTemplate () {
> > ...
> > FixedDMA (0x, 0x, Width32bit)
> > FixedDMA (0x0001, 0x0001, Width32bit)
> > })
> >
> > Name (_DSD, Package () {
> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > Package () {
> > Package () {"dma-names", Package () {"tx", "rx"}}
> > },
> > })
> > }
> >
> > The names "tx" and "rx" now provide index of the FixedDMA resource in
> > question.
> >
> > Modify acpi_dma_request_slave_chan_by_name() so that it looks for
> > "dma-names" property first and only then fall back using hardcoded indices.
> >
> > The DT "dma-names" binding that we reuse for ACPI is documented in
> > Documentation/devicetree/bindings/dma/dma.txt.
>
> Acked-by: Vinod Koul
>
> This is actually good and will help a lot.
Thanks!
Added [1/2] and this one to my device-properties branch.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ACPI / tables: test the correct variable
On Tuesday, September 22, 2015 03:29:25 PM Dan Carpenter wrote:
> The intent was to test "proc[i].handler" instead of "proc->handler".
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index c1ff58d..6c0f079 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -268,7 +268,8 @@ acpi_parse_entries_array(char *id, unsigned long
> table_size,
> for (i = 0; i < proc_num; i++) {
> if (entry->type != proc[i].id)
> continue;
> - if (!proc->handler || proc[i].handler(entry, table_end))
> + if (!proc[i].handler ||
> + proc[i].handler(entry, table_end))
> return -EINVAL;
>
> proc->count++;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Applied, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'
On Tuesday, September 15, 2015 02:04:58 PM Viresh Kumar wrote:
> global_lock is defined as an unsigned long and accessing only its lower
> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> for big endian 64 bit systems.
>
> Fix that by making global_lock an u32 instead.
>
> Cc: # v4.1+
> Signed-off-by: Viresh Kumar
>
> ---
> Its marked just for # v4.1+, because arm64 has the first 64 big-endian
> platform with ACPI. And ACPI support for that is mainlined recently
> only (Arnd Bergmann).
>
> Another thing worth noticing is that, global_lock is getting an unsigned
> long long value assigned to it in ec_parse_device() and this is what
> Arnd had to say about that:
>
> "I think that's fine, it does this because the _GLP variable in ACPI is
> defined as an u64. And that's what happens on 32-bit architectures
> anyway."
>
> This patch should go via GregKH, as the second patch has dependency on
> it.
>
> V2->V3:
> - Moved this out in a separate patch, so that it can be backported.
> ---
> drivers/acpi/ec_sys.c | 2 +-
> drivers/acpi/internal.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..bea8e425a8de 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -128,7 +128,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec,
> unsigned int ec_device_count)
Actually, what about adding a local u32 variable, say val, here and doing
> if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)_ec->gpe))
> goto error;
> if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> - (u32 *)_ec->global_lock))
> + _ec->global_lock))
if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, ))
> goto error;
first_ec->global_lock = val;
And then you can turn val into bool just fine without changing the structure
definition.
>
> if (write_support)
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 9e426210c2a8..9db196de003c 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -138,7 +138,7 @@ struct acpi_ec {
> unsigned long gpe;
> unsigned long command_addr;
> unsigned long data_addr;
> - unsigned long global_lock;
> + u32 global_lock;
> unsigned long flags;
> unsigned long reference_count;
> struct mutex mutex;
>
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/19] extcon: sm5502: fix handling regmap_irq_get_virq result
On 2015년 09월 24일 23:00, Andrzej Hajda wrote:
> The function can return negative value.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi,
>
> To avoid problems with too many mail recipients I have sent whole
> patchset only to LKML. Anyway patches have no dependencies.
>
> Regards
> Andrzej
> ---
> drivers/extcon/extcon-sm5502.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/extcon/extcon-sm5502.c b/drivers/extcon/extcon-sm5502.c
> index 92ae484..2945091 100644
> --- a/drivers/extcon/extcon-sm5502.c
> +++ b/drivers/extcon/extcon-sm5502.c
> @@ -586,7 +586,7 @@ static int sm5022_muic_i2c_probe(struct i2c_client *i2c,
>
> for (i = 0; i < info->num_muic_irqs; i++) {
> struct muic_irq *muic_irq = >muic_irqs[i];
> - unsigned int virq = 0;
> + int virq = 0;
>
> virq = regmap_irq_get_virq(info->irq_data, muic_irq->irq);
> if (virq <= 0)
>
Applied it.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/19] extcon: rt8973a: fix handling regmap_irq_get_virq result
On 2015년 09월 24일 23:00, Andrzej Hajda wrote:
> The function can return negative value.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi,
>
> To avoid problems with too many mail recipients I have sent whole
> patchset only to LKML. Anyway patches have no dependencies.
>
> Regards
> Andrzej
> ---
> drivers/extcon/extcon-rt8973a.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/extcon/extcon-rt8973a.c b/drivers/extcon/extcon-rt8973a.c
> index 3428b6a..1bc3737 100644
> --- a/drivers/extcon/extcon-rt8973a.c
> +++ b/drivers/extcon/extcon-rt8973a.c
> @@ -594,7 +594,7 @@ static int rt8973a_muic_i2c_probe(struct i2c_client *i2c,
>
> for (i = 0; i < info->num_muic_irqs; i++) {
> struct muic_irq *muic_irq = >muic_irqs[i];
> - unsigned int virq = 0;
> + int virq = 0;
>
> virq = regmap_irq_get_virq(info->irq_data, muic_irq->irq);
> if (virq <= 0)
>
Applied it.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/2] ACPI / EC: Fix broken big-endian 64bit platforms using 'global_lock'
On 23-09-15, 07:52, Zheng, Lv wrote: > And IMO, if we really want to change global_lock, we should make it bool here. Yeah, so the second patch in this series is doing just that. Just kept this patch separate to make more sense. Will resend both and keep you in cc. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/9] Phy, mdiobus, and netdev struct device fixes
On Fri, Sep 25, 2015 at 12:50:33AM +0200, Andrew Lunn wrote: > > Thanks for testing. Please could you confirm whether the same behaviour > > is observed without the patches, just to make absolutely sure that isn't > > a regression. > > So i tested this now. > > I have two FEC interfaces. One i my main access interface, and the > second is used by DSA to access switches. With your patches, the > module Used by count is equal to the number of interfaces which are > up. > > Without your patches, the count is always 0. That will be as a result of the MDIO bus module refcounting patch - "phy: fix mdiobus module safety". The code prior to that patch was totally useless and ineffectual - it might as well not even have been present, because it would never have any effect. bus_module would always be NULL in phy_attach_direct(). While my change makes the code start to work as originally intended, it's still unsafe: there's nothing to stop you manually unbinding the driver providing the MDIO bus from the struct device. The driver will then free the resources it claimed in its probe function, which may include the MMIO mapping for the MDIO bus accessor functions. If the accessors are then called, despite keeping the mdio bus, phy, etc data structures properly refcounted, the kernel will oops when the (many) MDIO bus drivers hit the free'd MMIO mapping. This is, unfortunately, just another pre-existing bug in this code. To stop that, we need some way to say "this MDIO bus has been removed, prevent further access" and that needs to be done in a race free way. Right now, that doesn't exist. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
