linux-next: manual merge of the akpm-current tree with the arm tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/arm/Kconfig

between commit:

  437682eeab45 ("ARM: 8456/1: code patching only works on MMU")

from the arm tree and commits:

  47fb802e4fcd ("arm: mm: support ARCH_MMAP_RND_BITS")
  8100fa068b27 ("ARM: avoid ARCH_MMAP_RND_BITS for NOMMU")

from the akpm-current 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 arch/arm/Kconfig
index 752775aab3ae,536a8e477a96..
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -33,8 -33,9 +33,9 @@@ config AR
select HARDIRQS_SW_RESEND
select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
 -  select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32
 -  select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32
 +  select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
 +  select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
+   select HAVE_ARCH_MMAP_RND_BITS if MMU
select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
select HAVE_ARCH_TRACEHOOK
select HAVE_BPF_JIT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/7] mm/compaction: update defer counter when allocation is expected to succeed

[Joonsoo Kim]

On Fri, Dec 04, 2015 at 05:52:21PM +0100, Vlastimil Babka wrote:
> On 12/03/2015 08:11 AM, Joonsoo Kim wrote:
> >It's rather strange that compact_considered and compact_defer_shift aren't
> >updated but compact_order_failed is updated when allocation is expected
> >to succeed. Regardless actual allocation success, deferring for current
> >order will be disabled so it doesn't result in much difference to
> >compaction behaviour.
> 
> The difference is that if the defer reset was wrong, the next
> compaction attempt that fails would resume the deferred counters?

Right. But, perhaps, if we wrongly reset order_failed due to difference
of check criteria, it could happen again and again on next compaction
attempt so defer would not work as intended.

> 
> >Moreover, in the past, there is a gap between expectation for allocation
> >succeess in compaction and actual success in page allocator. But, now,
> >this gap would be diminished due to providing classzone_idx and alloc_flags
> >to watermark check in compaction and changed watermark check criteria
> >for high-order allocation. Therfore, it's not a big problem to update
> >defer counter when allocation is expected to succeed. This change
> >will help to simplify defer logic.
> 
> I guess that's true. But at least some experiment would be better.

Yeah, I tested it today and found that there is a difference.
Allocation is more successful(really minor, 0.25%) than checking
in compaction. Reason is that watermark check in try_to_compact_pages()
uses low_wmark_pages but get_page_from_freelist() after direct compaction
uses min_wmark_pages. When I change low_wmark_pages to min_wmark_pages,
I can't find any difference. It seems reasonable to change
low_wmark_pages to min_wmark_pages in some places where checking
compaction finish condition.

I will add the patch on next spin.

> 
> >Signed-off-by: Joonsoo Kim 
> >---
> >  include/linux/compaction.h |  2 --
> >  mm/compaction.c| 27 ---
> >  mm/page_alloc.c|  1 -
> >  3 files changed, 8 insertions(+), 22 deletions(-)
> >
> 
> ...
> 
> >diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >index 7002c66..f3605fd 100644
> >--- a/mm/page_alloc.c
> >+++ b/mm/page_alloc.c
> >@@ -2815,7 +2815,6 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned 
> >int order,
> > struct zone *zone = page_zone(page);
> >
> > zone->compact_blockskip_flush = false;
> 
> While we are here, I wonder if this is useful at all?

I think it's useful. We still have some cases that premature
compaction complete happens (e.g. async compaction). In this case,
if next sync compaction succeed, compact_blockskip_flush is cleared
and pageblock skip bit will not be reset so overhead would be reduced.

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 5/7] mm/compaction: respect compaction order when updating defer counter

[Joonsoo Kim]

On Fri, Dec 04, 2015 at 06:15:02PM +0100, Vlastimil Babka wrote:
> On 12/03/2015 08:11 AM, Joonsoo Kim wrote:
> >It doesn't make sense that we reset defer counter
> >in compaction_defer_reset() when compaction request under the order of
> >compact_order_failed succeed. Fix it.
> 
> Right.
> 
> >And, it does make sense that giving enough chance for updated failed
> >order compaction before deferring. Change it.
> 
> Sorry, can't understand the meaning here. From the code it seems
> that you want to reset defer_shift to 0 instead of increasing it,
> when the current order is lower than the failed one? That makes
> sense, yeah.

You correctly understand my intention. :)

> How about this?
> 
> "On the other hand, when deferring compaction for an order lower
> than the current compact_order_failed, we can assume the lower order
> will recover more quickly, so we should reset the progress made
> previously on compact_defer_shift with the higher order."

Will add it.

> 
> >Signed-off-by: Joonsoo Kim 
> 
> Acked-by: Vlastimil Babka 

Thanks.
> 
> >---
> >  mm/compaction.c | 19 +++
> >  1 file changed, 11 insertions(+), 8 deletions(-)
> >
> >diff --git a/mm/compaction.c b/mm/compaction.c
> >index 67b8d90..1a75a6e 100644
> >--- a/mm/compaction.c
> >+++ b/mm/compaction.c
> >@@ -126,11 +126,14 @@ static struct page *pageblock_pfn_to_page(unsigned 
> >long start_pfn,
> >   */
> >  static void defer_compaction(struct zone *zone, int order)
> >  {
> >-zone->compact_considered = 0;
> >-zone->compact_defer_shift++;
> >-
> >-if (order < zone->compact_order_failed)
> >+if (order < zone->compact_order_failed) {
> >+zone->compact_considered = 0;
> >+zone->compact_defer_shift = 0;
> > zone->compact_order_failed = order;
> >+} else {
> >+zone->compact_considered = 0;
> >+zone->compact_defer_shift++;
> >+}
> >
> > if (zone->compact_defer_shift > COMPACT_MAX_DEFER_SHIFT)
> > zone->compact_defer_shift = COMPACT_MAX_DEFER_SHIFT;
> >@@ -161,11 +164,11 @@ bool compaction_deferred(struct zone *zone, int order)
> >  /* Update defer tracking counters after successful compaction of given 
> > order */
> >  static void compaction_defer_reset(struct zone *zone, int order)
> >  {
> >-zone->compact_considered = 0;
> >-zone->compact_defer_shift = 0;
> >-
> >-if (order >= zone->compact_order_failed)
> >+if (order >= zone->compact_order_failed) {
> >+zone->compact_considered = 0;
> >+zone->compact_defer_shift = 0;
> > zone->compact_order_failed = order + 1;
> >+}
> >
> > trace_mm_compaction_defer_reset(zone, order);
> >  }
> >
> 
> --
> 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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: email-clients.txt

[Clemens Ladisch]

Sanidhya Solanki wrote:
>  Claws Mail (GUI)
>
> -Works. Some people use this successfully for patches.
> +Tested and Works as of December 2015. Some people use this successfully
> +for patches.

"Some people" still doesn't include you:

> -Thunderbird is an Outlook clone that likes to mangle text, but there
> are ways -to coerce it into behaving.
> +Thunderbird is an Outlook clone that likes to mangle text, but there
> are +ways to coerce it into behaving. In December 2015, the internal
> editor +options do not appear to work.

How exactly?  Thunderbird appears to work for me, and doesn't break long lines 
or sends plain text as "flowed".

And version numbers might be more useful than dates.


Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 akpm-current tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/x86/mm/pgtable.c

between commit:

  d6ccc3ec9525 ("x86/paravirt: Remove paravirt ops pmd_update[_defer] and 
pte_update_defer")

from the tip tree and commit:

  275461f0db1f ("x86, thp: remove infrastructure for handling splitting PMDs")

from the akpm-current tree.

I fixed it up (I removed the function (pmdp_splitting_flush) removed by
the latter) and can carry the fix as necessary (no action is required).



-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tpmdd-devel] [PATCH v2 0/3] tpm_tis: Clean up force module parameter

[Wilck, Martin]

> > I'm a bit confused about the discussion because Martin replied that
> > tpm_tis used to get the address range before applying this series.
> > 
> > And pnp_driver in the backend for TPM 1.x devices grabs the address
> > range from DSDT.
> 
> You can completely ignore this question. I saw Martins reply with a fix for
> "tpm_tis: Use devm_ioremap_resource" that you should squash into that
> change. So it's proved that TPM ACPI device objects do not always have a
> memory resource. Good.

Repeat, the memory resource DOES exist on my system. Not sure what proof
you saw there.

Martin

Re: [PATCH v2 77/71] ncr5380: Fix wait for 53C80 registers registers after PDMA

[Ondrej Zary]

On Monday 07 December 2015 04:16:14 Finn Thain wrote:
> 
> On Mon, 7 Dec 2015, Ondrej Zary wrote:
> 
> > The check for 53C80 registers accessibility was commented out because
> > it was broken (inverted). Fix and enable it.
> > 
> > Signed-off-by: Ondrej Zary 
> > ---
> >  drivers/scsi/g_NCR5380.c |   37 ++---
> >  1 file changed, 6 insertions(+), 31 deletions(-)
> > 
> > diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> > index 038dddf..a7479c6 100644
> > --- a/drivers/scsi/g_NCR5380.c
> > +++ b/drivers/scsi/g_NCR5380.c
> > @@ -603,14 +603,10 @@ static inline int NCR5380_pread(struct Scsi_Host 
> > *instance, unsigned char *dst,
> > if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
> > printk("53C400r: no 53C80 gated irq after transfer");
> >  
> > -#if 0
> > -   /*
> > -*  DON'T DO THIS - THEY NEVER ARRIVE!
> > -*/
> > -   printk("53C400r: Waiting for 53C80 registers\n");
> > -   while (NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG)
> > +   /* wait for 53C80 registers to be available */
> > +   while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG))
> > ;
> 
> In the previous patch, udelay(4) was added to a CSR_GATED_53C80_IRQ 
> polling loop. It is interesting that you don't need it here when polling 
> CSR_53C80_REG.

Yes, it's weird. Reads work fine without the delay. Small writes work most of
the time without the delay but crash sometimes. Large writes crash the chip
consistently without the delay.

> > -#endif
> > +
> > if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
> > printk(KERN_ERR "53C400r: no end dma signal\n");
> > 
> > @@ -632,7 +628,6 @@ static inline int NCR5380_pwrite(struct Scsi_Host 
> > *instance, unsigned char *src,
> > struct NCR5380_hostdata *hostdata = shost_priv(instance);
> > int blocks = len / 128;
> > int start = 0;
> > -   int i;
> >  
> > NCR5380_write(hostdata->c400_ctl_status, CSR_BASE);
> > NCR5380_write(hostdata->c400_blk_cnt, blocks);
> > @@ -681,36 +676,16 @@ static inline int NCR5380_pwrite(struct Scsi_Host 
> > *instance, unsigned char *src,
> > blocks--;
> > }
> >  
> > -#if 0
> > -   printk("53C400w: waiting for registers to be available\n");
> > -   THEY NEVER DO ! while (NCR5380_read(hostdata->c400_ctl_status) & 
> > CSR_53C80_REG);
> > -   printk("53C400w: Got em\n");
> > -#endif
> > -
> > -   /* Let's wait for this instead - could be ugly */
> > -   /* All documentation says to check for this. Maybe my hardware is too
> > -* fast. Waiting for it seems to work fine! KLL
> > -*/
> > -   while (!(i = NCR5380_read(hostdata->c400_ctl_status) & 
> > CSR_GATED_53C80_IRQ)) {
> > +   /* wait for 53C80 registers to be available */
> > +   while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG)) {
> > udelay(4); /* DTC436 chip hangs without this */
> 
> ... based on the above, this udelay is probably not needed.
> 
> (Or perhaps it is only needed once, in between the final host_buf register 
> access and the first ctl_status access??)

I guess that the delay is needed when the chip does write in the background.
But why only on the last block?
Adding delays inside the while(1) loop does not help, it crashes anyway.
Single delay before the first ctl_status does not help either (perhaps only
if it's long enough for the write to complete).

The chip also crashes in transfer_pio during bigger transfers in a similar
way. With Quantum HDD, it did not crash once I got PDMA working.
But with a faster IBM HDD, it crashes even with smaller PIO trasnfers.

> Is there any reference in the docs to timing sensitivity?

Haven't found anything in NCR docs. Unfortunately, we don't have any DTC
docs.

> > /* FIXME - no timeout */
> > }
> >  
> > -   /*
> > -* I know. i is certainly != 0 here but the loop is new. See previous
> > -* comment.
> > -*/
> 
> Thanks for cleaning up this mess!
> 


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

Re: [PATCH v2 1/9] clk: hi3519: add dt-binding document and header file

[xuejiancheng]

On 2015/12/4 18:56, Arnd Bergmann wrote:
> On Friday 04 December 2015 11:21:28 xuejiancheng wrote:
>> Hi Arnd,
>>
>> On 2015/12/3 17:44, Arnd Bergmann wrote:
>>> On Thursday 03 December 2015 10:39:24 Jiancheng Xue wrote:
 +#ifndef __DTS_HI3519_CLOCK_H
 +#define __DTS_HI3519_CLOCK_H
>>>
>>> Please try to avoid adding headers like this if you can at all.
>>>
>>> I might ask you to merge the header file in one merge window
>>> otherwise and submit the platform code one kernel later, as they
>>> tendn to cause us needless dependencies otherwise.
>>>
>>
>> Sorry. In v1, Rob suggested putting binding doc and header files in
>> a separate patch. The clock driver indeed depends on the header.
>>
>> I will put the header and the clock driver in a patch, and keep the
>> binding doc in another patch.
> 
> Having split patches is better, I was really commenting on the fact
> that ideally you would not have a header file at all. If we merge
> the header through arm-soc, then you won't be able to merge the
> clk driver easily, and if you merge the header through the clk
> maintainer, I'm can't take your dts files.

Thank you for your comments. Because the clocks in the crg module have
different types and random layouts. If this header file is removed,
the clock driver and the dts files will get very complicated.

Could you help me acknowledge it if I put the header file and clock driver
in a patch?

Could you give me some suggestions If I want to keep this header file?

> 
 +/* fixed rate */
 +#define HI3519_FIXED_400M  1
 +#define HI3519_FIXED_200M  2
 +#define HI3519_FIXED_125M  3
 +#define HI3519_FIXED_150M  4
 +#define HI3519_FIXED_75M   5
 +#define HI3519_FIXED_300M  6
 +#define HI3519_FIXED_50M   7
 +#define HI3519_FIXED_24M   8
 +#define HI3519_FIXED_3M9
 +
 +/* mux clocks */
 +#define HI3519_FMC_MUX 32
 +#define HI3519_I2C_MUX 33
 +#define HI3519_UART_MUX34
 +#define HI3519_SYSAXI_MUX  35
 +
 +/*fixed factor clocks*/
 +#define HI3519_SYSAPB_CLK  64
 +
 +/* gate clocks */
 +#define HI3519_FMC_CLK 129
 +#define HI3519_UART0_CLK   153
 +#define HI3519_UART1_CLK   154
 +#define HI3519_UART2_CLK   155
 +#define HI3519_UART3_CLK   156
 +#define HI3519_UART4_CLK   157
>>>
>>> Where do those numbers come from? They are not consecutive, so it sounds
>>> like they are directly from the data sheet and won't be needed in the 
>>> driver.
>>> If that's true, just use the numbers directly, as you do for everything
>>> else.
>>
>> The numbers are defined by myself, not directly from the data sheet. Some 
>> numbers
>> are reserved for device nodes which will be added later. So they are not 
>> consecutive now.
> 
> I don't understand. How do you decide which numbers to reserve? If the
> numbers are completely arbitrary and you have no idea what other clocks
> there are, you can simply have consecutive numbers here and do the driver
> accordingly.

The clocks are divided into several groups according to their types. The clocks 
in
a group are expected to have consecutive numbers. So some numbers are reserved 
for
every group in this file, just like in some existing headers. Other clocks will 
be
added when other peripherals drivers are submitted. They will use the reserve 
numbers
and be inserted into existing groups.

Of course it is not required to reserve numbers for later added clocks.

> 
> If the numbers actually have a real meaning, then you either don't need them
> at all, or you could just put all numbers in there that you would eventually 
> need.

The numbers have no hardware meaning actually.

> 
 +#define HI3519_NR_CLKS 256
 +#define HI3519_NR_RSTS 256

>>> These seem to not be needed at all.
>>
>> These are used in drivers/clk/hisilicon/clk-hi3519.c.
> 
> Then move them there. Anything that is not needed by *both* the driver and 
> the dts files doesn't belong in here.


OK. I will move them into the driver code.

> 
>   Arnd
> 
> .
> 

Many thanks.

Jiancheng

.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv6 5/5] drm: bridge: anx78xx: Add anx78xx driver support by analogix.

[Dan Carpenter]

On Fri, Dec 04, 2015 at 09:35:07AM +0100, Enric Balletbo i Serra wrote:
> +static int sp_wait_aux_op_finish(struct anx78xx *anx78xx)
> +{
> + u8 errcnt;
> + u8 val;
> + struct device *dev = &anx78xx->client->dev;
> +
> + errcnt = 150;
> + while (errcnt--) {
> + sp_reg_read(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG, &val);
> + if (!(val & SP_AUX_EN))
> + break;
> + usleep_range(2000, 4000);
> + }
> +
> + if (!errcnt) {

This is off by one.  It should be:

while (--errcnt) {
...
}
if (errcnt == 0)
return -EWHATEVER;

Or:

while (errcnt--) {
...
}
if (errcnt == -1)
return -EWHATEVER;

Also "errcnt" is a bad name, it should be retry_cnt or something (or
maybe it actually is counting errors?).  Also -1 is never a correct
error code, please change all the -1 returns to something better.

> + /* Buffer size of AUX CH is 16 */
> + if (count > 16)
> + return -1;

Just make a define so that you don't need to add comments about why 16
is correct.

if (count > SIZE_AUX_CH)
return -EINVAL;

> + errcnt = 10;
> + while (errcnt--) {
> + sp_reg_read(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG, &val);
> + if (!(val & SP_AUX_EN))
> + break;
> + usleep_range(1000, 2000);
> + }
> +
> + if (!errcnt) {
> + dev_err(dev,
> + "failed to read DP AUX Channel Control Register 2\n");
> + sp_reset_aux(anx78xx);
> + return -1;
> + }

Off by one again.


> +
> + sp_reg_write(anx78xx, TX_P0, SP_AUX_ADDR_7_0_REG, SP_I2C_EXTRA_ADDR);
> + sp_tx_aux_wr(anx78xx, offset);
> + /* read 16 bytes (MOT = 1) */
> + sp_tx_aux_rd(anx78xx, 0xf0 | DP_AUX_I2C_MOT | DP_AUX_I2C_READ);
> +
> + for (i = 0; i < 16; i++) {
> + errcnt = 10;
> + while (errcnt--) {
> + sp_reg_read(anx78xx, TX_P0, SP_BUF_DATA_COUNT_REG,
> + &val);
> + if (val & SP_BUF_DATA_COUNT_MASK)
> + break;
> + usleep_range(2000, 4000);
> + }
> +
> + if (!errcnt) {
> + dev_err(dev,
> + "failed to read DP Buffer Data Count 
> Register\n");
> + sp_reset_aux(anx78xx);
> + return -1;
> + }

And here.

> + errcnt = 10;
> + while (errcnt--) {
> + sp_reg_read(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG, &val);
> + if (!(val & SP_AUX_EN))
> + break;
> + usleep_range(1000, 2000);
> + }
> +
> + if (!errcnt) {
> + dev_err(dev,
> + "failed to read DP AUX Channel Control Register 2\n");
> + sp_reset_aux(anx78xx);
> + return -1;
> + }

Here.


> +
> + return 0;
> +}
> +
> +static int sp_edid_block_checksum(const u8 *raw_edid)
> +{
> + int i;
> + u8 csum = 0;
> +
> + for (i = 0; i < EDID_LENGTH; i++)
> + csum += raw_edid[i];
> +
> + return csum;
> +}
> +
> +static int sp_tx_edid_read(struct anx78xx *anx78xx)
> +{
> + struct device *dev = &anx78xx->client->dev;
> + u8 val, last_block, offset = 0;
> + u8 buf[16];
> + int i, j, count;
> +
> + sp_tx_edid_read_initial(anx78xx);
> + sp_reg_write(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL1_REG, 0x04);
> + sp_reg_set_bits(anx78xx, TX_P0, SP_DP_AUX_CH_CTRL2_REG,
> + SP_AUX_EN | SP_ADDR_ONLY);
> +
> + if (sp_wait_aux_op_finish(anx78xx))
> + return -1;
> +
> + sp_addronly_set(anx78xx, false);
> +
> + /* Read the number of blocks */
> + sp_tx_aux_wr(anx78xx, 0x7e);
> + sp_tx_aux_rd(anx78xx, DP_AUX_I2C_READ);
> + sp_reg_read(anx78xx, TX_P0, SP_DP_BUF_DATA0_REG, &last_block);
> + dev_dbg(dev, "last EDID block is %d\n", last_block);
> +
> + /* FIXME: Why not just cap to 3 if the reported value is >3 */
> + if (last_block > 3)
> + last_block = 1;
> +
> + /* for every block */
> + for (count = 0; count <= last_block; count++) {
> + switch (count) {
> + case 0:
> + case 1:
> + for (i = 0; i < 8; i++) {
> + offset = (i + count * 8) * 16;
> + if (sp_edid_read(anx78xx, offset, buf))
> + return -1;
> + for (j = 0; j < 16; j++)
> + sp.edid_blocks[offset + j] = buf[j];
> + }
> + break;
> + case 2:
> + case 3:
> + offset = (count == 2) ? 0x00 : 0x80;
> + for (j = 0; j < 8; 

linux-next: manual merge of the akpm-current tree with the block tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in:

  fs/block_dev.c

between commit:

  6f3b0e8bcf3c ("blk-mq: add a flags parameter to blk_mq_alloc_request")

from the block tree and commit:

  f39b774555f0 ("fs/block_dev.c:bdev_write_page(): use blk_queue_enter(..., 
GFP_NOIO)")

from the akpm-current tree.

I fixed it up (see below, though I am not sure it is the correct fix?) and
can carry the fix as necessary (no action is required).

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

diff --cc fs/block_dev.c
index aa1a45985889,c27362de0039..
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@@ -432,7 -432,7 +432,7 @@@ int bdev_write_page(struct block_devic
  
if (!ops->rw_page || bdev_get_integrity(bdev))
return -EOPNOTSUPP;
-   result = blk_queue_enter(bdev->bd_queue, false);
 -  result = blk_queue_enter(bdev->bd_queue, GFP_NOIO);
++  result = blk_queue_enter(bdev->bd_queue, true);
if (result)
return result;
  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 3/4] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Jean-Francois Moine]

On Fri,  4 Dec 2015 22:24:42 +0100
Jens Kuske  wrote:

> The Allwinner H3 is a home entertainment system oriented SoC with
> four Cortex-A7 cores and a Mali-400MP2 GPU.
> 
> Signed-off-by: Jens Kuske 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 497 
> 
>  1 file changed, 497 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-h3.dtsi
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> new file mode 100644
> index 000..1524130e
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -0,0 +1,497 @@
[snip]
> + bus_gates: clk@01c20060 {
> + #clock-cells = <1>;
> + compatible = "allwinner,sun8i-h3-bus-gates-clk";
> + reg = <0x01c20060 0x14>;
> + clocks = <&ahb1>, <&ahb2>, <&apb1>, <&apb2>;
> + clock-names = "ahb1", "ahb2", "apb1", "apb2";
> + clock-indices = <5>, <6>, <8>,
> + <9>, <10>, <13>,
> + <14>, <17>, <18>,
> + <19>, <20>,
> + <21>, <23>,
> + <24>, <25>,
> + <26>, <27>,
> + <28>, <29>,
> + <30>, <31>, <32>,
> + <35>, <36>, <37>,
> + <40>, <41>, <43>,
> + <44>, <52>, <53>,
> + <54>, <64>,
> + <65>, <69>, <72>,
> + <76>, <77>, <78>,
> + <96>, <97>, <98>,
> + <112>, <113>,
> + <114>, <115>,
> + <116>, <128>, <135>;
> + clock-output-names = "bus_ce", "bus_dma", "bus_mmc0",
> +  "bus_mmc1", "bus_mmc2", "bus_nand",
> +  "bus_sdram", "bus_gmac", "bus_ts",
> +  "bus_hstimer", "bus_spi0",
> +  "bus_spi1", "bus_otg",
> +  "bus_otg_ehci0", "bus_ehci1",
> +  "bus_ehci2", "bus_ehci3",
> +  "bus_otg_ohci0", "bus_ohci1",
> +  "bus_ohci2", "bus_ohci3", "bus_ve",
> +  "bus_lcd0", "bus_lcd1", 
> "bus_deint",

The tcon1 clock is used by both lcd0 and lcd1, while the tcon0 clock is used 
for TV output from lcd1, so, this should be:

"bus_tcon0", "bus_tcon1", "bus_deint",

(the tcon1 clock is used by both lcd0 and lcd1, while
 the tcon0 clock is used for TV output from lcd1)

> +  "bus_csi", "bus_tve", "bus_hdmi",
> +  "bus_de", "bus_gpu", "bus_msgbox",
> +  "bus_spinlock", "bus_codec",
> +  "bus_spdif", "bus_pio", "bus_ths",
> +  "bus_i2s0", "bus_i2s1", "bus_i2s2",
> +  "bus_i2c0", "bus_i2c1", "bus_i2c2",
> +  "bus_uart0", "bus_uart1",
> +  "bus_uart2", "bus_uart3",
> +  "bus_scr", "bus_ephy", "bus_dbg";
> + };
[snip]

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 next 2/2] net: hns: fixes no syscon error when init mdio

[yankejian]

as dtsi files use the normal naming conventions using '-' instead of '_'
inside of property names, the driver needs to update the phandle name
strings of the of_parse_phandle func.

Signed-off-by: yankejian 
---
 drivers/net/ethernet/hisilicon/hns_mdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns_mdio.c 
b/drivers/net/ethernet/hisilicon/hns_mdio.c
index 37491c8..1e07e91 100644
--- a/drivers/net/ethernet/hisilicon/hns_mdio.c
+++ b/drivers/net/ethernet/hisilicon/hns_mdio.c
@@ -458,7 +458,7 @@ static int hns_mdio_probe(struct platform_device *pdev)
}
 
mdio_dev->subctrl_vbase =
-   syscon_node_to_regmap(of_parse_phandle(np, "subctrl_vbase", 0));
+   syscon_node_to_regmap(of_parse_phandle(np, "subctrl-vbase", 0));
if (IS_ERR(mdio_dev->subctrl_vbase)) {
dev_warn(&pdev->dev, "no syscon hisilicon,peri-c-subctrl\n");
mdio_dev->subctrl_vbase = NULL;
-- 
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] arm64: dts: mt8173: Add nor flash node

[Daniel Kurtz]

Bayi,

On Mon, Dec 7, 2015 at 12:46 PM, bayi cheng  wrote:
> On Mon, 2015-12-07 at 12:34 +0800, bayi cheng wrote:
>> On Mon, 2015-12-07 at 12:09 +0800, Daniel Kurtz wrote:
>> > Bayi,
>> >
>> > On Mon, Dec 7, 2015 at 11:53 AM, Bayi Cheng  
>> > wrote:
>> > > Add Mediatek nor flash node
>> > >
>> > > Signed-off-by: Bayi Cheng 
>> > > Acked-by: Brian Norris 
>> > > ---
>> > > Previous version of this patch is
>> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/386005.html
>> > > Drop flash node from mt8173.dtsi accroding review comment
>> >
>> > Is there a flash on mt8173-evb that can be accessed by the nor_flash ?
>> > If so, can you include flash@0 node in the mt8173-evb.dts.
>> >
>> > -Dan
>> >
>> Hi Daniel, Thanks for your comments! you are right, there is a flash on
>> mt8173-evb which can be accessed by the nor_flash, and I will include
>> flash@0 node in mt8173-evb.dts (kernel v3.18) too.
>>
>> Bayi
>
> Hi Dan, I have reworked a EVB board for spi nor verify, we replaced the
> spi nand flash with spi nor flash on EVB board,
> and our shipping EVB board haven't support spi nor flash, So I will not
> include flash@0 node in the mt8173-evb.dts. I am sorry to made you
> confused!

Thanks for confirming.

Reviewed-by: Daniel Kurtz 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero

[Ingo Molnar]

* Rusty Russell  wrote:

> Ingo Molnar  writes:
> > * Rusty Russell  wrote:
> >> I don't think there are great answers here.  But adding more subtle 
> >> zeroing 
> >> semantics feels wrong, even if it will mostly Just Work.
> >
> > It's not subtle if the naming clearly reflects it (hence my suggestion to 
> > rename 
> > the API) - and the status quo for on-stack allocations is zeroing anyway, 
> > so it's 
> > not a big jump...
> 
> True, but we already have zalloc_cpumask_var() though if we want that?

Indeed, didn't realize that.

> It probably makes sense to just switch everyone to that and get rid of the 
> non-z 
> one?

Yeah, I think this long-lived bug is a proper trigger for that. Lemme send a 
2-patch series.

Thanks,

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

[PATCH v2 next 0/2] dts: hisi: fixes no syscon error when init mdio

[yankejian]

this patchset fixes the bug that eth can't initial successful on hip05-D02
because the dts files doesn't match the source code.

yankejian (2):
  dts: hisi: fixes no syscon error when init mdio
  net: hns: fixes no syscon error when init mdio

---
change log:
v2:
 1) update the related documented in the binding as well
 2) use the normal naming conventions using '-' instead of '_', and
update the related *.c files.

v1:
 initial version

 .../devicetree/bindings/arm/hisilicon/hisilicon.txt  | 16 
 arch/arm64/boot/dts/hisilicon/hip05.dtsi |  5 +
 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi |  4 ++--
 drivers/net/ethernet/hisilicon/hns_mdio.c|  2 +-
 4 files changed, 24 insertions(+), 3 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 next 1/2] dts: hisi: fixes no syscon error when init mdio

[yankejian]

Signed-nux start up, we get the log below:
"Hi-HNS_MDIO 803c.mdio: no syscon hisilicon,peri-c-subctrl
 mdio_bus mdio@803c: mdio sys ctl reg has not maped   "

the source code about the subctrl is dealled with syscon, but dts doesn't.
it cause such fault. so this patch adds the syscon info on dts files to
fixes it. and it adds documentation for the devicetree bindings used by
DT files of Hisilicon Hip05-D02 development board.

Signed-off-by: yankejian 
---
change log:
v2:
 1) updates the related documented in the binding as well
 2) use the normal naming conventions using '-' instead of '_'

v1:
 initial version
