Re: [PATCH 2/2] iio: ti_am335x_adc: Add continuous sampling support

[Zubair Lutfullah :]

On Thu, Sep 19, 2013 at 06:41:22AM +0100, Jonathan Cameron wrote:
> 
> 
> >...
> >> >
> >> >  struct tiadc_device {
> >> >  struct ti_tscadc_dev *mfd_tscadc;
> >> >  int channels;
> >> >  u8 channel_line[8];
> >> >  u8 channel_step[8];
> >> >+ int buffer_en_ch_steps;
> >> >+ u32 *data;
> >> u16 *data;
> >> 
> >> Also it might actually save memory to simply have a fixed size array
> >> of the maximum size used here and avoid the extra allocations for
> >> the cost
> >> of 16 bytes in here.
> >> 
> >> Hence,
> >> 
> >> u16 data[8];
> >> >  };
> >
> >Why data[8]? The length is dynamic. 
> >This would be valid for the usual one sample per trigger case.
> >But here its continuous sampling and the hardware pushes samples
> >*quickly*
> >Dynamic allocation is needed.
> 
> As far as I can see you pull one set of channels into data[] then push that 
> out to the kfifo. 
> 
> That is repeated lots of times but only up to 8 entries are ever used in this 
> array. If not what is the maximum scanbytes can be?
> 

You have a good eye :).
I understand and will update.

Thanks
Zubair