---
 .../devicetree/bindings/arm/hisilicon/hisilicon.txt  | 16 
 arch/arm64/boot/dts/hisilicon/hip05.dtsi |  5 +
 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi |  4 ++--
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 6ac7c00..9f05767 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -187,6 +187,22 @@ Example:
reg = <0xb000 0x1>;
};
 
+Hisilicon HiP05 PERISUB system controller
+
+Required properties:
+- compatible : "hisilicon,peri-c-subctrl", "syscon";
+- reg : Register address and size
+
+The HiP05 PERISUB system controller is shared by peripheral controllers in
+HiP05 Soc to implement some basic configurations. the peripheral
+controllers include mdio, ddr, iic, uart, timer and so on.
+
+Example:
+   /* for HiP05 PCIe-SAS system */
+   peri-c-subctrl: sub-ctrl-c@8000 {
+   compatible = "hisilicon,peri-c-subctrl", "syscon";
+   reg = <0x0 0x8000 0x0 0x1>;
+   };
 ---
 Hisilicon CPU controller
 
diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
index 4ff16d0..5fec740 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
@@ -246,6 +246,11 @@
clock-frequency = <2>;
};
 
+   peri_c_subctrl: sub-ctrl-c@8000 {
+   compatible = "hisilicon,peri-c-subctrl", "syscon";
+   reg = < 0x0 0x8000 0x0 0x1>;
+   };
+
uart0: uart@8030 {
compatible = "snps,dw-apb-uart";
reg = <0x0 0x8030 0x0 0x1>;
diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
index 606dd5a..da7b6e6 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
@@ -10,8 +10,8 @@ soc0: soc@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "hisilicon,hns-mdio";
-   reg = <0x0 0x803c 0x0 0x1
-  0x0 0x8000 0x0 0x1>;
+   reg = <0x0 0x803c 0x0 0x1>;
+   subctrl-vbase = <&peri_c_subctrl>;
 
soc0_phy0: ethernet-phy@0 {
reg = <0x0>;
-- 
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 v9 3/4] irqchip:create irq domain for each mbigen device

[Marc Zyngier]

On Sun, 6 Dec 2015 15:53:20 -0500
majun  wrote:

> Hi Marc:
> 
> On 2015/12/3 11:25, Marc Zyngier wrote:
> > On 23/11/15 03:15, MaJun wrote:
> >> From: Ma Jun 
> >>
> >> For peripheral devices which connect to mbigen,mbigen is a interrupt
> >> controller. So, we create irq domain for each mbigen device and add
> >> mbigen irq domain into irq hierarchy structure.
> >>
> >> Signed-off-by: Ma Jun 
> >> ---
> >>  drivers/irqchip/irq-mbigen.c |  119 
> >> ++
> >>  1 files changed, 119 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> >> index 9f036c2..81ae61f 100644
> >> --- a/drivers/irqchip/irq-mbigen.c
> >> +++ b/drivers/irqchip/irq-mbigen.c
> >> @@ -16,13 +16,36 @@
> >>   * along with this program.  If not, see .
> >>   */
> >>  
> >> +#include 
> >> +#include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>  
> >> +/* Interrupt numbers per mbigen node supported */
> >> +#define IRQS_PER_MBIGEN_NODE  128
> >> +
> >> +/* 64 irqs (Pin0-pin63) are reserved for each mbigen chip */
> >> +#define RESERVED_IRQ_PER_MBIGEN_CHIP  64
> >> +
> >> +/**
> >> + * In mbigen vector register
> >> + * bit[21:12]:event id value
> >> + * bit[11:0]: device id
> >> + */
> >> +#define IRQ_EVENT_ID_SHIFT12
> >> +#define IRQ_EVENT_ID_MASK 0x3ff
> >> +
> >> +/* register range of each mbigen node */
> >> +#define MBIGEN_NODE_OFFSET0x1000
> >> +
> >> +/* offset of vector register in mbigen node */
> >> +#define REG_MBIGEN_VEC_OFFSET 0x200
> >> +
> >>  /**
> >>   * struct mbigen_device - holds the information of mbigen device.
> >>   *
> >> @@ -34,10 +57,94 @@ struct mbigen_device {
> >>void __iomem*base;
> >>  };
> >>  
> >> +static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq)
> >> +{
> >> +  unsigned int nid, pin;
> >> +
> >> +  hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
> >> +  nid = hwirq / IRQS_PER_MBIGEN_NODE + 1;
> >> +  pin = hwirq % IRQS_PER_MBIGEN_NODE;
> >> +
> >> +  return pin * 4 + nid * MBIGEN_NODE_OFFSET
> >> +  + REG_MBIGEN_VEC_OFFSET;
> >> +}
> >> +
> >> +static struct irq_chip mbigen_irq_chip = {
> >> +  .name = "mbigen-v2",
> >> +};
> >> +
> >> +static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
> >> +{
> >> +  struct irq_data *d = irq_get_irq_data(desc->irq);
> >> +  void __iomem *base = d->chip_data;
> >> +  u32 val;
> >> +
> >> +  base += get_mbigen_vec_reg(d->hwirq);
> >> +  val = readl_relaxed(base);
> >> +
> >> +  val &= ~(IRQ_EVENT_ID_MASK << IRQ_EVENT_ID_SHIFT);
> >> +  val |= (msg->data << IRQ_EVENT_ID_SHIFT);
> >> +
> >> +  writel_relaxed(val, base);
> > 
> > nit: It would be good to have a comment explaining why you do not need
> > to program the address of the doorbell...
> 
> The address of doorbell is encoded in mbigen register by default,
> So, we don't need to program the doorbell address in mbigen driver.
> 
> I'll add this comment in next version.
> 
> > 
> >> +}
> >> +
> >> +static int mbigen_domain_translate(struct irq_domain *d,
> >> +  struct irq_fwspec *fwspec,
> >> +  unsigned long *hwirq,
> >> +  unsigned int *type)
> >> +{
> >> +  if (is_of_node(fwspec->fwnode)) {
> >> +  if (fwspec->param_count != 2)
> >> +  return -EINVAL;
> >> +
> >> +  *hwirq = fwspec->param[0];
> >> +  *type = fwspec->param[1] & IRQ_TYPE_SENSE_MASK;
> >> +
> >> +  return 0;
> >> +  }
> >> +  return -EINVAL;
> >> +}
> >> +
> >> +static int mbigen_irq_domain_alloc(struct irq_domain *domain,
> >> +  unsigned int virq,
> >> +  unsigned int nr_irqs,
> >> +  void *args)
> >> +{
> >> +  struct irq_fwspec *fwspec = args;
> >> +  irq_hw_number_t hwirq;
> >> +  unsigned int type;
> >> +  struct mbigen_device *mgn_chip;
> >> +  int i, err;
> >> +
> >> +  err = mbigen_domain_translate(domain, fwspec, &hwirq, &type);
> >> +  if (err)
> >> +  return err;
> >> +
> >> +  err = platform_msi_domain_alloc(domain, virq, nr_irqs);
> >> +  if (err)
> >> +  return err;
> >> +
> >> +  mgn_chip = platform_msi_get_host_data(domain);
> >> +
> >> +  for (i = 0; i < nr_irqs; i++)
> >> +  irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> >> +&mbigen_irq_chip, mgn_chip->base);
> >> +
> >> +  return 0;
> >> +}
> >> +
> >> +static struct irq_domain_ops mbigen_domain_ops = {
> >> +  .translate  = mbigen_domain_translate,
> >> +  .alloc  = mbigen_irq_domain_alloc,
> >> +  .free   = irq_domain_free_irqs_common,
> >> +};
> >> +
> >>  static int mbigen_device_probe(struct platform_device *pdev

Re: [PATCH] Staging: speakup: kobjects: Return the error type to caller

[Dan Carpenter]

On Mon, Dec 07, 2015 at 12:46:37PM +0530, Saurabh Sengar wrote:
> >> @@ -688,6 +689,8 @@ ssize_t spk_var_store(struct kobject *kobj, struct 
> >> kobj_attribute *attr,
> >>
> >>   if (ret == -ERESTART)
> >>   pr_info("%s reset to default value\n", param->name);
> >
> > Is this really true?
> Sorry, I am not sure here what you mean here.
> I have not implemented it.
> >
> > This function is so weird and broken.  Please look at it some more and
> > fix it harder with a mallet.
> You mean I broke it ?

No, I mean it was broken to begin with.  Write a more extensive patch to
fix it.

That printk should be moved up to where we actually do the reset.
Anyway speakup is actually really bad and there is a lot of broken
stuff so you don't have to fix this function if you don't want to.  Just
fix the -ERANGE issue I mentioned and resend if you want.

regards,
dan carpenter

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

Re: [PATCH] mmc: sdhci-acpi: set non-removable in ACPI table

[Adrian Hunter]

On 04/12/15 17:40, Philip Elcan wrote:
> 
> On 12/03/2015 09:14 AM, Adrian Hunter wrote:
>> On 03/12/15 15:48, Philip Elcan wrote:
>>> This allows setting an SDHC controller as non-removable
>>> by using the _RMV method in the ACPI table. It doesn't
>> Is that _RMV on the host controller?  Shouldn't it be on the card i.e. child
>> device node?
> 
> Yes, this is on the host controller. The ACPI table only describes the
> host controller, not the child nodes.
> 

If you look at Intel devices, the _RMV is on the child e.g.

Device (SDHA)
{
Name (_HID, "80860F14")  // _HID: Hardware ID
Name (_CID, "PNP0D40")  // _CID: Compatible ID
Name (_DDN, "Intel(R) eMMC Controller - 80860F14")  // _DDN: DOS 
Device Name
...
Device (EMMD)
{
...
Method (_RMV, 0, NotSerialized)  // _RMV: Removal Status
{
Return (Zero)
}
}
}

I am not an ACPI expert but that seems like the correct place for it.

>>
>>> mark it as non-removable if GPIO card detection is
>>> already setup.
>>>
>>> Signed-off-by: Philip Elcan 
>>> ---
>>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/10] i915: Replace "hweight8(dev_priv->info.subslice_7eu[i]) != 1" with "!is_power_of_2(dev_priv->info.subslice_7eu[i])"

[Jani Nikula]

On Sun, 06 Dec 2015, Zhaoxiu Zeng  wrote:
> From: Zeng Zhaoxiu 
>
> Signed-off-by: Zeng Zhaoxiu 

I'd like to see a commit message describing what is done and why, even
for trivial changes. Now the subject line is essentially the diff in
plain English, which adds no information to the patch itself.

It doesn't even say that this should be a non-functional change.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 9461a23..16c8cf1 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -27,6 +27,7 @@
>   *
>   */
>  
> +#include 
>  #include 
>  #include "i915_drv.h"
>  #include 
> @@ -1000,7 +1001,7 @@ static int skl_tune_iz_hashing(struct intel_engine_cs 
> *ring)
>* Only consider slices where one, and only one, subslice has 7
>* EUs
>*/
> - if (hweight8(dev_priv->info.subslice_7eu[i]) != 1)
> + if (!is_power_of_2(dev_priv->info.subslice_7eu[i]))
>   continue;
>  
>   /*

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] input: gt801_2plus1 - Add initial support for Goodix GT801 2+1

[Julia Lawall]

It looks like braces may be mising.  Please check.

julia

On Mon, 7 Dec 2015, kbuild test robot wrote:

> Hi Priit,
> 
> [auto build test WARNING on mripard/sunxi/for-next]
> [also build test WARNING on next-20151203]
> [cannot apply to input/next v4.4-rc4]
> 
> url:
> https://github.com/0day-ci/linux/commits/Priit-Laes/input-Driver-for-Goodix-GT801-2-1-touchscreen/20151207-152831
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git 
> sunxi/for-next
> :: branch date: 46 minutes ago
> :: commit date: 46 minutes ago
> 
> >> drivers/input/touchscreen/gt801_2plus1.c:119:3-30: code aligned with 
> >> following code on line 120
> 
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout d66df313f96e04572821e49cada65cb5c1bea9e2
> vim +119 drivers/input/touchscreen/gt801_2plus1.c
> 
> d66df313 Priit Laes 2015-12-07  113   return;
> d66df313 Priit Laes 2015-12-07  114  
> d66df313 Priit Laes 2015-12-07  115   /* Build touch map */
> d66df313 Priit Laes 2015-12-07  116   touch_num = 0;
> d66df313 Priit Laes 2015-12-07  117   for (i = 0; (touch_raw != 0) && (i < 
> ts->max_touch_num); i++) {
> d66df313 Priit Laes 2015-12-07  118   if (touch_raw & 1)
> d66df313 Priit Laes 2015-12-07 @119   touch_map[touch_num++] 
> = i;
> d66df313 Priit Laes 2015-12-07 @120   touch_raw >>= 1;
> d66df313 Priit Laes 2015-12-07  121   }
> d66df313 Priit Laes 2015-12-07  122  
> d66df313 Priit Laes 2015-12-07  123   /* Calculate checksum */
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] net: hns: optimize XGE capability by reducing cpu usage

[Yankejian (Hackim Yim)]

On 2015/12/7 11:29, David Miller wrote:
> From: yankejian 
> Date: Sat, 5 Dec 2015 15:32:29 +0800
>
>> +#if (PAGE_SIZE < 8192)
>> +if (hnae_buf_size(ring) == HNS_BUFFER_SIZE_2048) {
>> +truesize = hnae_buf_size(ring);
>> +} else {
>> +truesize = ALIGN(size, L1_CACHE_BYTES);
>> +last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
>> +}
>> +
>> +#else
>> +truesize = ALIGN(size, L1_CACHE_BYTES);
>> +last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
>> +#endif
> This is not indented properly, and it looks terrible.
>
> .
>
Hi David,
Thanks for pointing it out. i will pay attention next time.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] acpi, apei, hest: Move HEST table initialization where it belongs.

[fu . wei]

From: Tomasz Nowicki 

Since HEST (hardware error sources table) can describe more than PCI
specific errors, it needs to be moved out of acpi_pci_root_init.

Changelog:
v1: This patch - the first upstream patch to linux mailing lists.
Fu Wei:
(1)Rebase to v4.4-rc4;
(2)Remove "#include " from drivers/acpi/pci_root.c]

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Fu Wei 
---
 drivers/acpi/pci_root.c | 2 --
 drivers/acpi/scan.c | 3 +++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index ae3fe4e..a35dd23 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include  /* for acpi_hest_init() */
 
 #include "internal.h"
 
@@ -865,7 +864,6 @@ out_release_info:
 
 void __init acpi_pci_root_init(void)
 {
-   acpi_hest_init();
if (acpi_pci_disabled)
return;
 
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 78d5f02..a52e776 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include  /* for acpi_hest_init() */
+
 #include 
 
 #include "internal.h"
@@ -1912,6 +1914,7 @@ int __init acpi_scan_init(void)
 {
int result;
 
+   acpi_hest_init();
acpi_pci_root_init();
acpi_pci_link_init();
acpi_processor_init();
-- 
2.5.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 v3 2/5] drm/dsi: Try to match non-DT dsi devices

[Jani Nikula]

On Mon, 07 Dec 2015, Archit Taneja  wrote:
> Hi,
>
> On 11/30/2015 06:15 PM, kbuild test robot wrote:
>> Hi Archit,
>>
>> [auto build test ERROR on: v4.4-rc3]
>> [also build test ERROR on: next-20151127]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Archit-Taneja/drm-dsi-DSI-for-devices-with-different-control-bus/20151130-200725
>> config: x86_64-allyesdebian (attached as .config)
>> reproduce:
>>  # save the attached .config to linux build tree
>>  make ARCH=x86_64
>>
>> All errors (new ones prefixed by >>):
>>
>> drivers/gpu/drm/drm_mipi_dsi.c: In function 'of_mipi_dsi_device_add':
 drivers/gpu/drm/drm_mipi_dsi.c:168:6: error: implicit declaration of 
 function 'of_modalias_node' [-Werror=implicit-function-declaration]
>>   if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
>
> Any suggestions on how to fix this? Is it ok to make DRM_MIPI_DSI
> depend on CONFIG_OF?

Please don't.

BR,
Jani.

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

Re: [PATCH v2 3/9] Documentation: dt-bindings: leds: add LM3633 LED binding information

[Kim, Milo]

Hi Jacek,

On 11/30/2015 9:26 PM, Jacek Anaszewski wrote:

In case of LM3633 the real current outputs are banks and multiplexing
that occurs between banks and LVLEDn pins can be conveniently expressed
with the bindings I proposed above.


>If three output channels are controlled by one control bank, then it
>should be represented as below.
>
>lvled-group-A {
>  led-sources = <0>, <1>, <2>;
>  led-max-microamp = ;
>}
>
>Please let me know if I misunderstand.

You silently assumed some definition of a "channel". led-sources means
in fact current sources, and when device is configured so that three
output pins are routed to the same current source, then in fact
they share common current source.


Thanks for comments. I've modified 'led-sources' based on your feedback.
Could you check updated dt-bindings below?

* Updates
- led-sources: List of current sources from 0 to 5.
- ti,led-outputs: Output channel specifier

The 'ti,led-outputs' property is exactly matched with datasheet 
description, so it's easy to understand which current source is used for 
output channels.

---
TI LMU LM3633 LED device tree bindings

Required properties:
  - compatible: "ti,lm3633-leds"

Child nodes:
  Each node matches with LED control bank.
  Please refer to the datasheet [1].

  Required properties of a child node:
  - led-sources: List of current sources from 0 to 5.
 0: control bank C for output LED 1
control bank C for output LED 1 and 2
control bank C for output LED 1, 2 and 3
 1: control bank D for output LED 2
 2: control bank E for output LED 3
 3: control bank F for output LED 4
control bank F for output LED 4 and 5
control bank F for output LED 4, 5 and 6
 4: control bank G for output LED 5
 5: control bank H for output LED 6
 Please refer to LED binding [2].

  - ti,led-outputs: Output channel specifier from 0 to 5.
0: LED 1
1: LED 2
2: LED 3
3: LED 4
4: LED 5
5: LED 6

  Optional properties of a child node:
  - label: LED channel identification. Please refer to LED binding [2].
  - led-max-microamp: Max current setting. Type is .
  Unit is microampere. Range is from 5000 to 29800.
  Step is 800. Please refer to LED binding [2].

Examples:

LED 1 is assigned for status LED. LED 4,5 and 6 are used for RGB 
indicator. RGB channels are controlled by bank F internally.


leds {
compatible = "ti,lm3633-leds";

status {
led-sources = <0>;
led-max-microamp = <5000>;
ti,led-outputs = <0>;
};

rgb {
led-sources = <3>;
led-max-microamp = <6600>;
ti,led-outputs = <3 4 5>;
};
};

LED 2 is power LED. LED 5 is notification LED.

leds {
compatible = "ti,lm3633-leds";

lvled2 {
label = "power";
led-sources = <1>;
led-max-microamp = <29000>;
ti,led-outputs = <1>;
};

lvled5 {
label = "noti";
led-sources = <4>;
led-max-microamp = <6600>;
ti,led-outputs = <4>;
};
};


[1] http://www.ti.com/product/LM3633/datasheet
[2] ../leds/common.txt

Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/13] perf tools: Move perf subcommand framework into lib/tools

[Jiri Olsa]

On Sun, Dec 06, 2015 at 02:02:42PM -0600, Josh Poimboeuf wrote:
> On Sun, Dec 06, 2015 at 04:50:06PM +0100, Jiri Olsa wrote:
> > On Sun, Dec 06, 2015 at 10:37:52AM +0100, Ingo Molnar wrote:
> > > 
> > > * Josh Poimboeuf  wrote:
> > > 
> > > > Ingo suggested that I factor out the perf subcommand functionality
> > > > (originally copied from git) into tools/lib so that it can be used by
> > > > stacktool[*] and possibly others.
> > > > 
> > > > All the subcommand option handling files have been moved into libapi,
> > > > including parse-options.c, run-command.c, exec_cmd.c, help.c, usage.c,
> > > > and their dependencies.  Since several of the dependencies are more
> > > > general-purpose "utilities" which aren't directly related to
> > > > subcommands, I put everything in 'tools/lib/api/util'.  They're linked
> > > > into perf as part of the libapi.a library.
> > > > 
> > > > Patches 1-10 do some cleanups and splitting up of the code in
> > > > preparation for the move.
> > > > 
> > > > Patch 11 does the actual moving of the files into tools/lib/api/util.
> > > > 
> > > > [*] https://lkml.kernel.org/r/cover.1445443144.git.jpoim...@redhat.com
> > > > 
> > > > Josh Poimboeuf (13):
> > > >   perf: Use -iquote for local include paths
> > > >   perf: Split up util.h
> > > >   perf: Move term functions out of util.c
> > > >   perf: Remove unused pager_use_color variable
> > > >   perf: Split up cache.h
> > > >   perf: Remove cache.h
> > > >   perf: Save cmdline arguments earlier
> > > >   perf: Remove check for unused PERF_PAGER_IN_USE
> > > >   perf: Move cmd_version() to builtin-version.c
> > > >   perf: Move help_unknown_cmd() to its own file
> > > >   perf tools: Move strlcpy() to tools/lib/string.c
> > > >   perf tools: Move perf subcommand framework into a library
> > > >   perf tools: Move subcommand framework and related utils to libapi
> > > 
> > > >  133 files changed, 852 insertions(+), 761 deletions(-)
> > > 
> > > So this split-out looks great to me!
> > > 
> > > A bit of a background: this series is a necessary precondition of me 
> > > being able to 
> > > merge 'stacktool' and the frame pointer handling enhancements Josh is 
> > > working on - 
> > > but it would be nice if this could all be done via Arnaldo's perf tree to 
> > > minimize 
> > > any impact on pending perf work.
> > > 
> > > I've Cc:-ed Namhyung and Jiri as well, who've done a lot of work in 
> > > perf/util/.
> > > 
> > 
> > heya,
> > got compilation error over this patchset:
> > 
> > [jolsa@krava perf]$ make clean && make JOBS=1
> > 
> >   ...
> > 
> >   CC   tests/llvm-src-base.o
> > tests/llvm-src-base.c:1:24: fatal error: tests/llvm.h: No such file or 
> > directory
> > compilation terminated.
> > mv: cannot stat ‘tests/.llvm-src-base.o.tmp’: No such file or directory
> > /home/jolsa/kernel/linux-perf/tools/build/Makefile.build:77: recipe for 
> > target 'tests/llvm-src-base.o' failed
> > make[3]: *** [tests/llvm-src-base.o] Error 1
> > /home/jolsa/kernel/linux-perf/tools/build/Makefile.build:116: recipe for 
> > target 'tests' failed
> > make[2]: *** [tests] Error 2
> > Makefile.perf:313: recipe for target 'perf-in.o' failed
> > make[1]: *** [perf-in.o] Error 2
> > Makefile:68: recipe for target 'all' failed
> > make: *** [all] Error 2
> 
> I think the problem is that you have a stale version of the
> auto-generated file llvm-src-base.c.  Looks like "make clean" doesn't
> remove it.  I'll add a patch to fix it.

FYI I switched back to Arnaldo's perf/core and did 'make clean && make'
which passed, then switched back to your change and build failed again

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] infiniband:core:Add needed error path in cm_init_av_by_path

[Michael Wang]

On 12/07/2015 08:57 AM, Haggai Eran wrote:
> On Friday, December 4, 2015 8:02 PM, Nicholas Krause  
> wrote:
>> To: dledf...@redhat.com
>> Cc: sean.he...@intel.com; hal.rosenst...@gmail.com; Haggai Eran; 
>> jguntho...@obsidianresearch.com; Matan Barak; yun.w...@profitbricks.com; 
>> ted.h@oracle.com; Doron Tsur; Erez Shitrit; david.ah...@oracle.com; 
>> linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: [PATCH] infiniband:core:Add needed error path in cm_init_av_by_path
>>
>> This adds a needed error path in the function, cm_init_av_by_path
>> after the call to ib_init_ah_from_path in order to avoid incorrectly
>> accessing the path pointer of structure type ib_sa_path_rec if this
>> function call fails to complete its intended work successfully by
>> returning a error code.
>>
>> Signed-off-by: Nicholas Krause 
> 
> The subject doesn't seem to match the convention but apart from that,
> 
> Reviewed-by: Haggai Eran 
> 
> I wonder if this should go to stable. If I understand correctly, this will 
> fail only when the SGID isn't found in the GID table, but such connections 
> would fail later on when creating a QP, right?

Me too think this need a reconsider, to me the current logical don't
really care the missing gid in cache when initializing AV, I'm not
sure if it's necessary to fail all the following path for such cache
missing...

Regards,
Michael Wang

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

[PATCH 0/4] [RFC] cpumask: Robustify the var-cpumask allocation APIs

[Ingo Molnar]

Hi Rusty,

this is the cpumask API robustification change we talked about in this
lkml thread:

  [PATCH] sched/core: Clear the root_domain cpumasks in init_rootdomain()

The idea is to first migrate all users of alloc_cpumask_var() to
zalloc_cpumask_var(), then remove the old API.

We still keep __alloc_cpumask_var_node(), for users who absolutely want
to micro-manage their cpumask allocations.

I also addressed a related naming ambiguity in alloc_bootmem_cpumask_var().

Lightly tested.

( If you like this series I can merge it via -tip, or you can pick it up,
  your call! )

Thanks,

Ingo

>


Ingo Molnar (4):
  cpumask: Migrate 'alloc_cpumask_var()' users to 'zalloc_cpumask_var()'
  cpumask: Remove 'alloc_cpumask_var()'
  cpumask: Rename 'alloc_bootmem_cpumask_var()' to 
'zalloc_bootmem_cpumask_var()'
  cpumask: Rename 'alloc_cpumask_var_node()' to '__alloc_cpumask_var_node()'

 arch/ia64/kernel/smp.c  |  2 +-
 arch/mips/kernel/mips-mt-fpaff.c|  6 +++---
 arch/powerpc/kernel/irq.c   |  2 +-
 arch/powerpc/kernel/rtas.c  |  4 ++--
 arch/powerpc/kernel/smp.c   |  2 +-
 arch/powerpc/mm/numa.c  |  2 +-
 arch/powerpc/platforms/powernv/subcore.c|  2 +-
 arch/powerpc/platforms/pseries/smp.c|  2 +-
 arch/powerpc/platforms/pseries/suspend.c|  2 +-
 arch/x86/kernel/apic/vector.c   |  4 ++--
 arch/x86/kernel/cpu/common.c|  8 +++
 arch/x86/kernel/cpu/mcheck/mce-inject.c |  2 +-
 arch/x86/kernel/smp.c   |  2 +-
 arch/x86/mm/mmio-mod.c  |  2 +-
 arch/x86/mm/numa.c  |  2 +-
 arch/x86/platform/uv/uv_nmi.c   |  2 +-
 arch/x86/xen/mmu.c  |  2 +-
 arch/x86/xen/smp.c  |  2 +-
 block/blk-mq-cpumap.c   |  2 +-
 crypto/pcrypt.c |  4 ++--
 drivers/acpi/acpi_pad.c |  2 +-
 drivers/acpi/processor_throttling.c |  2 +-
 drivers/base/cpu.c  |  2 +-
 drivers/cpufreq/cpufreq.c   |  2 +-
 drivers/crypto/n2_core.c|  2 +-
 drivers/firmware/dcdbas.c   |  2 +-
 drivers/hwmon/dell-smm-hwmon.c  |  2 +-
 drivers/net/ethernet/intel/i40e/i40e_main.c |  2 +-
 drivers/pci/host/pci-xgene-msi.c|  2 +-
 drivers/scsi/mpt3sas/mpt3sas_base.c |  2 +-
 drivers/virtio/virtio_pci_common.c  |  2 +-
 include/linux/cpumask.h | 20 ++---
 kernel/compat.c |  4 ++--
 kernel/cpu.c|  2 +-
 kernel/cpuset.c | 16 +++---
 kernel/irq/irqdesc.c|  2 +-
 kernel/irq/manage.c |  6 +++---
 kernel/irq/proc.c   |  4 ++--
 kernel/padata.c | 10 -
 kernel/profile.c|  4 ++--
 kernel/rcu/tree_plugin.h|  2 +-
 kernel/sched/core.c | 16 +++---
 kernel/smpboot.c|  4 ++--
 kernel/taskstats.c  |  4 ++--
 kernel/time/tick-sched.c|  6 +++---
 kernel/torture.c|  2 +-
 kernel/trace/ring_buffer.c  |  2 +-
 kernel/trace/trace.c| 10 -
 kernel/workqueue.c  |  4 ++--
 lib/cpumask.c   | 33 ++---
 mm/vmstat.c |  2 +-
 net/core/flow.c |  2 +-
 net/core/net-sysfs.c|  4 ++--
 net/core/sysctl_net_core.c  |  2 +-
 54 files changed, 116 insertions(+), 123 deletions(-)

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

[PATCH 4/4] cpumask: Rename 'alloc_cpumask_var_node()' to '__alloc_cpumask_var_node()'

[Ingo Molnar]

Add a double underscore to this API, to make it very clear that this is an
internal API with unusual semantics: for example on !CPUMASK_OFFSTACK
kernels it will result in initialized cpumasks, while on CPUMASK_OFFSTACK
kernels it will allocate a var-cpumask that is not initialized. The
caller has to make sure this initialization happens.

Also add this information to the documentation of the API.

Signed-off-by: Ingo Molnar 
---
 include/linux/cpumask.h |  4 ++--
 lib/cpumask.c   | 16 ++--
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 719fecaa64e4..7ed1e1f8e806 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -653,7 +653,7 @@ typedef struct cpumask *cpumask_var_t;
 
 #define this_cpu_cpumask_var_ptr(x) this_cpu_read(x)
 
-bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node);
+bool __alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node);
 bool zalloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node);
 bool zalloc_cpumask_var(cpumask_var_t *mask, gfp_t flags);
 void zalloc_bootmem_cpumask_var(cpumask_var_t *mask);
@@ -665,7 +665,7 @@ typedef struct cpumask cpumask_var_t[1];
 
 #define this_cpu_cpumask_var_ptr(x) this_cpu_ptr(x)
 
-static inline bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags,
+static inline bool __alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags,
  int node)
 {
return true;
diff --git a/lib/cpumask.c b/lib/cpumask.c
index cb9b80284274..c291d993fb9c 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -45,7 +45,7 @@ int cpumask_any_but(const struct cpumask *mask, unsigned int 
cpu)
 /* These are not inline because of header tangles. */
 #ifdef CONFIG_CPUMASK_OFFSTACK
 /**
- * alloc_cpumask_var_node - allocate a struct cpumask on a given node
+ * __alloc_cpumask_var_node - allocate a struct cpumask on a given node
  * @mask: pointer to cpumask_var_t where the cpumask is returned
  * @flags: GFP_ flags
  *
@@ -57,8 +57,12 @@ int cpumask_any_but(const struct cpumask *mask, unsigned int 
cpu)
  * usually smart enough to know that mask can never be NULL if
  * CONFIG_CPUMASK_OFFSTACK=n, so does code elimination in that case
  * too.
+ *
+ * ( Also note that the freshly allocated mask will not be zero
+ *   initialized - in contrast to !CONFIG_CPUMASK_OFFSTACK kernels
+ *   which typically pass in masks that are already initialized. )
  */
-bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node)
+bool __alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node)
 {
*mask = kmalloc_node(cpumask_size(), flags, node);
 
@@ -71,11 +75,11 @@ bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t 
flags, int node)
 
return *mask != NULL;
 }
-EXPORT_SYMBOL(alloc_cpumask_var_node);
+EXPORT_SYMBOL(__alloc_cpumask_var_node);
 
 bool zalloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node)
 {
-   return alloc_cpumask_var_node(mask, flags | __GFP_ZERO, node);
+   return __alloc_cpumask_var_node(mask, flags | __GFP_ZERO, node);
 }
 EXPORT_SYMBOL(zalloc_cpumask_var_node);
 
@@ -88,11 +92,11 @@ EXPORT_SYMBOL(zalloc_cpumask_var_node);
  * a nop returning a constant 1 (in ).
  * The cpumask is initialized to all zeroes.
  *
- * See alloc_cpumask_var_node().
+ * See __alloc_cpumask_var_node().
  */
 bool zalloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
 {
-   return alloc_cpumask_var_node(mask, flags | __GFP_ZERO, NUMA_NO_NODE);
+   return __alloc_cpumask_var_node(mask, flags | __GFP_ZERO, NUMA_NO_NODE);
 }
 EXPORT_SYMBOL(zalloc_cpumask_var);
 
-- 
2.5.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/

[PATCH 3/4] cpumask: Rename 'alloc_bootmem_cpumask_var()' to 'zalloc_bootmem_cpumask_var()'

[Ingo Molnar]

This API is somewhat confusingly named 'alloc', despite returning zeroed
cpumasks. Rename it to 'zalloc' to be in line with usual terminology.

Bootmem allocations are always zero initialized.

(Also fix a typo in a comment of this API while at it.)

Signed-off-by: Ingo Molnar 
---
 arch/powerpc/mm/numa.c   | 2 +-
 arch/powerpc/platforms/pseries/smp.c | 2 +-
 arch/x86/kernel/cpu/common.c | 8 
 arch/x86/mm/numa.c   | 2 +-
 include/linux/cpumask.h  | 4 ++--
 kernel/rcu/tree_plugin.h | 2 +-
 kernel/sched/core.c  | 2 +-
 kernel/time/tick-sched.c | 2 +-
 lib/cpumask.c| 6 +++---
 9 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 669a15e7fa76..762f7ea55e78 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -81,7 +81,7 @@ static void __init setup_node_to_cpumask_map(void)
 
/* allocate the map */
for_each_node(node)
-   alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
+   zalloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
 
/* cpumask_of_node() will now work */
dbg("Node to cpumask map for %d nodes\n", nr_node_ids);
diff --git a/arch/powerpc/platforms/pseries/smp.c 
b/arch/powerpc/platforms/pseries/smp.c
index 6932ea803e33..f22944b8033b 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -230,7 +230,7 @@ static void __init smp_init_pseries(void)
 
pr_debug(" -> smp_init_pSeries()\n");
 
-   alloc_bootmem_cpumask_var(&of_spin_mask);
+   zalloc_bootmem_cpumask_var(&of_spin_mask);
 
/*
 * Mark threads which are still spinning in hold loops
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 105da8df87ae..a9f43c4d9c28 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -61,10 +61,10 @@ cpumask_var_t cpu_sibling_setup_mask;
 /* correctly size the local cpu masks */
 void __init setup_cpu_local_masks(void)
 {
-   alloc_bootmem_cpumask_var(&cpu_initialized_mask);
-   alloc_bootmem_cpumask_var(&cpu_callin_mask);
-   alloc_bootmem_cpumask_var(&cpu_callout_mask);
-   alloc_bootmem_cpumask_var(&cpu_sibling_setup_mask);
+   zalloc_bootmem_cpumask_var(&cpu_initialized_mask);
+   zalloc_bootmem_cpumask_var(&cpu_callin_mask);
+   zalloc_bootmem_cpumask_var(&cpu_callout_mask);
+   zalloc_bootmem_cpumask_var(&cpu_sibling_setup_mask);
 }
 
 static void default_init(struct cpuinfo_x86 *c)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index c3b3f653ed0c..8f2875f4b854 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -122,7 +122,7 @@ void __init setup_node_to_cpumask_map(void)
 
/* allocate the map */
for (node = 0; node < nr_node_ids; node++)
-   alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
+   zalloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
 
/* cpumask_of_node() will now work */
pr_debug("Node to cpumask map for %d nodes\n", nr_node_ids);
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 0d24286fe8f8..719fecaa64e4 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -656,7 +656,7 @@ typedef struct cpumask *cpumask_var_t;
 bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node);
 bool zalloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node);
 bool zalloc_cpumask_var(cpumask_var_t *mask, gfp_t flags);
-void alloc_bootmem_cpumask_var(cpumask_var_t *mask);
+void zalloc_bootmem_cpumask_var(cpumask_var_t *mask);
 void free_cpumask_var(cpumask_var_t mask);
 void free_bootmem_cpumask_var(cpumask_var_t mask);
 
@@ -684,7 +684,7 @@ static inline bool zalloc_cpumask_var_node(cpumask_var_t 
*mask, gfp_t flags,
return true;
 }
 
-static inline void alloc_bootmem_cpumask_var(cpumask_var_t *mask)
+static inline void zalloc_bootmem_cpumask_var(cpumask_var_t *mask)
 {
 }
 
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 630c19772630..2fc158fa07a1 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1804,7 +1804,7 @@ static void increment_cpu_stall_ticks(void)
 /* Parse the boot-time rcu_nocb_mask CPU list from the kernel parameters. */
 static int __init rcu_nocb_setup(char *str)
 {
-   alloc_bootmem_cpumask_var(&rcu_nocb_mask);
+   zalloc_bootmem_cpumask_var(&rcu_nocb_mask);
have_rcu_nocb_mask = true;
cpulist_parse(str, rcu_nocb_mask);
return 1;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index aa7f8e965386..d57eeb6df663 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6171,7 +6171,7 @@ cpu_attach_domain(struct sched_domain *sd, struct 
root_domain *rd, int cpu)
 /* Setup the mask of cpus configured for isolated domains */
 static int __init isolated_cpu_setup(ch

[PATCH 2/4] cpumask: Remove 'alloc_cpumask_var()'

[Ingo Molnar]

This API is unused and slightly unrobust: on non-CPUMASK_OFFSTACK
kernels it will result in initialized cpumasks - while on
CPUMASK_OFFSTACK kernels it results in initialized cpumasks,
enabling hard to find initialization bugs.

Be conservative and default to zeroing. Users of this facility that
really want to allocate their cpumasks without initializing them can
still use alloc_cpumask_var_node() to do so.

Signed-off-by: Ingo Molnar 
---
 include/linux/cpumask.h |  6 --
 lib/cpumask.c   | 13 -
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 608beca04fc6..0d24286fe8f8 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -654,7 +654,6 @@ typedef struct cpumask *cpumask_var_t;
 #define this_cpu_cpumask_var_ptr(x) this_cpu_read(x)
 
 bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node);
-bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags);
 bool zalloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node);
 bool zalloc_cpumask_var(cpumask_var_t *mask, gfp_t flags);
 void alloc_bootmem_cpumask_var(cpumask_var_t *mask);
@@ -666,11 +665,6 @@ typedef struct cpumask cpumask_var_t[1];
 
 #define this_cpu_cpumask_var_ptr(x) this_cpu_ptr(x)
 