> >
> >
> >...
> >
> >> >+static irqreturn_t tiadc_worker_h(int irq, void *private)
> >> >+{
> >> >+ struct iio_dev *indio_dev = private;
> >> >+ struct tiadc_device *adc_dev = iio_priv(indio_dev);
> >> >+ int i, k, fifo1count, read;
> >> >+ u32 *data = adc_dev->data;
> >>u16* data = adc_dev->data;
> >> >+
> >> >+ fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
> >> >+ for (k = 0; k < fifo1count; k = k + i) {
> >> >+ for (i = 0; i < (indio_dev->scan_bytes)/4; i++) {
> >> >+ read = tiadc_readl(adc_dev, REG_FIFO1);
> >> >+ data[i] = read & FIFOREAD_DATA_MASK;
> 
> i is only ever up to scanbytes / 4.
> Hence max of 8 I think?
> 
> Now there is a good argument for adding some bulk filling code for the 
> buffers but that is not happening here.
> >> //This is a 12 bit number after the mask so will fit just fine into
> >16 bits.
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: ti_am335x_adc: Add continuous sampling support

[Jonathan Cameron]

"Zubair Lutfullah :"  wrote:
>On Wed, Sep 18, 2013 at 02:58:47PM +0100, Jonathan Cameron wrote:
>> On 18/09/13 12:23, Zubair Lutfullah wrote:
>> >Previously the driver had only one-shot reading functionality.
>> >This patch adds continuous sampling support to the driver.
>> >
>...
>> 
>> Very very nearly there. Couple of suggestions in-line.
>> (about 30 seconds work + testing ;)
>
>Thank-you so much. Makes me want to put in more work and finish it :)
>
>> 
>> I'm still unsure of why we need 32bit storage in the fifo
>> for the data.  I've proposed the changes I'd make to put it in 16 bit
>> storage inline.  The fact that the device is working in 32bits
>> is irrelevant given we only have a 12 bit number coming out and
>> it is in 12 least significant bits.  I guess there might be a tiny
>> cost in doing the conversion, but you kfifo will be half the size
>> as a result and that seems more likely to a worthwhile gain!
>> 
>
>I understand and will make the changes.
>
>> Out of interest, are you testing this with generic_buffer.c?
>> If so, what changes were necessary?  Given this driver will not
>> have a trigger it would be nice to update that example code to handle
>> that case if it doesn't already.
>
>I simply remove the lines like goto err_trigger etc. :p
>Sneaky but works. I wasn't sure how to make the code understand its a 
>INDIO_BUFFER_HARDWARE..
>But this is a separate discussion..
>
>> 
>> 
>> >---
>> >  drivers/iio/adc/ti_am335x_adc.c  |  216
>+-
>> >  include/linux/mfd/ti_am335x_tscadc.h |9 ++
>> >  2 files changed, 220 insertions(+), 5 deletions(-)
>> >
>> >diff --git a/drivers/iio/adc/ti_am335x_adc.c
>b/drivers/iio/adc/ti_am335x_adc.c
>...
>> >
>> >  struct tiadc_device {
>> >struct ti_tscadc_dev *mfd_tscadc;
>> >int channels;
>> >u8 channel_line[8];
>> >u8 channel_step[8];
>> >+   int buffer_en_ch_steps;
>> >+   u32 *data;
>> u16 *data;
>> 
>> Also it might actually save memory to simply have a fixed size array
>> of the maximum size used here and avoid the extra allocations for
>> the cost
>> of 16 bytes in here.
>> 
>> Hence,
>> 
>> u16 data[8];
>> >  };
>
>Why data[8]? The length is dynamic. 
>This would be valid for the usual one sample per trigger case.
>But here its continuous sampling and the hardware pushes samples
>*quickly*
>Dynamic allocation is needed.

As far as I can see you pull one set of channels into data[] then push that out 
to the kfifo. 

That is repeated lots of times but only up to 8 entries are ever used in this 
array. If not what is the maximum scanbytes can be?

>
>
>...
>
>> >+static irqreturn_t tiadc_worker_h(int irq, void *private)
>> >+{
>> >+   struct iio_dev *indio_dev = private;
>> >+   struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> >+   int i, k, fifo1count, read;
>> >+   u32 *data = adc_dev->data;
>>  u16* data = adc_dev->data;
>> >+
>> >+   fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
>> >+   for (k = 0; k < fifo1count; k = k + i) {
>> >+   for (i = 0; i < (indio_dev->scan_bytes)/4; i++) {
>> >+   read = tiadc_readl(adc_dev, REG_FIFO1);
>> >+   data[i] = read & FIFOREAD_DATA_MASK;

i is only ever up to scanbytes / 4.
Hence max of 8 I think?

Now there is a good argument for adding some bulk filling code for the buffers 
but that is not happening here.
>> //This is a 12 bit number after the mask so will fit just fine into
>16 bits.
>
>Indeed
>...
>> >+
>> >+static int tiadc_buffer_postenable(struct iio_dev *indio_dev)
>> >+{
>> >+   struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> >+   struct iio_buffer *buffer = indio_dev->buffer;
>> >+   unsigned int enb = 0;
>> >+   u8 bit;
>> >+
>> (can drop this if doing the array with adc_dev as suggested above)
>> >+   adc_dev->data = kmalloc(indio_dev->scan_bytes, GFP_KERNEL);
>> >+   if (adc_dev->data == NULL)
>> >+   return -ENOMEM;
>
>As explained previously. Large array.. This is needed..
>
>...
>> >+{
>> >+   struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> >+
>> >+   tiadc_step_config(indio_dev);
>> (can drop this if doing the array withing adc_dev as suggested above)
>> >+   kfree(adc_dev->data);
>> This is also missbalanced with the preenable (which is true of quite
>> a few drivers - one day I'll clean those up!)
>
>Misbalanced? :s
>
>> >+
>> >+   return 0;
>> >+}
>> 
>
>Thanks for the review and feedback.
>I'll resend the patches with 16 bit everything and dynamic allocation.
>
>Zubair
>> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: ti_am335x_adc: Add continuous sampling support

[Jonathan Cameron]

"Zubair Lutfullah :"  wrote:
>On Wed, Sep 18, 2013 at 06:05:12PM +0100, Jonathan Cameron wrote:
>> 
>> >> >However in this case such conversion us dangerous. With all but
>IRQ
>> >> >resource managed by the traditional methods they will be released
>> >first
>> >> >with IRQ handler deregistered very last. Therefore if device is
>not
>> >> >properly quiesced IRQ raised during driver unbinding is likely to
>> >> >result
>> >> >in kernel oops.
>> >> >
>> >> >IOW devm_request_irq() is very often evil (it is still useful if
>> >_all_
>> >> >your resources are managed by devm_*).
>> >> >
>> >> >In case of your driver I'd recommend switching to
>> >> >request_irq()/free_irq() instead.
>> >> >
>> >> >Thanks.
>> >> 
>> >> Pretty much all resources are devm managed in here
>> >> 
>> >>
>>
>>https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/tree/drivers/iio/adc/ti_am335x_adc.c?h=togreg=7a1aeba7ed0d5a1e83fd5a8ee2a2869430d40347
>> >
>> >
>> >So we are guaranteed that that new kfifo that is being allocated
>just
>> >before we requesting IRQ and will be freed way before we free the
>IRQ
>> >will not be used by the IOTQ handler?
>> >
>> >Thanks.
>> Good point. I forgot about that.  The source of interrupts 'should'
>be disabled before the kfifo is freed but I guess perhaps better to
>play it safe. Would take a fair bit of review to be sure that is not
>going to cause grief.
>> 
>> A few more devm handlers need writing before it is truly useful here.
>> 
>> Thanks for pointing this out.
>> 
>> J
>
>If I understand the conclusion correctly, no devm here?

No devm for the irq. The rest are fine.
>
>Zubair
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: ti_am335x_adc: Add continuous sampling support

[Zubair Lutfullah :]

On Wed, Sep 18, 2013 at 02:58:47PM +0100, Jonathan Cameron wrote:
> On 18/09/13 12:23, Zubair Lutfullah wrote:
> >Previously the driver had only one-shot reading functionality.
> >This patch adds continuous sampling support to the driver.
> >
...
> 
> Very very nearly there. Couple of suggestions in-line.
> (about 30 seconds work + testing ;)

Thank-you so much. Makes me want to put in more work and finish it :)

> 
> I'm still unsure of why we need 32bit storage in the fifo
> for the data.  I've proposed the changes I'd make to put it in 16 bit
> storage inline.  The fact that the device is working in 32bits
> is irrelevant given we only have a 12 bit number coming out and
> it is in 12 least significant bits.  I guess there might be a tiny
> cost in doing the conversion, but you kfifo will be half the size
> as a result and that seems more likely to a worthwhile gain!
> 

I understand and will make the changes.

> Out of interest, are you testing this with generic_buffer.c?
> If so, what changes were necessary?  Given this driver will not
> have a trigger it would be nice to update that example code to handle
> that case if it doesn't already.

I simply remove the lines like goto err_trigger etc. :p
Sneaky but works. I wasn't sure how to make the code understand its a 
INDIO_BUFFER_HARDWARE..
But this is a separate discussion..

> 
> 
> >---
> >  drivers/iio/adc/ti_am335x_adc.c  |  216 
> > +-
> >  include/linux/mfd/ti_am335x_tscadc.h |9 ++
> >  2 files changed, 220 insertions(+), 5 deletions(-)
> >
> >diff --git a/drivers/iio/adc/ti_am335x_adc.c 
> >b/drivers/iio/adc/ti_am335x_adc.c
...
> >
> >  struct tiadc_device {
> > struct ti_tscadc_dev *mfd_tscadc;
> > int channels;
> > u8 channel_line[8];
> > u8 channel_step[8];
> >+int buffer_en_ch_steps;
> >+u32 *data;
> u16 *data;
> 
> Also it might actually save memory to simply have a fixed size array
> of the maximum size used here and avoid the extra allocations for
> the cost
> of 16 bytes in here.
> 
> Hence,
> 
> u16 data[8];
> >  };

Why data[8]? The length is dynamic. 
This would be valid for the usual one sample per trigger case.
But here its continuous sampling and the hardware pushes samples
*quickly*
Dynamic allocation is needed.


...

> >+static irqreturn_t tiadc_worker_h(int irq, void *private)
> >+{
> >+struct iio_dev *indio_dev = private;
> >+struct tiadc_device *adc_dev = iio_priv(indio_dev);
> >+int i, k, fifo1count, read;
> >+u32 *data = adc_dev->data;
>   u16* data = adc_dev->data;
> >+
> >+fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
> >+for (k = 0; k < fifo1count; k = k + i) {
> >+for (i = 0; i < (indio_dev->scan_bytes)/4; i++) {
> >+read = tiadc_readl(adc_dev, REG_FIFO1);
> >+data[i] = read & FIFOREAD_DATA_MASK;
> //This is a 12 bit number after the mask so will fit just fine into 16 bits.

Indeed
...
> >+
> >+static int tiadc_buffer_postenable(struct iio_dev *indio_dev)
> >+{
> >+struct tiadc_device *adc_dev = iio_priv(indio_dev);
> >+struct iio_buffer *buffer = indio_dev->buffer;
> >+unsigned int enb = 0;
> >+u8 bit;
> >+
> (can drop this if doing the array with adc_dev as suggested above)
> >+adc_dev->data = kmalloc(indio_dev->scan_bytes, GFP_KERNEL);
> >+if (adc_dev->data == NULL)
> >+return -ENOMEM;

As explained previously. Large array.. This is needed..

...
> >+{
> >+struct tiadc_device *adc_dev = iio_priv(indio_dev);
> >+
> >+tiadc_step_config(indio_dev);
> (can drop this if doing the array withing adc_dev as suggested above)
> >+kfree(adc_dev->data);
> This is also missbalanced with the preenable (which is true of quite
> a few drivers - one day I'll clean those up!)

Misbalanced? :s

> >+
> >+return 0;
> >+}
> 

Thanks for the review and feedback.
I'll resend the patches with 16 bit everything and dynamic allocation.

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

Letter of Intent

[Mr,Tep]

Dear Friend 

It is my interest to contact you in respect of our client from your country, 
who share almost the same name with your name . I shall explain in details when 
I read your reply.You are my first contact, I shall wait for days and if I do 
not hear from you. I shall continue with my search, Thanks

Waiting to hear from you

Mr. Tep Sereya 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: ti_am335x_adc: Add continuous sampling support

[Zubair Lutfullah :]

On Wed, Sep 18, 2013 at 06:05:12PM +0100, Jonathan Cameron wrote:
> 
> >> >However in this case such conversion us dangerous. With all but IRQ
> >> >resource managed by the traditional methods they will be released
> >first
> >> >with IRQ handler deregistered very last. Therefore if device is not
> >> >properly quiesced IRQ raised during driver unbinding is likely to
> >> >result
> >> >in kernel oops.
> >> >
> >> >IOW devm_request_irq() is very often evil (it is still useful if
> >_all_
> >> >your resources are managed by devm_*).
> >> >
> >> >In case of your driver I'd recommend switching to
> >> >request_irq()/free_irq() instead.
> >> >
> >> >Thanks.
> >> 
> >> Pretty much all resources are devm managed in here
> >> 
> >>
> >https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/tree/drivers/iio/adc/ti_am335x_adc.c?h=togreg=7a1aeba7ed0d5a1e83fd5a8ee2a2869430d40347
> >
> >
> >So we are guaranteed that that new kfifo that is being allocated just
> >before we requesting IRQ and will be freed way before we free the IRQ
> >will not be used by the IOTQ handler?
> >
> >Thanks.
> Good point. I forgot about that.  The source of interrupts 'should' be 
> disabled before the kfifo is freed but I guess perhaps better to play it 
> safe. Would take a fair bit of review to be sure that is not going to cause 
> grief.
> 
> A few more devm handlers need writing before it is truly useful here.
> 
> Thanks for pointing this out.
> 
> J

If I understand the conclusion correctly, no devm here?

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

Re: [PATCH 09/17] Move unicode to ASCII conversion to shared function.

[Roy Franz]

On Wed, Sep 18, 2013 at 8:44 PM, Adam Borowski  wrote:
> On Mon, Sep 16, 2013 at 09:11:25PM -0700, Roy Franz wrote:
>> +/* Convert the unicode UEFI command line to ASCII to pass to kernel.
>> + * Size of memory allocated return in *cmd_line_len.
>> + * Returns NULL on error.
>> + */
>> +static char *efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,
>
>> +   int load_options_size = image->load_options_size / 2; /* ASCII */
>
>> + for (i = 0; i < options_size - 1; i++)
>> + *s1++ = *s2++;
>
> I'm afraid both this commit and comments inside are misnamed.  What you're
> changing here is the encoding rather than character set.
>
> In fact, these days it's 8-bit encodings that are more likely to be Unicode
> than 16-bit ones: UTF-8 is ubiquitous, while you usually get UCS2 at most.
> In either case, though, we have here is a 7-bit charset encoded as either
> 8-bit or 16-bit units.  What this function does is blindly truncating upper
> byte.  The supported payload is in both cases ASCII.
>
> I'd thus rename the function to what it already does: truncating u16 to u8,
> and adjust comments accordingly.
>
> Replacing values above 126 with a token character like '?' would be good
> too: that'd avoid producing corrupted characters and/or random ASCII chars.

I stuck to re-arranging the code that was there, as I don't know
enough about character encodings
to propose changes.  Also, this code is running as part of the kernel
decompressor, rather
than the kernel itself, so it doesn't have access to any kernel
facilities, and it also needs to
be position independent.  It's running in a quite limited environment
-  the decompressor has
its own copy of strstr(), and other string functions.

I checked the UEFI specification, and it states that all 16 bit
strings are UCS-2, unless
otherwise noted.  The load options that the command line is provided
through a void pointer
specified as:

"LoadOptions A pointer to the image's binary load options."

I couldn't quickly find any other mentions of LoadOptions in the
spec., so I don't know what
other types of values could be, or are typically provided.  The spec
isn't helpful regarding the type
of this data, and I don't know what common practice is here among the
various EFI/UEFI firmwares
out there.

Would it be acceptable to fix the naming/comments, and convert values
above 126 to '?'
in the current patchset, and address a more thorough fix in another patch set?
The ARM and ARM64 EFI stub patchsets that are mostly complete depend
on this one,
so getting this merged soon would be helpful.

Something like:
>> +/* Convert the UEFI command line from 16 bit to 8 bit encoding to pass to 
>> kernel.
>> + * by truncating to 7 bits.  Values above 126 are converted to 63 (ASCII 
>> '?')
>> + * Size of memory allocated return in *cmd_line_len.
>> + * Returns NULL on error.
>> + */
+static char *efi_truncate_cmdline_to_8bit_encoding(efi_system_table_t
*sys_table_arg,
(update code to truncate and convert to '?')

>
> Your commit only moves things around, so it might be out of scope for now,
> but I wonder: what if the kernel actually supported Unicode here?  Few
> cmdline arguments take values where non-ASCII makes sense, but at least some
> do: for example, a Russian guy is not unlikely to name subvolumes using
> cyrillic.  Supporting that would be easy (estimating the length then
> tf16us_to_utf8s()).  There's just one problem: which encoding to use, but
> these days, most distributions have either dropped non-UTF8 or hardly pay
> lip service, so we could get away with hard-coding UTF-8: those few who
> use ancient charsets can stick to ASCII.  Would this be ok?  If so, shout,
> I can code this if you don't care enough.

I would certainly appreciate your help improving this, although I think we'll
need to have a better understanding of what the UEFI firmware is providing
before we can implement something better.


>
> --
> ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: nand: fix memory leak in ONFI extended parameter page

[Brian Norris]

On Tue, Sep 17, 2013 at 10:12:57AM +0800, Huang Shijie wrote:
> 于 2013年09月17日 09:31, Brian Norris 写道:
> > This fixes a memory leak in the ONFI support code for detecting the
> > required ECC levels from this commit:
> >
> >   commit 6dcbe0cdd83fb5f77be4f44c9e06c535281c375a
> >   Author: Huang Shijie 
> >   Date:   Wed May 22 10:28:27 2013 +0800
> >
> >   mtd: get the ECC info from the Extended Parameter Page
> >
> > In the success case, we never freed the 'ep' buffer.
> >
> > Also, this fixes an oversight in the same commit where we (harmlessly)
> > freed the NULL pointer.
> >
> > Signed-off-by: Brian Norris 
> > Cc: Huang Shijie 
> > ---
> > David, if there are no objections, can you send this to Linus for 3.12?
> >
> > If this doesn't make it into 3.12, then it will be -stable material.
> >
> >  drivers/mtd/nand/nand_base.c | 8 +++-
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> > index d4578a1..00022b4 100644
> > --- a/drivers/mtd/nand/nand_base.c
> > +++ b/drivers/mtd/nand/nand_base.c
> > @@ -2869,10 +2869,8 @@ static int nand_flash_detect_ext_param_page(struct 
> > mtd_info *mtd,
> >  
> > len = le16_to_cpu(p->ext_param_page_length) * 16;
> > ep = kmalloc(len, GFP_KERNEL);
> > -   if (!ep) {
> > -   ret = -ENOMEM;
> > -   goto ext_out;
> > -   }
> > +   if (!ep)
> > +   return -ENOMEM;
> >  
> > /* Send our own NAND_CMD_PARAM. */
> > chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
> > @@ -2920,7 +2918,7 @@ static int nand_flash_detect_ext_param_page(struct 
> > mtd_info *mtd,
> > }
> >  
> > pr_info("ONFI extended param page detected.\n");
> > -   return 0;
> > +   ret = 0;
> >  
> >  ext_out:
> > kfree(ep);
> good catch!
> 
> Acked-by: Huang Shijie 

OK, pushed to l2-mtd.git. If I don't hear anything from David in a few
days, then I'll see about sending it upstream myself. He had time to
respond to your quad-SPI series but not to the pxa3xx compile failures
in his -rc1 pull request.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: return EEXIST instead of EBUSY for second registering

[Viresh Kumar]

On 19 September 2013 09:35, Yinghai Lu  wrote:
> System that cpu support intel_pstate, acpi_cpufreq fail to
> load, and udev keep trying until trace get filled up and
> kernel crash.
>
> The root cause is driver return ret from cpufreq_register_driver
> and when some other driver take over before, it would return
> EBUSY, then udev will keep trying...
>
> cpufreq_register_driver should return EEXIST instead.
> then system could boot without appending intel_pstate=disable
> and still use intel_pstate.
>
> Signed-off-by: Yinghai Lu 

Acked-by: Viresh Kumar 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: return EEXIST instead of EBUSY for second registering

[Yinghai Lu]

System that cpu support intel_pstate, acpi_cpufreq fail to
load, and udev keep trying until trace get filled up and
kernel crash.

The root cause is driver return ret from cpufreq_register_driver
and when some other driver take over before, it would return
EBUSY, then udev will keep trying...

cpufreq_register_driver should return EEXIST instead.
then system could boot without appending intel_pstate=disable
and still use intel_pstate.

Signed-off-by: Yinghai Lu 

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

Index: linux-2.6/drivers/cpufreq/cpufreq.c
===
--- linux-2.6.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6/drivers/cpufreq/cpufreq.c
@@ -2104,7 +2104,7 @@ int cpufreq_register_driver(struct cpufr
write_lock_irqsave(_driver_lock, flags);
if (cpufreq_driver) {
write_unlock_irqrestore(_driver_lock, flags);
-   return -EBUSY;
+   return -EEXIST;
}
cpufreq_driver = driver_data;
write_unlock_irqrestore(_driver_lock, flags);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Sep 19

[Stephen Rothwell]

Hi all,

Changes since 20130918:

The gpio tree lost its build failure.



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" as mentioned in the FAQ on the wiki
(see below).

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. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 218 trees (counting Linus' and 30 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

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.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.


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

$ git checkout master
$ git reset --hard stable
Merging origin/master (9baa505 Merge tag 'please-pull-pstore' of 
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux)
Merging fixes/master (fa8218d Merge tag 'regmap-v3.11-rc7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap)
Merging kbuild-current/rc-fixes (ad81f05 Linux 3.11-rc1)
Merging arc-current/for-curr (272b98c Linux 3.12-rc1)
Merging arm-current/fixes (c89efa7 ARM: 7836/1: add 
__get_user_unaligned/__put_user_unaligned)
Merging m68k-current/for-linus (21e884b m68k/m68knommu: Implement 
__get_user_unaligned/__put_user_unaligned())
Merging metag-fixes/fixes (3b2f64d Linux 3.11-rc2)
Merging powerpc-merge/merge (363edbe powerpc: Default arch idle could cede 
processor on pseries)
Merging sparc/master (4de9ad9 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile)
Merging net/master (bd784a1 net:dccp: do not report ICMP redirects to user 
space)
Merging ipsec/master (33fce60 xfrm: Guard IPsec anti replay window against 
replay bitmap)
Merging sound-current/for-linus (3d0049e Merge tag 'asoc-v3.12-4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (a923874 Merge tag 'pci-v3.12-changes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci)
Merging wireless/master (f4e1a4d rt2800: change initialization sequence to fix 
system freeze)
Merging driver-core.current/driver-core-linus (272b98c Linux 3.12-rc1)
Merging tty.current/tty-linus (93a8d41 n_tty: Fix EOF push index when termios 
changes)
Merging usb.current/usb-linus (42f4891 Merge tag 'fixes-for-v3.12-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging staging.current/staging-linus (c3cb718 staging: line6: add bounds check 
in snd_toneport_source_put())
Merging char-misc.current/char-misc-linus (272b98c Linux 3.12-rc1)
Merging input-current/for-linus (2f0d260 Input: i8042 - i8042_flush fix for a 
full 8042 buffer)
Merging md-current/for-linus (f94c0b6 md/raid5: fix interaction of 'replace' 
and 'recovery'.)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (26052f9 crypto: crct10dif - Add fallback for 
broken initrds)
Merging ide/master (64110c1 ide: sgiioc4: Staticize ioc4_ide_attach_one())
Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct 
resource to 0 in of_irq_to_resource())
Merging rr-fixes/fixes (6c2580c Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32)
Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl driver work 
without pdata)
Merging vfio-fixes/for-linus (d24cdbf vfio-pci: Avoid deadlock on remove)
Merging drm-intel-fixes/for-linux-next-fixes (571c608 drm/i915: kill 
set_need_

Re: [PATCH 09/17] Move unicode to ASCII conversion to shared function.

[H. Peter Anvin]

On 09/18/2013 10:44 PM, Adam Borowski wrote:
> 
> In fact, these days it's 8-bit encodings that are more likely to be Unicode
> than 16-bit ones: UTF-8 is ubiquitous, while you usually get UCS2 at most.
> In either case, though, we have here is a 7-bit charset encoded as either
> 8-bit or 16-bit units.  What this function does is blindly truncating upper
> byte.  The supported payload is in both cases ASCII.
> 
> I'd thus rename the function to what it already does: truncating u16 to u8,
> and adjust comments accordingly.
> 
> Replacing values above 126 with a token character like '?' would be good
> too: that'd avoid producing corrupted characters and/or random ASCII chars.
> 
> Your commit only moves things around, so it might be out of scope for now,
> but I wonder: what if the kernel actually supported Unicode here?  Few
> cmdline arguments take values where non-ASCII makes sense, but at least some
> do: for example, a Russian guy is not unlikely to name subvolumes using
> cyrillic.  Supporting that would be easy (estimating the length then
> utf16s_to_utf8s()).  There's just one problem: which encoding to use, but
> these days, most distributions have either dropped non-UTF8 or hardly pay
> lip service, so we could get away with hard-coding UTF-8: those few who
> use ancient charsets can stick to ASCII.  Would this be ok?  If so, shout,
> I can code this if you don't care enough.
> 

We should, indeed, do proper conversion to UTF-8 here.

I also suspect we should assume the input is UTF-16 rather than UCS-2,
although that is a bit more exotic.

-hpa

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

Re: [PATCH 09/17] Move unicode to ASCII conversion to shared function.

[Adam Borowski]

On Mon, Sep 16, 2013 at 09:11:25PM -0700, Roy Franz wrote:
> +/* Convert the unicode UEFI command line to ASCII to pass to kernel.
> + * Size of memory allocated return in *cmd_line_len.
> + * Returns NULL on error.
> + */
> +static char *efi_convert_cmdline_to_ascii(efi_system_table_t *sys_table_arg,

> +   int load_options_size = image->load_options_size / 2; /* ASCII */

> + for (i = 0; i < options_size - 1; i++)
> + *s1++ = *s2++;

I'm afraid both this commit and comments inside are misnamed.  What you're
changing here is the encoding rather than character set.

In fact, these days it's 8-bit encodings that are more likely to be Unicode
than 16-bit ones: UTF-8 is ubiquitous, while you usually get UCS2 at most.
In either case, though, we have here is a 7-bit charset encoded as either
8-bit or 16-bit units.  What this function does is blindly truncating upper
byte.  The supported payload is in both cases ASCII.

I'd thus rename the function to what it already does: truncating u16 to u8,
and adjust comments accordingly.

Replacing values above 126 with a token character like '?' would be good
too: that'd avoid producing corrupted characters and/or random ASCII chars.

Your commit only moves things around, so it might be out of scope for now,
but I wonder: what if the kernel actually supported Unicode here?  Few
cmdline arguments take values where non-ASCII makes sense, but at least some
do: for example, a Russian guy is not unlikely to name subvolumes using
cyrillic.  Supporting that would be easy (estimating the length then
utf16s_to_utf8s()).  There's just one problem: which encoding to use, but
these days, most distributions have either dropped non-UTF8 or hardly pay
lip service, so we could get away with hard-coding UTF-8: those few who
use ancient charsets can stick to ASCII.  Would this be ok?  If so, shout,
I can code this if you don't care enough.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm radeon/nouveau/core fixes

[Dave Airlie]

On Thu, Sep 19, 2013 at 12:20 PM, Linus Torvalds
 wrote:
> On Wed, Sep 18, 2013 at 9:07 PM, Dave Airlie  wrote:
>>
>> mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix
>> for AST driver.
>
> Ugh. I hope things calm down from here.

It shouldn't be that bad, this stuff was a bit delayed, some of it was
in my tree before the merge closed, I was just distracting myself with
other stuff,

The radeon stuff is for new hw that was merged in the merge window,
and more DPM fixes which is still off by default,

The only coming thing that worries me is the VGA arbitration fixes for
Intel GPUs is really screwed up and fixing it looks like resorting to
slightly drastic measures.

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

Re: Regression: bisected: commit 7c510133d93 breaks video

[Dave Airlie]

On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimmerman
 wrote:
> I have an ASUS P6X58D-Premium mobo with a GeForce 9400GT PCIe video card.
> With kernel 3.12-rc1, I get scrambled video on boot. Kernel 3.11 works
> fine.
>
> Bisecting this, I found 7c510133d93dd6f15ca040733ba7b2891ed61fd1 "drm:
> mark context support as a legacy subsystem" is the guilty commit. If I
> revert that commit, the video works fine.
>
> Is there any more info I can provide?

Full dmesg, and what driver you are using.

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

Re: [git pull] drm radeon/nouveau/core fixes

[Linus Torvalds]

On Wed, Sep 18, 2013 at 9:07 PM, Dave Airlie  wrote:
>
> mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix
> for AST driver.

Ugh. I hope things calm down from here.

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

Re: [PATCH 0/2] vsprintf: ignore %n again

[Tetsuo Handa]

Kees Cook wrote:
> > -- output start --
> > const : literal
> > not const : const char *
> > not const : const char []
> > const : const char * const
> 
> What version of gcc did you use? I don't get the last as const, for
> some reason. And as Dan mentions, shouldn't const char[] be detected
> as const too?

This worked on

  gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)
  gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)

with -On (where n != 0), but didn't work on

  gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

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

[git pull] drm radeon/nouveau/core fixes

[Dave Airlie]

Hi Linus,

mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix
for AST driver.

Dave.

The following changes since commit 01172772c7c973debf5b4881fcb9463891ea97ec:

  drm/nouveau: fix oops on runtime suspend/resume (2013-09-10 12:38:53 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 928c2f0c006bf7f381f58af2b2786d2a858ae311:

  drm/fb-helper: don't sleep for screen unblank when an oops is in
progress (2013-09-19 11:54:34 +1000)


Alex Deucher (24):
  drm/radeon/cik: properly handle internal cp ints
  drm/radeon/si: properly handle internal cp ints
  drm/radeon/dce6/audio: make sure pin is valid before accessing it
  drm/radeon: add a connector property for audio
  drm/radeon: dpm updates for KV
  drm/radeon: protect concurrent smc register access with a spinlock
  drm/radeon: add spinlocks for indirect register accesss
  drm/radeon/cik: update gpu_init for an additional berlin gpu
  drm/radeon: add some additional berlin pci ids
  drm/radeon: fix typo in PG flags
  drm/radeon/r6xx: add a stubbed out set_uvd_clocks callback
  drm/radeon/dpm: fix fallback for empty UVD clocks
  drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2)
  drm/radeon/dpm: handle bapm on trinity
  drm/radeon/dpm: handle bapm on kb/kv
  drm/radeon/dpm: add infrastructure to properly handle bapm
  drm/radeon/dpm: add bapm callback for trinity
  drm/radeon/dpm: add bapm callback for kb/kv
  drm/radeon/dpm/rs780: use drm_mode_vrefresh()
  drm/radeon/dpm/rs780: add some sanity checking to sclk scaling
  drm/radeon/dpm/rs780: don't enable sclk scaling if not required
  drm/radeon/dpm/rs780: fix force_performance state for same sclks
  drm/radeon/dpm: rework auto performance level enable
  drm/radeon: fix panel scaling with eDP and LVDS bridges

Anthoine Bourgeois (1):
  drm/radeon/dpm: implement force performance levels for rs780 (v2)

Ben Skeggs (5):
  drm/nouveau/bios/init: stub opcode 0xaa
  drm/nouveau/kms: enable for non-vga pci classes
  drm/nouveau/bios/init: fix thinko in INIT_CONFIGURE_MEM
  drm/nouveau/ttm: prevent double-free in
nouveau_sgdma_create_ttm() failure path
  drm/ttm: fix the tt_populated check in ttm_tt_destroy()

Christian König (3):
  drm/radeon: remove stale radeon_fence_retire tracepoint
  drm/radeon: add command submission tracepoint
  drm/radeon: avoid UVD corruptions on AGP cards

Damien Lespiau (1):
  drm/radeon: Fix hmdi typo

Dan Carpenter (2):
  drm/radeon: clean up r600_free_extended_power_table()
  drm/radeon: signedness bug in kv_dpm.c

Daniel Vetter (2):
  drm/udl: rip out set_need_resched
  drm/fb-helper: don't sleep for screen unblank when an oops is in progress

Dave Airlie (4):
  drm/ast: fix the ast open key function
  Merge branch 'drm-fixes-3.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge branch 'drm-fixes-3.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge branch 'drm-nouveau-next' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

Jean Delvare (2):
  drm/radeon: simplify driver data retrieval
  drm/radeon: expose DPM thermal thresholds through sysfs

Prarit Bhargava (1):
  drm, ttm Fix uninitialized warning

 drivers/gpu/drm/ast/ast_drv.h   |   2 +-
 drivers/gpu/drm/drm_fb_helper.c |   8 ++
 drivers/gpu/drm/nouveau/core/subdev/bios/init.c |  21 ++-
 drivers/gpu/drm/nouveau/nouveau_display.c   |  35 +++--
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |   3 +-
 drivers/gpu/drm/nouveau/nouveau_sgdma.c |   4 +-
 drivers/gpu/drm/radeon/atombios_encoders.c  |  23 ++--
 drivers/gpu/drm/radeon/btc_dpm.c|   6 -
 drivers/gpu/drm/radeon/ci_dpm.c |   6 -
 drivers/gpu/drm/radeon/ci_smc.c |  39 --
 drivers/gpu/drm/radeon/cik.c|  36 +-
 drivers/gpu/drm/radeon/cypress_dpm.c|   6 -
 drivers/gpu/drm/radeon/dce6_afmt.c  |  12 +-
 drivers/gpu/drm/radeon/kv_dpm.c | 164 +++-
 drivers/gpu/drm/radeon/kv_dpm.h |   1 +
 drivers/gpu/drm/radeon/kv_smc.c |   8 ++
 drivers/gpu/drm/radeon/ni_dpm.c |   6 -
 drivers/gpu/drm/radeon/ppsmc.h  |   2 +
 drivers/gpu/drm/radeon/r100.c   |   7 +
 drivers/gpu/drm/radeon/r420.c   |   7 +
 drivers/gpu/drm/radeon/r600.c   |  19 +++
 drivers/gpu/drm/radeon/r600_dpm.c   |  38 ++
 drivers/gpu/drm/radeon/r600d.h  |   2 +-
 drivers/gpu/drm/radeon/radeon.h |  82 +++-
 drivers/gpu/drm/radeon/radeon_asic.c

Regression: bisected: commit 7c510133d93 breaks video

[Paul Zimmerman]

I have an ASUS P6X58D-Premium mobo with a GeForce 9400GT PCIe video card.
With kernel 3.12-rc1, I get scrambled video on boot. Kernel 3.11 works
fine.

Bisecting this, I found 7c510133d93dd6f15ca040733ba7b2891ed61fd1 "drm:
mark context support as a legacy subsystem" is the guilty commit. If I
revert that commit, the video works fine.

Is there any more info I can provide?

-- 
Paul

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

[David Gibson]

On Wed, Sep 18, 2013 at 10:28:44AM -0600, Stephen Warren wrote:
> On 09/17/2013 03:15 PM, Olof Johansson wrote:
> > On Tue, Sep 17, 2013 at 2:08 PM, Frank Rowand  
> > wrote:
> >> On 9/17/2013 9:43 AM, Olof Johansson wrote:
> >>> On Tue, Sep 17, 2013 at 09:56:39AM +0200, Tomasz Figa wrote:
>  I'm afraid that I must disagree. For consistency I'd rather go with what
>  Ben said. Please see ePAPR chapter 2.2.1.1, which clearly defines how
>  nodes should be named.
> >>>
> >>> 2.2.1.1 is there to point out that unit address _has_ to reflect reg.
> >>>
> >>> 2.2.3 says that unit addresses can be omitted.
> >>
> >> 2.2.3 is talking about path names.
> >>
> >> 2.2.1.1 is talking about node names.
> >>
> >> 2.2.1.1 _does_ require the unit address in the node name, 2.2.3 does not
> >> remove that requirement.
> > 
> > Sigh, that's horrible. OF clearly doesn't require it.
> > 
> > I guess people prefer to follow ePAPR even though it's broken? That
> > means someone needs to cleanup the current dts files. Any takers?
> 
> FWIW, I investigated enhancing dtc to enforce this rule. Here are the
> results:
> 
> ** TEST SUMMARY
> * Total testcases:1446
> *PASS:1252
> *FAIL:58
> *   Bad configuration:136
> * Strange test result:0
> **
> 
> That's just in dtc itself, and not any of the *.dts in the kernel or
> U-Boot source trees...

Uh.. yeah.  The trees in the dtc testsuite are rather contrived and
not good examples of device trees in general.  They're really purely
examples of dts syntax, and don't at all resemble typical dt contents.

> I'll see how much of patch it takes to fix up all the test-cases in dtc.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


pgp02mWdxLXTB.pgp
Description: PGP signature

Re: [PATCH 5/5] lib: Add error string support to printks

[Daniel Santos]

On 09/18/2013 06:04 AM, David Howells wrote:

Joe Perches  wrote:


On Tue, 2013-09-17 at 18:08 -0500, danielfsan...@att.net wrote:

This adds an extension for the integral format specifier suffix of 'e',
so that the format %[duxXo]e will result in printing an number (as
before) in addition to a name and descrption for an error code, if such
support is enabled and a name and descrption is found.

My initial thought was to use the glibc extension of '%m', but this
format specifier uses the value of libc's errno and adding a value
breaks gcc's printf parsing.  I'm not convinced that the 'e' extension
is optimal, although there are only four instances of this pattern in
the kernel that would need to be changed.

 git grep -E '".*%[#0\ +\-]*[0-9]*[hljzt]*[idoxXu]e'

Alternatively, 'E' was another thought for a suffix as well.

I'd much rather see another %p extension used instead
of generating odd output given normal printf formats.

%pE might work

I guess you'd use that with ERR_PTR().  On one hand, it would look decidedly
odd, but on the other hand, we have errors in pointers in a lot of places
already which wouldn't then need converting back - so it doesn't seem entirely
unreasonable.

David


Hmm, this discussion makes me pine for the gnu libc '%m' extension even 
further.  I wish there was an easy way to tell gcc that you want it to 
check your format, but here are my extensions.  Oh well.


Honestly, I'm not too keen on the %pE idea, although I can see that %p 
is where all of the kernel extensions currently are. Unless I'm 
incorrect, if I use ERR_PTR() on a signed int on a x86_64 where pointer 
is 64 bits and int is 32, wouldn't that mean a signed conversion 
instruction where the sign bit has to be moved from bit 31 to 63?


Either way, %pE does seem to make a lot of sense for conditions where we 
already have a pointer that we would otherwise use PTR_ERR() to convert, 
but it just seems klunky to use it on an int, to have it treated like a 
pointer and then re-interpreted as an int.  Maybe we can add %pE as well 
as %dE and leave [ioxXu] out of it?


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

unsupported usb bluetooth device

[Ken O'Brien]

Hi,

I've acquired a Belkin "Mini Bluetooth v4.0 Adapter" F8T065bf
8830bf12557 Rev. A01.

I'm running Linux 3.7.10-1.16 (openSUSE 12.3) and this device is not
detecting beyond what I can see in lsusb.

What steps can I take to aid in patching the kernel to support this
device? I am a proficient C/asm programmer but I've not done kernel
driver dev before.

Best Regards,

Ken


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

[Ben Skeggs]

- Original Message -
> From: "Dave Jones" 
> To: "Linux Kernel" 
> Cc: bske...@redhat.com, airl...@redhat.com
> Sent: Wednesday, 18 September, 2013 7:26:34 AM
> Subject: nouveau: remove pointless assignment
> 
> self-assignment of a variable doesn't make a lot of sense.
Thanks, search-and-replace left-over, pulled into my tree.

Ben.

> 
> Signed-off-by: Dave Jones 
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 755c38d..d0a737c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -982,7 +982,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
> evict, bool intr,
>bool no_wait_gpu, struct ttm_mem_reg *new_mem)
>  {
>   struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
> - struct nouveau_channel *chan = chan = drm->ttm.chan;
> + struct nouveau_channel *chan = drm->ttm.chan;
>   struct nouveau_bo *nvbo = nouveau_bo(bo);
>   struct ttm_mem_reg *old_mem = >mem;
>   int ret;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RESEND PATCH] mm/mempolicy: use NUMA_NO_NODE

[David Rientjes]

On Tue, 17 Sep 2013, Jianguo Wu wrote:

> Use more appropriate NUMA_NO_NODE instead of -1
> 
> Signed-off-by: Jianguo Wu 
> Acked-by: KOSAKI Motohiro 

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

[no subject]

[Loan Offer]

-- 
Are You In Need Of money to pay your bills or to start any kind of
Business? If Yes; Contact us via: richard.fast.loancompa...@gmail.com
Full Name:
Amount Needed:
Duration:
Country:
Cell No:
Sex:
Age:
Noted that all email should been send to Mr Richard Fast on this
email: richard.fast.loancompa...@gmail.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/

[PATCH tty-next] tty: Remove unused drop() method from tty_port interface

[Peter Hurley]

Although originally conceived as a hook for port drivers to know
when a port reference is dropped, no driver uses this method.

Signed-off-by: Peter Hurley 
---
 drivers/tty/tty_port.c | 6 +-
 include/linux/tty.h| 1 -
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index f597e88..9857f7e 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -480,8 +480,6 @@ int tty_port_close_start(struct tty_port *port,
 
if (port->count) {
spin_unlock_irqrestore(>lock, flags);
-   if (port->ops->drop)
-   port->ops->drop(port);
return 0;
}
set_bit(ASYNCB_CLOSING, >flags);
@@ -500,9 +498,7 @@ int tty_port_close_start(struct tty_port *port,
/* Flush the ldisc buffering */
tty_ldisc_flush(tty);
 
-   /* Don't call port->drop for the last reference. Callers will want
-  to drop the last active reference in ->shutdown() or the tty
-  shutdown path */
+   /* Report to caller this is the last port reference */
return 1;
 }
 EXPORT_SYMBOL(tty_port_close_start);
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 64f8646..2f47989 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -180,7 +180,6 @@ struct tty_port_operations {
   IFF the port was initialized. Do not use to free resources. Called
   under the port mutex to serialize against activate/shutdowns */
void (*shutdown)(struct tty_port *port);
-   void (*drop)(struct tty_port *port);
/* Called under the port mutex from tty_port_open, serialized using
   the port mutex */
 /* FIXME: long term getting the tty argument *out* of this would be
-- 
1.8.1.2

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

[PATCH tty-next 0/1] premature tty_port destruction diagnostic

[Peter Hurley]

Hi Greg,

Now that the bluetooth rfcomm tty refcounting is fixed in linux-next,
I'd like to add this patch which aborts tty_port destruction if the
tty has not yet been released. At least this problem won't show up
as some random memory corruption (as was happening with rfcomm).

Even though this only WARNs, the machine is likely to crash anyway
because the port indexes will not be in sync; the tty layer will
assume the port has been destructed while the tty_port obviously
has not.

Regards,

Peter Hurley (1):
  tty: Prevent tty_port destruction if tty not released

 drivers/tty/tty_port.c | 4 
 1 file changed, 4 insertions(+)

-- 
1.8.1.2

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

[PATCH tty-next 1/1] tty: Prevent tty_port destruction if tty not released

[Peter Hurley]

If the tty driver mistakenly drops the last port reference
before the tty has been released, issue a diagnostic and
abort the port destruction.

This will leak memory and may zombify the port, but might
otherwise keep the machine in runnable state.

Signed-off-by: Peter Hurley 
---
 drivers/tty/tty_port.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 9857f7e..c94d234 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -140,6 +140,10 @@ EXPORT_SYMBOL(tty_port_destroy);
 static void tty_port_destructor(struct kref *kref)
 {
struct tty_port *port = container_of(kref, struct tty_port, kref);
+
+   /* check if last port ref was dropped before tty release */
+   if (WARN_ON(port->itty))
+   return;
if (port->xmit_buf)
free_page((unsigned long)port->xmit_buf);
tty_port_destroy(port);
-- 
1.8.1.2

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

Re: [PATCH v2] clk: si570: Add a driver for SI570 oscillators

[Guenter Roeck]

On Wed, Sep 18, 2013 at 04:32:59PM -0700, Sören Brinkmann wrote:
> On Wed, Sep 18, 2013 at 04:18:56PM -0700, Joe Perches wrote:
> > On Wed, 2013-09-18 at 16:09 -0700, Sören Brinkmann wrote:
> > > On Wed, Sep 18, 2013 at 04:02:41PM -0700, Joe Perches wrote:
> > > > On Wed, 2013-09-18 at 15:43 -0700, Soren Brinkmann wrote:
> > > > > Add a driver for SILabs 570, 571, 598, 599 programmable oscillators.
> > > > > The devices generate low-jitter clock signals and are reprogrammable 
> > > > > via
> > > > > an I2C interface.
> > > > []
> > > > > v2:
> > > > []
> > > > >  - use 1 as MIN and MAX value in usleep_range
> > > > []
> > > > > diff --git a/drivers/clk/clk-si570.c b/drivers/clk/clk-si570.c
> > > > []
> > > > > +static int si570_set_frequency(struct clk_si570 *data, unsigned long 
> > > > > frequency)
> > > > > +{
> > > > []
> > > > > + /* Applying a new frequency can take up to 10ms */
> > > > > + usleep_range(1, 1);
> > > > 
> > > > Generally it's nicer to have an actual range for usleep_range.
> > > Well, as I said in the discussion with Guenther. I'm flexible and nobody
> > > objected when I said to make both equal. A real range doesn't make sense
> > > here though, but I don't know what's common practice for cases like
> > > this.
> > 
> > udelay is normal, but I guess you don't need atomic context.
> After checkpatch correcting me a few times I went with what
> Documentation/timers/timers-howto.txt suggests. But yes, then we have
> this situation, that I want to sleep 10ms, but not longer using a
> *_range function. I guess it is very application specific whether a
> longer delay here is acceptable or not.
> 
You really want to sleep and not call udelay for 10ms. The idea behind 
usleep_range
is that you give the kernel some slack. In this case, you could for example 
make it
10-12 ms. That doesn't make much difference for the driver, but it might save a
timer interrupt in the kernel because it might be able to coalesce more than one
event. After all, it doesn't have to be _exactly_ 10 ms, which is what you are
claiming with the fixed number. Prior to usleep_range, you would have happily
called msleep(10) without realizing that it might sleep up to 20 ms on you.
Keep that in mind ...

> You're right. I'll add a delay there as well. The 'rang' question
> applies here as well.
> 
Same thing, really. You could make it 100-200uS. That doesn't make much
difference for this driver, but it might make a difference for overall
performance, especially if everyone is playing nicely.

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

Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit

[Dave Chinner]

[my keyboard my be on the fritz - it's not typing what I'm thinking...]

On Thu, Sep 19, 2013 at 06:38:22AM +1000, Dave Chinner wrote:
> On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
> > On 18.09.2013 11:10, Daniel Vetter wrote:
> > 
> > Just now I prepared a patch changing the same function in vmscan.c
> > >Also, this needs to be rebased to the new shrinker api in 3.12, I
> > >simply haven't rolled my trees forward yet.
> > 
> > Well, you should. Since commit 81e49f  shrinker->count_objects might be
> > set to SHRINK_STOP, causing shrink_slab_node() to complain loud and often:
> > 
> > [ 1908.234595] shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative 
> > objects to delete nr=-x
> > 
> > The kernel emitted a few thousand log lines like the one quoted above 
> > during the
> > last few days on my system.
> > 
> > >diff --git a/mm/vmscan.c b/mm/vmscan.c
> > >index 2cff0d4..d81f6e0 100644
> > >--- a/mm/vmscan.c
> > >+++ b/mm/vmscan.c
> > >@@ -254,6 +254,10 @@ unsigned long shrink_slab(struct shrink_control 
> > >*shrink,
> > >   total_scan = max_pass;
> > >   }
> > >+  /* Always try to shrink a bit to make forward progress. */
> > >+  if (shrinker->evicts_to_page_lru)
> > >+  total_scan = max_t(long, total_scan, batch_size);
> > >+
> > At that place the error message is already emitted.
> > >   /*
> > >* We need to avoid excessive windup on filesystem shrinkers
> > >* due to large numbers of GFP_NOFS allocations causing the
> > 
> > Have a look at the attached patch. It fixes my problem with the 
> > erroneous/misleading
> > error messages, and I think it´s right to just bail out early if 
> > SHRINK_STOP is found.
> > 
> > Do you agree ?
> 
> No, that's wrong. ->count_objects should never ass SHRINK_STOP.

*pass

> Indeed, it should always return a count of objects in the cache,
> regardless of the context. 
> 
> SHRINK_STOP is for ->scan_objects to tell the shrinker it can make

*can't

> any progress due to the context it is called in. This allows the
> shirnker to defer the work to another call in a different context.
> However, if ->count-objects doesn't return a count, the work that
> was supposed to be done cannot be deferred, and that is what

 *why

> ->count_objects should always return the number of objects in the
> cache.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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: [RFC PATCH] fpga: Introduce new fpga subsystem

[Ryan Mallon]

On 19/09/13 01:56, Michal Simek wrote:
> This new subsystem should unify all fpga drivers which
> do the same things. Load configuration data to fpga
> or another programmable logic through common interface.
> It doesn't matter if it is MMIO device, gpio bitbanging,
> etc. connection. The point is to have the same
> inteface for these drivers.
> 
> Signed-off-by: Michal Simek 

Hi Michal,

Some comments below.

~Ryan

> 
> ---
>  MAINTAINERS |   7 +
>  drivers/Kconfig |   2 +
>  drivers/Makefile|   1 +
>  drivers/fpga/Kconfig|  18 ++
>  drivers/fpga/Makefile   |   5 +
>  drivers/fpga/fpga-mgr.c | 433 
> 
>  include/linux/fpga.h| 105 
>  7 files changed, 571 insertions(+)
>  create mode 100644 drivers/fpga/Kconfig
>  create mode 100644 drivers/fpga/Makefile
>  create mode 100644 drivers/fpga/fpga-mgr.c
>  create mode 100644 include/linux/fpga.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e61c2e8..5c7597b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3427,6 +3427,13 @@ F: include/linux/fmc*.h
>  F:   include/linux/ipmi-fru.h
>  K:   fmc_d.*register
> 
> +FPGA SUBSYSTEM
> +M:   Michal Simek 
> +T:   git git://git.xilinx.com/linux-xlnx.git
> +S:   Supported
> +F:   drivers/fpga/
> +F:   include/linux/fpga.h
> +
>  FPU EMULATOR
>  M:   Bill Metzenthen 
>  W:   http://floatingpoint.sourceforge.net/emulator/index.html
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index aa43b91..17f3caa 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -166,4 +166,6 @@ source "drivers/reset/Kconfig"
> 
>  source "drivers/fmc/Kconfig"
> 
> +source "drivers/fpga/Kconfig"
> +
>  endmenu
> diff --git a/drivers/Makefile b/drivers/Makefile
> index ab93de8..2b5e73b 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -152,3 +152,4 @@ obj-$(CONFIG_VME_BUS) += vme/
>  obj-$(CONFIG_IPACK_BUS)  += ipack/
>  obj-$(CONFIG_NTB)+= ntb/
>  obj-$(CONFIG_FMC)+= fmc/
> +obj-$(CONFIG_FPGA)   += fpga/
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> new file mode 100644
> index 000..5357645
> --- /dev/null
> +++ b/drivers/fpga/Kconfig
> @@ -0,0 +1,18 @@
> +#
> +# FPGA framework configuration
> +#
> +
> +menu "FPGA devices"
> +
> +config FPGA
> + tristate "FPGA Framework"
> + help
> +   Say Y here if you want support for configuring FPGAs from the
> +   kernel.  The FPGA framework adds a FPGA manager class and FPGA
> +   manager drivers.
> +
> +if FPGA
> +
> +endif
> +
> +endmenu
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> new file mode 100644
> index 000..3c7f29b
> --- /dev/null
> +++ b/drivers/fpga/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the fpga framework and fpga manager drivers.
> +#
> +
> +obj-$(CONFIG_FPGA)   += fpga-mgr.o
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> new file mode 100644
> index 000..7312efd
> --- /dev/null
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -0,0 +1,433 @@
> +/*
> + * FPGA Framework
> + *
> + * Copyright (C) 2013 Xilinx, Inc.
> + *
> + * based on origin code from
> + * Copyright (C) 2013 Altera Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static struct idr fpga_mgr_idr;
> +static spinlock_t fpga_mgr_idr_lock;
> +static struct class *fpga_mgr_class;

Use the initialisers where available:

  static DEFINE_IDR(fpga_mgr_idr);
  static DEFINE_SPINLOCK(fpga_mgr_idr_lock);

> +/**
> + * fpga_mgr_name_show - Show fpga manager name
> + * @dev: Pointer to the device structure
> + * @attr: Pointer to the device attribute structure
> + * @buf: Pointer to the buffer location
> + *
> + * Returns the number of bytes copied to @buf, a negative error number 
> otherwise
> + */
> +static ssize_t fpga_mgr_name_show(struct device *dev,
> +   struct device_attribute *attr, char *buf)
> +{
> + struct fpga_manager *mgr = dev_get_drvdata(dev);
> +
> + if (!mgr)
> + return -ENODEV;
> +
> + return snprintf(buf, sizeof(mgr->name), "%s\n", mgr->name);
> +}
> +
> +/**
> + * fpga_mgr_status_show - Show fpga manager status
> + * @dev: Pointer to the device 

Re: [PATCH v3] ARM: pxa: sharpsl_param.c: fix invalid memory access

[Russell King - ARM Linux]

On Thu, Sep 19, 2013 at 01:18:39AM +0200, Andrea Adami wrote:
> After commit 72662e01088394577be4a3f14da94cf87bea2591
> ARM: head.S: only include __turn_mmu_on in the initial identity mapping
> 
> Zaurus PXA devices call sharpsl_save_param() during fixup and hang on
> boot because memcpy refers to physical addresses no longer valid if the
> MMU is setup.
> Zaurus collie (SA1100) is unaffected (function is called in init_machine).

Yes, moving that will have broken this, but that's only because this code
is making assumptions about stuff which we don't really "guarantee" will
be the case.  For PXA, moving it to use the virtual address is the right
solution, one which would've worked before the change too.

For SA11x0 - I suspect 0xe8ffc000 is a virtual address already (it
points into the main flash) so I think this is okay.

Some comments though:

> diff --git a/arch/arm/common/sharpsl_param.c b/arch/arm/common/sharpsl_param.c
> index d56c932..4dcd349 100644
> --- a/arch/arm/common/sharpsl_param.c
> +++ b/arch/arm/common/sharpsl_param.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Certain hardware parameters determined at the time of device manufacture,
> @@ -23,6 +24,8 @@
>   * them early in the boot process, then pass them to the appropriate drivers.
>   * Not all devices use all parameters but the format is common to all.
>   */
> +
> +

Please be more careful about adding extraneous blank lines/spaces to files.

>  #ifdef CONFIG_ARCH_SA1100
>  #define PARAM_BASE   0xe8ffc000
>  #else
> @@ -41,7 +44,17 @@ EXPORT_SYMBOL(sharpsl_param);
>  
>  void sharpsl_save_param(void)
>  {
> - memcpy(_param, (void *)PARAM_BASE, sizeof(struct 
> sharpsl_param_info));
> +/* NOTE:
> + * Zaurus PXA devices call sharpsl_save_param() during fixup and the MMU
> + * is setup so we need to translate the physical address.
> + * Zaurus collie (SA1100) is unaffected (function is called in init_machine).
> + */
> +#ifdef CONFIG_ARCH_SA1100
> + void *param_start = (void *)PARAM_BASE;
> +#else
> + void *param_start = phys_to_virt(PARAM_BASE);
> +#endif
> + memcpy(_param, param_start, sizeof(struct sharpsl_param_info));

I'd suggest moving the (void *) cast to the #defines above, and also the
phys_to_virt() too.  With a reasonable commit log, I don't think we need
the comments either.

> @@ -58,5 +71,3 @@ void sharpsl_save_param(void)
>   if (sharpsl_param.adadj_keyword != AD_MAGIC)
>   sharpsl_param.adadj=-1;
>  }
> -
> -

While removal of lines is a good thing, this isn't really part of this
patch, but I'd say in this case don't worry about that.

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

Re: [PATCH v2] clk: si570: Add a driver for SI570 oscillators

[Sören Brinkmann]

On Wed, Sep 18, 2013 at 04:18:56PM -0700, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:09 -0700, Sören Brinkmann wrote:
> > On Wed, Sep 18, 2013 at 04:02:41PM -0700, Joe Perches wrote:
> > > On Wed, 2013-09-18 at 15:43 -0700, Soren Brinkmann wrote:
> > > > Add a driver for SILabs 570, 571, 598, 599 programmable oscillators.
> > > > The devices generate low-jitter clock signals and are reprogrammable via
> > > > an I2C interface.
> > > []
> > > > v2:
> > > []
> > > >  - use 1 as MIN and MAX value in usleep_range
> > > []
> > > > diff --git a/drivers/clk/clk-si570.c b/drivers/clk/clk-si570.c
> > > []
> > > > +static int si570_set_frequency(struct clk_si570 *data, unsigned long 
> > > > frequency)
> > > > +{
> > > []
> > > > +   /* Applying a new frequency can take up to 10ms */
> > > > +   usleep_range(1, 1);
> > > 
> > > Generally it's nicer to have an actual range for usleep_range.
> > Well, as I said in the discussion with Guenther. I'm flexible and nobody
> > objected when I said to make both equal. A real range doesn't make sense
> > here though, but I don't know what's common practice for cases like
> > this.
> 
> udelay is normal, but I guess you don't need atomic context.
After checkpatch correcting me a few times I went with what
Documentation/timers/timers-howto.txt suggests. But yes, then we have
this situation, that I want to sleep 10ms, but not longer using a
*_range function. I guess it is very application specific whether a
longer delay here is acceptable or not.

>  
> > > Is there a bit you could periodically poll to see
> > > if the new frequency has been set or is stable so
> > > that a 10ms delay isn't always used?
> 
> > Unfortunately not.
> 
> Thanks.  I suppose I should read the datasheets before asking.
> 
> http://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf
> (page 12)
> 
> Anyway, perhaps si570_set_frequency_small needs a delay too.'
> 
> The 570 datasheet says it needs a 100uS delay.
You're right. I'll add a delay there as well. The 'rang' question
applies here as well.

Sören


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

Re: [PATCH 4/7] perf completion: modernize style

[Ramkumar Ramachandra]

Hi Arnaldo,

Arnaldo Carvalho de Melo wrote:
> Can you check how is this in the current perf/core branch so that we can
> move forward while I process some other patches?

perf/completion is now 3 months old, and my more recent patches have
already been merged into Linus' tree. Why is perf/completion being
held up? It should be trivial enough to merge, no?

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/

[PATCH v3 RFT 2/2] PM / Hibernate: use name_to_dev_t to parse resume

[Sebastian Capella]

Use the name_to_dev_t call to parse the device name echo'd to
to /sys/power/resume.  This imitates the method used in hibernate.c
in software_resume, and allows the resume partition to be specified
using other equivalent device formats as well.  By allowing
/sys/debug/resume to accept the same syntax as the resume=device
parameter, we can parse the resume=device in the init script and
use the resume device directly from the kernel command line.

Signed-off-by: Sebastian Capella 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: "Rafael J. Wysocki" 
---
 kernel/power/hibernate.c |   15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index b26f5f1..8b253c2 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -971,16 +971,11 @@ static ssize_t resume_show(struct kobject *kobj, struct 
kobj_attribute *attr,
 static ssize_t resume_store(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t n)
 {
-   unsigned int maj, min;
dev_t res;
-   int ret = -EINVAL;
 
-   if (sscanf(buf, "%u:%u", , ) != 2)
-   goto out;
-
-   res = MKDEV(maj,min);
-   if (maj != MAJOR(res) || min != MINOR(res))
-   goto out;
+   res = name_to_dev_t(buf);
+   if (res == 0)
+   return -EINVAL;
 
lock_system_sleep();
swsusp_resume_device = res;
@@ -988,9 +983,7 @@ static ssize_t resume_store(struct kobject *kobj, struct 
kobj_attribute *attr,
printk(KERN_INFO "PM: Starting manual resume from disk\n");
noresume = 0;
software_resume();
-   ret = n;
- out:
-   return ret;
+   return n;
 }
 
 power_attr(resume);
-- 
1.7.9.5

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

[PATCH v3 RFT 1/2] init/do_mounts.c: ignore final \n in name_to_dev_t

[Sebastian Capella]

Enhance name_to_dev_t to handle trailing newline characters
on device paths.  Some inputs to name_to_dev_t may come from
userspace where oftentimes a '\n' is appended to the path.
Added const to the name buffer in both the function
declaration and the prototype to reflect input buffer
handling.

By handling trailing newlines in name_to_dev_t, userspace
buffers may be directly passed to name_to_dev_t without
modification.

Signed-off-by: Sebastian Capella 
Cc: Pavel Machek 
Cc: "Eric W. Biederman" 
Cc: Serge Hallyn 
Cc: Andrew Morton 
Cc: Stephen Warren 
Cc: Jens Axboe 
Cc: Greg Kroah-Hartman 
Cc: Al Viro 
---
 include/linux/mount.h |2 +-
 init/do_mounts.c  |   25 +++--
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/include/linux/mount.h b/include/linux/mount.h
index 73005f9..b024d5c 100644
--- a/include/linux/mount.h
+++ b/include/linux/mount.h
@@ -76,6 +76,6 @@ extern struct vfsmount *vfs_kern_mount(struct 
file_system_type *type,
 extern void mnt_set_expiry(struct vfsmount *mnt, struct list_head 
*expiry_list);
 extern void mark_mounts_for_expiry(struct list_head *mounts);
 
-extern dev_t name_to_dev_t(char *name);
+extern dev_t name_to_dev_t(const char *name);
 
 #endif /* _LINUX_MOUNT_H */
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 816014c..5a031de 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -143,6 +143,13 @@ static dev_t devt_from_partuuid(const char *uuid_str)
clear_root_wait = true;
goto done;
}
+   if (uuid_str[cmp.len - 1] == '\n') {
+   cmp.len--;
+   if (!cmp.len) {
+   clear_root_wait = true;
+   goto done;
+   }
+   }
 
dev = class_find_device(_class, NULL, ,
_dev_by_uuid);
@@ -202,12 +209,13 @@ done:
  * bangs.
  */
 
-dev_t name_to_dev_t(char *name)
+dev_t name_to_dev_t(const char *name)
 {
char s[32];
char *p;
dev_t res = 0;
int part;
+   int n;
 
 #ifdef CONFIG_BLOCK
if (strncmp(name, "PARTUUID=", 9) == 0) {
@@ -228,7 +236,7 @@ dev_t name_to_dev_t(char *name)
goto fail;
} else {
res = new_decode_dev(simple_strtoul(name, , 16));
-   if (*p)
+   if (*p && *p != '\n')
goto fail;
}
goto done;
@@ -236,15 +244,20 @@ dev_t name_to_dev_t(char *name)
 
name += 5;
res = Root_NFS;
-   if (strcmp(name, "nfs") == 0)
+   if (strncmp(name, "nfs", 3) == 0)
goto done;
res = Root_RAM0;
-   if (strcmp(name, "ram") == 0)
+   if (strncmp(name, "ram", 3) == 0)
goto done;
 
-   if (strlen(name) > 31)
+   n = strlen(name);
+   if (n != 0 && name[n - 1] == '\n')
+   n--;
+   if (n > 31)
goto fail;
-   strcpy(s, name);
+   strncpy(s, name, n);
+   s[n] = '\0';
+
for (p = s; *p; p++)
if (*p == '/')
*p = '!';
-- 
1.7.9.5

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

[PATCH v3 RFT 0/2] PM / Hibernate: sysfs resume

[Sebastian Capella]

Patchset related to hibernation resume: one enhancement to make the use
of an existing resume file more general and one enhances name_to_dev_t
to ignore the trailing newlines coming from userspace.

Both patches are based on the 3.11 tag.  This was tested on a
Pandaboard with partial hibernation support, and compiled for x86.

Further testing is needed on other platforms.  Please let me know if
you're able to verify this on any other systems.

[PATCH 1/2] init/do_mounts.c: ignore final \n in name_to_dev_t
  init/do_mounts.c |   23 ++-
  1 file changed, 18 insertions(+), 5 deletions(-)

  Changes name_to_dev_t to handle a trailing newline in the
  input buffer, which will allow name_to_dev_t to be used
  directly with user buffers without requiring a copy.
  Also adds a const to the name parameter which reflects
  how name_to_dev_t is treating the input buffer currently.
  This also allows direct use of user buffers
  (from resume_store for example).

[PATCH 2/2] PM / Hibernate: use name_to_dev_t to parse resume
  kernel/power/hibernate.c |   15 ---
  1 file changed, 4 insertions(+), 11 deletions(-)

  Use name_to_dev_t to parse the /sys/power/resume file making the
  syntax more flexible.  It supports the previous use syntax
  and additionally can support other formats such as
  /dev/devicenode and UUID= formats.

  By changing /sys/debug/resume to accept the same syntax as
  the resume=device parameter, we can parse the resume=device
  in the initrd init script and use the resume device directly
  from the kernel command line.

Changes in v3:
--
* Dropped documentation patch as it went in through trivial
* Added patch for name_to_dev_t to support directly parsing userspace
  buffer

Changes in v2:
--
* Added check for null return of kstrndup in hibernate.c


Thanks,

Sebastian

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

RE: [PATCH V2 1/1] Drivers: input: serio: New driver to support Hyper-V synthetic keyboard

[KY Srinivasan]

> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: Wednesday, September 18, 2013 2:01 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; dan.carpen...@oracle.com; linux-
> in...@vger.kernel.org; vojt...@suse.cz
> Subject: Re: [PATCH V2 1/1] Drivers: input: serio: New driver to support 
> Hyper-V
> synthetic keyboard
> 
> Hi K.Y.,
> 
> On Tue, Sep 17, 2013 at 04:26:58PM -0700, K. Y. Srinivasan wrote:
> > Add a new driver to support synthetic keyboard. On the next generation
> > Hyper-V guest firmware, many legacy devices will not be emulated and this
> > driver will be required.
> >
> > I would like to thank Vojtech Pavlik  for helping me with 
> > the
> > details of the AT keyboard driver. I would also like to thank
> > Dan Carpenter  and
> > Dmitry Torokhov  for their detailed review of
> this
> > driver.
> >
> > I have addressed all the comments of Dan and Dmitry in this version of
> > the patch
> 
> This looks much better. Could you tell me if the patch below (on top of
> yours) still works?
> 
> Thanks.

Thank you. The code looks much better now. You forgot to initialize the 
port_data and
after I fixed that everything seems to work as it did before: Here is the patch 
I used:

> -Original Message-
> From: K. Y. Srinivasan [mailto:k...@microsoft.com]
> Sent: Wednesday, September 18, 2013 4:50 PM
> To: KY Srinivasan
> Subject: [PATCH 1/1] Drivers: input: serio: hyper-V: Initialize the port data
> correctly
> 
> 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  drivers/input/serio/hyperv-keyboard.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/input/serio/hyperv-keyboard.c 
> b/drivers/input/serio/hyperv-
> keyboard.c
> index 401fbdd..aff4152 100644
> --- a/drivers/input/serio/hyperv-keyboard.c
> +++ b/drivers/input/serio/hyperv-keyboard.c
> @@ -351,6 +351,7 @@ static int hv_kbd_probe(struct hv_device *hv_dev,
> 
>   hv_serio->dev.parent  = _dev->device;
>   hv_serio->id.type = SERIO_8042_XL;
> + hv_serio->port_data = kbd_dev;
>   strlcpy(hv_serio->name, dev_name(_dev->device),
>   sizeof(hv_serio->name));
>   strlcpy(hv_serio->phys, dev_name(_dev->device),
> --
> 1.7.4.1


Once again; thank you for all your help.

Regards,

K. Y

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tools lib lk: Uninclude linux/magic.h in debugfs.c.

[Vinson Lee]

From: Vinson Lee 

The compilation only looks for linux/magic.h from the default include
paths, which does not include the source tree. This results in a build
error if linux/magic.h is not available or not installed.

For example, this build error occurs on CentOS 5.

$ make -C tools/lib/lk V=1
[...]
gcc -o debugfs.o -c -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6
-D_FORTIFY_SOURCE=2 -Wbad-function-cast -Wdeclaration-after-statement
-Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-system-headers
-Wold-style-definition -Wpacked -Wredundant-decls -Wshadow
-Wstrict-aliasing=3 -Wstrict-prototypes -Wswitch-default -Wswitch-enum
-Wundef -Wwrite-strings -Wformat  -fPIC  -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 debugfs.c
debugfs.c:8:25: error: linux/magic.h: No such file or directory

The only symbol from linux/magic.h needed by debugfs.c is DEBUGFS_MAGIC,
and that is already defined in debugfs.h. linux/magic.h isn't providing
any extra symbols and can unincluded. This is similar to the approach by
perf, which has its own magic.h wrapper at
tools/perf/util/include/linux/magic.h

Signed-off-by: Vinson Lee 
Cc: sta...@vger.kernel.org # 3.10+
---
 tools/lib/lk/debugfs.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/lib/lk/debugfs.c b/tools/lib/lk/debugfs.c
index 099e7cd..7c43479 100644
--- a/tools/lib/lk/debugfs.c
+++ b/tools/lib/lk/debugfs.c
@@ -5,7 +5,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "debugfs.h"
-- 
1.8.2.1

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

Re: [PATCH v2] clk: si570: Add a driver for SI570 oscillators

[Joe Perches]

On Wed, 2013-09-18 at 16:09 -0700, Sören Brinkmann wrote:
> On Wed, Sep 18, 2013 at 04:02:41PM -0700, Joe Perches wrote:
> > On Wed, 2013-09-18 at 15:43 -0700, Soren Brinkmann wrote:
> > > Add a driver for SILabs 570, 571, 598, 599 programmable oscillators.
> > > The devices generate low-jitter clock signals and are reprogrammable via
> > > an I2C interface.
> > []
> > > v2:
> > []
> > >  - use 1 as MIN and MAX value in usleep_range
> > []
> > > diff --git a/drivers/clk/clk-si570.c b/drivers/clk/clk-si570.c
> > []
> > > +static int si570_set_frequency(struct clk_si570 *data, unsigned long 
> > > frequency)
> > > +{
> > []
> > > + /* Applying a new frequency can take up to 10ms */
> > > + usleep_range(1, 1);
> > 
> > Generally it's nicer to have an actual range for usleep_range.
> Well, as I said in the discussion with Guenther. I'm flexible and nobody
> objected when I said to make both equal. A real range doesn't make sense
> here though, but I don't know what's common practice for cases like
> this.

udelay is normal, but I guess you don't need atomic context.
 
> > Is there a bit you could periodically poll to see
> > if the new frequency has been set or is stable so
> > that a 10ms delay isn't always used?

> Unfortunately not.

Thanks.  I suppose I should read the datasheets before asking.

http://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf
(page 12)

Anyway, perhaps si570_set_frequency_small needs a delay too.'

The 570 datasheet says it needs a 100uS delay.

> On Wed, 2013-09-18 at 15:43 -0700, Soren Brinkmann wrote:
> Add a driver for SILabs 570, 571, 598, 599 programmable oscillators.
> The devices generate low-jitter clock signals and are reprogrammable via
> an I2C interface.
> []
> +static int si570_set_frequency_small(struct clk_si570 *data,
> +  unsigned long frequency)
> +{
> + /*
> +  * This is a re-implementation of DIV_ROUND_CLOSEST
> +  * using the div64_u64 function lieu of letting the compiler
> +  * insert EABI calls
> +  */
> + data->rfreq = div64_u64((data->rfreq * frequency) +
> + div_u64(data->frequency, 2), data->frequency);
> + regmap_write(data->regmap, SI570_REG_CONTROL, SI570_CNTRL_FREEZE_M);
> + si570_update_rfreq(data);
> + regmap_write(data->regmap, SI570_REG_CONTROL, 0);
> +
> + return 0;
> +}


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

[PATCH v3] ARM: pxa: sharpsl_param.c: fix invalid memory access

[Andrea Adami]

After commit 72662e01088394577be4a3f14da94cf87bea2591
ARM: head.S: only include __turn_mmu_on in the initial identity mapping

Zaurus PXA devices call sharpsl_save_param() during fixup and hang on
boot because memcpy refers to physical addresses no longer valid if the
MMU is setup.
Zaurus collie (SA1100) is unaffected (function is called in init_machine).

Signed-off-by: Marko Katic 
Signed-off-by: Andrea Adami 
---
 arch/arm/common/sharpsl_param.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/arm/common/sharpsl_param.c b/arch/arm/common/sharpsl_param.c
index d56c932..4dcd349 100644
--- a/arch/arm/common/sharpsl_param.c
+++ b/arch/arm/common/sharpsl_param.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Certain hardware parameters determined at the time of device manufacture,
@@ -23,6 +24,8 @@
  * them early in the boot process, then pass them to the appropriate drivers.
  * Not all devices use all parameters but the format is common to all.
  */
+
+
 #ifdef CONFIG_ARCH_SA1100
 #define PARAM_BASE 0xe8ffc000
 #else
@@ -41,7 +44,17 @@ EXPORT_SYMBOL(sharpsl_param);
 
 void sharpsl_save_param(void)
 {
-   memcpy(_param, (void *)PARAM_BASE, sizeof(struct 
sharpsl_param_info));
+/* NOTE:
+ * Zaurus PXA devices call sharpsl_save_param() during fixup and the MMU
+ * is setup so we need to translate the physical address.
+ * Zaurus collie (SA1100) is unaffected (function is called in init_machine).
+ */
+#ifdef CONFIG_ARCH_SA1100
+   void *param_start = (void *)PARAM_BASE;
+#else
+   void *param_start = phys_to_virt(PARAM_BASE);
+#endif
+   memcpy(_param, param_start, sizeof(struct sharpsl_param_info));
 
if (sharpsl_param.comadj_keyword != COMADJ_MAGIC)
sharpsl_param.comadj=-1;
@@ -58,5 +71,3 @@ void sharpsl_save_param(void)
if (sharpsl_param.adadj_keyword != AD_MAGIC)
sharpsl_param.adadj=-1;
 }
-
-
-- 
1.8.1.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 2/2] x86_64: Add safe check in a.out loaders and some coding style

[Geyslan Gregório Bem]

Now it's ok.

Geyslan Gregório Bem
hackingbits.com


2013/9/18 Geyslan G. Bem :
> ia32_aout had no safe checks concerning the mmap and f_op in this module.
> It's not necessary to verify f_op in the load_aout_library, since the
> prior kernel_read/vfs_read function already does.
> Coding style and printks fixes.
>
> Tested using qemu, a handcrafted a.out binary and a a.out linked with a
> cross-compiled ld.
>
> Signed-off-by: Geyslan G. Bem 
> ---
>  arch/x86/ia32/ia32_aout.c | 51 
> +++
>  1 file changed, 25 insertions(+), 26 deletions(-)
>
> diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
> index bae3aba..a5f3e66 100644
> --- a/arch/x86/ia32/ia32_aout.c
> +++ b/arch/x86/ia32/ia32_aout.c
> @@ -24,7 +24,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include 
>  #include 
> @@ -271,10 +271,17 @@ static int load_aout_binary(struct linux_binprm *bprm)
>  N_MAGIC(ex) != QMAGIC && N_MAGIC(ex) != NMAGIC) ||
> N_TRSIZE(ex) || N_DRSIZE(ex) ||
> i_size_read(file_inode(bprm->file)) <
> -   ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
> +   ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
> return -ENOEXEC;
> }
>
> +   /*
> +* Requires a mmap handler. This prevents people from using a.out
> +* as part of an exploit attack against /proc-related vulnerabilities.
> +*/
> +   if (!bprm->file->f_op || !bprm->file->f_op->mmap)
> +   return -ENOEXEC;
> +
> fd_offset = N_TXTOFF(ex);
>
> /* Check initial limits. This avoids letting people circumvent
> @@ -339,25 +346,16 @@ static int load_aout_binary(struct linux_binprm *bprm)
> }
> } else {
>  #ifdef WARN_OLD
> -   static unsigned long error_time, error_time2;
> if ((ex.a_text & 0xfff || ex.a_data & 0xfff) &&
> -   (N_MAGIC(ex) != NMAGIC) &&
> -   time_after(jiffies, error_time2 + 5*HZ)) {
> -   printk(KERN_NOTICE "executable not page aligned\n");
> -   error_time2 = jiffies;
> -   }
> +   (N_MAGIC(ex) != NMAGIC))
> +   pr_notice_ratelimited("executable not page 
> aligned\n");
>
> -   if ((fd_offset & ~PAGE_MASK) != 0 &&
> -   time_after(jiffies, error_time + 5*HZ)) {
> -   printk(KERN_WARNING
> -  "fd_offset is not page aligned. Please convert 
> "
> -  "program: %s\n",
> -  bprm->file->f_path.dentry->d_name.name);
> -   error_time = jiffies;
> -   }
> +   if ((fd_offset & ~PAGE_MASK) != 0)
> +   pr_warn_ratelimited("fd_offset is not page aligned. 
> Please convert program: %s\n",
> +   
> bprm->file->f_path.dentry->d_name.name);
>  #endif
>
> -   if (!bprm->file->f_op->mmap || (fd_offset & ~PAGE_MASK) != 0) 
> {
> +   if ((fd_offset & ~PAGE_MASK) != 0) {
> vm_brk(N_TXTADDR(ex), ex.a_text+ex.a_data);
> read_code(bprm->file, N_TXTADDR(ex), fd_offset,
> ex.a_text+ex.a_data);
> @@ -424,10 +422,17 @@ static int load_aout_library(struct file *file)
> if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != QMAGIC) || N_TRSIZE(ex) 
> ||
> N_DRSIZE(ex) || ((ex.a_entry & 0xfff) && N_MAGIC(ex) == ZMAGIC) ||
> i_size_read(file_inode(file)) <
> -   ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
> +   ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
> goto out;
> }
>
> +   /*
> +* Requires a mmap handler. This prevents people from using a.out
> +* as part of an exploit attack against /proc-related vulnerabilities.
> +*/
> +   if (!file->f_op->mmap)
> +   goto out;
> +
> if (N_FLAGS(ex))
> goto out;
>
> @@ -438,14 +443,8 @@ static int load_aout_library(struct file *file)
>
> if ((N_TXTOFF(ex) & ~PAGE_MASK) != 0) {
>  #ifdef WARN_OLD
> -   static unsigned long error_time;
> -   if (time_after(jiffies, error_time + 5*HZ)) {
> -   printk(KERN_WARNING
> -  "N_TXTOFF is not page aligned. Please convert "
> -  "library: %s\n",
> -  file->f_path.dentry->d_name.name);
> -   error_time = jiffies;
> -   }
> +   pr_warn_ratelimited("N_TXTOFF is not page aligned. Please 
> convert library: %s\n",
> +   file->f_path.dentry->d_name.name);
>  #endif
> vm_brk(start_addr, 

[PATCH 2/2] x86_64: Add safe check in a.out loaders and some coding style

[Geyslan G. Bem]

ia32_aout had no safe checks concerning the mmap and f_op in this module.
It's not necessary to verify f_op in the load_aout_library, since the
prior kernel_read/vfs_read function already does.
Coding style and printks fixes.

Tested using qemu, a handcrafted a.out binary and a a.out linked with a
cross-compiled ld.

Signed-off-by: Geyslan G. Bem 
---
 arch/x86/ia32/ia32_aout.c | 51 +++
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index bae3aba..a5f3e66 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
@@ -271,10 +271,17 @@ static int load_aout_binary(struct linux_binprm *bprm)
 N_MAGIC(ex) != QMAGIC && N_MAGIC(ex) != NMAGIC) ||
N_TRSIZE(ex) || N_DRSIZE(ex) ||
i_size_read(file_inode(bprm->file)) <
-   ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+   ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
return -ENOEXEC;
}
 
+   /*
+* Requires a mmap handler. This prevents people from using a.out
+* as part of an exploit attack against /proc-related vulnerabilities.
+*/
+   if (!bprm->file->f_op || !bprm->file->f_op->mmap)
+   return -ENOEXEC;
+
fd_offset = N_TXTOFF(ex);
 
/* Check initial limits. This avoids letting people circumvent
@@ -339,25 +346,16 @@ static int load_aout_binary(struct linux_binprm *bprm)
}
} else {
 #ifdef WARN_OLD
-   static unsigned long error_time, error_time2;
if ((ex.a_text & 0xfff || ex.a_data & 0xfff) &&
-   (N_MAGIC(ex) != NMAGIC) &&
-   time_after(jiffies, error_time2 + 5*HZ)) {
-   printk(KERN_NOTICE "executable not page aligned\n");
-   error_time2 = jiffies;
-   }
+   (N_MAGIC(ex) != NMAGIC))
+   pr_notice_ratelimited("executable not page aligned\n");
 
-   if ((fd_offset & ~PAGE_MASK) != 0 &&
-   time_after(jiffies, error_time + 5*HZ)) {
-   printk(KERN_WARNING
-  "fd_offset is not page aligned. Please convert "
-  "program: %s\n",
-  bprm->file->f_path.dentry->d_name.name);
-   error_time = jiffies;
-   }
+   if ((fd_offset & ~PAGE_MASK) != 0)
+   pr_warn_ratelimited("fd_offset is not page aligned. 
Please convert program: %s\n",
+   
bprm->file->f_path.dentry->d_name.name);
 #endif
 
-   if (!bprm->file->f_op->mmap || (fd_offset & ~PAGE_MASK) != 0) {
+   if ((fd_offset & ~PAGE_MASK) != 0) {
vm_brk(N_TXTADDR(ex), ex.a_text+ex.a_data);
read_code(bprm->file, N_TXTADDR(ex), fd_offset,
ex.a_text+ex.a_data);
@@ -424,10 +422,17 @@ static int load_aout_library(struct file *file)
if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != QMAGIC) || N_TRSIZE(ex) ||
N_DRSIZE(ex) || ((ex.a_entry & 0xfff) && N_MAGIC(ex) == ZMAGIC) ||
i_size_read(file_inode(file)) <
-   ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+   ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
goto out;
}
 
+   /*
+* Requires a mmap handler. This prevents people from using a.out
+* as part of an exploit attack against /proc-related vulnerabilities.
+*/
+   if (!file->f_op->mmap)
+   goto out;
+
if (N_FLAGS(ex))
goto out;
 
@@ -438,14 +443,8 @@ static int load_aout_library(struct file *file)
 
if ((N_TXTOFF(ex) & ~PAGE_MASK) != 0) {
 #ifdef WARN_OLD
-   static unsigned long error_time;
-   if (time_after(jiffies, error_time + 5*HZ)) {
-   printk(KERN_WARNING
-  "N_TXTOFF is not page aligned. Please convert "
-  "library: %s\n",
-  file->f_path.dentry->d_name.name);
-   error_time = jiffies;
-   }
+   pr_warn_ratelimited("N_TXTOFF is not page aligned. Please 
convert library: %s\n",
+   file->f_path.dentry->d_name.name);
 #endif
vm_brk(start_addr, ex.a_text + ex.a_data + ex.a_bss);
 
-- 
1.8.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 v2] clk: si570: Add a driver for SI570 oscillators

[Sören Brinkmann]

On Wed, Sep 18, 2013 at 04:02:41PM -0700, Joe Perches wrote:
> On Wed, 2013-09-18 at 15:43 -0700, Soren Brinkmann wrote:
> > Add a driver for SILabs 570, 571, 598, 599 programmable oscillators.
> > The devices generate low-jitter clock signals and are reprogrammable via
> > an I2C interface.
> []
> > v2:
> []
> >  - use 1 as MIN and MAX value in usleep_range
> []
> > diff --git a/drivers/clk/clk-si570.c b/drivers/clk/clk-si570.c
> []
> > +static int si570_set_frequency(struct clk_si570 *data, unsigned long 
> > frequency)
> > +{
> []
> > +   /* Applying a new frequency can take up to 10ms */
> > +   usleep_range(1, 1);
> 
> Generally it's nicer to have an actual range for usleep_range.
Well, as I said in the discussion with Guenther. I'm flexible and nobody
objected when I said to make both equal. A real range doesn't make sense
here though, but I don't know what's common practice for cases like
this.

> 
> Is there a bit you could periodically poll to see
> if the new frequency has been set or is stable so
> that a 10ms delay isn't always used?

Unfortunately not. The data sheet describes one bit which is cleared
when the new frequency configuration is applied, but it seems to be
cleared before the output is actually stable/enabled. At least our
testing failed when some driver changed the frequency and continued
operation w/o this additional delay.

Sören


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clk: si570: Add a driver for SI570 oscillators

[Joe Perches]

On Wed, 2013-09-18 at 15:43 -0700, Soren Brinkmann wrote:
> Add a driver for SILabs 570, 571, 598, 599 programmable oscillators.
> The devices generate low-jitter clock signals and are reprogrammable via
> an I2C interface.
[]
> v2:
[]
>  - use 1 as MIN and MAX value in usleep_range
[]
> diff --git a/drivers/clk/clk-si570.c b/drivers/clk/clk-si570.c
[]
> +static int si570_set_frequency(struct clk_si570 *data, unsigned long 
> frequency)
> +{
[]
> + /* Applying a new frequency can take up to 10ms */
> + usleep_range(1, 1);

Generally it's nicer to have an actual range for usleep_range.

Is there a bit you could periodically poll to see
if the new frequency has been set or is stable so
that a 10ms delay isn't always used?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [dtc RFC PATCH] Enforce node name unit-address presence/absence

[Stephen Warren]

On 09/18/2013 02:41 PM, Olof Johansson wrote:
> On Wed, Sep 18, 2013 at 1:23 PM, Stephen Warren  wrote:
>> From: Stephen Warren 
>>
>> ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
>> node that has a reg property must include a unit address in its name
>> with value matching the first entry in its reg property. Conversely, if
>> a node does not have a reg property, the node name must not include a
>> unit address.
>>
>> Implement a check for this. The code doesn't validate the format of the
>> unit address; ePAPR implies this may vary from binding to binding, so
>> I'm not sure that it's possible to validate the value itself.
...
> Anyway, I think it'd be better to produce warnings than errors for
> this. That way we could also merge it now while the trees are fixed
> up.

Yes, that makes sense.

> Also, maybe warn for @0x, which is another unpreferred syntax, it
> should just be @ (with foo being in hex).

ePAPR doesn't seem to disallow that; it explicitly says that the
unit-address consists of the characters from table 2-1, which is the
same table of characters used for the node name itself. However, it does
state that the binding for a particular bus may impose additional
restrictions; should I implement such a check but limit it to the root
node or specific known bus types? That would require explicitly
whitelisting the check for a lot of bus types, given that each I2C/...
controller binding is a bus type...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 vmstat: On demand vmstat threads

[Thomas Gleixner]

On Wed, 18 Sep 2013, Andrew Morton wrote:
> On Tue, 10 Sep 2013 21:13:34 + Christoph Lameter  wrote:
> > +   cpumask_copy(monitored_cpus, cpu_online_mask);
> > +   cpumask_clear_cpu(tick_do_timer_cpu, monitored_cpus);
> 
> What on earth are we using tick_do_timer_cpu for anyway? 
> tick_do_timer_cpu is cheerfully undocumented, as is this code's use of
> it.

tick_do_timer_cpu is a timer core internal variable, which holds the
CPU NR which is responsible for calling do_timer(), i.e. the
timekeeping stuff. This variable has two functions:

1) Prevent a thundering herd issue of a gazillion of CPUs trying to
   grab the timekeeping lock all at once. Only the CPU which is
   assigned to do the update is handling it.

2) Hand off the duty in the NOHZ idle case by setting the value to
   TICK_DO_TIMER_NONE, i.e. a non existing CPU. So the next cpu which
   looks at it will take over and keep the time keeping alive.
   The hand over procedure also covers cpu hotplug.

(Ab)Using it for anything else outside the timers core code is just
broken.

It's working for Christophs use case as his setup will not change the
assignment away from the boot cpu, but that's really not a brilliant
design to start with.

The vmstat accounting is not the only thing which we want to delegate
to dedicated core(s) for the full NOHZ mode.

So instead of playing broken games with explicitly not exposed core
code variables, we should implement a core code facility which is
aware of the NOHZ details and provides a sane way to delegate stuff to
a certain subset of CPUs.

Thanks,

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

Vážení E-mail užívateľa;

[webmail update]

Pre všetky e-mailového konta užívateľa.

Vezmite prosím na vedomie, že váš e-mailový účet prekročil
skladovacie kapacity. Nebudete môcť odosielať a prijímať e-maily a vaše
e-mailové konto, budú odstránené z nášho servera. Ak sa chcete tomuto
problému vyhnúť,
Kliknite na odkaz nižšie pre aktualizáciu vášho účtu.

http://webmailupdateonline2212.jimdo.com/


Ďakujeme vám za vašu spoluprácu,

S pozdravom,
WebSupport tím

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

[git pull] vfs and fs fixes

[Al Viro]

atomic_open-related fixes (Miklos' series, with EEXIST-related parts replaced
with fix in fs/namei.c:atomic_open() instead of messing with the instances)
+ race fix in autofs + leak on failure exit in 9p.  Please, pull from the
usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

Shortlog:
Al Viro (3):
  autofs4: close the races around autofs4_notify_daemon()
  atomic_open: take care of EEXIST in no-open case with O_CREAT|O_EXCL in 
fs/namei.c
  9p: don't forget to destroy inode cache if fscache registration fails

Miklos Szeredi (5):
  vfs: improve i_op->atomic_open() documentation
  cifs: fix filp leak in cifs_atomic_open()
  gfs2: set FILE_CREATED
  nfs: set FILE_CREATED
  vfs: don't set FILE_CREATED before calling ->atomic_open()

Diffstat:
 Documentation/filesystems/vfs.txt |   14 +++---
 fs/9p/v9fs.c  |7 ---
 fs/9p/vfs_inode_dotl.c|8 +---
 fs/autofs4/waitq.c|   13 +++--
 fs/cifs/dir.c |1 +
 fs/gfs2/inode.c   |4 +++-
 fs/namei.c|   34 ++
 fs/nfs/dir.c  |3 +++
 fs/open.c |   21 ++---
 9 files changed, 62 insertions(+), 43 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dependency bug in the uvcvideo Kconfig

[Randy Dunlap]

On 09/18/13 08:37, Peter Senna Tschudin wrote:
> Hi Randy,
> 
> I've tried to download the .config file from the link on the forum,
> but it tries to install something in my browser and the file is not
> downloadable for me. Can you provide it over an simpler interface such
> as pastebin.com?
> 
> Thanks

The original poster (Jeff) should have mentioned that is is a build bug problem 
in
Linux 3.5.4.  Jeff, have you tried 3.5.7?  I expect that this problem is already
fixed, if not in 3.5.x then in some later kernel version.

Jeff, also please provide the kernel .config file as an attachment here since
the one posted in the forum does not download (or has been deleted).


> On Wed, Sep 18, 2013 at 4:59 PM, Randy Dunlap  wrote:
>> [adding linux-media mailing list]
>>
>>
>> On 09/18/13 06:18, Jeff P. Zacher wrote:
>>> Not subscribed, please CC'me in replies:
>>>
>>> There seems to be a dependency bug in the Kconfig for the uvcvideo kernel
>>> module.  If uvcvideo is built in and usb support is built as a module, the
>>> kernel build will fail with the obviously missing dependanies.
>>>
>>>
>>> Error logs:
>>>
>>> * ERROR: Failed to compile the "bzImage" target...
>>> *
>>> * -- Grepping log... --
>>> *
>>> *  SHIPPED scripts/genksyms/keywords.hash.c
>>> *  SHIPPED scripts/genksyms/parse.tab.h
>>> *  SHIPPED scripts/genksyms/parse.tab.c
>>> *  HOSTCC  scripts/genksyms/lex.lex.o
>>> *scripts/genksyms/lex.lex.c_shipped: In function ‘yylex1’:
>>> *scripts/genksyms/lex.lex.c_shipped:904:1: warning: ignoring return value of
>>> ‘fwrite’, declared with attribute warn_unused_result [-Wunused-result]
>>> *--
>>> *  CC  drivers/video/console/font_8x16.o
>>> *  CC  drivers/video/console/softcursor.o
>>> *  CC  sound/core/seq/seq_memory.o
>>> *  CC  drivers/video/console/fbcondecor.o
>>> *  CC  sound/core/seq/seq_queue.o
>>> *drivers/video/console/fbcondecor.c:511:6: warning: function declaration 
>>> isn’t
>>> a prototype [-Wstrict-prototypes]
>>> *--
>>> *(.text+0xf8fb1): undefined reference to `usb_submit_urb'
>>> *drivers/built-in.o: In function `uvc_init':
>>> *uvc_driver.c:(.init.text+0x908a): undefined reference to
>>> `usb_register_driver'
>>> *drivers/built-in.o: In function `uvc_cleanup':
>>> *uvc_driver.c:(.exit.text+0x67e): undefined reference to `usb_deregister'
>>> *make: *** [vmlinux] Error 1
>>> *--
>>> * Running with options: --lvm --menuconfig all
>>> * Using genkernel.conf from /etc/genkernel.conf
>>> * Sourcing arch-specific config.sh from
>>> /usr/share/genkernel/arch/x86_64/config.sh ..
>>> * Sourcing arch-specific modules_load from
>>> /usr/share/genkernel/arch/x86_64/modules_load ..
>>> *
>>> * ERROR: Failed to compile the "bzImage" target...
>>> *
>>> * -- End log... --
>>>
>>> Compiling uvc as a module allows the compilation to complete.
>>>
>>> Platform x86_64
>>>
>>> Ref: http://forums.gentoo.org/viewtopic-p-7398782.html#7398782
>>>
>>>
>>> -- Jeff P. Zacher
>>> ad_si...@yahoo.com


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/22] ARM: dts: bcm281xx: Remove '0x's from BCM11351 DTS file

[Christian Daudt]

On 13-08-12 06:54 AM, Lee Jones wrote:

On Thu, 08 Aug 2013, Christian Daudt wrote:


Hi Lee,
  I had to change some of the lines in the dts files you modified, so
I've added your mods. This patch:
https://lkml.org/lkml/2013/8/8/477

includes your changes to bcm11351.dtsi and bcm11351-brt.dts. Not sure
where your patch is at this point, but I just wanted to point that
out.

I haven't done anything with that patch yet, but I'd prefer they
stayed separate to be honest. If you make your changes and ensure
they're in an upstream tree (and let me know which one), I'll rebase
my patches on top of that tree.


These changes are in 3.12-rc1 now:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d7358f845645c588aff84ac6b476a17d3eec75fa


 thanks,
   csd



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clk: si570: Add a driver for SI570 oscillators

[Sören Brinkmann]

I accidentally sent this out twice, sorry. Please ignore the second mail
of this thread.

Sören


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

Re: [PATCH 0/5] Preliminary: Add error names & descrptions to printks

[Daniel Santos]

On 09/18/2013 06:08 AM, David Howells wrote:

danielfsan...@att.net wrote:


Typically, we don't care about error messages or names in the kernel because
userspace will manage that.  But sometimes we need to output an error number
to printks and that creates a situation where a user, system admistrator or
developer must find an error number reference to figure out what went wrong
with a particular driver or whatever.  This patch adds two alternatives at
increasing memory costs:

1. print the number in addition to the name for 2k extra or
2. print the number, name and description for 6k extra.

I like the idea generally - and have occasionally entertained the idea of
implementing it myself.  However, I wouldn't bother with the "human readable"
description if we're going to do this.  Generally, the symbolic representation
is good enough - and that's what you're going to grep the code for anyway.

David


Yeah, I thought about that too, but I figured that descriptions were 
already there so I may as well make it an option for the 
search-engine-impared. :)  I was also thinking about system 
administrators and ordinary users trying to installing device drivers 
and other such situations where they would have to look at their syslogs 
or dmesg -- or just the lazy. :)


Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clk: si570: Add a driver for SI570 oscillators

[Soren Brinkmann]

Add a driver for SILabs 570, 571, 598, 599 programmable oscillators.
The devices generate low-jitter clock signals and are reprogrammable via
an I2C interface.

Cc: Guenter Roeck 
Signed-off-by: Soren Brinkmann 
---
v2:
 - document clock-output-names in bindings documentation
 - don't use wildcards in compatibility string
 - change Kconfig entry to "... 570 and compatible devices"
 - change some indentation flaws
 - use 1 as MIN and MAX value in usleep_range
 - fail probe() if 'factory-fout' is not provided in DT
   - default factory fout #defines removed
 - use i2c driver_data instead of OF data
   - remove some related structs and data
 - rename DT property 'initial-fout' => 'clock-frequency' (like si5351
   driver)
 - add some more details regarding the 'factory-fout' DT property

 .../devicetree/bindings/clock/silabs,si570.txt |  38 ++
 drivers/clk/Kconfig|  10 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-si570.c| 517 +
 4 files changed, 566 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si570.txt
 create mode 100644 drivers/clk/clk-si570.c

diff --git a/Documentation/devicetree/bindings/clock/silabs,si570.txt 
b/Documentation/devicetree/bindings/clock/silabs,si570.txt
new file mode 100644
index 000..7ab5c8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si570.txt
@@ -0,0 +1,38 @@
+Binding for Silicon Labs 570, 571, 598 and 599 programmable
+I2C clock generators.
+
+Reference
+This binding uses the common clock binding[1]. Details about the devices can be
+found in the data sheets[2][3].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Si570/571 Data Sheet
+http://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf
+[3] Si598/599 Data Sheet
+http://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf
+
+Required properties:
+ - compatible: Shall be one of "silabs,si570", "silabs,si571",
+  "silabs,si598", "silabs,si599"
+ - reg: I2C device address.
+ - #clock-cells: From common clock bindings: Shall be 0.
+ - factory-fout: Factory set default frequency. This frequency is part 
specific.
+The correct frequency for the part used has to be provided in
+order to generate the correct output frequencies. For more
+details, please refer to the data sheet.
+
+Optional properties:
+ - clock-output-names: From common clock bindings. Recommended to be "si570".
+ - clock-frequency: Output frequency to generate. This defines the output
+   frequency set during boot. It can be reprogrammed during
+   runtime using the common clock framework.
+ - temperature-stability-7ppm: Indicate a device with a temperature stability
+  of 7ppm
+
+Example:
+   si570: clock-generator@5d {
+   #clock-cells = <0>;
+   compatible = "silabs,si570";
+   reg = <0x5d>;
+   factory-fout = <15625>;
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 279407a..349b88a 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -64,6 +64,16 @@ config COMMON_CLK_SI5351
  This driver supports Silicon Labs 5351A/B/C programmable clock
  generators.
 
+config COMMON_CLK_SI570
+   tristate "Clock driver for SiLabs 570 and compatible devices"
+   depends on I2C
+   depends on OF
+   select REGMAP_I2C
+   help
+   ---help---
+ This driver supports Silicon Labs 570/571/598/599 programmable
+ clock generators.
+
 config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS11 MFD"
depends on MFD_SEC_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 7b11106..c0e94b3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
 obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
 obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
+obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
 obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
 obj-$(CONFIG_CLK_TWL6040)  += clk-twl6040.o
 obj-$(CONFIG_CLK_PPC_CORENET)  += clk-ppc-corenet.o
diff --git a/drivers/clk/clk-si570.c b/drivers/clk/clk-si570.c
new file mode 100644
index 000..c20dfce
--- /dev/null
+++ b/drivers/clk/clk-si570.c
@@ -0,0 +1,517 @@
+/*
+ * Driver for Silicon Labs Si570/Si571 Programmable XO/VCXO
+ *
+ * Copyright (C) 2010, 2011 Ericsson AB.
+ * Copyright (C) 2011 Guenter Roeck.
+ * Copyright (C) 2011 - 2013 Xilinx Inc.
+ *
+ * Author: Guenter Roeck 
+ *Sören Brinkmann 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; 

[PATCH v2] clk: si570: Add a driver for SI570 oscillators

[Soren Brinkmann]

Add a driver for SILabs 570, 571, 598, 599 programmable oscillators.
The devices generate low-jitter clock signals and are reprogrammable via
an I2C interface.

Cc: Guenter Roeck 
Signed-off-by: Soren Brinkmann 
---
v2:
 - document clock-output-names in bindings documentation
 - don't use wildcards in compatibility string
 - change Kconfig entry to "... 570 and compatible devices"
 - change some indentation flaws
 - use 1 as MIN and MAX value in usleep_range
 - fail probe() if 'factory-fout' is not provided in DT
   - default factory fout #defines removed
 - use i2c driver_data instead of OF data
   - remove some related structs and data
 - rename DT property 'initial-fout' => 'clock-frequency' (like si5351
   driver)
 - add some more details regarding the 'factory-fout' DT property

 .../devicetree/bindings/clock/silabs,si570.txt |  38 ++
 drivers/clk/Kconfig|  10 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-si570.c| 517 +
 4 files changed, 566 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/silabs,si570.txt
 create mode 100644 drivers/clk/clk-si570.c

diff --git a/Documentation/devicetree/bindings/clock/silabs,si570.txt 
b/Documentation/devicetree/bindings/clock/silabs,si570.txt
new file mode 100644
index 000..7ab5c8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si570.txt
@@ -0,0 +1,38 @@
+Binding for Silicon Labs 570, 571, 598 and 599 programmable
+I2C clock generators.
+
+Reference
+This binding uses the common clock binding[1]. Details about the devices can be
+found in the data sheets[2][3].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Si570/571 Data Sheet
+http://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf
+[3] Si598/599 Data Sheet
+http://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf
+
+Required properties:
+ - compatible: Shall be one of "silabs,si570", "silabs,si571",
+  "silabs,si598", "silabs,si599"
+ - reg: I2C device address.
+ - #clock-cells: From common clock bindings: Shall be 0.
+ - factory-fout: Factory set default frequency. This frequency is part 
specific.
+The correct frequency for the part used has to be provided in
+order to generate the correct output frequencies. For more
+details, please refer to the data sheet.
+
+Optional properties:
+ - clock-output-names: From common clock bindings. Recommended to be "si570".
+ - clock-frequency: Output frequency to generate. This defines the output
+   frequency set during boot. It can be reprogrammed during
+   runtime using the common clock framework.
+ - temperature-stability-7ppm: Indicate a device with a temperature stability
+  of 7ppm
+
+Example:
+   si570: clock-generator@5d {
+   #clock-cells = <0>;
+   compatible = "silabs,si570";
+   reg = <0x5d>;
+   factory-fout = <15625>;
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 279407a..349b88a 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -64,6 +64,16 @@ config COMMON_CLK_SI5351
  This driver supports Silicon Labs 5351A/B/C programmable clock
  generators.
 
+config COMMON_CLK_SI570
+   tristate "Clock driver for SiLabs 570 and compatible devices"
+   depends on I2C
+   depends on OF
+   select REGMAP_I2C
+   help
+   ---help---
+ This driver supports Silicon Labs 570/571/598/599 programmable
+ clock generators.
+
 config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS11 MFD"
depends on MFD_SEC_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 7b11106..c0e94b3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
 obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
 obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
+obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
 obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
 obj-$(CONFIG_CLK_TWL6040)  += clk-twl6040.o
 obj-$(CONFIG_CLK_PPC_CORENET)  += clk-ppc-corenet.o
diff --git a/drivers/clk/clk-si570.c b/drivers/clk/clk-si570.c
new file mode 100644
index 000..c20dfce
--- /dev/null
+++ b/drivers/clk/clk-si570.c
@@ -0,0 +1,517 @@
+/*
+ * Driver for Silicon Labs Si570/Si571 Programmable XO/VCXO
+ *
+ * Copyright (C) 2010, 2011 Ericsson AB.
+ * Copyright (C) 2011 Guenter Roeck.
+ * Copyright (C) 2011 - 2013 Xilinx Inc.
+ *
+ * Author: Guenter Roeck 
+ *Sören Brinkmann 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; 

Re: [PATCH 1/5] scripts: Add mkstrerror.sh

[Daniel Santos]

On 09/18/2013 06:38 AM, David Howells wrote:

danielfsan...@att.net wrote:


This is a simple bash script that parses our errno*.h files and formats
them into the error_strings.h header that our strerror and strerror_name
functions will use later.

I presume you haven't tried building with a "make O=foo" build directory?  I
see:

   /bin/sh: /data/fs/linux-2.6-fscache/include/generated/error_strings.h: 
No such file or directory

when I try it.


No, indeed I haven't, thanks. I'm going to need help figuring out the 
correct way to put this in the build because the current definitely 
isn't correct.  From what I could tell from digging into the build last 
night (which I've never carefully analyzed), this should be added 
somewhere in one of the scripts/Makefile*s and not in the root makefile 
(as I have done), or maybe even in lib/Makefile.




  (2) Storing the leading 'E' for each symbol is redundant as you can add that
  later so you might want to discard it.


This is a good thought, that's 150-ish bytes, but it will introduce some 
new challenges.  Currently, strerror() functions exactly like "man 3p 
strerror", except that it returns a pointer to a const string like the 
POSIX specification should have done. :)  So I directly return a pointer 
to the string within the .rodata section of the object file (same for 
strerror_name).  Omitting the 'E' would require I work up another 
solution requiring a return buffer or some such, thus increasing 
complexity and possibly loosing that savings to code.


However, if we wanted to squeze that much more out of it, then we could 
7-th bit terminate the strings and save another 150-ish bytes on null 
terminators or go even further and use some encoding scheme (maybe 32 
bits per character)?  At 2k for both the error names and the code, I 
figured it was already pretty low, but if there are some existing 
libraries in the kernel we could use to do this and not further bloat 
the text size for decompression then I wouldn't be opposed, so long as 
it makes sense.  And since we're dealing with error conditions which 
don't happen often, speed shouldn't be a concern.


Thanks!
Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/02] x86_64: Add safe check in a.out loaders and some coding style

[Geyslan Gregório Bem]

Please, disregard this due to problems reversing the commit.

I'll send the entire one soon.

Geyslan Gregório Bem
hackingbits.com


2013/9/18 Geyslan G. Bem :
> ia32_aout had no safe checks concerning the mmap and f_op in this module.
> It's not necessary to verify f_op in the load_aout_library, since the
> prior kernel_read/vfs_read function already does.
> Coding style and printks fixes.
>
> Tested using qemu, a handcrafted a.out binary and a a.out linked with a
> cross-compiled ld.
>
> Signed-off-by: Geyslan G. Bem 
> ---
>  arch/x86/ia32/ia32_aout.c | 25 ++---
>  1 file changed, 6 insertions(+), 19 deletions(-)
>
> diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
> index 15a8319..46a0346 100644
> --- a/arch/x86/ia32/ia32_aout.c
> +++ b/arch/x86/ia32/ia32_aout.c
> @@ -24,7 +24,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include 
>  #include 
> @@ -346,21 +346,13 @@ static int load_aout_binary(struct linux_binprm *bprm)
> }
> } else {
>  #ifdef WARN_OLD
> -   static unsigned long error_time, error_time2;
> if ((ex.a_text & 0xfff || ex.a_data & 0xfff) &&
> -   (N_MAGIC(ex) != NMAGIC) &&
> -   time_after(jiffies, error_time2 + 5*HZ)) {
> -   printk(KERN_NOTICE "executable not page aligned\n");
> -   error_time2 = jiffies;
> -   }
> +   (N_MAGIC(ex) != NMAGIC))
> +   pr_notice_ratelimited("executable not page 
> aligned\n");
>
> -   if ((fd_offset & ~PAGE_MASK) != 0 &&
> -   time_after(jiffies, error_time + 5*HZ)) {
> -   printk(KERN_WARNING
> -  "fd_offset is not page aligned. Please convert 
> program: %s\n",
> +   if ((fd_offset & ~PAGE_MASK) != 0)
> +   pr_warn_ratelimited("fd_offset is not page aligned. 
> Please convert program: %s\n",
>bprm->file->f_path.dentry->d_name.name);
> -   error_time = jiffies;
> -   }
>  #endif
>
> if ((fd_offset & ~PAGE_MASK) != 0) {
> @@ -451,13 +443,8 @@ static int load_aout_library(struct file *file)
>
> if ((N_TXTOFF(ex) & ~PAGE_MASK) != 0) {
>  #ifdef WARN_OLD
> -   static unsigned long error_time;
> -   if (time_after(jiffies, error_time + 5*HZ)) {
> -   printk(KERN_WARNING
> -  "N_TXTOFF is not page aligned. Please convert 
> library: %s\n",
> +   pr_warn_ratelimited("N_TXTOFF is not page aligned. Please 
> convert library: %s\n",
>file->f_path.dentry->d_name.name);
> -   error_time = jiffies;
> -   }
>  #endif
> vm_brk(start_addr, ex.a_text + ex.a_data + ex.a_bss);
>
> --
> 1.8.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: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver

[Thomas Gleixner]

On Wed, 18 Sep 2013, Santosh Shilimkar wrote:
> On Friday 13 September 2013 10:55 AM, Santosh Shilimkar wrote:
> > On Friday 13 September 2013 10:24 AM, Thomas Gleixner wrote:
> 
> [...]
> 
> >> Before you dig into MSI, lets talk about irq domains first.
> >>
> >> GIC implements a legacy irq domain, i.e. a linear domain of all
> >> possible GIC interrupts with a 1:1 mapping.
> >>
> >> So why can't you make use of irq domains and have the whole routing
> >> business implemented sanely?
> >>
> >> What's needed is in gic_init_bases():
> >>
> >>if (of_property_read(node, "routable_irqs", _routable_irqs) {
> >>  irq_domain_add_legacy(nr_gic_irqs);
> >>} else {
> >>  irq_domain_add_legacy(nr_per_cpu_irqs);
> >>  irq_domain_add_linear(nr_routable_irqs);
> >>}
> >>
> >> Now that separate domain has an xlate function which grabs a free GIC
> >> irq from a bitmap and returns the hardware irq number in the gic
> >> space. The map/unmap callbacks take care of setting up / tearing down
> >> the route in the crossbar.
> >>
> >> Thoughts?
> >>
> > This sounds pretty good idea. We will explore above option.
> > Thanks Thomas.
> > 
> After further looking into this, the irqdomain approach lets us
> setup the map only once during the init. This is similar to
> the earlier approach of cross-bar driver where at probe time
> the router was setup.  The whole debate started with the fact
> that we shouldn't fix the irq mapping at probe and should
> dynamically change the mapping based on [request/free]_irq()
> to be able to maximize the use of the IP.

Well, that's what irq_of_parse_and_map() resp. irq_create_mapping and
irq_dispose_mapping() are for.

It requires changes to drivers, but you can't get that thing for free.

Thanks,

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

Re: Regression on cpufreq in v3.12-rc1

[Rafael J. Wysocki]

On Wednesday, September 18, 2013 11:21:45 PM Linus Walleij wrote:
> Hi Rafael, Viresh,
> 
> I'm seeing this problem and maybe you can help me out fixing it
> properly:
> 
> On some machines like the StrongARM SA1100 it seems that
> cpufreq_get() can be called before the cpufreq driver and thus the
> policy is set, resulting in a crash like this:

Did you try the current linux-next branch from my tree?

Rafael


> 
[ cut here ]
> 
kernel BUG at /home/linus/linux/drivers/cpufreq/cpufreq.c:80!
> 
Internal error: Oops - BUG: 0 [#1] ARM
> 
Modules linked in:
> 
CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc1-1-g1266dae-dirty #17
> 
task: c183 ti: c1832000 task.ti: c1832000
> (...)
> Backtrace:
> [] (lock_policy_rwsem_read+0x0/0x48) from []
> (cpufreq_get+0x34/0x68)
> [] (cpufreq_get+0x0/0x68) from []
> (sa1100fb_activate_var+0xdc/0x3ac)
>  r5:0003 r4:000a
> [] (sa1100fb_activate_var+0x0/0x3ac) from []
> (sa1100fb_set_par+0xa0/0xa8)
> [] (sa1100fb_set_par+0x0/0xa8) from []
> (fbcon_init+0x444/0x4a8)
>  r4:c1803200
> [] (fbcon_init+0x0/0x4a8) from [] (visual_init+0x78/0xc8)
> [] (visual_init+0x0/0xc8) from []
> (do_bind_con_driver+0x160/0x310)
> 
> This bug comes from the framebuffer but I first encountered it
> in the PCMCIA driver, and both seem to cause the bug.
> 
> In the past I think things worked smoothly: the consumers
> calling cpufreq_get() too early would just get 0 back.
> (Or so it seems to me.)
> 
> The BUG() statement causing it is in the lock_policy_rwsem_##mode(int cpu)
> macro.
> 
> Applying a patch like this seems to fix the issue:
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 43c24aa..4977b4b 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -70,7 +70,8 @@ static DEFINE_PER_CPU(struct rw_semaphore, 
> cpu_policy_rwsem);
>  static int lock_policy_rwsem_##mode(int cpu)   \
>  {  \
> struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu); \
> -   BUG_ON(!policy);\
> +   if(!policy) \
> +   return 0;   \
> down_##mode(_cpu(cpu_policy_rwsem, policy->cpu));   \
> \
> return 0;   \
> @@ -83,7 +84,8 @@ lock_policy_rwsem(write, cpu);
>  static void unlock_policy_rwsem_##mode(int cpu)
>  \
>  {  \
> struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu); \
> -   BUG_ON(!policy);\
> +   if(!policy) \
> +   return; \
> up_##mode(_cpu(cpu_policy_rwsem, policy->cpu)); \
>  }
> 
> @@ -1423,6 +1425,9 @@ static unsigned int __cpufreq_get(unsigned int cpu)
> struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
> unsigned int ret_freq = 0;
> 
> +   if (!policy)
> +   return ret_freq;
> +
> if (!cpufreq_driver->get)
> return ret_freq;
> 
> I don't really know if this is the right solution at all, so please
> help me out here... if you want that patch I can send it once
> I understand this properly.
> 
> Yours,
> Linus Walleij
-- 
I speak only for myself.
Rafael J. Wysocki, 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] RX-51: Add missing max_current to rx51_lp5523_led_config

[Tony Lindgren]

* Pali Rohár  [130918 15:02]:
> Without max_current data in board file lp5523 driver does not change current.

Hmm is this a regression or are there other reasons to merge
this during the -rc cycle?

Regards,

Tony
 
> Signed-off-by: Pali Rohár 
> ---
>  arch/arm/mach-omap2/board-rx51-peripherals.c |9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
> b/arch/arm/mach-omap2/board-rx51-peripherals.c
> index 9326890..d0f857c 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -180,38 +180,47 @@ static struct lp55xx_led_config 
> rx51_lp5523_led_config[] = {
>   .name   = "lp5523:kb1",
>   .chan_nr= 0,
>   .led_current= 50,
> + .max_current= 255,
>   }, {
>   .name   = "lp5523:kb2",
>   .chan_nr= 1,
>   .led_current= 50,
> + .max_current= 255,
>   }, {
>   .name   = "lp5523:kb3",
>   .chan_nr= 2,
>   .led_current= 50,
> + .max_current= 255,
>   }, {
>   .name   = "lp5523:kb4",
>   .chan_nr= 3,
>   .led_current= 50,
> + .max_current= 255,
>   }, {
>   .name   = "lp5523:b",
>   .chan_nr= 4,
>   .led_current= 50,
> + .max_current= 255,
>   }, {
>   .name   = "lp5523:g",
>   .chan_nr= 5,
>   .led_current= 50,
> + .max_current= 255,
>   }, {
>   .name   = "lp5523:r",
>   .chan_nr= 6,
>   .led_current= 50,
> + .max_current= 255,
>   }, {
>   .name   = "lp5523:kb5",
>   .chan_nr= 7,
>   .led_current= 50,
> + .max_current= 255,
>   }, {
>   .name   = "lp5523:kb6",
>   .chan_nr= 8,
>   .led_current= 50,
> + .max_current= 255,
>   }
>  };
>  
> -- 
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] scripts: Add mkstrerror.sh

[Daniel Santos]

On 09/18/2013 06:55 AM, David Howells wrote:

David Howells  wrote:


  (1) Why are you double-NUL'ing all your strings?  (see the \0 in the strings)

Ah...  I see what you're doing.  I missed the fact that you don't have a comma
after each string.


Yeah, I was trying to format the code so that it's efficient and still 
easy to read, but then there's no comma where we normally expect one.  
It's the best middle ground solution I could come up with.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] uinput: Support injecting multiple events in one write() call

[Dmitry Torokhov]

Ryan Mallon  wrote:
>On 19/09/13 05:48, Dmitry Torokhov wrote:
>
>> Hi Ryan,
>> 
>> On Wed, Sep 18, 2013 at 08:55:44AM +1000, Ryan Mallon wrote:
>>> Rework the code in uinput_inject_event so that it matches the code
>in
>>> evdev_write and allows injecting more than one event, or zero
>events.
>> 
>> After some thinking I went back to the original version of your
>patch.
>> For justification see 46f49b7a223ac7493e7cf619fb583d11edefc2c2:
>> 
>> "When copy_to/from_user fails in the middle of transfer we should not
>> report to the user that read/write partially succeeded but rather
>> report -EFAULT right away, so that application will know that it got
>> its buffers all wrong.
>> 
>> If application messed up its buffers we can't trust the data fetched
>> from userspace and successfully written to the device or if data read
>> from the device and transferred to userspace ended up where
>application
>> expected it to end."
>
>
>Okay, so patch 1 is obviously dropped. Do you want me to resend a fixed
>
>version of this one, or have you already modified it?

I took your original version - is does the right thing.

Thanks.

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

Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver

[Thomas Gleixner]

On Wed, 18 Sep 2013, Sricharan R wrote:
> On Wednesday 18 September 2013 07:22 PM, Sricharan R wrote:
> > Hi Thomas,
> >
> > On Tuesday 17 September 2013 05:56 PM, Linus Walleij wrote:
> >> On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner  
> >> wrote:
> >>
> >>> So why can't you make use of irq domains and have the whole routing
> >>> business implemented sanely?
> >>>
> >>> What's needed is in gic_init_bases():
> >>> irq
> >>>if (of_property_read(node, "routable_irqs", _routable_irqs) {
> >>>   irq_domain_add_legacy(nr_gic_irqs);
> >>>} else {
> >>>   irq_domain_add_legacy(nr_per_cpu_irqs);
> >>>   irq_domain_add_linear(nr_routable_irqs);
> >>>}
> >>>
> >>> Now that separate domain has an xlate function which grabs a free GIC
> >>> irq from a bitmap and returns the hardware irq number in the gic
> >>> space. The map/unmap callbacks take care of setting up / tearing down
> >>> the route in the crossbar.
> >> This is obviously the right approach, it's exactly what .map should do
> >> the only special thing here being that we have hardware to perform
> >> the mapping ... bah why didn't I realize this :-(
> >>
> >> Yours,
> >> Linus Walleij
> > Thanks for the suggestion.
> >
> > So as i understand this, this implies using the GIC domain itself and
> >  add the support for dynamically routable irqs (like crossbar) with in the
> > GIC driver itself right ?
>   Please ignore this. So the question was more of how to implement the
>   call outs in the case of routable irqs from map/ unmap callbacks.

If you look closely at what I suggested, you'll notice that I added a
separate domain in the routed case. Go figure ...

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [BUG] 3.7-rc regression bisected: s2disk fails to resume image: Processes could not be frozen, cannot continue resuming

[Andrew Savchenko]

On Wed, 18 Sep 2013 20:16:07 +0100 Al Viro wrote:
> On Wed, Sep 18, 2013 at 10:40:32PM +0400, Andrew Savchenko wrote:
> 
> > And from suspend_ioctls.h:
> > #define SNAPSHOT_IOC_MAGIC  '3'
> > #define SNAPSHOT_FREEZE _IO(SNAPSHOT_IOC_MAGIC, 1)
> > 
> > My mistake, should be '3' instead of 3.
> 
> OK...  The thing to test, then, is what does __usermodehelper_disable()
> return to freeze_processes().  If that's where this -EAGAIN comes from,
> we at least have a plausible theory re what's going on.
> 
> freeze_processes() uses __usermodehelper_disable() to stop any new userland
> processes spawned by UMH (modprobe, etc.) and waits for ones it might be
> waiting for to complete.  Then it does try_to_freeze_tasks(), which
> freezes remaining userland, carefully skipping the current thread.
> However, it misses the possibility that current thread might have been
> spawned by something that had been launched by UMH, with UMH waiting
> for it.  Which is the case of everything spawned by linuxrc.
> 
> I'd try something like diff below, but I'm *NOT* familiar with swsusp at
> all; it's not for mainline until ACKed by swsusp folks.
> 
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index fb32636..d968882 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -571,7 +571,8 @@ int call_usermodehelper_exec(struct subprocess_info 
> *sub_info, int wait)
>   DECLARE_COMPLETION_ONSTACK(done);
>   int retval = 0;
>  
> - helper_lock();
> + if (!(current->flags & PF_FREEZER_SKIP))
> + helper_lock();
>   if (!khelper_wq || usermodehelper_disabled) {
>   retval = -EBUSY;
>   goto out;
> @@ -611,7 +612,8 @@ wait_done:
>  out:
>   call_usermodehelper_freeinfo(sub_info);
>  unlock:
> - helper_unlock();
> + if (!(current->flags & PF_FREEZER_SKIP))
> + helper_unlock();
>   return retval;
>  }
>  EXPORT_SYMBOL(call_usermodehelper_exec);

With this patch and 3.11.1 kernel resume works fine.

Best regards,
Andrew Savchenko


pgpxdr8tyVGsf.pgp
Description: PGP signature

Re: [REGRESSION][BISECTED] skge: add dma_mapping check

[Francois Romieu]

Igor Gnatenko  :
> Since 136d8f377e1575463b47840bc5f1b22d94bf8f63 commit we have kernel
> panic on:
> 01:05.0 Ethernet controller [0200]: Marvell Technology Group Ltd.
> 
> Screen: https://www.dropbox.com/s/mu3t3wxpxbn4ou5/IMAG0507.jpg
> 
> RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1008323

Does the ugly stuff below against mainline make a difference ?

Note to testers: use a size argument above 500 for 'ping' to
exercize the relevant code path.

diff --git a/drivers/net/ethernet/marvell/skge.c 
b/drivers/net/ethernet/marvell/skge.c
index ef94a59..aa85a3f 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -3086,6 +3086,7 @@ static struct sk_buff *skge_rx_get(struct net_device *dev,
   PCI_DMA_FROMDEVICE);
skge_rx_reuse(e, skge->rx_buf_size);
} else {
+   struct skge_element ee = *e;
struct sk_buff *nskb;
 
nskb = netdev_alloc_skb_ip_align(dev, skge->rx_buf_size);
@@ -3098,10 +3099,10 @@ static struct sk_buff *skge_rx_get(struct net_device 
*dev,
}
 
pci_unmap_single(skge->hw->pdev,
-dma_unmap_addr(e, mapaddr),
-dma_unmap_len(e, maplen),
+dma_unmap_addr(, mapaddr),
+dma_unmap_len(, maplen),
 PCI_DMA_FROMDEVICE);
-   skb = e->skb;
+   skb = ee.skb;
prefetch(skb->data);
}
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC vmstat: On demand vmstat threads

[Andrew Morton]

On Tue, 10 Sep 2013 21:13:34 + Christoph Lameter  wrote:

> Subject: vmstat: On demand vmstat workers V2

grumbles.

> vmstat threads are used for folding counter differentials into the
> zone, per node and global counters at certain time intervals.

These are not "threads".  Let's please use accurate terminology
("keventd works" is close enough) and not inappropriately repurpose
well-understood terms.

> They currently run at defined intervals on all processors which will
> cause some holdoff for processors that need minimal intrusion by the
> OS.
> 
> This patch creates a vmstat shepherd task that monitors the

No, it does not call kthread_run() hence it does not create a task.  Or
a thread.

> per cpu differentials on all processors. If there are differentials
> on a processor then a vmstat worker thread local to the processors
> with the differentials is created. That worker will then start
> folding the diffs in regular intervals. Should the worker
> find that there is no work to be done then it will
> terminate itself and make the shepherd task monitor the differentials
> again.
> 
> With this patch it is possible then to have periods longer than
> 2 seconds without any OS event on a "cpu" (hardware thread).

It would be useful (actually essential) to have a description of why
anyone cares about this.  A good and detailed description, please.

> The tick_do_timer_cpu is chosen to run the shepherd workers.
> So there must be at least one cpu that will keep running vmstat
> updates.
> 
> ...
>
> --- linux.orig/mm/vmstat.c2013-09-09 13:58:25.526562233 -0500
> +++ linux/mm/vmstat.c 2013-09-09 16:09:14.266402841 -0500
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -414,13 +415,18 @@ void dec_zone_page_state(struct page *pa
>  EXPORT_SYMBOL(dec_zone_page_state);
>  #endif
> 
> -static inline void fold_diff(int *diff)
> +
> +static inline int fold_diff(int *diff)
>  {
>   int i;
> + int changes = 0;
> 
>   for (i = 0; i < NR_VM_ZONE_STAT_ITEMS; i++)
> - if (diff[i])
> + if (diff[i]) {
>   atomic_long_add(diff[i], _stat[i]);
> + changes++;
> + }
> + return changes;
>  }
> 
>  /*
> @@ -437,11 +443,12 @@ static inline void fold_diff(int *diff)
>   * with the global counters. These could cause remote node cache line
>   * bouncing and will have to be only done when necessary.

Document the newly-added return value?  Especially as it's a scalar
which is used as a boolean when it isn't just ignored.

>   */
> -static void refresh_cpu_vm_stats(void)
> +static int refresh_cpu_vm_stats(void)
>  {
>   struct zone *zone;
>   int i;
>   int global_diff[NR_VM_ZONE_STAT_ITEMS] = { 0, };
> + int changes = 0;
> 
>   for_each_populated_zone(zone) {
>   struct per_cpu_pageset __percpu *p = zone->pageset;
> @@ -485,11 +492,14 @@ static void refresh_cpu_vm_stats(void)
>   if (__this_cpu_dec_return(p->expire))
>   continue;
> 
> - if (__this_cpu_read(p->pcp.count))
> + if (__this_cpu_read(p->pcp.count)) {
>   drain_zone_pages(zone, __this_cpu_ptr(>pcp));
> + changes++;
> + }
>  #endif
>   }
> - fold_diff(global_diff);
> + changes += fold_diff(global_diff);
> + return changes;
>  }
> 
>  /*
> @@ -1203,12 +1213,15 @@ static const struct file_operations proc
>  #ifdef CONFIG_SMP
>  static DEFINE_PER_CPU(struct delayed_work, vmstat_work);
>  int sysctl_stat_interval __read_mostly = HZ;
> +static struct cpumask *monitored_cpus;
> 
>  static void vmstat_update(struct work_struct *w)
>  {
> - refresh_cpu_vm_stats();
> - schedule_delayed_work(this_cpu_ptr(_work),
> - round_jiffies_relative(sysctl_stat_interval));
> + if (refresh_cpu_vm_stats())
> + schedule_delayed_work(this_cpu_ptr(_work),
> + round_jiffies_relative(sysctl_stat_interval));
> + else
> + cpumask_set_cpu(smp_processor_id(), monitored_cpus);
>  }
> 
>  static void start_cpu_timer(int cpu)
> @@ -1216,7 +1229,63 @@ static void start_cpu_timer(int cpu)
>   struct delayed_work *work = _cpu(vmstat_work, cpu);
> 
>   INIT_DEFERRABLE_WORK(work, vmstat_update);
> - schedule_delayed_work_on(cpu, work, __round_jiffies_relative(HZ, cpu));
> + schedule_delayed_work_on(cpu, work,
> + __round_jiffies_relative(sysctl_stat_interval, cpu));
> +}
> +
> +/*
> + * Check if the diffs for a certain cpu indicate that
> + * an update is needed.
> + */
> +static int need_update(int cpu)
> +{
> + struct zone *zone;
> +
> + for_each_populated_zone(zone) {
> + struct per_cpu_pageset *p = per_cpu_ptr(zone->pageset, cpu);
> +
> + /*
> +  * The fast way of checking if there are any vmstat diffs.
> +  * This works because the diffs are 

Re: Build failures due to commit 416161db (btrfs: offline dedupe)

[Mark Fasheh]

On Wed, Sep 18, 2013 at 11:40:07AM -0700, Guenter Roeck wrote:
> On Tue, Sep 17, 2013 at 03:43:54PM -0700, Mark Fasheh wrote:
> > On Fri, Sep 13, 2013 at 03:33:34PM -0400, Chris Mason wrote:
> > > Mark, could you please send a patch for the whole-struct option until
> > > the unaligned put is upstreamed?
> > > 
> > > -chris
> > 
> > Here you go. It's been lightly tested and needs review.
> > 
> At the very least it does fix the build error on the affected platforms.

Thanks for verifying that Guenter.
--Mark

--
Mark Fasheh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clockevents: Sanitize ticks to nsec conversion

[Thomas Gleixner]

On Wed, 18 Sep 2013, Uwe Kleine-König wrote:
> On Wed, Sep 18, 2013 at 11:38:07AM +0200, Thomas Gleixner wrote:
> > On Wed, 18 Sep 2013, Uwe Kleine-König wrote:
> > > Another doubt I have is: You changed clockevent_delta2ns to round up now
> > > unconditionally. For the numbers on at91 that doesn't matter, but I
> > > wonder if there are situations that make the timer core violate the
> > > max_delta_ticks condition now.
> > 
> > And how so? The + (mult - 1) ensures, that the conversion back to
> > ticks results in the same value as latch. So how should it violate
> > the max boundary?
> That is wrong:
> With max_delta_ticks << shift = n * mult - k for k in [0 .. mult-1] and
> an integer n:
> 
> (max_delta_ns * mult) >> shift
>   = max_delta_ticks << shift) + mult - 1) / mult) * mult) >> shift
>   = (((n * mult - k + mult - 1) / mult) * mult) >> shift
>   = n * mult >> shift
>   = ((max_delta_ticks << shift) + k) >> shift
>   = max_delta_ticks + (k >> shift)
> 
> k >> shift is only known to be zero if mult <= 1 << shift (i.e. the same
> condition as above where your 64bit overflow detection is wrong). So
> this can result in values > max_delta_ticks.

Right, should have waited for coffee actually activating the right
brain cells.

So the rounding thing works nicely for mult <= (1 << sft). For the
other cases the conversion is wrong by (mult / (1 << sft)) - 1. So for
a 3 GHz clock it's off by 2. That's not an issue for the min value,
but for the max value it might overflow the hardware limit. Not a real
functional issue as we'd just get a pointless short interrupt, but for
correctness reasons and for the sake of NOHZ we need to fix that.

There is no real correct solution for these cases, which will result
in a correct backwards conversion. We could validate against the max
delta ticks in program_event, but that adds another boundary check to
the hotpath so I rather want to avoid it.

The simple solution is to check for the following in the conversion
routine:

if (latch == dev->min_delta_ticks || dev->mult <= (1 << dev->sft))
   clc += mult - 1

That ensures, that we never violate the lower boundary independent of
the mult/sft relation. For the max_delta_ticks conversion in the "mult
> (1 << sft)" case we end up with a slightly smaller value, but well
inside the boundaries and close enough to the hardware limitations.

Versus the 64bit overflow check, we need to be even more careful. We
need to check for overflowing (1 << 63) - 1 (i.e. the max positive
value which fits into a s64). See clockevents_program_event().

So this check needs to be:

   u64 clc = (u64)latch << sft;

   if ((s64)clc < 0 || (clc >> sft ) != latch)
  clc = (1 << 63) - 1;

   And the above rounding magic, which has to be applied after this
   needs to take the following condition into account as well:

(1 << 63) - 1 - clc >= mult - 1

If that's not true, we can't do the rounding add, but we know that
we are well at the upper limit of the hardware, so no issue
either.

> > > > for boundary violation and can limit "clc" to (1 << 63) - 1 before the
> > > Where does this magic constant come from?
> > 
> > Rolling my magic hex dice gave me that.
> Wow, how many sides does your dice have? Couldn't it have choosen
> (u64)-1 for improved results?

No it's restricted to s64 positiv values due to software
limitations. See above.

Thanks,

tglx

[PATCH] RX-51: Add missing max_current to rx51_lp5523_led_config

[Pali Rohár]

Without max_current data in board file lp5523 driver does not change current.

Signed-off-by: Pali Rohár 
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9326890..d0f857c 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -180,38 +180,47 @@ static struct lp55xx_led_config rx51_lp5523_led_config[] 
= {
.name   = "lp5523:kb1",
.chan_nr= 0,
.led_current= 50,
+   .max_current= 255,
}, {
.name   = "lp5523:kb2",
.chan_nr= 1,
.led_current= 50,
+   .max_current= 255,
}, {
.name   = "lp5523:kb3",
.chan_nr= 2,
.led_current= 50,
+   .max_current= 255,
}, {
.name   = "lp5523:kb4",
.chan_nr= 3,
.led_current= 50,
+   .max_current= 255,
}, {
.name   = "lp5523:b",
.chan_nr= 4,
.led_current= 50,
+   .max_current= 255,
}, {
.name   = "lp5523:g",
.chan_nr= 5,
.led_current= 50,
+   .max_current= 255,
}, {
.name   = "lp5523:r",
.chan_nr= 6,
.led_current= 50,
+   .max_current= 255,
}, {
.name   = "lp5523:kb5",
.chan_nr= 7,
.led_current= 50,
+   .max_current= 255,
}, {
.name   = "lp5523:kb6",
.chan_nr= 8,
.led_current= 50,
+   .max_current= 255,
}
 };
 
-- 
1.7.10.4

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

[PATCHv6 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

This patch introduces a device tree bindings for
describing the hardware thermal behavior and limits.
Also a parser to read and interpret the data and feed
it in the thermal framework is presented.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Note that, in order to be able to have control
on the sensor registration on the DT thermal zone,
it was required to allow changing the thermal zone
.get_temp callback. For this reason, this patch
also removes the 'const' modifier from the .ops
field of thermal zone devices.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 .../devicetree/bindings/thermal/thermal.txt| 498 +
 drivers/thermal/Kconfig|  13 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/of-thermal.c   | 775 +
 drivers/thermal/thermal_core.c |   9 +-
 drivers/thermal/thermal_core.h |   9 +
 include/dt-bindings/thermal/thermal.h  |  27 +
 include/linux/thermal.h|  28 +-
 8 files changed, 1357 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h

---

Hello all,

Thanks Joe Perches for the effort of reviewing this code, I really appreciate 
it.

Here is a version with a refactored init function without leaks in the failure
patch. I also added a couple of comments to better understand the intention of
that function. Besides, when there are no memory available, the function
rolls back what ever thermal zones have been added.

Thanks,

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* Thermal Framework Device Tree descriptor
+
+Generic binding to provide a way of defining hardware thermal
+structure using device tree. A thermal structure includes thermal
+zones and their components, such as trip points, polling intervals,
+sensors and cooling devices binding descriptors.
+
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects, not how the system must control or which
+algorithm or policy must be taken in place.
+
+There are five types of nodes involved to describe thermal bindings:
+- sensors: used to describe the device source of temperature sensing;
+- cooling devices: used to describe devices source of power dissipation 
control;
+- trip points: used to describe points in temperature domain defined to
+make the system aware of hardware limits;
+- cooling attachments: used to describe links between trip points and
+cooling devices;
+- thermal zones: used to describe thermal data within the hardware;
+
+It follows a description of each type of these device tree nodes.
+
+* Sensor devices
+
+Sensor devices are nodes providing temperature sensing capabilities on thermal
+zones. Typical devices are I2C ADC converters and bandgaps. Theses are nodes
+providing temperature data to thermal zones. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:   Used to provide sensor device specific information
+   while referring to it. Must be at least 1, in order
+   to identify uniquely the sensor instances within
+   the IC. See thermal zone binding for more details
+   on how consumers refer to sensor devices.
+
+* Cooling device nodes
+
+Cooling devices are nodes providing control on power dissipation. There
+are essentially two ways to provide control on power dissipation. First
+is by means of regulating device performance, which is known as passive
+cooling. Second is by means of activating devices in order to remove
+the dissipated heat, which is known as active cooling, e.g. regulating
+fan speeds. In both cases, cooling devices shall have a way to determine
+the level of cooling.
+
+Required property:
+- cooling-min-level:   A unsigned integer indicating the smallest
+   cooling level accepted. Typically 0.
+- cooling-max-level:   An unsigned integer indicating the largest
+   cooling level accepted.
+- #cooling-cells:  Used to provide cooling device specific information
+   while referring to it. Must be at least 2, in order
+   to specify minimum and 

Re: [PATCH 2/2] uinput: Support injecting multiple events in one write() call

[Ryan Mallon]

On 19/09/13 05:48, Dmitry Torokhov wrote:

> Hi Ryan,
> 
> On Wed, Sep 18, 2013 at 08:55:44AM +1000, Ryan Mallon wrote:
>> Rework the code in uinput_inject_event so that it matches the code in
>> evdev_write and allows injecting more than one event, or zero events.
> 
> After some thinking I went back to the original version of your patch.
> For justification see 46f49b7a223ac7493e7cf619fb583d11edefc2c2:
> 
> "When copy_to/from_user fails in the middle of transfer we should not
> report to the user that read/write partially succeeded but rather
> report -EFAULT right away, so that application will know that it got
> its buffers all wrong.
> 
> If application messed up its buffers we can't trust the data fetched
> from userspace and successfully written to the device or if data read
> from the device and transferred to userspace ended up where application
> expected it to end."


Okay, so patch 1 is obviously dropped. Do you want me to resend a fixed 
version of this one, or have you already modified it?

Thanks,
~Ryan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Fixed typo in word 'implementations' in reboot.h

[Anoop Thomas Mathew]

Signed-off-by: Anoop Thomas Mathew 
---
 include/linux/reboot.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index 8e00f9f..0ff569d 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -52,7 +52,7 @@ struct pt_regs;
 extern void machine_crash_shutdown(struct pt_regs *);
 
 /*
- * Architecture independent implemenations of sys_reboot commands.
+ * Architecture independent implementations of sys_reboot commands.
  */
 
 extern void kernel_restart_prepare(char *cmd);
-- 
1.7.9.5

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

Re: [PATCH v2 2/4] gcov: add support for gcc 4.7 gcov format

[Andrew Morton]

On Wed, 18 Sep 2013 14:27:05 -0700 Joe Perches  wrote:

> On Wed, 2013-09-18 at 14:22 -0700, Andrew Morton wrote:
> > On Wed,  4 Sep 2013 16:42:54 +0200 Frantisek Hrbata  
> > wrote:
> > > The gcov in-memory format changed in gcc 4.7. The biggest change, which
> > > requires this special implementation, is that gcov_info no longer contains
> > > array of counters for each counter type for all functions and 
> > > gcov_fn_info is
> > > not used for mapping of function's counters to these arrays(offset). Now 
> > > each
> > > gcov_fn_info contans it's counters, which makes things a little bit 
> > > easier.
> > > 
> > > This is heavily based on the previous gcc_3_4.c implementation and patches
> > > provided by Peter Oberparleiter. Specially the buffer gcda implementation 
> > > for
> > > iterator.
> > 
> > A couple of little tweaks:
> []
> > +++ a/kernel/gcov/gcc_4_7.c
> []
> > @@ -267,8 +266,8 @@ struct gcov_info *gcov_info_dup(struct g
> > if (!dup->filename)
> > goto err_free;
> >  
> > -   dup->functions = kzalloc(sizeof(struct gcov_fn_info *) *
> > -   info->n_functions, GFP_KERNEL);
> > +   dup->functions = kcalloc(sizeof(struct gcov_fn_info *),
> > +info->n_functions, GFP_KERNEL);
> 
> kcalloc(n, size_t, flags)
> 
>   dup->functions = kcalloc(info->n_functions,
>sizeof(struct gcov_fn_info *), GFP_KERNEL);
> 

Already did that after checkpatch whined at me.  Stupid thing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sysfs: introduce [__]sysfs_remove()

[Tejun Heo]

Given a sysfs_dirent, there is no reason to have multiple versions of
removal functions.  A function which removes the specified
sysfs_dirent and its descendants is enough.

This patch intorduces [__}sysfs_remove() which replaces all internal
variations of removal functions.  This will be the only removal
function in the planned new sysfs_dirent based interface.

Signed-off-by: Tejun Heo 
---
 fs/sysfs/dir.c   | 47 ---
 fs/sysfs/group.c |  4 ++--
 fs/sysfs/inode.c |  2 +-
 fs/sysfs/sysfs.h |  4 ++--
 4 files changed, 29 insertions(+), 28 deletions(-)

diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 0cdfd81..b518afd 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -545,7 +545,8 @@ int sysfs_add_one(struct sysfs_addrm_cxt *acxt, struct 
sysfs_dirent *sd,
  * LOCKING:
  * Determined by sysfs_addrm_start().
  */
-void sysfs_remove_one(struct sysfs_addrm_cxt *acxt, struct sysfs_dirent *sd)
+static void sysfs_remove_one(struct sysfs_addrm_cxt *acxt,
+struct sysfs_dirent *sd)
 {
struct sysfs_inode_attrs *ps_iattr;
 
@@ -775,20 +776,6 @@ const struct inode_operations sysfs_dir_inode_operations = 
{
.setxattr   = sysfs_setxattr,
 };
 
-static void remove_dir(struct sysfs_dirent *sd)
-{
-   struct sysfs_addrm_cxt acxt;
-
-   sysfs_addrm_start();
-   sysfs_remove_one(, sd);
-   sysfs_addrm_finish();
-}
-
-void sysfs_remove_subdir(struct sysfs_dirent *sd)
-{
-   remove_dir(sd);
-}
-
 static struct sysfs_dirent *sysfs_leftmost_descendant(struct sysfs_dirent *pos)
 {
struct sysfs_dirent *last;
@@ -844,25 +831,36 @@ static struct sysfs_dirent 
*sysfs_next_descendant_post(struct sysfs_dirent *pos,
return pos->s_parent;
 }
 
-static void __sysfs_remove_dir(struct sysfs_dirent *dir_sd)
+void __sysfs_remove(struct sysfs_addrm_cxt *acxt, struct sysfs_dirent *sd)
 {
-   struct sysfs_addrm_cxt acxt;
struct sysfs_dirent *pos, *next;
 
-   if (!dir_sd)
+   if (!sd)
return;
 
-   pr_debug("sysfs %s: removing dir\n", dir_sd->s_name);
-   sysfs_addrm_start();
+   pr_debug("sysfs %s: removing\n", sd->s_name);
 
next = NULL;
do {
pos = next;
-   next = sysfs_next_descendant_post(pos, dir_sd);
+   next = sysfs_next_descendant_post(pos, sd);
if (pos)
-   sysfs_remove_one(, pos);
+   sysfs_remove_one(acxt, pos);
} while (next);
+}
 
+/**
+ * sysfs_remove - remove a sysfs_dirent recursively
+ * @sd: the sysfs_dirent to remove
+ *
+ * Remove @sd along with all its subdirectories and files.
+ */
+void sysfs_remove(struct sysfs_dirent *sd)
+{
+   struct sysfs_addrm_cxt acxt;
+
+   sysfs_addrm_start();
+   __sysfs_remove(, sd);
sysfs_addrm_finish();
 }
 
@@ -882,7 +880,10 @@ void sysfs_remove_dir(struct kobject *kobj)
kobj->sd = NULL;
spin_unlock(_assoc_lock);
 
-   __sysfs_remove_dir(sd);
+   if (sd) {
+   WARN_ON_ONCE(sysfs_type(sd) != SYSFS_DIR);
+   sysfs_remove(sd);
+   }
 }
 
 int sysfs_rename(struct sysfs_dirent *sd, struct sysfs_dirent *new_parent_sd,
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 2dae55c..1898a10 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -111,7 +111,7 @@ static int internal_create_group(struct kobject *kobj, int 
update,
error = create_files(sd, kobj, grp, update);
if (error) {
if (grp->name)
-   sysfs_remove_subdir(sd);
+   sysfs_remove(sd);
}
sysfs_put(sd);
return error;
@@ -219,7 +219,7 @@ void sysfs_remove_group(struct kobject *kobj,
 
remove_files(sd, kobj, grp);
if (grp->name)
-   sysfs_remove_subdir(sd);
+   sysfs_remove(sd);
 
sysfs_put(sd);
 }
diff --git a/fs/sysfs/inode.c b/fs/sysfs/inode.c
index 364c887..63f755e 100644
--- a/fs/sysfs/inode.c
+++ b/fs/sysfs/inode.c
@@ -330,7 +330,7 @@ int sysfs_hash_and_remove(struct sysfs_dirent *dir_sd, 
const char *name,
 
sd = sysfs_find_dirent(dir_sd, name, ns);
if (sd)
-   sysfs_remove_one(, sd);
+   __sysfs_remove(, sd);
 
sysfs_addrm_finish();
 
diff --git a/fs/sysfs/sysfs.h b/fs/sysfs/sysfs.h
index 4d11544..4b1d825 100644
--- a/fs/sysfs/sysfs.h
+++ b/fs/sysfs/sysfs.h
@@ -158,7 +158,8 @@ int __sysfs_add_one(struct sysfs_addrm_cxt *acxt, struct 
sysfs_dirent *sd,
struct sysfs_dirent *parent_sd);
 int sysfs_add_one(struct sysfs_addrm_cxt *acxt, struct sysfs_dirent *sd,
  struct sysfs_dirent *parent_sd);
-void sysfs_remove_one(struct sysfs_addrm_cxt *acxt, struct sysfs_dirent *sd);
+void __sysfs_remove(struct sysfs_addrm_cxt *acxt, struct sysfs_dirent *sd);
+void sysfs_remove(struct sysfs_dirent *sd);
 void sysfs_addrm_finish(struct sysfs_addrm_cxt 

[PATCH 01/02] x86: Useless inode var, printks and coding style fixes

[Geyslan G. Bem]

file size read only one time: useless prior value allocation.
It's not necessary to verify f_op in the load_aout_library, since the
prior kernel_read/vfs_read function already does.
Coding style fixes and printk replacements.

Tested using qemu, a handcrafted a.out binary and a a.out linked with a
cross-compiled ld.

Signed-off-by: Geyslan G. Bem 
---
 fs/binfmt_aout.c | 41 ++---
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c
index 89dec7f..2307467 100644
--- a/fs/binfmt_aout.c
+++ b/fs/binfmt_aout.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -142,7 +143,8 @@ static int set_brk(unsigned long start, unsigned long end)
  * memory and creates the pointer tables from them, and puts their
  * addresses on the "stack", returning the new stack pointer value.
  */
-static unsigned long __user *create_aout_tables(char __user *p, struct 
linux_binprm * bprm)
+static unsigned long __user *create_aout_tables(char __user *p,
+   struct linux_binprm *bprm)
 {
char __user * __user *argv;
char __user * __user *envp;
@@ -213,7 +215,8 @@ static int load_aout_binary(struct linux_binprm * bprm)
if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != OMAGIC &&
 N_MAGIC(ex) != QMAGIC && N_MAGIC(ex) != NMAGIC) ||
N_TRSIZE(ex) || N_DRSIZE(ex) ||
-   i_size_read(file_inode(bprm->file)) < 
ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+   i_size_read(file_inode(bprm->file)) <
+   ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
return -ENOEXEC;
}
 
@@ -292,19 +295,16 @@ static int load_aout_binary(struct linux_binprm * bprm)
}
} else {
if ((ex.a_text & 0xfff || ex.a_data & 0xfff) &&
-   (N_MAGIC(ex) != NMAGIC) && printk_ratelimit())
+   (N_MAGIC(ex) != NMAGIC))
{
-   printk(KERN_NOTICE "executable not page aligned\n");
+   pr_notice_ratelimited("executable not page aligned\n");
}
 
-   if ((fd_offset & ~PAGE_MASK) != 0 && printk_ratelimit())
-   {
-   printk(KERN_WARNING 
-  "fd_offset is not page aligned. Please convert 
program: %s\n",
-  bprm->file->f_path.dentry->d_name.name);
-   }
+   if ((fd_offset & ~PAGE_MASK) != 0)
+   pr_warn_ratelimited("fd_offset is not page aligned. 
Please convert program: %s\n",
+   
bprm->file->f_path.dentry->d_name.name);
 
-   if (!bprm->file->f_op->mmap||((fd_offset & ~PAGE_MASK) != 0)) {
+   if ((fd_offset & ~PAGE_MASK) != 0) {
vm_brk(N_TXTADDR(ex), ex.a_text+ex.a_data);
read_code(bprm->file, N_TXTADDR(ex), fd_offset,
  ex.a_text + ex.a_data);
@@ -350,14 +350,11 @@ beyond_if:
 
 static int load_aout_library(struct file *file)
 {
-   struct inode * inode;
unsigned long bss, start_addr, len;
unsigned long error;
int retval;
struct exec ex;
 
-   inode = file_inode(file);
-
retval = -ENOEXEC;
error = kernel_read(file, 0, (char *) , sizeof(ex));
if (error != sizeof(ex))
@@ -366,7 +363,8 @@ static int load_aout_library(struct file *file)
/* We come in here for the regular a.out style of shared libraries */
if ((N_MAGIC(ex) != ZMAGIC && N_MAGIC(ex) != QMAGIC) || N_TRSIZE(ex) ||
N_DRSIZE(ex) || ((ex.a_entry & 0xfff) && N_MAGIC(ex) == ZMAGIC) ||
-   i_size_read(inode) < 
ex.a_text+ex.a_data+N_SYMSIZE(ex)+N_TXTOFF(ex)) {
+   i_size_read(file_inode(file)) <
+   ex.a_text + ex.a_data + N_SYMSIZE(ex) + N_TXTOFF(ex)) {
goto out;
}
 
@@ -374,7 +372,7 @@ static int load_aout_library(struct file *file)
 * Requires a mmap handler. This prevents people from using a.out
 * as part of an exploit attack against /proc-related vulnerabilities.
 */
-   if (!file->f_op || !file->f_op->mmap)
+   if (!file->f_op->mmap)
goto out;
 
if (N_FLAGS(ex))
@@ -386,14 +384,11 @@ static int load_aout_library(struct file *file)
start_addr =  ex.a_entry & 0xf000;
 
if ((N_TXTOFF(ex) & ~PAGE_MASK) != 0) {
-   if (printk_ratelimit())
-   {
-   printk(KERN_WARNING 
-  "N_TXTOFF is not page aligned. Please convert 
library: %s\n",
-  file->f_path.dentry->d_name.name);
-   }
+   pr_warn_ratelimited("N_TXTOFF is not page aligned. Please 
convert library: %s\n",
+   

[PATCH 02/02] x86_64: Add safe check in a.out loaders and some coding style

[Geyslan G. Bem]

ia32_aout had no safe checks concerning the mmap and f_op in this module.
It's not necessary to verify f_op in the load_aout_library, since the
prior kernel_read/vfs_read function already does.
Coding style and printks fixes.

Tested using qemu, a handcrafted a.out binary and a a.out linked with a
cross-compiled ld.

Signed-off-by: Geyslan G. Bem 
---
 arch/x86/ia32/ia32_aout.c | 25 ++---
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/arch/x86/ia32/ia32_aout.c b/arch/x86/ia32/ia32_aout.c
index 15a8319..46a0346 100644
--- a/arch/x86/ia32/ia32_aout.c
+++ b/arch/x86/ia32/ia32_aout.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
@@ -346,21 +346,13 @@ static int load_aout_binary(struct linux_binprm *bprm)
}
} else {
 #ifdef WARN_OLD
-   static unsigned long error_time, error_time2;
if ((ex.a_text & 0xfff || ex.a_data & 0xfff) &&
-   (N_MAGIC(ex) != NMAGIC) &&
-   time_after(jiffies, error_time2 + 5*HZ)) {
-   printk(KERN_NOTICE "executable not page aligned\n");
-   error_time2 = jiffies;
-   }
+   (N_MAGIC(ex) != NMAGIC))
+   pr_notice_ratelimited("executable not page aligned\n");
 
-   if ((fd_offset & ~PAGE_MASK) != 0 &&
-   time_after(jiffies, error_time + 5*HZ)) {
-   printk(KERN_WARNING
-  "fd_offset is not page aligned. Please convert 
program: %s\n",
+   if ((fd_offset & ~PAGE_MASK) != 0)
+   pr_warn_ratelimited("fd_offset is not page aligned. 
Please convert program: %s\n",
   bprm->file->f_path.dentry->d_name.name);
-   error_time = jiffies;
-   }
 #endif
 
if ((fd_offset & ~PAGE_MASK) != 0) {
@@ -451,13 +443,8 @@ static int load_aout_library(struct file *file)
 
if ((N_TXTOFF(ex) & ~PAGE_MASK) != 0) {
 #ifdef WARN_OLD
-   static unsigned long error_time;
-   if (time_after(jiffies, error_time + 5*HZ)) {
-   printk(KERN_WARNING
-  "N_TXTOFF is not page aligned. Please convert 
library: %s\n",
+   pr_warn_ratelimited("N_TXTOFF is not page aligned. Please 
convert library: %s\n",
   file->f_path.dentry->d_name.name);
-   error_time = jiffies;
-   }
 #endif
vm_brk(start_addr, ex.a_text + ex.a_data + ex.a_bss);
 
-- 
1.8.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 v2 2/4] gcov: add support for gcc 4.7 gcov format

[Joe Perches]

On Wed, 2013-09-18 at 14:22 -0700, Andrew Morton wrote:
> On Wed,  4 Sep 2013 16:42:54 +0200 Frantisek Hrbata  
> wrote:
> > The gcov in-memory format changed in gcc 4.7. The biggest change, which
> > requires this special implementation, is that gcov_info no longer contains
> > array of counters for each counter type for all functions and gcov_fn_info 
> > is
> > not used for mapping of function's counters to these arrays(offset). Now 
> > each
> > gcov_fn_info contans it's counters, which makes things a little bit easier.
> > 
> > This is heavily based on the previous gcc_3_4.c implementation and patches
> > provided by Peter Oberparleiter. Specially the buffer gcda implementation 
> > for
> > iterator.
> 
> A couple of little tweaks:
[]
> +++ a/kernel/gcov/gcc_4_7.c
[]
> @@ -267,8 +266,8 @@ struct gcov_info *gcov_info_dup(struct g
>   if (!dup->filename)
>   goto err_free;
>  
> - dup->functions = kzalloc(sizeof(struct gcov_fn_info *) *
> - info->n_functions, GFP_KERNEL);
> + dup->functions = kcalloc(sizeof(struct gcov_fn_info *),
> +  info->n_functions, GFP_KERNEL);

kcalloc(n, size_t, flags)

dup->functions = kcalloc(info->n_functions,
 sizeof(struct gcov_fn_info *), GFP_KERNEL);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv5 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

On 18-09-2013 17:04, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:57 -0400, Eduardo Valentin wrote:
>> This patch introduces a device tree bindings for
>> describing the hardware thermal behavior and limits.
>> Also a parser to read and interpret the data and feed
>> it in the thermal framework is presented.
> []
>> +int __init of_parse_thermal_zones(void)
>> +{
>> +struct device_node *np, *child;
>> +struct __thermal_zone *tz;
>> +struct thermal_zone_device_ops *ops;
> []
>> +if (!ops)
>> +return -ENOMEM;
>> +
>> +tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +if (!tzp)
>> +return -ENOMEM;
> 
> leaking memory when ops && !tpz

Yeah, and if !ops too. I am reposting with proper kfreeing. I will be
rolling back the added thermal zones when there is an OOM situation too.

> 
>> +
>> +/* No hwmon because there might be hwmon drivers registering */
>> +tzp->no_hwmon = true;
>> +
>> +zone = thermal_zone_device_register(child->name, tz->ntrips,
>> +0, tz,
>> +ops, tzp,
>> +tz->passive_delay,
>> +tz->polling_delay);
>> +if (IS_ERR(zone))
>> +pr_err("Failed to build %s zone %ld\n", child->name,
>> +   PTR_ERR(zone));
>> +}
> 
> Still leaking memory if !zone no?

yeah. Will free them too.
> 
>> +
>> +return 0;
>> +}
> 
> 
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 2/4] gcov: add support for gcc 4.7 gcov format

[Andrew Morton]

On Wed,  4 Sep 2013 16:42:54 +0200 Frantisek Hrbata  wrote:

> The gcov in-memory format changed in gcc 4.7. The biggest change, which
> requires this special implementation, is that gcov_info no longer contains
> array of counters for each counter type for all functions and gcov_fn_info is
> not used for mapping of function's counters to these arrays(offset). Now each
> gcov_fn_info contans it's counters, which makes things a little bit easier.
> 
> This is heavily based on the previous gcc_3_4.c implementation and patches
> provided by Peter Oberparleiter. Specially the buffer gcda implementation for
> iterator.

A couple of little tweaks:

--- a/kernel/gcov/gcc_4_7.c~gcov-add-support-for-gcc-47-gcov-format-fix
+++ a/kernel/gcov/gcc_4_7.c
@@ -254,11 +254,10 @@ struct gcov_info *gcov_info_dup(struct g
size_t fi_size; /* function info size */
size_t cv_size; /* counter values size */
 
-   dup = kmalloc(sizeof(struct gcov_info), GFP_KERNEL);
+   dup = kmemdup(info, sizeof(*dup), GFP_KERNEL);
if (!dup)
return NULL;
 
-   *dup = *info;
dup->next = NULL;
dup->filename = NULL;
dup->functions = NULL;
@@ -267,8 +266,8 @@ struct gcov_info *gcov_info_dup(struct g
if (!dup->filename)
goto err_free;
 
-   dup->functions = kzalloc(sizeof(struct gcov_fn_info *) *
-   info->n_functions, GFP_KERNEL);
+   dup->functions = kcalloc(sizeof(struct gcov_fn_info *),
+info->n_functions, GFP_KERNEL);
if (!dup->functions)
goto err_free;
 
_

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

Regression on cpufreq in v3.12-rc1

[Linus Walleij]

Hi Rafael, Viresh,

I'm seeing this problem and maybe you can help me out fixing it
properly:

On some machines like the StrongARM SA1100 it seems that
cpufreq_get() can be called before the cpufreq driver and thus the
policy is set, resulting in a crash like this:


[ cut here ]

kernel BUG at /home/linus/linux/drivers/cpufreq/cpufreq.c:80!

Internal error: Oops - BUG: 0 [#1] ARM

Modules linked in:

CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc1-1-g1266dae-dirty #17

task: c183 ti: c1832000 task.ti: c1832000
(...)
Backtrace:
[] (lock_policy_rwsem_read+0x0/0x48) from []
(cpufreq_get+0x34/0x68)
[] (cpufreq_get+0x0/0x68) from []
(sa1100fb_activate_var+0xdc/0x3ac)
 r5:0003 r4:000a
[] (sa1100fb_activate_var+0x0/0x3ac) from []
(sa1100fb_set_par+0xa0/0xa8)
[] (sa1100fb_set_par+0x0/0xa8) from []
(fbcon_init+0x444/0x4a8)
 r4:c1803200
[] (fbcon_init+0x0/0x4a8) from [] (visual_init+0x78/0xc8)
[] (visual_init+0x0/0xc8) from []
(do_bind_con_driver+0x160/0x310)

This bug comes from the framebuffer but I first encountered it
in the PCMCIA driver, and both seem to cause the bug.

In the past I think things worked smoothly: the consumers
calling cpufreq_get() too early would just get 0 back.
(Or so it seems to me.)

The BUG() statement causing it is in the lock_policy_rwsem_##mode(int cpu)
macro.

Applying a patch like this seems to fix the issue:

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 43c24aa..4977b4b 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -70,7 +70,8 @@ static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
 static int lock_policy_rwsem_##mode(int cpu)   \
 {  \
struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu); \
-   BUG_ON(!policy);\
+   if(!policy) \
+   return 0;   \
down_##mode(_cpu(cpu_policy_rwsem, policy->cpu));   \
\
return 0;   \
@@ -83,7 +84,8 @@ lock_policy_rwsem(write, cpu);
 static void unlock_policy_rwsem_##mode(int cpu)
 \
 {  \
struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu); \
-   BUG_ON(!policy);\
+   if(!policy) \
+   return; \
up_##mode(_cpu(cpu_policy_rwsem, policy->cpu)); \
 }

@@ -1423,6 +1425,9 @@ static unsigned int __cpufreq_get(unsigned int cpu)
struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
unsigned int ret_freq = 0;

+   if (!policy)
+   return ret_freq;
+
if (!cpufreq_driver->get)
return ret_freq;

I don't really know if this is the right solution at all, so please
help me out here... if you want that patch I can send it once
I understand this properly.

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

[PATCH 3/4] sysfs: make __sysfs_remove_dir() recursive

[Tejun Heo]

Currently, sysfs directory removal is inconsistent in that it would
remove any files directly under it but wouldn't recurse into
directories.  Thanks to group subdirectories, this doesn't even match
with kobject boundaries.  sysfs is in the process of being separated
out so that it can be used by multiple subsystems and we want to have
a consistent behavior - either removal of a sysfs_dirent should remove
every descendant entries or none instead of something inbetween.

This patch implements proper recursive removal in
__sysfs_remove_dir().  The function now walks its subtree in a
post-order walk to remove all descendants.

This is a behavior change but kobject / driver layer, which currently
is the only consumer, has already been updated to handle duplicate
removal attempts, so nothing should be broken after this change.

Signed-off-by: Tejun Heo 
---
 fs/sysfs/dir.c | 75 +-
 1 file changed, 64 insertions(+), 11 deletions(-)

diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 105a7e2..0cdfd81 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -789,27 +789,81 @@ void sysfs_remove_subdir(struct sysfs_dirent *sd)
remove_dir(sd);
 }
 
+static struct sysfs_dirent *sysfs_leftmost_descendant(struct sysfs_dirent *pos)
+{
+   struct sysfs_dirent *last;
+
+   while (true) {
+   struct rb_node *rbn;
+
+   last = pos;
+
+   if (sysfs_type(pos) != SYSFS_DIR)
+   break;
+
+   rbn = rb_first(>s_dir.children);
+   if (!rbn)
+   break;
+
+   pos = to_sysfs_dirent(rbn);
+   }
+
+   return last;
+}
+
+/**
+ * sysfs_next_descendant_post - find the next descendant for post-order walk
+ * @pos: the current position (%NULL to initiate traversal)
+ * @root: sysfs_dirent whose descendants to walk
+ *
+ * Find the next descendant to visit for post-order traversal of @root's
+ * descendants.  @root is included in the iteration and the last node to be
+ * visited.
+ */
+static struct sysfs_dirent *sysfs_next_descendant_post(struct sysfs_dirent 
*pos,
+  struct sysfs_dirent 
*root)
+{
+   struct rb_node *rbn;
+
+   lockdep_assert_held(_mutex);
+
+   /* if first iteration, visit leftmost descendant which may be root */
+   if (!pos)
+   return sysfs_leftmost_descendant(root);
+
+   /* if we visited @root, we're done */
+   if (pos == root)
+   return NULL;
+
+   /* if there's an unvisited sibling, visit its leftmost descendant */
+   rbn = rb_next(>s_rb);
+   if (rbn)
+   return sysfs_leftmost_descendant(to_sysfs_dirent(rbn));
+
+   /* no sibling left, visit parent */
+   return pos->s_parent;
+}
 
 static void __sysfs_remove_dir(struct sysfs_dirent *dir_sd)
 {
struct sysfs_addrm_cxt acxt;
-   struct rb_node *pos;
+   struct sysfs_dirent *pos, *next;
 
if (!dir_sd)
return;
 
pr_debug("sysfs %s: removing dir\n", dir_sd->s_name);
sysfs_addrm_start();
-   pos = rb_first(_sd->s_dir.children);
-   while (pos) {
-   struct sysfs_dirent *sd = to_sysfs_dirent(pos);
-   pos = rb_next(pos);
-   if (sysfs_type(sd) != SYSFS_DIR)
-   sysfs_remove_one(, sd);
-   }
-   sysfs_addrm_finish();
 
-   remove_dir(dir_sd);
+   next = NULL;
+   do {
+   pos = next;
+   next = sysfs_next_descendant_post(pos, dir_sd);
+   if (pos)
+   sysfs_remove_one(, pos);
+   } while (next);
+
+   sysfs_addrm_finish();
 }
 
 /**
@@ -820,7 +874,6 @@ static void __sysfs_remove_dir(struct sysfs_dirent *dir_sd)
  * the directory before we remove the directory, and we've inlined
  * what used to be sysfs_rmdir() below, instead of calling separately.
  */
-
 void sysfs_remove_dir(struct kobject *kobj)
 {
struct sysfs_dirent *sd = kobj->sd;
-- 
1.8.3.1

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

[PATCH 1/4] sysfs: remove sysfs_addrm_cxt->parent_sd

[Tejun Heo]

sysfs_addrm_start/finish() enclose sysfs_dirent additions and
deletions and sysfs_addrm_cxt is used to record information necessary
to finish the operations.  Currently, sysfs_addrm_start() takes
@parent_sd, records it in sysfs_addrm_cxt, and assumes that all
operations in the block are performed under that @parent_sd.

This assumption has been fine until now but we want to make some
operations behave recursively and, while having @parent_sd recorded in
sysfs_addrm_cxt doesn't necessarily prevents that, it becomes
confusing.

This patch removes sysfs_addrm_cxt->parent_sd and makes
sysfs_add_one() take an explicit @parent_sd parameter.  Note that
sysfs_remove_one() doesn't need the extra argument as its parent is
always known from the target @sd.

While at it, add __acquires/releases() notations to
sysfs_addrm_start/finish() respectively.

This patch doesn't make any functional difference.

Signed-off-by: Tejun Heo 
---
 fs/sysfs/dir.c | 52 +++-
 fs/sysfs/file.c|  4 ++--
 fs/sysfs/inode.c   |  2 +-
 fs/sysfs/symlink.c |  6 +++---
 fs/sysfs/sysfs.h   | 10 +-
 5 files changed, 38 insertions(+), 36 deletions(-)

diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index d23e66d..6718689 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -406,22 +406,19 @@ struct sysfs_dirent *sysfs_new_dirent(const char *name, 
umode_t mode, int type)
 /**
  * sysfs_addrm_start - prepare for sysfs_dirent add/remove
  * @acxt: pointer to sysfs_addrm_cxt to be used
- * @parent_sd: parent sysfs_dirent
  *
- * This function is called when the caller is about to add or
- * remove sysfs_dirent under @parent_sd.  This function acquires
- * sysfs_mutex.  @acxt is used to keep and pass context to
- * other addrm functions.
+ * This function is called when the caller is about to add or remove
+ * sysfs_dirent.  This function acquires sysfs_mutex.  @acxt is used
+ * to keep and pass context to other addrm functions.
  *
  * LOCKING:
  * Kernel thread context (may sleep).  sysfs_mutex is locked on
  * return.
  */
-void sysfs_addrm_start(struct sysfs_addrm_cxt *acxt,
-  struct sysfs_dirent *parent_sd)
+void sysfs_addrm_start(struct sysfs_addrm_cxt *acxt)
+   __acquires(sysfs_mutex)
 {
memset(acxt, 0, sizeof(*acxt));
-   acxt->parent_sd = parent_sd;
 
mutex_lock(_mutex);
 }
@@ -430,10 +427,11 @@ void sysfs_addrm_start(struct sysfs_addrm_cxt *acxt,
  * __sysfs_add_one - add sysfs_dirent to parent without warning
  * @acxt: addrm context to use
  * @sd: sysfs_dirent to be added
+ * @parent_sd: the parent sysfs_dirent to add @sd to
  *
- * Get @acxt->parent_sd and set sd->s_parent to it and increment
- * nlink of parent inode if @sd is a directory and link into the
- * children list of the parent.
+ * Get @parent_sd and set @sd->s_parent to it and increment nlink of
+ * the parent inode if @sd is a directory and link into the children
+ * list of the parent.
  *
  * This function should be called between calls to
  * sysfs_addrm_start() and sysfs_addrm_finish() and should be
@@ -446,20 +444,21 @@ void sysfs_addrm_start(struct sysfs_addrm_cxt *acxt,
  * 0 on success, -EEXIST if entry with the given name already
  * exists.
  */
-int __sysfs_add_one(struct sysfs_addrm_cxt *acxt, struct sysfs_dirent *sd)
+int __sysfs_add_one(struct sysfs_addrm_cxt *acxt, struct sysfs_dirent *sd,
+   struct sysfs_dirent *parent_sd)
 {
struct sysfs_inode_attrs *ps_iattr;
int ret;
 
sd->s_hash = sysfs_name_hash(sd->s_name, sd->s_ns);
-   sd->s_parent = sysfs_get(acxt->parent_sd);
+   sd->s_parent = sysfs_get(parent_sd);
 
ret = sysfs_link_sibling(sd);
if (ret)
return ret;
 
/* Update timestamps on the parent */
-   ps_iattr = acxt->parent_sd->s_iattr;
+   ps_iattr = parent_sd->s_iattr;
if (ps_iattr) {
struct iattr *ps_iattrs = _iattr->ia_iattr;
ps_iattrs->ia_ctime = ps_iattrs->ia_mtime = CURRENT_TIME;
@@ -493,10 +492,11 @@ static char *sysfs_pathname(struct sysfs_dirent *sd, char 
*path)
  * sysfs_add_one - add sysfs_dirent to parent
  * @acxt: addrm context to use
  * @sd: sysfs_dirent to be added
+ * @parent_sd: the parent sysfs_dirent to add @sd to
  *
- * Get @acxt->parent_sd and set sd->s_parent to it and increment
- * nlink of parent inode if @sd is a directory and link into the
- * children list of the parent.
+ * Get @parent_sd and set @sd->s_parent to it and increment nlink of
+ * the parent inode if @sd is a directory and link into the children
+ * list of the parent.
  *
  * This function should be called between calls to
  * sysfs_addrm_start() and sysfs_addrm_finish() and should be
@@ -509,17 +509,18 @@ static char *sysfs_pathname(struct sysfs_dirent *sd, char 

Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Alan Tull]

On Wed, 2013-09-18 at 14:32 -0600, Jason Gunthorpe wrote:
> On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
> 
> > + Jason Gunthorpe
> 
> Thanks, looks interesting, we could possibly use this interface if it 
> met our needs..
>  
> > On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
> > > This new subsystem should unify all fpga drivers which
> > > do the same things. Load configuration data to fpga
> > > or another programmable logic through common interface.
> > > It doesn't matter if it is MMIO device, gpio bitbanging,
> > > etc. connection. The point is to have the same
> > > inteface for these drivers.
> 
> So, we have many years of in-field experience with this and this API
> doesn't really match what we do.
> 
> Here are the steps we perform, from userspace:
>  - Ask kernel to place FPGA into reset and prepare for programming
>* Kernel can return an error (eg FPGA failed to erase, etc)
>* this is the PROG_N low -> DONE high, PROG_N high -> INIT_N high
>  sequencing on Xilinx chips
>  - Ask kernel to load a bitstream.
>* Userspace locats the bitstream file to load, and the mmaps it.
>* Userspace passes the entire file in a single write() call to the
>  kernel which streams it over the configuration bus
>* The kernel can report an erro rhere (eg Xilinx can report CRC
>error)
>  - Ask the kernel to verify that configuration is complete. 
>* On Xilinx this wait for done to go high
>  - Ask the kernel to release the configuration bus (tristate
>all drivers) (or sometimes we have to drive the bus low,
>it depends on the bitfile, user space knows what to do)
> 
> It is very important that userspace know exactly which step fails
> because the resolution is different. We use this in a manufacturing
> setting, so failures are expected and need quick root cause
> determination.
> 
> You could probably address that need by very clearly defining a
> variety of errno values for the various cases. However, it would be a
> disaster if every driver did something a little different :|
> 
> Using request_firmware exclusively is not useful for us. We
> format the bitfile with a header that contains our internal tracking
> information. Sometimes we need to bitswap the bitfile. Our userspace
> handles all of this and can pass a bitfile in memory to write().
> 
> request_firmware would be horrible to use :)
> 
> Our API uses a binary sysfs attribute to stream the FPGA data, you
> might want to consider that.
> 
> Regards,
> Jason

The firmware approach is interesting.  It might be less flexible
compared with my original code (see link to git below) that this is
based on.  The original code created a devnode like /dev/fpga0 and a raw
bitstream could be loaded by doing 'cat bitstream > /dev/fpga0'.  Or
some other userspace app could write the /dev/fpga0 to handle any
headers that needed to be added to the bitstream.

This code also creates a set of files under /sys for each separate fpga.
I.e. checking status by looking at /sys/class/fpga/fpag0/status.  It
would be pretty small changes to control reseting the fpga by adding a
'reset' file there also (added first to the framework, and an interface
into the low level fpga manager driver).

I am trying this out with my low level fpga manager driver.  I'm very
curious about your approach and I am wondering whether the firmware
approach will work for us or not.

Will this framework handle more than one fpga at a time?

Is there some way a per-device userspace helper can be added that can
handle adding the headers?  Such that different fpga types get different
helpers?

My fpga framework code is in git at:
http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=commit;h=7b7c04ef3f8589349211bdfe884e42d6b7554b27

and

http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=commit;h=57ee6197d65015620cd6aad435a695ce00a48a8c

Best Regards,
Alan

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


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

[PATCHSET] sysfs: implement sysfs_remove()

[Tejun Heo]

Hello,

Currently, there are multiple variants of internal sysfs removal
functions and the directory removal behavior is a bit weird in that
while it does remove the files contained immediately in the directory
it wouldn't recurse into its subdirectories, even the group ones which
belong to the same kobject.

This patchset restructures sysfs removal path so that there is single
internal removal function which is fully recursive.  This will be the
only removal interface in the planned new interface based on
sysfs_dirents instead of kobjects.

This patchset contains the following four patches.

 0001-sysfs-remove-sysfs_addrm_cxt-parent_sd.patch
 0002-kobject-grab-an-extra-reference-on-kobject-sd-to-all.patch
 0003-sysfs-make-__sysfs_remove_dir-recursive.patch
 0004-sysfs-introduce-__-sysfs_remove.patch

The patches are on top of

  linus#master c2d95729e3 ("Merge branch 'akpm' (patches from Andrew Morton)")
+ [1] [PATCHSET] sysfs: disentangle kobject namespace handling from sysfs

and available in the following git branch.

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git 
review-sysfs-recursive-rm

 fs/sysfs/dir.c |  161 -
 fs/sysfs/file.c|4 -
 fs/sysfs/group.c   |4 -
 fs/sysfs/inode.c   |4 -
 fs/sysfs/symlink.c |6 -
 fs/sysfs/sysfs.h   |   14 ++--
 lib/kobject.c  |   12 +++
 7 files changed, 139 insertions(+), 66 deletions(-)

Thanks.

--
tejun

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

[PATCH 2/4] kobject: grab an extra reference on kobject->sd to allow duplicate deletes

[Tejun Heo]

sysfs currently has a rather weird behavior regarding removals.  A
directory removal would delete all files directly under it but
wouldn't recurse into subdirectories, which, while a bit inconsistent,
seems to make sense at the first glance as each directory is
supposedly associated with a kobject and each kobject can take care of
the directory deletion; however, this doesn't really hold as we have
groups which can be directories without a kobject associated with it
and require explicit deletions.

We're in the process of separating out sysfs from kboject / driver
core and want a consistent behavior.  A removal should delete either
only the specified node or everything under it.  I think it is helpful
to support recursive atomic removal and later patches will implement
it.

Such change means that a sysfs_dirent associated with kobject may be
deleted before the kobject itself is removed if one of its ancestor
gets removed before it.  As sysfs_remove_dir() puts the base ref, we
may end up with dangling pointer on descendants.  This can be solved
by holding an extra reference on the sd from kobject.

Acquire an extra reference on the associated sysfs_dirent on directory
creation and put it after removal.

Signed-off-by: Tejun Heo 
---
 fs/sysfs/dir.c |  7 ++-
 lib/kobject.c  | 12 
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 6718689..105a7e2 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -549,7 +549,12 @@ void sysfs_remove_one(struct sysfs_addrm_cxt *acxt, struct 
sysfs_dirent *sd)
 {
struct sysfs_inode_attrs *ps_iattr;
 
-   BUG_ON(sd->s_flags & SYSFS_FLAG_REMOVED);
+   /*
+* Removal can be called multiple times on the same node.  Only the
+* first invocation is effective and puts the base ref.
+*/
+   if (sd->s_flags & SYSFS_FLAG_REMOVED)
+   return;
 
sysfs_unlink_sibling(sd);
 
diff --git a/lib/kobject.c b/lib/kobject.c
index e769ee3..aa42d7d 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -75,6 +75,13 @@ static int create_dir(struct kobject *kobj)
if (error)
sysfs_remove_dir(kobj);
}
+
+   /*
+* @kobj->sd may be deleted by an ancestor going away.  Hold an
+* extra reference so that it stays until @kobj is gone.
+*/
+   sysfs_get(kobj->sd);
+
return error;
 }
 
@@ -531,10 +538,15 @@ out:
  */
 void kobject_del(struct kobject *kobj)
 {
+   struct sysfs_dirent *sd;
+
if (!kobj)
return;
 
+   sd = kobj->sd;
sysfs_remove_dir(kobj);
+   sysfs_put(sd);
+
kobj->state_in_sysfs = 0;
kobj_kset_leave(kobj);
kobject_put(kobj->parent);
-- 
1.8.3.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: [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

On 18-09-2013 17:00, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:52 -0400, Eduardo Valentin wrote:
>> On 18-09-2013 16:44, Joe Perches wrote:
>>> On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:
>>>
 +/**
 + * of_parse_thermal_zones - parse device tree thermal data
 + *
 + * Initialization function that can be called by machine initialization
 + * code to parse thermal data and populate the thermal framework
 + * with hardware thermal zones info. This function only parses thermal 
 zones.
 + * Cooling devices and sensor devices nodes are supposed to be parsed
 + * by their respective drivers.
 + *
 + * Return: 0 on success, proper error code otherwise
 + *
 + */
 +int __init of_parse_thermal_zones(void)
 +{
 +  struct device_node *np, *child;
 +  struct __thermal_zone *tz;
 +  struct thermal_zone_device_ops *ops;
 +
 +  np = of_find_node_by_name(NULL, "thermal-zones");
 +  if (!np) {
 +  pr_err("unable to find thermal zones\n");
 +  return 0;
>>>
>>> return 0? This is success?
>>
>> This case is success because there should be systems without thermal DT
>> entries.
> 
> Then the pr_err should be pr_notice/info or not there at all.

Yeah, done in v5.

> 
> []
> 
 +  /* No hwmon because there might be hwmon drivers registering */
 +  tzp->no_hwmon = true;
 +
 +  zone = thermal_zone_device_register(child->name, tz->ntrips,
 +  0, tz,
 +  ops, tzp,
 +  tz->passive_delay,
 +  tz->polling_delay);
 +  if (IS_ERR(zone))
 +  pr_err("Failed to build %s zone %ld\n", child->name,
 + PTR_ERR(zone));
> 
> Should there should be a return -ERR here?
> 

well, no, there might be other correct thermal zones in DT that needs
parsing.

>> hmmm.. I am sending after reworking the return code of this function.
> 
> thanks.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCHv5 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 16:57 -0400, Eduardo Valentin wrote:
> This patch introduces a device tree bindings for
> describing the hardware thermal behavior and limits.
> Also a parser to read and interpret the data and feed
> it in the thermal framework is presented.
[]
> +int __init of_parse_thermal_zones(void)
> +{
> + struct device_node *np, *child;
> + struct __thermal_zone *tz;
> + struct thermal_zone_device_ops *ops;
[]
> + if (!ops)
> + return -ENOMEM;
> +
> + tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> + if (!tzp)
> + return -ENOMEM;

leaking memory when ops && !tpz

> +
> + /* No hwmon because there might be hwmon drivers registering */
> + tzp->no_hwmon = true;
> +
> + zone = thermal_zone_device_register(child->name, tz->ntrips,
> + 0, tz,
> + ops, tzp,
> + tz->passive_delay,
> + tz->polling_delay);
> + if (IS_ERR(zone))
> + pr_err("Failed to build %s zone %ld\n", child->name,
> +PTR_ERR(zone));
> + }

Still leaking memory if !zone no?

> +
> + return 0;
> +}


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

Re: [PATCH 00/26] ARM: provide common arch init for DT clocks

[Sebastian Hesselbarth]

On 09/18/2013 10:48 PM, Olof Johansson wrote:

On Wed, Sep 18, 2013 at 12:52 PM, Sebastian Hesselbarth
 wrote:

On 09/18/2013 09:47 PM, Jason Cooper wrote:


On Wed, Sep 18, 2013 at 07:53:33PM +0200, Sebastian Hesselbarth wrote:
...


Sebastian Hesselbarth (26):
ARM: nomadik: move mtu setup to clocksource init
clk: nomadik: move src init out of nomadik_clk_init
clk: nomadik: declare OF clock provider
clk: prima2: declare OF clock provider
ARM: socfgpa: prepare for arch-wide .init_time callback
clk: sunxi: declare OF clock provider
clk: vt8500: parse pmc_base from clock driver
ARM: vt8500: prepare for arch-wide .init_time callback
ARM: call of_clk_init from default time_init handler
ARM: bcm2835: remove custom .init_time hook
ARM: dove: remove custom .init_time hook
ARM: exynos: remove custom .init_time hook
ARM: highbank: remove custom .init_time hook
ARM: imx: remove custom .init_time hook
ARM: kirkwood: remove custom .init_time hook
ARM: mxs: remove custom .init_time hook
ARM: nomadik: remove custom .init_time hook
ARM: nspire: remove custom .init_time hook
ARM: prima2: remove custom .init_time hook
ARM: rockchip: remove custom .init_time hook
ARM: socfpga: remove custom .init_time hook
ARM: sti: remove custom .init_time hook
ARM: sunxi: remove custom .init_time hook
ARM: tegra: remove custom .init_time hook
ARM: vexpress: remove custom .init_time hook
ARM: vt8500: remove custom .init_time hook

   arch/arm/kernel/time.c|   27 ++---
   arch/arm/mach-bcm2835/bcm2835.c   |2 -
   arch/arm/mach-dove/board-dt.c |   11 --
   arch/arm/mach-exynos/common.c |8 --
   arch/arm/mach-exynos/common.h |1 -
   arch/arm/mach-exynos/mach-exynos4-dt.c|2 -
   arch/arm/mach-exynos/mach-exynos5-dt.c|2 -
   arch/arm/mach-highbank/highbank.c |   23 ++---
   arch/arm/mach-imx/clk-imx51-imx53.c   |   29 ++
   arch/arm/mach-imx/common.h|4 -
   arch/arm/mach-imx/imx51-dt.c  |6 --
   arch/arm/mach-imx/mach-imx53.c|6 --
   arch/arm/mach-imx/mach-imx6q.c|   14 +--
   arch/arm/mach-imx/mach-imx6sl.c   |7 --
   arch/arm/mach-imx/mach-vf610.c|9 --
   arch/arm/mach-kirkwood/board-dt.c |8 --
   arch/arm/mach-mxs/mach-mxs.c  |   13 ---
   arch/arm/mach-nomadik/cpu-8815.c  |   36 ---
   arch/arm/mach-nspire/nspire.c |9 --
   arch/arm/mach-prima2/common.c |   11 --
   arch/arm/mach-prima2/common.h |1 -
   arch/arm/mach-rockchip/rockchip.c |9 --
   arch/arm/mach-socfpga/socfpga.c   |2 -
   arch/arm/mach-sti/board-dt.c  |   10 +-
   arch/arm/mach-sunxi/sunxi.c   |   10 --
   arch/arm/mach-tegra/tegra.c   |9 --
   arch/arm/mach-vexpress/v2m.c  |   14 +--
   arch/arm/mach-vt8500/common.h |   24 -
   arch/arm/mach-vt8500/vt8500.c |6 --
   drivers/clk/clk-bcm2835.c |8 --
   drivers/clk/clk-highbank.c|   10 +-
   drivers/clk/clk-nomadik.c |  161
++---
   drivers/clk/clk-prima2.c  |   29 ++
   drivers/clk/clk-vt8500.c  |   31 --
   drivers/clk/mxs/clk-imx23.c   |   15 +--
   drivers/clk/mxs/clk-imx28.c   |   16 +--
   drivers/clk/sunxi/clk-sunxi.c |   11 +-
   drivers/clocksource/nomadik-mtu.c |   11 ++
   include/linux/clk/mxs.h   |2 -
   include/linux/clk/sunxi.h |   22 
   include/linux/platform_data/clk-nomadik.h |2 -
   41 files changed, 182 insertions(+), 449 deletions(-)
   delete mode 100644 arch/arm/mach-vt8500/common.h
   delete mode 100644 include/linux/clk/sunxi.h
   delete mode 100644 include/linux/platform_data/clk-nomadik.h



How would you like to handle this series?



Jason,

honestly I don't really know, yet. I was hoping for Arnd and Olof
decide on that. Maybe they also create a topic branch up to where
arch-wide of_clk_init is introduced. Then each removal patch can
go through the independent sub-trees. There may be more machs
introduced before, that can then also depend on the common branch.


I'd like to see this merged early into arm-soc and have it as a base
branch for other platform branches if there will be much conflicts
(for trivial or small conflicts we can resolve, of course). So please
collect acks and prepare a branch for me to merge, Sebastian. Or if
it's easier I can just apply the patches directly -- just let me know.
But given the tegra dependency it's probably easier to take a branch.


Actually, I'd be happy if you make a decision. It would be my first
pull request and maybe it should go guided by more experienced devs
from now 

[PATCH] Fixed typo on word accounting in kprobes.c in mutliple architectures

[Anoop Thomas Mathew]

Signed-off-by: Anoop Thomas Mathew 
---
 arch/arc/kernel/kprobes.c |2 +-
 arch/ia64/kernel/kprobes.c|2 +-
 arch/powerpc/kernel/kprobes.c |2 +-
 arch/s390/kernel/kprobes.c|2 +-
 arch/sparc/kernel/kprobes.c   |2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arc/kernel/kprobes.c b/arch/arc/kernel/kprobes.c
index 72f9782..7446c8d 100644
--- a/arch/arc/kernel/kprobes.c
+++ b/arch/arc/kernel/kprobes.c
@@ -327,7 +327,7 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, 
unsigned long trapnr)
 */
 
/* We increment the nmissed count for accounting,
-* we can also use npre/npostfault count for accouting
+* we can also use npre/npostfault count for accounting
 * these specific fault cases.
 */
kprobes_inc_nmissed_count(cur);
diff --git a/arch/ia64/kernel/kprobes.c b/arch/ia64/kernel/kprobes.c
index f8280a7..074fde4 100644
--- a/arch/ia64/kernel/kprobes.c
+++ b/arch/ia64/kernel/kprobes.c
@@ -947,7 +947,7 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, 
int trapnr)
case KPROBE_HIT_SSDONE:
/*
 * We increment the nmissed count for accounting,
-* we can also use npre/npostfault count for accouting
+* we can also use npre/npostfault count for accounting
 * these specific fault cases.
 */
kprobes_inc_nmissed_count(cur);
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index 2156ea9..90fab64 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -429,7 +429,7 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, 
int trapnr)
case KPROBE_HIT_SSDONE:
/*
 * We increment the nmissed count for accounting,
-* we can also use npre/npostfault count for accouting
+* we can also use npre/npostfault count for accounting
 * these specific fault cases.
 */
kprobes_inc_nmissed_count(cur);
diff --git a/arch/s390/kernel/kprobes.c b/arch/s390/kernel/kprobes.c
index 0ce9fb2..018c1c4 100644
--- a/arch/s390/kernel/kprobes.c
+++ b/arch/s390/kernel/kprobes.c
@@ -673,7 +673,7 @@ static int __kprobes kprobe_trap_handler(struct pt_regs 
*regs, int trapnr)
case KPROBE_HIT_SSDONE:
/*
 * We increment the nmissed count for accounting,
-* we can also use npre/npostfault count for accouting
+* we can also use npre/npostfault count for accounting
 * these specific fault cases.
 */
kprobes_inc_nmissed_count(p);
diff --git a/arch/sparc/kernel/kprobes.c b/arch/sparc/kernel/kprobes.c
index e722121..d3d5d38 100644
--- a/arch/sparc/kernel/kprobes.c
+++ b/arch/sparc/kernel/kprobes.c
@@ -349,7 +349,7 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, 
int trapnr)
case KPROBE_HIT_SSDONE:
/*
 * We increment the nmissed count for accounting,
-* we can also use npre/npostfault count for accouting
+* we can also use npre/npostfault count for accounting
 * these specific fault cases.
 */
kprobes_inc_nmissed_count(cur);
-- 
1.7.9.5

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

Re: [PATCH V2 1/1] Drivers: input: serio: New driver to support Hyper-V synthetic keyboard

[Dmitry Torokhov]

Hi K.Y.,

On Tue, Sep 17, 2013 at 04:26:58PM -0700, K. Y. Srinivasan wrote:
> Add a new driver to support synthetic keyboard. On the next generation
> Hyper-V guest firmware, many legacy devices will not be emulated and this
> driver will be required.
> 
> I would like to thank Vojtech Pavlik  for helping me with the
> details of the AT keyboard driver. I would also like to thank
> Dan Carpenter  and
> Dmitry Torokhov  for their detailed review of this
> driver.
> 
> I have addressed all the comments of Dan and Dmitry in this version of
> the patch

This looks much better. Could you tell me if the patch below (on top of
yours) still works?

Thanks.

-- 
Dmitry

Input: hyperv-keyboard - misc changes

From: Dmitry Torokhov 

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/serio/Kconfig   |3 
 drivers/input/serio/hyperv-keyboard.c |  378 ++---
 2 files changed, 208 insertions(+), 173 deletions(-)

diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index f3996e7..a5f342e 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -274,4 +274,7 @@ config HYPERV_KEYBOARD
help
  Select this option to enable the Hyper-V Keyboard driver.
 
+ To compile this driver as a module, choose M here: the module will
+ be called hyperv_keyboard.
+
 endif
diff --git a/drivers/input/serio/hyperv-keyboard.c 
b/drivers/input/serio/hyperv-keyboard.c
index c327a18..401fbdd 100644
--- a/drivers/input/serio/hyperv-keyboard.c
+++ b/drivers/input/serio/hyperv-keyboard.c
@@ -10,6 +10,7 @@
  *  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  *  more details.
  */
+
 #include 
 #include 
 #include 
@@ -42,20 +43,16 @@ enum synth_kbd_msg_type {
  * Basic message structures.
  */
 struct synth_kbd_msg_hdr {
-   u32 type;
+   __le32 type;
 };
 
 struct synth_kbd_msg {
struct synth_kbd_msg_hdr header;
-   char data[1]; /* Enclosed message */
+   char data[]; /* Enclosed message */
 };
 
 union synth_kbd_version {
-   struct {
-   u16 minor_version;
-   u16 major_version;
-   };
-   u32 version;
+   __le32 version;
 };
 
 /*
@@ -78,8 +75,8 @@ struct synth_kbd_protocol_response {
 #define IS_E1  BIT(3)
 struct synth_kbd_keystroke {
struct synth_kbd_msg_hdr header;
-   u16 make_code;
-   u16 reserved0;
+   __le16 make_code;
+   __le16 reserved0;
__le32 info; /* Additional information */
 };
 
@@ -98,58 +95,27 @@ struct synth_kbd_keystroke {
  * Represents a keyboard device
  */
 struct hv_kbd_dev {
-   struct hv_device*device;
+   struct hv_device *hv_dev;
+   struct serio *hv_serio;
struct synth_kbd_protocol_request protocol_req;
struct synth_kbd_protocol_response protocol_resp;
/* Synchronize the request/response if needed */
-   struct completion   wait_event;
-   struct serio*hv_serio;
+   struct completion wait_event;
+   spinlock_t lock; /* protects 'started' field */
+   bool started;
 };
 
-
-static struct hv_kbd_dev *hv_kbd_alloc_device(struct hv_device *device)
-{
-   struct hv_kbd_dev *kbd_dev;
-   struct serio *hv_serio;
-
-   kbd_dev = kzalloc(sizeof(struct hv_kbd_dev), GFP_KERNEL);
-   if (!kbd_dev)
-   return NULL;
-   hv_serio = kzalloc(sizeof(struct serio), GFP_KERNEL);
-   if (hv_serio == NULL) {
-   kfree(kbd_dev);
-   return NULL;
-   }
-   hv_serio->id.type = SERIO_8042_XL;
-   strlcpy(hv_serio->name, dev_name(>device),
-   sizeof(hv_serio->name));
-   strlcpy(hv_serio->phys, dev_name(>device),
-   sizeof(hv_serio->phys));
-   hv_serio->dev.parent  = >device;
-   kbd_dev->device = device;
-   kbd_dev->hv_serio = hv_serio;
-   hv_set_drvdata(device, kbd_dev);
-   init_completion(_dev->wait_event);
-
-   return kbd_dev;
-}
-
-static void hv_kbd_free_device(struct hv_kbd_dev *device)
-{
-   serio_unregister_port(device->hv_serio);
-   hv_set_drvdata(device->device, NULL);
-   kfree(device);
-}
-
-static void hv_kbd_on_receive(struct hv_device *device,
-   struct synth_kbd_msg *msg, u32 msg_length)
+static void hv_kbd_on_receive(struct hv_device *hv_dev,
+ struct synth_kbd_msg *msg, u32 msg_length)
 {
-   struct hv_kbd_dev *kbd_dev = hv_get_drvdata(device);
+   struct hv_kbd_dev *kbd_dev = hv_get_drvdata(hv_dev);
struct synth_kbd_keystroke *ks_msg;
-   u16 scan_code;
+   unsigned long flags;
+   u32 msg_type = __le32_to_cpu(msg->header.type);
u32 info;
+   u16 scan_code;
 
-   switch (msg->header.type) {
+   switch (msg_type) {
case SYNTH_KBD_PROTOCOL_RESPONSE:
/*
 * Validate the information provided by the host.
@@ -158,13 +124,17 

Re: [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 16:52 -0400, Eduardo Valentin wrote:
> On 18-09-2013 16:44, Joe Perches wrote:
> > On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:
> > 
> >> +/**
> >> + * of_parse_thermal_zones - parse device tree thermal data
> >> + *
> >> + * Initialization function that can be called by machine initialization
> >> + * code to parse thermal data and populate the thermal framework
> >> + * with hardware thermal zones info. This function only parses thermal 
> >> zones.
> >> + * Cooling devices and sensor devices nodes are supposed to be parsed
> >> + * by their respective drivers.
> >> + *
> >> + * Return: 0 on success, proper error code otherwise
> >> + *
> >> + */
> >> +int __init of_parse_thermal_zones(void)
> >> +{
> >> +  struct device_node *np, *child;
> >> +  struct __thermal_zone *tz;
> >> +  struct thermal_zone_device_ops *ops;
> >> +
> >> +  np = of_find_node_by_name(NULL, "thermal-zones");
> >> +  if (!np) {
> >> +  pr_err("unable to find thermal zones\n");
> >> +  return 0;
> > 
> > return 0? This is success?
> 
> This case is success because there should be systems without thermal DT
> entries.

Then the pr_err should be pr_notice/info or not there at all.

[]

> >> +  /* No hwmon because there might be hwmon drivers registering */
> >> +  tzp->no_hwmon = true;
> >> +
> >> +  zone = thermal_zone_device_register(child->name, tz->ntrips,
> >> +  0, tz,
> >> +  ops, tzp,
> >> +  tz->passive_delay,
> >> +  tz->polling_delay);
> >> +  if (IS_ERR(zone))
> >> +  pr_err("Failed to build %s zone %ld\n", child->name,
> >> + PTR_ERR(zone));

Should there should be a return -ERR here?

> hmmm.. I am sending after reworking the return code of this function.

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/

[PATCHv5 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

This patch introduces a device tree bindings for
describing the hardware thermal behavior and limits.
Also a parser to read and interpret the data and feed
it in the thermal framework is presented.

This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.

This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.

Note that, in order to be able to have control
on the sensor registration on the DT thermal zone,
it was required to allow changing the thermal zone
.get_temp callback. For this reason, this patch
also removes the 'const' modifier from the .ops
field of thermal zone devices.

Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
 .../devicetree/bindings/thermal/thermal.txt| 498 ++
 drivers/thermal/Kconfig|  13 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/of-thermal.c   | 757 +
 drivers/thermal/thermal_core.c |   9 +-
 drivers/thermal/thermal_core.h |   9 +
 include/dt-bindings/thermal/thermal.h  |  27 +
 include/linux/thermal.h|  28 +-
 8 files changed, 1339 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
 create mode 100644 drivers/thermal/of-thermal.c
 create mode 100644 include/dt-bindings/thermal/thermal.h
---

Hello guys,

I've got couple of review suggestions by Joe P., so I am resending v5, as they 
were
minor changes. I've replaced kzalloc/memcpy by kmemdup and improved the error
code reporting in the init function of the parser.

Thanks Joe!

Eduardo

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 000..6664533
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,498 @@
+* Thermal Framework Device Tree descriptor
+
+Generic binding to provide a way of defining hardware thermal
+structure using device tree. A thermal structure includes thermal
+zones and their components, such as trip points, polling intervals,
+sensors and cooling devices binding descriptors.
+
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects, not how the system must control or which
+algorithm or policy must be taken in place.
+
+There are five types of nodes involved to describe thermal bindings:
+- sensors: used to describe the device source of temperature sensing;
+- cooling devices: used to describe devices source of power dissipation 
control;
+- trip points: used to describe points in temperature domain defined to
+make the system aware of hardware limits;
+- cooling attachments: used to describe links between trip points and
+cooling devices;
+- thermal zones: used to describe thermal data within the hardware;
+
+It follows a description of each type of these device tree nodes.
+
+* Sensor devices
+
+Sensor devices are nodes providing temperature sensing capabilities on thermal
+zones. Typical devices are I2C ADC converters and bandgaps. Theses are nodes
+providing temperature data to thermal zones. Temperature sensor devices may
+control one or more internal sensors.
+
+Required property:
+- #sensor-cells:   Used to provide sensor device specific information
+   while referring to it. Must be at least 1, in order
+   to identify uniquely the sensor instances within
+   the IC. See thermal zone binding for more details
+   on how consumers refer to sensor devices.
+
+* Cooling device nodes
+
+Cooling devices are nodes providing control on power dissipation. There
+are essentially two ways to provide control on power dissipation. First
+is by means of regulating device performance, which is known as passive
+cooling. Second is by means of activating devices in order to remove
+the dissipated heat, which is known as active cooling, e.g. regulating
+fan speeds. In both cases, cooling devices shall have a way to determine
+the level of cooling.
+
+Required property:
+- cooling-min-level:   A unsigned integer indicating the smallest
+   cooling level accepted. Typically 0.
+- cooling-max-level:   An unsigned integer indicating the largest
+   cooling level accepted.
+- #cooling-cells:  Used to provide cooling device specific information
+   while referring to it. Must be at least 2, in order
+   to specify minimum and maximum cooling level used
+   in the reference. See Cooling device attachments section
+   below for more 

Re: [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Eduardo Valentin]

On 18-09-2013 16:44, Joe Perches wrote:
> On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:
> 
>> +/**
>> + * of_parse_thermal_zones - parse device tree thermal data
>> + *
>> + * Initialization function that can be called by machine initialization
>> + * code to parse thermal data and populate the thermal framework
>> + * with hardware thermal zones info. This function only parses thermal 
>> zones.
>> + * Cooling devices and sensor devices nodes are supposed to be parsed
>> + * by their respective drivers.
>> + *
>> + * Return: 0 on success, proper error code otherwise
>> + *
>> + */
>> +int __init of_parse_thermal_zones(void)
>> +{
>> +struct device_node *np, *child;
>> +struct __thermal_zone *tz;
>> +struct thermal_zone_device_ops *ops;
>> +
>> +np = of_find_node_by_name(NULL, "thermal-zones");
>> +if (!np) {
>> +pr_err("unable to find thermal zones\n");
>> +return 0;
> 
> return 0? This is success?

This case is success because there should be systems without thermal DT
entries.

> 
>> +}
>> +
>> +for_each_child_of_node(np, child) {
>> +struct thermal_zone_device *zone;
>> +struct thermal_zone_params *tzp;
>> +
>> +tz = thermal_of_build_thermal_zone(child);
>> +if (IS_ERR(tz)) {
>> +pr_err("failed to build thermal zone %ld\n",
>> +   PTR_ERR(tz));
>> +return 0;
>> +}
>> +
>> +ops = kzalloc(sizeof(*ops), GFP_KERNEL);
>> +if (!ops)
>> +return 0;
>> +
>> +memcpy(ops, _thermal_ops, sizeof(*ops));
> 
> kmemdup instead of alloc/memcpy
> 

OK.

>> +tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
>> +if (!ops)
>> +return 0;
>> +

These should not be 0 though.

>> +/* No hwmon because there might be hwmon drivers registering */
>> +tzp->no_hwmon = true;
>> +
>> +zone = thermal_zone_device_register(child->name, tz->ntrips,
>> +0, tz,
>> +ops, tzp,
>> +tz->passive_delay,
>> +tz->polling_delay);
>> +if (IS_ERR(zone))
>> +pr_err("Failed to build %s zone %ld\n", child->name,
>> +   PTR_ERR(zone));
>> +}
>> +return 0;

This one is correct.

>> +}
> 
> All returns are 0, always successful?

hmmm.. I am sending after reworking the return code of this function.

> 
> 
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 8/8] audit: add audit_backlog_wait_time configuration option

[Eric Paris]

On Wed, 2013-09-18 at 16:49 -0400, Richard Guy Briggs wrote:
> On Wed, Sep 18, 2013 at 04:33:25PM -0400, Eric Paris wrote:
> > On Wed, 2013-09-18 at 15:06 -0400, Richard Guy Briggs wrote:
> > > reaahead-collector abuses the audit logging facility to discover which 
> > > files
> > > are accessed at boot time to make a pre-load list
> > > 
> > > Add a tuning option to audit_backlog_wait_time so that if auditd can't 
> > > keep up,
> > > or gets blocked, the callers won't be blocked.
> 
> > > diff --git a/kernel/audit.c b/kernel/audit.c
> > > index 3d17670..fc535b6 100644
> > > --- a/kernel/audit.c
> > > +++ b/kernel/audit.c
> > > @@ -701,8 +708,21 @@ static int audit_receive_msg(struct sk_buff *skb, 
> > > struct nlmsghdr *nlh)
> > >   if (err < 0)
> > >   return err;
> > >   }
> > > - if (s.mask & AUDIT_STATUS_BACKLOG_LIMIT)
> > > + if (s.mask & AUDIT_STATUS_BACKLOG_LIMIT) {
> > >   err = audit_set_backlog_limit(s.backlog_limit);
> > > + if (err < 0)
> > > + return err;
> > > + }
> > > + if (s.mask & AUDIT_STATUS_BACKLOG_WAIT_TIME) {
> > > + if (sizeof(s) > (size_t)nlh->nlmsg_len)
> > > + break;
> > 
> > What gets returned here?  I think err has a value of 0, but it doesn't
> > seem to have been clearly intentional.  If they know about the
> > AUDIT_STATUS_BACKLOG_WAIT_TIME flag, but they didn't send a long enough
> > skb?  That seems like an error condition
> 
> The intent was that it is a NOP, since err would have a value of zero,
> but I see your point, that if that flag is present, the struct member
> should be too.  My original intent was that if the structure member
> wasn't present, it would default to zero, unintentionally setting the
> wait time to zero.  It was part of my paranoia in the absence of an API
> version indicator.  No harm done, but I agree it should return an error.
> 
> Thanks for the catch.
> 
> > > + if (s.backlog_wait_time < 0 ||
> > > + s.backlog_wait_time > 10*AUDIT_BACKLOG_WAIT_TIME)
> > > + return -EINVAL;
> 
> I assume values less than zero or larger than 10 times the current
> default of one minute are errors or unreasonable.
> 
> Any argument for more than 10 minutes?

10 Minutes already seems nuts.  If someone has a reason to go higher, we
can change this sanity check then.

-Eric

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

Re: [patch 0/7] improve memcg oom killer robustness v2

[azurIt]

> CC: "Michal Hocko" , "Andrew Morton" 
> , "David Rientjes" , 
> "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro" 
> , linux...@kvack.org, 
> cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org, 
> linux-kernel@vger.kernel.org
>On Wed, Sep 18, 2013 at 02:19:46PM -0400, Johannes Weiner wrote:
>> On Wed, Sep 18, 2013 at 02:04:55PM -0400, Johannes Weiner wrote:
>> > On Wed, Sep 18, 2013 at 04:03:04PM +0200, azurIt wrote:
>> > > > CC: "Johannes Weiner" , "Andrew Morton" 
>> > > > , "David Rientjes" , 
>> > > > "KAMEZAWA Hiroyuki" , "KOSAKI 
>> > > > Motohiro" , linux...@kvack.org, 
>> > > > cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org, 
>> > > > linux-kernel@vger.kernel.org
>> > > >On Tue 17-09-13 13:15:35, azurIt wrote:
>> > > >[...]
>> > > >> Is something unusual on this stack?
>> > > >> 
>> > > >> 
>> > > >> [] dump_header+0x7e/0x1e0
>> > > >> [] ? find_lock_task_mm+0x2f/0x70
>> > > >> [] oom_kill_process+0x85/0x2a0
>> > > >> [] mem_cgroup_out_of_memory+0xa8/0xf0
>> > > >> [] mem_cgroup_oom_synchronize+0x2e6/0x310
>> > > >> [] ? mem_cgroup_uncharge_page+0x40/0x40
>> > > >> [] pagefault_out_of_memory+0x13/0x130
>> > > >> [] mm_fault_error+0x9e/0x150
>> > > >> [] do_page_fault+0x404/0x490
>> > > >> [] ? do_mmap_pgoff+0x3dc/0x430
>> > > >> [] page_fault+0x1f/0x30
>> > > >
>> > > >This is a regular memcg OOM killer. Which dumps messages about what is
>> > > >going to do. So no, nothing unusual, except if it was like that for ever
>> > > >which would mean that oom_kill_process is in the endless loop. But a
>> > > >single stack doesn't tell us much.
>> > > >
>> > > >Just a note. When you see something hogging a cpu and you are not sure
>> > > >whether it might be in an endless loop inside the kernel it makes sense
>> > > >to take several snaphosts of the stack trace and see if it changes. If
>> > > >not and the process is not sleeping (there is no schedule on the trace)
>> > > >then it might be looping somewhere waiting for Godot. If it is sleeping
>> > > >then it is slightly harder because you would have to identify what it is
>> > > >waiting for which requires to know a deeper context.
>> > > >-- 
>> > > >Michal Hocko
>> > > >SUSE Labs
>> > > 
>> > > 
>> > > 
>> > > I was finally able to get stack of problematic process :) I saved it two 
>> > > times from the same process, as Michal suggested (i wasn't able to take 
>> > > more). Here it is:
>> > > 
>> > > First (doesn't look very helpfull):
>> > > [] 0x
>> > > 
>> > > 
>> > > Second:
>> > > [] shrink_zone+0x481/0x650
>> > > [] do_try_to_free_pages+0xde/0x550
>> > > [] try_to_free_pages+0x9b/0x120
>> > > [] free_more_memory+0x5d/0x60
>> > > [] __getblk+0x14d/0x2c0
>> > > [] __bread+0x13/0xc0
>> > > [] ext3_get_branch+0x98/0x140
>> > > [] ext3_get_blocks_handle+0xd7/0xdc0
>> > > [] ext3_get_block+0xc4/0x120
>> > > [] do_mpage_readpage+0x38a/0x690
>> > > [] mpage_readpages+0xfb/0x160
>> > > [] ext3_readpages+0x1d/0x20
>> > > [] __do_page_cache_readahead+0x1c5/0x270
>> > > [] ra_submit+0x21/0x30
>> > > [] filemap_fault+0x380/0x4f0
>> > > [] __do_fault+0x78/0x5a0
>> > > [] handle_pte_fault+0x84/0x940
>> > > [] handle_mm_fault+0x16a/0x320
>> > > [] do_page_fault+0x13b/0x490
>> > > [] page_fault+0x1f/0x30
>> > > [] 0x
>> > 
>> > Ah, crap.  I'm sorry.  You even showed us this exact trace before in
>> > another context, but I did not fully realize what __getblk() is doing.
>> > 
>> > My subsequent patches made a charge attempt return -ENOMEM without
>> > reclaim if the memcg is under OOM.  And so the reason you have these
>> > reclaim livelocks is because __getblk never fails on -ENOMEM.  When
>> > the allocation returns -ENOMEM, it invokes GLOBAL DIRECT RECLAIM and
>> > tries again in an endless loop.  The memcg code would previously just
>> > loop inside the charge, reclaiming and killing, until the allocation
>> > succeeded.  But the new code relies on the fault stack being unwound
>> > to complete the OOM kill.  And since the stack is not unwound with
>> > __getblk() looping around the allocation there is no more memcg
>> > reclaim AND no memcg OOM kill, thus no chance of exiting.
>> > 
>> > That code is weird but really old, so it may take a while to evaluate
>> > all the callers as to whether this can be changed.
>> > 
>> > In the meantime, I would just allow __getblk to bypass the memcg limit
>> > when it still can't charge after reclaim.  Does the below get your
>> > machine back on track?
>> 
>> Scratch that.  The idea is reasonable but the implementation is not
>> fully cooked yet.  I'll send you an update.
>
>Here is an update.  Full replacement on top of 3.2 since we tried a
>dead end and it would be more painful to revert individual changes.
>
>The first bug you had was the same task entering OOM repeatedly and
>leaking the memcg reference, thus creating undeletable memcgs.  My
>fixup added a condition that if the task already set up an OOM context
>in that fault, another charge attempt 

Re: [PATCH 1/2] hwrng: OMAP3 ROM Random Number Generator support

[Aaro Koskinen]

Hi,

On Wed, Sep 18, 2013 at 10:05:56PM +0200, Pali Rohár wrote:
> + if (IS_ERR(rng_clk)) {
> + printk(KERN_ERR "%s: unable to get RNG clock\n",
> +omap3_rom_rng_name);
> + return IS_ERR(rng_clk);

This should be PTR_ERR().

A.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/8] audit: add audit_backlog_wait_time configuration option

[Richard Guy Briggs]

On Wed, Sep 18, 2013 at 04:33:25PM -0400, Eric Paris wrote:
> On Wed, 2013-09-18 at 15:06 -0400, Richard Guy Briggs wrote:
> > reaahead-collector abuses the audit logging facility to discover which files
> > are accessed at boot time to make a pre-load list
> > 
> > Add a tuning option to audit_backlog_wait_time so that if auditd can't keep 
> > up,
> > or gets blocked, the callers won't be blocked.

> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 3d17670..fc535b6 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -701,8 +708,21 @@ static int audit_receive_msg(struct sk_buff *skb, 
> > struct nlmsghdr *nlh)
> > if (err < 0)
> > return err;
> > }
> > -   if (s.mask & AUDIT_STATUS_BACKLOG_LIMIT)
> > +   if (s.mask & AUDIT_STATUS_BACKLOG_LIMIT) {
> > err = audit_set_backlog_limit(s.backlog_limit);
> > +   if (err < 0)
> > +   return err;
> > +   }
> > +   if (s.mask & AUDIT_STATUS_BACKLOG_WAIT_TIME) {
> > +   if (sizeof(s) > (size_t)nlh->nlmsg_len)
> > +   break;
> 
> What gets returned here?  I think err has a value of 0, but it doesn't
> seem to have been clearly intentional.  If they know about the
> AUDIT_STATUS_BACKLOG_WAIT_TIME flag, but they didn't send a long enough
> skb?  That seems like an error condition

The intent was that it is a NOP, since err would have a value of zero,
but I see your point, that if that flag is present, the struct member
should be too.  My original intent was that if the structure member
wasn't present, it would default to zero, unintentionally setting the
wait time to zero.  It was part of my paranoia in the absence of an API
version indicator.  No harm done, but I agree it should return an error.

Thanks for the catch.

> > +   if (s.backlog_wait_time < 0 ||
> > +   s.backlog_wait_time > 10*AUDIT_BACKLOG_WAIT_TIME)
> > +   return -EINVAL;

I assume values less than zero or larger than 10 times the current
default of one minute are errors or unreasonable.

Any argument for more than 10 minutes?


- RGB

--
Richard Guy Briggs 
Senior Software Engineer
Kernel Security
AMER ENG Base Operating Systems
Remote, Ottawa, Canada
Voice: +1.647.777.2635
Internal: (81) 32635
Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/26] ARM: provide common arch init for DT clocks

[Olof Johansson]

On Wed, Sep 18, 2013 at 12:52 PM, Sebastian Hesselbarth
 wrote:
> On 09/18/2013 09:47 PM, Jason Cooper wrote:
>>
>> On Wed, Sep 18, 2013 at 07:53:33PM +0200, Sebastian Hesselbarth wrote:
>> ...
>>>
>>> Sebastian Hesselbarth (26):
>>>ARM: nomadik: move mtu setup to clocksource init
>>>clk: nomadik: move src init out of nomadik_clk_init
>>>clk: nomadik: declare OF clock provider
>>>clk: prima2: declare OF clock provider
>>>ARM: socfgpa: prepare for arch-wide .init_time callback
>>>clk: sunxi: declare OF clock provider
>>>clk: vt8500: parse pmc_base from clock driver
>>>ARM: vt8500: prepare for arch-wide .init_time callback
>>>ARM: call of_clk_init from default time_init handler
>>>ARM: bcm2835: remove custom .init_time hook
>>>ARM: dove: remove custom .init_time hook
>>>ARM: exynos: remove custom .init_time hook
>>>ARM: highbank: remove custom .init_time hook
>>>ARM: imx: remove custom .init_time hook
>>>ARM: kirkwood: remove custom .init_time hook
>>>ARM: mxs: remove custom .init_time hook
>>>ARM: nomadik: remove custom .init_time hook
>>>ARM: nspire: remove custom .init_time hook
>>>ARM: prima2: remove custom .init_time hook
>>>ARM: rockchip: remove custom .init_time hook
>>>ARM: socfpga: remove custom .init_time hook
>>>ARM: sti: remove custom .init_time hook
>>>ARM: sunxi: remove custom .init_time hook
>>>ARM: tegra: remove custom .init_time hook
>>>ARM: vexpress: remove custom .init_time hook
>>>ARM: vt8500: remove custom .init_time hook
>>>
>>>   arch/arm/kernel/time.c|   27 ++---
>>>   arch/arm/mach-bcm2835/bcm2835.c   |2 -
>>>   arch/arm/mach-dove/board-dt.c |   11 --
>>>   arch/arm/mach-exynos/common.c |8 --
>>>   arch/arm/mach-exynos/common.h |1 -
>>>   arch/arm/mach-exynos/mach-exynos4-dt.c|2 -
>>>   arch/arm/mach-exynos/mach-exynos5-dt.c|2 -
>>>   arch/arm/mach-highbank/highbank.c |   23 ++---
>>>   arch/arm/mach-imx/clk-imx51-imx53.c   |   29 ++
>>>   arch/arm/mach-imx/common.h|4 -
>>>   arch/arm/mach-imx/imx51-dt.c  |6 --
>>>   arch/arm/mach-imx/mach-imx53.c|6 --
>>>   arch/arm/mach-imx/mach-imx6q.c|   14 +--
>>>   arch/arm/mach-imx/mach-imx6sl.c   |7 --
>>>   arch/arm/mach-imx/mach-vf610.c|9 --
>>>   arch/arm/mach-kirkwood/board-dt.c |8 --
>>>   arch/arm/mach-mxs/mach-mxs.c  |   13 ---
>>>   arch/arm/mach-nomadik/cpu-8815.c  |   36 ---
>>>   arch/arm/mach-nspire/nspire.c |9 --
>>>   arch/arm/mach-prima2/common.c |   11 --
>>>   arch/arm/mach-prima2/common.h |1 -
>>>   arch/arm/mach-rockchip/rockchip.c |9 --
>>>   arch/arm/mach-socfpga/socfpga.c   |2 -
>>>   arch/arm/mach-sti/board-dt.c  |   10 +-
>>>   arch/arm/mach-sunxi/sunxi.c   |   10 --
>>>   arch/arm/mach-tegra/tegra.c   |9 --
>>>   arch/arm/mach-vexpress/v2m.c  |   14 +--
>>>   arch/arm/mach-vt8500/common.h |   24 -
>>>   arch/arm/mach-vt8500/vt8500.c |6 --
>>>   drivers/clk/clk-bcm2835.c |8 --
>>>   drivers/clk/clk-highbank.c|   10 +-
>>>   drivers/clk/clk-nomadik.c |  161
>>> ++---
>>>   drivers/clk/clk-prima2.c  |   29 ++
>>>   drivers/clk/clk-vt8500.c  |   31 --
>>>   drivers/clk/mxs/clk-imx23.c   |   15 +--
>>>   drivers/clk/mxs/clk-imx28.c   |   16 +--
>>>   drivers/clk/sunxi/clk-sunxi.c |   11 +-
>>>   drivers/clocksource/nomadik-mtu.c |   11 ++
>>>   include/linux/clk/mxs.h   |2 -
>>>   include/linux/clk/sunxi.h |   22 
>>>   include/linux/platform_data/clk-nomadik.h |2 -
>>>   41 files changed, 182 insertions(+), 449 deletions(-)
>>>   delete mode 100644 arch/arm/mach-vt8500/common.h
>>>   delete mode 100644 include/linux/clk/sunxi.h
>>>   delete mode 100644 include/linux/platform_data/clk-nomadik.h
>>
>>
>> How would you like to handle this series?
>
>
> Jason,
>
> honestly I don't really know, yet. I was hoping for Arnd and Olof
> decide on that. Maybe they also create a topic branch up to where
> arch-wide of_clk_init is introduced. Then each removal patch can
> go through the independent sub-trees. There may be more machs
> introduced before, that can then also depend on the common branch.

I'd like to see this merged early into arm-soc and have it as a base
branch for other platform branches if there will be much conflicts
(for trivial or small conflicts we can resolve, of course). So please
collect acks and prepare a branch for me to merge, Sebastian. Or if
it's easier I can just apply the patches directly -- just let me know.
But given 

Re: [PATCH 00/26] ARM: provide common arch init for DT clocks

[Stephen Warren]

On 09/18/2013 01:52 PM, Sebastian Hesselbarth wrote:
> On 09/18/2013 09:47 PM, Jason Cooper wrote:
>> On Wed, Sep 18, 2013 at 07:53:33PM +0200, Sebastian Hesselbarth wrote:
>> ...
>>> Sebastian Hesselbarth (26):
>>>ARM: nomadik: move mtu setup to clocksource init
...
>>
>> How would you like to handle this series?
> 
> Jason,
> 
> honestly I don't really know, yet. I was hoping for Arnd and Olof
> decide on that. Maybe they also create a topic branch up to where
> arch-wide of_clk_init is introduced. Then each removal patch can
> go through the independent sub-trees. There may be more machs
> introduced before, that can then also depend on the common branch.

Oh, I was assuming you'd just take the whole thing through one tree,
likely in arm-soc. That's why I created the topic branch for the Tegra
PMIC patch that's a dependency of this... However, I guess if you just
merge the core into a topic branch in arm-soc and everyone merges it
back, that's fine. I assume the Tegra topic branch I created won't be
necessary in that case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv4 02/16] drivers: thermal: introduce device tree parser

[Joe Perches]

On Wed, 2013-09-18 at 16:31 -0400, Eduardo Valentin wrote:

> +/**
> + * of_parse_thermal_zones - parse device tree thermal data
> + *
> + * Initialization function that can be called by machine initialization
> + * code to parse thermal data and populate the thermal framework
> + * with hardware thermal zones info. This function only parses thermal zones.
> + * Cooling devices and sensor devices nodes are supposed to be parsed
> + * by their respective drivers.
> + *
> + * Return: 0 on success, proper error code otherwise
> + *
> + */
> +int __init of_parse_thermal_zones(void)
> +{
> + struct device_node *np, *child;
> + struct __thermal_zone *tz;
> + struct thermal_zone_device_ops *ops;
> +
> + np = of_find_node_by_name(NULL, "thermal-zones");
> + if (!np) {
> + pr_err("unable to find thermal zones\n");
> + return 0;

return 0? This is success?

> + }
> +
> + for_each_child_of_node(np, child) {
> + struct thermal_zone_device *zone;
> + struct thermal_zone_params *tzp;
> +
> + tz = thermal_of_build_thermal_zone(child);
> + if (IS_ERR(tz)) {
> + pr_err("failed to build thermal zone %ld\n",
> +PTR_ERR(tz));
> + return 0;
> + }
> +
> + ops = kzalloc(sizeof(*ops), GFP_KERNEL);
> + if (!ops)
> + return 0;
> +
> + memcpy(ops, _thermal_ops, sizeof(*ops));

kmemdup instead of alloc/memcpy

> + tzp = kzalloc(sizeof(*tzp), GFP_KERNEL);
> + if (!ops)
> + return 0;
> +
> + /* No hwmon because there might be hwmon drivers registering */
> + tzp->no_hwmon = true;
> +
> + zone = thermal_zone_device_register(child->name, tz->ntrips,
> + 0, tz,
> + ops, tzp,
> + tz->passive_delay,
> + tz->polling_delay);
> + if (IS_ERR(zone))
> + pr_err("Failed to build %s zone %ld\n", child->name,
> +PTR_ERR(zone));
> + }
> + return 0;
> +}

All returns are 0, always successful?


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