-static inline bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
-{
-   return true;
-}
-
 static inline bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags,
  int node)
 {
diff --git a/lib/cpumask.c b/lib/cpumask.c
index 7f93df07bce7..415041e9cda6 100644
--- a/lib/cpumask.c
+++ b/lib/cpumask.c
@@ -80,24 +80,19 @@ bool zalloc_cpumask_var_node(cpumask_var_t *mask, gfp_t 
flags, int node)
 EXPORT_SYMBOL(zalloc_cpumask_var_node);
 
 /**
- * alloc_cpumask_var - allocate a struct cpumask
+ * zalloc_cpumask_var - allocate a struct cpumask
  * @mask: pointer to cpumask_var_t where the cpumask is returned
  * @flags: GFP_ flags
  *
  * Only defined when CONFIG_CPUMASK_OFFSTACK=y, otherwise is
  * a nop returning a constant 1 (in ).
+ * The cpumask is initialized to all zeroes.
  *
- * See alloc_cpumask_var_node.
+ * See alloc_cpumask_var_node().
  */
-bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
-{
-   return alloc_cpumask_var_node(mask, flags, NUMA_NO_NODE);
-}
-EXPORT_SYMBOL(alloc_cpumask_var);
-
 bool zalloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
 {
-   return alloc_cpumask_var(mask, flags | __GFP_ZERO);
+   return alloc_cpumask_var_node(mask, flags | __GFP_ZERO, NUMA_NO_NODE);
 }
 EXPORT_SYMBOL(zalloc_cpumask_var);
 
-- 
2.5.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/

[PATCH 1/4] cpumask: Migrate 'alloc_cpumask_var()' users to 'zalloc_cpumask_var()'

[Ingo Molnar]

Xunlei Pang reported a scheduler bug in init_rootdomain(), which is
caused by improper use of alloc_cpumask_var(), which results in
uninitialized cpumasks being allocated.

No-one noticed this scheduler bug for a long time, probably because
alloc_cpumask_var() does result in initialized cpumasks in the
!CPUMASK_OFFSTACK case - which is the vast majority of systems
out there.

So migrate all alloc_cpumask_var() users over to zalloc_cpumask_var(),
to be on the safe side.

Reported-by: Xunlei Pang 
Signed-off-by: Ingo Molnar 
---
 arch/ia64/kernel/smp.c  |  2 +-
 arch/mips/kernel/mips-mt-fpaff.c|  6 +++---
 arch/powerpc/kernel/irq.c   |  2 +-
 arch/powerpc/kernel/rtas.c  |  4 ++--
 arch/powerpc/kernel/smp.c   |  2 +-
 arch/powerpc/platforms/powernv/subcore.c|  2 +-
 arch/powerpc/platforms/pseries/suspend.c|  2 +-
 arch/x86/kernel/apic/vector.c   |  4 ++--
 arch/x86/kernel/cpu/mcheck/mce-inject.c |  2 +-
 arch/x86/kernel/smp.c   |  2 +-
 arch/x86/mm/mmio-mod.c  |  2 +-
 arch/x86/platform/uv/uv_nmi.c   |  2 +-
 arch/x86/xen/mmu.c  |  2 +-
 arch/x86/xen/smp.c  |  2 +-
 block/blk-mq-cpumap.c   |  2 +-
 crypto/pcrypt.c |  4 ++--
 drivers/acpi/acpi_pad.c |  2 +-
 drivers/acpi/processor_throttling.c |  2 +-
 drivers/base/cpu.c  |  2 +-
 drivers/cpufreq/cpufreq.c   |  2 +-
 drivers/crypto/n2_core.c|  2 +-
 drivers/firmware/dcdbas.c   |  2 +-
 drivers/hwmon/dell-smm-hwmon.c  |  2 +-
 drivers/net/ethernet/intel/i40e/i40e_main.c |  2 +-
 drivers/pci/host/pci-xgene-msi.c|  2 +-
 drivers/scsi/mpt3sas/mpt3sas_base.c |  2 +-
 drivers/virtio/virtio_pci_common.c  |  2 +-
 include/linux/cpumask.h |  6 +++---
 kernel/compat.c |  4 ++--
 kernel/cpu.c|  2 +-
 kernel/cpuset.c | 16 
 kernel/irq/irqdesc.c|  2 +-
 kernel/irq/manage.c |  6 +++---
 kernel/irq/proc.c   |  4 ++--
 kernel/padata.c | 10 +-
 kernel/profile.c|  4 ++--
 kernel/sched/core.c | 14 +++---
 kernel/smpboot.c|  4 ++--
 kernel/taskstats.c  |  4 ++--
 kernel/time/tick-sched.c|  4 ++--
 kernel/torture.c|  2 +-
 kernel/trace/ring_buffer.c  |  2 +-
 kernel/trace/trace.c| 10 +-
 kernel/workqueue.c  |  4 ++--
 lib/cpumask.c   |  2 +-
 mm/vmstat.c |  2 +-
 net/core/flow.c |  2 +-
 net/core/net-sysfs.c|  4 ++--
 net/core/sysctl_net_core.c  |  2 +-
 49 files changed, 87 insertions(+), 87 deletions(-)

diff --git a/arch/ia64/kernel/smp.c b/arch/ia64/kernel/smp.c
index 7f706d4f84f7..d52b4d8de013 100644
--- a/arch/ia64/kernel/smp.c
+++ b/arch/ia64/kernel/smp.c
@@ -301,7 +301,7 @@ smp_flush_tlb_mm (struct mm_struct *mm)
preempt_enable();
return;
}
-   if (!alloc_cpumask_var(&cpus, GFP_ATOMIC)) {
+   if (!zalloc_cpumask_var(&cpus, GFP_ATOMIC)) {
smp_call_function((void (*)(void *))local_finish_flush_tlb_mm,
mm, 1);
} else {
diff --git a/arch/mips/kernel/mips-mt-fpaff.c b/arch/mips/kernel/mips-mt-fpaff.c
index 789d7bf4fef3..9b8241da4c4c 100644
--- a/arch/mips/kernel/mips-mt-fpaff.c
+++ b/arch/mips/kernel/mips-mt-fpaff.c
@@ -87,15 +87,15 @@ asmlinkage long mipsmt_sys_sched_setaffinity(pid_t pid, 
unsigned int len,
get_task_struct(p);
rcu_read_unlock();
 
-   if (!alloc_cpumask_var(&cpus_allowed, GFP_KERNEL)) {
+   if (!zalloc_cpumask_var(&cpus_allowed, GFP_KERNEL)) {
retval = -ENOMEM;
goto out_put_task;
}
-   if (!alloc_cpumask_var(&new_mask, GFP_KERNEL)) {
+   if (!zalloc_cpumask_var(&new_mask, GFP_KERNEL)) {
retval = -ENOMEM;
goto out_free_cpus_allowed;
}
-   if (!alloc_cpumask_var(&effective_mask, GFP_KERNEL)) {
+   if (!zalloc_cpumask_var(&effective_mask, GFP_KERNEL)) {
retval = -ENOMEM;
goto out_free_new_mask;
}
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 290559df1e8b..48558d1ae075 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -429,7 +429,7 @@ void migrate_irqs(void)
cpumask_var_t mask;
   

[PATCH] perf tools: Clear struct machine during machine__init()

[Wang Nan]

There are so many test cases use stack allocated 'struct machine'.
Including:
  test__hists_link
  test__hists_filter
  test__mmap_thread_lookup
  test__thread_mg_share
  test__hists_output
  test__hists_cumulate

Also, in non-test code (for example, machine__new_host()) there are
code use 'malloc()' to alloc struct machine.

These are dangerous operations, cause some tests fail or hung in
machines__exit(). For example, in

 machines__exit ->
   machine__destroy_kernel_maps ->
 map_groups__remove ->
   maps__remove ->
 pthread_rwlock_wrlock

a incorrectly initialized lock causes unintended behavior.

This patch bzero() that structure in machine__init() to ensure all
fields in 'struct machine' are initialized to zero.

Signed-off-by: Wang Nan 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
---
 tools/perf/util/machine.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index bfc289c..188cfdf 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -25,6 +25,7 @@ static void dsos__init(struct dsos *dsos)
 
 int machine__init(struct machine *machine, const char *root_dir, pid_t pid)
 {
+   bzero(machine, sizeof(*machine));
map_groups__init(&machine->kmaps, machine);
RB_CLEAR_NODE(&machine->rb_node);
dsos__init(&machine->dsos);
-- 
1.8.3.4

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

Re: [PATCH V3 2/6] acpi: pci: Setup MSI domain for ACPI based pci devices

[Marc Zyngier]

Hi Tomasz,

On 06/12/15 18:03, Tomasz Nowicki wrote:
> Hi Marc,
> 
> 
> On 11/22/2015 12:35 PM, Marc Zyngier wrote:
>> On Sat, 21 Nov 2015 15:18:45 -0600
>> Suravee Suthikulpanit  wrote:
>>
>>> Hi Marc,
>>>
>>> On 11/19/15 06:08, Marc Zyngier wrote:
 On Wed, 21 Oct 2015 11:47:25 -0700
 Suravee Suthikulpanit  wrote:

 Hi Suravee,

 Sorry it took so long to get to this series. Comments below.
>>> No worry.
>>>
> This patch introduces pci_host_bridge_acpi_msi_domain(), which returns
> the MSI domain of the specified PCI host bridge with DOMAIN_BUS_PCI_MSI
> bus token. Then, it is assigned to pci device.
>
> Signed-off-by: Suravee Suthikulpanit 
> ---
>drivers/pci/pci-acpi.c | 13 +
>drivers/pci/probe.c|  2 ++
>include/linux/pci.h|  7 +++
>3 files changed, 22 insertions(+)
>
> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> index a32ba75..0e21ef4 100644
> --- a/drivers/pci/pci-acpi.c
> +++ b/drivers/pci/pci-acpi.c
> @@ -9,7 +9,9 @@
>
>#include 
>#include 
> +#include 
>#include 
> +#include 
>#include 
>#include 
>#include 
> @@ -689,6 +691,17 @@ static struct acpi_bus_type acpi_pci_bus = {
>   .cleanup = pci_acpi_cleanup,
>};
>
> +struct irq_domain *pci_host_bridge_acpi_msi_domain(struct pci_bus *bus)
> +{
> + struct irq_domain *dom = NULL;
> + struct fwnode_handle *fwnode = pci_msi_get_fwnode(&bus->dev);
> +
> + if (fwnode)
> + dom = irq_find_matching_fwnode(fwnode,
> +DOMAIN_BUS_PCI_MSI);
> + return dom;
> +}
> +
 Given this, I really question the need for what you define in patch #1
 to be standalone. It is only used by ACPI (DT has its own private
 helpers), and it is so far unlikely that it will be of any use for
 other firmware interfaces.

 My suggestion is to get rid of pci_msi_get_fwnode() and move the
 registration helper into this file. That'd be much simpler.

 Thanks,

M.

>>> Ok, I'll take care of this. I assume the rest of the patches looks ok.
>> I still need to finish going through it (I have minor comments so far
>> on some of the other patches), but I want to get the core ACPI stuff in
>> shape before doing anything else.
> I am trying to do similar thing for GICv3 & ITS, can you please have a look:
> http://lkml.iu.edu/hypermail/linux/kernel/1510.1/06139.html
> 
> Can you please explain what ACPI core changes do you mean?

I mean the code in patches 1 and 2 in Suravee's series. This should form
the basics for being able to assign MSI domains to devices.

Thanks,

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

radeon -Wmaybe-uninitialized crap

[Borislav Petkov]

Hi guys,

this just started appearing when building -rc4. Got fixes yet? :-)

In file included from drivers/gpu/drm/radeon/radeon_mode.h:37:0,
 from drivers/gpu/drm/radeon/radeon.h:80,
 from drivers/gpu/drm/radeon/r100.c:33:
drivers/gpu/drm/radeon/r100.c: In function ‘r100_bandwidth_update’:
include/drm/drm_fixed.h:64:13: warning: ‘crit_point_ff.full’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
  u64 tmp = ((u64)A.full << 13);
 ^
drivers/gpu/drm/radeon/r100.c:3153:63: note: ‘crit_point_ff.full’ was declared 
here
  fixed20_12 peak_disp_bw, mem_bw, pix_clk, pix_clk2, temp_ff, crit_point_ff;
   ^
drivers/gpu/drm/radeon/r100.c:3583:42: warning: ‘disp_drain_rate.full’ may be 
used uninitialized in this function [-Wmaybe-uninitialized]
 temp_ff.full = read_return_rate.full - disp_drain_rate.full;
  ^
-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tools build: Introduce features dump include makefile

[Jiri Olsa]

ping, Wang Nan, any comments on these 2?

thanks,
jirka

On Fri, Nov 27, 2015 at 10:06:50AM +0100, Jiri Olsa wrote:
> Creating the FEATURE-INCLUDE file, that contains all features
> status dumped in make's variable format:
>...
>feature-backtrace=1
>feature-dwarf=1
>...
> 
> It's purpose is to be included in sub-project makefiles to get
> features detection state. This way we can run the detection only
> in top level project and propagate it down.
> 
> Cc: Wang Nan 
> Link: http://lkml.kernel.org/n/tip-fcq5rtdhcu4300sjp2p8l...@git.kernel.org
> Signed-off-by: Jiri Olsa 
> ---
>  tools/build/Makefile.feature | 12 
>  tools/lib/bpf/.gitignore |  1 +
>  tools/lib/bpf/Makefile   |  2 +-
>  tools/perf/.gitignore|  1 +
>  tools/perf/Makefile.perf |  2 +-
>  5 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
> index 37ff4c9f92f1..51f8d5928f98 100644
> --- a/tools/build/Makefile.feature
> +++ b/tools/build/Makefile.feature
> @@ -131,6 +131,16 @@ ifeq ($(dwarf-post-unwind),1)
>FEATURE_DUMP += dwarf-post-unwind($(dwarf-post-unwind-text))
>  endif
>  
> +# The FEATURE-INCLUDE file contains all features status
> +# dumped in make's variable format:
> +#   ...
> +#   feature-backtrace=1
> +#   feature-dwarf=1
> +#   ...
> +# It's to be included in sub-project makefiles to get
> +# features detection state.
> +FEATURE_INCLUDE_FILENAME = $(OUTPUT)FEATURE-INCLUDE$(FEATURE_USER)
> +
>  # The $(feature_display) controls the default detection message
>  # output. It's set if:
>  # - detected features differes from stored features from
> @@ -140,6 +150,8 @@ endif
>  
>  ifneq ("$(FEATURE_DUMP)","$(FEATURE_DUMP_FILE)")
>$(shell echo "$(FEATURE_DUMP)" > $(FEATURE_DUMP_FILENAME))
> +  $(shell rm -f $(FEATURE_INCLUDE_FILENAME))
> +  $(foreach feat,$(FEATURE_TESTS),$(shell echo 
> "feature-$(feat)=$(feature-$(feat))" >> $(FEATURE_INCLUDE_FILENAME)))
>feature_display := 1
>  endif
>  
> diff --git a/tools/lib/bpf/.gitignore b/tools/lib/bpf/.gitignore
> index f81e549ddfdb..4019b8e4021a 100644
> --- a/tools/lib/bpf/.gitignore
> +++ b/tools/lib/bpf/.gitignore
> @@ -1,2 +1,3 @@
>  libbpf_version.h
>  FEATURE-DUMP.libbpf
> +FEATURE-INCLUDE.libbpf
> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> index 636e3ddb93a1..6916cbe962a5 100644
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile
> @@ -190,7 +190,7 @@ config-clean:
>  clean:
>   $(call QUIET_CLEAN, libbpf) $(RM) *.o *~ $(TARGETS) *.a *.so 
> $(VERSION_FILES) .*.d \
>   $(RM) LIBBPF-CFLAGS
> - $(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf
> + $(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf 
> $(OUTPUT)FEATURE-INCLUDE.libbpf
>  
>  
>  
> diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore
> index 3d1bb802dbf4..4a3eb8dedc54 100644
> --- a/tools/perf/.gitignore
> +++ b/tools/perf/.gitignore
> @@ -2,6 +2,7 @@ PERF-CFLAGS
>  PERF-GUI-VARS
>  PERF-VERSION-FILE
>  FEATURE-DUMP
> +FEATURE-INCLUDE
>  perf
>  perf-read-vdso32
>  perf-read-vdsox32
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 929a32ba15f5..b74f924185b7 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -589,7 +589,7 @@ clean: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean 
> $(LIBBPF)-clean config-clean
>   $(Q)find . -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name 
> '\.*.d' -delete
>   $(Q)$(RM) $(OUTPUT).config-detected
>   $(call QUIET_CLEAN, core-progs) $(RM) $(ALL_PROGRAMS) perf 
> perf-read-vdso32 perf-read-vdsox32
> - $(call QUIET_CLEAN, core-gen)   $(RM)  *.spec *.pyc *.pyo */*.pyc 
> */*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE 
> $(OUTPUT)FEATURE-DUMP $(OUTPUT)util/*-bison* $(OUTPUT)util/*-flex* \
> + $(call QUIET_CLEAN, core-gen)   $(RM)  *.spec *.pyc *.pyo */*.pyc 
> */*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE 
> $(OUTPUT)FEATURE-DUMP $(OUTPUT)FEATURE-INCLUDE $(OUTPUT)util/*-bison* 
> $(OUTPUT)util/*-flex* \
>   $(OUTPUT)util/intel-pt-decoder/inat-tables.c
>   $(QUIET_SUBDIR0)Documentation $(QUIET_SUBDIR1) clean
>   $(python-clean)
> -- 
> 2.4.3
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tpmdd-devel] [PATCH v2 0/3] tpm_tis: Clean up force module parameter

[Jarkko Sakkinen]

On Mon, Dec 07, 2015 at 09:06:50AM +0100, Wilck, Martin wrote:
> > > I'm a bit confused about the discussion because Martin replied that
> > > tpm_tis used to get the address range before applying this series.
> > > 
> > > And pnp_driver in the backend for TPM 1.x devices grabs the address
> > > range from DSDT.
> > 
> > You can completely ignore this question. I saw Martins reply with a fix for
> > "tpm_tis: Use devm_ioremap_resource" that you should squash into that
> > change. So it's proved that TPM ACPI device objects do not always have a
> > memory resource. Good.
> 
> Repeat, the memory resource DOES exist on my system. Not sure what proof
> you saw there.

Ok, lets go this through.

I deduced this from two facts:

* It used to have memory resource as conditional and as a fallback use
  fixed value.
* Your workaround reverted the situation to this.

Did I understand something incorrectly?

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

Re: [PATCH net-next] net: hns: optimize XGE capability by reducing cpu usage

[Du, Fan]

On 2015/12/5 15:32, yankejian wrote:

here is the patch raising the performance of XGE by:
1)changes the way page management method for enet momery, and
2)reduces the count of rmb, and
3)adds Memory prefetching


Any numbers on how much it boost performance?


Signed-off-by: yankejian 
---
  drivers/net/ethernet/hisilicon/hns/hnae.h |  5 +-
  drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c |  1 -
  drivers/net/ethernet/hisilicon/hns/hns_enet.c | 79 +++
  3 files changed, 55 insertions(+), 30 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h 
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index d1f3316..6ca94dc 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -341,7 +341,8 @@ struct hnae_queue {
void __iomem *io_base;
phys_addr_t phy_base;
struct hnae_ae_dev *dev;/* the device who use this queue */
-   struct hnae_ring rx_ring, tx_ring;
+   struct hnae_ring rx_ring cacheline_internodealigned_in_smp;
+   struct hnae_ring tx_ring cacheline_internodealigned_in_smp;
struct hnae_handle *handle;
  };

@@ -597,11 +598,9 @@ static inline void hnae_replace_buffer(struct hnae_ring 
*ring, int i,
   struct hnae_desc_cb *res_cb)
  {
struct hnae_buf_ops *bops = ring->q->handle->bops;
-   struct hnae_desc_cb tmp_cb = ring->desc_cb[i];

bops->unmap_buffer(ring, &ring->desc_cb[i]);
ring->desc_cb[i] = *res_cb;
-   *res_cb = tmp_cb;
ring->desc[i].addr = (__le64)ring->desc_cb[i].dma;
ring->desc[i].rx.ipoff_bnum_pid_flag = 0;
  }
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c 
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index 77c6edb..522b264 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -341,7 +341,6 @@ void hns_ae_toggle_ring_irq(struct hnae_ring *ring, u32 
mask)
else
flag = RCB_INT_FLAG_RX;

-   hns_rcb_int_clr_hw(ring->q, flag);
hns_rcb_int_ctrl_hw(ring->q, flag, mask);
  }

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c 
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index cad2663..e2be510 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -33,6 +33,7 @@

  #define RCB_IRQ_NOT_INITED 0
  #define RCB_IRQ_INITED 1
+#define HNS_BUFFER_SIZE_2048 2048

  #define BD_MAX_SEND_SIZE 8191
  #define SKB_TMP_LEN(SKB) \
@@ -491,13 +492,51 @@ static unsigned int hns_nic_get_headlen(unsigned char 
*data, u32 flag,
return max_size;
  }

-static void
-hns_nic_reuse_page(struct hnae_desc_cb *desc_cb, int tsize, int last_offset)
+static void hns_nic_reuse_page(struct sk_buff *skb, int i,
+  struct hnae_ring *ring, int pull_len,
+  struct hnae_desc_cb *desc_cb)
  {
+   struct hnae_desc *desc;
+   int truesize, size;
+   int last_offset = 0;
+
+   desc = &ring->desc[ring->next_to_clean];
+   size = le16_to_cpu(desc->rx.size);
+
+#if (PAGE_SIZE < 8192)
+   if (hnae_buf_size(ring) == HNS_BUFFER_SIZE_2048) {
+   truesize = hnae_buf_size(ring);
+   } else {
+   truesize = ALIGN(size, L1_CACHE_BYTES);
+   last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
+   }
+
+#else
+   truesize = ALIGN(size, L1_CACHE_BYTES);
+   last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
+#endif
+
+   skb_add_rx_frag(skb, i, desc_cb->priv, desc_cb->page_offset + pull_len,
+   size - pull_len, truesize - pull_len);
+
 /* avoid re-using remote pages,flag default unreuse */
if (likely(page_to_nid(desc_cb->priv) == numa_node_id())) {
+#if (PAGE_SIZE < 8192)
+   if (hnae_buf_size(ring) == HNS_BUFFER_SIZE_2048) {
+   /* if we are only owner of page we can reuse it */
+   if (likely(page_count(desc_cb->priv) == 1)) {
+   /* flip page offset to other buffer */
+   desc_cb->page_offset ^= truesize;
+
+   desc_cb->reuse_flag = 1;
+   /* bump ref count on page before it is given*/
+   get_page(desc_cb->priv);
+   }
+   return;
+   }
+#endif
/* move offset up to the next cache line */
-   desc_cb->page_offset += tsize;
+   desc_cb->page_offset += truesize;

if (desc_cb->page_offset <= last_offset) {
desc_cb->reuse_flag = 1;
@@ -529,11 +568,10 @@ static int hns_nic_poll_rx_skb(struct hns_nic_ring_data 
*ring_data,
struct hnae_desc *desc;
struct hnae_desc_cb *desc_cb;

Re: [PATCH resend 1/6] clk: sunxi: Add DRAM gates support for sun4i-a10

[Maxime Ripard]

On Sat, Dec 05, 2015 at 09:16:42PM +0800, Chen-Yu Tsai wrote:
> The A10/A20 share the same set of DRAM clock gates, which controls
> direct memory access for some peripherals.
> 
> On the A10, bit 15 controls the system's DRAM clock output (possibly
> to the DRAM chips), which we need to keep on.
> 
> On the A20 this has been moved to the DRAM controller, becoming a no-op.
> However it is still listed in the user manual, so add it anyway.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH net-next] net: hns: optimize XGE capability by reducing cpu usage

[Yankejian (Hackim Yim)]

On 2015/12/7 11:32, Joe Perches wrote:
> On Sun, 2015-12-06 at 22:29 -0500, David Miller wrote:
>> > From: yankejian 
>> > Date: Sat, 5 Dec 2015 15:32:29 +0800
>> > 
>>> > > +#if (PAGE_SIZE < 8192)
>>> > > + if (hnae_buf_size(ring) == HNS_BUFFER_SIZE_2048) {
>>> > > + truesize = hnae_buf_size(ring);
>>> > > + } else {
>>> > > + truesize = ALIGN(size, L1_CACHE_BYTES);
>>> > > + last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
>>> > > + }
>>> > > +
>>> > > +#else
>>> > > + truesize = ALIGN(size, L1_CACHE_BYTES);
>>> > > + last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
>>> > > +#endif
>> > 
>> > This is not indented properly, and it looks terrible.
> And it makes one curious as to why last_offset isn't set
> in the first block.

Hi Joe,
if hnae_buf_size que equal to HNS_BUFFER_SIZE, last_offset is useless in the 
routines of this function.
so it is ignored in the first block. thanks for your suggestion.

Best regards,
yankejian


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

Re: [PATCH v3 2/5] drm/dsi: Try to match non-DT dsi devices

[Archit Taneja]

On 12/07/2015 02:15 PM, Jani Nikula wrote:

On Mon, 07 Dec 2015, Archit Taneja  wrote:

Hi,

On 11/30/2015 06:15 PM, kbuild test robot wrote:

Hi Archit,

[auto build test ERROR on: v4.4-rc3]
[also build test ERROR on: next-20151127]

url:
https://github.com/0day-ci/linux/commits/Archit-Taneja/drm-dsi-DSI-for-devices-with-different-control-bus/20151130-200725
config: x86_64-allyesdebian (attached as .config)
reproduce:
  # save the attached .config to linux build tree
  make ARCH=x86_64

All errors (new ones prefixed by >>):

 drivers/gpu/drm/drm_mipi_dsi.c: In function 'of_mipi_dsi_device_add':

drivers/gpu/drm/drm_mipi_dsi.c:168:6: error: implicit declaration of function 
'of_modalias_node' [-Werror=implicit-function-declaration]

   if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {


Any suggestions on how to fix this? Is it ok to make DRM_MIPI_DSI
depend on CONFIG_OF?


Please don't.


Just curious, how did x86 use DSI if the only way to create DSI devices
until now was via DT?

Archit



BR,
Jani.



--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

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

Re: [PATCH resend 3/6] ARM: dts: sun4i: Add DRAM gates

[Maxime Ripard]

On Sat, Dec 05, 2015 at 09:16:44PM +0800, Chen-Yu Tsai wrote:
> The DRAM gates controls direct memory access for some peripherals.
> These peripherals include the display pipeline, so add the required
> gates to the simplefb nodes as well.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH net-next] net: hns: optimize XGE capability by reducing cpu usage

[Joe Perches]

On Mon, 2015-12-07 at 16:58 +0800, Yankejian (Hackim Yim) wrote:
> On 2015/12/7 11:32, Joe Perches wrote:
> > On Sun, 2015-12-06 at 22:29 -0500, David Miller wrote:
> > > > From: yankejian 
> > > > Date: Sat, 5 Dec 2015 15:32:29 +0800
> > > > 
> > > > > > +#if (PAGE_SIZE < 8192)
> > > > > > + if (hnae_buf_size(ring) == HNS_BUFFER_SIZE_2048) {
> > > > > > + truesize = hnae_buf_size(ring);
> > > > > > + } else {
> > > > > > + truesize = ALIGN(size, L1_CACHE_BYTES);
> > > > > > + last_offset = hnae_page_size(ring) - 
> > > > > > hnae_buf_size(ring);
> > > > > > + }
> > > > > > +
> > > > > > +#else
> > > > > > + truesize = ALIGN(size, L1_CACHE_BYTES);
> > > > > > + last_offset = hnae_page_size(ring) - 
> > > > > > hnae_buf_size(ring);
> > > > > > +#endif
> > > > 
> > > > This is not indented properly, and it looks terrible.
> > And it makes one curious as to why last_offset isn't set
> > in the first block.
> 
> Hi Joe,

Hello.

> if hnae_buf_size que equal to HNS_BUFFER_SIZE, last_offset is useless in the 
> routines of this function.
> so it is ignored in the first block. thanks for your suggestion.

More to the point, last_offset is initialized to 0.

It'd be clearer not to initialize it at all and
set it to 0 in the first block and not overwrite
the initialization in each subsequent block.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ethernet: aurora: AURORA_NB8800 should depend on HAS_DMA

[Geert Uytterhoeven]

If NO_DMA=y:

ERROR: "dma_map_single" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
ERROR: "dma_unmap_page" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
ERROR: "dma_sync_single_for_cpu" [drivers/net/ethernet/aurora/nb8800.ko] 
undefined!
ERROR: "dma_unmap_single" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
ERROR: "dma_alloc_coherent" [drivers/net/ethernet/aurora/nb8800.ko] 
undefined!
ERROR: "dma_mapping_error" [drivers/net/ethernet/aurora/nb8800.ko] 
undefined!
ERROR: "dma_map_page" [drivers/net/ethernet/aurora/nb8800.ko] undefined!
ERROR: "dma_free_coherent" [drivers/net/ethernet/aurora/nb8800.ko] 
undefined!

Signed-off-by: Geert Uytterhoeven 
---
 drivers/net/ethernet/aurora/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/aurora/Kconfig 
b/drivers/net/ethernet/aurora/Kconfig
index a3c7106fdf85e78f..8ba7f8ff3434000f 100644
--- a/drivers/net/ethernet/aurora/Kconfig
+++ b/drivers/net/ethernet/aurora/Kconfig
@@ -13,6 +13,7 @@ if NET_VENDOR_AURORA
 
 config AURORA_NB8800
tristate "Aurora AU-NB8800 support"
+   depends on HAS_DMA
select PHYLIB
help
 Support for the AU-NB8800 gigabit Ethernet controller.
-- 
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 v3 0/2] IIO version of INA2xx

[Marc Titinger]

Version 3 of https://lkml.org/lkml/2015/11/25/245

  * rename ina2xx-iio to ian2xx-adc for consistency with other chips
(ina2xx being the hwmon driver).
  * add an exclusion in the iio/adc/Kconfig: depends on !SENSORS_INA2XX
  * more typos and style fixes
  * make regmap config const with .max_register = INA2XX_MAX_REGISTERS

previous references:
  * following RFC started in https://lkml.org/lkml/2015/11/10/370
  * and feed back from https://lkml.org/lkml/2015/11/18/395
  * Version 2: https://lkml.org/lkml/2015/11/30/245

Marc Titinger (2):
  iio: ina2xx: add support for TI INA2xx Power Monitors
  iio: ina2xx: provide a sysfs parameter to allow async readout of the
ADCs

 drivers/iio/adc/Kconfig  |  10 +
 drivers/iio/adc/Makefile |   1 +
 drivers/iio/adc/ina2xx-adc.c | 706 +++
 3 files changed, 717 insertions(+)
 create mode 100644 drivers/iio/adc/ina2xx-adc.c

-- 
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 v3 2/2] iio: ina2xx: provide a sysfs parameter to allow async readout of the ADCs

[Marc Titinger]

This can lead to repeated or skipped samples depending on the clock beat
between the capture thread and the chip sampling clock, but will also spare
reading/waiting for the Capture Ready Flag and improve the available i2c
bandwidth for reading measurements.

Output of iio_info:
...snip...
4 device-specific attributes found:
  attr 0: in_oversampling_ratio value: 4
  attr 1: in_allow_async_readout value: 0
  attr 2: integration_time_available value: 140 204 332 588 1100 2116...
  attr 3: in_sampling_frequency value: 114

Signed-off-by: Marc Titinger 
---
 drivers/iio/adc/ina2xx-adc.c | 54 
 1 file changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
index 0e7c474..615c203 100644
--- a/drivers/iio/adc/ina2xx-adc.c
+++ b/drivers/iio/adc/ina2xx-adc.c
@@ -111,6 +111,7 @@ struct ina2xx_chip_info {
s64 prev_ns;/* track buffer capture time, check for underruns*/
int int_time_vbus; /* Bus voltage integration time uS */
int int_time_vshunt; /* Shunt voltage integration time uS */
+   bool allow_async_readout;
 };
 
 static const struct ina2xx_config ina2xx_config[] = {
@@ -326,6 +327,33 @@ _err:
 }
 
 
+static ssize_t ina2xx_allow_async_readout_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct ina2xx_chip_info *chip = iio_priv(dev_to_iio_dev(dev));
+
+   return sprintf(buf, "%d\n", chip->allow_async_readout);
+}
+
+static ssize_t ina2xx_allow_async_readout_store(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf, size_t len)
+{
+   struct ina2xx_chip_info *chip = iio_priv(dev_to_iio_dev(dev));
+   bool val;
+   int ret;
+
+   ret = strtobool((const char *) buf, &val);
+   if (ret)
+   return ret;
+
+   chip->allow_async_readout = val;
+
+   return len;
+}
+
+
 #define INA2XX_CHAN(_type, _index, _address) { \
.type = (_type), \
.address = (_address), \
@@ -392,16 +420,17 @@ static int ina2xx_work_buffer(struct iio_dev *indio_dev)
 * GPIO a triggered buffer could be used instead.
 * For now, we pay for that extra read of the ALERT register
 */
-   do {
-   ret = regmap_read(chip->regmap, INA226_ALERT_MASK,
- &alert);
-   if (ret < 0)
-   return ret;
+   if (!chip->allow_async_readout)
+   do {
+   ret = regmap_read(chip->regmap, INA226_ALERT_MASK,
+ &alert);
+   if (ret < 0)
+   return ret;
 
-   alert &= INA266_CVRF;
-   trace_printk("Conversion ready: %d\n", !!alert);
+   alert &= INA266_CVRF;
+   trace_printk("Conversion ready: %d\n", !!alert);
 
-   } while (!alert);
+   } while (!alert);
 
/*
 * Single register reads: bulk_read will not work with ina226
@@ -446,7 +475,8 @@ static int ina2xx_capture_thread(void *data)
 * Poll a bit faster than the chip internal Fs, in case
 * we wish to sync with the conversion ready flag.
 */
-   sampling_us -= 200;
+   if (!chip->allow_async_readout)
+   sampling_us -= 200;
 
do {
buffer_us = ina2xx_work_buffer(indio_dev);
@@ -471,6 +501,7 @@ int ina2xx_buffer_enable(struct iio_dev *indio_dev)
 100/sampling_us, chip->avg);
 
trace_printk("Expected work period: %u us\n", sampling_us);
+   trace_printk("Async readout mode: %d\n", chip->allow_async_readout);
 
chip->prev_ns = iio_get_time_ns();
 
@@ -512,7 +543,12 @@ static int ina2xx_debug_reg(struct iio_dev *indio_dev,
 static IIO_CONST_ATTR_INT_TIME_AVAIL \
  ("0.000140 0.000204 0.000332 0.000588 0.001100 0.002116 0.004156 0.008244");
 
+static IIO_DEVICE_ATTR(in_allow_async_readout, S_IRUGO | S_IWUSR,
+  ina2xx_allow_async_readout_show,
+  ina2xx_allow_async_readout_store, 0);
+
 static struct attribute *ina2xx_attributes[] = {
+   &iio_dev_attr_in_allow_async_readout.dev_attr.attr,
&iio_const_attr_integration_time_available.dev_attr.attr,
NULL,
 };
-- 
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 v3 2/5] drm/dsi: Try to match non-DT dsi devices

[Jani Nikula]

On Mon, 07 Dec 2015, Archit Taneja  wrote:
> On 12/07/2015 02:15 PM, Jani Nikula wrote:
>> On Mon, 07 Dec 2015, Archit Taneja  wrote:
>>> Hi,
>>>
>>> On 11/30/2015 06:15 PM, kbuild test robot wrote:
 Hi Archit,

 [auto build test ERROR on: v4.4-rc3]
 [also build test ERROR on: next-20151127]

 url:
 https://github.com/0day-ci/linux/commits/Archit-Taneja/drm-dsi-DSI-for-devices-with-different-control-bus/20151130-200725
 config: x86_64-allyesdebian (attached as .config)
 reproduce:
   # save the attached .config to linux build tree
   make ARCH=x86_64

 All errors (new ones prefixed by >>):

  drivers/gpu/drm/drm_mipi_dsi.c: In function 'of_mipi_dsi_device_add':
>> drivers/gpu/drm/drm_mipi_dsi.c:168:6: error: implicit declaration of 
>> function 'of_modalias_node' [-Werror=implicit-function-declaration]
if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
>>>
>>> Any suggestions on how to fix this? Is it ok to make DRM_MIPI_DSI
>>> depend on CONFIG_OF?
>>
>> Please don't.
>
> Just curious, how did x86 use DSI if the only way to create DSI devices
> until now was via DT?

Oh, you want the gory details... we use the DSI code as a library for
abstraction and helpers, without actually creating or registering the
devices.

BR,
Jani.


>
> Archit
>
>>
>> BR,
>> Jani.
>>

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

Build regressions/improvements in v4.4-rc4

[Geert Uytterhoeven]

Below is the list of build error/warning regressions/improvements in
v4.4-rc4[1] compared to v4.3[2].

Summarized:
  - build errors: +12/-11
  - build warnings: +137/-105

JFYI, when comparing v4.4-rc4[1] to v4.4-rc3[3], the summaries are:
  - build errors: +11/-20
  - build warnings: +63/-35

Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.

As I haven't mastered kup yet, there's no verbose summary at
http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.4-rc4.summary.gz

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] http://kisskb.ellerman.id.au/kisskb/head/9664/ (256 out of 254 configs)
[2] http://kisskb.ellerman.id.au/kisskb/head/9535/ (256 out of 254 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/9647/ (255 out of 254 configs)


*** ERRORS ***

12 error regressions:
  + /home/kisskb/slave/src/arch/arm/kernel/patch.c: error: 'L_PTE_DIRTY' 
undeclared (first use in this function):  => 39:2
  + /home/kisskb/slave/src/arch/arm/kernel/patch.c: error: 'L_PTE_MT_WRITEBACK' 
undeclared (first use in this function):  => 39:2
  + /home/kisskb/slave/src/arch/arm/kernel/patch.c: error: 'L_PTE_PRESENT' 
undeclared (first use in this function):  => 39:2
  + /home/kisskb/slave/src/arch/arm/kernel/patch.c: error: 'L_PTE_XN' 
undeclared (first use in this function):  => 39:2
  + /home/kisskb/slave/src/arch/arm/kernel/patch.c: error: 'L_PTE_YOUNG' 
undeclared (first use in this function):  => 39:2
  + /home/kisskb/slave/src/net/sched/sch_dsmark.c: error: unrecognizable insn:: 
 => 316:1
  + error: e1000_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.memcpy' defined in .text section in arch/powerpc/lib/built-in.o:  => 
(.text+0x1ff98c4), (.text+0x1ff98b0)
  + error: e1000_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.netif_carrier_off' defined in .text section in net/built-in.o:  => 
(.text+0x1ff8a00)
  + error: e1000_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.netif_device_attach' defined in .text section in net/built-in.o:  => 
(.text+0x1ff8f00), (.text+0x1ff91dc)
  + error: e1000_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.netif_device_detach' defined in .text section in net/built-in.o:  => 
(.text+0x1ff7c74)
  + error: e1000_main.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_savegpr0_29' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ff8e58), (.text+0x1ff95f8)
  + error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`_restgpr0_30' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ff99d4), (.text+0x1ff997c)

11 error improvements:
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'early_init_dt_scan_nodes' 
[-Werror=implicit-function-declaration]: 244:2 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'early_init_dt_verify' 
[-Werror=implicit-function-declaration]: 215:2 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'of_flat_dt_match_machine' 
[-Werror=implicit-function-declaration]: 218:2 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'of_get_flat_dt_prop' 
[-Werror=implicit-function-declaration]: 229:3 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'of_get_flat_dt_root' 
[-Werror=implicit-function-declaration]: 228:3 => 
  - /home/kisskb/slave/src/drivers/scsi/advansys.c: error: implicit declaration 
of function 'free_dma' [-Werror=implicit-function-declaration]: 11384:3 => 
  - /home/kisskb/slave/src/drivers/scsi/advansys.c: error: implicit declaration 
of function 'request_dma' [-Werror=implicit-function-declaration]: 11300:4 => 
  - error: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' 
defined in .text section in arch/powerpc/kernel/entry_64.o: (.text+0x1ff8c08), 
(.text+0x1ff8684), (.text+0x1ff8a78), (.text+0x1ff8804), (.text+0x1ff90c8), 
(.text+0x1ff8ac0) => 
  - error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.eeh_check_failure' defined in .text section in 
arch/powerpc/kernel/built-in.o: (.text+0x1ff8ec4), (.text+0x1ff8fc0) => 
  - error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`_restgpr0_22' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ff90b0) => 
  - error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`_savegpr0_30' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o: (.text+0x1ff8a68) => 


*** WARNINGS ***

137 warning regressions:
  + /home/kisskb/slave/src/arch/powerpc/include/asm/io-defs.h: warning: 
'px_cmd' may be used uninitialized in this function [-Wuninitialized]:  => 11:1
  + /home/kisskb/slave/src/arch/powerp

Re: [PATCH 2/2] input: gt801_2plus1 - Add initial support for Goodix GT801 2+1

[Priit Laes]

On Mon, 2015-12-07 at 09:34 +0100, Julia Lawall wrote:
> It looks like braces may be mising.  Please check.

Thanks, nice catch!

It's actually messed up indenting. Code works as intended.
> 
> julia
> 
> On Mon, 7 Dec 2015, kbuild test robot wrote:
> 
> > Hi Priit,
> > 
> > [auto build test WARNING on mripard/sunxi/for-next]
> > [also build test WARNING on next-20151203]
> > [cannot apply to input/next v4.4-rc4]
> > 
> > url:    https://github.com/0day-ci/linux/commits/Priit-Laes/input-D
> river-for-Goodix-GT801-2-1-touchscreen/20151207-152831
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/mripard/lin
> ux.git sunxi/for-next
> > :: branch date: 46 minutes ago
> > :: commit date: 46 minutes ago
> > 
> > >> drivers/input/touchscreen/gt801_2plus1.c:119:3-30: code aligned
> with following code on line 120
> > 
> > git remote add linux-review https://github.com/0day-ci/linux
> > git remote update linux-review
> > git checkout d66df313f96e04572821e49cada65cb5c1bea9e2
> > vim +119 drivers/input/touchscreen/gt801_2plus1.c
> > 
> > d66df313 Priit Laes 2015-12-07  113   return;
> > d66df313 Priit Laes 2015-12-07  114  
> > d66df313 Priit Laes 2015-12-07  115   /* Build touch map */
> > d66df313 Priit Laes 2015-12-07  116   touch_num = 0;
> > d66df313 Priit Laes 2015-12-07  117   for (i = 0; (touch_raw != 0)
> && (i < ts->max_touch_num); i++) {
> > d66df313 Priit Laes 2015-12-07  118   if (touch_raw & 1)
> > d66df313 Priit Laes 2015-12-07
> @119   touch_map[touch_num++] = i;
> > d66df313 Priit Laes 2015-12-07 @120   touch_raw >>=
> 1;
> > d66df313 Priit Laes 2015-12-07  121   }
> > d66df313 Priit Laes 2015-12-07  122  
> > d66df313 Priit Laes 2015-12-07  123   /* Calculate checksum */
> > 
> > ---
> > 0-DAY kernel test infrastructure    Open Source
> Technology Center
> > https://lists.01.org/pipermail/kbuild-all  ; Intel
> Corporation
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/2] iio: ina2xx: add support for TI INA2xx Power Monitors

[Marc Titinger]

in SOFTWARE buffer mode, a kthread will capture the active scan_elements
into a kfifo, then compute the remaining time until the next capture tick
and do an active wait (udelay).

This will produce a stream of up to fours channels plus a 64bits
timestamps (ns).

Tested with ina226, on BeagleBoneBlack.

Datasheet: http://www.ti.com/lit/gpn/ina226

Signed-off-by: Marc Titinger 
---
 drivers/iio/adc/Kconfig  |  10 +
 drivers/iio/adc/Makefile |   1 +
 drivers/iio/adc/ina2xx-adc.c | 670 +++
 3 files changed, 681 insertions(+)
 create mode 100644 drivers/iio/adc/ina2xx-adc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index eb0cd89..e5fdc7d 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -170,6 +170,16 @@ config EXYNOS_ADC
  of SoCs for drivers such as the touchscreen and hwmon to use to share
  this resource.
 
+config INA2XX_ADC
+   tristate "Texas Instruments INA2xx Power Monitors IIO driver"
+   depends on I2C && !SENSORS_INA2XX
+   select REGMAP_I2C
+   select IIO_BUFFER
+   select IIO_KFIFO_BUF
+   help
+ Say yes here to build support for TI INA2xx family of Power Monitors.
+ This driver is mutually exclusive with the HWMON version.
+
 config LP8788_ADC
tristate "LP8788 ADC driver"
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a096210..2869b0ef 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
 obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
 obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
+obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
 obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_MAX1027) += max1027.o
 obj-$(CONFIG_MAX1363) += max1363.o
diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
new file mode 100644
index 000..0e7c474
--- /dev/null
+++ b/drivers/iio/adc/ina2xx-adc.c
@@ -0,0 +1,670 @@
+/*
+ * INA2XX Current and Power Monitors
+ *
+ * Copyright 2015 Baylibre SAS.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Based on linux/drivers/iio/adc/ad7291.c
+ * Copyright 2010-2011 Analog Devices Inc.
+ *
+ * Based on linux/drivers/hwmon/ina2xx.c
+ * Copyright 2012 Lothar Felten 
+ *
+ * Licensed under the GPL-2 or later.
+ *
+ * IIO driver for INA219-220-226-230-231
+ *
+ * Configurable 7-bit I2C slave address from 0x40 to 0x4F
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* INA2XX registers definition */
+#define INA2XX_CONFIG   0x00
+#define INA2XX_SHUNT_VOLTAGE0x01   /* readonly */
+#define INA2XX_BUS_VOLTAGE  0x02   /* readonly */
+#define INA2XX_POWER0x03   /* readonly */
+#define INA2XX_CURRENT  0x04   /* readonly */
+#define INA2XX_CALIBRATION  0x05
+
+#define INA226_ALERT_MASK  0x06
+#define INA266_CVRFBIT(3)
+
+#define INA2XX_MAX_REGISTERS8
+
+/* settings - depend on use case */
+#define INA219_CONFIG_DEFAULT   0x399F /* PGA=8 */
+#define INA226_CONFIG_DEFAULT   0x4327
+#define INA226_DEFAULT_AVG  4
+#define INA226_DEFAULT_IT  1110
+
+#define INA2XX_RSHUNT_DEFAULT   1
+
+/*
+ * bit mask for reading the averaging setting in the configuration register
+ * FIXME: use regmap_fields.
+ */
+#define INA2XX_MODE_MASK   GENMASK(3, 0)
+
+#define INA226_AVG_MASKGENMASK(11, 9)
+#define INA226_SHIFT_AVG(val)  ((val) << 9)
+
+/* Integration time for VBus */
+#define INA226_ITB_MASKGENMASK(8, 6)
+#define INA226_SHIFT_ITB(val)  ((val) << 6)
+
+/* Integration time for VShunt */
+#define INA226_ITS_MASKGENMASK(5, 3)
+#define INA226_SHIFT_ITS(val)  ((val) << 3)
+
+/* Cosmetic macro giving the sampling period for a full P=UxI cycle */
+#define SAMPLING_PERIOD(c) ((c->int_time_vbus + c->int_time_vshunt) \
+* c->avg)
+
+static bool ina2xx_is_writeable_reg(struct device *dev, unsigned int reg)
+{
+   return (reg == INA2XX_CONFIG) || (reg > INA2XX_CURRENT);
+}
+
+static bool ina2xx_is_volatile_reg(struct device *dev, unsigned int reg)
+{
+   return (reg != INA2XX_CONFIG);
+}
+
+static const struct regmap_config ina2xx_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 16,
+   .max_register = INA2XX_MAX_REGISTERS,
+   .writeable_reg = ina2xx_is_writeable_reg,
+   .volatile_reg = ina2xx_is_volatile_reg,
+};
+
+enum ina2xx_ids { ina219, ina226 };
+
+struct ina2xx_config {
+   u16 config_default;
+   int calibration_factor;
+   int shunt_div;
+   int bu

Re: (4.3.0) r8152: deadlock related to runtime suspend?

[Lu Baolu]

Hi Peter,

Have you ever tried disabling auto-pm? Did things go smoothly if auto-pm is 
disabled?

I always disable usb auto-pm in below way.

# echo on | tee /sys/bus/usb/devices/*/power/control
# echo on > /sys/bus/pci/devices//power/control

Thanks,
Baolu

On 12/05/2015 06:59 PM, Peter Wu wrote:
> Hi,
>
> I rarely use a Realtek USB 3.0 Gigabit Ethernet adapter (vid/pid
> 0bda:8153), but when I did last night, it resulted in a lockup of
> processes doing networking ("ip link", "ping", "ethtool", ...).
>
> A (few) minute(s) before that event, I noticed that there was no network
> connectivity (ping hung) which was somehow solved by invoking "ethtool
> eth1" (triggering runtime pm wakeup?). This same trick did not work at
> the next event. Invoking "ethtool eth1", "ip link", etc. hung completely
> and interrupt (^C) did not work at all.
>
> Since that did not work, I pulled the USB adapter and re-inserted it,
> hoping it would reset things. That did not work at all, there was a
> "usb disconnect" message, but no further driver messages.
>
> Fast forward an hour, and it has become a disaster. I have terminated
> and killed many programs via SysRq but am still unable to get a stable
> system that does not hang on network I/O. Even the suspend process
> fails so in the end I attempted to shutdown the system. After half an
> hour after getting the poweroff message, I issued SysRq + B to reboot
> (since SysRq + O did not shut down either).
>
> Attached are logs with various various backtraces from SysRq and failed
> suspend. Let me know if you need more information!
>
> By the way, often I have to rmmod xhci and re-insert it, otherwise
> plugging it in does not result in a detection. A USB 2.0 port does not
> have this problem (runtime PM is enabled for all devices). This is the
> USB 3.0 port:
>
> 02:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0
> Host Controller [1033:0194] (rev 03)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARC: [axs10x] enable DW DMA controller

[Alexey Brodkin]

Hi Vineet,

On Sat, 2015-12-05 at 10:14 +, Vineet Gupta wrote:
> On Saturday 05 December 2015 12:52 AM, Alexey Brodkin wrote:
> > From: Nelson Pereira 
> > 
> > ARC SDP baseboard among other peripherals sports
> > DesignWare DMA controller.
> > 
> > This enables support of that device.
> > Note typically DW DMA controller is used with external devices
> > connected to ARC SDP board via HAPS Extension bus.
> 
> Such a board config needs to have it's own defconfig / DT (if needed). 
> There's no
> point in enabling this for rest of the world who don't have a use case for 
> this IP.
> 
> So nack !

I see rationale behind this decision but:
1) How enabled DMA controller hurts other users of the same SDP board
2) That DMA controller exists in SDP anyway - that's not a special flavor of 
ARC SDP
3) Another defconfig and .dts adds another item for verification while
   enabling DW DMA in our current defconfigs allows usage of the same one 
binaries for
   all purposes on ARC SDP.

-AlexeyN�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 2/2] keys, trusted: seal with a policy

[Jarkko Sakkinen]

On Fri, Nov 20, 2015 at 01:34:35PM +1100, James Morris wrote:
> On Wed, 18 Nov 2015, Jarkko Sakkinen wrote:
> 
> > On Wed, Nov 18, 2015 at 11:21:01AM +1100, James Morris wrote:
> > > On Tue, 17 Nov 2015, Jarkko Sakkinen wrote:
> > > 
> > > > }
> > > > break;
> > > > +   case Opt_policydigest:
> > > > +   if (!tpm2 ||
> > > > +   strlen(args[0].from) != (2 * 
> > > > opt->digest_len))
> > > > +   return -EINVAL;
> > > > +   kfree(opt->policydigest);
> > > > +   opt->policydigest = kzalloc(opt->digest_len,
> > > > +   GFP_KERNEL);
> > > 
> > > Is it correct to kfree opt->policydigest here before allocating it?
> > 
> > I think so. The same option might be encountered multiple times.
> 
> This would surely signify an error?

I'm following the semantics of other options. That's why I implemented
it that way for example:

keyctl add trusted kmk "new 32 keyhandle=0x8000 keyhandle=0x8000"

is perfectly OK. I just thought that it'd be more odd if this option
behaved in a different way...

> -- 
> James Morris
> 

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Dec 7

[Stephen Rothwell]

Hi all,

Changes since 20151203:

Dropped tree: cgroup (complex conflict)

The vfs tree gained conflicts against the file-locks and Linus' trees.

The wireless-drivers-next tree gained a conflict against Linus' tree.

The drm tree gained a conflict against Linus' tree.

The modules tree lost its build failure.

The block tree gained conflicts against Linus' tree.

The clockevents tree gained a conflict against the h8300 tree.

The cgroup tree gained a complex conflict against Linus' tree for which
I dropped the cgroup tree.

The gpio tree still had its build failure, so I used the version from
next-20151127 for today.

The akpm-current tree gained conflicts against the arm, block and
tip trees.

Non-merge commits (relative to Linus' tree): 4118
 4783 files changed, 169401 insertions(+), 69856 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), I do an x86_64 modules_install followed by builds
for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc,
sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 231 trees (counting Linus' and 36 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

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

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (d035e336287b staging/lustre: remove IOC_LIBCFS_PING_TEST 
ioctl)
Merging fixes/master (25cb62b76430 Linux 4.3-rc5)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (2e22502c080f ARC: dw2 unwind: Remove falllback 
linear search thru FDE entries)
Merging arm-current/fixes (77f1b959b0b6 ARM: report proper DACR value in oops 
dumps)
Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2)
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 (7f821fc9c77a powerpc/tm: Check for already 
reclaimed tasks)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (2c302e7e4105 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging net/master (8b570dc9f7b6 sctp: only drop the reference on the datamsg 
after sending a msg)
Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops)
Merging ipvs/master (8e662164abb4 netfilter: nfnetlink_queue: avoid harmless 
unnitialized variable warnings)
Merging wireless-drivers/master (eeec5d0ef7ee rtlwifi: rtl8821ae: Fix lockups 
on boot)
Merging mac80211/master (c1df932c0574 mac80211: fix off-channel mgmt-tx 
uninitialized variable usage)
Merging sound-current/for-linus (a74a821624c0 ALSA: rme96: Fix unexpected 
volume reset after rate changes)
Merging pci-current/for-linus (99496bd2971f PCI: altera: Fix error when INTx is 
4)
Merging driver-core.current/driver-core-linus (31ade3b83e18 Linux 4.4-rc3)
Merging tty.current/tty-linus (31ade3b83e18 Linux 4.4-rc3)
Merging usb.current/usb-linus (4a0c4c36094c USB: host: ohci-at91: fix a crash 
in ohci_hcd_at91_overcurrent_irq)
Merging usb-gadget-fixes/fixes (62e345ae5b6e usb: dwc3: gadget: don't prestart 
interrupt endpoints)
Merging usb-serial-fixes/usb-linus (a0e80fbd56b4 USB: serial: Another Infineon 
flash loader USB ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: 
fix a possible NULL dereference)
Merging staging.current/staging-linus (9225c0b7b976 staging: lustre: 
echo_copy.._lsm() dereferences userland pointers directly)
Merging char-misc.current/char-misc-linus (e8c77bda05e5 fpga manager: Fix 
firmware resource leak on error)
Merging input-current/for-linus (1cf44efa1e4f Input: arizona-haptic 

Re: [PATCH] ARM: multi_v7_defconfig: Enable fan, sensors and audio for Odroid XU3

[Arnd Bergmann]

On Monday 07 December 2015 09:59:54 Krzysztof Kozlowski wrote:
> For Odroid XU3-family enable the:
>  - PWM fan (to control the CPU fan using thermal subsystem),
>  - TI INA231 sensors (provide power measurements of big.LITTLE cores,
>DRAM and GPU),
>  - Samsung sound (for Odroid XU3 and Snow as well).
> 
> Signed-off-by: Krzysztof Kozlowski 
> 

Looks good. Do you have a samsung/defconfig branch already that you
can put this into, or should be pick it up into arm-soc directly?

My preference is the former, but it would be a bit silly if that
is the only samsung defconfig change we need.

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

Re: Non-ascii mantainers

[Geert Uytterhoeven]

Hi Michael,

On Tue, Dec 1, 2015 at 6:27 PM, Michal Suchanek  wrote:
> On 1 December 2015 at 18:20, Al Viro  wrote:
>> On Tue, Dec 01, 2015 at 06:10:29PM +0100, Michal Suchanek wrote:
>>> there are non-ascii characters in output of scripts/get_maintainer.pl
>>>
>>> If output of said script is used as --to in git format-patch the patch
>>> is rejected by this list.
>>
>> Try to reproduce that in a UTF8 locale...
>
> I am using UTF-8 locale since ages.
>
> The characters show correctly in my terminal. I have no problem with
> that. The e-mail is then just rejected by the list server.
>
> I don't really care if the maintainers are encoded or whatever.
> However, neither get_maintainers nor git format-patch encodes them and
> the listserver rejects them when not encoded.

I always pass the --to and --cc to git send-email, not to format-patch, and
that works:

git send-email \
--to "Måns Rullgård " \
--to "David S. Miller " \
--cc "net...@vger.kernel.org" \
--cc "linux-kernel@vger.kernel.org" \
*00*

becomes:

From: Geert Uytterhoeven 
To: =?UTF-8?q?M=C3=A5ns=20Rullg=C3=A5rd?= ,
"David S. Miller" 
Cc: net...@vger.kernel.org,
linux-kernel@vger.kernel.org,
Geert Uytterhoeven 
Subject: [PATCH] ethernet: aurora: AURORA_NB8800 should depend on HAS_DMA
Date: Mon,  7 Dec 2015 10:09:06 +0100
Message-Id: <1449479346-32601-1-git-send-email-ge...@linux-m68k.org>
X-Mailer: git-send-email 1.9.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [net-next v5 0/8] dpaa_eth: Add the Freescale DPAA Ethernet driver

[Madalin-Cristian Bucur]

Hi Timur,

I've managed somehow to make got send-email to move the From: line in the body 
instead of the header, probably typed something wrong when asked to confirm the 
sender. I've resent the series.

Regards,
Madalin

From: Timur Tabi 
Sent: Saturday, December 5, 2015 6:40:11 AM
To: Bucur Madalin-Cristian-B32716
Cc: net...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; lkml; David Miller; 
Wood Scott-B07421; Liberman Igal-B31950; p...@mindchasers.com; Joe Perches; 
pebo...@tiscali.nl; Joakim Tjernlund; Greg Kroah-Hartman
Subject: Re: [net-next v5 0/8] dpaa_eth: Add the Freescale DPAA Ethernet driver

On Thu, Dec 3, 2015 at 6:08 AM,  <> wrote:
> From: Madalin Bucur 
>
> This patch series adds the Ethernet driver for the Freescale
> QorIQ Data Path Acceleration Architecture (DPAA).

Please fix your git-send-email configuration, so that your emails are
formatted properly.  This is the From: header:

From: <>

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/5] drm/dsi: Try to match non-DT dsi devices

[Archit Taneja]

On 12/07/2015 02:40 PM, Jani Nikula wrote:

On Mon, 07 Dec 2015, Archit Taneja  wrote:

On 12/07/2015 02:15 PM, Jani Nikula wrote:

On Mon, 07 Dec 2015, Archit Taneja  wrote:

Hi,

On 11/30/2015 06:15 PM, kbuild test robot wrote:

Hi Archit,

[auto build test ERROR on: v4.4-rc3]
[also build test ERROR on: next-20151127]

url:
https://github.com/0day-ci/linux/commits/Archit-Taneja/drm-dsi-DSI-for-devices-with-different-control-bus/20151130-200725
config: x86_64-allyesdebian (attached as .config)
reproduce:
   # save the attached .config to linux build tree
   make ARCH=x86_64

All errors (new ones prefixed by >>):

  drivers/gpu/drm/drm_mipi_dsi.c: In function 'of_mipi_dsi_device_add':

drivers/gpu/drm/drm_mipi_dsi.c:168:6: error: implicit declaration of function 
'of_modalias_node' [-Werror=implicit-function-declaration]

if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {


Any suggestions on how to fix this? Is it ok to make DRM_MIPI_DSI
depend on CONFIG_OF?


Please don't.


Just curious, how did x86 use DSI if the only way to create DSI devices
until now was via DT?


Oh, you want the gory details... we use the DSI code as a library for
abstraction and helpers, without actually creating or registering the
devices.


Okay, got it. I'll go with the IS_ENABLED(CONFIG_OF) approach.

Humble request: Next time if I share something that doesn't make sense, 
please reply with something more than a "Please don't". That just sounds

condescending and doesn't really help me with my cause either.

Thanks,
Archit



BR,
Jani.




Archit



BR,
Jani.





--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

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

Re: [PATCH resend 5/6] ARM: dts: sun7i: Add DRAM gates

[Maxime Ripard]

On Sat, Dec 05, 2015 at 09:16:46PM +0800, Chen-Yu Tsai wrote:
> The DRAM gates controls direct memory access for some peripherals.
> These peripherals include the display pipeline, so add the required
> gates to the simplefb nodes as well.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH v5 2/4] pinctrl: sunxi: Add H3 PIO controller support

[Maxime Ripard]

On Fri, Dec 04, 2015 at 10:24:41PM +0100, Jens Kuske wrote:
> The H3 uses the same pin controller as previous SoC's from Allwinner.
> Add support for the pins controlled by the main PIO controller.
> 
> Signed-off-by: Jens Kuske 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: Build regressions/improvements in v4.4-rc4

[Geert Uytterhoeven]

On Mon, Dec 7, 2015 at 10:10 AM, Geert Uytterhoeven
 wrote:
> JFYI, when comparing v4.4-rc4[1] to v4.4-rc3[3], the summaries are:
>   - build errors: +11/-20

Just a few more R_PPC64_REL24, and already reported arm-randconfig stuff.

> [1] http://kisskb.ellerman.id.au/kisskb/head/9664/ (256 out of 254 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/9647/ (255 out of 254 configs)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 RESEND] gpio: arizona: Support Cirrus Logic CS47L24 and WM1831

[Richard Fitzgerald]

The CS47L24 and WM1831 codecs only have two GPIO lines, but are
otherwise similar to the WM8280.

Signed-off-by: Richard Fitzgerald 
Acked-by: Linus Walleij 
---
 drivers/gpio/gpio-arizona.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
index 412d131..bb2a319 100644
--- a/drivers/gpio/gpio-arizona.c
+++ b/drivers/gpio/gpio-arizona.c
@@ -122,6 +122,10 @@ static int arizona_gpio_probe(struct platform_device *pdev)
case WM1814:
arizona_gpio->gpio_chip.ngpio = 5;
break;
+   case WM1831:
+   case CS47L24:
+   arizona_gpio->gpio_chip.ngpio = 2;
+   break;
default:
dev_err(&pdev->dev, "Unknown chip variant %d\n",
arizona->type);
-- 
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 v3 RESEND] gpio: arizona: Support Cirrus Logic CS47L24 and WM1831

[Richard Fitzgerald]

This patch seems to have got lost when all the other CS47L24 patches
were applied. I don't care whether it goes through the GPIO tree or
the MFD tree with the rest of the patches, but note that it has a build
dependency on the MFD patches for CS47L24.

Richard Fitzgerald (1):
  gpio: arizona: Support Cirrus Logic CS47L24 and WM1831

 drivers/gpio/gpio-arizona.c | 4 
 1 file changed, 4 insertions(+)

-- 
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 v1 02/10] clockevents/drivers: add MPS2 Timer driver

[Vladimir Murzin]

On 02/12/15 09:33, Vladimir Murzin wrote:
> MPS2 platform has simple 32 bits general purpose countdown timers.
> 
> The driver uses the first detected timer as a clocksource and the rest
> of the timers as a clockevent

Daniel, you had concerns on the RFC version. Does this one look fine to
you or there is something I should improve?

Thanks
Vladimir

> 
> Signed-off-by: Vladimir Murzin 
> ---
>  drivers/clocksource/Kconfig  |5 +
>  drivers/clocksource/Makefile |1 +
>  drivers/clocksource/mps2-timer.c |  277 
> ++
>  3 files changed, 283 insertions(+)
>  create mode 100644 drivers/clocksource/mps2-timer.c
> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 2eb5f0e..8bca09c 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -137,6 +137,11 @@ config CLKSRC_STM32
>   depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>   select CLKSRC_MMIO
>  
> +config CLKSRC_MPS2
> + bool "Clocksource for MPS2 SoCs" if COMPILE_TEST
> + depends on OF && ARM
> + select CLKSRC_MMIO
> +
>  config ARM_ARCH_TIMER
>   bool
>   select CLKSRC_OF if OF
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index 56bd16e..7033b9c 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_CLKSRC_EFM32)  += time-efm32.o
>  obj-$(CONFIG_CLKSRC_STM32)   += timer-stm32.o
>  obj-$(CONFIG_CLKSRC_EXYNOS_MCT)  += exynos_mct.o
>  obj-$(CONFIG_CLKSRC_LPC32XX) += time-lpc32xx.o
> +obj-$(CONFIG_CLKSRC_MPS2)+= mps2-timer.o
>  obj-$(CONFIG_CLKSRC_SAMSUNG_PWM) += samsung_pwm_timer.o
>  obj-$(CONFIG_FSL_FTM_TIMER)  += fsl_ftm_timer.o
>  obj-$(CONFIG_VF_PIT_TIMER)   += vf_pit_timer.o
> diff --git a/drivers/clocksource/mps2-timer.c 
> b/drivers/clocksource/mps2-timer.c
> new file mode 100644
> index 000..3e19af5
> --- /dev/null
> +++ b/drivers/clocksource/mps2-timer.c
> @@ -0,0 +1,277 @@
> +/*
> + * Copyright (C) 2015 ARM Limited
> + *
> + * Author: Vladimir Murzin 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#define pr_fmt(fmt)  KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TIMER_CTRL   0x0
> +#define TIMER_CTRL_ENABLEBIT(0)
> +#define TIMER_CTRL_IEBIT(3)
> +
> +#define TIMER_VALUE  0x4
> +#define TIMER_RELOAD 0x8
> +#define TIMER_INT0xc
> +
> +struct clockevent_mps2 {
> + void __iomem *reg;
> + u32 clock_count_per_tick;
> + struct clock_event_device clkevt;
> +};
> +
> +static void __iomem *sched_clock_base;
> +
> +static u64 notrace mps2_sched_read(void)
> +{
> +return ~readl_relaxed(sched_clock_base + TIMER_VALUE);
> +}
> +
> +static inline struct clockevent_mps2 *to_mps2_clkevt(struct 
> clock_event_device *c)
> +{
> + return container_of(c, struct clockevent_mps2, clkevt);
> +}
> +
> +static void clockevent_mps2_writel(u32 val, struct clock_event_device *c, 
> u32 offset)
> +{
> + writel(val, to_mps2_clkevt(c)->reg + offset);
> +}
> +
> +static int mps2_timer_shutdown(struct clock_event_device *ce)
> +{
> + clockevent_mps2_writel(0, ce, TIMER_RELOAD);
> + clockevent_mps2_writel(0, ce, TIMER_CTRL);
> +
> + return 0;
> +}
> +
> +static int mps2_timer_set_next_event(unsigned long next, struct 
> clock_event_device *ce)
> +{
> + clockevent_mps2_writel(next, ce, TIMER_VALUE);
> + clockevent_mps2_writel(TIMER_CTRL_IE | TIMER_CTRL_ENABLE, ce, 
> TIMER_CTRL);
> +
> + return 0;
> +}
> +
> +static int mps2_timer_set_periodic(struct clock_event_device *ce)
> +{
> + u32 clock_count_per_tick = to_mps2_clkevt(ce)->clock_count_per_tick;
> +
> + clockevent_mps2_writel(clock_count_per_tick, ce, TIMER_RELOAD);
> + clockevent_mps2_writel(clock_count_per_tick, ce, TIMER_VALUE);
> + clockevent_mps2_writel(TIMER_CTRL_IE | TIMER_CTRL_ENABLE, ce, 
> TIMER_CTRL);
> +
> + return 0;
> +}
> +
> +static irqreturn_t mps2_timer_interrupt(int irq, void *dev_id)
> +{
> + struct clockevent_mps2 *ce = dev_id;
> + u32 status = readl(ce->reg + TIMER_INT);
> +
> + if (!status) {
> + pr_warn("spuirous interrupt\n");
> + return IRQ_NONE;
> + }
> +
> + writel(1, ce->reg + TIMER_INT);
> +
> + ce->clkevt.event_handler(&ce->clkevt);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int __init mps2_clockevent_init(struct device_node *np)
> +{
> + void __iomem *base;
> + struct clk *clk;
> + struct clockevent_mps2 *ce;
> + u32 rate;
> + int irq, ret;
> + const char *name = "mps2-clkevt";
> +
> + ret = of_property_read_u32(np, "cloc

[PATCH] x86/mm: Align macro defines

[Borislav Petkov]

From: Borislav Petkov 

Bring PAGE_{SHIFT,SIZE,MASK} to the same indentation level as the rest
of the header.

Signed-off-by: Borislav Petkov 
---
 arch/x86/include/asm/page_types.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/page_types.h 
b/arch/x86/include/asm/page_types.h
index cc071c6f7d4d..7bd0099384ca 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -5,9 +5,9 @@
 #include 
 
 /* PAGE_SHIFT determines the page size */
-#define PAGE_SHIFT 12
-#define PAGE_SIZE  (_AC(1,UL) << PAGE_SHIFT)
-#define PAGE_MASK  (~(PAGE_SIZE-1))
+#define PAGE_SHIFT 12
+#define PAGE_SIZE  (_AC(1,UL) << PAGE_SHIFT)
+#define PAGE_MASK  (~(PAGE_SIZE-1))
 
 #define PMD_PAGE_SIZE  (_AC(1, UL) << PMD_SHIFT)
 #define PMD_PAGE_MASK  (~(PMD_PAGE_SIZE-1))
-- 
2.3.5

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

Re: [PATCH v1 04/10] serial: mps2-uart: add MPS2 UART driver

[Vladimir Murzin]

Gentle ping...

On 02/12/15 09:33, Vladimir Murzin wrote:
> This driver adds support to the UART controller found on ARM MPS2
> platform.
> 
> Signed-off-by: Vladimir Murzin 
> ---
>  drivers/tty/serial/Kconfig   |   12 +
>  drivers/tty/serial/Makefile  |1 +
>  drivers/tty/serial/mps2-uart.c   |  596 
> ++
>  include/uapi/linux/serial_core.h |3 +
>  4 files changed, 612 insertions(+)
>  create mode 100644 drivers/tty/serial/mps2-uart.c
> 
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index f38beb2..e98bfea 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1473,6 +1473,18 @@ config SERIAL_EFM32_UART
> This driver support the USART and UART ports on
> Energy Micro's efm32 SoCs.
>  
> +config SERIAL_MPS2_UART_CONSOLE
> + bool "MPS2 UART console support"
> + depends on SERIAL_MPS2_UART
> + select SERIAL_CORE_CONSOLE
> +
> +config SERIAL_MPS2_UART
> + bool "MPS2 UART port"
> + depends on ARM || COMPILE_TEST
> + select SERIAL_CORE
> + help
> +   This driver support the UART ports on ARM MPS2.
> +
>  config SERIAL_EFM32_UART_CONSOLE
>   bool "EFM32 UART/USART console support"
>   depends on SERIAL_EFM32_UART=y
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index 5ab4111..7f589f5 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR) += 
> digicolor-usart.o
>  obj-$(CONFIG_SERIAL_MEN_Z135)+= men_z135_uart.o
>  obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
>  obj-$(CONFIG_SERIAL_STM32)   += stm32-usart.o
> +obj-$(CONFIG_SERIAL_MPS2_UART)   += mps2-uart.o
>  
>  # GPIOLIB helpers for modem control lines
>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)  += serial_mctrl_gpio.o
> diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
> new file mode 100644
> index 000..09bac16
> --- /dev/null
> +++ b/drivers/tty/serial/mps2-uart.c
> @@ -0,0 +1,596 @@
> +/*
> + * Copyright (C) 2015 ARM Limited
> + *
> + * Author: Vladimir Murzin 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * TODO: support for SysRq
> + */
> +
> +#define pr_fmt(fmt)  KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SERIAL_NAME "ttyMPS"
> +#define DRIVER_NAME "mps2-uart"
> +#define MAKE_NAME(x) (DRIVER_NAME # x)
> +
> +#define UARTn_DATA   0x0
> +
> +#define UARTn_STATE  0x4
> +#define UARTn_STATE_TX_FULL  BIT(0)
> +#define UARTn_STATE_RX_FULL  BIT(1)
> +#define UARTn_STATE_TX_OVERRUN   BIT(2)
> +#define UARTn_STATE_RX_OVERRUN   BIT(3)
> +
> +#define UARTn_CTRL   0x8
> +#define UARTn_CTRL_TX_ENABLE BIT(0)
> +#define UARTn_CTRL_RX_ENABLE BIT(1)
> +#define UARTn_CTRL_TX_INT_ENABLE BIT(2)
> +#define UARTn_CTRL_RX_INT_ENABLE BIT(3)
> +#define UARTn_CTRL_TX_OVERRUN_INT_ENABLE BIT(4)
> +#define UARTn_CTRL_RX_OVERRUN_INT_ENABLE BIT(5)
> +
> +#define UARTn_INT0xc
> +#define UARTn_INT_TX BIT(0)
> +#define UARTn_INT_RX BIT(1)
> +#define UARTn_INT_TX_OVERRUN BIT(2)
> +#define UARTn_INT_RX_OVERRUN BIT(3)
> +
> +#define UARTn_BAUDDIV0x10
> +#define UARTn_BAUDDIV_MASK   GENMASK(20, 0)
> +
> +#define MPS2_MAX_PORTS   3
> +
> +struct mps2_uart_port {
> + struct uart_port port;
> + struct clk *clk;
> + unsigned int tx_irq;
> + unsigned int rx_irq;
> +};
> +
> +static inline struct mps2_uart_port *to_mps2_port(struct uart_port *port)
> +{
> + return container_of(port, struct mps2_uart_port, port);
> +}
> +
> +static void mps2_uart_write8(struct uart_port *port, u8 val, unsigned off)
> +{
> + struct mps2_uart_port *mps_port = to_mps2_port(port);
> +
> + writeb(val, mps_port->port.membase + off);
> +}
> +
> +static u8 mps2_uart_read8(struct uart_port *port, unsigned off)
> +{
> + struct mps2_uart_port *mps_port = to_mps2_port(port);
> +
> + return readb(mps_port->port.membase + off);
> +}
> +
> +static void mps2_uart_write32(struct uart_port *port, u32 val, unsigned off)
> +{
> + struct mps2_uart_port *mps_port = to_mps2_port(port);
> +
> + writel_relaxed(val, mps_port->port.membase + off);
> +}
> +
> +static unsigned int mps2_uart_tx_empty(struct uart_port *port)
> +{
> + u8 status = mps2_uart_read8(port, UARTn_STATE);
> +
> + 

Re: [PATCH net-next] net: hns: optimize XGE capability by reducing cpu usage

[Yankejian (Hackim Yim)]

On 2015/12/7 17:05, Joe Perches wrote:
> On Mon, 2015-12-07 at 16:58 +0800, Yankejian (Hackim Yim) wrote:
>> On 2015/12/7 11:32, Joe Perches wrote:
>>> On Sun, 2015-12-06 at 22:29 -0500, David Miller wrote:
> From: yankejian 
> Date: Sat, 5 Dec 2015 15:32:29 +0800
>
>>> +#if (PAGE_SIZE < 8192)
>>> + if (hnae_buf_size(ring) == HNS_BUFFER_SIZE_2048) {
>>> + truesize = hnae_buf_size(ring);
>>> + } else {
>>> + truesize = ALIGN(size, L1_CACHE_BYTES);
>>> + last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
>>> + }
>>> +
>>> +#else
>>> + truesize = ALIGN(size, L1_CACHE_BYTES);
>>> + last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
>>> +#endif
> This is not indented properly, and it looks terrible.
>>> And it makes one curious as to why last_offset isn't set
>>> in the first block.
>> Hi Joe,
> Hello.
>
>> if hnae_buf_size que equal to HNS_BUFFER_SIZE, last_offset is useless in the 
>> routines of this function.
>> so it is ignored in the first block. thanks for your suggestion.
> More to the point, last_offset is initialized to 0.
>
> It'd be clearer not to initialize it at all and
thanks, that is a good idea.

> set it to 0 in the first block and not overwrite
> the initialization in each subsequent block.
because it is useless, i think we'd better ignored it.

> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> .
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: gigaset: freeing an active object

[Tilman Schmidt]

Am 06.12.2015 um 21:12 schrieb Paul Bolle:
> On zo, 2015-12-06 at 16:29 +0100, Tilman Schmidt wrote:
>> So the solution might be as simple as moving the kfree() call from
>> gigaset_freecshw() to gigaset_device_release(). Something like this:
>>
>> --- a/drivers/isdn/gigaset/ser-gigaset.c
>> +++ b/drivers/isdn/gigaset/ser-gigaset.c
>> @@ -370,19 +370,18 @@ static void gigaset_freecshw(struct cardstate
>> *cs)
>> tasklet_kill(&cs->write_tasklet);
>> if (!cs->hw.ser)
>> return;
>> -   dev_set_drvdata(&cs->hw.ser->dev.dev, NULL);
>> platform_device_unregister(&cs->hw.ser->dev);
>> -   kfree(cs->hw.ser);
>> -   cs->hw.ser = NULL;
>>  }
>>
>>  static void gigaset_device_release(struct device *dev)
>>  {
>> -   struct platform_device *pdev = to_platform_device(dev);
>> +   struct cardstate *cs = dev_get_drvdata(dev);
>>
>> -   /* adapted from platform_device_release() in drivers/base/platform.c 
>> */
>> -   kfree(dev->platform_data);
>> -   kfree(pdev->resource);
>> +   if (!cs)
>> +   return;
>> +   dev_set_drvdata(dev, NULL);
>> +   kfree(cs->hw.ser);
>> +   cs->hw.ser = NULL;
>>  }
> 
> This solution assumes that the struct platform_device is moved out of
> the struct ser_cardstate, doesn't it? In other words, this is something
> to do on top of my (draft) patch.

No, that wasn't my intention. I thought of that solution as an
alternative, not an increment to your patch.

> Otherwise we'd still be freeing memory
> managed through reference counting.

Now I#m confused. I thought by following Peter's suggestion to put the
kfree() in the release method we'd avoid just that.

Regards,
Tilman

-- 
Tilman Schmidt  E-Mail: til...@imap.cc
Bonn, Germany
Nous, on a des fleurs et des bougies pour nous protéger.



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v5 05/11] spi: imx: Add support for loopback for ECSPI controllers

[Sascha Hauer]

On Sat, Dec 05, 2015 at 05:57:03PM +0100, Anton Bondarenko wrote:
> Support for ECSPI loopback for IMX51, IMX53 and IMX6Q using TEST register.
> 
> Signed-off-by: Mohsin Kazmi 
> Signed-off-by: Anton Bondarenko 
> ---
>  drivers/spi/spi-imx.c | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 363276d..3525616 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -246,6 +246,9 @@ static bool spi_imx_can_dma(struct spi_master *master, 
> struct spi_device *spi,
>  #define MX51_ECSPI_STAT  0x18
>  #define MX51_ECSPI_STAT_RR   (1 <<  3)
>  
> +#define MX51_ECSPI_TEST  0x20
> +#define MX51_ECSPI_LOOP  BIT(31)
> +
>  /* MX51 eCSPI */
>  static unsigned int mx51_ecspi_clkdiv(unsigned int fin, unsigned int fspi,
> unsigned int *fres)
> @@ -316,6 +319,7 @@ static int __maybe_unused mx51_ecspi_config(struct 
> spi_imx_data *spi_imx,
>   u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0, dma = 0;
>   u32 tx_wml_cfg, rx_wml_cfg, rxt_wml_cfg;
>   u32 clk = config->speed_hz, delay;
> + u32 lpb = 0;
>  
>   /*
>* The hardware seems to have a race condition when changing modes. The
> @@ -356,6 +360,12 @@ static int __maybe_unused mx51_ecspi_config(struct 
> spi_imx_data *spi_imx,
>   writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
>   writel(cfg, spi_imx->base + MX51_ECSPI_CONFIG);
>  
> + if (config->mode & SPI_LOOP)
> + lpb |= MX51_ECSPI_LOOP;
> +
> + if ((readl(spi_imx->base + MX51_ECSPI_TEST) & MX51_ECSPI_LOOP) != lpb)
> + writel(lpb, spi_imx->base + MX51_ECSPI_TEST);
> +
>   /*
>* Wait until the changes in the configuration register CONFIGREG
>* propagate into the hardware. It takes exactly one tick of the
> @@ -1128,6 +1138,9 @@ static int spi_imx_probe(struct platform_device *pdev)
>   spi_imx = spi_master_get_devdata(master);
>   spi_imx->bitbang.master = master;
>  
> + spi_imx->devtype_data = of_id ? of_id->data :
> + (struct spi_imx_devtype_data *)pdev->id_entry->driver_data;
> +
>   for (i = 0; i < master->num_chipselect; i++) {
>   int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
>   if (!gpio_is_valid(cs_gpio) && mxc_platform_info)
> @@ -1154,10 +1167,10 @@ static int spi_imx_probe(struct platform_device *pdev)
>   spi_imx->bitbang.master->unprepare_message = spi_imx_unprepare_message;
>   spi_imx->bitbang.master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
>  
> - init_completion(&spi_imx->xfer_done);
> + if (is_imx51_ecspi(spi_imx))
> + spi_imx->bitbang.master->mode_bits |= SPI_LOOP;
>  
> - spi_imx->devtype_data = of_id ? of_id->data :
> - (struct spi_imx_devtype_data *) pdev->id_entry->driver_data;
> + init_completion(&spi_imx->xfer_done);

Some unrelated lines are moved in these two hunks. Is this necessary or
just some leftover from development?

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/x86: fix filter_events() bug with event mappings

[Jiri Olsa]

On Sun, Dec 06, 2015 at 10:35:06PM +0100, Stephane Eranian wrote:

SNIP

> 
> This problem was introduced into commit 8300daa26.
> 
> Fixes: 8300daa26 ("perf/x86: Filter out undefined events from sysfs events 
> attribute")
> 
> Patch is relative to tip.git commit 03b6b9f.
> 
> Signed-off-by: Stephane Eranian 
> ---
>  arch/x86/kernel/cpu/perf_event.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/perf_event.c 
> b/arch/x86/kernel/cpu/perf_event.c
> index e7e63a9..70e16c7 100644
> --- a/arch/x86/kernel/cpu/perf_event.c
> +++ b/arch/x86/kernel/cpu/perf_event.c
> @@ -1534,6 +1534,7 @@ static void __init filter_events(struct attribute 
> **attrs)
>  {
>   struct device_attribute *d;
>   struct perf_pmu_events_attr *pmu_attr;
> + int offset = 0;
>   int i, j;
>  
>   for (i = 0; attrs[i]; i++) {
> @@ -1542,14 +1543,23 @@ static void __init filter_events(struct attribute 
> **attrs)
>   /* str trumps id */
>   if (pmu_attr->event_str)
>   continue;
> - if (x86_pmu.event_map(i))
> + if (x86_pmu.event_map(i + offset))
>   continue;
>  
>   for (j = i; attrs[j]; j++)
>   attrs[j] = attrs[j + 1];
> + attrs[j] = NULL;

hum.. the loop above quits when attrs[j] == NULL,
so I dont think u need to assign it again after

the NULL should get shifted in the last iteration of the loop above

>  
>   /* Check the shifted attr. */
>   i--;
> +
> + /*
> +  * event_map() is index based, the attrs array is organized
> +  * by increasing event index. If we shift the events, then
> +  * we need to compensate for the event_map(), otherwise
> +  * we are looking up the wrong event in the map
> +  */
> + offset++;

ouch, thanks for fixing this

I tested the patch and it fixes the issue

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] mailbox: Add support for APM X-Gene platform mailbox driver

[Duc Dang]

On Fri, Nov 20, 2015 at 3:47 AM, Jassi Brar  wrote:
> On Mon, Nov 9, 2015 at 11:35 PM, Duc Dang  wrote:
>> X-Gene mailbox controller provides 8 mailbox channels, with
>> each channel has a dedicated interrupt line.
>>
>> [dhdang: rebase over 4.3-rc5, some minor changes to
>> address comment in v2 patch set]
>>
> Do you want this to go into git logs?

Yes.

I will also rebase the patch set to v4.4-rc1.

>
>> Signed-off-by: Feng Kan 
>> Signed-off-by: Duc Dang 
>> ---
> here is the right place for any history. And it is good practice to
> specify whatever changes were made from last revision.

I will add change log into this section in next version of the patch.

>
>
>> +
>> +struct slimpro_mbox_chan {
>> +   struct device *dev;
>> +   struct mbox_chan *chan;
>> +   void __iomem *reg;
>> +   int id;
>>
> You don't seem to really need 'id'.

I will remove 'id'.

>
>
>> +
>> +static void mb_chan_enable_int(struct slimpro_mbox_chan *mb_chan, u32 mask)
>> +{
>> +   u32 val = readl(mb_chan->reg + REG_DB_STATMASK);
>> +
>> +   val &= ~mask;
>> +   writel(val, mb_chan->reg + REG_DB_STATMASK);
>> +}
>> +
>> +static void mb_chan_disable_int(struct slimpro_mbox_chan *mb_chan, u32 mask)
>> +{
>> +   u32 val = readl(mb_chan->reg + REG_DB_STATMASK);
>> +
>> +   val |= mask;
>> +   writel(val, mb_chan->reg + REG_DB_STATMASK);
>> +}
>> +
> These 2 functions are called just once. And do what other drivers
> usually inline. Wouldn't it be better to directly set & clear the bit
> when needed?

I will fold these 2 functions into their callers and then get rid of them.

>
>> +static int slimpro_mbox_send_data(struct mbox_chan *chan, void *msg)
>> +{
>> +   struct slimpro_mbox_chan *mb_chan =
>> +   (struct slimpro_mbox_chan *)chan->con_priv;
>> +
> You don't need to typecast a void pointer. Here and elsewhere.

I will remove all the typecast of a void pointer in the driver.

>
>
>> +
>> +   /* Setup mailbox links */
>> +   for (i = 0; i < MBOX_CNT; i++) {
>> +   ctx->mc[i].irq = platform_get_irq(pdev, i);
>>
> You expect every platform to provide exactly 'MBOX_CNT' irqs and they
> must be different (because you don't 'SHARE' when you request).
> Usually developers relax either of the conditions.

I will relax the MBOX_CNT irqs restriction: Platform can provide less
than MBOX_CNT irqs, which also means less than MBOX_CNT mailbox
channels.

>
>
>> +static struct platform_driver slimpro_mbox_driver = {
>> +   .probe  = slimpro_mbox_probe,
>> +   .remove = slimpro_mbox_remove,
>> +   .driver = {
>> +   .name = "xgene-slimpro-mbox",
>> +   .owner = THIS_MODULE,
>>
> No need to set .owner.

I will remove it.

>
> Cheers.

Regards,
Duc Dang.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tools build: Introduce features dump include makefile

[Wangnan (F)]

Sorry for the late response...

Tested-by: Wang Nan 

But I'm thinking whether we can remove FEATURE-DUMP and rely on
FEATURE-INCLUDE only, since they contain same information...

Thank you.

On 2015/12/7 16:56, Jiri Olsa wrote:

ping, Wang Nan, any comments on these 2?

thanks,
jirka

On Fri, Nov 27, 2015 at 10:06:50AM +0100, Jiri Olsa wrote:

Creating the FEATURE-INCLUDE file, that contains all features
status dumped in make's variable format:
...
feature-backtrace=1
feature-dwarf=1
...

It's purpose is to be included in sub-project makefiles to get
features detection state. This way we can run the detection only
in top level project and propagate it down.

Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-fcq5rtdhcu4300sjp2p8l...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
  tools/build/Makefile.feature | 12 
  tools/lib/bpf/.gitignore |  1 +
  tools/lib/bpf/Makefile   |  2 +-
  tools/perf/.gitignore|  1 +
  tools/perf/Makefile.perf |  2 +-
  5 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 37ff4c9f92f1..51f8d5928f98 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -131,6 +131,16 @@ ifeq ($(dwarf-post-unwind),1)
FEATURE_DUMP += dwarf-post-unwind($(dwarf-post-unwind-text))
  endif
  
+# The FEATURE-INCLUDE file contains all features status

+# dumped in make's variable format:
+#   ...
+#   feature-backtrace=1
+#   feature-dwarf=1
+#   ...
+# It's to be included in sub-project makefiles to get
+# features detection state.
+FEATURE_INCLUDE_FILENAME = $(OUTPUT)FEATURE-INCLUDE$(FEATURE_USER)
+
  # The $(feature_display) controls the default detection message
  # output. It's set if:
  # - detected features differes from stored features from
@@ -140,6 +150,8 @@ endif
  
  ifneq ("$(FEATURE_DUMP)","$(FEATURE_DUMP_FILE)")

$(shell echo "$(FEATURE_DUMP)" > $(FEATURE_DUMP_FILENAME))
+  $(shell rm -f $(FEATURE_INCLUDE_FILENAME))
+  $(foreach feat,$(FEATURE_TESTS),$(shell echo "feature-$(feat)=$(feature-$(feat))" 
>> $(FEATURE_INCLUDE_FILENAME)))
feature_display := 1
  endif
  
diff --git a/tools/lib/bpf/.gitignore b/tools/lib/bpf/.gitignore

index f81e549ddfdb..4019b8e4021a 100644
--- a/tools/lib/bpf/.gitignore
+++ b/tools/lib/bpf/.gitignore
@@ -1,2 +1,3 @@
  libbpf_version.h
  FEATURE-DUMP.libbpf
+FEATURE-INCLUDE.libbpf
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 636e3ddb93a1..6916cbe962a5 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -190,7 +190,7 @@ config-clean:
  clean:
$(call QUIET_CLEAN, libbpf) $(RM) *.o *~ $(TARGETS) *.a *.so 
$(VERSION_FILES) .*.d \
$(RM) LIBBPF-CFLAGS
-   $(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf
+   $(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf 
$(OUTPUT)FEATURE-INCLUDE.libbpf
  
  
  
diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore

index 3d1bb802dbf4..4a3eb8dedc54 100644
--- a/tools/perf/.gitignore
+++ b/tools/perf/.gitignore
@@ -2,6 +2,7 @@ PERF-CFLAGS
  PERF-GUI-VARS
  PERF-VERSION-FILE
  FEATURE-DUMP
+FEATURE-INCLUDE
  perf
  perf-read-vdso32
  perf-read-vdsox32
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 929a32ba15f5..b74f924185b7 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -589,7 +589,7 @@ clean: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean 
$(LIBBPF)-clean config-clean
$(Q)find . -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name 
'\.*.d' -delete
$(Q)$(RM) $(OUTPUT).config-detected
$(call QUIET_CLEAN, core-progs) $(RM) $(ALL_PROGRAMS) perf 
perf-read-vdso32 perf-read-vdsox32
-   $(call QUIET_CLEAN, core-gen)   $(RM)  *.spec *.pyc *.pyo */*.pyc 
*/*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE 
$(OUTPUT)FEATURE-DUMP $(OUTPUT)util/*-bison* $(OUTPUT)util/*-flex* \
+   $(call QUIET_CLEAN, core-gen)   $(RM)  *.spec *.pyc *.pyo */*.pyc 
*/*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE 
$(OUTPUT)FEATURE-DUMP $(OUTPUT)FEATURE-INCLUDE $(OUTPUT)util/*-bison* 
$(OUTPUT)util/*-flex* \
$(OUTPUT)util/intel-pt-decoder/inat-tables.c
$(QUIET_SUBDIR0)Documentation $(QUIET_SUBDIR1) clean
$(python-clean)
--
2.4.3




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

Re: [PATCH] usb: host: iounmap before return

[Lu Baolu]

On 12/06/2015 09:47 PM, Geyslan G. Bem wrote:
> This patch fixes a 'quirk_usb_handoff_xhci()' branch return that was not 
> unmapping correctly.
>
> Coccinelle: scripts/coccinelle/free/iounmap.cocci
>
> Signed-off-by: Geyslan G. Bem 
> ---
>  drivers/usb/host/pci-quirks.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index f940056..64150dd 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -990,7 +990,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>   /* We're reading garbage from the controller */
>   dev_warn(&pdev->dev,
>"xHCI controller failing to respond");
> - return;
> + goto out;

If "out" is only used here, why not iounmap and return directly here?

>   }
>  
>   if (!ext_cap_offset)
> @@ -1062,6 +1062,7 @@ hc_init:
>XHCI_MAX_HALT_USEC, val);
>   }
>  
> +out:
>   iounmap(base);
>  }
>  

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

Re: [PATCH v5 06/11] spi: imx: return error from dma channel request

[Sascha Hauer]

On Sat, Dec 05, 2015 at 05:57:04PM +0100, Anton Bondarenko wrote:
> On SDMA initialization return exactly the same error, which is
> reported by dma_request_slave_channel_reason(), it is a preceding
> change to defer SPI DMA initialization, if SDMA module is not yet
> available.
> 
> Signed-off-by: Vladimir Zapolskiy 
> Signed-off-by: Anton Bondarenko 
> ---
>  drivers/spi/spi-imx.c | 27 ---
>  1 file changed, 16 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 3525616..277dd75 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -846,10 +846,11 @@ static int spi_imx_sdma_init(struct device *dev, struct 
> spi_imx_data *spi_imx,
>   spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
>  
>   /* Prepare for TX DMA: */
> - master->dma_tx = dma_request_slave_channel(dev, "tx");
> - if (!master->dma_tx) {
> - dev_err(dev, "cannot get the TX DMA channel!\n");
> - ret = -EINVAL;
> + master->dma_tx = dma_request_slave_channel_reason(dev, "tx");
> + if (IS_ERR(master->dma_tx)) {
> + dev_info(dev, "cannot get the TX DMA channel!\n");

When changing it can you add the error code to the message? That's
usually the next thing one wants to know when reading it. Also, isn't
dev_dbg enough here? Otherwise the driver gets really verbose when it
actually defers probe.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] pwm-backlight: Avoid backlight flicker when probed from DT

[Lee Jones]

On Mon, 07 Dec 2015, Daniel Kurtz wrote:

> Hi Lee,
> 
> On Wed, Nov 25, 2015 at 12:26 AM, Lee Jones  wrote:
> > On Wed, 18 Nov 2015, Philipp Zabel wrote:
> >
> >> If the driver is probed from the device tree, and there is a phandle
> >> property set on it, and the enable GPIO is already configured as output,
> >> and the backlight is currently disabled, keep it disabled.
> >> If all these conditions are met, assume there will be some other driver
> >> that can enable the backlight at the appropriate time.
> >>
> >> Signed-off-by: Philipp Zabel 
> >> Reviewed-by: Christian Gmeiner 
> >> Tested-by: Heiko Stuebner 
> >> ---
> >>  - Rebased onto v4.4-rc1
> >>  - Added Heiko's Tested-by
> >> ---
> >>  drivers/video/backlight/pwm_bl.c | 23 ++-
> >>  1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > Applied, thanks.
> 
> Hmm, where was this applied?  I do not see it in:
>  * v4.4-rc4
>  * linux-next next-20151203 (dcccebc - Add linux-next specific files
> for 20151203)
> 
> Nor do I see it in any branch in:
>  * git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
> Is this the right git?

Yes, that's right.  When I say "applied", it means I applied it to my
local repository.  I am careful not to allude to the patch being
"pushed".  There is no guarantee when this will happen, since it
completly depends how busy the subsystem is.  For Backlight, as the
churn is low, the impetus for pushing is pretty low.

It has been "pushed" now though.

> By the way this repository has a git tag called "HEAD", which is a bit
> annoying since every time I "git remote update" from here, git gets
> confused until I manually delete it (git tag -d HEAD).

Thanks for letting me know.  I have now removed this tag.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] acpi, apei, arm64: APEI initial support for aarch64.

[Hanjun Guo]

Hi Fu Wei,

On 12/04/2015 01:15 AM, fu@linaro.org wrote:

From: Tomasz Nowicki 

This commit provides APEI arch-specific bits for aarch64

The reason for wrapping "acpi_disable_cmcff" by
"#if defined(__i386__) || defined(__x86_64__)" in hest.c is:
according to ACPI spec CMC(Corrected Machine Check) is only for IA-32
Architecture.

Changelog:
v3: Remove "acpi_disable_cmcff" from arm64 code,
 and wrap it in hest.c by "#if defined(__i386__) || defined(__x86_64__)"

v2: https://lkml.org/lkml/2015/12/2/432
 Rebase to latest kernel version(4.4-rc3).
 Move arch_apei_flush_tlb_one() to arch/arm64/kernel/acpi.c

v1: https://lkml.org/lkml/2015/8/14/199
 Move arch_apei_flush_tlb_one() to arch/arm64/include/asm/apci.h.
 Delete arch/arm64/kernel/apei.c.
 Add "#ifdef CONFIG_ACPI_APEI" for "acpi_disable_cmcff".


The version updates is not belong here, if you need to add
it, please place it under "---" below.



Signed-off-by: Tomasz Nowicki 
Tested-by: Jonathan (Zhixiong) Zhang 
Signed-off-by: Fu Wei 
---


...just here.


  arch/arm64/Kconfig| 1 +
  arch/arm64/include/asm/acpi.h | 1 +
  arch/arm64/kernel/acpi.c  | 6 ++
  drivers/acpi/apei/hest.c  | 2 ++
  4 files changed, 10 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 871f217..58c8992 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -3,6 +3,7 @@ config ARM64
select ACPI_CCA_REQUIRED if ACPI
select ACPI_GENERIC_GSI if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
+   select HAVE_ACPI_APEI if ACPI
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index caafd63..7207f8e 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -94,6 +94,7 @@ static inline const char *acpi_get_enable_method(int cpu)

  #ifdefCONFIG_ACPI_APEI
  pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
+void arch_apei_flush_tlb_one(unsigned long addr);
  #endif

  #endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..7a742e7 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -32,6 +32,7 @@
  #ifdef CONFIG_ACPI_APEI
  # include 
  # include 
+# include 
  #endif

  int acpi_noirq = 1;   /* skip ACPI IRQ initialization */
@@ -233,4 +234,9 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
return __pgprot(PROT_NORMAL_NC);
return __pgprot(PROT_DEVICE_nGnRnE);
  }
+
+void arch_apei_flush_tlb_one(unsigned long addr)
+{
+   flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+}


Maybe just a static inline function in arch/arm64/include/asm/acpi.h
will be good?


  #endif
diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
index 20b3fcf..4ead747 100644
--- a/drivers/acpi/apei/hest.c
+++ b/drivers/acpi/apei/hest.c
@@ -232,8 +232,10 @@ void __init acpi_hest_init(void)
goto err;
}

+#if defined(__i386__) || defined(__x86_64__)
if (!acpi_disable_cmcff)
apei_hest_parse(hest_parse_cmc, NULL);
+#endif


How about put it together into a function, and
introduce a stub function when no __i386__ and
__x86_64__ case?

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

Re: [PATCH v5] clk: sunxi: Add CLK_OF_DECLARE support for sun8i-a23-apb0-clk driver

[Maxime Ripard]

Hi,

On Thu, Dec 03, 2015 at 03:05:30PM +0800, Chen-Yu Tsai wrote:
> The APBS clock on sun9i is the same as the APB0 clock on sun8i. With
> sun9i we are supporting the PRCM clocks by using CLK_OF_DECLARE,
> instead of through a PRCM mfd device and subdevices for each clock
> and reset control. As such we need a CLK_OF_DECLARE version of
> the sun8i-a23-apb0-clk driver.
> 
> Also, build it for sun9i/A80, and not just for configurations with
> MFD_SUN6I_PRCM enabled.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
> 
> Changes since v4:
> 
>   - Keep building clk-sun8i-apb0 for SUN6I_MFD_PRCM.
> 
>   - Add an error message and comment for when of_io_request_and_map()
> fails. of_io_request_and_map() merges a bunch of errors into -EINVAL,
> so this might not be the best approach. But I think having an error
> message when we know something is wrong (-EBUSY, -ENOMEM) is better.
> 
> ---
>  drivers/clk/sunxi/Makefile |  1 +
>  drivers/clk/sunxi/clk-sun8i-apb0.c | 80 
> --
>  2 files changed, 69 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index 103efab05ca8..ccf21ba3b6b0 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -15,6 +15,7 @@ obj-y += clk-sun9i-core.o
>  obj-y += clk-sun9i-mmc.o
>  obj-y += clk-usb.o
>  
> +obj-$(CONFIG_MACH_SUN9I) += clk-sun8i-apb0.o
>  obj-$(CONFIG_MACH_SUN9I) += clk-sun9i-cpus.o
>  
>  obj-$(CONFIG_MFD_SUN6I_PRCM) += \
> diff --git a/drivers/clk/sunxi/clk-sun8i-apb0.c 
> b/drivers/clk/sunxi/clk-sun8i-apb0.c
> index 7ae5d2c2cde1..7ba61103a6f5 100644
> --- a/drivers/clk/sunxi/clk-sun8i-apb0.c
> +++ b/drivers/clk/sunxi/clk-sun8i-apb0.c
> @@ -17,13 +17,77 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> +static struct clk *sun8i_a23_apb0_register(struct device_node *node,
> +void __iomem *reg)
> +{
> + const char *clk_name = node->name;
> + const char *clk_parent;
> + struct clk *clk;
> + int ret;
> +
> + clk_parent = of_clk_get_parent_name(node, 0);
> + if (!clk_parent)
> + return ERR_PTR(-EINVAL);
> +
> + of_property_read_string(node, "clock-output-names", &clk_name);
> +
> + /* The A23 APB0 clock is a standard 2 bit wide divider clock */
> + clk = clk_register_divider(NULL, clk_name, clk_parent, 0, reg,
> +0, 2, CLK_DIVIDER_POWER_OF_TWO, NULL);
> + if (IS_ERR(clk))
> + return clk;
> +
> + ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
> + if (ret)
> + goto err_unregister;
> +
> + return clk;
> +
> +err_unregister:
> + clk_unregister_divider(clk);
> +
> + return ERR_PTR(ret);
> +}
> +
> +static void sun8i_a23_apb0_setup(struct device_node *node)
> +{
> + void __iomem *reg;
> + struct resource res;
> + struct clk *clk;
> +
> + reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> + if (IS_ERR(reg)) {
> + /*
> +  * This happens with clk nodes instantiated through mfd,
> +  * as those do not have their resources assigned in the
> +  * device tree. Do not print an error in this case.
> +  */
> + if (PTR_ERR(reg) != -EINVAL)
> + pr_err("Could not get registers for a23-apb0-clk\n");

This is not the only case you have to take into account.

There's also the case when you have a regular clock (and by regular I
mean that is not in the PRCM) that will be probed by the
CLK_OF_DECLARE mechanism and then later by the device model.

In such a case, the second of_io_request_and_map will fail, and you
will have an error returned that you do not ignore at the moment.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH 2/3] dt-bindings: regulator/mfd: Reorganize S5M8767 bindings

[Lee Jones]

On Fri, 04 Dec 2015, Krzysztof Kozlowski wrote:

> The regulator/s5m8767-regulator.txt duplicates some of the information
> about bindings with old mfd/s2mps11.txt. Now common part exists entirely
> in mfd/samsung,sec-core.txt so:
>  - add company prefix to file name (regulator/samsung,s5m8767.txt),
>  - remove duplicated information,
>  - reorganize the contents to match style of
>regulator/samsung,s2mps11.txt.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../devicetree/bindings/mfd/samsung,sec-core.txt   |   4 +-

Acked-by: Lee Jones 

>  .../bindings/regulator/s5m8767-regulator.txt   | 163 
> -
>  .../bindings/regulator/samsung,s5m8767.txt | 145 ++
>  MAINTAINERS|   2 +-
>  4 files changed, 149 insertions(+), 165 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt 
> b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
> index ef0166d0f643..4aeb95c82304 100644
> --- a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
> +++ b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
> @@ -14,6 +14,7 @@ addressed by the host system using different I2C slave 
> addresses.
>  This document describes bindings for main device node. Optional sub-blocks
>  must be a sub-nodes to it. Bindings for them can be found in:
>   - bindings/regulator/samsung,s2mps11.txt
> + - bindings/regulator/samsung,s5m8767.txt
>   - bindings/clock/samsung,s2mps11.txt
>  
>  
> @@ -23,7 +24,8 @@ Required properties:
>   - "samsung,s2mps13-pmic",
>   - "samsung,s2mps14-pmic",
>   - "samsung,s2mps15-pmic",
> - - "samsung,s2mpu02-pmic".
> + - "samsung,s2mpu02-pmic",
> + - "samsung,s5m8767-pmic".
>   - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
>  
>  Optional properties:
> diff --git 
> a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt 
> b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
> deleted file mode 100644
> index 20191315e444..
> --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
> +++ /dev/null
> @@ -1,163 +0,0 @@
> -* Samsung S5M8767 Voltage and Current Regulator
> -
> -The Samsung S5M8767 is a multi-function device which includes voltage and
> -current regulators, rtc, charger controller and other sub-blocks. It is
> -interfaced to the host controller using a i2c interface. Each sub-block is
> -addressed by the host system using different i2c slave address. This document
> -describes the bindings for 'pmic' sub-block of s5m8767.
> -
> -Required properties:
> -- compatible: Should be "samsung,s5m8767-pmic".
> -- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
> -
> -- s5m8767,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt 
> (uV)
> -  units for buck2 when changing voltage using gpio dvs. Refer to [1] below
> -  for additional information.
> -
> -- s5m8767,pmic-buck3-dvs-voltage: A set of 8 voltage values in micro-volt 
> (uV)
> -  units for buck3 when changing voltage using gpio dvs. Refer to [1] below
> -  for additional information.
> -
> -- s5m8767,pmic-buck4-dvs-voltage: A set of 8 voltage values in micro-volt 
> (uV)
> -  units for buck4 when changing voltage using gpio dvs. Refer to [1] below
> -  for additional information.
> -
> -- s5m8767,pmic-buck-ds-gpios: GPIO specifiers for three host gpio's used
> -  for selecting GPIO DVS lines. It is one-to-one mapped to dvs gpio lines.
> -
> -[1] If none of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
> -property is specified, the 's5m8767,pmic-buck[2/3/4]-dvs-voltage'
> -property should specify atleast one voltage level (which would be a
> -safe operating voltage).
> -
> -If either of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
> -property is specified, then all the eight voltage values for the
> -'s5m8767,pmic-buck[2/3/4]-dvs-voltage' should be specified.
> -
> -Optional properties:
> -- interrupt-parent: Specifies the phandle of the interrupt controller to 
> which
> -  the interrupts from s5m8767 are delivered to.
> -- interrupts: Interrupt specifiers for two interrupt sources.
> -  - First interrupt specifier is for 'irq1' interrupt.
> -  - Second interrupt specifier is for 'alert' interrupt.
> -- s5m8767,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
> -- s5m8767,pmic-buck3-uses-gpio-dvs: 'buck3' can be controlled by gpio dvs.
> -- s5m8767,pmic-buck4-uses-gpio-dvs: 'buck4' can be controlled by gpio dvs.
> -
> -Additional properties required if either of the optional properties are used:
> -
> -- s5m8767,pmic-buck234-default-dvs-idx: Default voltage setting selected from
> -  the possible 8 options selectable by the dv

Re: [PATCH 3/3] dt-bindings: regulator/mfd: Reorganize S2MPA01 bindings

[Lee Jones]

On Fri, 04 Dec 2015, Krzysztof Kozlowski wrote:

> The mfd/s2mpa01.txt duplicates some of the information about bindings
> with old mfd/s2mps11.txt. Now common part exists entirely in
> mfd/samsung,sec-core.txt so:
>  - add company prefix to file name (regulator/samsung,s2mpa01.txt),
>  - remove duplicated information,
>  - reorganize the contents to match style of
>regulator/samsung,s2mps11.txt.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/mfd/s2mpa01.txt  | 90 
> --
>  .../devicetree/bindings/mfd/samsung,sec-core.txt   |  4 +-

Acked-by: Lee Jones 

>  .../bindings/regulator/samsung,s2mpa01.txt | 79 +++
>  3 files changed, 82 insertions(+), 91 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/mfd/s2mpa01.txt
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/s2mpa01.txt 
> b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
> deleted file mode 100644
> index c13d3d8c3947..
> --- a/Documentation/devicetree/bindings/mfd/s2mpa01.txt
> +++ /dev/null
> @@ -1,90 +0,0 @@
> -
> -* Samsung S2MPA01 Voltage and Current Regulator
> -
> -The Samsung S2MPA01 is a multi-function device which includes high
> -efficiency buck converters including Dual-Phase buck converter, various LDOs,
> -and an RTC. It is interfaced to the host controller using an I2C interface.
> -Each sub-block is addressed by the host system using different I2C slave
> -addresses.
> -
> -Required properties:
> -- compatible: Should be "samsung,s2mpa01-pmic".
> -- reg: Specifies the I2C slave address of the PMIC block. It should be 0x66.
> -
> -Optional properties:
> -- interrupt-parent: Specifies the phandle of the interrupt controller to 
> which
> -  the interrupts from s2mpa01 are delivered to.
> -- interrupts: An interrupt specifier for the sole interrupt generated by the
> -  device.
> -
> -Optional nodes:
> -- regulators: The regulators of s2mpa01 that have to be instantiated should 
> be
> -  included in a sub-node named 'regulators'. Regulator nodes and constraints
> -  included in this sub-node use the standard regulator bindings which are
> -  documented elsewhere.
> -
> -Properties for BUCK regulator nodes:
> -- regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500
> -  (default), 25000, or 5. May be 0 for disabling the ramp delay on
> -  BUCK{1,2,3,4}.
> -
> - In the absence of the regulator-ramp-delay property, the default ramp
> - delay will be used.
> -
> -  NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be 
> set
> -  for a particular group of BUCKs. So provide same 
> regulator-ramp-delay=.
> -
> -  The following BUCKs share ramp settings:
> -  * 1 and 6
> -  * 2 and 4
> -  * 8, 9, and 10
> -
> -The following are the names of the regulators that the s2mpa01 PMIC block
> -supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
> -as per the datasheet of s2mpa01.
> -
> - - LDOn
> -   - valid values for n are 1 to 26
> -   - Example: LDO1, LD02, LDO26
> - - BUCKn
> -   - valid values for n are 1 to 10.
> -   - Example: BUCK1, BUCK2, BUCK9
> -
> -Example:
> -
> - s2mpa01_pmic@66 {
> - compatible = "samsung,s2mpa01-pmic";
> - reg = <0x66>;
> -
> - regulators {
> - ldo1_reg: LDO1 {
> - regulator-name = "VDD_ALIVE";
> - regulator-min-microvolt = <100>;
> - regulator-max-microvolt = <100>;
> - };
> -
> - ldo2_reg: LDO2 {
> - regulator-name = "VDDQ_MMC2";
> - regulator-min-microvolt = <280>;
> - regulator-max-microvolt = <280>;
> - regulator-always-on;
> - };
> -
> - buck1_reg: BUCK1 {
> - regulator-name = "vdd_mif";
> - regulator-min-microvolt = <95>;
> - regulator-max-microvolt = <135>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - buck2_reg: BUCK2 {
> - regulator-name = "vdd_arm";
> - regulator-min-microvolt = <95>;
> - regulator-max-microvolt = <135>;
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-ramp-delay = <5>;
> - };
> - };
> - };
> diff --git a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt 
> b/Documentation/devicetree/bindings/

Re: [PATCH v2 1/9] clk: hi3519: add dt-binding document and header file

[Arnd Bergmann]

On Monday 07 December 2015 16:01:03 xuejiancheng wrote:
> On 2015/12/4 18:56, Arnd Bergmann wrote:
> > On Friday 04 December 2015 11:21:28 xuejiancheng wrote:
> >> Hi Arnd,
> >>
> >> On 2015/12/3 17:44, Arnd Bergmann wrote:
> >>> On Thursday 03 December 2015 10:39:24 Jiancheng Xue wrote:
>  +#ifndef __DTS_HI3519_CLOCK_H
>  +#define __DTS_HI3519_CLOCK_H
> >>>
> >>> Please try to avoid adding headers like this if you can at all.
> >>>
> >>> I might ask you to merge the header file in one merge window
> >>> otherwise and submit the platform code one kernel later, as they
> >>> tendn to cause us needless dependencies otherwise.
> >>>
> >>
> >> Sorry. In v1, Rob suggested putting binding doc and header files in
> >> a separate patch. The clock driver indeed depends on the header.
> >>
> >> I will put the header and the clock driver in a patch, and keep the
> >> binding doc in another patch.
> > 
> > Having split patches is better, I was really commenting on the fact
> > that ideally you would not have a header file at all. If we merge
> > the header through arm-soc, then you won't be able to merge the
> > clk driver easily, and if you merge the header through the clk
> > maintainer, I'm can't take your dts files.
> 
> Thank you for your comments. Because the clocks in the crg module have
> different types and random layouts. If this header file is removed,
> the clock driver and the dts files will get very complicated.
> 
> Could you help me acknowledge it if I put the header file and clock driver
> in a patch?
> 
> Could you give me some suggestions If I want to keep this header file?

If this is another clock controller that has a random register layout,
then adding the header file is the least problematic solution indeed.

> >>> Where do those numbers come from? They are not consecutive, so it sounds
> >>> like they are directly from the data sheet and won't be needed in the 
> >>> driver.
> >>> If that's true, just use the numbers directly, as you do for everything
> >>> else.
> >>
> >> The numbers are defined by myself, not directly from the data sheet. Some 
> >> numbers
> >> are reserved for device nodes which will be added later. So they are not 
> >> consecutive now.
> > 
> > I don't understand. How do you decide which numbers to reserve? If the
> > numbers are completely arbitrary and you have no idea what other clocks
> > there are, you can simply have consecutive numbers here and do the driver
> > accordingly.
> 
> The clocks are divided into several groups according to their types. The 
> clocks in
> a group are expected to have consecutive numbers. So some numbers are 
> reserved for
> every group in this file, just like in some existing headers. Other clocks 
> will be
> added when other peripherals drivers are submitted. They will use the reserve 
> numbers
> and be inserted into existing groups.
> 
> Of course it is not required to reserve numbers for later added clocks.

Are you able to enumerate all the clocks then? If all clocks that are
supported by this clock controllers have names in the data sheet, I
would prefer to just list them all now rather than only enter the ones
we already need, to avoid having future merge conflicts.

Then we just need to add code to support those clocks when we need them,
but that can be done in parallel to adding the DT nodes and the driver,
rather than strongly serializing the patch flow on the header file patches.

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

Re: [PATCH 1/3] dt-bindings: regulator/clock/mfd: Reorganize S2MPS-family bindings

[Lee Jones]

On Fri, 04 Dec 2015, Krzysztof Kozlowski wrote:

> Bindings for Samsung S2M and S5M family PMICs are in mess. They are
> spread over different files and subdirectories in a non-consistent way.
> The devices and respective drivers for them share a lot in common so
> everything could be organized in a more readable way.
> 
> Reorganize the S2MPS11/13/14/15 Device Tree bindings to match the
> drivers for this family of devices:
>  - move mfd/s2mps11.txt to mfd/samsung,sec-core.txt for the main MFD
>driver (common for entire family),
>  - split clock block to clock/samsung,s2mps11.txt,
>  - split regulator block to regulator/samsung,s2mps11.txt.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../devicetree/bindings/clock/samsung,s2mps11.txt  |  49 +++
>  Documentation/devicetree/bindings/mfd/s2mps11.txt  | 153 
> -
>  .../devicetree/bindings/mfd/samsung,sec-core.txt   |  84 +++

Acked-by: Lee Jones 

>  .../bindings/regulator/samsung,s2mps11.txt | 102 ++
>  MAINTAINERS|   4 +-
>  5 files changed, 238 insertions(+), 154 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
>  delete mode 100644 Documentation/devicetree/bindings/mfd/s2mps11.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/samsung,s2mps11.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt 
> b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
> new file mode 100644
> index ..2726c1d58a79
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
> @@ -0,0 +1,49 @@
> +Binding for Samsung S2M and S5M family clock generator block
> +
> +
> +This is a part of device tree bindings for S2M and S5M family multi-function
> +devices.
> +More information can be found in bindings/mfd/sec-core.txt file.
> +
> +The S2MPS11/13/15 and S5M8767 provide three(AP/CP/BT) buffered 32.768 kHz
> +outputs. The S2MPS14 provides two (AP/BT) buffered 32.768 KHz outputs.
> +
> +To register these as clocks with common clock framework instantiate under
> +main device node a sub-node named "clocks".
> +
> +It uses the common clock binding documented in:
> + - Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +
> +Required properties of the "clocks" sub-node:
> + - #clock-cells: should be 1.
> + - compatible: Should be one of: "samsung,s2mps11-clk", 
> "samsung,s2mps13-clk",
> +   "samsung,s2mps14-clk", "samsung,s5m8767-clk"
> +   The S2MPS15 uses the same compatible as S2MPS13, as both provides similar
> +   clocks.
> +
> +
> +Each clock is assigned an identifier and client nodes use this identifier
> +to specify the clock which they consume.
> +Clock   ID   Devices
> +--
> +32KhzAP  0S2MPS11/13/14/15, S5M8767
> +32KhzCP  1S2MPS11/13/15, S5M8767
> +32KhzBT  2S2MPS11/13/14/15, S5M8767
> +
> +Include dt-bindings/clock/samsung,s2mps11.h file to use preprocessor defines
> +in device tree sources.
> +
> +
> +Example:
> +
> + s2mps11_pmic@66 {
> + compatible = "samsung,s2mps11-pmic";
> + reg = <0x66>;
> +
> + s2m_osc: clocks {
> + compatible = "samsung,s2mps11-clk";
> + #clock-cells = <1>;
> + clock-output-names = "xx", "yy", "zz";
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> deleted file mode 100644
> index 09b94c97faac..
> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> +++ /dev/null
> @@ -1,153 +0,0 @@
> -
> -* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator
> -
> -The Samsung S2MPS11 is a multi-function device which includes voltage and
> -current regulators, RTC, charger controller and other sub-blocks. It is
> -interfaced to the host controller using an I2C interface. Each sub-block is
> -addressed by the host system using different I2C slave addresses.
> -
> -Required properties:
> -- compatible: Should be one of the following
> - - "samsung,s2mps11-pmic"
> - - "samsung,s2mps13-pmic"
> - - "samsung,s2mps14-pmic"
> - - "samsung,s2mps15-pmic"
> - - "samsung,s2mpu02-pmic".
> -- reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
> -
> -Optional properties:
> -- interrupt-parent: Specifies the phandle of the interrupt controller to 
> which
> -  the interrupts from s2mps11 are delivered to.
> -- interrupts: Interrupt specifiers for interrupt sources.
> -- samsung,s2mps11-wrstbi-ground: Indicates that WRSTBI pin of PMIC is pulled
> -  do

Re: (4.3.0) r8152: deadlock related to runtime suspend?

[Peter Wu]

On Mon, Dec 07, 2015 at 05:11:50PM +0800, Lu Baolu wrote:
> Hi Peter,
> 
> Have you ever tried disabling auto-pm? Did things go smoothly if auto-pm is 
> disabled?
> 
> I always disable usb auto-pm in below way.
> 
> # echo on | tee /sys/bus/usb/devices/*/power/control
> # echo on > /sys/bus/pci/devices//power/control
> 
> Thanks,
> Baolu

Hi Baolu,

The deadlock does not seem to occur with auto-PM disabled, but that is a
workaround for the issue. The hang can always be reproduced under this
test:

 - Start a QEMU VM, passing through the USB adapter
 - This VM boots to a busybox shell with no other services running or
   udev magic (to reduce interference).
 - Enable runtime PM for all devices by default (see script below)
 - From the console, invoke "ip link set eth1 up" (eth0 is a virtio
   adapter).

# somewhere in /init after mounting filesystems
echo /sbin/hotplug > /proc/sys/kernel/hotplug
echo auto | tee  /sys/bus/pci/devices/*/power/control \
/sys/bus/usb/devices/*/power/control >/dev/null

#!/bin/sh
# /sbin/hotplug
path="/sys/$DEVPATH/power/control"
[ -e "$path" ] || return
newval=auto
read status < "$path"
if [ "x$status" != "x$newval" ]; then
echo "$DEVPATH: $status -> $newval" >/dev/kmsg
echo $newval > "$path"
fi

With "auto", the ip command hangs (a trace can be found on the bottom of
this mail). With "on", it does not.

If I keep a loop spinning that invokes `ethtool eth1`, the command
returns immediately without issues (presumably because the device is not
suspended through runtime PM).

Under some circumstances I get a lockdep warning (when trying to bring
an interface down if I remember correctly). Its trace can be found on
the bottom of this mail.

I'll keep testing. For the lockdep warning, my initial guess is that
calling schedule_delayed_work_sync under tp->lock is a bad idea because
scheduled work can execute and try to claim tp->lock too.

Maybe there are two different lockup cases here, I'll keep testing.

Kind regards,
Peter

> On 12/05/2015 06:59 PM, Peter Wu wrote:
> > Hi,
> >
> > I rarely use a Realtek USB 3.0 Gigabit Ethernet adapter (vid/pid
> > 0bda:8153), but when I did last night, it resulted in a lockup of
> > processes doing networking ("ip link", "ping", "ethtool", ...).
> >
> > A (few) minute(s) before that event, I noticed that there was no network
> > connectivity (ping hung) which was somehow solved by invoking "ethtool
> > eth1" (triggering runtime pm wakeup?). This same trick did not work at
> > the next event. Invoking "ethtool eth1", "ip link", etc. hung completely
> > and interrupt (^C) did not work at all.
> >
> > Since that did not work, I pulled the USB adapter and re-inserted it,
> > hoping it would reset things. That did not work at all, there was a
> > "usb disconnect" message, but no further driver messages.
> >
> > Fast forward an hour, and it has become a disaster. I have terminated
> > and killed many programs via SysRq but am still unable to get a stable
> > system that does not hang on network I/O. Even the suspend process
> > fails so in the end I attempted to shutdown the system. After half an
> > hour after getting the poweroff message, I issued SysRq + B to reboot
> > (since SysRq + O did not shut down either).
> >
> > Attached are logs with various various backtraces from SysRq and failed
> > suspend. Let me know if you need more information!
> >
> > By the way, often I have to rmmod xhci and re-insert it, otherwise
> > plugging it in does not result in a detection. A USB 2.0 port does not
> > have this problem (runtime PM is enabled for all devices). This is the
> > USB 3.0 port:
> >
> > 02:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0
> > Host Controller [1033:0194] (rev 03)
> 

-- 

lockdep splat from the bare machine:

==
[ INFO: possible circular locking dependency detected ]
4.3.0-custom #1 Tainted: G   O   
---
kworker/0:1/38 is trying to acquire lock:
 (&tp->control){+.+.+.}, at: [] rtl8152_resume+0x24/0x130 
[r8152]

but task is already holding lock:
 ((&(&tp->schedule)->work)){+.+.+.}, at: [] 
process_one_work+0x15c/0x660

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 ((&(&tp->schedule)->work)){+.+.+.}:

[] lock_acquire+0xc3/0x1d0
   [] flush_work+0x3d/0x290
   [] __cancel_work_timer+0xfe/0x1c0
   [] cancel_delayed_work_sync+0x13/0x20
   [] rtl8152_set_speed+0x2a/0x260 [r8152]
   [] rtl8152_open+0x396/0x4f0 [r8152]
   [] __dev_open+0xaf/0x120
   [] __dev_change_flags+0x9d/0x160
   [] dev_change_flags+0x29/0x70
   [] do_setlink+0x5ba/0xb00
   [] rtnl_newlink+0x5a9/0x8a0
   [] rtnetlink_rcv_msg+0x84/0x210
   [] netlink_rcv_skb+0x97/0xb0

Re: [PATCH] ARM: multi_v7_defconfig: Enable fan, sensors and audio for Odroid XU3

[Krzysztof Kozlowski]

On 07.12.2015 18:14, Arnd Bergmann wrote:
> On Monday 07 December 2015 09:59:54 Krzysztof Kozlowski wrote:
>> For Odroid XU3-family enable the:
>>  - PWM fan (to control the CPU fan using thermal subsystem),
>>  - TI INA231 sensors (provide power measurements of big.LITTLE cores,
>>DRAM and GPU),
>>  - Samsung sound (for Odroid XU3 and Snow as well).
>>
>> Signed-off-by: Krzysztof Kozlowski 
>>
> 
> Looks good. Do you have a samsung/defconfig branch already that you
> can put this into, or should be pick it up into arm-soc directly?
> 
> My preference is the former, but it would be a bit silly if that
> is the only samsung defconfig change we need.

I had a couple of defconfig patches in my queue but I sent them last
week to Kukjin in pull request. He didn't pull it yet. Maybe he could
apply this patch after pulling?

Anyway we can wait for a few days to sort it out. If I don't have
another defconfig patches then I will remind myself with applying it to
arm-soc.

Best regards,
Krzysztof

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

[PATCH 0/4] x86/cpufeature: Cleanup, p1

[Borislav Petkov]

From: Borislav Petkov 

Hi,

this is the first and the easiest part of the cleanup - getting rid of
the unused and seldomly used cpu_has_xx uglies. Future work will get rid
of the remaining ones but they need more careful inspection first.

The last patch helps with tinyconfig and slims it down by ~1.5K,
according to 0day numbers:

i386-tinyconfig vmlinux size:

+---+--+--+-+-+
| TOTAL | TEXT | DATA | BSS |   
  |
+---+--+--+-+-+
| -1512 | -352 |0 |   0 | df63d2e25f80 x86/cpu: Provide a config option to 
disable static_cpu_has |
|+5 |0 |0 |   0 | 8b9e9097bf18 Merge remote-tracking branch 
'tip/x86/cleanups' into cpufeature-v3 |
| -1507 | -352 |0 |   0 | ALL COMMITS   
  |
+---+--+--+-+-+

Stuff is ontop of tip/x86/cleanups because it needs

  ed29210cd6a6 ("x86: Remove unused function cpu_has_ht_siblings()")


Thanks.

Borislav Petkov (4):
  x86/cpufeature: Move some of the scattered feature bits to x86_capability
  x86/cpufeature: Cleanup get_cpu_cap()
  x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros
  x86/cpu: Provide a config option to disable static_cpu_has

 arch/x86/Kconfig|  11 +++
 arch/x86/crypto/chacha20_glue.c |   2 +-
 arch/x86/crypto/crc32c-intel_glue.c |   2 +-
 arch/x86/include/asm/cmpxchg_32.h   |   2 +-
 arch/x86/include/asm/cmpxchg_64.h   |   2 +-
 arch/x86/include/asm/cpufeature.h   | 115 ++--
 arch/x86/include/asm/xor_32.h   |   2 +-
 arch/x86/kernel/cpu/amd.c   |   4 +-
 arch/x86/kernel/cpu/centaur.c   |   2 +-
 arch/x86/kernel/cpu/common.c|  52 +++--
 arch/x86/kernel/cpu/intel.c |   3 +-
 arch/x86/kernel/cpu/intel_cacheinfo.c   |   6 +-
 arch/x86/kernel/cpu/mtrr/generic.c  |   2 +-
 arch/x86/kernel/cpu/mtrr/main.c |   2 +-
 arch/x86/kernel/cpu/perf_event_amd.c|   4 +-
 arch/x86/kernel/cpu/perf_event_amd_uncore.c |  11 +--
 arch/x86/kernel/cpu/scattered.c |  20 -
 arch/x86/kernel/cpu/transmeta.c |   4 +-
 arch/x86/kernel/fpu/init.c  |   4 +-
 arch/x86/kernel/hw_breakpoint.c |   6 +-
 arch/x86/kernel/smpboot.c   |   2 +-
 arch/x86/kernel/vm86_32.c   |   4 +-
 arch/x86/mm/setup_nx.c  |   4 +-
 drivers/char/hw_random/via-rng.c|   5 +-
 drivers/crypto/padlock-aes.c|   2 +-
 drivers/crypto/padlock-sha.c|   2 +-
 drivers/iommu/intel_irq_remapping.c |   2 +-
 fs/btrfs/disk-io.c  |   2 +-
 28 files changed, 141 insertions(+), 138 deletions(-)

-- 
2.3.5

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

[PATCH 3/4] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

[Borislav Petkov]

From: Borislav Petkov 

Those are stupid and code should use static_cpu_has_safe() or
boot_cpu_has() instead. Kill the least used and unused ones.

The remaining ones need more careful inspection before a conversion can
happen. On the TODO.

Signed-off-by: Borislav Petkov 
Cc: David Sterba 
Cc: Herbert Xu 
Cc: Peter Zijlstra 
Cc: Matt Mackall 
Cc: Chris Mason 
Cc: Josef Bacik 
Signed-off-by: Borislav Petkov 
---
 arch/x86/crypto/chacha20_glue.c |  2 +-
 arch/x86/crypto/crc32c-intel_glue.c |  2 +-
 arch/x86/include/asm/cmpxchg_32.h   |  2 +-
 arch/x86/include/asm/cmpxchg_64.h   |  2 +-
 arch/x86/include/asm/cpufeature.h   | 37 -
 arch/x86/include/asm/xor_32.h   |  2 +-
 arch/x86/kernel/cpu/amd.c   |  4 ++--
 arch/x86/kernel/cpu/common.c|  4 +++-
 arch/x86/kernel/cpu/intel.c |  3 ++-
 arch/x86/kernel/cpu/intel_cacheinfo.c   |  6 ++---
 arch/x86/kernel/cpu/mtrr/generic.c  |  2 +-
 arch/x86/kernel/cpu/mtrr/main.c |  2 +-
 arch/x86/kernel/cpu/perf_event_amd.c|  4 ++--
 arch/x86/kernel/cpu/perf_event_amd_uncore.c | 11 +
 arch/x86/kernel/fpu/init.c  |  4 ++--
 arch/x86/kernel/hw_breakpoint.c |  6 +++--
 arch/x86/kernel/smpboot.c   |  2 +-
 arch/x86/kernel/vm86_32.c   |  4 +++-
 arch/x86/mm/setup_nx.c  |  4 ++--
 drivers/char/hw_random/via-rng.c|  5 ++--
 drivers/crypto/padlock-aes.c|  2 +-
 drivers/crypto/padlock-sha.c|  2 +-
 drivers/iommu/intel_irq_remapping.c |  2 +-
 fs/btrfs/disk-io.c  |  2 +-
 24 files changed, 48 insertions(+), 68 deletions(-)

diff --git a/arch/x86/crypto/chacha20_glue.c b/arch/x86/crypto/chacha20_glue.c
index 722bacea040e..8baaff5af0b5 100644
--- a/arch/x86/crypto/chacha20_glue.c
+++ b/arch/x86/crypto/chacha20_glue.c
@@ -125,7 +125,7 @@ static struct crypto_alg alg = {
 
 static int __init chacha20_simd_mod_init(void)
 {
-   if (!cpu_has_ssse3)
+   if (!boot_cpu_has(X86_FEATURE_SSSE3))
return -ENODEV;
 
 #ifdef CONFIG_AS_AVX2
diff --git a/arch/x86/crypto/crc32c-intel_glue.c 
b/arch/x86/crypto/crc32c-intel_glue.c
index 81a595d75cf5..0e9871693f24 100644
--- a/arch/x86/crypto/crc32c-intel_glue.c
+++ b/arch/x86/crypto/crc32c-intel_glue.c
@@ -257,7 +257,7 @@ static int __init crc32c_intel_mod_init(void)
if (!x86_match_cpu(crc32c_cpu_id))
return -ENODEV;
 #ifdef CONFIG_X86_64
-   if (cpu_has_pclmulqdq) {
+   if (boot_cpu_has(X86_FEATURE_PCLMULQDQ)) {
alg.update = crc32c_pcl_intel_update;
alg.finup = crc32c_pcl_intel_finup;
alg.digest = crc32c_pcl_intel_digest;
diff --git a/arch/x86/include/asm/cmpxchg_32.h 
b/arch/x86/include/asm/cmpxchg_32.h
index f7e142926481..e4959d023af8 100644
--- a/arch/x86/include/asm/cmpxchg_32.h
+++ b/arch/x86/include/asm/cmpxchg_32.h
@@ -109,6 +109,6 @@ static inline u64 __cmpxchg64_local(volatile u64 *ptr, u64 
old, u64 new)
 
 #endif
 
-#define system_has_cmpxchg_double() cpu_has_cx8
+#define system_has_cmpxchg_double() boot_cpu_has(X86_FEATURE_CX8)
 
 #endif /* _ASM_X86_CMPXCHG_32_H */
diff --git a/arch/x86/include/asm/cmpxchg_64.h 
b/arch/x86/include/asm/cmpxchg_64.h
index 1af94697aae5..caa23a34c963 100644
--- a/arch/x86/include/asm/cmpxchg_64.h
+++ b/arch/x86/include/asm/cmpxchg_64.h
@@ -18,6 +18,6 @@ static inline void set_64bit(volatile u64 *ptr, u64 val)
cmpxchg_local((ptr), (o), (n)); \
 })
 
-#define system_has_cmpxchg_double() cpu_has_cx16
+#define system_has_cmpxchg_double() boot_cpu_has(X86_FEATURE_CX16)
 
 #endif /* _ASM_X86_CMPXCHG_64_H */
diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index 35401fef0d75..144b042c0872 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -385,58 +385,29 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
 } while (0)
 
 #define cpu_has_fpuboot_cpu_has(X86_FEATURE_FPU)
-#define cpu_has_de boot_cpu_has(X86_FEATURE_DE)
 #define cpu_has_pseboot_cpu_has(X86_FEATURE_PSE)
 #define cpu_has_tscboot_cpu_has(X86_FEATURE_TSC)
 #define cpu_has_pgeboot_cpu_has(X86_FEATURE_PGE)
 #define cpu_has_apic   boot_cpu_has(X86_FEATURE_APIC)
-#define cpu_has_sepboot_cpu_has(X86_FEATURE_SEP)
-#define cpu_has_mtrr   boot_cpu_has(X86_FEATURE_MTRR)
-#define cpu_has_mmxboot_cpu_has(X86_FEATURE_MMX)
 #define cpu_has_fxsr   boot_cpu_has(X86_FEATURE_FXSR)
 #define cpu_has_xmmboot_cpu_has(X86_FEATURE_XMM)
 #define cpu_has_xmm2   boot_cpu_has(X86_FEATURE_XMM2)
-#define cpu_has_xmm3   boot_cpu_has(X86_FEATURE_XMM3)
-#define cpu_has_ssse3  boot_cpu_has(X86_FEATURE_SSSE3)
 #d

Re: [PATCH v7 2/6] mfd: syscon: add a DT property to set value width

[Lee Jones]

On Mon, 30 Nov 2015, Damien Riegel wrote:

> Currently syscon has a fixed configuration of 32 bits for register and
> values widths. In some cases, it would be desirable to be able to
> customize the value width.
> 
> For example, certain boards (like the ones manufactured by Technologic
> Systems) have a FPGA that is memory-mapped, but its registers are only
> 16-bit wide.
> 
> This patch adds an optional "reg-io-width" DT binding for syscon that
> allows to change the width for the data bus (i.e. val_bits). If this
> property is provided, it will also set the register stride to
> reg-io-width's value. If not provided, the default configuration is
> used.
> 
> Signed-off-by: Damien Riegel 
> ---
>  Documentation/devicetree/bindings/mfd/syscon.txt |  4 
>  drivers/mfd/syscon.c | 13 +
>  2 files changed, 17 insertions(+)

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt 
> b/Documentation/devicetree/bindings/mfd/syscon.txt
> index fe8150b..408f768 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> @@ -13,6 +13,10 @@ Required properties:
>  - compatible: Should contain "syscon".
>  - reg: the register region can be accessed from syscon
>  
> +Optional property:
> +- reg-io-width: the size (in bytes) of the IO accesses that should be
> +  performed on the device.
> +
>  Examples:
>  gpr: iomuxc-gpr@020e {
>   compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 176bf0f..b7aabee 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -47,6 +47,7 @@ static struct syscon *of_syscon_register(struct device_node 
> *np)
>   struct syscon *syscon;
>   struct regmap *regmap;
>   void __iomem *base;
> + u32 reg_io_width;
>   int ret;
>   struct regmap_config syscon_config = syscon_regmap_config;
>  
> @@ -69,6 +70,18 @@ static struct syscon *of_syscon_register(struct 
> device_node *np)
>else if (of_property_read_bool(np, "little-endian"))
>   syscon_config.val_format_endian = REGMAP_ENDIAN_LITTLE;
>  
> + /*
> +  * search for reg-io-width property in DT. If it is not provided,
> +  * default to 4 bytes. regmap_init_mmio will return an error if values
> +  * are invalid so there is no need to check them here.
> +  */
> + ret = of_property_read_u32(np, "reg-io-width", ®_io_width);
> + if (ret)
> + reg_io_width = 4;
> +
> + syscon_config.reg_stride = reg_io_width;
> + syscon_config.val_bits = reg_io_width * 8;
> +
>   regmap = regmap_init_mmio(NULL, base, &syscon_config);
>   if (IS_ERR(regmap)) {
>   pr_err("regmap init failed\n");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] x86/cpufeature: Move some of the scattered feature bits to x86_capability

[Borislav Petkov]

From: Borislav Petkov 

Turn the CPUID leafs which are proper CPUID feature bit leafs into
separate ->x86_capability words.

Signed-off-by: Borislav Petkov 
---
 arch/x86/include/asm/cpufeature.h | 54 +++
 arch/x86/kernel/cpu/common.c  |  5 
 arch/x86/kernel/cpu/scattered.c   | 20 ---
 3 files changed, 37 insertions(+), 42 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index e4f8010f22e0..13d78e0e6ae0 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -12,7 +12,7 @@
 #include 
 #endif
 
-#define NCAPINTS   14  /* N 32-bit words worth of info */
+#define NCAPINTS   16  /* N 32-bit words worth of info */
 #define NBUGINTS   1   /* N 32-bit bug flags */
 
 /*
@@ -181,22 +181,17 @@
 
 /*
  * Auxiliary flags: Linux defined - For features scattered in various
- * CPUID levels like 0x6, 0xA etc, word 7
+ * CPUID levels like 0x6, 0xA etc, word 7.
+ *
+ * Reuse free bits when adding new feature flags!
  */
-#define X86_FEATURE_IDA( 7*32+ 0) /* Intel Dynamic 
Acceleration */
-#define X86_FEATURE_ARAT   ( 7*32+ 1) /* Always Running APIC Timer */
+
 #define X86_FEATURE_CPB( 7*32+ 2) /* AMD Core Performance 
Boost */
 #define X86_FEATURE_EPB( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS 
support */
-#define X86_FEATURE_PLN( 7*32+ 5) /* Intel Power Limit 
Notification */
-#define X86_FEATURE_PTS( 7*32+ 6) /* Intel Package Thermal 
Status */
-#define X86_FEATURE_DTHERM ( 7*32+ 7) /* Digital Thermal Sensor */
+
 #define X86_FEATURE_HW_PSTATE  ( 7*32+ 8) /* AMD HW-PState */
 #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
-#define X86_FEATURE_HWP( 7*32+ 10) /* "hwp" Intel HWP */
-#define X86_FEATURE_HWP_NOTIFY ( 7*32+ 11) /* Intel HWP_NOTIFY */
-#define X86_FEATURE_HWP_ACT_WINDOW ( 7*32+ 12) /* Intel HWP_ACT_WINDOW */
-#define X86_FEATURE_HWP_EPP( 7*32+13) /* Intel HWP_EPP */
-#define X86_FEATURE_HWP_PKG_REQ ( 7*32+14) /* Intel HWP_PKG_REQ */
+
 #define X86_FEATURE_INTEL_PT   ( 7*32+15) /* Intel Processor Trace */
 
 /* Virtualization flags: Linux defined, word 8 */
@@ -205,16 +200,7 @@
 #define X86_FEATURE_FLEXPRIORITY ( 8*32+ 2) /* Intel FlexPriority */
 #define X86_FEATURE_EPT ( 8*32+ 3) /* Intel Extended Page Table */
 #define X86_FEATURE_VPID( 8*32+ 4) /* Intel Virtual Processor ID */
-#define X86_FEATURE_NPT( 8*32+ 5) /* AMD Nested Page Table 
support */
-#define X86_FEATURE_LBRV   ( 8*32+ 6) /* AMD LBR Virtualization support */
-#define X86_FEATURE_SVML   ( 8*32+ 7) /* "svm_lock" AMD SVM locking MSR */
-#define X86_FEATURE_NRIPS  ( 8*32+ 8) /* "nrip_save" AMD SVM next_rip save 
*/
-#define X86_FEATURE_TSCRATEMSR  ( 8*32+ 9) /* "tsc_scale" AMD TSC scaling 
support */
-#define X86_FEATURE_VMCBCLEAN   ( 8*32+10) /* "vmcb_clean" AMD VMCB clean bits 
support */
-#define X86_FEATURE_FLUSHBYASID ( 8*32+11) /* AMD flush-by-ASID support */
-#define X86_FEATURE_DECODEASSISTS ( 8*32+12) /* AMD Decode Assists support */
-#define X86_FEATURE_PAUSEFILTER ( 8*32+13) /* AMD filtered pause intercept */
-#define X86_FEATURE_PFTHRESHOLD ( 8*32+14) /* AMD pause filter threshold */
+
 #define X86_FEATURE_VMMCALL ( 8*32+15) /* Prefer vmmcall to vmcall */
 
 
@@ -258,6 +244,30 @@
 /* AMD-defined CPU features, CPUID level 0x8008 (ebx), word 13 */
 #define X86_FEATURE_CLZERO (13*32+0) /* CLZERO instruction */
 
+/* Thermal and Power Management Leaf, CPUID level 0x0006 (eax), word 14 */
+#define X86_FEATURE_DTHERM (14*32+ 0) /* Digital Thermal Sensor */
+#define X86_FEATURE_IDA(14*32+ 1) /* Intel Dynamic 
Acceleration */
+#define X86_FEATURE_ARAT   (14*32+ 2) /* Always Running APIC Timer */
+#define X86_FEATURE_PLN(14*32+ 4) /* Intel Power Limit 
Notification */
+#define X86_FEATURE_PTS(14*32+ 6) /* Intel Package Thermal 
Status */
+#define X86_FEATURE_HWP(14*32+ 7) /* Intel Hardware P-states */
+#define X86_FEATURE_HWP_NOTIFY (14*32+ 8) /* HWP Notification */
+#define X86_FEATURE_HWP_ACT_WINDOW (14*32+ 9) /* HWP Activity Window */
+#define X86_FEATURE_HWP_EPP(14*32+10) /* HWP Energy Perf. Preference */
+#define X86_FEATURE_HWP_PKG_REQ (14*32+11) /* HWP Package Level Request */
+
+/* AMD SVM Feature Identification, CPUID level 0x800a (edx), word 15 */
+#define X86_FEATURE_NPT(15*32+ 0) /* Nested Page Table support 
*/
+#define X86_FEATURE_LBRV   (15*32+ 1) /* LBR Virtualization support */
+#define X86_FEATURE_SVML   (15*32+ 2) /* "svm_lock" SVM locking MSR */
+#define X86_FEATURE_NRIPS  (15*32+ 3) /* "nrip_save" SVM next_rip save */
+#define X86_FEATURE_TSCRATEMSR  (15*32+ 4) /* "tsc_scale" TSC scaling support 
*/
+#define X86_FEATURE_VMCBCLEAN   (15*32+ 5) /* "vmcb_clean" VMCB clean bi

[PATCH 2/4] x86/cpufeature: Cleanup get_cpu_cap()

[Borislav Petkov]

From: Borislav Petkov 

Add an enum for the ->x86_capability array indices and cleanup
get_cpu_cap() by killing some redundant local vars.

Signed-off-by: Borislav Petkov 
---
 arch/x86/include/asm/cpufeature.h | 20 +
 arch/x86/kernel/cpu/centaur.c |  2 +-
 arch/x86/kernel/cpu/common.c  | 47 ++-
 arch/x86/kernel/cpu/transmeta.c   |  4 ++--
 4 files changed, 45 insertions(+), 28 deletions(-)

diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index 13d78e0e6ae0..35401fef0d75 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -288,6 +288,26 @@
 #include 
 #include 
 
+enum cpuid_leafs
+{
+   CPUID_1_EDX = 0,
+   CPUID_8000_0001_EDX,
+   CPUID_8086_0001_EDX,
+   CPUID_LNX_1,
+   CPUID_1_ECX,
+   CPUID_C000_0001_EDX,
+   CPUID_8000_0001_ECX,
+   CPUID_LNX_2,
+   CPUID_LNX_3,
+   CPUID_7_0_EBX,
+   CPUID_D_1_EAX,
+   CPUID_F_0_EDX,
+   CPUID_F_1_EDX,
+   CPUID_8000_0008_EBX,
+   CPUID_6_EAX,
+   CPUID_8000_000A_EDX,
+};
+
 #ifdef CONFIG_X86_FEATURE_NAMES
 extern const char * const x86_cap_flags[NCAPINTS*32];
 extern const char * const x86_power_flags[32];
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index d8fba5c15fbd..ae20be6e483c 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -43,7 +43,7 @@ static void init_c3(struct cpuinfo_x86 *c)
/* store Centaur Extended Feature Flags as
 * word 5 of the CPU capability bit array
 */
-   c->x86_capability[5] = cpuid_edx(0xC001);
+   c->x86_capability[CPUID_C000_0001_EDX] = cpuid_edx(0xC001);
}
 #ifdef CONFIG_X86_32
/* Cyrix III family needs CX8 & PGE explicitly enabled. */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c75517331989..e14d5bd8671f 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -599,52 +599,47 @@ void cpu_detect(struct cpuinfo_x86 *c)
 
 void get_cpu_cap(struct cpuinfo_x86 *c)
 {
-   u32 tfms, xlvl;
-   u32 ebx;
+   u32 eax, ebx, ecx, edx;
 
/* Intel-defined flags: level 0x0001 */
if (c->cpuid_level >= 0x0001) {
-   u32 capability, excap;
+   cpuid(0x0001, &eax, &ebx, &ecx, &edx);
 
-   cpuid(0x0001, &tfms, &ebx, &excap, &capability);
-   c->x86_capability[0] = capability;
-   c->x86_capability[4] = excap;
+   c->x86_capability[CPUID_1_ECX] = ecx;
+   c->x86_capability[CPUID_1_EDX] = edx;
}
 
/* Additional Intel-defined flags: level 0x0007 */
if (c->cpuid_level >= 0x0007) {
-   u32 eax, ebx, ecx, edx;
-
cpuid_count(0x0007, 0, &eax, &ebx, &ecx, &edx);
 
-   c->x86_capability[9] = ebx;
+   c->x86_capability[CPUID_7_0_EBX] = ebx;
 
-   c->x86_capability[14] = cpuid_eax(0x0006);
+   c->x86_capability[CPUID_6_EAX] = cpuid_eax(0x0006);
}
 
/* Extended state features: level 0x000d */
if (c->cpuid_level >= 0x000d) {
-   u32 eax, ebx, ecx, edx;
-
cpuid_count(0x000d, 1, &eax, &ebx, &ecx, &edx);
 
-   c->x86_capability[10] = eax;
+   c->x86_capability[CPUID_D_1_EAX] = eax;
}
 
/* Additional Intel-defined flags: level 0x000F */
if (c->cpuid_level >= 0x000F) {
-   u32 eax, ebx, ecx, edx;
 
/* QoS sub-leaf, EAX=0Fh, ECX=0 */
cpuid_count(0x000F, 0, &eax, &ebx, &ecx, &edx);
-   c->x86_capability[11] = edx;
+   c->x86_capability[CPUID_F_0_EDX] = edx;
+
if (cpu_has(c, X86_FEATURE_CQM_LLC)) {
/* will be overridden if occupancy monitoring exists */
c->x86_cache_max_rmid = ebx;
 
/* QoS sub-leaf, EAX=0Fh, ECX=1 */
cpuid_count(0x000F, 1, &eax, &ebx, &ecx, &edx);
-   c->x86_capability[12] = edx;
+   c->x86_capability[CPUID_F_1_EDX] = edx;
+
if (cpu_has(c, X86_FEATURE_CQM_OCCUP_LLC)) {
c->x86_cache_max_rmid = ecx;
c->x86_cache_occ_scale = ebx;
@@ -656,22 +651,24 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
}
 
/* AMD-defined flags: level 0x8001 */
-   xlvl = cpuid_eax(0x8000);
-   c->extended_cpuid_level = xlvl;
+   eax = cpuid_eax(0x8000);
+   c->extended_cpuid_level = eax;
+
+   if ((eax & 0x) == 0x8000) {
+   if (eax >= 0x8001) {
+   cpuid(0x8001, &eax, &ebx, &ecx, &edx);
 
-   if ((

arRe: [PATCH net-next 2/2] net: hns: enet specisies a reference to dsaf (config and documents)

[Arnd Bergmann]

On Monday 07 December 2015 15:14:13 Yankejian wrote:
> On 2015/12/6 6:19, Arnd Bergmann wrote:
> > On Saturday 05 December 2015 14:10:56 yankejian wrote:
> >> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt 
> >> b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> >> index 80411b2..ecacfa4 100644
> >> --- a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> >> +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> >> @@ -4,8 +4,6 @@ Required properties:
> >>  - compatible: should be "hisilicon,hns-dsaf-v1" or 
> >> "hisilicon,hns-dsaf-v2".
> >>"hisilicon,hns-dsaf-v1" is for hip05.
> >>"hisilicon,hns-dsaf-v2" is for Hi1610 and Hi1612.
> >> -- dsa-name: dsa fabric name who provide this interface.
> >> -  should be "dsafX", X is the dsaf id.
> >>  - mode: dsa fabric mode string. only support one of dsaf modes like these:
> >> "2port-64vf",
> >> "6port-16rss",
> >> @@ -26,9 +24,8 @@ Required properties:
> >>  
> >>  Example:
> >>  
> >> -dsa: dsa@c700 {
> >> +dsaf0: dsa@c700 {
> >> compatible = "hisilicon,hns-dsaf-v1";
> >> -   dsa_name = "dsaf0";
> >> mode = "6port-16rss";
> >> interrupt-parent = <&mbigen_dsa>;
> >> reg = <0x0 0xC000 0x0 0x42
> >> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt 
> >> b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
> >> index 41d19be..e6a9d1c 100644
> >> --- a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
> >> +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
> >> @@ -4,8 +4,9 @@ Required properties:
> >>  - compatible: "hisilicon,hns-nic-v1" or "hisilicon,hns-nic-v2".
> >>"hisilicon,hns-nic-v1" is for hip05.
> >>"hisilicon,hns-nic-v2" is for Hi1610 and Hi1612.
> >> -- ae-name: accelerator name who provides this interface,
> >> -  is simply a name referring to the name of name in the accelerator node.
> >> +- ae-handle: accelerator engine handle for hns,
> >> +  specifies a reference to the associating hardware driver node.
> >> +  see Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> >>  - port-id: is the index of port provided by DSAF (the accelerator). DSAF 
> >> can
> >>connect to 8 PHYs. Port 0 to 1 are both used for adminstration purpose. 
> >> They
> >>are called debug ports.
> >> @@ -41,7 +42,7 @@ Example:
> >>  
> >>
> > This looks like an incompatible change, as you add and remove
> > required properties. Is there a way to support both the old and
> > the new style?
> >
> >   Arnd
> >
> > .
> 
> Hi Arnd,
> Thanks for your suggestions.  it must be set the same strings in dsaf node 
> and every enet node before.
> it seems inappropriate. as Rob Herring  's suggestions, that 
> would solve associating
> enet with a particular dsaf. so we discus the solution with Yisen Zhuang 
> .
> we decide to use the new way instead of the old one.

I agree the new form looks better than the original way, but I'm worried
about the migration path. You don't explain in the patch description
how you want to ensure that nothing breaks for existing systems.

We generally try to avoid doing incompatible changes altogether and
prefer to keep backwards compatibility, unless we can prove that no
other systems exist that would get impacted by the change.

Are you sure that nobody ships a DTB file for this hardware with their
firmware that would now require an incompatible update which in turn
breaks old kernels?

Are you sure that there is no hardware using the same dsa hardware
with out-of-tree dts files that need to make the same change but might
not be aware of the change?

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

Re: Non-ascii mantainers

[Michal Suchanek]

On 7 December 2015 at 10:18, Geert Uytterhoeven  wrote:
> Hi Michael,
>
> On Tue, Dec 1, 2015 at 6:27 PM, Michal Suchanek  wrote:
>> On 1 December 2015 at 18:20, Al Viro  wrote:
>>> On Tue, Dec 01, 2015 at 06:10:29PM +0100, Michal Suchanek wrote:
 there are non-ascii characters in output of scripts/get_maintainer.pl

 If output of said script is used as --to in git format-patch the patch
 is rejected by this list.
>>>
>>> Try to reproduce that in a UTF8 locale...
>>
>> I am using UTF-8 locale since ages.
>>
>> The characters show correctly in my terminal. I have no problem with
>> that. The e-mail is then just rejected by the list server.
>>
>> I don't really care if the maintainers are encoded or whatever.
>> However, neither get_maintainers nor git format-patch encodes them and
>> the listserver rejects them when not encoded.
>
> I always pass the --to and --cc to git send-email, not to format-patch, and
> that works:
>
> git send-email \
> --to "Måns Rullgård " \
> --to "David S. Miller " \
> --cc "net...@vger.kernel.org" \
> --cc "linux-kernel@vger.kernel.org" \
> *00*
>
> becomes:
>
> From: Geert Uytterhoeven 
> To: =?UTF-8?q?M=C3=A5ns=20Rullg=C3=A5rd?= ,
> "David S. Miller" 
> Cc: net...@vger.kernel.org,
> linux-kernel@vger.kernel.org,
> Geert Uytterhoeven 
> Subject: [PATCH] ethernet: aurora: AURORA_NB8800 should depend on HAS_DMA
> Date: Mon,  7 Dec 2015 10:09:06 +0100
> Message-Id: <1449479346-32601-1-git-send-email-ge...@linux-m68k.org>
> X-Mailer: git-send-email 1.9.1
>

I don't use git send-email because I do not have access to a working
SMTP server directly.

There is an option to use a sendmail binary instead of a SMTP server
address so I can try faking that I guess.

Thanks

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

[PATCH 4/4] x86/cpu: Provide a config option to disable static_cpu_has

[Borislav Petkov]

From: Borislav Petkov 

This brings .text savings of about ~1.6K when building a tinyconfig. It
is off by default so nothing changes for the default.

Kconfig help text from Josh.

Reviewed-by: Josh Triplett 
Signed-off-by: Borislav Petkov 
---
 arch/x86/Kconfig  | 11 +++
 arch/x86/include/asm/cpufeature.h |  2 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index db3622f22b61..a2abc2fb6970 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -349,6 +349,17 @@ config X86_FEATURE_NAMES
 
  If in doubt, say Y.
 
+config X86_FAST_FEATURE_TESTS
+   bool "Fast CPU feature tests" if EMBEDDED
+   default y
+   ---help---
+ Some fast-paths in the kernel depend on the capabilities of the CPU.
+ Say Y here for the kernel to patch in the appropriate code at runtime
+ based on the capabilities of the CPU. The infrastructure for patching
+ code at runtime takes up some additional space; space-constrained
+ embedded systems may wish to say N here to produce smaller, slightly
+ slower code.
+
 config X86_X2APIC
bool "Support x2apic"
depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index 144b042c0872..43e144474043 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -409,7 +409,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
  * fast paths and boot_cpu_has() otherwise!
  */
 
-#if __GNUC__ >= 4
+#if __GNUC__ >= 4 && defined(CONFIG_X86_FAST_FEATURE_TESTS)
 extern void warn_pre_alternatives(void);
 extern bool __static_cpu_has_safe(u16 bit);
 
-- 
2.3.5

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

Re: [PATCH v5 08/11] spi: imx: allow only WML aligned transfers to use DMA

[Sascha Hauer]

On Sat, Dec 05, 2015 at 05:57:06PM +0100, Anton Bondarenko wrote:
> RX DMA tail data handling doesn't work correctly in many cases with current
> implementation. It happens because SPI core was setup to generates both RX
> and RX TAIL events. And RX TAIL event does not work correctly.
> This can be easily verified by sending SPI transaction with size modulus
> WML(32 in our case) not equal 0.
> 
> Also removing change introduced in f6ee9b582d2db652497b73c1f117591dfb6d3a90
> since this change only fix usecases with transfer size from 33 to 128 bytes
> and does not fix 129 bytes etc.
> 
> This is output from transaction with len 138 bytes in loopback mode at 10Mhz:
> TX: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
> TX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
> TX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
> TX0030: 5f 3c 35 b5 c4 8c dd 6c 11 32 3d e2 b4 b4 59 cf
> TX0040: ce 23 3d 27 df a7 f9 96 fc 1e e0 66 2c 0e 7b 8c
> TX0050: ca 30 42 8f bc 9f 7b ce d1 b8 b1 87 ec 8a d6 bb
> TX0060: 2e 15 63 0e 3c dc a4 3a 7a 06 20 a7 93 1b 34 dd
> TX0070: 4c f5 ec 88 96 68 d6 68 a0 09 6f 8e 93 47 c9 41
> TX0080: db ac cf 97 89 f3 51 05 79 71
> 
> RX: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
> RX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
> RX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
> RX0030: 5f 3c 35 00 00 b5 00 00 00 c4 00 00 8c 00 00 dd
> RX0040: 6c 11 32 3d e2 b4 b4 59 cf ce 23 3d 27 df a7 f9
> RX0050: 96 fc 1e e0 66 2c 0e 7b 8c ca 30 42 8f 1f 1f bc
> RX0060: 9f 7b ce d1 b8 b1 87 ec 8a d6 bb 2e 15 63 0e ed
> RX0070: ed 3c 58 58 58 dc 3d 3d a4 6a 6a 3a 52 52 7a 36
> RX0080: 06 20 a7 93 1b 34 dd 4c f5 ec
> 
> Zeros at offset 33 and 34 caused by reading empty RX FIFO which not possible
> if DMA RX read was triggered by RX event. This mean DMA was triggered
> by RX TAIL event.
> 
> Signed-off-by: Anton Bondarenko 
> ---
>  drivers/spi/spi-imx.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index fa24637..7a68c62 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -204,8 +204,8 @@ static bool spi_imx_can_dma(struct spi_master *master, 
> struct spi_device *spi,
>  {
>   struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
>  
> - if (spi_imx->dma_is_inited &&
> - transfer->len > spi_imx->wml * sizeof(u32))
> + if (spi_imx->dma_is_inited && transfer->len > spi_imx->wml &&
> + (transfer->len % spi_imx->wml) == 0)
>   return true;

Must transfer->len really be bigger than spi_imx->wml? I would assume it
should be >= instead. And where is the * sizeof(u32) gone? If that's
unnecessary I heven't understood why.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: multi_v7_defconfig: Enable fan, sensors and audio for Odroid XU3

[Arnd Bergmann]

On Monday 07 December 2015 18:38:44 Krzysztof Kozlowski wrote:
> On 07.12.2015 18:14, Arnd Bergmann wrote:
> > On Monday 07 December 2015 09:59:54 Krzysztof Kozlowski wrote:
> >> For Odroid XU3-family enable the:
> >>  - PWM fan (to control the CPU fan using thermal subsystem),
> >>  - TI INA231 sensors (provide power measurements of big.LITTLE cores,
> >>DRAM and GPU),
> >>  - Samsung sound (for Odroid XU3 and Snow as well).
> >>
> >> Signed-off-by: Krzysztof Kozlowski 
> >>
> > 
> > Looks good. Do you have a samsung/defconfig branch already that you
> > can put this into, or should be pick it up into arm-soc directly?
> > 
> > My preference is the former, but it would be a bit silly if that
> > is the only samsung defconfig change we need.
> 
> I had a couple of defconfig patches in my queue but I sent them last
> week to Kukjin in pull request. He didn't pull it yet. Maybe he could
> apply this patch after pulling?
> 
> Anyway we can wait for a few days to sort it out. If I don't have
> another defconfig patches then I will remind myself with applying it to
> arm-soc.
> 

Ok, sounds good.

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

Re: [PATCH 3/4] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

[Ingo Molnar]

* Borislav Petkov  wrote:

>  static int __init chacha20_simd_mod_init(void)
>  {
> - if (!cpu_has_ssse3)
> + if (!boot_cpu_has(X86_FEATURE_SSSE3))
>   return -ENODEV;

Btw., could we rename 'boot_cpu_has()' to the more appropriate (and shorter!) 
'system_has()' form?

'boot cpu' is a conceptual misnomer here really: it's just an implementational 
detail that we are looking at the boot CPU's flags, what we really mean to 
express 
is that these are system-wide features with no per-cpu properties.

Agreed?

Thanks,

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

Re: [PATCH v2 3/9] ARM: hisi: enable Hi3519 soc

[Arnd Bergmann]

On Monday 07 December 2015 14:58:14 xuejiancheng wrote:
> On 2015/12/5 5:54, Arnd Bergmann wrote:
> > On Friday 04 December 2015 12:07:58 xuejiancheng wrote:
> >> On 2015/12/3 17:40, Arnd Bergmann wrote:
> >>> On Thursday 03 December 2015 10:42:45 Jiancheng Xue wrote:
>  --- a/arch/arm/mach-hisi/Kconfig
>  +++ b/arch/arm/mach-hisi/Kconfig
>  @@ -12,6 +12,14 @@ if ARCH_HISI
>   
>   menu "Hisilicon platform type"
>   
>  +config ARCH_HI3519
>  +   bool "Hisilicon Hi3519 Soc" if ARCH_MULTI_V7
>  +   select HAVE_ARM_ARCH_TIMER
>  +   select ARCH_HAS_RESET_CONTROLLER
>  +
>  +   help
>  + Support for Hisilicon Hi3519 Soc
>  +
>   config ARCH_HI3xxx
>  bool "Hisilicon Hi36xx family" if ARCH_MULTI_V7
>  select CACHE_L2X0
> >>>
> >>> Do those need to be separate? I would just extend the Hi36xx
> >>> to cover all Hi3xxx, if nothing in the platform code really
> >>> depends on this.
> >>
> >> For HI3519, there is really no special platform code. But HI35xx and 
> >> HI36xx soc families
> >> belong to different product lines in hisilicon. HI35xx family also 
> >> composes of various
> >> architectures socs(single core, smp and big-little). So I think it may be 
> >> clear to have
> >> separate arch definitions.
> >>
> >> Could you give me more suggestions about this?  Thank you!
> > 
> > For the most part, you already need to enable the device drivers for the
> > specific components on each chip, and the per-soc top-level options here
> > don't actually control the compilation of any particular code.
> > 
> > This is slightly different for some of the older platforms that for historic
> > reasons need fine-grained options. You could probably just make the device
> > drivers depend on "ARCH_HISI || COMPILE_TEST" in general, but some level
> > of classification is ok, in particular when the chips are not related at 
> > all.
> > 
> > In this case, my impression is that while HI3519 and HI36xx are made
> > by different business units, there is still a noticeable amount of shared
> > IP in them (e.g. the "sysctrl" node that seems to be shared with some of
> > the other chips as well), so grouping them together should make sense.
> 
> HI35xx and HI36xx are designed totally independently, including IP selection.
> The relation between HI35xx and HI36xx is just like the one between HI36xx
> and HIP0x. In another word, HI35xx and HI36xx are not related except they all
> belong to hisilicon. So I don't think it's proper to group them together.
> 
> Is it OK if I drop ARCH_HI3519 and use ARCH_HISI directly?

I think we should come up with a way to handle this in general for
ARCH_HISI. It's not problem to have a couple of sub-options, but I'd
rather not have one for each SoC because I'm sure that hisilicon has
made dozens or possibly hundreds of ARM based SoCs that belong into
a couple of families.

The individual selection of IP blocks is not that important, because
those tend to just be generic device drivers that we can enable on
any platform using the defconfig files.

You said that ARCH_HI3519 and HIP04 have an identical system controller,
but it's different for Hi36xx, correct?

So maybe we can generalize the HIP04 option to include all chips with
that system controller as they appear to share a common ancestry regardless
of the target market?

The Hi35xx family includes some rather older chips as well based on ARM9
etc, correct? Are they closely related to the new one as well, or do they
just share the name?

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

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

[Gregory CLEMENT]

Hi Felipe,

I am going back on this subject (again :) )
 
 On mar., oct. 20 2015, Gregory CLEMENT  
wrote:

> Hi Felipe,
>  
>  On lun., oct. 05 2015, Felipe Balbi  wrote:
>
>
>>> So after many tests on different devices, 200ms is enough for most of
>>> them, but for one, 2000ms (2s) was needed!
>>>
>>> I see several option:
>>> - adding a sysfs entry to setup the time
>>> - adding a debugs entry entry
>>> - adding configuration option in menuconfig
>>> - using 2000ms and hopping it was enough for everyone
>>>
>>> My preference would go to the first option, what is your opinion?
>>
>> I'm not sure if either of them is good. man 2s is just too large. If the

Well 2s is lon I agree, but currently instead of 2s we have an infinite
wait, which is worse!

>> device isn't following the specification, I'm afraid that device needs
>> to be fixed.

I agree but these devices are for most of them USB stick that we find in
retail. We have no influence on them, so we have to do with them, even
if they do not follow the sepc.

So what about using configfs or sysfs to let the user confgiure this
value if needed?

I go back on this because, your suggestion didn't work. At least, I
didn't manage to make it improve the situation.

Thanks,

>>
>> I think the real issue here is the lack of a disconnect IRQ from AM335x
>> devices. But here's something I've been meaning to test but never had
>> time. If you look into AM335x address space, there's a bit in the
>> wrapper which tells it to use the standard MUSB registers for IRQ,
>> instead of the TI-specific thing. Can you see if we get a disconnect IRQ
>> with that ?
>>
>> TRM is at [1], see page 2566. Basically, if you set bit 3 in register
>> offset 0x1014, then it should use Mentor IRQ registers. If that works,
>> quite a few problems will actually vanish :-p
>
> So I tried it with the following patch:
>
> -
> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> index c791ba5..c714500 100644
> --- a/drivers/usb/musb/musb_dsps.c
> +++ b/drivers/usb/musb/musb_dsps.c
> @@ -470,6 +470,7 @@ static int dsps_musb_init(struct musb *musb)
>  
> /* Reset the musb */
> dsps_writel(reg_base, wrp->control, (1 << wrp->reset));
> +   dsps_writel(musb->ctrl_base, wrp->control, BIT(3));
>  
> musb->isr = dsps_interrupt;
>  
> @@ -625,6 +626,7 @@ static int dsps_musb_reset(struct musb *musb)
> if (session_restart || !glue->sw_babble_enabled) {
> dev_info(musb->controller, "Restarting MUSB to recover from 
> Babble\n");
> dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset));
> +   dsps_writel(musb->ctrl_base, wrp->control, BIT(3));
> usleep_range(100, 200);
> usb_phy_shutdown(musb->xceiv);
> usleep_range(100, 200);
> 
>
> I am not very familiar with that driver but my understanding was that
> the Mentor IRQ registeres are managed by the musb_interrupt() function
> which is called from the dsps_interrupt() interrupt handler.
>
> Am I right?
>
> if it is the case then it didn't fix the issue I had.
>
> I activated the following debug line:
>
> [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012"
> [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012"
>
> But I didn't get any interrupt while disconnecting the cable without any
> device connected on it (whereas I got an interrupt when I connected it).
>
> Note that I applied this patch instead of the "usb: musb: dsps: handle
> the otg_state_a_wait_vrise_timeout case", is what you had in mind ?
>
> Gregory
>
>>
>> [1] http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf
>>
>> -- 
>> balbi
>
> -- 
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tpmdd-devel] [PATCH v2 0/3] tpm_tis: Clean up force module parameter

[Wilck, Martin]

> > > You can completely ignore this question. I saw Martins reply with a fix 
> > > for
> > > "tpm_tis: Use devm_ioremap_resource" that you should squash into that
> > > change. So it's proved that TPM ACPI device objects do not always have a
> > > memory resource. Good.
> > 
> > Repeat, the memory resource DOES exist on my system. Not sure what proof
> > you saw there.
> 
> Ok, lets go this through.
> 
> I deduced this from two facts:
> 
> * It used to have memory resource as conditional and as a fallback use
>   fixed value.
> * Your workaround reverted the situation to this.
> 
> Did I understand something incorrectly?

The problem in my case didn't occur because ACPI was lacking a resource.
It has one "extra" resource that Jason's original code didn't
recognize. 

Jason's code was wrongly assuming that a resource that isn't of type
"IRQ" has to be of type "MEMORY". If I print out the resource types
encountered in tpm_check_resource(), I get
ACPI_RESOURCE_TYPE_FIXED_MEMORY32  (0x0a) first, followed by
ACPI_RESOURCE_TYPE_END_TAG (0x07). The latter was mistakenly used by
Jason't code as a memory resource. This is how ACPI ResourceTemplates
work (a list with an end marker). The correct solution is to always
check the return value of acpi_dev_resource_memory(), as it's currently
implemented in Jason't current "for-jarkko" branch.

Martin


> 
> /Jarkko
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH] drm: do not use device name as a format string

[Jani Nikula]

On Mon, 07 Dec 2015, Daniel Vetter  wrote:
> On Sun, Dec 06, 2015 at 11:16:32AM +0100, Nicolas Iooss wrote:
>> On 12/06/2015 10:35 AM, Daniel Vetter wrote:
>> >> On 11/18/2015 06:58 PM, Nicolas Iooss wrote:
>> >>> drm_dev_set_unique() formats its parameter using kvasprintf() but many
>> >>> of its callers directly pass dev_name(dev) as printf format string,
>> >>> without any format parameter.  This can cause some issues when the
>> >>> device name contains '%' characters.
>> >>>
>> >>> To avoid any potential issue, always use "%s" when using
>> >>> drm_dev_set_unique() with dev_name().
>> > 
>> > Not sure this is worth it really, normally people don't place % characters
>> > into their device names, ever. And if they do it'll blow up. There's also
>> > no security issue here since userspace can't set this name.
>> > 
>> > If the maintainers of the affected drivers don't want this I won't merge
>> > this patch.
>> 
>> Actually I had the same opinion before I began to add __printf
>> attributes and "%s" in several places in the kernel to make
>> -Wformat-security useful.  This led me to discover some funny issues
>> like the one fixed by commit 3958b79266b1 ("configfs: fix kernel
>> infoleak through user-controlled format string",
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3958b79266b14729edd61daf9dfb84de45f4ec6d
>> ).  The patch I sent is in fact a very small step towards making
>> -Wformat-security useful again to detect "real" issues.
>> 
>> Of course, if you do not feel it is worth it and believe that dev_name
>> is fully controlled by trusted sources which will never introduce any %
>> character, I understand your will of not merging my patch.
>
> Ah, that's the context I was missing, that really should be in the commit
> message. If this is part of an overall effort to enable something useful
> it makes more sense to get it in.
>
> On the patch itself it feels rather funny to do a "%s", str); combo, maybe
> we should have a drm_dev_set_unique_static instead? Including kerneldoc
> explaining why there's too.

No caller of drm_dev_set_unique() actually uses the formatting for
anything... so you'd end up with drm_dev_set_unique_static() and an
orphaned drm_dev_set_unique()...

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 11/16] Documentation: DT: bindings: Update NVIDIA PMC for Tegra210

[Jon Hunter]

On 06/12/15 00:31, Rob Herring wrote:
> On Fri, Dec 04, 2015 at 02:57:12PM +, Jon Hunter wrote:
>> ---
>>  Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt 
>> b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> index 02c27004d4a8..838e1a69ec0a 100644
>> --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> @@ -9,8 +9,9 @@ Required properties:
>>  - compatible : For Tegra20, must contain "nvidia,tegra20-pmc".  For Tegra30,
>>must contain "nvidia,tegra30-pmc".  For Tegra114, must contain
>>"nvidia,tegra114-pmc".  For Tegra124, must contain "nvidia,tegra124-pmc".
>> -  Otherwise, must contain "nvidia,-pmc", plus at least one of the
>> -  above, where  is tegra132.
>> +  For Tegra210, must contain "nvidia,tegra210-pmc". Otherwise, must contain
>> +  "nvidia,-pmc", plus at least one of the above, where  is
>> +  tegra132.
> 
> Can you reorg this some so the compatible strings are a list rather than 
> a paragraph of text. I find the last sentence a bit confusing as well. 
> Seems like  should be a list rather than just tegra132.

Yes no problem.

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 3/4] x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

[Borislav Petkov]

On Mon, Dec 07, 2015 at 10:45:04AM +0100, Ingo Molnar wrote:
> 
> * Borislav Petkov  wrote:
> 
> >  static int __init chacha20_simd_mod_init(void)
> >  {
> > -   if (!cpu_has_ssse3)
> > +   if (!boot_cpu_has(X86_FEATURE_SSSE3))
> > return -ENODEV;
> 
> Btw., could we rename 'boot_cpu_has()' to the more appropriate (and shorter!) 
> 'system_has()' form?
> 
> 'boot cpu' is a conceptual misnomer here really: it's just an 
> implementational 
> detail that we are looking at the boot CPU's flags, what we really mean to 
> express 
> is that these are system-wide features with no per-cpu properties.
> 
> Agreed?

Yeah, sounds good to me.

Mind if I do it for the next part of the cleanup, though, and not rework
those patches which are already tested?

I have a bunch of bulletpoints on the TODO still and could take care of
the renaming then too.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/